HSPA Architectural Evolution

With the advent of LTE we are experiencing high speeds over the packet network. But what about the legacy WCMDA network. Operators have invested a lot of CAPEX in setting up a network which can provide a coverage for WCDMA/HSPA. In this context, the HSPA evolution plays a quite important role.

HSPA networks will form an integral part of future 3G systems and as they evolve, should provide a smooth migration path towards LTE. HSPA operators are just as interested in the potential performance and cost savings which may be achieved through HSPA Evolution as they are in the future LTE system.

HSPA was first introduced in release 7 when HSDPA (High speed downlink packet access) was combined with EUL(enhanced uplink) to form a FDD system

Evolution Paths

  1. HSPA Spectrum Efficiency, Peak Data Rate and Latency should continue to evolve favorably.
  2. HSPA and its evolution should facilitate the joint technology operation with LTE and offer a smooth migration path towards LTE (Long Term Evolution) i.e. The possibility to adopt common elements or a common functional split with LTE and the possibility to re-use the evolved Core Network defined as part of the System Architecture Evolution (SAE) study should be analyzed as well;
  3. Evolved HSPA should be able to operate as a packet-only network based on utilization of the high speed data channels only (HS-DSCH, E-DCH and associated channels);
  4. HSPA Evolution shall be backward compatible in the sense that legacy terminals (R99-DCH and HSPA mobiles) shall be able to share the same carrier with terminals implementing the latest features of the HSPA Evolution track without any performance degradation;
  5. Ideally, existing infrastructure should only need a simple upgrade to support the features defined as part of the HSPA Evolution.
  6. The main objective of the HSPA evolution is to improve further the latency and the bit rate with limited and controlled


Architectural Evolution

  1. Current Architecture – Same as Rel. 6 
    1. Option 1 is to use the same architecture without going any further changes in the network.
    2. The UTRAN consists of a set of Radio Network Subsystems connected to the Core Network through the Iu.
    3. A RNS consists of a Radio Network Controller one or more Node Bs
    4. A Node B is connected to the RNC through the Iub interface.
    5. The RNC is responsible for the Handover decisions that require signalling to the UE.
    6. A RNC may include a combining/splitting function to support combination/splitting of information streams Inside the UTRAN, the RNCs of the Radio Network Subsystems can be interconnected together through the Iur.
    7. Iu(s) and Iur are logical interfaces. Iur can be conveyed over direct physical connection between RNCs or virtual networks using any suitable transport network.
  2. Iu with enhanced SRNC separate from the enhanced collapsed CRNC/DRNC/Node B 
    1. The RAN-CN functional can be split and is thus kept to readily reuse the proven Iu interface
      with no additional delay.
    2. Besides, only the functions which effectively contribute to the reduction of the latency and the increase of bit rate have been moved from the RNC down to the nodeB in order to minimize the hardware and software impacts.
    3. An RNC RLC mirror function is placed in nodeB to improve the latency induced by repetitions for both the user plane and the control plane, – the scheduling of all common resources is moved to the nodeB (enhanced scheduler) where they benefit from the HARQ function.
    4. The centralized scheduling of common resources in the nodeB also leads to power management
      optimizations and corresponding gains in bit rate.
    5. Other enhancements already identified within the R7 study items (signalling enhancements, Continuous Packet Connectivity, delay optimization for procedures,…)
    6. Moreover, these changes also result in the possible move of the CRNC and DRNC functions into the nodeB which can lead to a simplified architecture.
  3. PS User Plane /Control Plane split, CP functions in RNC, direct UP tunnel PS CN – Node B
    1. The current UTRAN architecture, inherited from GPRS, is not optimised for very pervasive broadband packet services.
    2. The presence of anRNC in the User Plane path plays as a bottleneck for the traffic throughput because of
      1. limitations given by switching and routing capacity of an RNC.
      2. limitations given by RLC/MAC and Iub Framing Protocol termination in the RNC.
    3. A possible solution to those limitations is allowing User Plane and Control Plane to scale separately and terminating the User Plane protocols in the Node Bs. That is introducing a ‘flat’ architecture for the UP part.
    4. As a consequence, the Node B will have a direct IP broadband connection to the Packet Core.
    5. Latency and delay on the user plane will improve since radio protocols and re-transmission will be terminated in the Node B, similar to what has been decided for LTE.
    6. At the same time, other important aspects such as mobility, efficient coordination between different layer (pico/micro/macro coverage), reuse of legacy investments should not be overlooked.
  4. Iu with RNC U-Plane & C-Plane functions in Node-B
    1. In this architecture the RNC functions are in the NodeB, which can be named as evolved HSPA NodeB.
    2. Evolved HSPA system enables to use 3GPP Release 5 and later Releases of air interface with no modifications for HSPA traffic.
    3. The intended use scenario for HSPA capable terminals is to utilise HSPA both in uplink (E-DCH) and in downlink (HS-DSCH).
    4. The evolved HSPA NodeB has Iu-PS interface towards packet switched CN.
    5. Iu-PS user plane is terminated either in SGSN or in case of one tunnel approach (Rel-7) in GGSN.
    6. Evolved stand-alone HSPA is designed with full mobility support, including handovers within the system.
    7. Intra-system handover in evolved HSPA is executed between cells, which belong to different evolved HSPA NodeBs (inter-NodeB handover).
    8. Handover towards other 3G networks is standard serving RNC relocation. The communication between evolved HSPA NodeBs takes place over Iur interface.
    9. Evolved HSPA architecture is a solution for a flat radio access architecture of UTRAN network. In the solution all or part of RNC functions are in the NodeB, which in the present document is named as evolved HSPA NodeB.


In summary, the described solution is characterised by the following features:
– Evolved Node Bs have a direct IP broadband connection towards the Packet Core for PS traffic.
– A flat RAN architecture, allowing delay optimisation and scalability without capacity bottlenecks.
– RNC is not needed at all for pure PS carrier, i.e. in stand-alone deployment.
– RNC is used to implement CS support and therefore CS core is not changed at all in carrier sharing deployment.
– Stand-alone scenario requires minimal changes or no changes for the current specifications and network elements



HSPA : High Speed Packet Access
LTE : Long Term Evolution
MIMO : Multiple Input Multiple Output
NAS : Non Access Stratum
OPEX : Operational expenditure
QoS : Quality of Service
PS : Packet Switched
TCP : Transmission Control Protocol
UE : User Equipment


 ETSI TR 125 999 V7.1.0 (2008-04)


Mohit Kumar

A simple person who likes to share his thoughts on this blog. Know more about me

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *