i-hspa overview i-hspa architecture3

8/10/2019 I-HSPA Overview I-HSPA Architecture3

http://slidepdf.com/reader/full/i-hspa-overview-i-hspa-architecture3 1/19

© Nokia Siemens Networks 1 (19)

I-HSPA overview-

I-HSPA Architecture



I-HSPA overview – I-HSPA Architecture


Legal notice

Intellectual Property Rights

All copyrights and intellectual property rights for Nokia Siemens Networks trainingdocumentation, product documentation and slide presentation material, all of whichare forthwith known as Nokia Siemens Networks training material, are the exclusiveproperty of Nokia Siemens Networks. Nokia Siemens Networks owns the rights tocopying, modification, translation, adaptation or derivatives including anyimprovements or developments. Nokia Siemens Networks has the sole right tocopy, distribute, amend, modify, develop, license, sublicense, sell, transfer andassign the Nokia Siemens Networks training material. Individuals can use the NokiaSiemens Networks training material for their own personal self-development only,those same individuals cannot subsequently pass on that same Intellectual Propertyto others without the prior written agreement of Nokia Siemens Networks. TheNokia Siemens Networks training material cannot be used outside of an agreedNokia Siemens Networks training session for development of groups without theprior written agreement of Nokia Siemens Networks.

Indemnity

The information in this document is subject to change without notice and describesonly the product defined in the introduction of this documentation. This document isintended for the use of Nokia Siemens Networks customers only for the purposes ofthe agreement under which the document is submitted, and no part of it may beused, reproduced, modified or transmitted in any form or means without the priorwritten permission of Nokia Siemens Networks. The document has been preparedto be used by professional and properly trained personnel, and the customerassumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development andimprovement of the documentation.

The information or statements given in this document concerning the suitability,capacity, or performance of the mentioned hardware or software products are given“as is” and all liability arising in connection with such hardware or software productsshall be defined conclusively in a separate agreement between Nokia Siemens

Networks and the customer. However, Nokia Siemens Networks has made allreasonable efforts to ensure that the instructions contained in the document areadequate and free of material errors and omissions. Nokia Siemens Networks will, ifdeemed necessary by Nokia Siemens Networks, explain issues which may not becovered by the document.

Nokia Siemens Networks will correct errors in the document as soon as possible. INNO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS INTHIS DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TOSPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANYMONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT,REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY ORDATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT

This document and the product it describes are considered protected by copyrightsand other intellectual property rights according to the applicable laws.

Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registeredtrademark of Nokia Corporation. Siemens is a registered trademark of Siemens

AG.

Other product names mentioned in this document may be trademarks of theirrespective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2007. All rights reserved.





Table of Contents:

1

Network Architecture before I-HSPA.................................................................. 4

2 I-HSPA Step 1: Collapsed RNC/BTS................................................................. 8

3

I-HSPA Step 2: Direct Tunnel Solution ............................................................ 10

4 I-HSPA Transport Solution .............................................................................. 12

5

I-HSPA and Mobility Management................................................................... 13

6 I-HSPA and Security........................................................................................ 15

7

I-HSPA and Quality of Service (QoS) .............................................................. 17

8 Capacity Options ............................................................................................. 18

9 Exercise .......................................................................................................... 19





1 Network Architecture before I-HSPA

Before starting to investigate the I-HSPA network architecture, let us first examinethe generic architecture of a 3G network.

Please move your mouse pointer over the network elements RNC, SGSN, GGSN,MSC, and SAS for a short description.

Note also the following interfaces: Iub, Iur, Iu-PS, Iu-CS, Iu-PC, and Gn.





2 I-HSPA Step 1: Collapsed RNC/BTS

The basic idea in the I-HSPA solution is to move the packet-switched functions of theRNC to an I-HSPA adapter unit added to the BTS. Consequently, a separate RNC isnot needed any more as far as packet-switched traffic is concerned. Also, the Iubinterface is fully removed from the network.

This architecture is called flat RAN architecture or collapsed architecture in 3GPPtechnical report 25.999.

Note that there are no changes at the air interface. In other words any terminal thatsupports the 3GPP release 5 specifications can be used in an I-HSPA network.

In I-HSPA, the radio resource control (RRC) and radio link control (RLC) protocolsare terminated in the I-HSPA BTS. As a result, the round trip time (RTT) in the userplane is reduced compared to the case where the protocols are terminated in theRNC. Also, I-HSPA reduces the connection setup delay due to the direct signallingbetween the BTS and SGSN.

Very large I-HSPA networks with more than 4095 I-HSPA base stations require thatthe length of the RNC identifier is increased from 12 bits to 16 bits as specified in3GPP release 7. After this change, up to 65536 I-HSPA BTS nodes can be deployedin a single I-HSPA network.

If communication with the circuit-switched core network is required, that is, the user

wishes to make or receive circuit-switched calls, the I-HSPA BTS must also supportthe Iu-CS signalling interface over which paging and hard handover signalling takesplace.





3 I-HSPA Step 2: Direct Tunnel Solution

In the I-HSPA solution it is also possible to implement a direct GTP tunnel betweenthe I-HSPA adapter and the GGSN for carrying the user plane traffic. The signallingin the control plane takes place via the SGSN as before.

The flat packet core network architecture obtained in this way is specified in 3GPPRelease 7 standards.

The SGSN controls the establishment of the direct tunnels, in other words it providesthe I-HSPA adapter with the tunnel endpoint identifier and IP address of the GGSNand the GGSN with the tunnel endpoint identifier and IP address of the I-HSPAadapter. The detailed tunnel establishment procedures are specified in 3GPPtechnical specification 29.060. As before, the SGSN also performs various mobilitymanagement tasks, and may perform security functions and access control tasks.

The direct tunnel solution offers high bitrates in a very cost efficient manner andfurthermore reduces the round trip time (RTT) in the user plane.

It is not mandatory to employ the direct tunnel solution in I-HSPA. However, if thedirect tunnel solution is not used, that is, the user plane traffic is routed via theSGSN, upgrading of the SGSN user plane capacity needs to be considered.





4 I-HSPA Transport Solution

According to the original 3GPP standards, all control plane and user plane traffic inthe radio access network is carried over ATM. As an example, the figure shows thecontrol plane protocol stack at the Iu interface.

As a newer option, it is possible to replace the signalling system number 7 (SS7)based transport protocols with the IP-over-ATM (IPoA) based transport solutionincluding the Sigtran protocols SCTP and M3UA.

In an I-HSPA network, the interfaces are all based on IP transport, both in the controlplane and user plane. The figure shows the control plane protocol stack at the Iuinterface and the user plane protocol stack at the Gn interface, where it is assumedthat a direct tunnel exists between the I-HSPA BTS and the GGSN.

Note the IP-over-Ethernet solution, where IP packets are directly carried withinEthernet frames without first being split up into ATM cells. Direct IP-over-Ethernettransport is also employed at the Iur interface between two I-HSPA adapters.





5 I-HSPA and Mobility Management

I-HSPA supports softer handovers within a single base station and soft handoversbetween two base stations, provided the Iur interface exists between the I-HSPAadapters.

To be more specific, the soft or softer handover is implemented for the associateddedicated channel (DCH) in the case of HSDPA, and the enhanced dedicatedchannel (E-DCH) in the case of HSUPA. Remember that the high speed downlinkshared channel (HS-DSCH) in HSDPA does not support soft or softer handovers.

If the Iur interface does not exist, the inter-I-HSPA handover is always a hardhandover.

Between the I-HSPA network and a WCDMA 3G or GSM 2G network, only hardhandovers are possible. The reason for this is that the Iur interface between an I-HSPA adapter and stand-alone RNC is not yet available in I-HSPA release 1.

When the UE requests a circuit-switched service, the I-HSPA system hands over theUE to a traditional 3G or 2G network. Also mobile terminated calls are possible,provided the Iu-CS interface is available for signalling between the I-HSPA BTS andthe circuit-switched core network.





6 I-HSPA and Security

I-HSPA implements the latest 3GPP security standards for securing the traffic overthe air interface. The 3GPP specified ciphering over the air interface is terminated inthe I-HSPA adapter.

Between the I-HSPA adapter and the packet-switched core network, the transport isoptionally secured using IPSec. In the packet core, the IPSec protection is terminatedin the security gateway - if there is such a separate network element - or in theGGSN in the case of user plane traffic and the SGSN in the case of control planesignalling.

In the I-HSPA adapter, the 3GPP and IPSec ciphering and deciphering takes placewithin a secure domain, for instance a single processor, to prevent eavesdropping.

The I-HSPA BTS is authenticated with a digital X.509 certificate to protect againstattackers masquerading as legitimate base stations.

Finally, centralised user password management enforces regular password updates.





7 I-HSPA and Quality of Service (QoS)

Quality of service (QoS) in I-HSPA basically means that voice-over-IP (VoIP) traffic isprioritised over other traffic in order to minimise the VoIP packet end-to-end delay inthe network.

There are several ways of implementing QoS in an I-HSPA network:

Over the air interface, the scheduling priority indicator (SPI) can be used by theHSPA packet scheduler in the I-HSPA BTS to prioritise VoIP flows relative to otherflows. This functionality will be introduced in I-HSPA release 2.

Admission control in the I-HSPA BTS takes into account the allocation and retentionpriority (ARP), which determines the VoIP bearer priority relative to other UMTSbearers.

In IP transport networks, the differentiated services (DiffServ) QoS mechanism canbe used, where the priority class is indicated in the 8-bit “type of service” field withinthe IP header of each packet. The routers in the IP network then utilise thisinformation when routing the packets through the network to their destination.





8 Capacity Options

There are several I-HSPA capacity options, where each option offers a specificHSPA uplink and downlink capacity.

The capacity of the I-HSPA adapter is defined by the adapter-specific capacitylicence.

The capacity licence sets a limit on the downlink traffic. If the average downlink datarate per second exceeds this capacity limit, packets are dropped.

The uplink capacity limit is equal to the downlink limit divided by three.





9 Exercise

i-hspa overview i-hspa architecture3

Documents