01 rn33007en10gla0 hspa in nsn ras

HSDPA in Nokia RASObjectives
At the end of this module you will be able to:
Describe principles of HSPA.
Illustrate briefly transmission&transport features for HSPA
Describe I-HSPA overview
HSDPA is introduced in 3GPP Rel5 specifications.
HSDPA offers a lower cost per bit, provides peak cell throughput 14 Mbps and the peak bit rate for single user 14 Mbps (RU10)
Link adaptation feature, modulation and coding scheme is selected by the BTS-based on feedback information.
Reduced (re)transmission delays.
Improved QoS control (BTS-based packet scheduling).
HSDPA is mainly intended for non-real time traffic, but can also be used for traffic with tighter delay requirements.
Selection of the optimum modulation and coding scheme is performed based on the downlink quality indicators provided by the UE. Allowed combinations form TFRC (Transport Format and Resource Combination) illustrated in table.
Naturally, due to increasing requirements for phase and amplitude estimation, higher order MCS (modulation and coding schemes) are available only for UEs with good channel conditions. Generally, less redundancy is introduced in all available HSDPA MCS, since only one channel is multiplexed on HS-DSCH (High Speed – Data Shared Channel). HSDPA-capable WBTS is responsible for selecting the transport format to be used with particular modulation and a number of codes. Variation of the transport block size, the modulation scheme, and a number of multi-codes leads to a range of effective code rates (0.15 – 0.98).
In RU10 the peak bit rate on HSDPA for single user is increased to 14Mbps. The HSDPA category 10 UE can utilize its maximum 14Mbps peak bit rate with 15 codes.
* © Nokia Siemens Networks RN33007EN10GLA0
Introduction to HSDPA (2/7)
In RU10, HSDPA user peak rate is increased up to 14Mbps/user
5 codes
Fast H-ARQ (hybrid automatic retransmission request) functionality centralized in the BTS rapidly requests the retransmission of missing data entities, SAW (stop-and-wait) protocol is used. Retransmitted data entities are soft combined with the original transmission before message decoding process. Since the H-ARQ mechanism resides in the BTS (MAC-hs), requests can be done immediately. This way, probability of successful combining is increased. If all data is correctly decoded, the ACK message is sent on the associated UL channel HS-DPCCH (High Speed – Dedicated Physical Control Channel). H-ARQ requires some memory in the UE to buffer the soft information.
There are two strategies of H-ARQ:
- IR (incremental redundancy);
- CC (chase combining).
Additional unit with MAC functionality (HSDPA MAC or MAC-hs) is installed at the BTS.
Retransmission controlled by the BTS reduces retransmission delay.
The Iub interface (BTS-RNC) requires a flow control mechanism to ensure that BTS buffers are used properly and there is no buffer overflow.
The RNC still retains the RLC functionalities as it provides retransmission in cases when HS-DSCH BTS retransmission fails.
Packets
Packets
H-ARQ, retransmission handling and coding.
Uplink feedback decoding.
HARQ &
Coding
The MAC layer is implemented with two separate MAC entities.
MAC-d:
Terminal sends the ACK/NACK in the UL HS-DPCCH 7.5 slots after the end of the HS-PDSCH TTI.
The network side is asynchronous in terms of when to initiate the DL transmission.
Layer 3 signalling, TPC for the UL, speech if necessary
Control signalling
User data
CQI, H-ARQ ACK, TCP for the DL, speed if necessary
HSDPA physical channels:
DL HS-PDSCH (High Speed – Physical Downlink Shared Channel)
- Carries the user data in the DL HS-DSCH (High Speed – Downlink Shared Channel).
- Modulation QPSK or higher modulation scheme (16 QAM), lower encoding redundancy leading to high peak data rates.
- TTI (Transmission Time Interval), interleaving period = 2 (In R’99, TTI = 10/20/40/80 ms).
- Fixed SF (spreading factor) (16), support multi-code transmission, as well as multiplexing of different users (15 – maximum capability) – not supported by Nokia implementation.
- Users check the information on the HS-SCCH to determine which HS-DSCH codes to despread (in case of code multiplexing of HSDPA users).
- HS-DSCH has always DL DPCH associated (signal radio bearer for layer 3 signalling, power control command for UL HS-DPCCH, etc.).
DL HS-SCCH (High Speed - Shared Control Channel)
- Carries the information needed for HS-DSCH demodulation.
- The UTRAN allocates a number of HS-SCCHs corresponding to the maximum number of users code-multiplexed.
- If there is no data on HS-DSCH, HS-SCCH is not assigned.
- The HS-SCCH uses SF 128, accommodating 40 bits per slot.
- Each HS-SCCH block has a three–slot duration divided into 2 functional parts:
First part (first slot) carries the time-crucial information needed to start the demodulation process in due time ( -> avoid chip level buffering) and indication if QPSK or 16 QAM modulation is used on HS-DSCH.
Second part (next two slots) contains CRC (cyclic redundancy check) for checking HS-SCCH, ARQ process number, and redundancy version.
This page is intentionally left blank
In addition, the uplink physical channel is introduced for HSDPA functionality.
UL HS-DPCCH (High Speed - Dedicated Physical Control Channel)
- Carries ACK/NACK information for the L1 retransmissions.
- Carries CQI (DL Channel Quality Indicator) to be used by BTS scheduler to determine to which terminal to transmit and at which rate.
- Intensively discussed in the 3GPP forum, feedback method is not easy to be standardized due to differences in the terminals.
The feedback information consists of 5 bits.
- One state expresses: ’do not bother to transmit’.
- Other states represent the transmission that terminal can receive.
- These states range from single code QPSK transmission to 15 multi-code 16 QAM (including various coding rates).
- Terminals, which do not support certain number of codes should signal this for power-reduction factor related to the most demanding supported TFRCs.
The scheduler in the BTS evaluates channel conditions for each UE. The BTS identifies the HS-DSCH parameters (number of codes/modulation/H-ARQ mode).
The information in the HS-SCCH is sent two slots before the corresponding HS-DSCH. The UE monitors the HS-SCCH, and once the first part is decoded, the UE starts buffering the necessary codes from the HS-DSCH. When the second part of the HS-SCCH is decoded, the UE determines to which ARQ process the data belongs and if needed – it is combined with the data in the soft buffer. When data is decoded, the UE sends in the UL an ACK/NACK indicator (depending on the CRC check conducted on the HS-DSCH). If the network continues to transmit data for the UE in consecutive TTIs, the UE will stay on the same HS-SCCH.
DCH/HS-DSCH
E-DCH/HS-DSCH
Is UM RLC (streaming) supported by HSPA?
This feature Streaming QoS for HSPA (RAN1004) introduces support of streaming traffic class RABs with Guaranteed Bit Rate (GBR) on HSPA.
Admission and resource allocation of a new streaming traffic class RABs is done according Guaranteed Bit Rate.
Streaming traffic class RAB can take resources from NRT RABs (RT-over-NRT).
Streaming traffic class RABs are prioritized over NRT RABs through whole RAN.
This feature makes it also possible to have Nominal Bit Rate (NBR) for NRT traffic classes, which is taken in account in BTS scheduler (NBRs can be used only in HSPA cases).
This feature brings state transitions for PS RT RABs used for streaming
The maximum number of HSDPA users per cell is 64(RU10)
HS-DSCH can be transmitted to all cells in the WBTS at the same time.
Number of required channel elements depending on activated features e.g. shared HSDPA scheduler for based band efficiency needs 64CEs and 80CEs for Ultrasite and Flexi BTS respectively.
64 users
64 users
64 users
Note: These capacities are depending on the activated features and allocated resources.
R-bus
DSC-BUS
Iub
WAF
WTR
WSM
WPA
WSP
WSP
DSC-BUS
WAF
WTR
WSM
WPA
WSP
WSP
DSC-BUS
WAF
WTR
WSM
WPA
WSP
WSP
R-bus
T-bus
RT-bus
RR-bus
ST-bus
SR-bus
WSP
One WSPCs per cell assigned for HSDPA use. Handles L1, MAC-hs and FP
IFU
IFU
AXU
IFU
WSC
Carrier
Interface
WAM
WAM
WAM
R-bus
WSP
WSP
- WN5.0 Software has to be installed on the WBTS.
- At least one WSPC needs to be installed in the WBTS to support HSDPA using 5 codes.
- A software update for the WSPC is required to support HSDPA.
- No changes are required to any other units for HSDPA to be taken into operation and their dimensioning can be done according to the normal guidelines.
All types of WSP units can be combined in one cabinet.
NIU
A2SU
DMCU
SFU
MXU
MXU
NIU
GTPU
Soft DMPG pooling
A2SU
All user plane (DCHs and HS-DSCHs) AAL2 connection are allocated to the same AAL2 VCC over Iub
Separate AAL2 level queues for DCHs and HS-DSCHs data streams
MXU
GTPU
All units shared with all PS domain traffic
Iub
Iu
Separate VCC is dedicated for HSDPA.
No needs for shared AAL2 allocations.
Statistical multiplexing of the HSDPA traffic supported independently of the R’99 traffic.
HSDPA tolerates delays better than R’99 DCH traffic on the Iub.
For both HSDPA and R’99 traffic, CBR is the supported service in the RNC/BTS.
The HSDPA route selection feature is available from RAS5.1
Allows defining dedicated AAL2UP VCCs for selected types of traffic
The traffic types are:
Defining each VCC traffic type depends on customer strategy
Mandatory for Dynamic Scheduling for HSDPA and NRT DCH with Path Selection features
CoCO
DCH
HSDPA
HSPA
Flexible connection of VPCs for WBTS
The feature enables more flexible usage of VPCs and VCCs in the connection
configuration for a BTS in the RNC. Several VPCs can be used towards a BTS.
Benefits for the operator: OPEX savings because of faster and less user actions demanding RAN configuration.
Functional description: With this feature, multible VPCs can be connected to one WBTS object in the RNC configuration. The feature also enables more flexible configuration for the VPC/VCCs for the BTS connections (this is needed with Path and Route Selection features).
The Coco object includes parameter for the traffic type and different kind of default configuration
for the VPCs and allows use of multible VPCs for each BTS and BTS termination point.
In Path and Route Selection this feature moves the variations to the transport configuration inside the RNC which makes the network management much easier.
Current implementation: The current RNC implementation allows one virtual path connection (VPC) to be connected to each WCDMA base station (WBTS) object. If several physical interfaces are needed, an inverse multiplexing for ATM (IMA) group is used.
In networks where all transmission network elements does not support IMA groups, only one E1 can be used for each WBTS. In addition to this, the VPC configuration in the RNC Coco object (RNW) does not allow use of separate AAL2 connection VCCs for different kind of traffic, as would be needed in Path and Route Selection features.
Dynamic HSDPA transport scheduling
HSDPA traffic overbooking without sacrificing HSDPA nor DCH QoS.
Optimised usage of the Iub transport resources in Shared VCC configuration.
RNC monitors the Iub transport utilization and adjust dynamically HSDPA MAC-d flow parameters in Iub.
Reduces the packet drop ratio of the HSDPA traffic during Iub congestion.
No need for static traffic parameter settings for HSDPA flow in Iub, saving OPEX.
RNC
BTS
HSDPA
Bearer
Rel99/Rel04
Bearer
HSDPA Traffic
DCH Traffic
Dynamic HSDPA Transport Scheduling feature introduces a MAC-d flow control algorithm between the AAL2 multiplexing and the MAC layer in the RNC. The algorithm reduces the packet drop ratio of the HSDPA traffic during I-ub congestion. Since the HSDPA flow control algorithm in the BTS does not know the I-ub capacity available for the HSDPA traffic, it may allocate more capacity for the HSDPA MAC-d flows than there is available bandwidth in the I-ub.
The MAC-d flow control algorithm in the RNC is based on monitoring the length of the AAL2 queue. There are two thresholds in the queue: the high threshold and the low threshold. When the high threshold is crossed, a flow control message is sent to the MAC layer. As a result, the MAC-d entities reduce the data rate, preventing the AAL2 queue from overflowing. The high threshold is set so that the target maximum delay on the I-ub (e.g., 100 ms) is not exceeded. In turn, when the low threshold is crossed, the MAC layer is informed that it can start using the full capacity allocation again. The low threshold is set in order to maximize the I-ub utilization.
Dynamic Scheduling for HSDPA and NRT DCH with Path Selection
Introduce AAL2 flow control and VCC bundling concept.
AAL2 flow control operates between MAC and AAL2 layers, based on defined threshold on AAL2 queue length.
On a VCC bundle, it can be defined how the excess bandwidth is shared among HSDPA and NRT-DCH by defining their share
This feature require Path Selection feature is enabled, and works in Iub only
HSDPA
NRT-DCH
(PS)
RT-DCH
(voice)
hi
lo
HSDPA
NRT-DCH
RT-DCH
CBR 2.0 Mbps
Excess bandwidth 1.0 Mbps
HSPA in NSN RAS
Average C/I (users with the highest averaged C/I are prioritized);
Round Robin (cycle, entirely blind approach) – implemented in Nokia RAS05.
Fair throughput (prioritizes users with the lowest average throughput).
Fast (opportunistic) scheduling techniques (scheduling period ~2 ms):
Maximum C/I (in every TTI, users with the best instantaneous C/I are prioritized);
Fast fair throughput (aims at maximizing fairness while taking advantage of fast fading);
Proportional fair (serves the user with the largest relative channel quality) – implemented in Nokia RAS05.1.
RAS05.1 feature.
Increases system throughput by serving the user above their average data rate requested
Advantage:
Disadvantage:
reports
calculated over a period of time
User with highest ratio is
scheduled first
Method of Operation
The proportional fair algorithm is selected for the MAC-hs packet scheduling in the BTS. The MAC-hs packet scheduling algorithm is similar to the round robin principle. The P-FR (proportional fair resource) algorithm utilises the radio channel state information from the UEs in making scheduling decisions. The P-FR principle is to select one UE among those active users that have data in their buffers and are not limited by their capabilities for selection, to maximize the relative instantaneous channel quality (ratio of instantaneous throughput to the average throughput) for scheduling in the following 2ms TTI. The relative instantaneous channel quality is calculated in every TTI (2 ms).
5 codes are reserved for HSDPA (since RAS05)
Up to 15 codes are dynamically allocated, according HSDPA Dynamic Resource Allocation feature.
Peak Cell level total throughput 14.4 Mbps, while peak data rate per user is 14 Mbps (RU10)
With this feature a category 10 UE may receive data with its maximum bit rate when 15 codes for HSDPA are allocated in the cell
SF=1
SF=2
SF=4
SF=8
SF=16
SF=32
SF=64
SF=128
SF=256
3 HS-SCCH are required for each UE in Coded multiplexing
The number of HS-PDSCH dynamically allocated
At least 5 codes are always supported
Largest possible number of codes should be used before using less robust coding
BTS has to support HSDPA 10/15 Codes
TTI

HSDPA mobility (serving cell change)
Serving HS-DSCH can be changed without updating active set for R’4 channels.
CPICH Ec/N0
Handover delay
Switching from the HS-DSCH in one cell directly to the HS-DSCH in another cell
The HSDPA serving cell change is a HS-DSCH to HS-DSCH hard handover that can happen either intra-BTS intra-RNC or inter-BTS intra-RNC.
The main input for selecting the serving cell is the UE's intra-frequency measurement reporting Event 1d for the quantity CPICH Ec/N0. This event describes the change of the HSDPA serving cell. By adequate parameterization, the operator can control the sensitivity of the serving cell change. For all cases, the MAC-hs of the source cell will be reset upon the serving cell change and the RLC protocol will take care of the retransmission of the data to the target cell.
The operator can select whether the HSDPA serving cell change or DCH switching is used for handling the mobility of the HSDPA users. When the HSDPA serving cell change is selected, switching to DCH may still be needed in bad radio conditions.
HSDPA mobility (intra-BTS serving cell change)
Entire transmission from the source cell stops at specified time (defined and provided by the RNC).
Packet scheduler in the target cell is then allowed to control transmission to the UE.
Two options, (RAS05.1 supports MAC-hs reset).
1) MAC-hs preservation:
There is no data loss, as buffered data (for H-ARQ protocol) in the original cell is moved to the target cell.
H-ARQ manager will continue functionality without any breaks.
2) Reset the MAC-hs:
Similarly as in inter-BTS hard handover, the MAC-hs buffer is reset.
Retransmission of the data is executed by higher layers (RLC).
HSDPA mobility (inter-BTS serving cell change)
At the time of the cell change, the MAC-hs for the user in the original cell is reset, all data in the buffers is deleted.
At the same time instant, the MAC-hs flow control in the target cell starts to request PDUs from the SRNC.
Higher layer retransmissions (RLC protocol) are exploited to recover the data that was lost during the buffer reset in the original BTS.
HSDPA mobility (HS-DSCH to DCH hard handover)
Required when user moves from HSDPA-enabled cell to a cell that is not HSDPA capable.
Transmission continues on DPCH.
Buffers in the original cell are reset in a similar manner as in inter-BTS HSDPA hard handover.
The user is immediately switched to the DCH of the requested bit rate when there is a data volume request either from the UE or RNC (no need for first DCH 0x0 DCH Initial bit rate DCH Final bit rate).
Cell (layer) with HSDPA capability
Cell (layer) without HSDPA capability
Enable multilayer support for HSDPA and maximum utilisation for HSDPA users when HSDPA is not implemented on all frequency layers.
1
2
The feature ensures full coverage for HSDPA
Soft/softer HOs are supported for the associated DPCH for the UE with HSDPA connection
DPCH
DPCH
DPCH
HS-DSCH
Soft/softer handover for HSDPA users enables HSDPA usage in the whole cell coverage area and between cells. Therefore, HS-DSCH is also supported for UEs with an active set size larger than one (for the UEs in the soft/softer handover region).
The following intra-frequency soft/softer handovers for associated DPCH are supported:
- Intra-BTS intra-RNC softer handover;
- Inter-BTS intra-RNC soft handover;
- Inter-BTS inter-RNC soft handover.
A specific functionality is needed for preventing the use of SRNC anchoring for HS-DSCH in case of inter-BTS inter-RNC soft handover. When the serving cell change would trigger to map the HS-DSCH to the radio link on Iur interface that is prevented by switching the HSDSCH to the DCH. From that on the SRNC Relocation procedure can be performed normally using only DCH. However, if the branch(es) from DRNC is (are) released due to normal mobility, the HS-DSCH can be used again.
When inter-frequency handover triggers, RNC initiates compressed mode on HSDPA
Because there is no need to switch to DCH, IFHO is 1.5 seconds faster
Inter-frequency serving cell
E.g. handover
HSPA throughput
available during
compressed mode
Drag the side handles to change the width of the text block.
Compressed mode measurements started on HSPA due to quality reason
HSPA allocation in the target cell
HSPA layer
Non-HSPA layer
HSPA layer
Capacity optimised link adaptation:
Not enough data to fill the transport block
CQI indicates that HS-DSCH power can be reduced
In code multiplexing resources are shared in a more efficient manner
Buffer occupancy and channel conditions of the user are taken into account.
PDU
HSDPA Congestion Control
With HSDPA Congestion Control BTS detects congestion on Iub and notifies RNC about it. MAC-d scheduler in RNC reduces selectively sending rate
By preventing congestion on the Iub, the feature avoids further reduction of throughput when the RLC retransmissions start to accumulate due to Iub congestion
Allows HSDPA traffic to dynamically use bandwidth as it becomes available
Allows aggressive HSDPA overbooking in ATM networks
Also enables use of heavily contended packet networks for HSDPA offload (hybrid backhaul)
CAPEX and OPEX savings are achieved by increased Iub efficiency and HSDPA throughput
BTS sends an congestion indication
to the RNC. RNC lowers the data rate
to reduce the congestion situation in the
network.
Congestion
Indication
QoS aware HSPA Scheduling
The need for subscriber and service differentiation (QoS) comes with the growing traffic; flat rate tariffs drive the traffic growth
Ability to differentiate services and subscribers on HSPA supports different tariffing plans
Premium services and subscribers will have higher priority over low tariff broadband HSPA data traffic
QoS aware HSPA scheduling enables up to 16 different Scheduling Priority Indicator (SPI) levels for HSPA traffic
SPI is based on RAB parameters: allocation and retention priority, traffic class and traffic handling priority
TC+THP+ARP
Priority (0…15)
Interactive THP1 ARP1
Enables up to 3 interactive or background RABs on HSPA
RAB combination AMR + 3*NRT HSPA is supported
RNC
BTS
NRT RAB #2, streaming with real player
NRT RAB #1, WAP portal
#1, #2 and #3 can have different priorities
Multiplexing at BTS MAC-hs and MAC-e
HSPA in NSN RAS
Introduction to HSUPA
High Speed Uplink Packet Access HSUPA is part of 3GPP radio specification release 6, officially known as E-DCH.
HSUPA works on RAN with no direct impact to CN.
HSUPA only works together with HSDPA
HSUPA works simultaneously with AMR call
HSUPA introduces new physical and transport channels.
HSUPA provides data rate up to 5.76 Mbps(2Mbps in RU10) UL.
HSUPA is backward compatible to previous 3GPP Release.
HSUPA Key Technical Aspects
Fast Retransmission in UL
L1 retransmissions (UE – BTS)
Fast Scheduling in UL
Scheduler considers:
Feedback from UE (happy bit)
Available baseband resources
Transport Channels
E-DCH Absolute Grant Channel (E-AGCH)
E-DCH Relative Grant Channel (E-RGCH)
E-DCH Hybrid ARQ Indication Channel
E-DPDCH
E-DPCCH
E-AGCH
E-DCH
WBTS
RNC
E-RGCH
E-HICH
E-DPDCH – E-DCH Dedicated Physical Data Channel (BPSK) carries uplink user data.
15-960kbps uses SF256-SF4
E-DPCCH – E-DCH dedicated Physical Control Channel (SF256 - BPSK)
uplink channel used to transmit information about the E-DPDCH transmission from the UE to the BTS. Also has information necessary to decode the E-DPDCH. 10 info bits – 7 indicating transport format, 2 indicating the Retransmission Sequence Number (RSN) [1st trans = 0, 1st retrans. = 1, 2nd retrans. = 2, 3rd and all subsequent retrans. = 3] and 1 Happy Bit indicating whether the UE is content with current data rate (relative power). It is Mandatory for it to exist with the E-DPDCH.
E-HICH – E-DCH H-ARQ Indicator Channel
used to indicate ack/nack for the uplink data transmissions. The E-HICH for the serving cell transmits acks and nacks while other cells only transmit acks
E-RGCH –E-DCH Relative Grant Channel (BPSK)
used to transmit single step up/down scheduling commands for the transmit power of the UE E-DPDCH and effectively adjusting the uplink data rate up/down
E-AGCH – E-DCH Absolute Grant Channel
transmits the absolute value of the Node-B schedulers decision that lets the UE know the relative transmission power to use for the E-DPDCH and effectively setting the data rate
Inter-frequency and inter-system mobility is provided via DCH
E-DCH serving cell is always the same as HS-DSCH serving cell
HS-DSCH serving cell change and HS-DSCH serving cell selection algorithms are not changed due to HSUPA
It is more critical for HSDPA than for HSUPA that the serving cell is the best cell as HSDPA does not have soft handover like in HSUPA
E-DCH Active Set is a subset of DCH Active Set
Maximum number of E-DCH Active Set is 3
HSUPA Aspects on WBTS
Only supported together with HSDPA
BTS controlled scheduling of the E-DCH within the limits set by the RNC
Physical layer retransmission handling in the BTS
Maximum number of users/BTS = 60 and users/cell = 20 (RU10)
Peak data rate of 2Mbps (category 4) = 2X SF2 codes
HSUPA Setting on WBTS
Required Baseband Capacity for HSUPA
Due to higher number of HSUPA users and higher throughput CEs pool was extanded
Higher L1 throughput
More HSUPA Users
0
SGSN on Control-plane
I-HSPA is part of 3GPP R7 HSPA Evolution Work Item
I-HSPA is the first step towards LTE/SAE with simplified network architecture
Solution for cost-efficient broadband wireless access with 50% CAPEX savings
Significant OPEX savings enabled by IP/Ethernet transport option and less elements
Improves End-User experience by reducing delays
Deployable with existing WCDMA base stations
IP networks
Enterprise networks
Service providers
The I-HSPA solution architecture locates all the 3GPP radio and bearer
specific functions to the base station. Traffic aggregation and intra-system
user plane mobility is provided by standard SGSN and GGSN. SGSN
controls mobility, but is not needed on the user plane. The I-HSPA user
plane is directly connected to the GGSN and the control plane is
connected to SGSN. This “one tunnel” solution makes the core network
very cost efficient also for high capacities. I-HSPA can also be
implemented without “one tunnel solution” but the SGSN user plane
capacity upgrade then needs to be considered. SGSN and GGSN based
core network secures smooth inter working with the 2G and 3G networks.
791.bin
Standard 3GPP packet core
Standard 3GPP HSPA terminals
No changes to Rel5/6 Terminals
3GPP Rel-7 standardizes the flat architecture for both RAN and PaCo
Flat PaCo: Direct Tunnel defined in SA WG2, for removing SGSN from the U-plane
Flat RAN: HSPA Evolution TR25.999 defines BTS collapsed RNC
RNC ID extension from 4096 to a higher value to allow large I-HSPA network
Carrier Sharing: UE Involved Relocation is agreed at RAN3 #57 (R3-071758)
L1 SHO per UL DCH and E-DCH MAC-d flow (e.g. only SRB MDC)
Iur C
Existing NSN customer with Flexi
Upgrading an existing 3G network which is already based on Nokia Siemens Networks Flexi base station is especially easy as the I-HSPA adapter is based on the same HW architecture as the other Flexi modules. The only work which has to be done at the site would be to plug in the I-HSPA adapter into the Flexi basestation. With the I-HSPA enabled Flexi the operator can fully use I-HSPA and it’s features without limits.
Existing NSN customer with Ultra
Support of I-HSPA for Ultra base stations is planned for a future release. As Ultra and I-HSPA are using the same Iub interface the upgrade of Ultra sites is very handy. In fact only the I-HSPA adapter has to be placed and connected to the site. With the I-HSPA enabled Ultra base station the operator can fully use I-HSPA.
Supported features are:
Optimization for VoIP (e.g. QoS, HC)
Optional MIP Mobility, AAA+HA
Carrier sharing
Existing NSN customer with NB/RS88x
Also support of NB/RS88x is planned for a future I-HSPA release. Bringing I-HSPA to existing Radio Server and NodeB sites offers the advantage using the large market momentum of NB/RS88x base stations worldwide. This overlay solution can be realized in a similar way as for legacy 3G equipment, see point 8.3 above.
I-HSPA Adapter for Rel-1
. 3GPP defined protocols to handle terminals compliant to 3GPP
. Certain Telecom and Mobility signaling procedures
. Header compression as part of PDCP
. I-HSPA specific protocols and procedures
. Authentication and authorization
. Adapter to Adapter interface and related Inter I-HSPA handover, PDP context transfer and paging procedures
. Radio Resource Management
. Allocation & management
. Triggering PDP context re-establishment
For Circuit Switched (CS) handovers, active CS users are moved to CS
network, either GSM/EGDE or 3rd Generation.
Instantanous supported data rate
UE commanded to

01 rn33007en10gla0 hspa in nsn ras

Documents