Showing posts sorted by date for query service tunnel. Sort by relevance Show all posts
Showing posts sorted by date for query service tunnel. Sort by relevance Show all posts

Tuesday, 17 January 2023

Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)

3GPP Release 17 introduced a new feature called AKMA (Authentication and Key Management for Applications), the goal of which is to enable the authentication and generation of application keys based on 3GPP credentials for all UE types in the 5G System, especially IoT devices, ensuring to bootstrap the security between the UE and the applications in the 5G system.

3GPP TR 21.917 has an excellent summary as follows:

Authentication and key management for applications based on 3GPP credential in 5G (AKMA) is a cellular-network-based delegated authentication system specified for the 5G system, helping establish a secure tunnel between the end user and the application server. Using AKMA, a user can log in to an application service only based on the 3GPP credential which is the permanent key stored in the user’s tamper-resistant smart card UICC. The application service provider can also delegate the task of user authentication to the mobile network operator by using AKMA. 

The AKMA architecture and procedures are specified by SA3 in TS 33.535, with the related study showing how its general principles are derived documented in TR 33.835. The AKMA feature introduces a new Network Function into the 5G system, which is the AKMA Anchor Function (AAnF). Its detailed services and API definitions are specified by CT3 in TS 29.535. Earlier generations of cellular networks include two similar standards specified by SA3, which are generic bootstrapping architecture (GBA) and battery-efficient security for very low throughput machine type communication devices (BEST). Since the AKMA feature is deemed as a successor of these systems, the work is launched by SA3 without the involvement of stage 1.

In the latest issue of 3GPP Highlights Magazine, Suresh Nair, 3GPP Working Group SA3 Chair, Saurabh Khare & Jing Ping (Nokia) has explained the AKMA procedure. The article is also available on 3GPP website here. The article lists the following as AKMA advantages:

  • Since the AKMA framework uses authentication and authorization of the UE leveraging the PLMN credentials stored on the USIM, this becomes as strong as the network primary authentication and subsequent keys derived further to UE and Application Function (AF) interface.
  • The Application Functions can leverage the authentication service provided by the AKMA Anchor Function (AAnF) without additional CAPEX and OPEX.
  • The architecture provides a direct interface between the UE and the AF where a customized application-specific interface can be built, including the key management, key lifetime extension, etc.

The Journal of ICT Standardization has a paper on Authentication Mechanisms in the 5G System. It details AKMA and much more. It's a great place to start for anyone new looking to understand different 5G Authentication Mechanisms. 

Related Posts

Wednesday, 1 April 2020

A Look into 5G Virtual/Open RAN - Part 2

In the first blog post of this series the different virtual RAN functions, interfaces and protocols have been discussed. Now it is time to have a look at a set of procedures that are required for the establishment of an UE connection in virtual 5G RAN.

The Big Picture

In 5G standalone RAN the crucial elements for user plane payload transport of an UE connection are  GTP/IP transport tunnels and a dedicated radio bearer on the radio interface.

When looking at the 5G RAN there are two of such tunnels: one on NG-U (aka N3) that is controlled by NGAP, and one on F1-U that is controlled by F1AP - see figure 1.

On behalf  of these two tunnels payload data can be transported between the 5G core network User Plane Function (UPF) to the gNB Distributed Unit (gNB-DU) and vice versa. For the transport over the 5G RAN fronthaul (realized e.g. as eCPRI) and across the radio interface a dedicated radio bearer (DRB) for the user plane transport must be configured by the gNB Central Unit for the Control Plane (gNB-CU CP).

As in LTE it is the RRC protocol that establishes this DRB. However, due to the virtualization the different protocol layers for the air interface are also distributed and the gNB-DU is in charge of all the lower layer PHY/RLC/MAC parameters (e.g the c-RNTI), while the gNB-CU CP assigns higher layer parameters of PDCP and RRC like the DRB-ID. Since only the gNB-CU CP can send downlink RRC messages to the UE the lower layer parameters from the DU first need to be sent in uplink direction to the gNB-CU CP.

Beside this parameter exchange the F1AP is also responsible for the tunnel management of the F1-U Tunnel.

The downlink tunnel endpoint information is provided by the gNB-DU using F1AP, but the uplink tunnel endpoint terminates at the gNB-CU UP and thus, its endpoint parameters are received by the gNB-CU CP when it exchanges information with the gNB-CU UP on behalf of the E1AP protocol.

Figure 1: Network Functions, Protocols and Parameters involved in Setup of User Plane Data Transmission Resources
(click on the image to see full size)
A similar situation we see for the NG-U tunnel that is controlled by NGAP, the protocol for communication between gNB-CU CP and the Access and Mobility Management Function (AMF) in the 5G core. Neither the gNB-CU CP nor hte AMF have direct access to the NG-U tunnel endpoints. Hence, E1AP is used again to transmit the downlink tunnel parameters to the gNB-CU CP while the uplink tunnel endpoint parameters must be sent by the UPF to the Session Management Function (SMF) using the Packet Forwarding Control Protocol (PFCP) and later by the SMF to the AMF over the service-based interface where the tunnel endpoint parameters are embedded in a JavaScript Object Notation (JSON) container.

By the way, JSON is a quite generic format for exchanging and storing different kind of data. Between the AMF and the SMF JSON is used to transport Non-Access Stratum Session Management messages (defined in 3GPP 24.501).

The Ladder Diagram

Having the Big Picture in mind it is now easier to look at the ladder diagram with the individual RAN messages for UE connection setup - shown in Figure 2.

It looks complicated, because the F1AP messages carry RRC plus NAS messages in uplink and downlink direction, but when understanding the underlying logic it is easy.

Figure 2: 5G VRAN Successful UE Connection Setup
(click on the image to see full size)

The very first step (in the figure: step 0) is the random access procedure executed on the MAC layer involving the UE and the gNB-DU.

After successful random access the UE sends the NR RRC Setup Request message. This is the Initial UL RRC Message transported by the F1AP from the gNB-DU to the gNB-CU CP. Actually the F1AP carries PDCP transport blocks and inside the PDCP the NR RRC messages are found, but to keep it simple I do not show the PDCP header in the ladder diagram.

Beside RRC Setup Request there are also some other initial NR RRC messages and RRC response messages possible (see step 1 and 2).

More RRC messages are transported over F1AP until the RRC Connection establishment is complete.

The NR RRC Setup Complete message also transports the initial NAS message and the reception of this message by the gNB-CU CP triggers the setup of a F1AP UE context. The concept of UE context management in F1AP is the same as in NGAP or - when looking back into the E-UTRAN - in S1AP.

The GTP/IP transport tunnel on F1-U is established during F1AP UE Context Setup assisted by E1AP Bearer Context Setup procedure that provides the necessary tunnel endpoint parameters.

In the same manner the NG-U tunnel is established by the NGAP Initial UE Context Setup procedure.

Additional NAS messages (especially for session management) and NR RRC Reconfiguration are exchanged to establish the end-to-end UE connection through the core network. And that's it.

Related Posts:

Friday, 22 November 2019

5G Call Drops in EN-DC: A Thread for Service Quality?

As explained in the post about EN-DC setup the addition of 5G NR radio resources to an ongoing LTE connection provides additional bandwidth for user plane data transmission. And it seems to be fair to say that at least in social media today 5G speed test results, especially throughput measurements, are treated as the benchmark for EN-DC service performance. Hence, it is also logical that a loss of the physical 5G radio link (5G drop) could have a serious impact on user experience.

I write "could", because as a matter of fact many 5G drops will not be recognized by subscribers using non-realtime services including HTTP streaming.

Due to the dual connectivity of LTE Master eNodeB (MeNB) and Secondary gNodeB (SgNB) the signaling trigger points indicating a 5G drop are also a bit more complex compared to what we know from LTE. Indeed, both network nodes are able to release 5G radio resources abnormally using three different X2AP message flow scenarios as shown in figure 1.

Figure 1: Three Basic Signaling Flows for Abnormal Release of 5G Radio Resources

Which of these individual message flows will be found in the trace data depends on which of the two base stations is the first one that detects a problem on the 5G radio link.

A particular case that is seen quite often in live networks is illustrated in figure 2.

Figure 2: 5G Drop due to SGC Failure in UE

Here the trigger is a LTE RRC SCG Failure Information NR message sent by the UE to the MeNB. Thus, the MeNB requests the release of 5G radio resources, which is acknowledged and executed by the SgNB.

In addition (not show in the figures) also the GTP/IP-Tunnel for user plane transport between S-GW and gNB is released by the MeNB after successful completion of the X2AP SgNB Release procedure.

For the UE the 5G drop is not as serious as a drop of the LTE radio connection would be. It is just a fallback on plain LTE, so to say. And after the switching the GTP/IP-Tunnel back to a downlink endpoint at the eNB 4G payload transmission continues.

The longer the overall duration of the radio connection the higher is the risk that the 5G radio resources are lost during an EN-DC call. One of my favorite cases is a subscriber with a radio connection that last a bit more than two and a half hours - see figure 3.

Figure 3: Location Session Record of a Single Subscriber indicating a total number 340 SgNB Drops over 2:33 Hours

Thanks to the smart algorithms of NETSCOUT's TrueCall geolocation engine there is high confidence that she or he sits in an indoor environment, but is served by an outdoor 5G cell. Thus, the penetration loss of the 5G signal is significant. Due to the higher frequency the path loss has also higher impact on the 5G than on the 4G radio signal. This seems to be the main reason why the 5G radio link drops as often as 340 times, which leads to an overall 5G (SgNB) Drop Rate of 83% for this connection.

However, the impact on the subscriber experience might not be a serious one as a different KPI, the 5G EN-DC Duration Rate indicates. According to the Duration Rate 99.99% of all the time 5G radio resources have been available for the subscriber. This is possible, because as also shown in figure 2 within a relatively short time new 5G radio resources are allocated again to this connection. Even if the subscriber is watching e.g. a Netflix video the buffering of already downloaded data on the end user device should be sufficient to conceal the short interruption of the data transfer over 5G resources.

With rising amount of EN-DC traffic it might be rather problematic for the network to handle the additional signaling load originating from the frequent 5G additions and releases. In extreme cases this may even lead to congestion due to CPU overload in RAN nodes or virtual network functions.

For realtime services like Voice over New Radio (VoNR) the entire situation changes. Here even short interruptions of the user plane radio transmission can be perceived by subscribers so that the above discussed 5G Duration Rate KPI will become insufficient to estimate the service quality. Hence, this will drive the demand for a fully integrated view of 5G RAN and Core KPIs covering both, signaling and application quality. 

Tuesday, 5 December 2017

Summary of 3GPP Release-14 Work Items


With all focus on 5G (Release-15), looks like Rel-14 has been feeling a bit neglected. There are some important updates though as it lays foundation for other services.

3GPP used to maintain Release Descriptions here for all different releases but have stopped doing that since 2014. For Release-14, a new document "3GPP TR 21.914: Release 14 Description; Summary of Rel-14 Work Items" is now available here.

An executive summary from the document:

Release 14 focusses on the following items:
  • Improving the Mission Critical aspects, in particular with the introduction of Video and Data services
  • Introducing the Vehicle-to-Everything (V2X) aspects, in particular the Vehicle-to-Vehicle (V2)
  • Improving the Cellular Internet of Things (CIoT) aspects, with 2G, 3G and 4G support of Machine-Type of Communications (MTC)
  • Improving the radio interface, in particular by enhancing the aspects related to coordination with WLAN and unlicensed spectrum
  • A set of uncorrelated improvements, e.g. on Voice over LTE (VoLTE), IMS, Location reporting.


The continuation of this document provides an exhaustive view of all the items specified by 3GPP in Release 14.

I have blogged about the Mission Critical Communications here. 3GPP has also done a webinar on this topic which can be viewed here. I like this slide below that summarizes features in different releases.

Then there are quite a few new features and enhancements for V2X. I have blogged about sidelink and its proposed extensions here.

From the document:

The Work Item on “Architecture enhancements for LTE support of V2X services (V2XARC)”, driven by SA WG2, specifies the V2X architectures, functional entities involved for V2X communication, interfaces, provisioned parameters and procedures in TS 23.285.
Figure above depicts an overall architecture for V2X communication. V2X Control Function is the logical function defined for network related actions required for V2X and performs authorization and provisioning of necessary parameters for V2X communication to the UE via V3 interface.

A UE can send V2X messages over PC5 interface by using network scheduled operation mode (i.e. centralized scheduling) and UE autonomous resources selection mode (i.e. distributed scheduling) when the UE is "served by E-UTRAN" while a UE can send V2X messages over PC5 interface only by using UE autonomous resources selection mode when the UE is "not served by E-UTRAN". 

Both IP based and non-IP based V2X messages over PC5 are supported. For IP based V2X messages over PC5, only IPv6 is used. PPPP (ProSe Per-Packet Priority) reflecting priority and latency for V2X message is applied to schedule the transmission of V2X message over PC5.

A UE can send V2X messages over LTE-Uu interface destined to a locally relevant V2X Application Server, and the V2X Application Server delivers the V2X messages to the UE(s) in a target area using unicast delivery and/or MBMS (Multimedia Broadcast/Multicast Service) delivery.

Both IP based and non-IP based V2X messages are supported for V2X communication over LTE-Uu. In order to transmit non-IP based V2X messages over LTE-Uu, the UE encapsulates the V2X messages in IP packets.

For latency improvements for MBMS, localized MBMS can be considered for localized routing of V2X messages destined to UEs.

For V2X communication over LTE-Uu interface, the V2X messages can be delivered via Non-GBR bearer (i.e. an IP transmission path with no reserved bitrate resources) as well as GBR bearer (i.e. an IP transmission path with reserved (guaranteed) bitrate resources). In order to meet the latency requirement for V2X message delivery, the following standardized QCI (QoS Class Identifier) values defined in TS 23.203 can be used:
  • QCI 3 (GBR bearer) and QCI 79 (Non-GBR bearer) can be used for the unicast delivery of V2X messages.
  • QCI 75 (GBR bearer) is only used for the delivery of V2X messages over MBMS bearers. 


There are updates to cellular IoT (CIot) which I have blogged about here.

There are some other interesting topic that are enhanced as part of Release14. Here are some of them:
  • S8 Home Routing Architecture for VoLTE
    • Robust Call Setup for VoLTE subscriber in LTE
    • Enhancements to Domain Selection between VoLTE and CDMA CS
    • MBMS improvements
    • eMBMS enhancements for LTE
    • IMS related items
    • Evolution to and Interworking with eCall in IMS
    • Password-based service activation for IMS Multimedia Telephony service
    • Multimedia Priority Service Modifications
    • Enhancements to Multi-stream Multiparty Conferencing Media Handling
    • Enhancement for TV service
    • Improved Streaming QoE Reporting in 3GPP (IQoE)
    • Quality of Experience (QoE) Measurement Collection for streaming services in UTRAN
    • Development of super-wideband and fullband P.835
    • Enhancements to User Location Reporting Support
    • Enhancing Location Capabilities for Indoor and Outdoor Emergency Communications
    • Further Indoor Positioning Enhancements for UTRA and LTE
    • Improvements of awareness of user location change
    • Terminating Access Domain Selection (T-ADS) supporting WLAN Access
    • Enhanced LTE-WLAN Aggregation (LWA)
    • Enhanced LTE WLAN Radio Level Integration with IPsec Tunnel (eLWIP)
    • Positioning Enhancements for GERAN
    • New GPRS algorithms for EASE
    • RRC optimization for UMTS
    • Multi-Carrier Enhancements for UMTS
    • DTX/DRX enhancements in CELL_FACH
    • LTE radio improvements
    • Enhancements on Full-Dimension (FD) MIMO for LTE
    • Downlink Multiuser Superposition Transmission for LTE
    • Performance enhancements for high speed scenario in LTE
    • Control and User Plane Separation (CUPS) of EPC nodes
    • Paging Policy Enhancements and Procedure
    • Shared Subscription Data Update
    • Service Domain Centralization
    • Control of Applications when Third party Servers encounter difficulties
    • PS Data Off Services
    • Enhancement to Flexible Mobile Service Steering 
    • Sponsored data connectivity improvements
    • Group based enhancements in the network capability exposure functions
    • Improved operator control using new UE configuration parameters
    • Charging and OAM stand alone improvements
    • Rel-14 Charging
    • ...

    Further Reading:


    Sunday, 3 September 2017

    5G Core Network, System Architecture & Registration Procedure

    The 5G System architecture (based on 3GPP TS 23.501: System Architecture for the 5G System; Stage 2) consists of the following network functions (NF). The functional description of these network functions is specified in clause 6.
    - Authentication Server Function (AUSF)
    - Core Access and Mobility Management Function (AMF)
    - Data network (DN), e.g. operator services, Internet access or 3rd party services
    - Structured Data Storage network function (SDSF)
    - Unstructured Data Storage network function (UDSF)
    - Network Exposure Function (NEF)
    - NF Repository Function (NRF)
    - Network Slice Selection Function (NSSF)
    - Policy Control function (PCF)
    - Session Management Function (SMF)
    - Unified Data Management (UDM)
    - Unified Data Repository (UDR)
    - User plane Function (UPF)
    - Application Function (AF)
    - User Equipment (UE)
    - (Radio) Access Network ((R)AN)

    As you can see, this is slightly more complex than the 2G/3G/4G Core Network Architecture.

    Alan Carlton, Vice President, InterDigital and Head of InterDigital International Labs Organization spanning Europe and Asia provided a concise summary of the changes in 5G core network in ComputerWorld:

    Session management is all about the establishment, maintenance and tear down of data connections. In 2G and 3G this manifested as the standalone General Packet Radio Service (GPRS). 4G introduced a fully integrated data only system optimized for mobile broadband inside which basic telephony is supported as just one profile.

    Mobility management as the name suggests deals with everything that needs doing to support the movement of users in a mobile network. This encompasses such functions as system registration, location tracking and handover. The principles of these functions have changed relatively little through the generations beyond optimizations to reduce the heavy signaling load they impose on the system.

    The 4G core network’s main function today is to deliver an efficient data pipe. The existence of the service management function as a dedicated entity has been largely surrendered to the “applications” new world order. Session management and mobility management are now the two main functions that provide the raison d’etre for the core network.

    Session management in 4G is all about enabling data connectivity and opening up a tunnel to the world of applications in the internet as quickly as possible. This is enabled by two core network functions, the Serving Gateway (SGW) and Packet Data Gateway (PGW). Mobility management ensures that these data sessions can be maintained as the user moves about the network. Mobility management functions are centralized within a network node referred to as Mobility Management Entity (MME). Services, including voice, are provided as an “app” running on top of this 4G data pipe. The keyword in this mix, however, is “function”. It is useful to highlight that the distinctive nature of the session and mobility management functions enables modularization of these software functions in a manner that they can be easily deployed on any Commercial-Off-The-Shelf (COTS) hardware.

    The biggest change in 5G is perhaps that services will actually be making a bit of a return...the plan is now to deliver the whole Network as a Service. The approach to this being taken in 3GPP is to re-architect the whole core based on a service-oriented architecture approach. This entails breaking everything down into even more detailed functions and sub-functions. The MME is gone but not forgotten. Its former functionality has been redistributed into precise families of mobility and session management network functions. As such, registration, reachability, mobility management and connection management are all now new services offered by a new general network function dubbed Access and Mobility Management Function (AMF). Session establishment and session management, also formerly part of the MME, will now be new services offered by a new network function called the Session Management Function (SMF). Furthermore, packet routing and forwarding functions, currently performed by the SGW and PGW in 4G, will now be realized as services rendered through a new network function called the User Plane Function (UPF).

    The whole point of this new architectural approach is to enable a flexible Network as a Service solution. By standardizing a modularized set of services, this enables deployment on the fly in centralized, distributed or mixed configurations to enable target network configurations for different users. This very act of dynamically chaining together different services is what lies at the very heart of creating the magical network slices that will be so important in 5G to satisfy the diverse user demands expected. The bottom line in all this is that the emphasis is now entirely on software. The physical boxes where these software services are instantiated could be in the cloud or on any targeted COTS hardware in the system. It is this intangibility of physicality that is behind the notion that the core network might disappear in 5G.


    3GPP TS 23.502: Procedures for the 5G System; Stage 2, provides examples of signalling for different scenarios. The MSC above shows the example of registration procedure. If you want a quick refresher of LTE registration procedure, see here.

    I dont plan to expand on this procedure here. Checkout section "4.2.2 Registration Management procedures" in 23.502 for details. There are still a lot of FFS (For further studies 😉) in the specs that will get updated in the coming months.


    Further Reading:

    Wednesday, 21 January 2015

    Voice over WiFi (VoWiFi) technical details

    VoWiFi is certainly a hot topic, thanks to the support of VoWiFi on iPhone 6. A presentation from LTE World Summit 2014 by Taqua on this topic has already crossed 13K views. In this post I intend to look at the different approaches for VoWiFi and throw in some technical details. I am by no means an expert so please feel free to add your input in the comments.

    Anybody reading this post is not aware of S2a, S2b, Samog, TWAG, ePDG, etc. and what they are, please refer to our whitepaper on cellular and wi-fi integration here (section 3).

    There are two approaches to VoWiFi, native client already in your device or an App that could be either downloaded from the app store or pre-installed. The UK operator '3' has an app known as ThreeInTouch. While on WiFi, this app can make and receive calls and texts. The only problem is that it does not handover an ongoing call from WiFi to cellular and and vice versa. Here are a few slides (slides 36-38) from them from a conference last year:



    The other operators have a native client that can use Wi-Fi as the access network for voice calls as well as the data when the device is connected on the WLAN.

    A simple architecture can be seen from the picture above. As can be seen, the device can connect to the network via a non-3GPP trusted wireless access network via the TWAG or via a non-3GPP untrusted wireless access network via ePDG. In the latter case, an IPSec tunnel would have to be established between the device and the ePDG. The SIM credentials would be used for authentication purposes so that an intruder cannot access ePDG and the core.

    Now, I dont want to talk about VoLTE bearers establishment, etc. which I have already done here earlier. In order to establish S2a (trusted) and S2b (untrusted) connection, the AAA server selects an APN among those which are subscribed to in the HLR/HSS. The PDN-GW (generally referred to as PGW) dynamically assigns an IP address out of a pool of addresses which is associated with this APN. This UE IP address is used by the VoWiFi SIP UA (User Agent) as the contact information when registering to the SIP soft switch (which would typically be the operators IMS network).

    If for any reason the SIP UA in the device is not able to use the SIM for authentication (needs ISIM?) then a username/password based authentication credentials can be used (SIP digest authentication).

    Typically, there would be a seperate UA for VoLTE and VoWiFi. They would both be generally registering to the same IMS APN using different credentials and contact addresses. The IMS network can deal with multiple registrations from the same subscriber but from different IP addresses (see 3GPP TS 23.237 - 'IMS Service Continuity' for details).

    Because of multiple UA's, a new element needs to be introduced in order to 'fork' the downstream media streams (RTP/RTCP packets) to different IP addresses over time.

    3GPP has defined the Access Transfer Gateway (ATGW) which is controlled by the Access Transfer Control Function (ATCF); the ATCF interfaces to the IMS and Service Centralization and Continuity Application Server (SCC AS). All these are not shown in the picture above but is available in 3GPP TS 23.237. The IMS networks in use today as well as the one being deployed for VoLTE does not have ATGW/ATCF. As a result vendors have to come up with clever non-standardised solutions to solve the problem.

    When there is a handover between 3GPP and non-3GPP networks, the UE IP address needs to be preserved. Solutions like MIP and IPSec have been used in the past but they are not flexible. The Release-12 solution of eSAMOG (see 3GPP TS 23.402) can be used but the solution requires changes in the UE. For the time being we will see proprietary solutions only but hopefully in future there would be standardised solutions available.

    3GPP TS 23.234 describes more in detail the interworking of 3GPP based system and WLAN. Interested readers can refer to that for further insight.

    Thursday, 16 December 2010

    Packet Flow in 2.5G, 3G, 3.5G and 4G




    The 'LTE Signaling' is a very interesting book just being released that is a must have for people who are involved in design, development and testing. A book that explains the basic concepts from beginning till advanced concepts and explains how different components and interfaces fit together.

    Though I havent yet read this book, I have read the earlier one titled UMTS Signaling, from the same authors that is an excellent reference for understanding Signalling in UMTS. I have no doubt that this book will be the same high quality.

    The Excerpt on Wiley's website provides complete chapter 1 which is quite detailed and the Packet flow pictures and details below is extracted from this book.
    The first stage of the General Packet Radio Service (GPRS), that is often referred to as the 2.5G network, was deployed in live networks starting after the year 2000. It was basically a system that offered a model of how radio resources (in this case, GSM time slots) that had not been used by Circuit Switched (CS) voice calls could be used for data transmission and, hence, profitability of the network could be enhanced. At the beginning there was no pre-emption for PS (Packet Switched) services, which meant that the packet data needed to wait to be transmitted until CS calls had been finished.

    In contrast to the GSM CS calls that had a Dedicated Traffic Channel (DTCH) assigned on the radio interface, the PS data had no access to dedicated radio resources and PS signaling, and the payload was transmitted in unidirectional Temporary Block Flows (TBFs) as shown in Figure 1.2.

    In Release 99, when a PDP (Packet Data Protocol) context is activated the UE is ordered by the RNC (Radio Network Controller) to enter the Radio Resource Control (RRC) CELL_DCH state. Dedicated resources are assigned by the Serving Radio Network Controller (SRNC): these are the dedicated physical channels established on the radio interface. Those channels are used for transmission of both IP payload and RRC signaling – see Figure 1.7. RRC signaling includes the exchange of Non-Access Stratum (NAS) messages between the UE and SGSN.

    The spreading factor of the radio bearer (as the combination of several physical transport resources on the Air and Iub interfaces is called) depends on the expected UL/DL IP throughput. The expected data transfer rate can be found in the RANAP (Radio Access Network Application Part) part of the Radio Access Bearer (RAB) assignment request message that is used to establish the Iu bearer, a GPRS Tunneling Protocol (GTP) tunnel for transmission of a IP payload on the IuPS interface between SRNC and SGSN. While the spreading factor controls the bandwidth of the radio connection, a sophisticated power control algorithm guarantees the necessary quality of the radio transmission. For instance, this power control ensures that the number of retransmitted frames does not exceed a certain critical threshold.

    Activation of PDP context results also in the establishment of another GTP tunnel on the Gn interface between SGSN and GGSN. In contrast to IuPS, where tunnel management is a task of RANAP, on the Gn interface – as in (E)GPRS – the GPRS Tunneling Protocol – Control (GTP-C) is responsible for context (or tunnel) activation, modification, and deletion.

    However, in Release 99 the maximum possible bit rate is still limited to 384 kbps for a single connection and, more dramatically, the number of users per cell that can be served by this highest possible bit rate is very limited (only four simultaneous 384 kbps connections per cell are possible on the DL due to the shortness of DL spreading codes).

    To increase the maximum possible bit rate per cell as well as for the individual user, HSPA was defined in Releases 5 and 6 of 3GPP.

    In High-Speed Downlink Packet Access (HSDPA) the High-Speed Downlink Shared Channel (HSDSCH) which bundles several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) is used by several UEs simultaneously – that is why it is called a shared channel.

    A single UE using HSDPA works in the RRC CELL_DCH state. For DL payload transport the HSDSCH is used, that is, mapped onto the HS-PDSCH. The UL IP payload is still transferred using a dedicated physical data channel (and appropriate Iub transport bearer); in addition, the RRC signaling is exchanged between the UE and RNC using the dedicated channels – see Figure 1.8.

    All these channels have to be set up and (re)configured during the call. In all these cases both parties of the radio connection, cell and UE, have to be informed about the required changes. While communication between NodeB (cell) and CRNC (Controlling Radio NetworkController) uses NBAP (Node B Application Part), the connection between the UE and SRNC (physically the same RNC unit, but different protocol entity) uses the RRC protocol.

    The big advantage of using a shared channel is higher efficiency in the usage of available radio resources. There is no limitation due to the availability of codes and the individual data rate assigned to a UE can be adjusted quicker to the real needs. The only limitation is the availability of processing resources (represented by channel card elements) and buffer memory in the base station.

    From the user plane QoS perspective the two major targets of LTE are:
    • a further increase in the available bandwidth and maximum data rate per cell as well as for the individual subscriber;
    • reducing the delays and interruptions in user data transfer to a minimum.

    These are the reasons why LTE has an always-on concept in which the radio bearer is set up immediately when a subscriber is attached to the network. And all radio resources provided to subscribers by the E-UTRAN are shared resources, as shown in Figure 1.9. Here it is illustrated that the IP payload as well as RRC and NAS signaling are transmitted on the radio interfaces using unidirectional shared channels, the UL-SCH and the Downlink Shared Channel (DL-SCH). The payload part of this radio connection is called the radio bearer. The radio bearer is the bidirectional point-to-point connection for the user plane between the UE and eNodeB (eNB). The RAB is the user plane connection between the UE and the Serving Gateway (S-GW) and the S5 bearer is the user plane connection between the S-GW and public data network gateway (PDN-GW).

    The end-to-end connection between the UE and PDN-GW, that is, the gateway to the IP world outside the operator’s network, is called a PDN connection in the E-UTRAN standard documents and a session in the core network standards. Regardless, the main characteristic of this PDN connection is that the IP payload is transparently tunneled through the core and the radio access network.

    To control the tunnels and radio resources a set of control plane connections runs in parallel with the payload transport. On the radio interface RRC and NAS signaling messages are transmitted using the same shared channels and the same RLC transport layer that is used to transport the IP payload.

    RRC signaling terminates in the eNB (different from 3G UTRAN where RRC was transparently routed by NodeB to the RNC). The NAS signaling information is – as in 3G UTRAN – simply forwarded to the Mobility Management Entity (MME) and/or UE by the eNB.

    You can read in detail about all these things and much more from the Wiley's website here.

    Monday, 23 November 2009

    WiMAX Femtocell System Architecture


    So what does it take to build a WiMAX Femtocell solution?

    WiMAX Femtocell can be visualized as a scaled down version of WiMAX macro-cell solution. In addition to the capabilities of a WiMAX macro-cell, other required features of a WiMAX Femtocell are the following:

    Spectrum: WFAP operates over licensed spectrum using standard WiMAX wireless air interface and protocol.

    Form factor: WFAP can be standalone (similar to WiFi access points) or integrated with DSL or cable modems.

    Transport: WFAP uses transport network of subscribers’ DSL, FTTH or cable-based broadband connection.

    User Capacity: Since WFAP is deployed inside a building; a WFAP needs to support at least 5-6 subscribers.

    Power Output: With a range of roughly 10 meters, power output should be kept very low, no more than a 2.4 GHz WiFi product.

    Deployment Support: Operating in a licensed spectrum a WFAP may face interference from neighboring base stations (femto or macro). Therefore, a WFAP should have the capabilities to automatically adjust to minimize the interference.

    Local Breakout: A WFAP should optionally support the capability to route incoming or outgoing traffic directly to the destination through the Internet Service Provider (ISP) network. This approach will bypass the WiMAX service provider network, thus offloading WiMAX service provider network and reducing the cost of service to the subscriber.

    Performance: A Femtocell solution should fit as per the WiMAX network architecture defined by the WiMAX forum. The deployment should not limit the number of WFAPs that are able to connect with a designated ASN Gateway unless operator specified. A network deployment should allow different ISPs to connect WFAP with ASN Gateway in the core network.

    Hand-over: A Femtocell solution should allow handovers between WFAP and WiMAX macro cells or with other adjacent WFAPs.

    Security: A Femtocell solution should use a secure channel of communication (for both control plane and data plane) with ASN Gateways in the core network. The core network must authenticate and authorize a WFAP before it starts offering services to MS/SS in its coverage area. A WFAP may authenticate the ASN Gateway with which it gets connected. A WFAP should keep its air interface disabled unless it is authenticated and authorized to start communication with the ASN Gateway in the core network. A Femtocell may support close subscriber group (CSG) database i.e. a list of subscribers allowed to access the WFAP, and its management.

    Accounting: For providing different rate plans to subscribers accessing services through WFAP, a WFAP needs to make sure that it is recognized by the core network.

    Location Information: A WFAP should support location identification procedures with the core network. Location information can then be used for emergency services or location based services.

    Air Interface: A WFAP should provide at least 10 meters of coverage area in a residential set up without any exclusion zone around it.

    Network Synchronization: A WFAP should support mechanism to synchronize with external network to provide services that require strict air interface co-ordination. Some of the services are soft-handovers, support for idle mode paging, and multicast-broadcast (MCBCS) services.

    Quality of Service: A WFAP should support marking of incoming/outgoing packets with appropriate DSCP code, as configured by a service provider. This would allow support for defined service level agreements (SLAs) when the service is delivered through a WFAP.

    Manageability: A WFAP should implement DSL forum’s defined TR069 protocol to allow an operator to remotely manage a WAFP. It must allow an operator to remotely disable/enable the air interface service.


    The WiMAX network architecture for femtocell systems is based on the WiMAX basic network reference model that differentiates the functional and business domains of NAPs from those of the network service providers (NSPs). The NAP is a business entity that provides and manages WiMAX radio access infrastructure, while the NSP is the business entity that manages user subscriptions, and provides IP connectivity and WiMAX services to subscribers according to negotiated service level agreements (SLAs) with one or more NAPs. A NAP is deployed as one or more access service networks (ASNs), which are composed of ASN gateways and BSs, while the NSP includes a home agent, authentication, authorization, and accounting (AAA), and other relevant servers and databases.

    In a WiMAX network supporting a femtocell, a new business entity called the femto-NSP is introduced, which is responsible for the operation, authentication, and management of WFAPs. The femto-NSP is logically separated from the conventional WiMAX NSPs responsible for MSs’ subscriptions, and it includes femto-AAA and femtocell management/self-organizing network (SON) subsystems.

    The femtocell management system is an entity to support operation and maintenance (O&M) features of the WFAP based on TR-069 or DOCSIS standards. Because potentially many femto BSs will be deployed in overlay coverage of macrocell BSs and have to support handover to/from macrocell BSs or neighbor femto BSs, the operating parameters of femto BSs have to be well organized and optimized. Femto BS parameter configuration and network performance, coverage, and capacity optimization can be done in an autonomous fashion by using SON functions. A SON server provides SON functions to measure/analyze performance data, and to fine-tune network attributes in order to achieve optimal performance.

    A femto-NAP implements its infrastructure using one or more femto-ASNs; an ASN is defined as a complete set of network functions needed to provide radio access to a WiMAX femtocell subscriber. The reference model for a the femto-ASN is defined based on some changes to the conventional ASN to address specific needs of WFAPs, which typically reside at customer premises, and are operated and managed remotely by a femtocell operator over third party IP broadband connection. The femto-ASN reference model includes a WFAP connected to a femto-GW serving as the ASN-GW, through a new entity called a security gateway (SeGW). The SeGW provides IP Security (IPsec) tunnels for WFAPs, and is responsible for authentication and authorization of the WFAPs. The WFAP is connected to a femto-ASN gateway (femto-ASN GW) and other functional entities in the network through this IPsec tunnel. The management system is connected to WFAP through Rm for remote configuration, and it will also include the SON server function, to be defined in the next releases of the femto architecture.

    The femto-ASN GW is an entity that controls WFAPs, and performs bearer plane routing to the CSN and Internet as well as control plane functions similar to ASN-GW providing the link to the connectivity service network (CSN) and other ASNs with mobility and security support in the control plane and IP forwarding. In addition to common functionalities of the ASN-GW, the femto-ASN GW supports femto-specific functionalities such as closed subscriber group (CSG) subscriber admission control, femtocell handover control, WFAP low-duty mode management, and femtocell interference management.


    Wednesday, 7 October 2009

    Femtocells Standardization in 3GPP

    Femtocells have been around since 2007. Before Femtocells, the smallest possible cell was the picocell that was designed to serve a small area, generally a office or a conference room. With Femtocells came the idea of having really small cells that can be used in houses and they were designed to serve just one home. Ofcourse in my past blogs you would have noticed me mentioning about Super Femtos and Femto++ that can cater for more users in a small confined space, typically a small office or a meeting room but as far as the most common definition is concerned they are designed for small confined spaces and are intended to serve less than 10 users simultaneously.

    This blog post is based on IEEE paper on "Standardization of Femtocells in 3GPP" that appeared in IEEE Communications Magazine, September 2009 issue. This is not a copy paste article but is based on my understanding of Femtos and the research based on the IEEE paper. This post only focusses on 3GPP based femtocells, i.e., Femtocells that use UMTS HSDPA/HSPA based technology and an introduction to OFDM based LTE femtocells.

    The reason attention is being paid to the Femtocells is because as I have blogged in the past, there are some interesting studies that suggest that majority of the calls and data browsing on mobiles originate in the home and the higher the frequency being used, the less its ability to penetrate walls. As a result to take advantage of the latest high speed technologies like HSDPA/HSUPA, it makes sense to have a small cell sitting in the home giving ability to the mobiles to have high speed error free transmission. In addition to this if some of the users that are experiencing poor signal quality are handed over to these femtocells, the overall data rate of the macro cell will increase thereby providing better experience to other users.

    Each technology brings its own set of problems and femocells are no exception. There are three important problems that needs to be answered. They are as follows:

    Radio interference mitigation and management: Since femtocells would be deployed in adhoc manner by the users and for the cost to be kept down they should require no additional work from the operators point of view, they can create interference with other femtocells and in the worst possible scenario, with the macro cell. It may not be possible initially to configure everything correctly but once operational, it should be possible to adjust the parameters like power, scrambling codes, UARFCN dynamically to minimise the interference.

    Regulatory aspects: Since the mobiles work in licensed spectrum bands, it is required that they follow the regulatory laws and operate in a partcular area in a band it is licensed. This is not a problem in Europe where the operators are given bands for the whole country but in places like USA and India where there are physical boundaries within the country for the allocation of spectrum for a particular operator. This brings us to the next important point.

    Location detection: This is important from the regulatory aspect to verify that a Femtocell can use a particular band over an area and also useful for emergency case where location information is essential. It is important to make sure that the user does not move the device after initial setup and hence the detection should be made everytime the femto is started and also at regular intervals.

    3GPP FEMTOCELLS STANDARDIZATION

    Since the femtocells have been available for quite a while now, most of them do not comply to standards and they are proprietary solutions. This means that they are not interoperable and can only work with one particular operator. To combat this and to create economy of scale, it became necessary to standardise femtocells. Standardized interfaces from the core network to femtocell devices can potentially allow system operators to deploy femtocell devices from multiple vendors in a mix-and-match manner. Such interfaces can also allow femtocell devices to connect to gateways made by multiple vendors in the system operator’s core network (e.g., home NodeB gateway [HNB-GW] devices).

    In 2008, Femto Forum was formed and it started discussion on the architecture. From 15 different proposals, consensus was reached in May over the Iuh interface as shown below.

    There are two main standard development organizations (SDOs) shaping the standard for UMTS-related (UTRAN) femto technology: 3GPP and The Broadband Forum (BBF).
    More about 3GPP here. BBF (http://www.broadbandforum.org) was called the DSL Forum until last year. As an SDO to meet the needs of fixed broadband technologies, it has created specifications mainly for DSL-related technologies. It consists of multiple Working Groups. The Broadband Home WG in particular is responsible for the specification of CPE device remote management. The specification is called CPE wide area network (WAN) Management Protocol (CWMP), which is commonly known by its document number, TR-069.

    There are several other important organisations for femto technology. The two popular ones are the Femto Forum (www.femtoforum.org) and Next Generation Mobile Network (NGMN).

    3GPP has different terminology for Femtocells and components related to that. They are as follows:

    Generic term: Femtocell
    3GPP Term: home NodeB (HNB)
    Definition: The consumer premises equipment (CPE) device that functions as the small-scale nodeB by interfacing to the handset over the standard air interface (Uu) and connecting to the mobile network over the Iuh interface.

    Generic term: FAP Gateway (FAP-GW) or Concentrator
    3GPP Term: home NodeB gateway (HNB-GW)
    Definition: The network element that directly terminates the Iuh interface with the HNB and the existing IuCS and IuPS interface with the CN. It effectively aggregates a large number of HNBs (i.e., Iuh interface) and presents it as a single IuCS/PS interface to the CN.

    Generic term: Auto-Configuration Server (ACS)
    3GPP Term: home NodeB management system (HMS)
    Definition: The network element that terminates TR-069 with the HNB to handle the remote management of a large number of HNBs.

    In addition, there is a security gateway (SeGW) that establishes IPsec tunnel to HNB. This ensures that all the Iuh traffic is securely protected from the devices in home to the HNB-GW.
    The HNB-GW acts as a concentrator to aggregate a large number of HNBs which are logically represented as a single IuCS/IuPS interface to the CN. In other words, from the CN’s perspective, it appears as if it is connected to a single large radio network controller (RNC). This satisfies a key requirement from 3GPP system operators and many vendors that the femtocell system architecture not require any changes to existing CN systems.

    The radio interface between HNB and UE is the standard RRC based air interface but has been modified to incude HNB specific changes like the closed subscriber group (CSG) related information.

    Two new protocols were defined to address HNB-specific differences from the existing Iu interface protocol to 3GPP UMTS base stations (chiefly, RANAP at the application layer).

    HNB Application Protocol (HNBAP): An application layer protocol that provides HNB-specific control features unique to HNB/femtocell deployment (e.g., registration of the HNB device with the HNBGW).

    RANAP User Adaptation (RUA): Provides a lightweight adaptation function to allow RANAP messages and signaling information to be transported directly over Stream Control Transport Protocol (SCTP) rather than Iu, which uses a heavier and more complex protocol stack that is less well suited to femtocells operating over untrusted networks from home users (e.g., transported over DSL or cable modem connections).


    Figure above is representation of the protocol stack diagram being used in TS 25.467.

    Security for femtocell networks consists of two major parts: femtocell (HNB) device authentication, and encryption/ciphering of bearer and control information across the untrusted Internet connection between the HNB and the HNB-GW (e.g., non-secure commercial Internet service). The 3GPP UMTS femtocell architecture provides solutions to both of these problems. 3GPP was not able to complete the standardization of security aspects in UMTS Release 8; however, the basic aspects of the architecture were agreed on, and were partially driven by broad industry support for a consensus security architecture facilitated in discussions within the Femto Forum. All security specifications will be completed in UMTS Release 9 (targeted for Dec. 2009).

    FEMTOCELL MANAGEMENT

    Management of femtocells is a very big topic and very important one for the reasons discussed above.

    The BBF has created CWMP, also referred to as TR-069. TR-069 defines a generic framework to establish connection between the CPE and the automatic configuration server (ACS) to provide configuration of the CPE. The messages are defined in Simple Object Access Protocol (SOAP) methods based on XML encoding, transported over HTTP/TCP. It is flexible and extensive enough to incorporate various types of CPE devices using various technologies. In fact, although TR-069 was originally created to manage the DSL gateway device, it has been adopted by many other types of devices and technologies.

    The fundamental functionalities TR-069 provides are as follows:
    • Auto-configuration of the CPE and dynamic service provisioning
    • Software/firmware management and upgrade
    • Status and performance monitoring
    • Diagnostics

    The auto-configuration parameters are defined in a data model. Multiple data model specifications exist in the BBF in order to meet the needs of various CPE device types. In fact, the TR-069 data model is a family of documents that has grown over the years in order to meet the needs of supporting new types of CPE devices that emerge in the market. In this respect, femtocell is no exception. However, the two most common and generic data models are:
    TR-098: “Internet Gateway Device Data Model for TR-069”
    TR-106: “Data Model Template for TR-069-Enabled Devices”

    HAND-IN AND FEMTO-TO-FEMTO HANDOVERS

    The 3GPP specifications focused on handovers in only one direction initially — from femtocell devices to the macrocellular system (sometimes called handout). A conscious decision was made to exclude handover from the macrocellular system to the femtocell devices (sometimes called macro to femtocell hand-in). This decision was driven by two factors:
    • There are a number of technical challenges in supporting hand-in with unmodified mobile devices and core network components.
    • The system operator requirements clearly indicate that supporting handout is much more important to end users.
    Nonetheless, there is still a strong desire to develop open, interoperable ways to support handin in an efficient and reliable manner, and the second phase of standards in 3GPP is anticipated to support such a capability.

    NEXT-G EFFORTS

    3GPP Release 8 defines the over-the-air radio signaling that is necessary to support LTE femtocells. However, there are a number of RAN transport and core network architecture, interface, and security aspects that will be addressed as part off 3GPP’s Release 9 work efforts. While it is preliminary as of the publication of this article, it seems highly likely that all necessary RAN transport and core network work efforts for LTE femtocells will be completed in 3GPP Release 9 (targeted for completion by the end of 2009).

    3GPP STANDARDS ON FEMTOCELLS

    [1] 3GPP TS 25.331: RRC
    [2] 3GPP TS 25.367: Mobility Procedures for Home NodeB (HNB); Overall Description; Sage 2
    [3] 3GPP TS 25.467: UTRAN Architecture for 3G Home NodeB; Stage 2
    [4] 3GPP TS 25.469: UTRAN Iuh Interface Home NodeB (HNB) Application Part (HNBAP) Signaling
    [5] 3GPP TS 25.468: UTRAN Iuh Interface RANAP User Adaption (RUA) Signaling
    [6] 3GPP TR 3.020: Home (e)NodeB; Network Aspects -(http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/R3_internal_TRs/R3.020_Home_eNodeB/)
    [7] 3GPP TS 25.104: Base Station (BS) Radio Transmission and Reception (FDD)
    [8] 3GPP TS 25.141: Base Station (BS) Conformance Testing (FDD)
    [9] 3GPP TR 25.967: FDD Home NodeB RF Requirements
    [10] 3GPP TS 22.011: Service Accessibility
    [11] 3GPP TS 22.220: Service Requirements for Home NodeB (HNB) and Home eNodeB (HeNB)
    [12] 3GPP TR 23.830: Architecture Aspects of Home NodeB and Home eNodeB
    [13] 3GPP TR 23.832: IMS Aspects of Architecture for Home NodeB; Stage 2
    [14] 3GPP TS 36.300: E-UTRA and E-UTRAN; Overall Description; Stage 2
    [15] 3GPP TR 33.820: Security of H(e)NB 3GPP TR 32.821: Telecommunication Management; Study of Self-Organizing Networks (SON) Related OAM Interfaces for Home NodeB
    [16] 3GPP TS 32.581: Telecommunications Management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and Requirements for Type 1 Interface HNB to HNB Management System (HMS)
    [17] 3GPP TS 32.582: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Information Model for Type 1 Interface HNB to HNB Management System (HMS)
    [18] 3GPP TS 32.583: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HNB to HNB Management System (HMS)
    [19] 3GPP TS 32.584: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); XML Definitions for Type 1 Interface HNB to HNB Management System (HMS)
    I would strongly recommend reading [3] and [6] for anyone who wants to gain better understanding of how Femtocells work.

    Saturday, 2 August 2008

    LTE, IMS and Voice calls!

    Picked this up from Martin's Blog. One of the things that has been left undefined are the end user applications. Unlike GSM and 3G+ where AMR RAB's has been defined for CS voice calls, there is no provision in LTE. In fact we know that CS domain is completely absent and only IP based PS domain is present. It has been assumed that IMS will be de-facto present along with LTE and the architecture rightly defines so but there is nothing stopping LTE being deployed without IMS. The following is from Martin's Blog:

    LTE requires the IP Multimedia Subsystem (IMS) for voice calls. So what will happen to LTE if IMS doesn't take off? I know, many in the industry believe even asking such a question is close to heresy but who can promisse today that IMS will be a success?

    The trouble with IMS and to some extent with mobile VoIP is not that it's a young technology, standardization has been going on for many years and books about it are going into their third edition. However, there are still no IMS systems out there today that have come out of the trial phase, and I have yet to see a mobile device with an IMS client which is nicely integrated and simply works. Also, the IMS standard is getting more complicated by the day which doesn't make life easier. Another main issue with VoIP and consequently IMS is power consumption. I use VoIP over Wifi a lot on my Nokia N95 and can nicely observe how the phone slightly heats up during a long phone call. Also the non-IMS but SIP compliant Nokia VoIP client in the phone, which by the way is nicely integrated, sends keep alive messages to the SIP server in the network several times a minute. This is necessary mainly due to Network Address Translation (NAT). While this doesn't require a lot of power over Wifi, power consumption skyrockets as soon as I configure VoIP for use over 3G. I can almost watch the power level of the battery drop as the network now constantly keeps a communication channel open to the device. So there are two problems here: VoIP calls cause a much higher processor load during a call, i.e. the VoIP talk time is much shorter than the 2G or 3G talk time and the standby time is significantly reduced. Add to that the missing handover capability to 2G and 3G networks (yes, I know there is VCC in theory) and you have a prefect package for a very bad user experience.

    So the big question is if all of these things can be fixed, say over the next 5 years!? I have my doubts... If not, then LTE has a big problem. Will network operators accept running GSM or HSPA alongside LTE until the problems are fixed? The choice is this and accepting that LTE is for Internet access and some niche VoIP applications on devices such as notebooks or to decide sticking to HSPA(+) until things are fixed.

    In case LTE is deployed and LTE - IMS devices are not ready it's likely that a device can't be attached to several radio networks simultaneously. So how do you inform a device attached to LTE about an incoming voice call? It looks like the people in standards bodies are looking at different solutions:
    • Send a paging message for an incoming circuit switched voice call via LTE to the device. You can do this on the IP layer or on the radio network signalling layer. The device them switches radio technologies and accepts the call.
    • Some people have started thinking about extending LTE with a circuit switching emulation.
    This could be handled on the lower layers of the protocol stack and the software on top would not notice if the call uses GSM, UMTS or LTE. This one is easier said than done because I don't think this concept will fly without a seamless handover to a 2G or 3G network. If such a solution ever gets into mobile phones, it would make life for IMS even harder. Who would need it then?

    Are there any other initiatives I have missed so far to fix the LTE voice issue?

    Dean Bubley in his Disruptive Wireless Blog has interesting analysis on this topic as well:

    My view is that operators should either work with Skype, Truphone, fring et al – or compete head-to-head with them using their own pre-standard mobile VoIP implementations. I still believe this is a good route to VoIPo3G, especially for operators that are already moving to VoIP in their fixed networks, or which are early deployers of IMS or other IP-NGN architectures. Blocking VoIP it not a viable option in competitive markets - as evidenced by the increasing trend towards openness that's been seen in recent weeks.

    But interestingly, another ‘flavour’ of mobile VoIPo3G is now emerging as an alternative for mobile operators – Circuit Switched Voice over HSPA, as an early specification within 3GPP’s Release 8 generation of standards. This was just starting to evolve seriously when I published the report in November, and is mentioned in the comments on this post of mine. And it now seems to be moving fast. In the last week, two of the largest ‘'movers and shakers' in mobile technology - from both handset and network sides - have talked up this approach to me unprompted. And I’m in agreement that it’s undoubtedly going to be important.

    Basically, CS voice over HSPA takes the ordinary mobile circuit voice service, using ordinary diallers on the phone, and circuit core switches in the network... and tunnels it over an underlying IP bearer. So the application isn't VoIP, but ordinary circuit telephony, but the wireless transport (down in the guts of the phone) is IP.

    In other words, it's "Mobile Circuit Telephony over IP"

    In fact, we've all heard this concept before. It is an almost direct HSPA equivalent of UMA’s voice over WiFi. In both cases, there are benefits for operator voice calls, derived from the nature of the radio IP bearer: cost in WiFi’s case as it’s unlicenced spectrum, and the efficiencies of new packet transmission techniques in HSUPA and beyond. And in both cases, it’s not necessary for the operator to have already deployed IMS, VCC and so forth – they can reuse their existing core networks, and get away with less messing-around at the handset application layer. [I’m not sure yet whether the IP tunnel uses a similar IPsec approach to UMA, and could use a similar gateway, or if it’s entirely new]. The downside is that this isn’t a next-gen IP voice service in terms of application capability – it’s voice 1.0 transported over network 3.5.

    There are also various reasons why I'm more positive on CS over HSPA than I am about WiFi-UMA.

    It's a matter of semantics whether you treat CS Voice over HSPA and UMA as 'true' wireless VoIP. Both are using classic circuit signalling, rather than SIP or proprietary protocols like Skype. Neither are as easy to use as "full VoIP" as the basis of innovative applications like voice mashups.

    The interesting thing to me is that the industry is starting to polarise into different points of view on this issue. Ericsson remains a staunch MMTel advocate, driven by its desire to push IMS as the main future application layer. But other major players seem to be edging towards a CS over HS worldview, albeit with a hedge around naked-SIP VoIP.

    So… taken together, the various types of VoIPo3G are going to be:
    • Over-the-top independent VoIP (Skype, Truphone, IP-PBX etc) with a dedicated client on the handset or PC
    • CS voice over HSPA, using the ordinary circuit voice app plus some lower-level IP ‘plumbing’.
    • IMS MMTel – needing a full IMS client on the device
    • Other IMS or standards-based voice apps like PoC or perhaps a standalone SIP VoIP server plugged into the IMS application layer
    • Standalone operator softswitch-based VoIP connecting to a (probably) SIP client on the handset.
    • Partnerships or mashups of the above.

    Messy and diverse, in other words. And all of these have different use cases, different pro’s and con’s, different requirements in terms of user behaviour, cost and so on.

    But the bottom line is that with the addition of CS Voice over HSPA, my top-level VoIPo3G predictions are still looking feasible, although some of the fancier web- or application-based VoIP capabilities will be trickier to exploit by the operators choosing that approach.

    I have to admit that I havent looked into this area at all and cannot comment on which direction things will move. One thing that I can definitely say from my experience is that the initial movers, if successful, will set the direction for others to follow and may be eventual winners.