Let's talk about LIPA

I recently read somewhere that 3GPP stage 2 specifications for Local IP Access (LIPA) are in pretty good shape by now so I thought it was time to take a look to understand the basic principle that is taken forward. So here’s my summary:

First of all, the general idea of LIPA is to enable a UMTS or LTE device to access the local IP network that a femtocell is connected to. In other words, when a user has a femtocell at home or in the office, mobile devices can use LIPA to access devices that are connected to the local network such as connected TVs, video and picture libraries on computers, NAS servers, etc. over the femtocell.

A number of different approaches were studied in 3GPP and the different options can be found in 3GPP TR 23.829. The selected solution that now goes into Technical Specification (TS) documents can be found in 7.2.1, where it says that LIPA solution 1 variant 1 described in 5.2 has been selected. Note that TR 23.829 also treats SIPTO, which stands for Selective IP Traffic Offload, but that’s something different and a topic for another post.

The selected solution for LIPA works as follows: To get access to devices on a local network to which a femto is connected to, the mobile device can use a special APN. The APN tells the SGSN (UMTS) or the MME (LTE) that the mobile device wants to get a connection to the local network and not to the network operator’s core network. This way, the solution is backwards compatible to current devices, i.e. LIPA will work without any software modifications on devices. Optionally, a LIPA flag is defined that can be sent by the mobile device during the PDP context establishment (UMTS) or the Default Bearer activation (LTE) for the same purpose. This, however, requires some additional software in the mobile device.

For simultaneous access to the local network and the Internet, two solutions are given in the TR. First, the mobile could have two PDP contexts (UMTS) or two default bearers (LTE), one that terminates in the local network and one that goes through the core network to the GGSN/P-GW. Also the TR specifically says that the in case Internet connectivity is available through the local network, LIPA does allow the UE to reach the Internet this way. This might be desirable in many cases as it nicely offloads Internet traffic as well but has some consequences for IP based network operator services such as MMS as these can’t be reached that way.

Further, the TR specifies a (logical) Local Gateway (L-GW) in the femtocell that acts as a GGSN (UMTS) or P-GW (LTE). Once the LIPA PDP context / default bearer is established data flows directly to the L-GW and from there into the local network without traversing the radio access network or the core network of the network operator.

Control of the LIPA PDP context / default bearer, however, remains with the SGSN / MME in the core network. In other words, authentication, authorization and security procedures remain with the network operator. An interesting result of this architecture is how incoming packets from the local network are forwarded to a mobile device that is in UMTS Idle/Cell- or URA-PCH state or LTE Idle state respectively. In these states the mobile device needs to be paged first and has to re-establish an RRC (Radio Resource Control) connection before the data can be forwarded. The paging remains a responsibility of the SGSN/MME and hence, the femtocell needs to send a notification to the SGSN/MME which then pages the mobile device via the femtocell. Once the RRC connection is established again, the data packet is forwarded.

Mobility of the LIPA bearer between femtocells, e.g. when several femtocells are deployed in an office is discussed in the TR, but the conclusion is that this part will not be specified in 3GPP Release 10. In other words, in a first version of LIPA, the bearer is lost when the mobile looses contact to the femtocell.

And finally, here’s a list of some of the specs that will be expanded for LIPA in Release 10: TS 23.060, TS 23.203 and TS 23.401.

There we go, this should be enough to get you started once you want to find out more about LIPA. The question for me is if it will find traction!? Today, smartphones with  operating systems such as Symbian, Android, iOS, etc. already have a Wi-Fi chip build in and the OS is capable of switching between a known Wi-Fi network and 3G connectivity automatically. Many Symbian applications can even be configured to use a specific APN / Wi-Fi network, e.g. a podcast catcher application can always and exclusively use the Wi-Fi network at home if configured that way. In other words, local access that LIPA wants to give mobile devices is already done over Wi-Fi today. As always, any thought on the topic are greatly appreciated.

Comments

[Benjamin Lovell]

Agreed, I don't see this as very useful for your average smartphone UE as WiFi already provides this at greater speed and in a more straight forward manner.

Things like sensor nodes or other non-classic UE types that don't use WiFi *might* make use of it but would they group in a small enough area to use a pico/microcell? Any scenario I can think of w/o WiFi seems that it would likely be spread out too much to use anything but a macro tower.

I can't think a really good use case at the intersection of no WiFi, covered by one or more pico/micro cells, efficient local network access needed, mobility not needed.

Internet offload does seem clutch in a vast number of use cases tho.

[sameer]

The whole point of implementing [or not] would have to be providing better radio access to the devices in the vicinity of each other. So for example if HNB/eHNB can prove to be better at providing radio access meaning 1> higher speed 2> better range/coverage 3> better over the air QoS 4> encryption 5> economy of deployment/management etc, than a network of wifi access points; then it is worth considering creating architecture play around HNB/eHNB with all kinds of devices talking to each other over 3GPP access.

Once that need is generated then LIPA/SIPTO just try to solve the problem of management of IP I think.

So IMO, 3GPP access has to prove far to beneficial than already well established Wifi for SIPTO/LIPA to be even considered worth implementing.