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:

• A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend
• 3G4G: Open RAN, OpenRAN and O-RAN

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.

Image Reference: WiMAX Femtocell: Requirements, Challenges, and Solutions

AIPN Scenarios

AIPN or All-IP Network is being introduced part of 3GPP Release 7. TS 22.978 shows some scenarios where AIPN will play a big part

USE CASE 1 (see left in the daigram): Bob has his own Personal Area Network (PAN). While at home, this network is composed with the Home Area Network using WLAN, which in turn connects externally with a local hotspot service, which in turn connects to a cellular network. Bob's PAN, Bob’s Home-WLAN, the local hotspot service and the AIPN cellular access system are under different administrative domains. Still, if Bob moves outside coverage of his Home-WLAN, his PAN will communicate with the outside world via the local hotspot service. If he moves outside coverage from the hotspot service, his PAN will communicate with the outside world via the AIPN cellular access system.

USE CASE 2: The user is driving a car. While being under good radio coverage, he starts an IMS session with several media. The car goes through a tunnel where there is no radio coverage, and comes out of the tunnel into good radio coverage a minute later. Connections using disruption resilient transport protocols are automatically re-established and these protocols restore the communication to the point they were before the interruption.

USE CASE 3: Alice has a mobile device and Bob has a fixed one. Both devices have equal audio but different video capabilities in terms of screen size, number of colors and video codecs supported. Alice establishes a multimedia connection with audio and video components to Bob. The terminal capabilities are discovered and it is realized that Bob's terminal has better video capabilities than Alice. The terminal informs the network that it is unable to support new the new video codec and the AIPN then introduces a video transcoder in the path of the video media to adapt the video signal (stream, codec, format, etc) to the video capabilities and bit rates available on each side of the transcoder.

Enhanced Services should be possible with AIPN:

• Support for advanced application services
• Support for group communication services, e.g. voice group call, instant group messaging, and multicast delivery. In some cases, a group may include a large number of participants.
• Support for integrated services, e.g. a service including a mixture of services among SMS/MMS/Instant Message, or a service including voice call/video call/voice mail.
• Provision of seamless services (e.g. transparent to access systems, adaptable to terminal capabilities, etc) Users should be able to move transparently and seamlessly between access systems and to move communication sessions between terminals.
• Support ubiquitous services (e.g. associations with huge number of sensors, RF tags, etc.) ... see right side of diagram above.
• Improve disruption-prone situations when network connectivity is intermittent.

Disruption-free network connectivity may not be cost effective, or even feasible, in all cases (e.g. cell planning for full radio coverage for all services, disruption-free inter-access system handovers, disruption-free IP connectivity in all network links). An AIPN should consider solutions for making services as resilient to temporary lack of connectivity as possible.

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:

• 3GPP Release 14 - Techplayon
• Enhanced Television Services over 3GPP eMBMS
• RAN Evolution of LTE in Release 14
• 3GPP announces RAN work programme for R14
• LTE System Information According to Release 14 (3GPP TS 36.300 V14.3.0 )

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:

• 3GPP TR 23.799: Study on Architecture for Next Generation System
• 3GPP TS 23.501: System Architecture for the 5G System; Stage 2
• 3GPP TS 23.502: Procedures for the 5G System; Stage 2

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.

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. 

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: 

• The 3G4G Blog: 3GPP Release 17 Description and Summary of Work Items
• The 3G4G Blog: Lawful Intelligence and Interception in 5G World with Data and OTT Apps
• The 3G4G Blog: 5G and Cyber Security
• The 3G4G Blog: Realizing Zero Trust Architecture for 5G Networks
• The 3G4G Blog: AT&T Cybersecurity Experts Provide 5G Security Overview
• The 3G4G Blog: Everything you need to know about 5G Security
• The 3G4G Blog: Introduction to 3GPP Security in Mobile Cellular Networks
• The 3G4G Blog: Initiative to Remove Non-inclusive terms from 3GPP Specifications
• The 3G4G Blog: 3GPP 5G Non Terrestrial Networks (NTN) Standardization Update
• The 3G4G Blog: 3GPP Explains TSG CT Work on UAS Connectivity, Identification and Tracking 

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.

Flatter Architecture from Nokia-Siemens Network

From Unstrung:

In its bid to overtake Ericsson AB and become the world’s top radio access infrastructure supplier in terms of revenue, Nokia Siemens Networks believes its approach to all-IP flat architecture on 3G networks will give it an edge. Nokia Siemens says operators do not have to wait for LTE, to get the benefits of an all-IP architecture, and it is the only vendor that currently champions a flat 3G radio access network (RAN) approach.

As mobile data traffic continues to surge, operators are considering how to adopt flat, all-IP architectures in their 3G networks before the advent of 4G in order to gain lower latency, lower cost per bit, support for multiple access networks, and preparation for next-generation networks. But there are different ways to implement such architectures, and just how operators arrive at a flatter data network architecture is hotly debated.

Nokia Siemens has put its money on a flat RAN approach for high-speed packet access (HSPA) and the coming HSPA+ standard, in addition to its support for the Direct Tunnel architecture.
In a flat RAN architecture, the radio network controller (RNC) is integrated into the Node B so that the base station communicates directly with the Gateway GPRS Support Node (GGSN).
But there are as many benefits as drawbacks to flat 3G RANs, which makes it a controversial approach, according to the recent Heavy Reading report, "Flat IP Architectures in Mobile Networks: From 3G to LTE."

With flat RANs, some of the benefits include lower latency for data applications, lower operational costs due to fewer nodes to maintain and manage, augmented data capacity through a data network overlay, and good preparation for so-called 4G LTE/SAE (System Architecture Evolution), which uses a similar functional architecture. Also, costs won’t grow in line with data traffic growth, because operators won’t have to deploy extra RNC and SGSN capacity as traffic increases.

It may be challenging to integrate the RNC into a Node B. RNCs are critical to supporting macro-diversity in mobile networks, which enables mobile handsets to communicate with multiple base stations on the uplink and allows operators to deploy fewer base stations. NSN’s flat RAN architecture supports this feature, but in an unorthodox way, according to the Heavy Reading report.

So far, Nokia Siemens has three customers using its Internet HSPA (I-HSPA) flat RAN solution: Stelera Wireless and TerreStar Neworks in the U.S. and T-2 in Slovenia. And Mobilkom Austria AG & Co. KG recently trialed the solution.

Nokia Siemens’ Rouanne explains that flat 3G RANs aren’t necessary when there is just “medium” data traffic, but are best suited when operators have big data traffic volumes. “Those networks that are starting to be under pressure with traffic are coming to us and wanting to direct traffic directly to the Internet,” he says.

Even though Nokia Siemens is the only vocal supporter of flat 3G RANs right now, Brown says the strategy isn’t risky, but it’s “forward-looking.”

And a flat 3G RAN can set up an operator to be ready for the shift to LTE with its inherent flat architecture.

According to an old Ericsson presentation, ”Direct Tunnel” support added for 3G payload optimization has the following advantages:

• Cost efficient scaling for Mobile Broadband deployments
• Increased flexibility in terms of network topology
• Allows the SGSN node to be optimized for control plane
• Specifications part of 3GPP rel-7
• Designed for operation in legacy (GGSN/UTRAN) networks
• First step towards the SAE architecture

According to heavy reading article:

To efficiently deliver mobile broadband services, operators require a network infrastructure that simultaneously provides lower costs, lower latency, and greater flexibility. The key to achieving this goal is the adoption of flat, all-IP network architectures. With the shift to flat IP architectures, mobile operators can:

• Reduce the number of network elements in the data path to lower operations costs and capital expenditure
• Partially decouple the cost of delivering service from the volume of data transmitted to align infrastructure capabilities with emerging application requirements
• Minimize system latency and enable applications with a lower tolerance for delay; upcoming latency enhancements on the radio link can also be fully realized
• Evolve radio access and packet core networks independently of each other to a greater extent than in the past, creating greater flexibility in network planning and deployment
• Develop a flexible core network that can serve as the basis for service innovation across both mobile and generic IP access networks
• Create a platform that will enable mobile broadband operators to be competitive, from a price/performance perspective, with wired networks

Note: Diagrams above shamelessly copied from Ericsson's presentation.