DESC:The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-
This application is based on and derives the benefit of Indian Provisional Applications 4338/CHE/2015, the contents of which are incorporated herein by reference.

TECHNICAL FIELD
[001] The embodiments herein generally relate to Long Term Evolution (LTE) field and more particularly to handling of LTE Data Radio Bearer (DRB) offloaded to a Wireless Local Area Network (WLAN).

BACKGROUND
[002] Current wireless technology efficiently utilizes the licensed frequency spectrum to provide maximum data rate to a user of a User Equipment (UE). Even though advances in the wireless technology such as Long term Evolution (LTE) networks have increased the performance and capacity of wireless networks, this alone may not be sufficient to meet the data rate demand of future.
[003] Third Generation Partnership Project (3GPP) specifications provide mechanisms to meet the data rate demand of the UE, using means such as Carrier Aggregation (CA) or Dual Connectivity (DC) by adding radio resources to the UE. For example, the UE is configured with component carrier #1 and component carrier #2, where both these aggregated carriers are transmitted using LTE Radio Access Technology (RAT). Integration and/or aggregation of multiple RATs using the DC framework, where a LTE RAT and a wireless local area network (WLAN) RAT are aggregated at a radio layer are being explored. Such multiple RAT aggregation enables addition of radio resources to the UE from the unlicensed band along with radio resources in licensed band, providing efficient and appropriate usage of the unlicensed spectrum. A WLAN radio working in unlicensed spectrum for example, in the 2.4 GHz or 5.0 GHz band, can be aggregated when the UE is served by LTE carrier(s) such that aggregation of WLAN radio resources happens at the radio layer. A DC framework specified by 3GPP in Release-12 can be exploited such that a Data Radio Bearer (DRB) established for the UE on the LTE carrier can be split below a Packet Data Convergence Protocol (PDCP) layer and offloaded to WLAN over a standardized interface so that user plane packets (data packets) can be transmitted over the LTE air-interface and/or WLAN air-interface respectively. The established DRB considered for offload can be either downlink (DL) DRB and/or uplink (UL) DRB.
[004] When such offloading of user plane packets occurs at the PDCP layer, in accordance to existing 3GPP standard, a Wireless Terminal (WT) node of the WLAN is unable to understand the LTE QoS characteristics of the DRB for applying them for the data packets transmitted over the WLAN air interface. Thus, LTE QoS characteristics need to be mapped to WLAN QoS characteristics for the DRB offloaded to the WLAN. Without the mapping, this may lead to difficulty in maintaining the expected QoS of the user and effectively degrades the user experience.
[005] Further, there is a need for a flow control mechanism to control data rate for the offloaded data packets transmitted between a LTE node (eNB) and a WT node. Without the flow control mechanism it may lead to congestion of user data packets (PDCP Packet Data Units (PDUs)) transmitted between the LTE node and the WT node.

OBJECT OF INVENTION
[006] The principal object of the embodiments herein is to provide method and wireless communication system for handling offloading of one or more Data Radio Bearers (DRBs) of a User Equipment (UE) served by a Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier of a WLAN at a Packet Data Convergence Protocol (PDCP) layer, wherein data packets on an offloaded DRB are PDCP Protocol Data Units (PDUs)
[007] Another object of the embodiments herein is to provide a method for offloading of the one or more DRBs by mapping LTE Quality of Service (QoS) parameters of the offloaded DRB to WLAN QoS parameters at a LTE node or a WLAN Termination (WT) node of the WLAN.
[008] Another object of the embodiments herein is to provide a method for implementing a flow control mechanism at the WT node to control data rate at which data packets of the offloaded DRB are received by the WT node from the LTE node.

SUMMARY
[009] In view of the foregoing, an embodiment herein provides a method for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier served by a WLAN. The method comprises exchanging control plane signaling, by a LTE node with a WLAN Termination (WT) node, to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node. Further, the method comprises mapping, by one of the LTE node and the WT node, the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received on the offloaded DRB. Further, the method comprises receiving, by the WT node, data packets of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
[0010] Embodiments further disclose a wireless communication system for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier served by a WLAN. The wherein the wireless communication system comprises a LTE node configured to exchange control plane signaling with a WLAN Termination (WT) node to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node. Further, one of the LTE node and the WT node configured of the wireless communication system is configured to map the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received by the WT node on the offloaded DRB. Further, the WT node is configured to receive the data packets, sent by the LTE node, of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
[0011] Embodiments here further disclose a Wireless Local Area Network (WLAN) Termination node (WT node) for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a WLAN carrier served by a WLAN. The WT node comprises a WLAN offloading management module configured to exchange control plane signaling with a LTE node to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node. Further, the WLAN offloading management module is configured to map the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received on the offloaded DRB. Further, the WLAN offloading management module is configured to receive data packets of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
[0012] Embodiments herein further disclose a Long Term Evolution (LTE) node for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier served by a WLAN. The, LTE node comprises a WLAN offloading management module configured to exchange control plane signaling with a WLAN Termination (WT) node to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node. Further, the WLAN offloading management module is configured to map the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received by the WT node on the offloaded DRB. Furthermore, the WLAN offloading management module is configured to send the data packets of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
[0013] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES
[0014] The embodiments of this invention are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[0015] FIGs. 1a and 1b illustrate a wireless communication system providing aggregation of Long Term Evolution (LTE) Radio Access Technology (RAT) with Wireless Local Area Network (WLAN) RAT for offloading of data radio bearers (DRBs) served by a LTE carrier to a WLAN carrier served by the WLAN for a non- collocated deployment scenario, as disclosed in the embodiments herein;
[0016] FIG. 2 is a flow diagram illustrating a method for offloading of DRBs served by the LTE carrier to the WLAN carrier served by the WLAN, as disclosed in the embodiments herein;
[0017] FIG. 3 illustrates end to end protocol architecture to support the LTE RAT and the WLAN RAT aggregation at radio layer using layer 2 transport for both collocated scenario and non-collocated scenario, as disclosed in the embodiments herein;
[0018] FIGs. 4a and 4b illustrate user plane packet (data packet) structure for Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs) offloaded to the WLAN using layer 2 transport, as disclosed in the embodiments herein;
[0019] FIG. 5 illustrates a sequence diagram depicting steps for addition of the WT node conforming to dual connectivity (DC) framework, as disclosed in the embodiments herein.;
[0020] FIG. 6 illustrates a sequence diagram depicting steps for addition of the WT node to offload the DRBs, with mapping of LTE Quality of Service (QoS) parameters of the offloaded DRB to WLAN QoS parameters performed at the LTE node, as disclosed in the embodiments herein;
[0021] FIG. 7a and FIG 7b illustrates plurality of entities of the WLAN AP when interface between the LTE RAT and the WLAN RAT is terminated in the WLAN AP, as disclosed in the embodiments herein;
[0022] FIG. 8a and FIG. 8b illustrate plurality of entities of the WLAN AG (WT node) and the WLAN AP when interface between the LTE RAT and the WLAN RAT is terminated in the WLAN AG, as disclosed in the embodiments herein;
[0023] FIG. 9a and FIG. 9b illustrate plurality of entities of the WLAN AG (WT node) and the WLAN AP implementing a flow control mechanism at the WT node to control data rate at which the data packets of the offloaded DRB are received from the LTE node, as disclosed in the embodiments herein; and
[0024] FIG. 10 illustrates a sequence diagram depicting steps for implementation of the flow control mechanism at the WT node, as disclosed in the embodiments herein.
[0025] FIG. 11 illustrates a sequence diagram depicting implementation of the flow control mechanism at the UE side, as disclosed in the embodiments herein;
[0026] FIG. 12 a sequence diagram depicting a mechanism for providing Radio Link Failure (RLF) feedback to the LTE node from the WLAN AP, as disclosed in the embodiments herein;
[0027] FIG. 13 illustrates plurality of components of the LTE node, as disclosed in the embodiments herein;
[0028] FIG. 14 illustrates plurality of components of the WT node (WLAN AP or WLAN AG), as disclosed in the embodiments herein; and
[0029] FIG. 15 illustrates plurality of components of the UE, as disclosed in the embodiments herein.

DETAILED DESCRIPTION
[0030] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0031] The embodiments herein achieve a method and wireless communication system for handling offloading of one or more Data Radio Bearers (DRBs) of a User Equipment (UE). The DRBs served by a Long Term Evolution (LTE) carrier are offloaded to a Wireless Local Area Network (WLAN) carrier of a WLAN at a Packet Data Convergence Protocol (PDCP) layer. The data packets on an offloaded DRB are PDCP Protocol Data Units (PDUs). The offloaded DRB is assigned an LTE QoS parameter by an Evolved Packet Core (EPC) when an Evolved Packet System (EPS) bearer is created. The method includes offloading one or more DRBs by mapping LTE Quality of Service (QoS) parameter of the offloaded DRB to WLAN QoS parameter at a LTE eNB or a Wireless Termination (WT) node. In an embodiment, the WT node can be a WLAN Access Point (AP) or a WLAN Access Gateway (AG). Further, the method includes implementing a flow control mechanism at the WT node or at the UE to control data rate at which data packets of the offloaded DRB are received by the WT node from the LTE node.
[0032] In an embodiment, the wireless communication system is a system enabling aggregation of a LTE Radio Access Technology (RAT) or LTE network and a WLAN RAT or WLAN.
[0033] Throughout the description, the wireless communication system is explained for the non-collocated deployment scenario. However, it can be understood that the wireless communication system can be implemented for aggregation of the LTE RAT and the WLAN RAT at radio layer for a collocated deployment scenario with minimum modification. In the collocated scenario, the LTE node and the WT node of the WLAN are physically located in same physical node.
[0034] In an embodiment, the UE can be a mobile phone, a tablet, a smartphone, a personal digital assistant, a laptop or any communication device supporting the offloading of the DRBs by aggregation of the LTE RAT and the WLAN RAT.
[0035] Thus, method proposed facilitates the aggregation of the LTE RAT and the WLAN RAT at the radio layer by offloading LTE DRBs to WLAN. Further the proposed method provides mapping of LTE QoS parameter to the WLAN QoS parameters for the offloaded DRB to enable maintaining QoS associated with the DRB when data packets are scheduled through the WLAN RAT.
[0036] Referring now to the drawings, and more particularly to FIGS. 1 through 15, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
[0037] FIGs. 1a and 1b illustrate a wireless communication system 100 providing aggregation of Long Term Evolution (LTE) Radio Access Technology (RAT) with Wireless Local Area Network (WLAN) RAT for offloading of data radio bearers (DRBs) served by the LTE carrier to the WLAN carrier served by the WLAN for the non-collocated deployment scenario, as disclosed in the embodiments herein.
[0038] The FIG. 1a depicts the wireless communication system 100, where a standardized interface connects the LTE node 102 and one or more WT nodes, wherein the WT nodes include WLAN APs 106a through 106d respectively. For example, the standardized interface can be similar to the X2 interface and hence forth referred as Xw interface. The FIG. 1b depicts the wireless communication system 100, where the LTE node 102 is connected to a single WT node through the Xw interface, wherein the WT node is a WLAN Access Gateway (AG) 108, alternatively referred as WLAN Access Controller (AC). The WLAN AG or WLAN AC 108 can be configured to control multiple WLAN APs such as WLAN APs 106a through 106e through a local interface, for example, an Ethernet. Further, the WLAN APs 106a through 106e serve one or more UEs on a WLAN interface.
[0039] As depicted in FIG. 1a, plurality of UEs 104a through 104d supporting the capability of aggregating the LTE RAT and the WLAN RAT are served by the LTE node 102 on a licensed LTE carrier. Such a UE 104a establishes a Radio Resource Control (RRC) connection with the LTE node 102 on the licensed LTE carrier. There can be one or more DRBs established for a single UE 104a, thus as can be understood, multiple DRBs can exists per UE. The UE 104d and the UE 104e even though having capability to support LTE RAT and WLAN RAT aggregation are served only on the licensed LTE carrier from the LTE node 102 as they are not in the coverage area of any WT node (WLAN APs 106a through 106d respectively). However, the UE 104a, 104b and 104c respectively served by the LTE carrier of the LTE node 102 are within the coverage of the WLAN APs 106a, 106b and 106c respectively. Thus the DRBs for UE 104a, 104b and 104c respectively can be offloaded to the WLAN carrier of the WLAN AP 106a, 106b and 106c respectively.
[0040] As depicted in FIG. 1b, plurality of UEs 104a through 104e supporting the capability of aggregating the LTE RAT and the WLAN RAT are served by the LTE node 102 on the licensed LTE carrier. Such a UE 104a establishes the RRC connection with the LTE node 102 on the licensed LTE carrier. There can be one or more DRBs established for a single UE 104a, thus as can be understood, multiple DRBs can exists per UE. The UE 104b and the UE 104d even though having capability to support LTE RAT and WLAN RAT aggregation are served only on the licensed LTE carrier from the LTE node 102 as they are not in the coverage area of any WT node (WLAN APs 106a through 106e respectively). However, the UE 104a, 104c and 104e respectively served by the LTE carrier of the LTE node 102 are within the coverage of the WLAN APs 106a, 106c and 106e respectively. Thus the DRBs for UE 104a, 104c and 104e respectively can be offloaded to the WLAN carrier of the WLAN AP 106a, 106b and 106c respectively through the WLAN AG 108 (functioning as the WT node).
[0041] Thus the WT node can be the WLAN AP or the WLAN AG. However, regardless of whether the WT node is the WLAN AP or the WLAN AG procedures on Xw interface for adding WLAN resources for the UE are the same. The Xw interface would therefore support the control plane signaling and using a GPRS Tunneling Protocol User Plane (GTP-U) tunnel to transport user plane data from the LTE node 102 to the WT node. The procedures on the Xw interface are also applicable for the collocated scenario where the LTE node and the WT node are physically located in same physical node.
[0042] FIG. 2 is a flow diagram illustrating a method for offloading of DRBs served by the LTE carrier to the WLAN carrier served by the WLAN, as disclosed in the embodiments herein. Whenever, suitable WT node is identified by the LTE node 102, then the LTE node 102 may add the WT node for offloading one or more DRBs of one or more UEs to the WLAN carrier served by the WT node (WLAN AP 106a or WLAN AG 108), wherein the WT node(s) are connected to the LTE node 102 through the standardized interface such as the Xw interface. End to end protocol architecture to support the LTE RAT and the WLAN RAT aggregation at a radio layer using layer 2 transport for both collocated scenario and non-collocated scenario is explained in conjunction with FIG. 3. Further, steps for addition of the WT node are explained in conjunction with FIG. 5 and FIG. 6.
[0043] Once addition of the WT node is decided, then at step 202 the method 200 includes allowing the LTE node 102 to exchange control plane signaling with the WT node (WLAN AP 106a or WLAN AG 108) to establish one or more GPRS Tunneling Protocol User Plane (GTP-U) tunnels for offloading one or more DRBs of one or more UEs within the coverage area of the WT node (WLAN AP 106a or WLAN AG 108). Here DRBs of UE 106a lying within the coverage of the WLAN AP 106a that are initially served by the LTE carrier of the LTE node 102 can be offloaded to the WLAN carrier corresponding to the WT node (WLAN AP 106a or WLAN AG 108). Once, the offloading of one or more DRBs to the WT node (WLAN AP 106a or WLAN AG 108) is decided then the offloaded DRB (each offloaded DRB) already has assigned LTE QoS parameter. The offloading of one or more DRBs to the WLAN carrier is performed at the PDCP layer, wherein the data packets on the offloaded DRB are the PDCP PDUs.
[0044] At step 204, the method 200 includes allowing the WT node (WLAN AP 106a or WLAN AG 108) or the LTE node 102 to map the LTE QoS parameter associated with the offloaded DRB to the WLAN QoS parameter to enable scheduling of each data packet received on the offloaded DRB on the WLAN air interface. Thus, mapping of LTE QoS parameters to the WLAN QoS parameters can happen at either the LTE node 102 or the WT node (WLAN AP106a or WLAN AG 108) and is implementation specific.
[0045] Plurality of embodiments for mapping LTE QoS parameters to WLAN QoS parameters are explained in conjunction with FIG. 6. Plurality of LTE QoS parameters and WLAN QoS parameters that can be used and the need for mapping between them, is explained later in the description once steps 206 through 214 are explained.
[0046] At step 206, the method 200 includes allowing the WT node (WLAN AP 106a or WLAN AG 108) to receive data packets of the offloaded DRB through a GTP-U tunnel associated with the offloaded DRB. One or more GTU tunnels can be established per UE for one or more offloaded DRBs associated with that particular UE. Each data packet transported through the GTP-U tunnel, alternatively referred as tunnel, associated with the offloaded DRB comprises a plurality of headers. The headers comprise a GTP header and a Packet Data Convergence Protocol (PDCP) header. Further, the PDCP header comprises data radio bearer identity (DRB-ID) of the EPS bearer corresponding to the offloaded DRB. There is one-to-one mapping between DRB-ID and E-RAB for a corresponding EPS bearer. Therefore the terms DRB-ID and E-RAB are used interchangeably in the invention.
[0047] In an embodiment, the offloaded DRB can be a Downlink (DL) bearer established for the UE 104a.
[0048] In an embodiment, the offloaded DRB can be an uplink (UL) bearer established for the UE 104a. In such a case, the method 200 allows the LTE node 102 or the WT node (WLAN AP 106a or WLAN AG 108) to inform the mapped WLAN QoS parameter associated with the offloaded UL DRB to the UE 104a.
[0049] In scenario where the WT node is the WLAN AP 106a, at step 208 the method 200 includes allowing the WT node (WLAN AP 106a) to create one or more Access Class (AC) queues per UE corresponding to one or more WLAN AC categories in accordance with the WLAN QoS parameter assigned to the offloaded DRB. The data packets received through the GTP-U tunnel associated with the offloaded DRB are queued in the appropriate AC queue. At step 210, the method 200 includes allowing the WT node (WLAN AP 106a) to schedule on the WLAN carrier data packets queued in a Access Class (AC) queue, associated with the UE 104a based on the mapped WLAN QoS parameter. A user plane packet (data packet) structure for Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs) offloaded to the WLAN using layer 2 transport, where the WT node is the WLAN AP 106a, is explained in conjunction with FIG. 4a. Creation of one or more AC queues and buffering the data packets based on the mapped WLAN QoS parameter by the WLAN AP 106a is explained in conjunction with FIG. 7a and FIG. 7b. The method 200 allows the WT node (WLAN AP 106a or WLAN AG 108) to implement the flow control mechanism at the WT node or at the UE to control data rate at which the data packets of the offloaded DRB are received from the LTE node 102. The flow control mechanism comprises providing the LTE node 102 with a delivery status of each data packet.
[0050] However, when the WT node is the WLAN AG 108, the step 206 is followed by step 212, wherein, the method 200 includes allowing the WT node (WLAN AG 108) to mark each data packet of one or more offloaded DRBs with a WLAN QoS header. The WLAN QoS header of each data packet comprises the mapped WLAN QoS parameter for that offloaded DRB. At step 214, the method 200 includes allowing the WT node (WLAN AG 108) to transmit each marked data packet to the WLAN AP 106a over the local interface. Further, the method 200 allows the WLAN AP 106a to create one or more AC queues per UE based on the WLAN QoS header associated with each marked data packet of one or more offloaded DRBs. Such QoS marking in the header of each data packet enables to buffer each data packet in the appropriate AC queue. The data packets from the AC queue associated with the UE 104a are then scheduled on the WLAN carrier based on the mapped WLAN QoS parameter. The user plane packet (data packet) structure for PDCP PDUs offloaded to the WLAN using layer 2 transport, where the WT node is the WLAN AG 108, is explained in conjunction with FIG. 4b, FIG. 8a and FIG. 8b. The method 200 allows the WT node (WLAN AG 108) to implement the flow control mechanism at the WT node (WLAN 108) to control data rate at which the data packets of the offloaded DRB are received from the LTE node 102. The flow control mechanism comprises providing the LTE node 102 with the delivery status of each data packet. The delivery status is generated by mapping a PDCP sequence number associated with each data packet to a GTP-U sequence number, wherein the PDCP sequence number is received from the WLAN AP 106a. The PDCP sequence number is identified by the WLAN AP 106a by mapping the feedback received from the UE 104a for a MAC sequence number of each data packet transmitted on the WLAN carrier to the UE 104a. The flow control mechanism is explained in conjunction with FIG. 9a, FIG. 9b and FIG. 10.
[0051] As mentioned at step 204, the LTE QoS parameters and the WLAN QoS parameters that can used by the method 200 are provided below:
[0052] The LTE RAT and the WLAN RAT have their own set of QoS parameters for user plane data handling. Even though there is some difference in the approach used by both RATs in terms of access control there is some kind of similarity in terms of traffic classification and traffic prioritization. During radio layer aggregation of the WLAN with the LTE, any data radio bearer (DRB) that carries user plane traffic with a given set of required LTE QoS characteristics when at least some data of that DRB is transmitted using WLAN air interface does not perform worse than a data radio bearer with similar LTE QoS characteristics whose data traffic is exclusively transmitted using LTE air interface. The principles of the LTE QoS framework remain applicable for EPS bearers offloaded to WLAN when WLAN is aggregated with LTE at radio layer. When the WT node is added through Xw interface based on the procedures specified for DC functionality in Release-12 of 3GPP, the added WT node does not understand the LTE QoS parameters associated with the offloaded EPS bearer. To have seamless aggregation between LTE and WLAN radio resources for a particular UE the method 200 defines the mapping rules which translate the LTE QoS attributes to the WLAN QoS attributes such that data packets when scheduled over the WLAN air-interface experience similar QoS handling when scheduled over LTE air-interface. Since LTE node is responsible for mobility management and handles control plane signaling towards the UE, the mapping methods/rules need to be defined such that LTE node can control or handle QoS offered by the WLAN access per EPS bearer.
[0053] The LTE QoS parameters include QoS Class Identifier (QCI), Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR), Maximum Bit Rate (MBR), Access point name (APN)-Aggregate maximum bit rate (AMBR) APN-AMBR, UE-AMBR. It is mandatory that every EPS bearer must have QCI and ARP defined. The QCI is particularly important because it serves as reference in determining QoS in terms of priority level for each EPS bearer. In LTE Allocation and Retention Priority (ARP) is basically used for deciding whether new bearer modification or establishment request is to be accepted considering the current resource situation. In the dual connectivity context the ARP associated with EPS bearer may be used for admission control to decide whether to accept or drop the bearer. The ARP is therefore an important QoS attribute used to accept/modify/drop bearers in case of resource limitation. In case of bandwidth (bit rate), GBR and MBR are defined only for GBR type EPS bearers, whereas AMBR (APN-AMBR and UE-AMBR) is defined only in Non-GBR type EPS bearers.
[0054] The WLAN QoS can be based on IEEE 802.11 specification. Two types of QoS are defined namely, prioritized QoS and parameterized QoS. Prioritized QoS is a weak requirement that enforces relative priority between traffic streams. Parameterized QoS express quantitatively the QoS parameters hence enforcing strict requirement. The IEEE 802.11 defines the hybrid coordination function (HCF) which provides two methods of channel access, namely, the HCF Controlled Channel Access (HCCA) for contention free access and Enhanced Distributed Channel Access (EDCA) for contention based access. The EDCA mechanism defines four access categories (ACs) namely AC_VO (Voice), AC_VI (Video), AC_BE (Best Effort) and AC_BK (Background) that provide support for the delivery of traffic streams with prioritized QoS. The access category or access class (AC) is a marking for traffic stream comprising medium access control (MAC) service data units (MSDUs) that have a distinct user priority (UP) associated with the traffic stream. The QoS functionality in IEEE 802.11 specification supports eight user priority values. The UP may take integer values from 0 to 7 and are identical to the IEEE 802.1D priority tags. WLAN AP that supports prioritized QoS functionality based on an Enhanced Distributed Channel Access (EDCA) within the MAC understands the meaning of access category and user priority associated with MSDU. If the LTE PDCP PDU transported on Xw at least with certain QCI and ARP associated with data radio bearer is mapped to access category and user priority then the WLAN MAC entity can determine the prioritized QoS for MSDUs (for example, PDCP PDUs). Therefore LTE QoS characteristic is required to be visible to the WLAN MAC by translating to WLAN QoS characteristic so that WLAN MAC can perform the access category/access class classification according to IEEE 802.11 specification to support prioritized QoS. Thus, the mapping of LTE QoS to the WLAN QoS is performed at step 204
[0055] The various actions in method 200 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 2 may be omitted.
[0056] FIG. 3 illustrates end to end protocol architecture to support the LTE RAT and the WLAN RAT aggregation at radio layer using layer 2 transport for both collocated scenario and non-collocated scenario, as disclosed in the embodiments herein. The protocol stack in E-UTRAN (LTE node 102) depicts the protocol stack for S1-U interface 306 between LTE node (LTE eNB) 102 and serving gateway (SGW) 308 and the protocol stack for Xw interface 304 between LTE node (LTE eNB) 102 and WLAN AP 106a. For the collocated scenario the protocol stack comprises only the PDCP layer whereas for the non-collocated scenario, it is assumed that PDCP PDU is delivered over GTP-U tunnel to the WLAN AP 106a. Therefore the protocol stack PDCP entity in the EUTRAN (LTE node 102) and WLAN AP 106a carries the user plane packet (data packet), i.e. the PDCP PDU. The Xw interface 304 which is terminated at the WLAN AP 106a is used for exchanging the control plane signaling and for the transport of user plane data packet from the LTE node 102 using GTP-U tunnel. Regardless of whether the Xw is directly terminated in WLAN AP 106a or WLAN AG 108 the user plane packet (data packet) on the Xw 304 looks same as shown in FIGS. 4a and 4b.
[0057] FIGs. 4a and 4b illustrate user plane packet (data packet) structure for Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs) offloaded to the WLAN using layer 2 transport, as disclosed in the embodiments herein. When the EPC packet on the S1-U interface 306 lands in EUTRAN (LTE node 102) from the SGW 308 it contains a GTP header, an IP header and data payload. Since S1-U interface 306 terminates at the LTE node 102, the LTE node 102 removes the GTP header and adds a PDCP header 402 or PDCP header 406 for transmitting the data packet towards UE 104a. This is depicted as EUTRAN PDCP packet in FIGS. 4a and 4b, where if it is decided to offload the EUTRAN PDCP packet on Xw interface 304 then some modifications to the PDCP header may be needed. Such modification to PDCP header is needed to differentiate the EPS bearers of the UE 104a depending on the number of bearers offloaded towards WLAN AP 106a for that particular UE. The GTP-U tunnel for transporting the PDCP PDUs from LTE node 102 towards WLAN AP 106a for a particular UE is created per EPS bearer. The PDCP entity depicted in EUTRAN (LTE node 102) and UE 104a and the GTP entity depicted in EUTRAN (LTE node 102) and WLAN AP 106a (refer FIG. 3) is created per EPS bearer. The one-to-one mapping between the EPS bearer and the data radio bearer (DRB) is maintained. In order to differentiate the PDCP PDUs belonging to different offloaded data radio bearers at the UE side. The PDCP header 402 or PDCP header 406 is extended to include the bearer identity or data radio bearer identity (DRB ID) or logical channel identity (LCID) of that EPS bearer. As shown in FIGS. 4a and 4b the PDCP header 402 or PDCP header 406 can include the PDCP sequence number (SN) of the PDCP PDU and the bearer ID/DRB ID/LCID associated with the EPS bearer indicating which PDCP entity is responsible to process the PDCP PDU. When the PDCP PDU is transported on Xw interface 304 through the GTP-U tunnel established for that EPS bearer of a particular UE the PDCP PDU is appended with GTP-U header. This is depicted as “Packet on Xw” in FIGS. 4a and 4b regardless of Xw interface 304 terminates in WLAN AG 108 or WLAN AP 106a.
[0058] Since the Xw interface 304 terminates in WT/WLAN AP further user plane processing involves appending the WLAN MAC header 404 to the PDCP PDU as shown in FIG. 4a to form the WLAN MAC SDU. This is depicted as WLAN AP MAC Packet in FIG. 4a where the Xw interface 304 terminates in WLAN AP 106a. The MAC SDU containing the WLAN MAC header 404 comprises the UE MAC address as the destination address and WLAN AP 106a MAC address as source address. Since the GTP-U tunnel between the LTE node 102 and WT node is maintained per bearer per UE the QoS characteristics of the GTP-U tunnel can be associated with the LTE QoS characteristics of the EPS bearer. However, the WT node (WLAN AP 106a) cannot understand the LTE QoS characteristics of the GTP-U tunnel and therefore translation of the LTE QoS characteristics to WLAN QoS characteristics is needed. This is possible by either maintaining a mapping table at the LTE node 102 or at the WT node (WLAN AP 106a or WLAN AG 108) which translates the LTE QCI and priority level attributes to WLAN QoS parameters and user priority attributes. So, when the PDCP PDUs of a particular GTP-U tunnel of a particular UE is delivered to WLAN MAC then the PDCP PDU is buffered (queued) in appropriate AC queue associated with the WLAN QoS parameters and user priority such that the AC queue is maintained per UE. If the Xw interface 304 terminates in WT node (WLAN AG 108) then depending on the local interface between the WLAN AG 108 and WLAN AP 106a an appropriate header 408 (i.e. WLAN QoS header) is appended to the PDCP PDU as shown in FIG. 4b. This is depicted as packet on WT-AP interface in FIG. 4b. On the local interface between the WLAN AG 108 and WLAN AP 106a it may not be possible to maintain the bearer/tunnel concept because layer 2 transport is used to forward the PDCP PDUs of one or more bearers of one or more UEs from the WLAN AG 108 to the WLAN AP 106a. In order to maintain LTE QoS characteristics of the GTP-U tunnel on Xw interface 304 for the data packets it is transporting there is need that each PDCP PDU carries QoS marking associated with QoS characteristic of that particular bearer/GTP-U tunnel when transported on the local interface between WLAN AG 108 and WLAN AP 106a. For example, if the local interface between the WLAN AG 108 and the WLAN AP 106a is Ethernet then an Ethernet header (header 408 or WLAN QoS header) is appended to the PDCP PDU such that the Ethernet header 408 which can at least include a destination address in the form of UE WLAN MAC address to identify a particular UE and QoS marking field associated with QoS characteristic of that particular bearer/GTP-U tunnel as shown in the FIG. 4b. For example, such QoS marking in header 408 which is added to the PDCP PDU may be similar to QoS marking which is used in 802.1Q header. The 802.1Q header contains the 3 bit Priority Code Point (PCP) field which can be used for such QoS marking. Depending on the local interface appropriate header (which is the WLAN QoS header) 408 containing the UE WLAN MAC address to identify a particular UE and QoS marking field can be appended to the PDCP PDU for maintaining the QoS characteristics associated with the offloaded bearer. This process of adding the header that includes the QoS marking when the PDCP PDU is transported on the local interface between WLAN AG 108 and WLAN AP 106a can be referred as per packet marking. Since the local interface terminates in WLAN AP 106a further user plane processing involves appending the WLAN MAC header 410 to the PDCP PDU as shown in FIG. 4b to form the WLAN MAC SDU. This is depicted as WLAN AP MAC Packet in FIG. 4b where the local interface terminates in WLAN AP 106a.
[0059] FIG. 5 illustrates a sequence diagram depicting steps for addition of the WT node conforming to dual connectivity (DC) framework, as disclosed in the embodiments herein. In FIG. 5 for the offloaded DRBs, the mapping of LTE Quality of Service (QoS) parameters to WLAN QoS parameters is performed at the WT node, During the WT node (WLAN AP 106a or WLAN AG 108) addition procedure, there is a preparation phase between LTE node (LTE eNB) 102 and the WT node (WLAN AP 106a or WLAN AG 108) in which the WT node (WLAN AP 106a or WLAN AG 108) is informed about at least one new UE (here UE 104a) arriving in the near future (identified by UE WLAN MAC address) and establishing the GTP-U tunnel between LTE node 102 and WT node (WLAN AP 106a or WLAN AG 108) using control signaling on the Xw interface 304.
[0060] Further, the LTE node 102 can be configured to receive (502) UE capability information shared by the UE 104a indicating support of LTE RAT-WLAN RAT radio layer aggregation during initial setup or during attach procedure or as requested by the LTE node 102. The LTE node 102 can be configured to receive (504) the UE WLAN MAC address shared by the UE 104a through WLAN status indication or any other RRC message. The LTE node 102 may need the UE WLAN MAC address for authentication with WLAN. Based on load or signal condition LTE node 102 may configure the UE 104a with WLAN measurements through RRC connection reconfiguration message (506) which includes the WLAN channels to be scanned. The LTE node 102 may also share the list of WLAN AP and reporting criteria which can be used by the UE 104a to use as trigger condition. Further, the UE 104a can be configured to start scanning for WLAN carriers according to the WLAN measurement configuration. Once, the UE 104a detects the event as configured by LTE node 102, the LTE node 102 can be configured to receive (508) measurement report from the UE 104a with the list of WLAN APs detected along with signal strength associated with each detected WLAN AP. On receiving the measurement report from the UE 104a the LTE node 102 can be configured to evaluate the measurement report and decide to add WT node (here say WLAN AP 106a) reported by UE 104a. The LTE QoS parameters associated with DRB which is intended to be offloaded to WLAN AP 106a includes at least the QCI value of the bearer, Allocation and Retention Priority (ARP) of the bearer, some GBR QoS parameters like Packet delay Budget, Packet error Rate and so on. Further, the LTE node 102 can be configured to evaluate the measurement report and decide to add (510) the WLAN AP 106a reported by UE 104a.
[0061] Once decided to add the WLAN AP 106a, the LTE node 102 (also called a Master eNB) can be configured to initiate the procedure to add WT node (here, WLAN AP 106a) and send (512) an ADDITION REQUEST message to the WT node (here WLAN AP 106a) over Xw interface 304. The WLAN AP ADDITION REQUEST message includes at least a list of bearer IDs, also referred as DRB ID or E-RABs, the UE WLAN MAC address and the list of detected APs which are expected to be in vicinity of UE. As depicted in FIG. 5 in addition to list of bearer ID (E-RABs) the WLAN AP ADDITION REQUEST message includes the LTE QoS parameters associated with data radio bearer (E-RAB). In FIG. 5 in addition to list of bearer ID (i.e. E-RABs), which are the DRBs to be offloaded, the WLAN AP ADDITION REQUEST message includes the LTE QoS parameters associated with the DRBs. When the LTE node 102 sends the WLAN AP ADDITION REQUEST message, the LTE node 102 can be configured to start a timer TDCprep and if the WT node (here WLAN AP 106a or else can also be WLAN AG 108) is not able to respond within the specified time set by the timer, the LTE node 102 may consider the WT node addition procedure as unsuccessful.
[0062] Further, the WT node (WLAN AP 106a) can be configured to receive (512) the WLAN AP ADDITION REQUEST message comprising the list of DRB ID (i.e. E-RABs) and the associated LTE QoS parameters like QCI and ARP. The WT node (WLAN AP 106a or WLAN 108) can be configured to translate or map (514) the received LTE QoS parameters to WLAN QoS parameters using a mapping table derived as per one of the mapping methods proposed and described in conjunction with FIG. 6. The WT node (WLAN AP 106a or WLAN 108) performs the mapping of the LTE QoS parameters to the WLAN QoS parameters by translating parameters like QCI and priority level to the access category and user priority which is understood by WLAN MAC for packet scheduling for each data packet transported by the offloaded E-RAB. Pluralities of embodiments for mapping the LTE QoS parameters to the WLAN QoS parameters are described in conjunction with FIG. 6.
[0063] The WT node (WLAN AP 106a or WLAN AG 108) can be further configured to map the LTE QoS parameters associated with a particular bearer like packet delay budget and packet error rate to derive WLAN parameterized QoS such CWmin, CWmax, TxOP, AIFS to ensure that QoS requirements can be met. Once the WT node accepts the ADDITION REQUEST, the WT node (WLAN AP 106 or WLAN AG 108) can be configured to send (516) ADDITION REQUEST ACKNOWLEDGE (ACK) message to the LTE node 102 and include the result for all requested offloaded bearer IDs such as E-RABs in the following way:
[0064] A list of bearer IDs (i.e. E-RABs) which are successfully established is included in the E-RABs Admitted List Information Element (IE).
[0065] WLAN QoS parameters associated with list of bearer IDs (i.e. E-RABs) in the E-RAB Admitted List IE if the successfully established E-RABs correspond to UL DRBs.
[0066] A list of bearer IDs (i.e. E-RABs) which failed to be established is included in the E-RABs Not Admitted List IE.
[0067] WLAN AP cell identity (i.e. SSID or BSSID) and GTP tunnel end-point ID (i.e. TEID)
[0068] The WT node may decide not to admit one or more bearer (DRBs) from the list of E-RABs received in the WLAN AP ADDITION REQUEST message based on the ARP value associated with the E-RAB. Such E-RABs which are not admitted by the WT/WLAN AP are included in the E-RABs Not Admitted List IE.
[0069] The WT node can be configured to also send WLAN ADDITION REQUEST reject in case it determines it may not able to meet QoS requirements for a particular UE due to load situation. However, if the WT node receives the WLAN AP ADDITION REQUEST message containing LTE QoS parameters which contains a QCI IE associated with bearer indicating that the bearer is a GBR bearer and which does not contain the GBR QoS Information IE, then WT node considers the establishment of the corresponding bearer ID (E-RAB) as failed.
[0070] However, on receiving ADDITION REQUEST ACK from the WT node the LTE node 102 can be configured to configure the UE 104a with WLAN resources by sending (518) RRC reconfiguration message by adding the identity of WT node. The RRC message (518) sent to the UE 104a may also include the WLAN QoS parameters associated with the offloaded DRB if the DRB is UL DRB. In response, the LTE node 102 can be configured to receive (520) a RRC connection reconfiguration complete message from the UE 104a after the UE 104a applies the WLAN configuration. Further, the WT node can be configured to receive communication from the UE 104a to perform (522) the association procedure as indicated in the WLAN configuration.
[0071] FIG. 6 illustrates a sequence diagram depicting steps for addition of the WT node to offload the DRBs, with mapping of LTE Quality of Service (QoS) parameters of the offloaded DRB to WLAN QoS parameters performed at the LTE node, as disclosed in the embodiments herein. All the steps in FIG. 5 and FIG. 6 are same except step 510 and step 610, where the LTE node 102 can be configured to decide to add the WT node (WLAN AP 106a or WLAN AG 108) and in addition configured to map the LTE QoS parameters to WLAN QoS parameters at the LTE node (102) itself. The LTE node 102 performs the mapping of LTE QoS parameters to WLAN QoS parameters by translating parameters like QCI and priority level to the access category and user priority which is understood by WLAN MAC for packet scheduling for each data packet transported by the offloaded E-RAB. Thus the step 514 performed by the WT node of the FIG. 5 is not required to be performed by the WT node of FIG. 6 as the mapped WLAN QoS parameters are sent to the WT node by the LTE node 102 in the WLAN ADDITION REQUEST at step 612. The steps that are similar in FIG. 5 and FIG.6 are not repeated for brevity. The RRC message (616) sent to the UE 104a may also include the WLAN QoS parameters associated with the offloaded DRB if the DRB is UL DRB.
[0072] The description below provides plurality of embodiments for mapping embodiments or translating the LTE QoS parameter to the WLAN QoS parameters for the offloaded DRB to enable maintaining QoS associated with the DRB when data packets are scheduled through the WLAN RAT. Any one of the embodiments for mapping may be used by method 200 depicted in FIG 2 and performed at step 514 depicted in FIG. 5 or step 610 depicted in FIG. 6.
[0073] In an embodiment, a mapping method 1 maps the LTE QCI to the WLAN AC category based on prioritized QoS. The mapping between the LTE QCI and the WLAN AC category can be done based on a priority level. For example, a LTE QCI 5 having highest priority level of 1 is mapped to WLAN AC_VO having highest user priority 7 (i.e. UP 7). LTE QCI 1 having priority level 2 is mapped to WLAN AC_VO having user priority 6 (i.e. UP 6). An example mapping of the LTE QCI to WLAN AC based on priority level is shown below in table 1 and can be implemented either at the LTE node 102 or WT node (WLAN AP 106a or WLAN AG 108). The actual mapping table between LTE QCI and WLAN AC can be based on wireless network operator policy. EPS bearers associated with QCI 65,66,69,70 may or may not be offloaded to WLAN depending on operator policy as these bearers are related to Mission Critical services.
Table1:
[0074] In yet another embodiment, a mapping method 2 maps the LTE QCI and the WLAN AC based on type of service. The LTE QCI to WLAN AC mapping can be performed based on type of service. For example conversational voice can be mapped to WLAN access class (AC) which is supporting voice, such as mapping QCI 1 to AC_V0. Similar kind of mapping can be performed for other services like video, background and video. The LTE priority level associated with the QCI is mapped as per current user priority (UP) associated with AC in WLAN for all these services. Few services like IMS signaling, Mission critical PTT services etc. may be mapped to any of the AC and UP based on wireless network operator policy. An example mapping table of the LTE QCI to WLAN AC based on type of service is shown below in table 2. Rules for the mapping can be as provided below:
1. QCI 1, 2 used for conversational can be mapped to WLAN AC_V0 and UP can be 6
2. QCI 3, 4 used for streaming can be mapped to WLAN AC_V1 and UP can be 4/5. QCI 5 used for signaling can be mapped to WLAN AC_V0 with designation of NC (Network controlled) and UP can be 7. Alternatively it can be mapped to AC_BE or AC_BK or AC_V1 and set the priority accordingly
3. QCI 6, 7, 8 used for interactive traffic can be mapped to AC_BE and UP can be 3/0
4. QCI 9 used for background can be mapped to AC_BK and UP can be 2/1
5. QCI 65, 66 used for push to talk voice data can be mapped to AC_V0 with UP 6
6. QCI 69, 70 used for push to talk signaling data can be mapped to AC_V0 with UP 7/6 or AC_BE or AC_BK with UP 0/1/2/3

TABLE 2:


[0075] In yet another embodiment, a mapping method 3 maps the LTE QCI and WLAN AC for only GBR type bearers. In practical deployments where the wireless operator network supports LTE RAT and WLAN RAT aggregation at radio layer it is possible only GBR type of bearer is offloaded to WLAN. An EPS bearer with resource type as GBR is associated with guaranteed bandwidth. Only a dedicated bearer can be a GBR type. Default EPS bearer cannot be GBR type. Typically the QCI of GBR type bearer can range from 1 to 4. Therefore there is no need to do mapping of each and every LTE QCI to WLAN AC. The mapping is only applicable for bearers having QCI associated with GBR type. An example mapping table of the LTE QCI to WLAN AC based on GBR type is shown below in table 3. For example QCI 2 can be used for voice or video. The same can be the case for WLAN access classes.

Table 3:

[0076] In yet another embodiment, a mapping method 4 maps the LTE QCI and WLAN AC for only Non-GBR type of bearer. An EPS bearer with resource type as non-GBR is associated with non- guaranteed bandwidth. This means the non-GBR bearer type is a best effort type bearer. A default EPS bearer is always a Non-GBR type, whereas a dedicated EPS bearer can be either GBR type or non-GBR type. Typically the QCI of a non-GBR bearer type can range from 5 to 9. In this proposed method for mapping, the LTE QCI to WLAN AC mapping is only applicable for QCI which are associated with non-GBR bearer type. The WLAN AC and user priority can be mapped based on LTE priority level and associated service type. An example mapping table of the LTE QCI to WLAN AC based on non-GBR type is shown below in table 4.

Table 4:

[0077] In yet another embodiment a mapping method 5 dynamically maps the LTE QCI and the WLAN AC: This mapping is dynamic and it may keep changing based on load and other factors like radio conditions and so on experienced at WT node (WLAN AG/WLAN AP). The LTE eNB or any other entity of the wireless communication system 100 can maintain this mapping table and keep updating the same based on the LTE eNB and WLAN negotiation on Xw interface. It may work as mentioned below:
1. The LTE eNB decides to add the WLAN AP and for an offloaded bearer it determines the AC and UP based any of mapping methods 1 to 4 described above. Further the LTE eNB make a suggestion to WT node (WLAN AG/WLAN AP) over the Xw interface.
2. WT node (WLAN AG/WLAN AP) can respond back with AC and priority that it can support for the LTE eNB suggestion. This is important in case multiple bearers are going to be offloaded to WLAN.
3. Based on such negotiation LTE eNB can maintain the QCI to WLAN AC mapping and can use it for future reference for the bearers it wants to offload to WLAN. Next time for same QCI and/or bearer type the LTE eNB can directly choose the WLAN AC and UP for negotiation over Xw interface with WT node (WLAN AG/WLAN AP).
4. WT node (WLAN AG/WLAN AP) continues informing the LTE eNB if it can support the same suggestion based on load and other factors like radio conditions etc.
[0078] In yet another embodiment, a mapping method 6 maps the LTE QoS parameter to the WLAN parameterized QoS. The EPS bearer is associated with QCI value such that each QCI is expressed in terms of priority level, packet delay budget and packet error loss rate. The HCCA functionality in IEEE 802.11 supports parameterized QoS such that it uses a centralized coordinator, called a hybrid coordinator (HC) which is collocated with the WLAN AP and uses the HC’s higher priority of access to the wireless medium to initiate frame exchange sequences and to allocate transmission opportunities (TxOPs) to the WLAP AP and WLAN UEs in order to provide limited-duration of contention-free transfer of data. It is possible to derive the setting of the values for parameterized WLAN QoS parameters like CWmin, CWmax, TxOp, AIFS from the corresponding QCI's Packet Delay Budget and Packet Error Loss Rate respectively. The WLAN while deciding the value of these parameters can consider the attributes of LTE QCI and accordingly set the parameterized WLAN QoS parameters for different traffic streams or service or within different access category to meet strict QoS requirements. The LTE ARP value may also be considered as optional attribute to derive parameterized WLAN QoS parameters. The setting of the values of all other WLAN QoS is based on operator policy.
[0079] In yet another embodiment, a mapping method 7 maps LTE QoS parameters to WLAN parameters by using the ARP attribute at the WLAN: There are 0-15 ARP priorities defined in LTE. When eNB is offloading any bearer or service to WLAN it needs to maintain the QoS associated with the bearer, so that WLAN can take any modification/drop decision later. The ARP attribute associated with the bearer may also be used by WLAN to decide the service modification or in simple terms whether to accept or reject the bearer when WT node (WLAN AG/WLAN AP) receives the WLAN AP ADDITION REQUEST message. The below guidelines may be applicable for the admission control at the WT/WLAN AP of the bearer:
1. When EPS bearer QoS parameters are mapped to WLAN QoS parameters the pre-emption capability and the pre-emption vulnerability information of the EPS bearer i.e. ARP attribute is not ignored by WT/WLAN AP even though ARP is not mapped to any WLAN QoS parameter.
2. The LTE eNB may translate the ARP values (0-15) associated with a bearer and provide to the WLAN in terms of H (high priority), M (medium priority) and L (lowest priority) which can be set according to operator requirements to ensure proper admission control of bearers. The minimum value of H is 1. The minimum value of M is H+1 and L is M+1. This admission control priority associated with the bearer should not be confused with the user priority (UP) of access class to which the bearer is mapped to.
[0080] In yet another embodiment, a mapping method 8 maps the LTE QCIs and WLAN Access class based on GBR and Non-GBR service. In this case GBR services can be mapped to WLAN Access class which supports voice and video. Non-GBR services can be mapped to Access class which supports background and best effort. The user priority range is mentioned and it can be decided by any NW entity say LTE or WLAN. The Access class can be reversed also where GBR can support background (BK) and (best effort) BE, while Non-GBR supports voice and Video.
[0081] FIG. 7a and FIG. 7b illustrate plurality of entities of the LTE node and the WLAN AP when interface between the LTE RAT and the WLAN RAT is terminated in the WLAN AP, as disclosed in the embodiments herein. For the LTE RAT and WLAN RAT aggregation at radio layer, the LTE node 102 can be configured to create GTP-U tunnel per UE per bearer according to Xw procedure described in FIG. 5 and FIG. 6 by exchanging control plane signaling with the WT node (WLAN AP 106a). During the creation of GTP-U tunnel for transporting the PDCP PDUs of the offloaded EPS bearer towards the WT node (WLAN AP 106a) the QoS characteristics of the GTP-U tunnel are determined. As described in FIG. 5 the GTP-U tunnel per UE per bearer is created according to LTE QoS parameters such as QCI, ARP and the like. An adapter entity 702 in WLAN AP 106a can be configured to perform the mapping of LTE QoS parameters to WLAN QoS parameters according to one of the mapping methods 1 to 8 described in conjunction with FIG. 6. Alternatively, if mapping is performed at the LTE node 102 then the GTP-U tunnel per UE per bearer is created according to WLAN QoS parameters such as AC, UP and the like. In FIG. 7a the LTE node 102 can be configured to perform the mapping of LTE QoS parameters to WLAN QoS parameters. In FIG. 7b the WLAN AP 106a can be configured to perform the mapping of LTE QoS parameters to WLAN QoS parameters. The adapter entity 702 is also responsible for handling the flow control such that not more than half of the PDCP sequence number (SN) space is brought in flight on the Xw interface 304 per GTP-U tunnel. Further, the adapter entity 702 can be configured to provide feedback to the LTE node 102 per GTP-U tunnel about the successful delivered PDCP PDUs and PDCP PDUs which are not delivered through the WLAN air-interface. If multiple bearers are offloaded to WLAN AP 106a then this results in multiple GTP-U tunnels on Xw interface 304 which is handled by a bearer management entity 708 within the adapter entity 702. The data packets (PDCP PDUs) transported on the respective GTP-U tunnels need to be buffered at the WLAN AP 106a according to WLAN QoS characteristics identified according to the WLAN AC and UP parameters associated with the bearer (GTP-U tunnel) after translation or mapping. A queue management entity 710 in the adapter entity 702 is responsible for delivering the data packets (PDCP PDUs) of a particular UE belonging to a particular bearer (GTP-U tunnel) to the respective AC queues 704 created per UE according to the WLAN AC and UP parameters associated with the bearer. The AC queues 704 in the WLAN AP 106a are per UE, therefore the respective AC queues may comprise data packets of different bearers (DRBs) of the same UE having the same WLAN QoS parameters. Even though the PDCP PDUs of different bearers having same WLAN QoS parameters associated with a particular UE are buffered in same AC queue, the bearer ID/DRB ID/LCID field in the PDCP header differentiates the PDCP PDUs. A WLAN MAC entity 706 may be configured to use the bearer ID/DRB ID/LCID field in the PDCP header while maintaining the mapping between PDCP SN and MAC sequence numbers (SN) of the (MSDUs). In an embodiment, the WLAN MAC entity tags the mapping between PDCP SN and MAC SN with DRB-ID or E-RAB or LCID. Tagging the mapping between PDCP SN and MAC SN with bearer ID/DRB ID/E-RAB/LCID is needed to provide feedback to the LTE node 102 per GTP-U tunnel about the successful and unsuccessful delivered PDCP PDUs.
[0082] The adapter entity 702, the bearer management entity 708 and the queue management entity 710 are logical entities. Therefore, these entities and their functionalities may either be implemented in WT node (WLAN AP 106) in distributed or centralized manner. The LTE QoS to WLAN QoS mapping function, if present in the WLAN AP 106a, may either be implemented in the adapter entity 702 or the bearer management entity 708.
[0083] GTP-U tunnel per bearer per UE is needed for layer 2 aggregation of LTE RAT and WLAN RAT which is depicted in the FIG. 7b. In this case, LTE node 102 can be configured to create a tunnel with the WLAN AP 106a for a DRB of the UE. There is one-to-one mapping of the DRB and the GTP-U tunnel. The DRB and the tunnel of a UE, is mapped using the DRB ID and the tunnel endpoint ID (TEID) of the E-RAB, so that every DRB (E-RAB) is uniquely mapped to the GTP-U tunnel. In this scenario, the LTE QoS (QCI) or the WLAN QoS (AC) of the DRB is mapped to a Tunneling Endpoint Identifier (TEID), so that WLAN AP 106a can either directly use the AC of the TEID or use the mapping table to identify the AC of the particular TEID. The TEID values and the corresponding LTE QoS/WLAN QoS information can be exchanged between LTE node 102 and WLAN AP 106a using control plane messaging (Xw-AP) when creating the tunnel as depicted in FIG. 5 and FIG. 6.
[0084] The FIG. 7b depicts the adapter entity 702, the bearer management entity 708 and the queue management entity 710 implemented at the WLAN AP 106a. The bearer management entity 708 can be configured to take care of maintaining the mapping of Xw-U sequence number or GTP-U sequence number and PDCP Sequence number per bearer for flow control. The WLAN MAC entity 706 exchanges information about the successful or unsuccessful delivery of MSDU (i.e. PDCP PDUs) with the bearer management entity 708 per DRB-ID (i.e. E-RAB) based on tagging information. The bearer management entity 708 can therefore generate the flow control feedback on GTP-U SN basis for each GTP-U packet transported by that particular GTP-U tunnel. The queue management entity 710 can be configured to take care of mapping of PDCP PDU of each bearer of a particular UE to the appropriate WLAN access class queue 704 of that UE based on the AC associated with the TEID of the GTP-U tunnel.
[0085] FIG. 8a and FIG. 8b illustrate plurality of entities of the WLAN AG and the WLAN AP when interface between the LTE RAT and the WLAN RAT is terminated in the WLAN AG, as disclosed in the embodiments herein. As depicted, the Xw interface 304 is terminated in the WT node (WLAN AG 108) which is connected to one or more WLAN APs such as WLAN AP 106a through a local interface 802 such as the Ethernet. A bearer management entity 808 is responsible for forwarding the PDCP PDUs received on the GTP-U towards the respective WLAN AP 106a on the local interface 802. As depicted in FIG. 8a and FIG 8b, the LTE node 102 can be configured to create multiple GTP-U tunnels according to WLAN QoS parameters on the Xw interface 304 for one or more UEs. The GTP-U tunnel per UE per bearer having unique TEID is marked with the WLAN QoS parameters so the adapter entity 806 or bearer management entity 808 is aware about the manner in which delivery of the PDCP PDUs of each GTP-U tunnel to the respective AC queues per UE in the WLAN AP 106a is to be performed. Alternatively, the LTE node 102 can be configured to create multiple GTP-U tunnels according to LTE QoS parameters on the Xw interface 304 for one or more UEs. However for simplicity this scenario is not depicted explicitly in which case the adaptor entity 806 can be configured to map the LTE QoS parameters to WLAN QoS parameters according to one of the mapping methods disclosed in conjunction with FIG. 6.
[0086] Further, even though the GTP-U tunnel is created per UE per bearer such that its TEID is marked with appropriate LTE QoS parameters or the WLAN QoS parameters, it may not be possible to maintain the bearer concept on the local interface 802 between the WLAN AG 108 and WLAN AP 106a. The reason being layer 2 transport like Ethernet may be used to forward the data packets (PDCP PDUs) of one or more bearers (GTP-U tunnels) associated with one or more UEs from the WLAN AG 108 to the WLAN AP 106a. In order to maintain QoS characteristics of the bearer (GTP-U tunnel) for the data packets (PDCP PDUs) being transported on the GTU-tunnel, each PDCP PDU may be required to carry WLAN QoS marking associated with QoS characteristic of that particular bearer/GTP-U tunnel when it lands in the WLAN AP 106a via the local interface 802. For example, as depicted in FIG. 8b if the local interface 802 is the Ethernet then the Ethernet header (i.e. WLAN QoS header) 814, is appended to the PDCP PDU. The Ethernet header (i.e. WLAN QoS header) 814 may include at least a destination address in the form of UE WLAN MAC address and a field for WLAN QoS marking associated with QoS characteristic of that particular bearer/GTP-U tunnel. In one example the QoS marking in the Ethernet frame is feasible by using the IEEE 802.1Q tag which adds a 32-bit field between the source MAC address and the EtherType/length fields of the Ethernet frame header. Out of the 32-bit field the Priority code point (PCP) is a 3-bit field which can be used for QoS marking to indicate the priority level of the payload carried in the Ethernet frame. When WLAN AP 106a receives the Ethernet frame then the PCP field of the IEEE 802.1Q tag can be used for the AC classification to queue the packets in appropriate AC queues 804. As shown in FIG. 8b the queue management entity 810 at the WLAN AP 106a can be configured to handle the mapping of the Ethernet frames to the appropriate AC queues 804 for a particular UE. The bearer management entity 808 or the adapter entity 806 is responsible for adding such header 814 in front of the PDCP header before forwarding the packet (PDCP PDU) on the local interface 802.
[0087] LTE QCI to QoS field marking mapping: If the QoS field marking is based on PCP or other fields like class of service (CoS) or type of service (ToS) then the priority level of the QCI associated with the GTP-U tunnel can be mapped to the priority level indicated by the PCP/CoS/ToS field. Such mapping can be similar to prioritized QoS described previously in Table 1. The LTE node 102 configures EPS bearer on Xw interface 304 with specific QCI value which has an associated priority level. In this case the WT node (WLAN AG 108) is configured to maintain the mapping between QCI value and the QoS marking field like the PCP in the Ethernet header or CoS/ToS in some other headers 814 added in front of the PDCP header of each PDCP PDU.
[0088] WLAN Access Class to QoS field marking mapping: If LTE node 102 configures EPS bearer on Xw interface 304 with specific WLAN AC which has an associated user priority level, then in this case WT node (WLAN AG 108) can be configured to directly map the UP associated with WLAN AC category with the QoS marking field like the PCP/CoS/ToS. The WT node can be configured to add the QoS marking field to the header 814 of Ethernet frame comprising one or more packets (PDCP PDUs) as payload which is then forwarded on the local interface 802 between WLAN AG 108 and appropriate WLAN AP 106a. FIG. 8b depicts the LTE RAT and WLAN RAT aggregation functionality where the bearer management entity 808 at WT node (WLAN AG 108) and the queue management entity 810 at the WLAN AP 106a, which are responsible for maintaining the QoS characteristics on the local interface 802. The queue management entity 810 is configured to deliver the PDCP PDUs received on the local interface 802 to the appropriate AC queues 804 of that particular UE. The bearer management entity 808 at WLAN AG 108 which handles the PDCP packet for QoS marking may also be configured to maintain the mapping of GTP-U SN or PDCP sequence number (SN) to WLAN MAC SN per radio bearer or per GTP-U tunnel. The queue management entity 810 is configured to determine the AC queue and User priority (UP) from the provided QoS marking field such as PCP/ToS/CoS in the header 814 of the packet transported on the local interface 802.
[0089] In LTE, the QCI is associated per EPS bearer (i.e. per DRB ID). LTE MAC header carries LCID in each user plane packet i.e. LTE MAC PDU. One to one mapping of LCID and DRB ID (implies one QCI value per LCID). In WLAN, WLAN QoS parameters are associated with Access Class (AC) categories for prioritized QoS. The LTE node 102 configures QCI value for the LCID/ DRB ID. The LCID/DRB ID is carried in the PDCP header of the data packet from LTE node 102 transmitter entity (PDCP) to the WLAN MAC entity 812 and from the WLAN MAC entity 812 to the reception entity (PDCP) of the UE 104a. Since the LTE MAC entity is not involved in the transmission reception path of the PDCP PDU transported via the WT node, the DRB ID is preferred in the PDCP header instead of the LCID. Based on LCID/DRB ID in every packet (PDCP PDU), the TEID marked with the UE WLAN MAC identity and the QoS marking in the header 814 the queue management entity 810 can be configured to map the PDCP PDU to particular AC queue 804 of that UE to enforce uniform QoS for packets transmitted through WLAN air interface.
[0090] Plurality of embodiments providing flow control mechanism for the LTE RAT and the WLAN RAT aggregation are provided. The architecture for LTE–WLAN Aggregation at radio layer is based on Dual Connectivity framework. The interface between LTE node and the WT node WLAN node is the standardized Xw interface described here. The flow control mechanism between these two nodes can be based on GTP-U, which is used for Xw User Plane (Xw-UP) protocol. In Release-12 dual connectivity X2 UP protocol layer is using services of the transport network layer in order to allow flow control of user data packets transferred over the X2 interface between master eNB (MeNB or LTE node 102) and secondary eNB (SeNB). The data management, feedback mechanism and the like in both the MeNB and the SeNB is same as both nodes are based on LTE user protocol relying on the feedback from RLC layer for flow control. However, this is not the case with flow control handling for LTE-WLAN aggregation because the user plane protocol in MeNB is based on LTE while the user plane protocol in SeNB is based on WLAN. Even though it is not possible to reuse the same concept of flow control as defined for X2 UP protocol layer it is possible to introduce new flow control mechanism for user data packets transferred over the Xw-UP interface between LTE eNB and WLAN AP.
[0091] In an embodiment, a flow control method is based on mapping of PDCP SN and WLAN MAC SN for flow control between LTE node and the WT node wherein the feedback status is provided by the WT node.
[0092] In another embodiment, a flow control method is based on mapping of GTP-U SN and WLAN MAC SN for flow control between LTE node and the WT node wherein the feedback status is provide by the WT node.
[0093] In yet another embodiment, a flow control method is based on mapping of PDCP SN and WLAN MAC SN for flow control between LTE node and the WT node wherein the feedback status is provide by the UE.
[0094] The LTE node 102 and the WLAN AP 106a or WLAN AG 108 work on different type of user plane protocol, so one to one mapping between PDCP SN and WLAN MAC SN is not possible. To maintain the flow control between two nodes for user data packets transferred over the Xw-UP interface it is important for LTE node 102 to be aware of status of each PDCP PDU and the amount of PDCP PDUs to be brought in flight on Xw-UP. To support the same there is need to introduce new mechanism between WT node (/WLAN AP 106a/WLAN AG 108) and LTE node 102 which can determine the mapping between PDCP sequence number of PDCP PDU and MAC SN of WLAN MAC PDU. Thus, whenever the WLAN MAC PDU is successfully delivered to the UE some entity at the WT node (/WLAN AP 106a /WLAN AG 108) can mark that PDCP packet as successful and share the status with LTE node 102. The various possible approaches with which the WT node can provide the feedback to the LTE node are mentioned below in the present invention. The below mentioned approaches are applicable regardless of Xw is terminated in WLAN AP 106a or Xw is terminated at WT node (WLAN AC or WLAN AG 108).
[0095] Approach 1: Create a local reference number (LRN) for each PDCP PDU and share with WT/WLAN AP
[0096] In this case when PDCP packet is received by WT node (WLAN AP 106a or WLAN AG 108) on a particular bearer associated with the UE 104a, the adapter entity creates a local reference number (LRN) for each received PDCP packet per UE per bearer. This LRN can be shared with the WLAN MAC when the received PDCP PDU is delivered to the appropriate access class queue. The LRN can be used to determine the mapping between PDCP SN and WLAN MAC SN at the WLAN MAC. When WLAN MAC assigns MAC SN to each MAC PDU (M-PDU), it determines the LRN associated with that packet and maintains mapping between LRN and MAC SN. The mapping entity in WLAN MAC may report the determined mapping to the adapter entity in WT node (WLAN AP 106a or WLAN AG 108) for each PDCP PDU. On receiving the same the adapter entity at WT node (WLAN AP 106a or WLAN AG 108) can maintain the PDCP SN to MAC SN mapping based on information provided for each LRN. Adapter entity in WT can later mark the PDCP packet as successful or not successful based on status provided by WLAN MAC for the MAC SN. Alternatively WLAN MAC itself maintains the mapping between LRN and MAC SN and based on the feedback received from the UE the WLAN MAC informs the status of each LRN to the adapter entity in WT node (WLAN AP 106a or WLAN AG 108). On receiving the same adapter entity at WT node (WLAN AP 106a or WLAN AG 108) can mark the PDCP PDU as successfully delivered or not successful. The adapter entity also maintains a mapping between the LRN and GTP-U SN. The adapter entity then uses the status of the LRN reported by the WLAN MAC for flow control on the Xw-UP per bearer per UE providing the feedback for each GTP-U SN received from the LTE node.
[0097] Approach 2: WLAN MAC maintains the PDCP SN of each packet to create a mapping between PDCP SN and WLAN MAC SN
[0098] In this case when PDCP packet is received by WT node (WLAN AP 106a or WLAN AG 108) on a particular bearer (GTP-U tunnel) associated with the UE 104a, the adapter entity delivers the PDCP PDU to appropriate access class queue of that UE based on the QoS marking where the packet is treated as M-SDU. Since the PDCP header is not encrypted it is possible for the mapping entity in the WLAN MAC to determine the PDCP SN and DRB ID/LCID/E-RAB of the received packet. The mapping entity in WLAN MAC determines the PDCP SN and DRB ID for each packet and stores it in a local database and while processing each packet, while forming a MAC PDU (M-PDU) by assigning MAC SN, for each packet the mapping entity determines the mapping between PDCP SN and WLAN MAC SN per bearer based on the DRB ID/LCID/E-RAB. The mapping entity in WLAN MAC may report the determined mapping to the adapter entity in WT node (WLAN AP 106a or WLAN AG 108) for each PDCP PDU per bearer per UE. On receiving the same WT node (WLAN AP 106a or WLAN AG 108) can maintain the mapping between the GTP-U SN and PDCP SN based on the information provided by WLAN MAC. The WT node (WLAN AP 106a or WLAN AG 108) can later marks the PDCP packet (i.e. GTP-U packet) as successful delivered or not successful based on status provided by WLAN MAC mapping entity. Another way is WLAN MAC itself maintains the mapping between PDCP SN and MAC SN and only informs the status of each PDCP PDU to the WT node. On receiving the status from the mapping entity in WLAN MAC the adapter entity at the WT node (WLAN AP 106a or WLAN AG 108) can mark the GTP-U SN as successful delivered or not successful. The adapter entity then uses this status of the GTP-U SN (i.e. PDCP SN) for flow control on the Xw-UP per bearer per UE.
[0099] Approach 3: WLAN termination Node predicting the mapping based on configured parameters by WLAN
[00100] In this case while configuring the WLAN AP 106a, it will provide the few of parameters to the WT node (WLAN AC or WLAN AG 108) entity which is required to determine the mapping between PDCP SN and WLAN MAC SN. In this case WLAN AP 106a shares the parameters like fragmentation threshold, Concatenation or Aggregation and possible WLAN header size in bytes. Once the WT node (WLAN AC or WLAN AG 108) entity receives the PDCP packet, it determines the possible packet size based on provided parameters by WLAN AP 106a, by comparing the size of PDCP data packet with fragmentation threshold and concatenation parameters provided by WLAN AP. It then determines number of fragmented or concatenated packets by comparing size of PDCP PDU with these parameters and also by considering possible header fields and then determining the possible WLAN MAC SN and maintains the mapping between PDCP SN and WLAN MAC SN. WLAN MAC on receiving the PDCP packet processes the PDU and from the M-PDU by assigning WLAN MAC SN and transmit to UE104a. Once receiver entity (i.e. UE WLAN MAC entity) acknowledges the successful reception of MAC SN to the transmitter entity (i.e. WLAN AP 106a), the WLAN AP 106a informs the status of each MAC SN to WT node entity (WLAN AG108).
[00101] On receiving the same adapter entity at the WT node (WLAN AC or WLAN AG 108) can mark the PDCP PDU as successful delivered or not successful associated with that WLAN MAC SN. The adapter entity then uses the status of the PDCP SN which is mapped to GTP-U SN for flow control on the Xw-UP per bearer per UE.
[00102] In case multiple bearers have been offloaded to WLAN with same QoS requirements then the WT node (WLAN AC or WLAN AG 108) or WLAN MAC may apply any one of the above flow control approaches by considering common WLAN MAC SN space i.e. different PDCP PDU from different bearers can be mapped to common MAC entity. The bearers, with different QoS requirements, have different WLAN MAC SN space. The mapping rules are same in both the cases.
[00103] FIG. 9a and Fig. 9b illustrate plurality of entities of the WLAN AG (WT node) and the WLAN AP implementing the flow control mechanism at the WT node to control data rate at which the data packets of the offloaded DRB are received from the LTE node, as disclosed in the embodiments herein. As depicted in the FIG. 9a and FIG. 9b, the WT node (here, the WLAN AG 108) is further connected to plurality of WLAN APs such as WLAN AP 106a through the local interface 902. The PDCP entity which is created per bearer in LTE node 102 assigns PDCP SN to each PDCP PDU (for example, 500, 501, 502, and 503). The PDCP entity in the LTE node 102 is per UE per bearer entity. The PDCP entity assigns the PDCP SN and includes the LCID/DRB ID to each PDCP packet in the PDCP header and sends the packets to the GTP entity.
[00104] The GTP entity (not shown in FIGs. 9a and 9b for brevity), is also per UE per bearer entity. The GTP entity appends the GTP-U header in front of the PDCP header. Further, transports the PDCP PDU appended with GTP-U header on the GTP-U tunnel associated with that bearer to WLAN AG 108. The appended GTP-U header comprises the GTP-U sequence number (GTP-U SN) for the PDCP PDU payload transported on the GTP-U tunnel associated with that bearer. The GTP-U header containing the GTP-U SN is also referred as Xw-SN. A bearer management entity 910 in WLAN AG 108, based on the TEID of the GTP-U tunnel, removes the GTP-U header but maintains mapping between the GTP-U SN or Xw-SN inside the GTP-U header and the PDCP SN inside the PDCP header for each data packet received on each established GTP-U tunnel.
[00105] The bearer management entity 910 can be configured to handle the received data packets (PDCP PDUs) transported on the respective GTP-U tunnels which need to be buffered at the WLAN AP 106a according to WLAN QoS characteristics that are identified according to the WLAN AC and UP parameters associated with bearer (GTP-U tunnel) after translation or mapping. The bearer management entity 910 can be configured to either deliver the received PDCP PDU removing the GTP-U header to appropriate AC queues (when Xw interface 304 is directly terminated at WLAN AP 106a) associated with the UE or send one or more PDCP PDUs with same QoS characteristics on the local interface 902 adding an appropriate header containing the QoS marking field.
[00106] The queue management entity 912 can be configured to deliver the packets (PDCP PDUs) of a particular UE belonging to a particular bearer (GTP-U tunnel) to the respective AC queue according to the WLAN AC and UP parameters associated with bearer. In some implementations the queue management entity 912 may also be configured to maintain the mapping between the PDCP SN and WLAN MAC SN per UE per bearer. As shown in FIG. 9b, based on the TEID or UE WLAN MAC address in the header containing the QoS marking field the data packet reaches a WLAN MAC 904 where the data packets are treated as MAC SDU (M-SDU) by a queue management entity 912 and buffered in appropriate AC queues 914. Every M-SDU is equivalent to PDCP PDU. The WLAN MAC 904 has mapping entity 908 which may fragment or aggregate this M-SDU to form MAC PDU (M-PDU) based on parameters configured by wireless network operator of the wireless communication system 100.
[00107] The mapping entity 908 is present in the WLAN MAC 904 and can be configured to perform the following tasks:
[00108] 1. Fragment M-SDU or concatenate (aggregate) multiple M-SDUs to form M-PDU based on parameters configured by wireless network operator;
[00109] 2. Add MAC SN to each M-PDU;
[00110] 3. Detect the PDCP SN and DRB ID/E-RAB of each packet (M-SDU) from the PDCP header and determine the mapping between PDCP SN and WLAN MAC SN per UE per bearer;
[00111] 4. If LRN is assigned to the PDCP PDU then optionally store LRN in its database and then while forming M-PDU need to determine the WLAN MAC to PDCP SN mapping per UE per bearer;
[00112] 5. Maintain and store the mapping between PDCP SN or LRN and WLAN MAC SN per UE per bearer;
[00113] 6. Provide the status to flow control entity 918 for each PDCP packet or M-PDU or M-SDU for each PDCP SN or Local reference number or WLAN MAC SN per UE per bearer based on the feedback received from the UE for the transmitted M-PDU;
[00114] 7. Interact with the retransmission entity 906 to determine which packet is successfully transmitted or not for re-transmission purpose.
[00115] The WLAN MAC 904 can be configured to assign MAC SN to each M-PDU and a mapping entity 908 can be configured to maintain mapping between PDCP SN or a Local Reference Number (LRN) and MAC SN per UE per bearer based on TEID/DRB ID/UE WLAN MAC address. As depicted in the FIG. 9b multiple M-SDU can be concatenated into single M-PDU, where multiple PDCP PDU (each having different PDCP SN) can be concatenated to single M-PDU with same WLAN MAC SN. Alternatively, single M-SDU is fragmented into multiple M-PDU with same MAC SN, where PDCP PDU is fragmented into multiple M-PDU with same WLAN MAC SN (Fragment packets belonging to same SDU have same WLAN MAC SN). A retransmission entity 906 can be configured to handle retransmission of each M-PDU and informs the status of each packet to mapping entity 908 as shown in FIGs. 9a and 9b. The retransmission entity 906 can be configured to handle the feedback for each M-PDU received from UE on WLAN air-interface and inform the mapping entity 908 about successful/unsuccessful transmission of each WLAN packet. It may directly inform the flow control entity 918 the transmission status for each PDCP packet or M-PDU or M-SDU for each PDCP SN or Local reference number or WLAN MAC SN per UE per bearer.
[00116] The flow control entity 918 can be configured to maintain the successful and unsuccessful transmission status for each PDCP packet per UE per bearer based on status provided by the mapping entity 908 in WLAN AP 106a. On receiving the status of each M-PDU from retransmission entity 906, the mapping entity 908 can be configured to inform the status to a flow control entity 918 in WLAN AG 108 for each PDCP PDU, where the status of either MAC SN or PDCP SN or LRN is informed depending on the mapping approaches used during implementation. On receiving the feedback 920 from the mapping entity 908 the flow control entity 918 can be configured to determine the successful and unsuccessful transmission of each PDCP PDU per UE per bearer as shown in FIG. 9b. When LTE node 102 enquires for status of the PDCP packet or GTP packet, the flow control entity 918 can be configured to form the data delivery status PDU such as PDU type 1 and share with LTE node 102. The flow control entity 918 can be configured to determine the mapping between GTP-U SN and PDCP SN when the enquiry from the LTE node 102 is on GTP-U SN or Xw-SN basis.

[00117] The flow control can be per UE per GTP-U tunnel regardless of one or more bearers associated with the UE mapped to the respective GTP-U tunnels.
[00118] FIG. 10 illustrates a sequence diagram depicting steps for implementation of the flow control mechanism at the WT node, as disclosed in the embodiments herein. As depicted, the LTE node 102 sends (1002) the PDCP packet to the WT node (WLAN AP 106a or WLAN AG 108) over the Xw interface 304 through the established GTP-U tunnel. The PDCP packet is sent as a GTP-U packet through the established GTP-U tunnel. The WT node maintains (1004) the buffer per bearer and maintains the mapping between GTP-U SN and PDCP SN. It may also use alternate approaches such as creating local reference number (LRN) for each PDCP PDU. The WT node sends (1006) the PDCP packet to WLAN MAC along with LRN. These packets are treated as M-SDU at WLAN MAC. The WLAN MAC 904, on receiving the same performs (1008) fragmentation or concatenation for each M-SDU and forms an M-PDU by assigning WLAN MAC SN. The WLAN MAC 904 also determines the mapping between PDCP SN and WLAN MAC SN or alternatively determines the mapping between LRN and WLAN MAC SN. Further, the WLAN MAC 904 sends (1010) the MAC SN(s) associated with the PDCP SN/LRN to the WT node. This step (1010) is optional in the case where status in step 1018 is based on MAC SN instead of PDCP SN or LRN. In case multiple bearers are offloaded with same QoS requirements, the WLAN MAC 904 sends separate LRN/PDCP SN to WLAN MAC SN mapping for each bearer. Further, the WT node maintains (1012) GTP-U SN or XW-U SN to PDCP SN mapping for each bearer based on information provided by WLAN MAC entity 904. The WLAN MAC 904 then transmits (1014) the M-PDU to the UE 104a on the WLAN air interface based on the WLAN QoS parameters. In response, the UE 104a sends (1016) ACK/Block ACK for successful received PDUs.
[00119] Once WLAN MAC 904 receives the acknowledgement, the WLAN MAC 904 determines the PDCP SN/LRN successfully delivered to the UE based the acknowledgement (1016) from the UE. The WLAN MAC 904 sends (1018) the status of each LRN/PDCP SN to WT node. Optionally the status (1018) can also be based on MAC SN if mapping of MAC SN to PDCP SN/LRN is informed to WT node in step 1010. Further, the WT node marks (1020) the successful transmission of GTP-U SN or Xw-U SN based on status provided for PDCP SN/LRN. In case WLAN MAC 904 does not receive the status for any packet, the WLAN MAC 904 decides (1022) to retransmit the packet for which ACK is not received and retransmits (1024) the MAC PDU. Further, the WLAN MAC 904 waits for a response from UE 104a for the retransmitted MAC PDU. If the WLAN MAC 904 does not receive any ACK from the UE 104a then marks the transmission of that WLAN MAC SN as unsuccessful. Based on the mapping between PDCP SN and WLAN MAC SN the WLAN MAC 904 sends (1026) the status of PDCP SN or LRN to the WT node. The WT node then marks (1028) the unsuccessful transmission of PDCP SN based on status provided by WLAN MAC. Further, the WT node uses this status of the PDCP SN for flow control on the Xw-U per bearer per UE. The WT node forms the DL DATA DELIVERY STATUS (PDU TYPE 1) and shares (1030) the status with LTE node 102.
[00120] The methods mentioned in FIG 10. for mapping of PDCP SN to WLAN MAC SN can be applicable even at the UE side for the UL DRB whose PDCP PDUs are directly transmitted by the UE 104a to the WLAN AP 106a on the WLAN air interface.
[00121] FIG. 11 illustrates a sequence diagram depicting implementation of the flow control mechanism at the UE side, as disclosed in the embodiments herein.
[00122] The LTE node 102 needs feedback from the WLAN to control the downlink user data flow via the WT node (WLAN AP 106a or WLAN AG 108). A protocol of the WT node cannot provide the desired information required by the LTE node 102 to handle the flow control. A new mechanism is introduced to handle flow control as shown in FIG. 11, where LTE node 102 receives the input from the UE 104a as well as the WT node (WLAN AP 106a or WLAN AG 108). The sequence of steps followed by the wireless communication system 100 for flow control mechanism involving the UE 104a is described by the sequence diagram of FIG. 11. The UE 104a, in RRC connected state (1102), performs the association (1104) procedure with the WT node (WLAN AP 106a or WLAN AG 108), indicated in the WLAN configuration as described in FIG. 5 or FIG. 6. The LTE node 102 sends PDCP PDUs of offloaded bearer over the Xw interface through DL USER DATA message (1106) to the WT Node. Further, the WT node (WLAN AP 106a or WLAN AG 108) processes the PDCP packets and forms the WLAN MAC PDUs (1108) and sends it to UE 104a. The UE 104a, on receiving the packets from WLAN link, detect successfully received WLAN MAC PDUs (1110) and forwards the packets to PDCP entity which maintains successful and unsuccessful received PDCP PDU SN. Further, the UE 104a sends ACK/Block ACK for successfully received WLAN MAC PDUs (1112) to the WT node. Further, the UE 104a can share the feedback or the PDCP status report (1114) with LTE node 102 for the offloaded bearer in new PDCP status PDU so that it can handle the flow control. The UE 104a can provide the information like highest successful delivered PDCP SN and also highest successful delivered PDCP SN by WLAN, lost SN range and so on. A table 5 below describes the format for the new PDCP status PDU. The various trigger for new PDCP status PDU are as below:
1. UE can control this status PDU based on timers configured by the network (wireless communication system 100). The network (NW) can configure periodic timer for the same and on expiry of same UE can share the status PDU.
2. The status PDU can be send during error scenario like Radio Link Failure (RLF), out of service (OOS) or the like. Alternatively, the status PDU can be sent during error recovery scenario or other scenarios like Hand over (HO), re-establishment. The NW can control the transmission of the status PDU through status prohibit timer. This timer is used by the PDCP entity in order to prohibit transmission of a STATUS PDU
3. The NW can ask the UE to send this packet through indication or through the new PDCP status PDU , on receiving the same UE can send this new packet to the NW
4. A new PDU type say enhanced PDCP status report can be defined whose value is in the range of 010-111. The various options to send this packet are as shown below in Table 5 below.

Table 5:

[00123] Further, the WT node determines data rate (1116) and buffer status per UE per bearer and provide this information to LTE node 102 to handle the flow control. A new PDU format PDU type 2 can be defined for the same which can provide this information or the PDU format PDU type 1 can be enhanced which can have these additional parameters. The determination of these parameters like data rate and buffer state is explained in the later section WLAN buffer size and status. On receiving the data rate and status report the LTE node 102 decides the rate control on the Xw interface and retransmission of unsuccessful PDCP PDUs through LTE air interface (1118).
[00124] Option 1: In this case UE provides RSW (Highest received PDCP SN by UE through WLAN link) followed by missing SN range through FSM (first missing SN) and bitmap: This parameter indicates feedback about the in-sequence delivery status of PDCP PDUs at the UE towards the UE. RSW can be optional and UE may directly provide the FSM
[00125] Option 2: This PDCP PDU format has the RSW, a list length field (LENGTH) and a list of LENGTH number of pairs as shown above. The various parameters are as below:
1. LENGTH: The number of (SNi, Li)-pairs in this status PDU
2. SNi: "Sequence Number" of PDCP PDU, which was not correctly received.
3. Li: Number of consecutive PDCP PDUs not correctly received following PDCP PDU with "Sequence Number" SNi.
[00126] Option 3: It is same as option2 except that there is no RSW field in this.
[00127] Option 4: The option 4 has FMS (First Missing SN), highest successfully delivered SN, No of lost SN range along with range
[00128] Estimation of WLAN data Rate and Buffer status or size
[00129] The WT node (WLAN AP 106a) may be serving multiple UEs and it is possible the queues are common for all UEs. Thus, there is need to define a method at WLAN AP 106a or adaptor entity which determines the data rate and buffer size per UE and per bearer.
[00130] WLAN buffer size/status: Steps that can be followed to determine WLAN buffer size/status is explained below in Table 6. WLAN AP 106a can provide the buffer status per UE (multiple bearers) or per bearer or total buffer size or the like. The buffer size can be determined at different levels. It is left to a NW operator, which information the NW operator wants to share with the MeNB (LTE node 102). The steps mentioned indicate:
1. The bearer management entity is aware how many PDCP PDU’s per UE it has put in all the Access class queues. Based on that it can derive a weight for each UE such that sum of the weights is X
2. The bearer management entity is aware how many PDCP PDU’s per UE it has put in the Access Class queues. Based on that it can derive a weight for each UE per Access class
3. The bearer management entity is aware how many PDCP PDU’s per UE per bearer it has put in the Access Class queues. Based on that it can derive a weight for each UE per Access class per bearer
4. Total Buffer status at WLAN AP or Sum rate can be derived by adding weight for all the UE served by WLAN AP
5. Total Buffer status per Access Class can be determined by adding weight for all the UE for every access class served by WLAN AP
Table 6:
Equation1: Weight per UE(WU): Sum of weight of UE for all Access Class
WU = Sum of PDCP PDU per AC(AC-V0 + AC-V1 + AC-BE + AC-BK)
Equation2: Weight per UE per Access Class(WU-AC): Sum of UE per Access Class
WU-AC = Sum of PDCP PDU per AC – Single Access Class
Equation3: Weight per UE per Access Class per Bearer (WU-AC-Bearer): Sum of UE per Access Class per bearer
WU-AC-Bearer = Sum of PDCP PDU per UE per AC per Bearer (Multiple bearer)
Equation4: Total Buffer Status or size (TBS): Sum of weight of all UE served through WLAN
TBS = WU1 + WU2……………..WUn
Equation5: Total Buffer Status per Access Class: Sum of weight of all UE served through specific AC
TBS-AC = WU-AC {Sum of (UE1 + UE2…………….UEn)}

[00131] WLAN Data Rate: The WLAN data rate can be determined at different levels as explained below in Table 7. It is left to the NW operator which information it wants to share with the LTE node 102 (i.e. MeNB)Option1: WLAN rate per UE can be calculated based on weight per UE and sum rate (i.e. Total buffer status)
[00132] Option2: WLAN rate per UE per Access Class (AC) can be derived on the weight assigned to the queues or AC .So there can be weight per queue and weight per UE based on which roughly the rate per UE per bearer can be estimated
[00133] Option3: WLAN rate per UE per Access Class (AC) based on total buffer status per AC: This rate can be derived per UE depending on the weight assigned to the queues or AC .So there can be weight per queue and total buffer status on which roughly the rate per UE per bearer can be estimated
[00134] Option4: WLAN rate per UE per Access class (AC) can be derived on the weight assigned to the queues or AC total buffer status per AC, based on which roughly the rate per UE per bearer can be estimated
[00135] Option 5: WLAN rate per UE can be calculated based on weight per UE and total buffer status per AC
[00136] Option 6: WLAN rate per UE can be calculated based on total buffer status per Access Class and total buffer status across all UEs
[00137] Option 7: WLAN rate per UE can be calculated based on weight assigned to the queues or AC per bearer to the total weight assigned to the per AC or queues per UE.
Table 7:
Option1: WLAN data rate = WU/TBS
Option2: WLAN data rate = WU-AC/WU
Option3: WLAN data rate = WU-AC/TBS
Option4: WLAN data rate = WU-AC/TBS-AC
Option5: WLAN data rate = WU/TBS-AC
Option6: WLAN data rate = TBS-AC/TBS
Option7: WLAN data rate = WU-AC-bearer/WU-AC
NOTE: All equations valid for WU-AC can be valid for WU-AC bearer also.

[00138] WLAN throughput per UE: Sum of packets in all queues divided by the observation time gives the throughput on Wi-Fi interface for all bearers and all UEs the WLAN is handling.
[00139] DL DATA DELIVERY STATUS from WLAN AP 106a (new PDU Type)
[00140] WLAN AP 106a provides feedback to MeNB through PDU type 2 or Enhanced format for PDU type 1. New (Option1) or enhanced PDU type (option 2) frame formats are defined to transfer feedback to allow the receiving MeNB to control the downlink user data flow via the WLAN AP 106a.
[00141] All possible option related to feedback like WLAN data rate, buffer size or status or throughput can use below mentioned formats to share the information with MeNB. Alternatively the LTE node 102 (i.e. MeNB) can also ask for specific details from WLAN AP. The below formats have been explained by considering few options; however these are applicable for every possible option explained above.
[00142] Option 1: Format for PDU type 2
[00143] The PDU type 2 can contain the below fields as shown in Table 8 below. The WLAN AP 106a can provide WLAN buffer size or status for the E-RAB/UE. The WLAN AP 106a can also provide WLAN data Rate per UE/per bearer along with highest delivered PDCP Sequence Number. These new fields can help to handle to flow control at the LTE node 102 (i.e. MeNB). The sequence of these fields can be changed as per design. WLAN AP 106a can also provide throughput per UE per bearer or per Access Class.
Table 8:

[00144] Option 2: Enhanced PDU Format for PDU type 1/1a
[00145] The enhanced PDU type 1 or 1a or PDU type 1 can contain WLAN buffer size for the E-RAB or UE. Additionally it can also contain WLAN data rate per UE or per bearer. The fields which are currently present in PDU type 1 like PDCP Sequence Number, lost of packets and so on can be optional for WLAN AP 106a. It may or may not provide these values depending upon the NW operator implementation and handling of packets. The PDCP SN can be determined based on method defined above.
[00146] Thus, the new flow control mechanism can enable the LTE node 102 to decide data rate control on Xw interface and retransmission of unsuccessful PDCP PDUs through LTE air interface.
[00147] FIG. 12 a sequence diagram depicting a mechanism for providing Radio Link Failure (RLF) feedback to the LTE node from the WLAN AP, as disclosed in the embodiments herein.
[00148] In Dual connectivity, a Secondary Cell Group (SCG) failure is due to two reasons; either due to RLF during normal operation or due to expiry of a T307 timer before RACH is completed. Once such condition occurs, then UE 104a sends the SCG failure to MeNB and MeNB take appropriate action to recover from error scenario.
However, in LTE and Wi-Fi aggregation, such triggers cannot be used because there is no RLF concept in Wi-Fi so there is need to introduce detection of RLF mechanism at the NW side. The absence of this detection can lead to huge packet drop and can impact the data rate. The FIG. 12 provides a mechanism for providing radio link failure feedback to LTE node 102 from the WT node (WLAN AP 106a or WLAN AG 108) The UE 104a is connected to LTE node 102 as well as WLAN through LTE RAT and WLAN RAT aggregation mechanism (1202 and 1204). Once WT node detects RLF (1206) or error in connection or gets disconnected from the UE 104a, the WT node informs the LTE node 102 about WLAN link failure indication (1208) over Xw interface so that the LTE node 102 can take appropriate action. The WT node can also inform about last successful PDCP SN, number of lost packets and so on. The WT node can reuse the existing mechanism to detect the link failure such as connection lost due to signal condition or packet loss or Triggers which can cause disconnect of the UE with WT node and so on. On receiving the same, the LTE node 102 can decide to release or reconfigure or suspend (1210) the WT node (WLAN AP 106a or WLAN AG 108). The LTE node 102 (i.e. MeNB) can retransmit the unacknowledged PDCP packets over new WLAN link or through LTE itself. Further, the LTE node 102 may start WLAN AP modification procedure (1212) to resume the WLAN services.
[00149] Apart from the trigger explained above, few more triggers can be added or introduced at WT node which can help to determine link failure .The triggers could be based on:
1. If WLAN buffers starts overflowing it should inform the Adaptor entity about failure
2. Adaptor entity runs out of Sequence Number (SN) or its buffer is full with PDCP packets
3. There is significant loss of packets above defined threshold
[00150] FIG. 13 illustrates plurality of components of the LTE node, as disclosed in the embodiments herein. Referring to figure 13, the LTE node 102 is illustrated in accordance with an embodiment of the present subject matter. In an embodiment, the LTE node 102 may include at least one processor 1302, an input/output (I/O) interface 1304, memory 1306, a WLAN offloading management module, and a communication module 1310. The at least one processor 1302 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries and so on that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 1302 is configured to fetch and execute computer-readable instructions stored in the memory 1306.
[00151] The I/O interface1304 may include a variety of software and hardware interfaces, for example, a user interface and the like. The communication module 1310 can be configured to facilitate multiple communications within a wide variety of networks and protocol types, including networks, for example, Wireless Local Area network (WLAN), cellular networks such as LTE networks and the like enabling communication with plurality of entities of the wireless communication system 100 such as WLAN APs 106a through 106d, WLAN AG 108, one or more UEs 104a through 104e and other entities (not shown). The WLAN offloading management module 1308 may include routines, programs, objects, components, data structures, and so on, which perform particular tasks, functions or implement particular abstract data types. The WLAN offloading management module 1308 may include programs or coded instructions that supplement applications and functions of the LTE node 102. The memory 1306 may store data for the functions performed by the LTE node 102 such as mapping table for the LTE QoS parameters to WLAN QoS parameters, which can be used during offloading of the DRBs to the WLAN when LTE node 102 is configured to perform the mapping.
[00152] In an embodiment, the WLAN offloading management module 1308 can be configured to perform one or more of functions associated the LT node 102 s as described in FIG 1 through FIG. 12 to implement steps of method 200 for performing offloading of the DRBs to the WLAN. Thus, the WLAN offloading management module 1308 can be configured provide or assist in one or more functions such as mapping of the LTE QoS parameters to the WLAN QoS parameters (if implemented at LTE node 102), controlling the data rate for data transferred from the LTE node 102 to the WT node on the Xw interface, wherein the flow control mechanism, may be implemented in at least one of the WT node and the UE.
[00153] FIG.14 illustrates plurality of components of the WT node (WLAN AP or WLAN AG), as disclosed in the embodiments herein. Referring to figure 14, the WT node (WLAN AP 106a or WLAN AG 108) is illustrated in accordance with an embodiment of the present subject matter. In an embodiment, the WT node (WLAN AP 106a or WLAN AG 108) may include at least one processor 1402, an input/output (I/O) interface 1404, a memory 1406, a WLAN offloading management module 1408 a communication module 1410. The at least one processor 1402 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries and so on that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 1402 is configured to fetch and execute computer-readable instructions stored in the memory 1406.
[00154] The I/O interface1404 may include a variety of software and hardware interfaces, for example, a user interface and the like. The communication module 1410 can be configured to facilitate multiple communications within a wide variety of networks and protocol types, including networks, for example, Wireless Local Area network (WLAN), cellular networks such as LTE networks and the like, to communicate with plurality of entities of the wireless communication system 100 such as LTE nodes including LTE node 102 through the Xw interface, one or more UEs 104a through 104e through WLAN interface and other entities (not shown). The WLAN offloading management module 1408 may include routines, programs, objects, components, data structures, and so on, which perform particular tasks, functions or implement particular abstract data types. The WLAN offloading management module 1408 may include programs or coded instructions that supplement applications and functions of the WT node (WLAN AP 106a or WLAN AG 108). The memory 1406 may store data for the functions of the WT node (WLAN AP 106a or WLAN AG 108)such as mapping table for the LTE QoS parameters to WLAN QoS parameters, which can be used during offloading of the DRBs to the WLAN when the WT node (such as WLAN AP 106a) is configured to perform the mapping.
[00155] In an embodiment, the WLAN offloading management module 1408 can be configured to perform one or more of functions associated the WT node (WLAN AP 106a or WLAN AG 108) as described in FIG 1 through FIG. 12 to implement steps of method 200 for performing offloading of the DRBs to the WLAN. Thus, the WLAN offloading management module 1408 can be configured provide or assist in one or more functions such as mapping of the LTE QoS parameters to the WLAN QoS parameters, assist the LTE node 102 to control the data rate on the Xw interface using the flow control mechanism, if implemented at the WT node. The functions implemented by the WT node can be carried out by one or more entities within the WT node such as the adapter entity, the bearer management entity, the queue management entity and the like.
[00156] FIG. 15 illustrates plurality of components of the UE, as disclosed in the embodiments herein. Referring to figure 15, the UE 104a is illustrated in accordance with an embodiment of the present subject matter. In an embodiment, the UE 104a may include at least one processor 1502, an input/output (I/O) interface 1504, a memory 1506, a WLAN offloading management module 1508 and a communication module 1510. The at least one processor 1502 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries and so on that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 1502 is configured to fetch and execute computer-readable instructions stored in the memory 1506.
[00157] The I/O interface1504 may include a variety of software and hardware interfaces, for example, a user interface and the like. The communication module 1510 may include a LTE communication module 1512 to communicate with the entities of the LTE network such as the LTE node 102. Further, the communication module 1510 may include a WLAN communication module 1514 to enable the UE 104a to communicate with the WT node (WLAN AP 106a or WLAN AG 108) over WLAN interface during offloading of the DRBs to the WLAN. Further, the communication module 1510 may facilitate multiple communications within a wide variety of networks and protocol types, including networks, for example, Wireless Local Area network (WLAN), cellular networks such as LTE networks, Device to Device communication and the like. The WLAN offloading management module 1508 may include routines, programs, objects, components, data structures, and so on, which perform particular tasks, functions or implement particular abstract data types. The WLAN offloading management module 1508 may include programs or coded instructions that supplement applications and functions of the UE 104a. The memory 1506 may store data for the functions of the such PDCP status reports for the flow control mechanism implemented in the UE 104a for offloaded DRBs to the WLAN.
[00158] In an embodiment, the WLAN offloading management module 1508 can be configured to perform one or more of functions associated the UE 104a as described in FIG 1 through FIG. 12 to implement steps of method 200 for performing offloading of the DRBs to the WLAN. Thus, the WLAN offloading management module 1508 can be configured provide or assist in one or more functions of the WT node and the LTE node 102.
[00159] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in FIG. 1 through FIG. 15 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
[00160] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
,CLAIMS:STATEMENT OF CLAIMS
We claim:
1. A method for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier served by a WLAN, wherein the method comprises:
exchanging control plane signaling, by a LTE node with a WLAN Termination (WT) node, to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node;
mapping, by one of the LTE node and the WT node, the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received on the offloaded DRB; and
receiving, by the WT node, data packets of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
2. The method as claimed in claim 1, wherein the method comprises:
when the WT node is a WLAN Access Point (AP);
creating, by the WT node, at least one Access Class (AC) queue corresponding to at least one WLAN AC category in accordance with the WLAN QoS parameter assigned to the offloaded DRB, to buffer the data packets received through the GTP-U tunnel; and
scheduling, by the WT node, each data packet, buffered in the at least one Access Class (AC) queue, on the WLAN carrier based on the assigned WLAN QoS parameter associated with the offloaded DRB.
3. The method as claimed in claim 1, wherein the method comprises:
when the WT node is a WLAN Access Gateway (AG);
marking, by the WT node, each data packet of the offloaded DRB with a QoS header, wherein the QoS header comprises the mapped WLAN QoS parameter for the offloaded DRB; and
transmitting, by the WT node, each marked data packet to a WLAN Access Point (AP) over a local interface, wherein the WLAN AP creates at least one AC queue based on the QoS header associated with each marked data packet for buffering each data packet in the at least one Access Class (AC) queue and scheduling the buffered data packet on the WLAN carrier based on the assigned WLAN QoS parameter associated with the data packet.
4. The method as claimed in claim 1, wherein offloading of the at least one DRB to the WLAN carrier is performed at a Packet Data Convergence Protocol (PDCP) layer, wherein the data packets of the offloaded DRB are PDCP Protocol Data Units (PDUs).
5. The method as claimed in claim 1, wherein mapping of the LTE QoS parameter to the WLAN QoS parameter on per DRB level comprises mapping of a LTE QoS Class Identifier (QCI) value to a WLAN AC category based on at least one of a priority attribute of the LTE QoS parameter associated with the offloaded DRB, type of service associated with the offloaded DRB and, a bearer type attribute associated with the offloaded DRB.
6. The method as claimed in claim 1, wherein each data packet transported through the GTP-U tunnel associated with the offloaded DRB comprises a plurality of headers, wherein the plurality of headers comprise a GTP header and a Packet Data Convergence Protocol (PDCP) header, wherein the GTP header comprises the GTP sequence number and the PDCP header comprises data radio bearer identity (DRB-ID) of an Evolved Packet System (EPS) bearer corresponding to the offloaded DRB.
7. The method as claimed in claim 1, wherein the offloaded DRB is at least one of a Downlink (DL) bearer and an uplink (UL) bearer established for the UE.
8. The method as claimed in claim 7, wherein the method comprises informing the mapped WLAN QoS parameter associated with the offloaded DRB to the UE by one of the LTE node and the WT node when the offloaded DRB is the UL bearer.
9. The method as claimed in claim 1, wherein the method comprises implementing a flow control mechanism in at least one of the WT node and a UE to control data rate at which the data packets are received from the LTE node through the GTP-U tunnel associated with the offloaded DRB.
10. The method as claimed in claim 9, wherein the flow control mechanism, implemented at the WT node, comprises providing the LTE node with a delivery status of each data packet, wherein the delivery status is generated by mapping a PDCP sequence number associated with each data packet to a GTP sequence number, wherein status of the PDCP sequence number is received from a WLAN MAC entity of the WLAN AP.
11. The method as claimed in claim 10, wherein the status of PDCP sequence number is derived by the WLAN MAC entity of the WLAN AP by mapping a MAC sequence number (MAC SN) to the PDCP sequence number and based on the acknowledgement received from the MAC entity of the UE for each MAC SN.
12. The method as claimed in claim 9, wherein the flow control mechanism, implemented at the UE, comprises providing the LTE node with a delivery status of each data packet, wherein the delivery status is generated by mapping a PDCP sequence number associated with each data packet to a MAC SN, wherein the status of the MAC SN is received from a WLAN MAC entity of the UE.
13. The wireless communication system for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier served by a WLAN, wherein the wireless communication system comprises:
a LTE node configured to:
exchange control plane signaling with a WLAN Termination (WT) node to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node;
one of the LTE node and the WT node configured to:
map the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received by the WT node on the offloaded DRB;
the WT node configured to:
receive the data packets, sent by the LTE node, of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
14. The wireless communication system as claimed in claim 13, wherein the WT node, when the WT node is a WLAN Access Point (AP), is configured to:
create at least one Access Class (AC) queue corresponding to at least one WLAN AC category in accordance with the WLAN QoS parameter assigned to the offloaded DRB, to buffer the data packets received through the GTP-U tunnel; and
schedule each data packet, buffered in the at least one Access Class (AC) queue, on the WLAN carrier based on the assigned WLAN QoS parameter associated with the offloaded DRB.
15. The wireless communication system as claimed in claim 13, wherein the WT node, when the WT node is a WLAN Access Gateway (AG), is configured to:
mark each data packet of the offloaded DRB with a QoS header, wherein the QoS header comprises the mapped WLAN QoS parameter for the offloaded DRB; and
transmit each marked data packet to a WLAN Access Point (AP) over a local interface, wherein the WLAN AP creates at least one AC queue based on the QoS header associated with each marked data packet for buffering each data packet in the at least one Access Class (AC) queue and scheduling the buffered data packet on the WLAN carrier based on the assigned WLAN QoS parameter associated with the data packet.
16. The wireless communication system as claimed in claim 13, wherein the LTE node is configured to perform the offloading the at least one DRB to the WLAN carrier at a Packet Data Convergence Protocol (PDCP) layer, wherein the data packets of the offloaded DRB are PDCP Protocol Data Units (PDUs).
17. The wireless communication system as claimed in claim 13, wherein one of the LTE node and the WT node is configured to map the LTE QoS parameter to the WLAN QoS parameter on per DRB level by mapping of a LTE QoS Class Identifier (QCI) value to a WLAN AC category based on at least one of a priority attribute of the LTE QoS parameter associated with the offloaded DRB, type of service associated with the offloaded DRB and, a bearer type attribute associated with the offloaded DRB.
18. The wireless communication system as claimed in claim 13, wherein each data packet, transported through the GTP-U tunnel associated with the offloaded DRB comprises a plurality of headers, wherein the plurality of headers comprise a GTP header and a Packet Data Convergence Protocol (PDCP) header, wherein the GTP header comprises the GTP sequence number and the PDCP header comprises data radio bearer identity (DRB-ID) of an Evolved Packet System (EPS) bearer corresponding to the offloaded DRB.
19. The wireless communication system as claimed in claim 13, wherein the offloaded DRB is at least one of a Downlink (DL) bearer and an uplink (UL) bearer established for the UE.
20. A Wireless Local Area Network (WLAN) Termination node (WT node) for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a WLAN carrier served by a WLAN, wherein the WT node comprises a WLAN offloading management module configured to:
exchange control plane signaling with a LTE node to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node;
map the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received on the offloaded DRB; and
receive data packets of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
21. The WT node as claimed in claim 20, wherein the WLAN offloading management module, when the WT node is a WLAN Access Point (AP), is configured to:
create at least one Access Class (AC) queue corresponding to at least one WLAN AC category in accordance with the WLAN QoS parameter assigned to the offloaded DRB, to buffer the data packets received through the GTP-U tunnel; and
schedule each data packet, buffered in the at least one Access Class (AC) queue, on the WLAN carrier based on the assigned WLAN QoS parameter associated with the offloaded DRB.
22. The WT node as claimed in claim 20, wherein the WLAN offloading management module, when the WT node is a WLAN Gateway (AG), is configured to:
mark each data packet of the offloaded DRB with a QoS header, wherein the QoS header comprises the mapped WLAN QoS parameter for the offloaded DRB; and
transmit each marked data packet to a WLAN Access Point (AP) over a local interface, wherein the WLAN AP creates at least one AC queue based on the QoS header associated with each marked data packet for buffering each data packet in the at least one Access Class (AC) queue and scheduling the buffered data packet on the WLAN carrier based on the assigned WLAN QoS parameter associated with the data packet.
23. The WT node as claimed in claim 20, wherein the WLAN offloading management module is configured to inform the mapped WLAN QoS parameter associated with the offloaded DRB to the UE when the offloaded DRB is a Uplink (UL) bearer.
24. The WT node as claimed in claim 20, wherein the WLAN offloading management module is configured to implement a flow control mechanism to control data rate at which the data packets are received from the LTE node through the GTP-U tunnel associated with the offloaded DRB.
25. The WT node as claimed in claim 24, wherein the WLAN offloading management module, implementing the flow control mechanism, is configured to provide the LTE node with a delivery status of each data packet, wherein the delivery status is generated by mapping a PDCP sequence number associated with each data packet to a GTP sequence number, wherein status of the PDCP sequence number is received from a WLAN MAC entity of the WLAN AP.
26. The WT node as claimed in claim 25, wherein the WLAN offloading management module is configured to derive the status of PDCP sequence number using the WLAN MAC entity of a WLAN AP by mapping a MAC sequence number (MAC SN) to the PDCP sequence number and based on the acknowledgement received from a MAC entity of the UE for each MAC SN.
27. A Long Term Evolution (LTE) node for handling offloading of data radio bearers (DRBs) served by Long Term Evolution (LTE) carrier to a Wireless Local Area Network (WLAN) carrier served by a WLAN, wherein the LTE node comprises a WLAN offloading management module configured to:
exchange control plane signaling with a WLAN Termination (WT) node to establish at least one GPRS Tunneling Protocol User Plane (GTP-U) tunnel for offloading at least one DRB of at least one User Equipment (UE) to the WLAN carrier, wherein an offloaded DRB is assigned an LTE QoS parameter by the LTE node;
map the LTE QoS parameter assigned to the offloaded DRB to a WLAN QoS parameter for buffering each data packet received by the WT node on the offloaded DRB; and
send the data packets of the offloaded DRB through at least one GTP-U tunnel associated with the offloaded DRB.
28. The LTE node as claimed in claim 27, wherein the WLAN offloading management module is configured to control data rate at which the data packets are sent through the GTP-U tunnel associated with the offloaded DRB based on a flow control mechanism implemented at one of the WT node and the UE.

Dated this 8th of August 2016

Signature:

Name of the Signatory: Dr. Kalyan Chakravarthy