Table of Content
1. Introduction
2. Current Trends in LTE - WiFi Aggregation
2.1 3GPP-based LTE - WiFi Aggregation
2.1.1 LTE in Unlicensed/Licensed Assisted Access (LTE-U/LAA)
2.1.2 LTE - WiFi Link Aggregation (LWA)
2.2 IETF-based LTE - WiFi Aggregation
2.2.1 MPTCP Proxy
3 Summary and Future Trends
1. Introduction
At the end of 2014, we posted an article about "Debates on LTE-Unlicensed and Wi-Fi (KT, SK Telecom, Qualcomm, etc.)" in Korea. For the past year or so since then, the world has witnessed pretty impressive progress in terms of unlicensed band utilization. Last year saw LTE-U Forum released LTE-U specifications, and this year will see 3GPP releasing specifications for Licensed Assisted Access (LAA) and LTE-WiFi Link Aggregation (LWA). Commercialized LTE-U/LAA/LWA is likely to be rolled out as well.
With most smartphones coming with built-in cellular and WiFi modems these days, an increasingly surging number of smartphones and mobile traffic means huge spikes in WiFi subscriptions and traffic in a way. User’s strong desire for high-quality video content has made even WiFi service providers share the same goal with mobile network operators: faster speeds and better QoE.
Facing scarceness of available spectrum and a burden of high license fees, mobile operators have been looking for ways out, for example by employing small cells for capacity improvement. This, however, leads to interference and mobility control issues, which is costly. So, mobile operators are in desperate need of more economical solutions to secure more spectrum available.
To cope with increasing WiFi traffic, more WiFi APs have been installed, making WiFi even more easily accessible in cities. Although WiFi APs of today support Gbps-class high capacity, it is still hard to guarantee the quality of video streaming because of the nature of WiFi that shares the channel by multiple users. Besides, quality degradation or service interruption can be experienced even while moving at low speeds because of short coverage. This is why WiFi service providers need a solution to guarantee minimum service quality even during traffic congestion or while on the go.
In fact, 3GPP has long standardized LTE-WLAN integrated architecture at IP level to provide IP mobility to LTE devices accessing over WiFi. So, an LTE device accessing through a WiFi AP can still access the LTE core network thanks to IP connectivity. Specifically, a device can access a separate GW (e.g. ePDG, TWAG, etc.) through a WiFi AP, and then a P-GW. But the downside to this type of IP connectivity is increased signaling load at the LTE core network caused by separate, mandatory security and authentication processes, and a burden of costs to install access GWs.
Recently, new types of LTE-WiFi aggregation solutions at radio link level and at TCP level have been introduced. The first type, radio link-level aggregation, includes LAA and LWA, which are currently being standardized by 3GPP. The strength of LAA and LWA is that they can use both LTE and WiFi bands concurrently for data transmission, and no separate access GW for WiFi is needed because LTE-WiFi aggregation takes place right at device and base station. The second type is TCP-level aggregation, which includes Multipath TCP (MPTCP) Proxy-based aggregation that is currently being discussed at IETF. MPTCP can split data and transmit them through both LTE and WiFi networks, concurrently. LTE-WiFi aggregation takes place right at device and MPTCP Proxy, and hence no dedicated network equipment is required for aggregation additionally.
Such advent of various LTE-WiFi aggregation solutions gives a message that LTE and WiFi now have to cooperate with each other closely instead of maintaining a mere complementary relationship. With both LTE and WiFi traffic growing, the benefit of cooperation is obvious – improved capacity and speeds for LTE and reliable service quality for WiFi.
This document will explore current and future trends in the three most popular LTE-WiFi aggregation solutions: LTE-U/LAA, LWA and MPTCP Proxy.
2. Current Trends in LTE -WiFi Aggregation
Figure 1 shows the conceptual architecture of different types of LTE-WiFi aggregation solutions. LTE CA boosts user speeds by expanding the total bandwidth by means of multiple LTE channel aggregation. Though not involving any WiFi access technically, LTE CA shares the same technical concept that is also applied to LTE-WiFi aggregation.
LTE CA aggregates multiple channels – one primary and one or more secondary channel(s). Only the primary channel can control CA, combining or releasing secondary channel(s) while working as an anchor. LTE-A and LTE-Pro can aggregate LTE channels up to 5 and 32, respectively supporting up to hundreds of Mbps and several Gbps.
Figure 1. Aggregation technologies: LTE-A, LTE-U/LAA, LWA and MPTCP Proxy
With LTE CA, the more channels you aggregate, the faster speeds you achieve. However, due to limit in available licensed spectrum and tremendous spectrum license fees, mobile operators are having a hard time obtaining additional licensed spectrum in time. In Korea, SK Telecom launched the world’s first commercialized 2-band CA (of 20 MHz capable of 150 Mbps) in June 2013, and all 3 operators (KT, SK Telecom and LG U+) launched 2-band wideband CA (of 30 MHz capable of 225 Mbps) a year later. Then in January 2015, they all commercialized 3-band CA (of 40 MHz capable of 300 Mbps), making persistent efforts to discover more advanced CA. But from then on, no speed improvement by CA has been made because of the challenge in securing additional spectrum.
To overcome the challenge, mobile operators are now actively seeking ways to utilize ‘unlicensed’ WiFi bands. In Korea, LG U+ conducted LTE-U demonstration in its commercial network in May 2015, and is all set to launch commercialized LTE-U in 2016. In June 2015, all three operators released MPTCP Proxy-based LTE-WiFi aggregation service.
2.1 3GPP-based LTE -WiFi Aggregation
3GPP is making diligent efforts to standardize technologies for boosting LTE speeds through leveraging unlicensed WiFi bands.
2.1.1 LTE in Unlicensed/Licensed Assisted Access (LTE-U/LAA)
The first of such efforts was LTE-U/LAA, which simply extends LTE CA used in licensed bands to unlicensed bands. LTE-U/LAA is the same as LTE CA in that it uses all channels for LTE, but different from LTE CA in that it uses unlicensed 5GHz.
It is only LTE channel that can work as a primary channel, and unlicensed channel(s) can work as secondary channel(s) that can just assist LTE data transmission rather than performing LTE communication independently. Because of Tx power limits in unlicensed bands, LTE-U/LAA is naturally targeting small cells
LTE and WiFi use different channel access mechanisms. |
|
|
How WiFi bands are allocated, and what regulations are applied to each band vary depending on countries. Below we will discuss what potential issues are expected when 5 GHz bands are shared by WiFi and LTE, and how much progress has been made in standardization of LTE-WiFi aggregation.
Regulations
For 5GHz band, each country has their own frequency policies, regulatory requirements, WiFi band allocations, etc. (Figure 5). For example, Europe and Japan require Listen Before Talk (LBT) channel access mechanism while others like Korea, China and USA do not. LAA is a solution developed with single global solution framework in mind. So, global harmonization for WiFi bands allocation and regulatory requirements should be obtained
Figure 2. 5 GHz spectrum allocation and regulations by country
Fair Access
What should be addressed first is fair access issues resulting from co-channel operation of LTE and WiFi as they use different channel access mechanisms. So, without a proper fair access solution in place, if both LTE and WiFi attempt to transmit through the same channel, LTE would have much greater channel access opportunities than WiFi, failing to create a level playing field. That is because LTE users are transmitted without competition thanks to scheduling by base station, while WiFi users still have to compete to win a channel access chance.
Fair access issues can be more problematic in countries where LBT is not required in WiFi bands. A harmonized fair access solution is essential to realize fair co-existence of LTE-U/LAA and WiFi without causing current WiFi users any performance degradation in 5GHz band. There are two harmonization approaches proposed: LTE-U and LAA.
First, LTE-U solution can be adopted in countries with no LBT regulation (e.g. Korea, USA, China, etc.). The LTE-U forum has released LTE-U specifications including duty cycle-based fair access solution in 2015 (Figure 3). An LTE-U cell first looks for a 'clean channel' through spectrum sensing. It transmits data using full duty cycle if there is one, but to the 'least crowded channel' using dynamic duty cycle if there is not.
Figure 3. Channel access scheme in LTE-U: duty cycle based
The second approach, LAA, can be used even in the countries with LBT requirement (e.g. EU, Japan, etc.). And its standardization is taking place in 3GPP Release 13. EU provides two options for LBT schemes: Frame-Based Equipment (FBE) and Load-Based Equipment (LBE) as seen in Figure 4.
Figure 4. LBT supported by ETSI
Transceivers run on fixed timing with a fixed frame period. Once every frame period, at the end of an idle frame, FBE performs clear channel assessment (CCA) on an operating channel. If the channel is clear, data is transmitted immediately at the beginning of the next frame through the channel. But if it is occupied, another CCA is performed during the next frame period.
LBE performs CCA whenever there is data to transmit. If the channel is clear, data is transmitted immediately. But, if occupied, it attempts to transmit after backoff during the extended CCA (ECCA).
Compared to FBE, LBE is relatively similar to WiFi. But, unlike WiFi that adopts exponential backoff, it adopts fixed linear backoff with fixed size of contention window, which keeps channel access opportunities of WiFi still very low when channels are over-loaded. WiFi performs random backoffs in the event of data collision, and makes contention window larger, consequently making channel access opportunities drop when channels are over-loaded. On the other hand, LBE keeps fixed window size ranges, and so the opportunities remain unaffected even when channels are over-loaded. For this reason, 3GPP LAA is trying to make window size ranges in LBE variable in its LBT standardization effort.
Cost
LTE-U/LAA small cells require installation of new 5 GHz LTE hardware (HW). Introducing new LTE-U/LAA small cells (small RRH, Pico, etc.) in the legacy LTE network is obviously expensive.
Device
LTE-U/LAA requires new 5 GHz LTE HW on devices, which makes all devices available in the market now incompatible. To use LTE-U/LAA service, vendors will have to release LTE-U/LAA-compatible devices, and users will have to purchase them.
HARQ
LTE uses licensed bands where transmitters and receivers work on exact timing. However, LAA works on LBT mechanism in unlicensed bands where channel access opportunities are uncertain. So, HARQ should be adjusted accordingly for more effective operation. In traditional LTE, HARQ ACK feedback has to be delivered within fixed HARQ cycle, and only synchronous HARQ is accepted in uplink (UL). However, asynchronous and adaptive HARQ can be considered in LAA.
Standardization Status
Efforts for LAA standardization are being made in 3GPP Release 13. LAA was approved as a Work Item (WI) (Licensed-Assisted Access to Unlicensed Spectrum) for Release 13 in June 2015, and the standardization process will be completed in June 2016. Release 13 defines specifications for fair LTE-WiFi co-existence in downlink (DL) only, and the same in UL will be discussed in Release 14.
3GPP LAA has defined 4 different LBT categories and is evaluating them. Of all the categories, ‘Category 4’ is LBT with random back-off with variable size of contention window (instead of fixed window size in LBE in Figure 4). This type of LBT offers channel access mechanism that is most similar to traditional WiFi, and so is likely to become a most promising fair access solution.
2.1.2 LTE - WiFi Link Agregation (LWA)
LWA, capable of leveraging legacy devices and base stations, emerged as an alternative to LTE-U/LAA which requires new 5 GHz LTE-enabled device and small cells for unlicensed band use.
For LTE traffic transmission, LWA uses unlicensed bands just like LTE-U/LAA, but transmission is made through WiFi unlike LTE-U/LAA. This means LWA does not need new LTE-enable 5 GHz HW, and it can transmit LTE traffic through WiFi APs connected to LWA base stations. At this time, the WiFi APs can use LTE core network functions (e.g. authentication, security, etc.) without a dedicated GW - all that without disturbing native WiFi APs even slightly. |
|
|
LWA architecture consists of LWA eNB, LWA-aware WiFi AP and LWA UE (Figure 5). LWA eNB and WiFi AP can be collocated or non-collocated. If non-collocated, data is delivered through IP tunnel between them.
LWA eNB performs scheduling for PDCP packets on PDCP layer, and transmits some over LTE and others over WiFi via WiFi AP after encapsulating them in WiFi frames. All the packets received, over either LTE or WiFi, are then aggregated at PDCP layer of the LWA UE. WiFi APs are connected to LWA eNBs, and report information on channel conditions to the LWA eNB, which then determines whether to have the APs work for LWA purpose or not based on the information reported. LWA eNB can improve LTE performance by managing radio resources in real time according to the RF and load conditions of both LTE and WiFi. A WiFi AP can work as a native WiFi AP while not serving LWA purpose.
Figure 5. LWA: conceptual architecture
Unlike LTE-U/LAA, LWA uses LTE on LTE bands, and WiFi on WiFi bands. This eliminates potential fairness or regulations issues on WiFi bands. However, as LTE data has to be split at eNB and then aggregated at UE, all involving nodes like eNB, WiFi AP and UE have to be LWA-enabled. Of course LWA architecture, protocol and operations will have to be defined as well. Below, we will explore potential issues and the current status of standardization of LWA.
Cost
Unlike LAA, new HW is not required, and existing eNBs and WiFi APs can become LWA-enabled with SW upgrade – a much more economical option than LAA which needs installation of new small cells, especially in case of large-scale deployment. But, a drawback to this solution is investment costs needed in case less-capable eNBs/small cells and WiFi APs needs to be replaced, or in case native WiFi APs (operator-deployed, user-deployed, municipal Wi-Fi, etc.) cannot be used. The costs may not as high as in LTE-U/LAA, but still can be significant.
Device
PDCP re-ordering and PDCP aggregation features should be added to UE. UE can utilize currently available LTE and WiFi modems. So, legacy UEs can also become LWA-compatible, but only if their SW are upgradeable.
Charging
A way to collect charging information for LTE traffic delivered over WiFi and a new charging policy will have to be secured.
Standardization Status
Efforts for LWA standardization are being made in 3GPP Release 13. LWA was approved as a WI (LTE-WLAN Radio Level Integration and Interworking Enhancement) for Release 13 in June 2015, and the standardization process will be completed in March 2016.
LTE and WiFi integration architecture so far have always required WiFi-specific core network nodes and interfaces (as shown in dotted lines in Figure 6). However, LWA is different as LTE and WiFi are aggregated at radio link level. Standardization for LWA, including protocol architecture, solutions for aggregating data at PDCP layer, signaling and interfaces between eNB and WiFi AP, etc., is in place now.
Figures 6 and 7 show the network architecture and protocol architecture of LWA being discussed by 3GPP.
Figure 6. LWA network architecture (non-collocated case)
Figure 7. LWA protocol architecture (non-collocated case, user plane)
A new interface called Xw was defined for communication between eNB and WiFi AP. With Xw, which is pretty similar to X2, user data is delivered through an IP tunnel (GTP tunnel) while control messages are delivered as Xw-AP messages over SCTP connection
Upon arriving at eNB, DL user traffic is split on PDCP layer and then forwarded over LTE and WiFi. Some PDCP packets are delivered via data radio bearer (DRB) over the LTE radio link, and others, destined for WiFi, are delivered to WiFi AP by eNB, which adds a DRB ID to the packets to indicate which DRB they belong to and delivers the LWA PDUs to WiFi AP through the IP tunnel established over Xw. WiFi AP then sets Ethertype as PDCP and forwards the LWA PDU to LWA UE over 802.11 interface. Upon receiving 802.11 frames, LWA UE forwards the frames to LTE PDCP layer if Ethertype is set PDCP. PDCP layer then collects PDCP packets, received from LTE and WiFi, that belong to the same LWA bearer by checking their DRB IDs, and aggregates them through re-ordering. Defining of LWA adaptation protocol (LWAAP) as 3GPP TS 36.360 is in place to support these LWA operations.
Also open items like RRC details, security details, UE capabilities, PDCP feedback, etc are under discussions for LWA specification.
2.2 IETF-based LTE -WiFi Aggregation
In case of LTE-WiFi aggregation solutions led by 3GPP, aggregation takes place at radio link level. However, it takes at TCP level in case of MPTCP Proxy-based LTE-WiFi aggregation solutions led by IETF MPTCP WG.
The main purpose of the WG was to transmit data using as many paths as possible while still working with the existent Internet environment in a stable way, without causing any changes in existing Internet infrastructure or applications. For this purpose, TCP protocol, a transport layer protocol, was extended to MPTCP. Legacy TCP uses only one path even when there are more than one path between UE and server. On the other hand, MPTCP can establish multiple paths, and send data through them concurrently (Figure 8).
Figure 8. IETF MPTCP (source: Netmanias Blog)
MPTCP functions are performed by MPTCP client and MPTCP server. Smartphones (UEs) with built-in LTE and WiFi modems, and MPTCP Proxy servers (as legacy TCP is embedded in most application servers, yet) are considered most MPTCP-friendly clients and servers, respectively.
2.2.1 MPTCP Proxy
MPTCP network, being an overlay network, is not affected by the types of underlying access/IP network. This empowers LTE operators to aggregate LTE and WiFi simply by adding MPTCP Proxy and upgrading software on UE, without need of replacing/changing the legacy network infrastructure (LTE network, WiFi network and IP infrastructure) (Figure 9). It also gives the operators freedom to use even public/private WiFi APs and 3rd-party WiFi APs as well as their own WiFi APs. MPTCP Proxy-based LTE-WiFi aggregation is considered very cost-effective in that it is readily deployable in commercial networks with minimum investment in infrastructure, and can still improve data speeds and QoE. |
|
|
In Korea, the big 3 operators released 3-Band CA capable of up to 300 Mbps in January 2015, and have been testing LTE-U and LWA capable of 450 Mbps ~ 600 Mbps since then. However, the two solutions have not been commercialized yet due to technological immaturity, high costs of replacing existing LTE/WiFi equipment, etc.
To cope with the circumstances, all 3 operators introduced MPTCP Proxy-based LTE-WiFi aggregation service in last June, for enhancement of LTE speeds. Specifically, KT launched ‘GiGA LTE’ service that supports up to 1Gbps by means of 3-band LTE-A and GiGA WiFi combination utilizing MPTCP Proxy (Figure 10), followed by ‘band LTE WiFi’ by SK Telecom and ‘Giga Multi-Path’ by LG U+. This indicates that MPTCP Proxy technology can be recognized as one of the most feasible, readily deployable technologies that can be commercialized across the nationwide network of the nation at minimum costs.
Figure 9. No change in existing wireless infra
Figure 10. KT's GiGA LTE architecture (source: IETF 93, MPTCP WG, Re-illustrated by Netmanias)
Now, let’s see what the current status of standardization of MPTCP Proxy is, and what potential issues the technology is facing.
Standardization Status
Certainly, MPTCP Proxy is probably the most cost-effective solution, but the slow standardization process and technical immaturity of the technology have led operators to develop their own proprietary solutions.
Standardization for MPTCP began in 2009 when IETF MPTCP WG was formed. Core specifications are defined in RFC 6824 (TCP Extensions for Multipath Operation with Multiple Addresses) released in January 2013. RFC 6824 has been recently supplemented with MPTCP signaling. MPTCP WG has discussed data center, cellular/WiFi offload and MPTCP Proxy as user cases. Specifically, MPTCP Proxy-related topics included MPTCP Proxy mode, requirements for MPTCP Proxy, etc.
MPTCP Proxy can be either in on-path MPTCP Proxy or off-path MPTCP Proxy mode, depending on where and how MPTCP Proxy will work (Figure 11). In on-path mode, MPTCP Proxy is located somewhere on a ‘common’ routing route shared by LTE and WiFi traffic and so the Proxy is transparent to UE. This allows UE to establish multipath using destination server's IP address. In off-path mode, MPTCP Proxy is located on the routing route of ‘only one’ network traffic - either LTE or WiFi. If it is only on the direct route of LTE network traffic, any WiFi network (owned by a serving network operator or not) can be used for WiFi traffic. For subflow routed through WiFi network, UE first obtains the IP address of MPTCP Proxy, and has the WiFi traffic transmitted towards MPTCP Proxy.
Figure 11. Example of MPTCP Proxy deployment model: on-path vs. off-path
(source: draft-deng-mptcp-proxy-01)
Table 1 lists requirements for MPTCP Proxy currently under review.
Table 1. Requirements for MPTCP Proxy
Issues
Now we will look into potential MPTCP Proxy-related issues. Although standardization for MPTCP Proxy has already began, detailed architecture and deployment scenarios of MPTCP Proxy-based aggregation have not been specified yet. So, here we will define the architecture as seen in Figure 12.
In Figure 12, MPTCP Manager manages MPTCP Proxy server, and support off-path behaviors of MPTCP Proxy. M-UE obtains MPTCP Proxy information by requesting MPTCP for a MPTCP Proxy list, and creates LTE and WiFi subflow to be sent to a specified MPTCP Proxy. This re-direction scheme gives operators some flexibility in deployment of MPTCP proxies and in failover of MPTCP proxy failure (e.g. establishing a session with other proxy).
Figure 12. High-level architecture for MPTCP Proxy-based LTE-WiFi aggregation
LTE and WiFi have their own networks, and so MPTCP Proxy (or MPTCP Manager) should interwork with operators’ policy servers in order to perform flow control on traffic forwarded to each network. Also, for the traffic forwarded through WiFi network, charging information should be reported as well – another reason why interworking with operators’ servers is needed.
Service provision should not be interrupted even in the event MPTCP Proxy servers fail. And, M-UE should be able to bypass all failed servers by directly establishing a TCP session to the destination server, for uninterrupted service provision.
Figure 13. MPTCP Proxy failover
MPTCP Proxy should be able to convert the IP addresses of multiple paths used by M-UE into its IP address for establishing a TCP session with the application server. NAT feature should still work properly even when the IP address types (IPv4/IPv6) for LTE and WiFi networks are different, or the IP address type of UE is different from that of the application server. For example, UE should still work whether it accesses to its serving LTE operator's WiFi AP and obtains both IPv6 and IPv4 addresses, or accesses to a third-party’s WiFi AP and obtains only IPv4 address.
OS in UE should be able to support MPTCP, but it is totally up to vendors. So, whether operators can control/support this or not is questionable.
MPTCP Proxy-based LTE-WiFi aggregation is readily deployable in legacy LTE and WiFi networks without any modification to the networks, and can even work with LTE RAN where LTE-U, LAA or LWA is employed. It is also compatible with any legacy WiFi APs, whether public, private or 3rd party WiFi AP. Although this document discusses only use cases for LTE and WiFi networks, it is a flexible solution that can still be employed in 3G and WiFi networks.
3. Summary and Future Trends
We have so far reviewed solutions designed for mobile operators to improve LTE QoE using unlicensed bands. To recap (see Table 2 for full list):
LTE-U and LWA-enabled chipsets already hit the market last year, and many operators (LGU+, Verizon, T-Mobile, NTT DoCoMo, etc.) have completed demonstration of LTE-U or LAA last year. This year will likely see release of LTE-U-enabled phones and LAA chipset, and launch of commercialized LTE-U/LAA/LWA. Also, there was a solution introduced by a vendor, designed to use only unlicensed bands for LTE.
Despite slow progress in standardization for MPTCP Proxy, commercialization efforts have been made diligently. All the big 3 operators already commercialized MPTCP Proxy in June 2015, and others are likely to join them in near-future.
With cells getting smaller and WiFi ecosystem expanding drastically, both cellular and WiFi are in instant need of additional spectrum. As development of LTE-WiFi aggregation solutions has been fueled by 3GPP and IETF, more discussions on shared access spectrum are also expected soon.
Long-time candidates for this shared access spectrum are 2.3 GHz and 3.5 GHz. In 2015, FCC declared its intention to make its 150 MHz in 3.5 GHz available for mobile broadband purpose. Verizon also shared its plan to support LTE-U in both 5GHz and 3.5GHz. Technologies for aggregating licensed and unlicensed bands are speculated to prevail even further.
Table 2. Comparison of aggregation technologies (blue: 5 GHz, yellow: LTE Band, character: MAC/PHY)
Excellent report. There are other WiFi access solutions such as ePDG which have enjoyed standardization since 3GPP Release 8 and earlier WiFi solutions such as I-WLAN, PDG, and the earlier cousin of ePDG... TTG and even earlier solutions such as UMA. There is also Trusted Access/TWAG that was introduced in Release 11. Both ePDG and TWAG have been significantly enhanced in Release 12 and 13 to support network based IP flow mobility which allows for switching of IP flows between RATs and also allow for dedicated bearer and multiple APN support key to supporting IMS. There are other IETF solutions including DSMIP (and that was addressed in 3GPP under non-3GPP access as S2c). It will be interesting to see how operators try to leverage WiFi... many of these will continue and it's not an all or none approach.
super clarification...keep it up.
thanks for the document, clear and understandable...
Very useful overview. Specifically, the overview of multipath TCP concept is useful.
As described in document, it seems that WiFI AP has to be provided by the operator (like AT&T), because AP has to cooperate with eNodeB. LWA can not work on the WiFi AP I bought by myself. Am I correct?
good report and technical coverage
good and didactic report.
Excellent document.....very clear and informative