LWA stands for LTE-WLAN Aggregation. It is a kind of technology on the evolution path of LTE Unlicencesed technology. You would get the overview of LWA under the context of LTE Unlicensed technology, refer to LTE-U/LAA/LWA page. I decided to create a separate page for LWA since the technical details will be too long to put in the overview page. I will describe the details of the LWA based on 3GPP documents in this page. However, it will take very long before I complete this page because this technology is at very early stage as of now (as of Jun 2016) and I haven't seen any real implementation of this technology personally.
LWA sits between the two families on the LTE-U/LAA/LWA page. Like LAA, it keeps the eNB in control of every bearer. Unlike LAA, it does not run LTE in the unlicensed band, and it sends part of the traffic over a real WLAN access point instead. The sections below cover the architecture, the procedures that add and remove the WLAN, and what the UE does on the WLAN side.
Followings are the topics to be covered in this page.
- Overall Network Architecture for LWA
- Overall Protocol Sequence for LWA
- How does the UE find, report and secure the WLAN ?
- Reference
Overall Network Architecture for LWA
Following is overal network architecture of LWA. As you see here, there can be two different type of scenario(implmentation) of LWA. One is called 'Colocated scenario' and the other one is called 'Non-Colocated scenario'. Regardless of the scenario, one common thing is that the data is split at PDCP layer of LTE and forwarded to LWAAP (LWA Adaptation Protocol) which in turn forwarded to WLAN MAC layer. The difference between the two scenario is the location of WLAN MAC/PHY. In Colocated scenario, LLAN MAC/PHY reside within the eNB (i.e, in the same location of LTE Radio Stack). So LTE PDCP can directed connected to LWAAP and it does not need any special interface between LTE and WLAN. On the contrary, in non-colocated scenario WLAN MAC/PHY resides out side of eNB, so they need special interface called Xw (Xw-C and Xw-U) to convey the control and user data between LWAAP and WLAN MAC/PHY.

Both scenarios have the same three bearer types. In the colocated scenario, the eNB and the WT sit side by side with an internal interface. In the non-colocated scenario, LWAAP stays in the eNB, which reaches the WT over Xw-C and Xw-U.
LTE bearer : PDCP, RLC and MAC in the eNB, as in plain LTE.Split LWA bearer : one PDCP entity sends part of the traffic over LTE and part over WLAN.Switched LWA bearer : PDCP in the eNB, but the data goes over WLAN only.LWAAP : the adaptation layer that hands PDCP PDUs to the WLAN.
36.300 v19.2.0 clause 22A.1 adds several details to the picture. In the downlink, the LWAAP entity adds a DRB identity to each PDU, and the WT sends it with the LWA EtherType 0x9E65. The UE uses the EtherType to recognise LWA traffic, and the DRB identity to find the bearer. The uplink works the same way in reverse, so an LWA bearer can carry uplink PDCP PDUs over WLAN as well. Only RLC AM and RLC UM can be configured for an LWA bearer.
The core network does not see the WLAN at all. S1-U and S1-MME terminate at the eNB, and no core network interface is required for the WLAN. In the non-collocated scenario, the Xw-C interface carries Xw-AP, which sets up the UE context at the WT and transfers WLAN metrics such as BSS load. The Xw-U interface carries the LWAAP PDUs, together with flow control feedback from the WT. The WT itself is a logical node, and 3GPP does not specify where it is implemented.
EtherType 0x9E65 marks LWA traffic : the DRB identity in the LWAAP PDU selects the bearer.No core network change : the WLAN hides behind the eNB.Xw-U has flow control : the WT tells the eNB how the downlink delivery is going.LWA excludes DC, LWIP and RCLWI : E-UTRAN does not configure them for the same UE at the same time.
Overall Protocol Sequence for LWA
The architecture needs procedures to bring the WLAN in and take it out again, and they are all Xw procedures between the eNB and the WT. The UE sees only their result, in an RRCConnectionReconfiguration.
Following is overall protocol sequence for LWA operation. As you see, there are roughly 3 types of operation as listed below.
1) WT (WLAN Termination) Attach
2) WT Modification : This operation can be devided into two types depending on who (eNB or WT) initiate the modification
3) WT Release : This operation can be devided into two types depending on who (eNB or WT) initiate the
At a very high level view, you may notice that the overall procedure is similar to LTE-LTE carrier aggregation process
(Following diagram is based on 36.300 22A.1.7 LTE-WLAN Aggregation Operation)

WT Addition, then eNB initiated WT Modification. The label (7) is used twice, once for WLANConnectionStatusReport and once for WT Modification Request.

WT initiated WT Modification, then eNB initiated WT Release. The label (18) is used twice, once for Release LWA resource and once for RRC Connection Reconfiguration.

WT initiated WT Release. The WT asks, the eNB confirms, and the UE releases its LWA configuration after an RRC Connection Reconfiguration.
The diagrams follow 36.300 clause 22A.1.7, and three labels differ from the v19.2.0 text. In WT Addition, the WT sends the WT Association Confirmation message, where the diagram says WT Association Complete. In the WT initiated WT Modification, the WT starts with the WT Modification Required message, where the diagram says WT Modification Request. In the eNB initiated WT Release, the UE releases the LWA configuration before it replies with RRCConnectionReconfigurationComplete.
The comparison with carrier aggregation holds in one more way. Every procedure except the WT initiated ones starts at the eNB, and the UE receives only an RRCConnectionReconfiguration from it. The WT Modification and WT Release procedures do not always need signalling towards the UE, and the recipient of a WT Release request cannot reject it. A change of WT uses a WT Release followed by a WT Addition.
WT Addition : Xw request and acknowledge, then RRC reconfiguration and WLAN association.WT Modification : initiated by the eNB or the WT, with RRC reconfiguration only when needed.WT Release : cannot be rejected, and the UE may keep its WLAN association afterwards.Change of WT : a WT Release followed by a WT Addition.
How does the UE find, report and secure the WLAN ?
The eNB controls the bearers, but the WLAN connection itself is made by the UE with ordinary WLAN procedures. So the eNB needs a way to tell the UE which access points to use, to hear back how the connection is going, and to secure it without a separate login. 36.300 v19.2.0 clauses 22A.1.4 to 22A.1.8 cover these three points.
The eNB gives the UE a WLAN mobility set, a list of access points identified by BSSID, HESSID or SSID that share one WT. The UE may move between access points in the set without telling the eNB. To move outside the set, the eNB updates it, usually after WLAN measurement reports. Those reports are triggered by RSSI and can be configured for the 2.4 GHz, 5 GHz and 60 GHz bands.
The UE reports its WLAN state with the WLANConnectionStatusReport message, which is step (7) in the diagram above. The report can indicate WLAN connection failure, WLAN connection success, WLAN temporary suspension or WLAN connection resumption. A WLAN failure does not trigger RRC connection re-establishment, and the LTE part of a split LWA bearer carries on unaffected.
For security, the eNB can include a WT Counter in the LWA configuration. The UE then derives the key S-KWT from the WT Counter and KeNB, and uses it as the PMK or PSK for the WLAN, as 33.401 annex G specifies. Without a WT Counter, the UE authenticates with the WLAN methods of 33.402.
WLAN mobility set : the UE moves freely between its access points, and the eNB changes the set.WLANConnectionStatusReport : failure, success, temporary suspension or resumption.WLAN failure leaves LTE alone : no RRC re-establishment, and the LTE leg keeps running.S-KWT from the WT Counter : the eNB key secures the WLAN link without a separate login.
Reference
[1] Collaboration on LTE - WLAN Integration - 3GPP
[2] TS 36.300, section 22A.1 : Stage-2 high level description
[3] TS 36.323 : Stage-3 data plane (PDCP)
[4] TS 36.360 : Stage-3 data plane (LWAAP)
[5] TS 36.331 : Stage-3 control plane (RRC)
[6] TS 36.463, TS 36.462, TS 36.461 : Stage-3 control plane network interface (Xw)
[7] TS 36.465. TS 36.464 : Stage-3 data plane network interface (Xw)
[8] TS 33.401 : Stage-3 security aspects – TS 33.401
[9] 3GPP TS 36.300 v19.2.0 - clause 22A.1, LTE-WLAN Aggregation