umts bible
TRANSCRIPT
Date:
UMTS Bible- core network
Document history
Version Editor Date Explanation Status1.0 Herjan Barnard 19 February
2001Document created by merging texts of Anton, Toon, and Balint.
Draft
2.0 Paul Tilanus 15 June 2001 Reduction of the document to core network; chapters by Tomas, Bàlint, Titus and Paul added and harmonised.
For internal review
2.1 Paul Tilanus 6 july 2001 Internal review comments processed.
For external review
3.0 Paul Tilanus 27 july 2001 External review comments processed.
Final
KPN Research
Information sheet issued with Report 32731
Title: UMTS Bible – core network
Abstract: The UMTS Bible – core network is an introduction the UMTS core network and the 3GPP standards for the core network. The basics of the UMTS architecture, mobility management and connection management are described in such a way that, as a next step, the 3GPP core network standards can be read without the need to follow the many references of the 3GPP documents.
Author(s): T.H.A.J. Cordenier, B. Rakoczi , P.A.J. Tilanus, U. TitusInternal reviewers: B.J. Busropan, E.B.M. van TilborgExternal reviewers: J.J. Adema, R. Barzani (KPN Mobile NL)
R. Roth (KPN E-plus)C. Smith (KPN Orange)
Department: BIT UMTS NetworksProject: UMTS Core Network - UMTS Bible core networkProject manager: J.M. van LoonProject number: 16785Programme: UMTS Core NetworkCommissioned by: KPN MobielDate: July 2001
For internal use only at KPN
Person responsible at KPN Research: Petula Huising
Key Words: UMTS, 3GPP, core network architecture, mobility management, communication management, call control, session control
Mailing List:
KPN Mobile Holding P. Bosch, W. Helgers, B. LinnemansKPN Mobile NL J.J. Adema, R. Barzani, R. Bennink, J. van den Berg, B. Buijck,
R. Glas, R. Hagedoorn, M. Klepper, H.F. van Oortmarssen, P. Peppelman, S. Stenberg, E. Stringer, H. de Vries.
KPN E-plus M. ShahbazKPN Orange J. de Kock, A. Boeykens, J. McLachlan KPN Research alg dr KPN Research, dr R&D, hfd PPC, M.L. Hofstra, BIT
UMTS Networks
Koninklijke KPN N.V., KPN Research 2001.Alle rechten voorbehouden.Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de rechthebbende. Het vorenstaande is eveneens van toepassing op gehele of gedeeltelijke bewerking.De rechthebbende is met uitsluiting van ieder ander gerechtigd de door derden verschuldigde vergoedingen voor kopiëren als bedoeld in artikel 17, tweede lid, Auteurswet 1912 en het K.B. van 20 juni 1974 (Stb.351) zoals gewijzigd bij het K.B. van 23 augustus 1985 (Stb.471) ex artikel 16b Auteurswet 1912, te innen en/of daartoe in en buiten rechte op te treden.Voor het overnemen van delen van deze uitgave ex artikel 16 Auteurswet 1912 dient men zich tot de rechthebbende te wenden.
Royal KPN N.V., KPN Research 2001.All rights reserved.No part of this book may be reproduced in any form, by print, photoprint, microfilm or any other means without the prior written permission from the publisher.
Contents
Management Summary....................................................................................................7
List of Abbreviations........................................................................................................9
1 Introduction.............................................................................................................13
2 UMTS architecture...................................................................................................15
2.1 UMTS: new access network; existing core network technology.................15
2.2 Domains and reference points........................................................................16
2.3 Network architecture.......................................................................................17
2.4 Interfaces in the UMTS architecture...............................................................182.4.1 Interfaces between Core and Access Network...........................................192.4.2 Interfaces internal to the Core Network.......................................................192.4.3 Other interfaces..........................................................................................20
2.5 Protocol Stacks................................................................................................202.5.1 General protocol model for the UTRAN interfaces......................................202.5.2 The Transport network Control Plane.........................................................222.5.3 Control plane protocol stacks......................................................................242.5.4 User Plane Protocol Stacks........................................................................28
3 UMTS Mobility Management...................................................................................33
3.1 Mobility Management architecture.................................................................343.1.1 Separate and combined CS/PS MM operation...........................................343.1.2 MM architecture of the CS domain..............................................................353.1.3 MM architecture of the PS domain..............................................................353.1.4 Security management (EIR, AuC)...............................................................37
3.2 The hierarchical tracking concept..................................................................373.2.1 The hierarchical area structure...................................................................373.2.2 The level of tracking the user......................................................................393.2.3 Optimal size of system areas......................................................................40
3.3 State machines.................................................................................................413.3.1 RRC state machine.....................................................................................413.3.2 CS/PS service state machine......................................................................423.3.3 Relationship between CS and PS service states and RRC states..............43
3.4 Detailed description of mobility-related procedures....................................443.4.1 UTRAN-related procedures.........................................................................453.4.2 Core network-related procedures................................................................51
For internal use only at KPN 5/100
4 Communication Management................................................................................59
4.1 Circuit switched and Packet switched services............................................59
4.2 Call control (circuit-switched).........................................................................604.2.1 Establishing a mobile originated call...........................................................604.2.2 Establishing a mobile terminated call..........................................................634.2.3 Maintaining a call........................................................................................66
4.3 Session control (packet-switched).................................................................674.3.1 Static and Dynamic PDP Addresses...........................................................684.3.2 Establishing a session.................................................................................684.3.3 Maintaining a session..................................................................................71
4.4 Use of IP based services.................................................................................714.4.1 Access to intranet and Internet...................................................................714.4.2 Virtual Home Environment / Open Services Architecture............................744.4.3 Multimedia Messaging Services..................................................................764.4.4 Location Services........................................................................................794.4.5 CAMEL........................................................................................................834.4.6 Terminal Based Services............................................................................85
5 Introduction to CDMA (UMTS) for core network specialists................................91
5.1 Multiple access: CDMA principles..................................................................91
5.2 Demodulation...................................................................................................935.2.1 Multipath.....................................................................................................935.2.2 Rake receiver..............................................................................................935.2.3 Macro diversity............................................................................................94
5.3 Duplexing: FDD and TDD.................................................................................95
5.4 Radio interface protocol architecture............................................................965.4.1 Logical Channels........................................................................................965.4.2 Transport Channels (FDD)..........................................................................98
6 References.............................................................................................................101
6.1 KPN Research reports...................................................................................101
6.2 Specifications Manual...................................................................................102
Management Summary
Introduction
KPN Mobile will roll out a UMTS network. Those involved in this roll out need at least a basic understanding of the UMTS technology to be able to read the relevant parts of the 3GPP standardisation documents.
Aim
KPN Mobile has a challenge to broaden the knowledge of most of its current employees towards UMTS and to train new employees, while the organisation is under high pressure to cut costs, including training costs. Good books, in particular on the mobile core network, are hardly available. With the 'UMTS Bible - Core Network' we intend to fill this gap.
Audience
The target audience of this UMTS Bible – core network are those who need:
a basic understanding of the UMTS core network, background knowledge regarding the UMTS core network to study the relevant 3GPP
standardisation documents.
Result
Consequently, the UMTS Bible – core network focuses on the following topics:
UMTS network and protocol architecture Mobility management in UMTS Communication management in UMTS
In addition to the description of these topics (and their relations), references are included to the 3GPP UMTS standardisation documents. This makes the UMTS Bible – core network also a good starting point to go to the level of detail of the UMTS Technical Specifications.
For internal use only at KPN 7/100
List of Abbreviations
AAL ATM Adaption LayerACM Answer Complete MessageALCAP Access Link Control Application ProtocolAMR Adaptive Multi RateANM ANswer MessageAPN Access Point NameATM Asynchronous Transfer Mode AuC Authentication CenterBRAN Broadband Radio Access NetworkBSC Base Station ControllerBSS Base Station SubsystemBSSGP Base Station System GPRS ProtocolCAMEL Customised Applications for Mobile Network Enhanced LogicCDR Call Detail RecordCM Call ManagementCN Core NetworkCN Corresponding Node (in Mobile IP)CoA Care-of-AddressCS Circuit SwitchedCSI Camel Subscription InformationDCH-FP Dedicated Channel - Frame ProtocolDHCP Dynamic Host Configuration ProtocolDTMF Dual Tone Multiple FrequencyEDGE Enhanced Data rates for GSM EvolutionEFR Enhanced Full RateEIR Equipment Identity RegisterFA Foreign AgentFACH-FP Forward Access Channel - Frame ProtocolGERAN GPRS EDGE Radio Access NetworkGGSN Gateway GPRS Support NodeGMLC Gateway Mobile Location CenterGMSC Gateway Mobile Switching CenterGPRS General Packet Radio ServiceGSM Global System for Mobile communicationsGSN GPRS Support NodeGTP GPRS Tunneling ProtocolGTP-C GPRS Tunnenling Protocol for the Control planeGTP-U GPRS Tunneling Protocol for the User planeHA Home AgentHLR Home Location RegisterHPLMN Home Public Land Mobile NetworkHTTP Hyper Text Transfer ProtocolIAM Initial Address messageIMEI International Mobiel Equipment IdentityIMSI International Mobile Subscriber IdentityIN Intelligent NetworkIP Internet ProtocolISDN Integrated Services Digital NetworkISUP ISDN User PartLA Location Area
For internal use only at KPN 9/100
00000October 1998
LAC Location Area CodeLAI Location Area IdentiyLCAF Location Client Authorization FunctionLCCF Location Client Control FunctionLCCTF Location Client Co-ordinate Transformation FunctionLCF Location Client FunctionLCS Location ServicesLLC Logical Link ControlLSAF Location Subscriber Authorization FunctionLSBF Location System Billing FunctionLSCF Location System Control FunctionLSOF Location System Operations FunctionLSPF Location Subscriber Privacy FunctionMAC Medium Access ControlMAP Mobile Application PartMCC Mobile Country CodeME Mobile EquipmentMExE Mobile station application Execution EnvironmentMIME Multipurpose Internet Mail ExtensionsMIP Mobile Internet ProtocolMM Mobility ManagementMM Multimedia Message (IP services context)MMS Multimedia Message ServiceMMSE Multimedia Message Service EnvironmentMNC Mobile Network CodeMO Mobile OriginatedMS Mobile StationMSC Mobile Switching CenterMSE MExE Service EnvironmentMSISDN Mobile Subscriber ISDN NumberMT Mobile TerminatedMTP Message Transfer PartNBAP Node B Application PartN-PDU Network-Packet Data UnitNSAPI Network Service Access Point IdentifierO&M Operation and MaintananceOSA Open Service ArchitecturePDCP Packet Data Convergence ProtocolPDN Public Data Network / Packet Data NetworkPDP Packet Data Protocol PDU Packet Data UnitPLMN Public Land Mobile NetworkPPP Point-to-Point ProtocolPRN Provide Roaming NumberPS Packet SwitchedPSE Personal Service EnvironmentPSTN Public Switched Telephone NetworkP-TMSI Packet-Temporary Mobile Subscriber IdentityPVC Permanent Virtual CircuitQoS Quality of ServiceRA Routing AreaRAB Radio Access BearerRAC Routing Area CodeRACH-FP Random Access Channel - Frame Protocol RADIUS Remote Authentication Dial In User ServiceRAI Routing Area IdentityRAN Radio Access NetworkRANAP Radio Access Network Application PartRLC Radio Link ControlRNC Radio Network Controller
For internal use only at KPN10/100
RNS Radio Network SubsystemRNSAP Radio Network Subsystem Application PartRNTI Radio Network Temporary IdentityRRC Radio Resource ControlRRM Radio Resource ManagementSCF Service Control Function (IN context) SCF Service Capability Feature (VHE/OSA Context)SCP Service Control PointSCS Service Capability Server (VHE/OSA Context)SGSN Serving GPRS Support NodeSIFIC Send Information For Incomming CallSIFOC Send Information For Outgoing CallSIM Subscriber Identity ModuleSIP Session Initiated Protocol SM Session ManagementSMS Short Message ServiceSNDCP Sub-Network Dependent Convergence ProtocolSRNC Serving Radio Network ControllerSRNS Serving Radio Network SubsystemSS7 (Common Channel) Signalling System no. 7 SSCF-NNI Service Specific Coordination Function - Network to Network InterfaceSSCF-UNI Service Specific Coordination Function - User to Network Interface SSCOP Service Specific Connection Oriented ProtocolTDM Time Devision MultiplexTEID Tunnel End Point IdentifierTI Transaction IdentifierTMSI Temporary Mobile Subscriber IdentityUDP User Datagram ProtocolUE User EquipmentUICC Universal Integrated Circuit BoardU-LSCF Access Network Location System Control FunctionUMSC UMTS-MSCUMTS Universal Mobile Telecommunications SystemU-PCF UMTS Access Network Positioning Calculation FunctionU-PRCF Positioning Radio co-ordination FunctionU-PRRM UMTS Access Network - Positioning Radio Resource ManagementU-PSMF UMTS Access Network - Positioning Signal Measurement FunctionURA User Registration Area / UTRAN Registration areaURI Uniform Resource IdentifierUSAT USIM Application ToolkitUSIM UMTS Subscriber Identity ModuleUSSD Unstructured Supplementary Service DataUTRAN UMTS Terrestrial Radio Access NetworkVC Virtual CircuitVHE Virtual Home EnvironmentVLR Visitor Location RegisterVMSC Visited Mobile Switching CenterVPLMN Visited Public Land Mobile NetworkWAP Wireless Application Protocol WML Wireless Markup LanguageWSP Wireless Session Protocol
For internal use only at KPN 11/100
1 Introduction
Operators in the KPN Mobile group will introduce a UMTS network. Those involved in this introduction need at least a basic understanding of the UMTS technology to be able to read the relevant parts of the 3GPP standardisation documents. The 3GPP standardisation documents are not easily accessible, e.g. due to extensive referencing between these documents.
For the radio technology of UMTS, W-CDMA, good books are available that provide the required understanding. For the UMTS core network there are sheetbooks that come with some expensive, commercial UMTS training and are targeted at those who attended the training; these sheetbooks are not suited for those who did not attend the training.
The KPN mobile operators have a challenge to broaden the knowledge of most of their current employees towards UMTS and to train new employees, while the organisation is under high pressure to cut costs, including training costs. Good books, in particular on the mobile core network, are hardly available. The vendors can help out to a certain extend, but their training is focussed on the equipment they deliver. Moreover, the employees of KPN mobile operators need the UMTS knowledge to be able to verify if the delivered products comply to the UMTS standards, so an information source other than these vendors is needed. This UMTS Bible – core network can be that information source.
The target audience of this UMTS Bible – core network are those who are going to work on UMTS and need: a basic understanding of the UMTS R’99 core network, background knowledge regarding the UMTS core network to study the relevant 3GPP
standardisation documents.
The scope of this UMTS Bible – core network is limited to R’99 version of the standard. R’99 is the initial version and for the UMTS basics the limitation is not severe. In the referenced standardisation documents no version number is included. When the reader refers to the version number belonging to R’99 the information will match with the UMTS Bible – core network; with a higher version number the future developments can be assessed (which might be important for a future proof network, but are not yet stable at the moment of writing this document).
Consequently, the UMTS Bible – core network focusses on the following topics:
UMTS R’99 network and protocol architecture, including evolution from GSM – GPRS – UMTS domains and reference points network architecture protocol stacks
mobility management in UMTS, including the mobility management architecture hierarchical mobility tracking concept the mobility management state machines description of the mobility related procedures (cell selection, handover, location
management, attach/detach, location update, authentication, etc.).
communication management, including description of differences in circuit switched and packet switched call control in the circuit switched domain session control in the packet switched domain
13/100
use of IP based services Quality of Service.
In addition to the description of these topics (and their relations), references are included to the 3GPP UMTS standardisation documents. All these documents can be downloaded from the 3GPP internet site. A manual to the structure of the specifications is included in Chapter 6.2. This makes the UMTS Bible – core network also a good starting point to go to the level of detail of the UMTS Technical Specifications
For those readers who need a broader view on UMTS, a chapter on W-CDMA is included at the end of the document. It makes it easier for core network experts to understand the issues of their radio colleagues.
The core network of UMTS R’99 is in many aspects very similar to the core network of the GSM/GPRS system, though they are not completely the same.
Important differences between GSM/GPRS and UMTS are highlighted in this 'UMTS Bible – core network', in textblocks like this one. These blocks are also used for other detailled information that might be skipped at first reading.
14/100
2 UMTS architecture
This chapter describes the UMTS architecture. First, the basic premises in the development of the UMTS architecture are described. A section on the UMTS network architecture is preceded by an introduction in the concept of domains and reference points on which these network architectures are based. This chapter is concluded with sections on interfaces and protocol stacks.
2.1 UMTS: new access network; existing core network technology
During the development of UMTS, there was a strong drive to base the UMTS architecture on GSM. This would enable operators to re-use their existing GSM network. And, at least as important, it would ensure that GSM vendors could bring their technology-leadership into the 3G era.
The main new feature that UMTS brings compared to GSM is its broadband radio access. The new CDMA-based radio access technology enables bit rates up to 2 Mbits/s. With this new radio access technology came a new radio access network. New concepts like macro-diversity1 made it unfeasible to reuse the existing GSM radio access network.
The UMTS core network, on the other hand, is completely based on the GSM/GPRS core network. There is only one set of core network specifications that applies for both GSM/GPRS and UMTS. The same circuit switched GSM core network handles circuit switched calls made via either the GSM access network or the UMTS access network. Only minimal modifications were made to the specifications of the circuit switched GSM core network to accommodate UMTS services. Similarly, the same GPRS packet switched core network can handle packet data communication from both the GSM access network and the UMTS access network. The GPRS core network has been updated to some larger extent than the circuit switched GSM core network. Figure 2-1 shows the resulting configuration with a GSM access and a UMTS access and a circuit switched GSM core and a packet switched GPRS core.
GSM AccessGERAN
BTS BSC
BSS
UMTS AccessUTRAN
Node B RNC
RNS
GPRS Core
SGSN GGSN
GSM Core
MSCHLR PSTN/ISDN
Internet
Figure 2-1: UMTS: new access network, existing core network technology
1 Macro diversity allows a mobile station to be connected to several Node Bs. The different signals can be combined, resulting in a better connection quality.
15/100
2.2 Domains and reference points
In order to understand the UMTS network architecture, it is important to first have a look at the concept of UMTS domains and reference points. Figure 2-2 shows a high level picture of the UMTS network architecture consisting of domains and reference points between these domains. A domain is a representation of (a number of) network entities. There can be different implementations of one domain, e.g. both the GPRS and the GSM core network are implementations of a Core Network Domain. A reference point, identifies a point between two domains. On a reference point, one or more interfaces are specified that enable the communication between the two domains.
User EquipmentDomain
AccessNetworkDomain
CoreNetworkDomain
InfrastructureDomain
Cu
MobileEquipmentDomain
USIMDomain
HomeNetworkDomain
TransitNetworkDomain
Uu Iu
[Zu]
[Yu]
ServingNetworkDomain
Figure 2-2: UMTS Domains and reference points
Two very basic domains are the User Equipment Domain and the Infrastructure Domain. In between is the Uu reference point, on which the radio interface is specified. The User Equipment Domain is made up of the USIM (UMTS Subscriber Identity Module) and the Mobile Equipment Domain. In UMTS, the same separation as in GSM is made between subscriber identity in a smart card and the terminal itself.
The infrastructure domain is made up of the Access Network Domain, with base stations and controllers, and the Core Network, with entities like switches, subscriber databases and service nodes. The reference point between the Access Network Domain and the Core Network Domain is called the Iu reference point. The Iu reference point has been defined as a generic reference point that should allow different access networks to work with different core networks. Currently, GPRS and the GSM core networks are standardised as implementations of the Core Network Domain. At the moment only the UMTS Terrestrial Radio Access Network – UTRAN is standardised, though different access network implementations should be possible in the future (e.g. Broadband Radio Access Network – BRAN, or GPRS EDGE Radio Access Network – GERAN).
The core network is sub-divided in Serving Network Domain, Home Network Domain and Transit Domain. When a user is roaming, the Serving Network Domain – the network that currently serves the user – is distinct from the Home Network Domain – the network that holds the user’s subscription. In case the user is not roaming, the Serving Network Domain and the Home Network Domain are the same. The Transit Network Domain represents transport networks that may be needed to establish end-to-end communications.
16/100
References
A detailled description of the different domains used in UMTS can be found in TS 23.101, General UMTS Architecture.
2.3 Network architecture
CoreNetwork
RNS
RNS
Node B
Node B
Node B
Node B
RNC
RNC
Iu
Iu
Iub
Iub
Iur
Figure 2-3: UMTS Terrestrial Access Network (UTRAN)
The UMTS Terrestrial Access Network (UTRAN), depicted in Figure 2-3 is the main new part of the UMTS Network Architecture. It contains the following items:
Node-BNode B is the base station, similar to the BTS in GSM.
RNC (Radio Network Controller)The RNC controls a number of Node Bs. In that, it is similar to the BSC in GSM. However, with the new UMTS Radio technology, the RNC performs quite different functions. In the RNC, the macro-diversity combiner is located that combines signals received via different Node Bs.
RNS (Radio Network Subsystem)One RNC, together with the Node Bs under its direct control form a Radio Network Subsystem (RNS). In a typical access network, there will be multiple RNSs.
With the new network entities in the UTRAN, also new reference points have been defined. Already mentioned was the new Iu reference point between the Access Network Domain and the Core Network Domain. The RNC is always the UTRAN entity that connects to the Core Network Domain and hence the Iu reference point is between the RNC and the Core Network domain. The Iub reference point is the reference point between the Node B and the RNC.
A new concept in UMTS is the direct connection between two different RNCs. There is no similar direct connection between two BSCs in GSM. The direct connection between the RNCs is used in macro diversity. Node Bs included in a macro diversity set may belong to different RNSs. In this case, one RNC is in control and the Node Bs from the other RNS
17/100
are controlled by this RNC via their own RNC. The direct connection between these two RNCs is represented by the Iur reference point.
A macro diversity set is a set of Node Bs between which macro diversity can be used. The Node Bs in the macro diversity set can belong to one or more RNSs.
Figure 2-4 shows the complete UMTS network architecture, including the Core Network Domain. As said, the UMTS Core Network Domain is based on the GSM/GPRS core network. The Mobile Switching Centre (MSC), Gateway MSC (GMSC), Home Location Register (HLR), Visitor Location Register (VLR), Equipment Identity Register (EIR) and Authentication Centre (AuC) are all entities that are also present in the original GSM core network architecture. This is referred to as the circuit switched part (note that HLR, EIR and AuC are also used by the packet switched part). The Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN) were added with the introduction of GPRS, which is referred to the packet switched part.
The User Equipment Domain, is represented by the Mobile Station (MS). The MS can either be a UMTS terminal, a GSM terminal or a multimode terminal. There is both a GSM Subscriber Identity Module (SIM) and a new UMTS Subscriber Identity Module (USIM). The Mobile Equipment (ME) represents the actual terminal equipment without the SIM/USIM.
IP-world
PSTNworld
RNS
BSS
MSCVLR
GMSC
SGSN GGSN
BD
EIR AuCHLR
MSCVLR
B
G
ISUP/ PSTN ISUP
GiGn
H
Gr
Gs
GcGf
F
E
C
A
Other PLMN
Gp
MS
MS
Uu
Iur
UmGb
Iu-PS
Iu-CS
RNC
RNC
Bearer and signallingSignalling only
BGGp
Figure 2-4: UMTS network architecture
References
Detailed information concerning issues described in this section can be found in TS 23.002, Network Architecture, in which the basic and specific entities of the UMTS network are described, including the interfaces. The description is high level and for details, references are provided to corresponding specifications.
2.4 Interfaces in the UMTS architecture
In UMTS mainly two new interfaces were introduced: Iu-CS and Iu-PS. Although most of the other interfaces remain the same as in GSM / GPRS, a short description of the important ones is given below. The interfaces are also given in Figure 2-4.
18/100
2.4.1 Interfaces between Core and Access Network
A-interface, between MSC and the BSS.
GSM interface, which carries information concerning Call Handling, Mobility management and BSS management, for the GSM access network. The transport layer is based on TDM.
Iu-CS interface, between MSC and the RNS.
The UMTS variant of the A-interface. Iu-CS also carries information for Call Handling, Mobility management and RNS management. The transport layer is based on ATM and AAL2.
Gb-interface, between SGSN and BSS.
GPRS interface, used for information transport concerning Mobility management of GPRS users and packet data transmission. The transport layer is based on Frame Relay.
Iu-PS interface, between SGSN and RNS.
The UTMS variant of the Gb-interface. Iu-PS has the same function as Gb and thus carries information concerning Mobility management and packet data transmission. The transport layer is based on ATM and AAL5.
2.4.2 Interfaces internal to the Core Network
B-interface, between the MSC and its associated VLR.
The VLR is the location and management database for the mobile subscribers roaming in the area controlled by the associated MSC(s). Whenever the MSC needs data related to a given mobile station currently located in its area, it interrogates the VLR.
For changes in the state of the MS (location updating, activation of a specific service) the MSC informs or queries the VLR. An update between VLR and HLR may be the result and takes places over the D-interface.
This interface is internal to the MSC/VLR and signalling on it is not standardised.
C-interface, between the HLR and the GMSC.
This interface is used in every procedure where user information for routing is needed. The Gateway MSC interrogates the HLR regarding a subscriber to obtain routing information for a call or a short message directed to that subscriber.
D-interface, between the HLR and the VLR.
This interface is used to exchange data related to the location of the mobile station and to the management of the subscriber. To support the reception or set up of calls within the whole network, the location registers have to exchange data. The VLR informs the HLR of the location of a mobile station managed by the latter and provides it (either at location updating or at call set-up) with the roaming number of that station. The HLR sends to the VLR all the data needed to support the service to the mobile subscriber. The HLR then instructs the previous VLR to cancel the location registration of this subscriber.
Exchanges of data may also occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means.
Gr-interface, between SGSN and HLR.
This interface resembles the D-interface, but now for packet switched services. It is used to exchange the data related to the location of the mobile station and to the management of the subscriber. The SGSN informs the HLR of the location of a mobile station. The
19/100
HLR sends to the SGSN all the data needed to support the service to the mobile subscriber. Note that the SGSN contains a VLR-like database for this. The process is the same as described for the D-interface.
Exchanges of data may also occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means.
The signalling on the D- and Gr-interface uses the Mobile Application Part (MAP), which is part of the SS7.
Gc-interface, between GGSN and HLR.
This optional interface resembles the C-interface, but now for packet switched services. Since sessions are always set-up from the mobile station and not from the external network, this interface is not strictly required, and might be used for exchange of signalling information between GGSN and HLR.
The signalling on the C-interface uses the Mobile Application Part (MAP), which is part of the SS7. If the GGSN supports SS7, then MAP can also be used for the Gc-interface. Alternatively any GSN in the same PLMN as the GGSN and HLR can be used as GTP-to-MAP protocol converter to realise the Gc interface.
Gn- and Gp-interface, between SGSN and GGSN.
These interfaces are used to support mobility between the SGSN and GGSN. The Gn interface is used when GGSN and SGSN are located inside one PLMN. The Gp-interface is used if GGSN and SGSN are located in different PLMNs. The Gn/Gp interface also includes a part that allows SGSNs to communicate subscriber and user data, when changing SGSN. Note that the Gn and Gp interface are the same for GPRS and UMTS.
The role of the Border Gateway (BG) on the Gp interface is to provide the appropriate level of security to protect the PLMN and its subscribers.
Signalling on these interfaces uses the User Datagram Protocol, UDP/IP, as carrier.
Gi-interface, between GGSN and packet domain networks.
In practice the Gi-interface is almost always an IP interface to an intranet or the Internet, though the standard includes the interconnection with X.25 based networks.
2.4.3 Other interfaces
Other interfaces as for example to the Legal Interception Gateway, Charging Gateway, Group Call Register, Location services, CAMEL, etc. are described in the specifications. These interfaces are not depicted in Figure 2-4 to limit the complexity of this figure.
References
For a detailed description of the protocol stacks of the PS domain the reader is advised to consult 3G TS 23.060, the GPRS service description stage 2.
2.5 Protocol Stacks
This chapter describes the protocol stacks within the UMTS architecture. First a general introduction of the protocol model of the UTRAN is given. In subsections 2.5.2, 2.5.3 and 2.5.4 respectively a more detailed description of the transport network control plane, the 'normal' control plane and the user plane is given. To give the reader a better feeling of the interaction between the different planes, an example of a call is given at the end of subsection 2.5.3. It might be useful to refer to this example when reading the detailed
20/100
parts. Finally, at the end of subsection 2.5.4, a comparison is made between UMTS and GPRS for the packet switched domain.
2.5.1 General protocol model for the UTRAN interfaces
In Figure 2-5 the general protocol architecture for the UTRAN is given. The structure is based on the principle that the layers and planes are logically independent of each other. In this way it is possible for standardisation bodies to easily alter protocol stacks and planes to fit future requirements.
ApplicationProtocol
DataStream(s)
ALCAP(s)
TransportNetwork
Layer
Physical Layer
SignallingBearer(s)
TransportUser
NetworkPlane
Control Plane User Plane
TransportUser
NetworkPlane
Transport NetworkControl Plane
RadioNetwork
Layer
SignallingBearer(s)
DataBearer(s)
Figure 2-5: General protocol model for UTRAN interfaces.
Horizontal structure
The Protocol Structure consists of two main layers, the Radio Network Layer, and the Transport Network Layer. All UTRAN related issues are visible only in the Radio Network Layer, and the Transport Network Layer represents standard transport technology that is selected to be used for the UTRAN, but without any UTRAN specific requirements.
Vertical structure
Control plane
The Control Plane includes the Application Protocol, i.e. RANAP, RNSAP or NBAP, and the Signalling Bearer for transporting the Application Protocol messages.
Among other things, the Application Protocol is used for setting up bearers (i.e. Radio Access Bearer) in the Radio Network Layer. The Application Protocol triggers the ALCAP, which sets up AAL2 VCs for the transport of user data, between the Node B and the RNC and (only for CS services) between RNC and MSC. The parameters in the Application Protocol are not directly related to the User Plane technology.
The Signalling Bearer for the Application Protocol can or can not be of the same type as the Signalling Protocol bearer for the ALCAP (e.g. a leased lined can be used for the Application Protocol, whereas for the ALCAP IP is used). The Signalling Bearer is always set up by O&M actions.
User plane
The User Plane includes the data streams and the data bearers for the data streams. They are characterised by one or more frame protocols specified for that specific interface (e.g. RACH-FP, FACH-FP), these are radio specific frame protocols.
21/100
Transport Network Control Plane
The Transport Network Control Plane is a plane that acts between the Control Plane and the User Plane. It includes the ALCAP protocol(s) that are needed to set up the transport bearers (data bearer) for the User Plane. It also includes the appropriate signalling bearers needed for the ALCAP protocol(s) itself.
The introduction of the Transport Network Control Plane makes it possible for the Application Protocol in the Radio Network Control Plane to be completely independent of the technology selected for the data bearer in the user plane. As an example, IP can be used as the data bearer in the user plane and a channel can be set up by SIP.
References
The general protocol architecture is described in TS 25.401, UTRAN Overall Description.
2.5.2 The Transport network Control Plane
The transport network control plane acts between the control plane and the user plane to set up user data bearers. On the Iub interface, this protocol stack is identical for CS and PS services. On the Iu interface, the transport network control plane only exists for CS services and not for PS services because in the user plane AAL5 Permanent Virtual Circuits (PVCs) are present on the Iu-PS interface.
The mechanism of a separate call control and transport network control plane works as follows: If a call control action results in the need for a user data bearer, there is a signalling transaction by the Application Protocol in the Control Plane (see Figure 2-5), which triggers the set up of the user data bearer by the Access Link Control Application Protocol (ALCAP) - for R99 the AAL2 signalling protocol is used, as AAL2 VCs are used in the user plane.
For CS services, the ALCAP (Figure 2-6) sets up AAL2 Virtual Circuits (AAL2 VCs) in the user plane, between the Node B, RNC and MSC, for the transport of user data. For PS services, the ALCAP (Figure 2-7) sets up AAL2 Virtual Circuits in the user plane, between Node B and RNC only. Between the RNC and SGSN for PS services AAL5 PVCs are present. This can be seen in the protocol stacks of the user planes in Figure 2-11 (for PS) and Figure 2-12 (for CS).
SCCF-UNI
SSCOP
AAL5
ATM-pvc
L1
SCCF-NNI
SSCOP
AAL5
ATM-pvc
L1
Q2630.1
Q2150.1
MTP3b
RNC MSCNode B
Q2150.2
-
Q2630.1
RELAY
SCCF-UNI
SSCOP
AAL5
ATM-pvc
L1
Q2150.2
-
Q2630.1
SCCF-NNI
SSCOP
AAL5
ATM-pvc
L1
Q2630.1
Q2150.1
MTP3b
ALCAP
Iub Iu_cs
Figure 2-6: Protocol stack for CS Transport Network Control Plane.
22/100
SCCF-UNI
SSCOP
AAL5
ATM-pvc
L1
RNCNode B
Q2150.2
-
Q2630.1
SCCF-UNI
SSCOP
AAL5
ATM-pvc
L1
Q2150.2
-
Q2630.1
ALCAP
Iub
Figure 2-7: Protocol stack for PS Transport Network Control Plane.
ATM: Asynchronous Transfer Mode: ATM is a cell-based, label-switched transport protocol. The information to be transmitted is divided into fixed-size cells (53 octets), multiplexed, and transmitted. It is asynchronous in the sense that the recurrence of cells containing information from an individual user is not necessarily periodic.
AAL: ATM Adapation Layer: The part of the ATM protocol that breaks up application packets into 48-byte payloads which become ATM cells when the 5-byte headers are attached. The AAL resides between the higher layer transport protocols and the ATM layer.
AAL-2: ATM Adaptation Layer Type 2: AAL functions in support of variable slow bit rate, traffic.
AAL-5: ATM Adaptation Layer Type 5: AAL functions in support of variable bit rate, delay-tolerant connection-oriented data traffic requiring minimal sequencing or error detection support
ATM-PVC: ATM-Permanent Virtual Circuit:A link with a static route, defined by O&M.
SSCF: Service Specific Coordination Function: SSCF is an in-between function serving as translator between layer 3 (for example MTP3b) and SSCOP. UNI is used at the User to Network interface, NNI is used at Network to Network interfaces.
SSCOP: Service Specific Connection Oriented Protocol: An adaptation layer protocol, which is responsible for data delivery between AAL points (sequence ordering, selective re-transmission, flow and connection control).
MTP3b: Message Transfer Part, layer 3.MTP 3 provides message routing between signaling points in the SS7 network. It reroutes traffic away from failed links and signaling points and controls traffic when congestion occurs. MTP3b is used in case ATM is used as the transport for SS7.
23/100
Q2630.1Q2630.1 specifies the inter-node protocol and nodal functions that control AAL type 2 point-to-point connections. The AAL type 2 signalling protocol is usable in switched and non-switched environments and can operate in public or private networks over a range of signalling transport protocol stacks. Q2150.1 / Q2150.2Q2150.1 and Q2150.2 are ITU-T specifications that specify the AAL2 signalling transport converter on broadband MTP and on SSCOP.
The Transport Network Control Plane does not include any Radio Network Layer information, and is completely in the Transport Layer.
ALCAP might not be used for all types data bearers. If there is no ALCAP signalling transaction, the transport network control plane is not needed at all. This is the case when pre-configured data bearers are used.
References
In TS 25.410, UTRAN Iu Interface: General Aspects and Principles and TS 25.430, UTRAN Iub Interface, information on the transport network control plane is found. Details on the other protocols described in this section can be found in the following specifications:
ATM is specified in ITU-T I.361. AAL5 is specified in ITU-T I.363.5. SCCF at NNI is specified in Q.2140. SCCF at UNI is specified in Q.2130. SSCOP is specified in Q.2110. MTP3b is specified in Q.2210. Q2630.1 is an ITU-T specification of the AAL type 2 signalling protocol. Q2150.1 is an ITU-T specification of the AAL type 2 signalling transport converter on
broadband MTP Q2150.2 is an ITU-T specification of the AAL type 2 signalling transport converter on
SSCOP.
2.5.3 Control plane protocol stacks
This paragraph describes the protocol stacks for the control plane of UMTS. In Figure 2-8 the protocol stack for the packet switched part is depicted. The figure is followed by a description of the different layers. Figure 2-10 displays the circuit switched variant. From the figures it can be concluded that the protocol stacks are identical from the Uu interface up to and including the Iu interface, apart from the upper management layer. Different stacks are found in the Core Network.
It is - although already mentioned - important to realise that in UMTS two control planes exist. The 'normal' control plane is responsible for the common call control functions (e.g. call or context set up). The protocol stacks are described in this subsection.
The transport network control plane is responsible for the set up of user plane data bearers, as described in subsection 2.5.2.
24/100
MS
GMM/SM/SMS
MAC
L1
RLC
RRC NBAP
MAC
L1
RLC
RRC
RELAY
SCCF-UNI
-
SSCOP
AAL5
ATM-pvc
L1
Node B
NBAP
SCCF-UNI
-
SSCOP
AAL5
ATM-pvc
L1
RANAP
SCCF-NNI
SSCOP
AAL5
ATM-pvc
L1
RELAY
-
SCCP
MTP3b
RANAP
SCCF-NNI
SSCOP
AAL5
ATM-pvc
L1
-
SCCP
MTP3b
GMM/SM/SMS
RNC SGSNUu Iub Iu_ps
-
UDP
IP
AAL5
ATM-pvc
L1
-
-
-
GTP-C
Gn or Gp
RELAY
-
UDP
IP
AAL5
ATM-pvc
L1
-
-
-
GTP-C
GGSN
Figure 2-8: Protocol stack for UMTS PS control plane from MS - 3G GGSN.
Note: Some of the layers already are explained in paragraph 2.5.2.
GMM/SM/SMS: UMTS Mobility Management and Session Management/Short Message Service: GMM supports mobility management functionality such as attach, detach, security, and routing area update. SM supports PDP context2 activation and PDP context deactivation. SMS supports the mobile-originated and mobile-terminated short message service.
RRC: Radio Resource Control:The RRC offers the following services to upper layers: general and dedicated control, notification. The RRC layer provides signalling connections to the upper layers to support the exchange of upper layer's information flow over the radio interface. The signalling connection is an acknowledged-mode link between the user equipment and the core network to transfer upper layer information. For each core network domain, at most one signalling connection may exist at the same time. The RRC layer maps the signalling connections for one MS on a single RRC connection.
RLC: Radio Link Control:The Radio Link Control sublayer is a part of L2 and is situated on top of the MAC sublayer. The RLC does not offer any new channels or channel types, it ‘just’ performs Radio Link Control on the logical channels that are offered to it by the MAC and then in turn offers these ‘RLC bearers’ to the higher (sub)layers.
MAC: Medium Access Control:The MAC (Medium Access Control) offers ‘logical’ channels and associated services to higher (sub)layers. It also performs the functions to reliably operate these logical channels. The MAC offers these logical channels by mapping them on top of the transport channels offered by the physical layer.
The logical channels offered by the MAC come in two flavours: control channels (CCH) and traffic channels (TCH). This is also reflected in the split into an U-plane (traffic channels) and a C-plane (control channels). Control channels only transfer control information, traffic channels only transfer user information.
NBAP: NodeB Application Part:The NBAP provides all kinds of Cell, Channel, System and Radio management, Measurement possibilities (and reporting of measurements) and Control actions. Some of these are e.g. Cell Configuration Management, System Information Management, Resource Event Management, Configuration Alignment, Radio Link Management, Compressed Mode Control [FDD] and Reporting of General Error Situations.
2 A PDP context is a set of information regarding a certain packet data flow. This information includes among others the endpoints of the data flow (addresses) and the quality of service. Refer for more details to section 4.3.
25/100
RANAP: Radio Access Network Application Protocol: This protocol encapsulates and carries higher-layer signalling and handles signalling between the 3G-SGSN and UTRAN. It is also responsible for the set up of GTP tunnels - for PS services - over the AAL5 PVCs between the SGSNs and the RNC (one AAL5 connection can be shared by multiple GTP tunnels).
SCCP: Signaling Connection Control Part:SCCP provides connectionless and connection-oriented network services above MTP Level 3. While MTP3 allows messages to be addressed to specific signaling points, SCCP allows messages to be addressed to specific applications (called subsystems).SCCP also provides the means to perform global title translation, a procedure by which the destination (signaling point and subsystem number) is determined from digits (i.e., the ISDN number) present in the signaling message.
GTP-C: GPRS Tunnelling Protocol for the control plane: This protocol tunnels signalling messages between SGSNs and GGSNs (Gn), and between SGSNs in the backbone network (Gp).
UDP: User Datagram Protocol: UDP is used in case no special reliable link is needed (or reliability is already assured by another layer). In this stack, the protocol transfers signalling messages between GSNs.
IP: Internet Protocol:The IP part of the TCP/IP communications protocol. IP implements the network layer and accepts "packets" from the transport protocol (TCP or UDP), adds its own header to it and delivers a "datagram" to the data link protocol. Within UMTS it is used for routing user data and in this stack for routing control signalling. The backbone network may initially be based on the IPv4, ultimately, IPv6 shall be used.
Replaceable part on the Iu-PS interface.
The left part of Figure 2-9 can be replaced by its right part.
SCCF-NNI
SSCOP
MTP3b M3UA
IP
SCTP
Figure 2-9: Replaceable part on Iu-PS interface
For the circuit switched control plane no new layers are introduced on the Iu interface, exept for the MM/CM. A difference is obviously found in the MSC. On the core network side, a normal SS7 stack can be found, which is shortly described in this section. A description of most layers seen in Figure 2-10 can be found in the text covering Figure 2-8 or in subsection 2.5.2.
26/100
MS
MM/CM/SMS
MAC
L1
RLC
RRC NBAP
MAC
L1
RLC
RRC
RELAY
SCCF-UNI
-
SSCOP
AAL5
ATM-pvc
L1
Node B
NBAP
SCCF-UNI
-
SSCOP
AAL5
ATM-pvc
L1
RANAP
SCCF-NNI
SSCOP
AAL5
ATM-pvc
L1
RELAY
-
SCCP
MTP3b
ISUP
RANAP
SCCF-NNI
SSCOP
AAL5
ATM-pvc
L1
-
SCCP
MTP3b
MM/CM/SMS
MTP1
SCCP
MTP3
MTP2
TCAP
MAP
RELAY
RNC MSCUu Iub Iu_cs SS7
Figure 2-10: Protocol stack for UMTS CS control plane from MS - MSC.
MM/CM/SMS: Mobility Management/Call Management/Short Message Service:MM supports the location updating. CM supports call set up and release. SMS supports the mobile-originated and mobile-terminated short message service.
MAP: Mobile Application Part:The MAP protocol stack used at many different interfaces for non-circuit related services e.g. Mobility Management and Short Message Service. The MAP protocol is also used in the process to find routing information (interaction of (G)MSCs / GSNs with VLRs, HLRs).
TCAP:Transaction Capability Application Part.TCAP messages are used to support non circuit-related, connectionless information exchange. Among other things, TCAP messages are used to send queries to databases (such as a query to the Home Location Register, using MAP, carried over TCAP) and to return the database response.
ISUP: Integrated Services Digital Network user part:ISUP is a layer of the SS7 protocol; ISUP messages are connection-oriented messages used to set up and tear down telephone calls; ISUP defines a handshaking protocol that initiates the phone call, reserves a path for the voice or data between the originating and destination devices, and ultimately releases the call; Note that despite the name of this part of the SS7 stack, ISUP messages are not limited to ISDN calls.
MTP1, MTP2, MTP3: Message Transfer Part:MTP is part of SS7 protocol stack. It is divided into three levels.
MTP1 is equivalent to the OSI Physical Layer and defines the physical, electrical, and functional characteristics of the digital signaling link.
MTP 2 ensures accurate end-to-end transmission of a message across a signaling link. It implements flow control, message sequence validation, and error checking. When an error occurs on a signaling link, the message (or set of messages) is retransmitted.
MTP 3 provides message routing between signaling points in the SS7 network. It reroutes traffic away from failed links and signaling points and controls traffic when congestion occurs.
SS7: Common Channel Signaling System No. 7 SS7 is a global standard for telecommunications defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T). The standard defines the procedures and protocols by which network elements in the public
27/100
switched telephone network (PSTN) exchange information over a digital signalling network to effect wireless (cellular) and wireline call setup, routing and control.
Example
To clarify the mechanism of the different planes (two control planes and a user plane) the following examples are given:
Set up of a mobile terminated call
Imagine a mobile user is called. The mobility management procedures have been performed and the MSC has the correct routing information (Mobile Station Roaming Number). The 'normal' control plane is of importance now. Refering to Figure 2-10, an Initial Address Message for the set up of a call, arrives at the MSC . The Call Management protocol in the UTRAN is responsible for call control related procedures (setup, alerting, call confirm, etc). These messages are transported transparently over the UTRAN, being relayed by the RANAP to NBAP and NBAP to RRC. At this moment however (when a call set up over the UTRAN is initiated), the RANAP protocol also triggers the AAL2 signalling protocol (ALCAP in general) of the transport network control plane, depicted in Figure 2-6. This control plane is responsible for the set up of an AAL2 VC in the user plane, between MSC, RNC and Node B. Speech data will finally be transported over this bearer, which is depicted in the protocol stack of Figure 2-12.
Set up of a PDP context
In case a MS initiates a PDP context set up, Session Management information is transparently transferred over the UTRAN in the 'normal' control plane (refer to Figure 2-8 for the protocol stack) for the establishment of GTP tunnels. Control signalling is relayed by the RRC to NBAP and NBAP to RANAP. It is at this point, that the transport network control plane comes into the picture again. At the moment of PDP context setup by the SM, the NBAP triggers the AAL2 signalling protocol (refer to Figure 2-7) for the set up of an AAL2 VC in the user plane (Figure 2-11), between the Node B and the RNC (remember that between RNC and SGSN AAL5 PVCs are present in the user plane). Between the RNC and SGSN, on the Iu-PS interface, the GTP tunnels (Figure 2-11)are established in the user plane by the RANAP protocol (Figure 2-8) in the control plane. Further down in the core network, the GTP tunnels of the user plane are established by the GTP-C protocol.
References
For the packet switched part, a lot of information can be found in TS 23.60: GPRS Service description. Some information about the cs part can be conducted from this standard also. A more detailed view on the protocol subject can be obtained by combining the following specifications:TS 25.410: UTRAN Iu Interface: General Aspects and Principles,TS 25.430: UTRAN Iub Interface: General Aspects and Principles.For a description of RANAP and NBAP the following specifications are valid:TS 25.413: UTRAN Iu Interface RANAP Signalling,TS 25.433: UTRAN Iub Interface NBAP Signalling.
2.5.4 User Plane Protocol Stacks
In the following, the user planes for UMTS packet switched and circuit switched are described. Note that for the MS, Node B and RNC both the cs and the ps protocol stack is shown in the figures. In this way it is clearly visible which parts coincide and which not. At the end of this subsection, background information is given on the GPRS facts.
28/100
It is important to realise that on the Iub interface, no distinction between PS and CS traffic is made. Both circuit switched and packet switched services are transported over AAL2 circuits. Again, pay some attention to the mechanism with which the transport network control plane sets up the user plane bearers: As explained in subsection 2.5.2 these AAL2 VCs in the user plane are set up by the AAL2 signalling protocol (in general ALCAP) in the transport network control plane.
For CS services this is done on the Iub and Iu-CS interface whereas for PS services this is only done on the Iub interface. On the Iu-PS interface, AAL5 PVCs are provided in which the RANAP protocol establishes GTP tunnels towards the core network.
The reader is advised to combine the information in Figure 2-6 and Figure 2-7 with the user plane bearers found in Figure 2-11 and Figure 2-12, to fully comprehend the mechanism. The example at the end of subsection 2.5.3 can assist in clarifying the subject.
UDP
IP
AAL5pvc
ATM
L1
GTP-U
RNCUuIub Iu_ps
-
ATM
L1
-
AAL2 AAL2
1 2 3 4
pscs
ATM
L1
-
AAL2L1
MAC
RLC
PDCP -
L1
MAC
RLC
- PDCP
4 3 2 1
Node BMS
Iu UPps
ATM
L1 L1
SGSN
UDP
IP
AAL5 PVC
GTP-U
L2
UDP
IP
GTP-U
ps cspscs
-
RELAY
L1
L2
UDP
IP
GTP-U
-
PSAppl.
GGSNGn
Iu UPcs
Iu UPps
RELAY
1 2 3 4 1 2 3 4
RELAY
Figure 2-11 : Protocol stack for UMTS PS User plane.
Note: Some of the layers are already described in subsection 2.5.2 and 2.5.3.
"Radio" channels 1, 2, 3, 4:These elements represent the Random Access Channel Frame Protocol (RACH FP), Forward Access Channel Frame Protocol (FACH FP), Dedicated transport Channel Frame Protocol (DCH FP) etc. Specific channels are used for specific data streams. E.g. for voice a DCH is used on the radio link. The RNC already maps the data onto the right frame protocol. For each frame protocol a separate AAL2 VC is set up. For more information on the radio channels, the reader is referred to subsection 5.4.2 and to the specifications.
PDCP: Packet Data Convergence Protocol: This transmission functionality maps higher-level characteristics onto the characteristics of the underlying radio-interface protocols. PDCP provides protocol transparency for higher-layer protocols. PDCP supports e.g., IPv4, PPP and IPv6. Introduction of new higher-layer protocols shall be possible without any changes to the radio-interface protocols. PDCP provides protocol control information compression.
Iu UP cs, ps:The Iu UP protocol is used to convey user data associated to Radio Access Bearers. One Iu UP protocol instance is associated to one RAB only. If several RABs are established towards one given MS, then these RABs make use of several Iu UP protocol instances.The Iu UP can operate in two modes: - transparent mode, in which the Iu UP layer only transfers PDUs between upper and
transport network layer - support mode for predefined SDU size: intended for RABs that do require particular
features form the Iu UP protocol in addition to the transfer of data.
29/100
This particular feature can be e.g. frame rate addation for AMR speech. Other functions performed in 'support mode for predefined SDU size Service' are: rate control, time alignment, handling of error event, frame quality classification.
GTP-U: GPRS Tunnelling Protocol for the user plane: This protocol tunnels user data between UTRAN and the 3G-SGSN, and between the GSNs in the backbone network. All PDP PDUs shall be encapsulated by GTP.
Iu UPps
UDP
IP
AAL5pvc
ATM
L1
GTP-U
RNCUuIub Iu_cs
-
ATM
L1
-
AAL2 AAL2
1 2 3 4
ps cs
ATM
L1
-
AAL2L1
MAC
RLC
- PDCP
L1
MAC
RLC
PDCP -
Node BMS
-
AAL2
ATM
L1
TDM
L1
MSCpscsps cs
-
TDM
L1
-
CSAppl.
1 2 3 4
GMSC
4 3 2 1 1 2 3 4
RELAY
Iu UPcs
RELAY
Iu UPcs
RELAY
Figure 2-12: Protocol stack for UMTS CS User plane.
Most of the layers in Figure 2-12 already have been explained in the text covering Figure 2-11 and subsections 2.5.2 and 2.5.3. Only in the MSC on the core network side TDM is introduced.
TDM: Time Devision Multiplex:A technology that transmits multiple signals simultaneously over a single transmission path. A timeslot is reserved for each data stream and the bits are interleaved one after the other.
GPRS specific:
Relay
NetworkService
GTP-U
Application
IP
SNDCP
LLC
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1bis
RLC
MAC
GSM RF
BSSGP
L1bis
Relay
L2
L1
IP
L2
L1
IP
GTP-U
IP
Um Gb Gn GiMS BSS SGSN GGSN
NetworkService
UDPUDP
Figure 2-13: User plane of the packet switched part for MS-GPRS
GTP-U:For GPRS, the protocol tunnels user data between GPRS Support Nodes in the backbone network. All PDP PDUs shall be encapsulated by GTP. Note that GTP-U in UMTS is used over a wider part of the network than in GPRS.
SNDCP: Subnetwork Dependent Convergence Protocol: This transmission functionality maps network-level characteristics onto the characteristics of the underlying network.
30/100
LLC: Logical Link Control: This layer provides a highly reliable ciphered logical link. LLC shall be independent of the underlying radio interface protocols in order to allow introduction of alternative GPRS radio solutions with minimum changes to the NSS.
BSSGP : Base Station System GPRS Protocol: This layer conveys routeing- and QoS-related information between the BSS and the SGSN. BSSGP does not perform error correction.
NS: Network Service: This layer transports BSSGP PDUs. NS is based on the Frame Relay connection between the BSS and the SGSN, and may - multi-hop and traverse a network of Frame Relay switching nodes.
GSM RF:As defined in GSM 05 series.
References
A lot of information, both for UMTS and GPRS can be found in TS 23.60: GPRS Service description More detailed information is found in:TS 25.410: UTRAN Iu Interface: General Aspects and Principles,TS 25.430: UTRAN Iub Interface: General Aspects and Principles.The UTRAN Iu interface user plane protocols can be found in TS 25.415.Furthermore: PDCP is specified in 3G TS 25.323. SNDCP is specified in GSM 04.65. LLC is specified in GSM 04.64. BSSGP is specified in GSM 08.18. NS is specified in GSM 08.16.
31/100
3 UMTS Mobility Management
The main goal of Mobility Management (MM) is to find a user in a mobile network. Whereas in a fixed network the user can be found based on the geographic information contained within the telephone number, in mobile communications this works differently. In case a mobile user is called, first the location of the mobile user is retrieved from a database, then the call is routed based on that information. The location information in the database is updated when the user registers to the network or moves to a different location. An illustration of the concept is shown in Figure 3-14.
Figure 3-14: The concept of Mobility Management
Although the concept may sound simple at first, the realisation is much more complex. First of all an appropriate architecture (e.g. databases, gateways) is needed that supports the mobility management functions. This architecture will be briefly described in section 3.1.
An interesting question is how and in what terms the user’s location is determined by the network. For this purpose size-varying geographical areas are defined and controlled by the network. The user is tracked at different levels of these areas. The area concept is described in more details in section 3.2.
The characteristics of Mobility Management procedures being carried out depend also on the status of the MS. For instance, a communicating MS handles a MM event (e.g. location update) differently than a non-communicating MS or a switched-off MS. For this reason, state machines are implemented both in the MS and in the network, which are kept synchronised. The concept of state machines is described in section 3.3.
The network elements incorporating MM functions have to communicate with each other using a common “language”, therefore protocols and procedures (performed via exchange of protocol messages) are standardised. Procedures realising Mobility Management and their position in the overall UMTS protocol stack is discussed in section 3.4.
32/100
DB
A
Where is John?Where is John?John is at A!John is at A!
Call JohnB
I am at location A
Route to A
GW
1
2
3
4
In general, Mobility Management is a very important element of a mobile network. As such, it is implemented throughout the whole network infrastructure, despite the distinction made between the MM function of the radio access and core domain. In this chapter both areas will be addressed with extra attention to the core domain.
3.1 Mobility Management architecture
UMTS network is logically divided into two parts: Radio Access Network (RAN or UTRAN) and Core Network (Core or CN) connected via an open interface (Iu).
Figure 3-15: Separate Mobility Management for the UTRAN and for the Core Network
Both domains incorporate Mobility Management functions (see Figure 3-15):
UTRAN MM takes place between the MS and the radio access network and it is used only when the MS already has a dedicated radio connection established with the UTRAN (e.g. a communicating MS is being served). In this case the MM function is handled by the Radio Network Controller (RNC) residing in the UTRAN (see Figure 2-4).
Core MM takes place between the MS and the core network and it is used when the MS has no dedicated radio connection with the UTRAN (e.g. non-communicating but moving MS). The Core MM function is distributed network-wide over several core network elements.
Further on, the Core MM has two instances: the Circuit Switched (CS) MM and a Packet Switched (PS) MM. Depending on what kind of service is used (PS, CS or both) the corresponding domain MM is in operation.
3.1.1 Separate and combined CS/PS MM operation
Normally, the PS and CS MM functions are separated and operate independently of each other. In most cases, however, the separate MM operation of the two domains results in a non-optimal use of radio resources (e.g. when the MS changes location, it has to maintain two separate MM signalling connection via a single radio interface). To avoid this, it should be possible for the MS to perform combined MM procedures.
In the old GSM/GPRS architecture the support for combined PS and CS mobility mechanism is accomplished by means of an interface called Gs (see Figure 2-4) whereby an association between MSC and SGSN is created (e.g. a MS connected to the SGSN can now carry out MM procedures for both PS and CS modes). In UMTS Release 99 it is also possible to have a joint MSC/SGSN node called UMSC providing combined PS and CS capability (operator option). UMTS Release ’99 compatible terminals should support the use of both combined and separate mechanism. The support of this feature by all UMTS mobiles will also ease evolution of UMTS MM in future.
Some more detail on combined MM (e.g. combined location update, combined attach) can be found in section 3.4.2.
References
33/100
MS RAN CN
UTRAN MM
Core MM
Uu Iu
More information on the issues discussed in this section can be found in TS 29.016, regarding the Gs interface network service specification, in TS 29.018, about the Gs interface layer 3 specification, and in TS 23.121 on the requirements of combined MM procedures.
3.1.2 MM architecture of the CS domain
The mobility architecture consists of the functional elements of Mobility Management and their inter-relation. In order to understand both, we will explain the architecture with an example of an incoming call. The description can be followed in Figure 2-4.
In case of an incoming CS call (e.g. speech connection request), first the Gateway Mobile Switching Centre (GMSC) residing at the edge of CS domain receives the call. This indicates that the call is intended for a mobile user. Then the GMSC interrogates the Home Location Register (HLR) and asks for the location of the user. Based on this information the call is routed to the serving MSC. Finally the MSC makes contact with the MS via the UTRAN network on a non-dedicated radio channel (this procedure is called paging). In the serving MSC the location of the user is known with higher accuracy (e.g. at the level of location areas) than in the HLR where only the address of the serving MSC is given.
The HLR and the GMSC are always located in the user’s home network3, whereas the serving MSC and the serving UTRAN network connected to this MSC are located in a visited network, which may be different from the home network (e.g. in case of roaming). The HLR plays a very important role in the whole procedure, since it is the only one that knows (at least at the level of the MSC areas) where each subscriber of the home network is located. The MS keeps the HLR up-to-date by mean of a so-called location update procedure.
The MM function in the visited network is carried out by a local database called Visited Location Register (VLR) that is connected to the serving MSC. This entity handles attach (or registration) of the MSs moving into the coverage of the MSC/VLR, allocates local temporary identity for the MS, maintains the user location information at the level of location areas and transfers location update towards the HLR when the serving MSC changes. The location information and other data concerning the user are stored in the VLR as long as the user is located within the coverage of the MSC/VLR.
More detail on the above-mentioned local MM procedures can be found in section 3.4.
3.1.3 MM architecture of the PS domain
The Mobility Management taking place in the PS domain is very similar to that of the CS domain with some slight differences. To follow the description below, see Figure 2-4.
In the PS domain the role of GMSC is taken by the Gateway GPRS Support Node (GGSN), and the role of MSC is taken by the Serving GPRS Support Node (SGSN). The VLR function is incorporated in the SGSN that stores user location information at the level of routing areas. In case of an activated PS session4 (e.g. an Internet connection), the GGSN receives the IP packets of the session from the external network, it looks for the destination of the MS and routes the IP packets to the SGSN serving the routing area where the MS is currently located.
The routing between SGSN and the GGSN is carried out by a so-called tunnelling mechanism. Detailed description of tunnel setup can be found in section 4.3.2.
3 The user’s home network is the mobile network where the user is subscribed for the service. The subscriber information is stored in the HLR of the home network.4 Only the user can activate a PS session, whenever he intends to use packet-switched services (this is called PDP context activation in GPRS). The network initiated PDP context activation is part of the UMTS R’99 standard, but not yet implemented in today’s network elements.
34/100
Figure 3-16: Tunnelling between GGSN and SGSN
Figure 3-17: The tunnel endpoint changes as the MS moves (the IP address of the MS does not need to change)
Tunnelling in the PS domain is not only a simple routing method, it also resolves the problem of “moving IP end-points”. In a normal IP network the routing function is static by nature, unlike in GPRS, where the IP end-point moves as the MS changes its location. The idea of tunnelling is that each packet intended for a MS is first encapsulated and sent to the serving SGSN, and then this SGSN is in charge of setting up the end-link to the MS according to its current position. The tunnel endpoint address changes only when the MS moves into the coverage of another SGSN (see Figure 3-16. and Figure 3-17). The GGSN receives the address of the new SGSN from the HLR as soon as the HLR is updated by means of a routing area update procedure.
References
A description of GTP tunnelling can be found in TS 23.060.
3.1.4 Security management (EIR, AuC)
There are some other network elements depicted in Figure 2-4 that still have to be addressed. These are the Authentication Centre (AuC) and the Equipment Identity Register (EIR). Their function, the Security Management, is vital, but not an inherent part
35/100
MS
PS domain To: MS
To: SGSN A
GGSN
SGSN A
SGSN B
MS
PS domain To: MS
To: SGSN B
GGSN
SGSN A
SGSN B
MS
of the Mobility Management. Though, we usually discuss the two functions together, since they are performed using the same equipment (e.g. MS, HLR) and they interact in the same procedures (e.g. registration).
Whenever the user attempts to gain access to the, first he must be authenticated to this network. The access is granted from his home network via an advanced authentication procedure (ciphering) as part of the registration process. The secret keying material used for this authentication is obtained from the AuC database of the home network.
The mobile terminal may get stolen or malfunctioning. If it happens, the equipment is marked in the EIR, and next time when the user attempts to get access to UMTS network by using this terminal, the status of the terminal will be checked in the EIR and the access will be denied or restricted. This procedure is called IMEI check or equipment identity check, which is also usually part of the registration procedure.
More detail on security management can be found in section 3.4.
References
In TS 23.121 the requirements on UMTS Mobility Management can be found, which is an elaboration of the general requirements on UMTS in TS 22.100. More towards the realisation of these requirements are TS 33.002, the description of the functional elements of the MM architecture and TS 23.008 on the organisation of location information stored in different registers.
3.2 The hierarchical tracking concept
The MS can be tracked at different levels of system areas depending on the status of the connection the MS has with the network. If the MS has a dedicated radio connection established with the network then the user is tracked within the serving UTRAN (UTRAN MM), otherwise he is tracked in the core network (Core MM). To allow the location of the MS to be perceived at different levels, the concept of hierarchical system areas was introduced to UMTS. First the structure of system areas is described in subsection 3.2.1 and then the concept of hierarchical tracking is described in subsection 3.2.2. For optimal use of the tracking system, optimal sizes of system areas have to be chosen. This issue will be discussed in subsection 3.2.3.
3.2.1 The hierarchical area structure
A possible configuration of system areas is shown in Figure 3-18. The difference between the various system areas will be explained in this figure.
36/100
Figure 3-18: Structure of system areas
System areas that are solely used within UTRAN are distinguished from those that are used in the core network.
System areas of the UTRAN are as follows:
The cell is a slightly different concept in UMTS R’99 than in GSM/GPRS. It can denote either the coverage area of a Node B station or one sector antenna of a Node B (see Figure 3-18: green circles). This is the smallest area that a MM function is able to perceive.
The UTRAN routing area (URA) is a new concept in UMTS R’99 (see Figure 3-18: grey circles). It consists of a number of cells. These cells can be controlled by one or more RNCs (see Figure 3-18: the same URA is connected to RNC4 and RNC5). The operator has the option to set the size of URAs. The structure of URAs is not visible in Core network, which has to be taken into account when setting the optimal size of different system areas (for more detail see subsection 3.2.3.).
The RNC area is a new concept in UMTS R’99 (similar to the BSC of GSM). It is composed of all the cells controlled by the RNC (see Figure 3-18: the coverage are of RNC3 consists of the 4 cells that are connected to RNC3, here identical to RA2). A RNC may consist of several URAs.
System areas of the Core Network are as follows:
The Location Area (LA) consists of a number of RNC areas that are handled by the same MSC/VLR, thus one LA is always controlled by only one MSC/VLR (see Figure 3-18: LA1 is controlled by only 3G-MSC1). Mapping between one LA and several RNCs is done in the MSC/VLR. The LA may span the boundary between URAs and a URA may span the boundary between LAs. The LA is used only in the CS domain. The operator has the option to set the size of LAs.
The Routing Area (RA) consists of a number of RNC areas handled by the same SGSN, thus one RA is always controlled by only one SGSN (see Figure 3-18: RA1 is controlled only by 3G-SGSN1). Mapping between one RA and several RNCs is done in the SGSN controlling this RA. The RA may span the boundary between URAs and a URA may span the boundary between RAs (see Figure 3-18: the relation between RA4, RA5 and RNC6, RNC7). The RA is always contained within a LA (see Figure 3-18: the relation between RA4, RA5 and LA3). The RA is used only in the PS domain. The operator has the option to set the size of RAs.
37/100
The MSC/VLR area5 is composed of all the LAs controlled by this MSC. The LAs, however, never span the boundary of the MSC/VLR area (see Figure 3-18: relation between LA2, LA3, 3G-MSC2). The MSC/VLR area is used only in the CS domain.
The SGSN area is composed of all the RAs controlled by the SGSN. The RAs never span the boundary of the SGSN area (see Figure 3-18: relation between RA2, RA3, 3G-SGSN2). The SGSN area is used only in the PS domain.
References
TS 33.002 defines the system areas, based on the requirements on system areas in TS 23.121. TS 25.331 provides the definition of the UMTS-specific URA concept.
3.2.2 The level of tracking the user
If the MS has a dedicated radio connection established with the network then the user is tracked within the serving UTRAN. When the MS is tracked in UTRAN the mobility can be handled at two levels: at cell level or at URA level.
The MS is tracked at cell level, if the connection is very active. In this case the RNC knows exactly, to which Node B (or which sector of a node B) the MS is connected. For instance when the user moves into the coverage of a new cell, the MS gets connected to the new node B (or a new sector of the same node B) under the process of a so-called soft handover (or softer handover) controlled by the serving RNC.
More detail on soft handover can be found in section 3.4.1.
The MS is tracked at URA level, if the connection is not active, but the probability of active transmission events is still quite high. A good example is the transfer of telemetry data, where it is still useful to keep the connection “on-line”, however, the data transfer occurs very occasionally. In this case the location of the user is updated in the RNC whenever the MS crosses the border of a URA.
More detail on URA management (e.g. URA update) can be found in Section 3.4.1.
Moving to the coverage of a new RNC involves MM procedure only if sRNC relocation is needed. More detail on sRNC relocation can be found in Section 3.4.1.
If there is no dedicated radio connection6 between the MS and UTRAN then the mobility is handled between the MS and the Core network. In the CN the location management is carried out at two levels: locally in the serving MSC/VLR (or SGSN) at the level of LAs (or RAs), and network-wide managed by the HLR at the level of MSC/VLR areas (or SGSN areas).
In principle, it means that the user updates his location frequently in the local MSC/VLR (or in the SGSN) whenever he crosses the border of a new LA (or RA). But if the user, at the same time, also crosses the border of a MSC/VLR (or SGSN area), then location update procedure triggers a subsequent update of the location information stored in the HLR (e.g. when roaming).
More detail on CN location management (e.g. LA update) can be found in subsection 3.4.2.
5 The standard makes a distinction between MSC and VLR areas. A VLR area may consists of several MSC areas. In GSM practise they are identical.6 During the lifetime of a dedicated radio connection the Core MM is mostly suppressed in the UE, and only the UTRAN MM is active. This happens even when a communicating MS moves to a new LA because the MS will remain served in the old LA. Thus the LA update can be performed only after the dedicated radio connection has been released.
38/100
3.2.3 Optimal size of system areas
It is very important that the size of system areas is chosen optimally, especially because it has a large impact on the operational behaviour of the system. Here are some examples where the network operator has the option to influence the behaviour of his network by choosing the optimal size of the system areas.
The network operator has the possibility to optimise paging and updating load by controlling the size of the different CN areas (LAs and RAs). In case of an incoming call, the Core MM routes the call to a location area (or a routing area) which is translated within UTRAN into the actual set of cells covered by this location area, and the user is finally paged in these cells. It implies that the smaller the location area (or routing area) is the lower the paging load on the cells. On the other hand, when using small location areas (or routing areas), the location of the MS is tracked with great precision and the MS needs to send more location updates. This concept leads to a trade off between location updates and paging.
In current mobile networks, like GSM/GPRS, the LA (and RA) coincides with the area in which the paging message is sent out, as described above. In advanced mobile systems, like UMTS, new mobility management mechanisms are now being investigated, where the LAs (and RAs) and paging areas are handled differently to mitigate the trade-off. Various ideas have been devised. Some of them are as follows:
Assignment of overlapping location areas: It would expectedly reduce the number of location updates, given that it introduces a sort of hysteresis in the updating process.
Location areas linked to user class: Users can be classified in several ways like mobility or activity. For instance, users with high mobility are better to be tracked at the level of larger location areas, since it would reduce the update frequency. On the other hand, users with high activity are better to be tracked at the level of smaller location areas, since it would reduce the paging load.
Non-coinciding location areas and paging areas: Paging for an incoming call starts in the area where the MS most likely to be found (e.g. area where it received or generated the last call). Paging is extended to the entire location area only if the network receives no response.
In UMTS R’99 the combination of the last two ideas is adopted. The MM operation is designed to serve various types of users, depending on the activity of the connection the user has with the network. The location of the MS is known on cell level, when the activity of the connection is high. When the activity is low, the location is known at the level of larger areas, either at the level of URA or RA. The UMTS operator has the option to choose this tracking level by controlling the so-called dedicated_connection_release timer7. For example, one operator may decide that URAs are large, and that dedicated connection is released only if the dedicated connection is lost, so that most attached MSs are tracked at the URA level. Another operator may decide that URAs are small, and that the dedicated connection is released after a relatively short time of inactivity, so that most attached MSs are tracked at the RA level (optimum for a MS mainly using client-server type of PS service). This concept will minimise the number of location updates for a moving packet8 MS with low activity and remove the need for paging the MS in every cell.
References
TS 23.121 describes the tracking concept and TS 25.401 elaborates the tracking in UTRAN.
7 Also referred to as RRC_connection_release timer.8 In theory the URA concept would also apply to CS calls, but the chance that a CS connection is inactive for long is rather low.
39/100
3.3 State machines
The way in which the MS mobility is handled in the network depends very much on the current state of the MS, namely whether the MS is connected actively to the network or not. For this reason state machines are implemented both in the MS and in the network. Two state machines are distinguished:
the RRC state machine that describes the relation between the MS and the UTRAN
the PS/CS service state machine that takes care of the co-operation between the MS and the CN.
The two state machines are not completely independent. This section contains a brief description of these state machines and their relation.
3.3.1 RRC state machine
The Radio Resource Control (RRC) state machine exists as peer entities, one in the MS and one in UTRAN. Apart from transient situations and error cases they are kept synchronised. The main modes/states of the RRC state machine are RRC-CONNECTED and RRC-IDLE states.
RRC-CONNECTED state
In this state the mobility of the MS is handled within UTRAN. A dedicated radio connection is established between the MS and the serving RNC (SRNC), and the MS is tracked by this SRNC. If the MS location is known at cell level in the SRNC, the MS is in cell-connected state. When the MS location is known at URA level, the MS is in the URA-connected state.
When establishing a RRC-connection (see Figure 3-19) first the MS enters the cell-connected state and if the activity of connection slows down, the MS may go to URA-connected state.
During the lifetime of the RRC connection a temporary MS context is stored in the “location register” of the SRNC. This context typically contains mobility-related information like location information of the MS (e.g. current cell) and the Radio Network Temporary Identity (RNTI) allocated for the MS and used locally within UTRAN.
Idle mode
CellConnected
RRCconnectionestablishment
URAConnected
RRCconnectionrelease
Enter URAconnected state
Enter cellconnected state
Connected mode
Figure 3-19: RRC state machine
40/100
In this state the MS uses the dedicated RRC connection to receive Mobility Management information coming from the network (e.g. information about current URAs, LAs and RAs).
RRC-IDLE state
In this state there is no dedicated connection established between the MS and the UTRAN. The mobility is handled in the core network, where the CS/PS service state machine is used. There is even not so much signalling between UTRAN and the MS, except for MM system information coming from CN on the broadcast channel (e.g. information about current LAs and RAs) and paging messages delivered on the paging channel.
The MS is identified by a CN associated identity (e.g. International Mobile Subscriber Identity, IMSI) that is stored, together with the location information of the MS, in CN databases. In this state the UTRAN has no information stored about the MS.
3.3.2 CS/PS service state machine
From a logical point of view, the Core Network consists of two service domains, a CS service domain and a PS service domain or one of these domains.
Each service domain has its own service state machine which works independently of the other, although associated to the same MS and to the same HLR (see Figure 3-20).
Note that the MM state machine defined in UMTS PS domain is different from the one used in GPRS. The UMTS state machine is particularly designed to handle both CS and PS modes simultaneously.
Two Iu signalling connections (“two RANAP instances”)
UTRAN
3G SGSN
HLR
3G MSC/VLR
UE
CS servicedomain
Two CN service domains
One RRC connection
UTRAN withdistributionfunctionality
PS servicedomain
Common subscription data base
CS state PS state
PS state CS state
CS location PS location
Figure 3-20: CS/PS service state machine
41/100
A MS that supports both CS services and PS services has a separate CS service state machine and PS service state machine. These are synchronised respectively with the CS state machine located in the MSC/VLR and the PS state machine located in the SGSN. The synchronisation is the task of the MS-CN signalling that has also two instances: one for the CS service domain and one for the PS service domain. These instances, however, are separated only between UTRAN and CN (as respective CS-Iu and PS-Iu signalling connections), and the part between the MS and the UTRAN is common (realised as one RRC connection). The inter-relation with the RRC state machine rises from this fact.
The main CS service states are as follows: CS-DETACHED: The MS is not reachable by the network for CS services (e.g.
switched off MS). The MS does not initiate any LA updates at LA changes (or periodic LA updates).
CS-IDLE: The MS is reachable by paging for CS services (e.g. a powered-on, non-communicating MS). The MS initiates LA updates at LA changes (or periodic LA updates).
CS-CONNECTED: The MS has a dedicated signalling connection for CS services established between the MS and the CN, which implies that it is also RRC-CONNECTED (e.g. a communicating MS). The MS does not initiate LA update (even not when the present LA changes) and no periodic CS service updates, since the mobility handling is taken over by UTRAN.
The same states can be defined for PS services with the same features. The only difference is that the MS can initiate RA updates even in PS-CONNECTED state (e.g. when RA identity in MM system information changes), but no periodic RA updates can be performed in this state. It also means that in the PS domain, unlike in the CS domain, the CN MM function is not completely suppressed when the mobility is handled within UTRAN.
3.3.3 Relationship between CS and PS service states and RRC states
The following relations are valid between service states and RRC modes for a MS: when in either CS-CONNECTED state or PS-CONNECTED state, or in both CS-
CONNECTED state and PS-CONNECTED state, then the MS is in RRC CONNECTED state (see Figure 3-21.)
SRNC RNC
3G_MSC/VLR 3G_SGSN
RRC state
CS state
UE
RRC CELL-CONNECTED
CS-CONNECTED
RRC CELL-CONNECTED
PS-IDLE
PS-IDLE
PS state
CS-CONNECTED
Or UMSC
Figure 3-21: The MS is in CS-CONNECTED, so it is also in RRC-CONNECTED state (regardless of the state of the PS service state machine)
42/100
when in neither CS-CONNECTED state nor PS-CONNECTED state, then the MS is in RRC IDLE state (see Figure 3-22.)
RNC RNC
3G_MSC/VLR 3G_SGSN
UE
RRC IDLE MODE
CSIDLE
RRC IDLEMODE
CS-IDLE
PSDETACHED
PS-DETACHED
RRC state
CS state
PS state
Or UMSC
Figure 3-22: The MS is neither in CS-CONNECTED nor in PS-CONNECTED state, so it is in RRC-IDLE state
References
TS 23.121 describes the UMTS state machines and the GPRS state machines can be found in TS 23.060.
3.4 Detailed description of mobility-related procedures
The signalling and control functions activated between the MS and the UTRAN9 (e.g. Radio Resource Management, RRM) are dependent of the radio technology. The signalling and control functions between the MS and Core Network functionality10 however (e.g. Call Management (CM) or Session Management (SM)) are typically independent of the radio technology.
As for Mobility Management, however, it is related to both because it has to be provided throughout the whole network infrastructure.
Figure 3-23 shows the control plane (signalling) protocol stack on the interface between the MS and the CN.
9 Also referred to UTRAN-related signalling or Access Stratum control procedures.10 Also referred to Core network-related signalling or Non-Access Stratum control procedures
43/100
Figure 3-23: Protocol stack of the signalling plane
On the other hand, distinction can be made between local and network-wide mobility control. The local mobility control is in charge of guaranteeing service-continuity while the user is in motion (e.g. handover). This is provided by the local UTRAN network. The network-wide mobility control is responsible for tracking the user across large geographical areas (e.g. roaming). This functionality is handled by the core network.
If the user happens to use the service while crossing large distances, the two control mechanisms are forced to interact with each other. It can be elaborated whether this is the responsibility of the radio network or the core network to deal with such cases. One of the main differences between the GSM and the UMTS system is, that in GSM it is a core network issue (e.g. inter-MSC handover), whilst in UMTS it became UTRAN-related MM function (e.g. SRNC-relocation).
GSM/GPRS and UMTS will undoubtedly coexist in the future. Operators, who will provide both services, have also the intention to make the best out of this coexistence. A possible way of taking advantage of this situation is to use UMTS as “islands” in the GSM network, so that if a UMTS user gets out of the UMTS coverage of, he can still use the service via the GSM interface. The consequence of this approach is that the mobility management of the two systems will have to interwork (e.g. intersystem handover). However, this issue falls out of the scope of this document.
3.4.1 UTRAN-related procedures
Cell selection
In UMTS, each mobile terminal in idle state (e.g. powered-on but not RRC-CONNECTED) is associated with a Node B base station. This base station will be the one that provides the local link between the MS and the network, which link then can be used by the MS: to initiate a call to receive an incoming call by listening to paging messages
to send/receive signalling messages (e.g. location update, system information)
When the MS is turned on, the cell selection procedure will provide the means by which the MS can choose a suitable Node B to be initially connected to. This choosing is also known as "camping on the cell", where the cell is a sector in the coverage area of the chosen Node B. The selected cell will be updated through the cell re-selection process, anytime the MS loses coverage of the cell or finds a more suitable cell. If the MS is in cell-connected state, the result of the cell selection will be reported to the RNC in form of a cell update procedure.
44/100
References
TS 23.122 describes the cell selection; TS 25.304 and TS 25.331 describe the cell selection in more details on the radio interface.
Handover
In UMTS, when the MS is in RRC-CONNECTED state (e.g. having an active PS session/-CS call), the continuity of his radio connection with the network has to be maintained regardless of his movements and locations.
From the mobility point of view, the most difficult part to manage is when the MS gets out of the coverage of the serving cell and his connection needs to be “handed over” to another cell. Undoubtedly, handover is a UTRAN-related MM issue, however the way handovers are treated in UTRAN has impact on the core network MM as well. Especially, when the target cell is controlled by a different CN nodes than the source cell (e.g. when the target and the source cell are not in the same MSC/VLR area or SGSN area).
In the following the different types of handover mechanism are described with their relation to the core network.
Three different types of handovers are supported in UTRAN: hard HO, soft HO, and softer HO.
Hard hand-over
When a communicating MS arrives at the border of two cells, he breaks the connection to the source cell and builds up a new connection to the target cell. Because of real-time restrictions, this has to occur almost simultaneously as it is illustrated in Figure 3-24 and Figure 3-25. In UMTS hard HO is performed when the source cell and the target cell operate on different frequencies (e.g. handover between FDD and TDD-based11 UMTS system, handover between UMTS and GSM). In these cases the two cells usually belong to different RNC areas and most likely also to different CN node areas, which involves SRNC relocation described later in this section (see page 48) and subsequent change of the serving CN node. The call/session is re-routed then on the network according to this change.
Figure 3-24: Hard hand-over step 1: a still connected to cell 1.
11 The difference between FDD and TDD based system is described in subsection 5.3.
45/100
UE
RNC
cell 2
Core Network
cell 1
Figure 3-25: Hard hand-over step 2: break down connection to cell 1 and build it up to cell 2
Soft hand-over
In UMTS it is possible for the MS to have connections with more than one cell simultaneously (e.g. when the MS is in between the source and the target cell). This is illustrated in Figure 3-26. We say that the MS is in a soft hand-over state. There are two main requirements that has to be fulfilled in order that soft HO could be performed: the source and the target cell have to operate on the same frequency macrodiversity (combining traffic streams coming from different cells) has to be
supported by the serving RNCThese are inherent features of UMTS.
Figure 3-26: Soft hand-over: connected simultaneously to cell 1 and to cell 2
It is also possible that the source and the target cell are connected to different RNCs. Figure 3-27 sketches such a situation. In this case the RNC connected to the target cell (called drift RNC, dRNC) will relay the traffic stream towards the serving RNC (the RNC where the source cell is connected). The sRNC will combine the traffic (macrodiversity) and forward it to the core network.
46/100
UE
RNC
cell 2
Core Network
cell 1
UE
RNC
cell 2
Core Network
cell 1
Figure 3-27: Soft hand-over: connected to different RNCs
If necessary, the drift RNC can become a serving RNC (see sRNC relocation). It implies that the connection between Core network and RNCs should change (the serving Iu interface), which has impact on the core network MM as well.
Softer hand-over
It is also possible for the MS to have connections via several sectors belonging to the same Node B. This is typically the case when the MS is located close to the border of two sectors, see Figure 3-28. In such a situation we speak about softer hand-over.In case of softer handover the Mobility Management is handled locally by the node B, so the CN is never involved.
Figure 3-28: Softer hand-over: the MS has connections with several sectors of the same node B
References
The handover requirements can be found in TS 22.129. The handover procedures implementing these requirements are specified in TS 23.009. TS 23.110 describes the handover classified as UTRAN-related procedure.
47/100
RNC
UE12
3
Core Network
UE
sRNC
cell 2
Core Network
cell 1
dRNC
sRNC relocation
In case of a MS in RRC-CONNECTED mode, the Mobility Management is carried out by the UTRAN. Since the MM procedure is performed completely invisible to the Core network, the MM operation is not always optimal.
Figure 3-29: sRNC relocation
Imagine that the MS is in soft handover state and communicating to cells that are connected to two different RNCs, a serving RNC (sRNC) and a drift RNC (dRNC). Now the MS moves further to the right, leaving the coverage area of cells controlled by the sRNC (see Figure 3-29 on the left). This results in a situation, where the MS is only connected to the drift RNC, but he is still served by the sRNC that directs the traffic stream to the core network. The sRNC relocation is designed to optimise network resources (without changing the radio resources) by relocating the serving functionality from the sRNC to the dRNC (see Figure 3-29 on the right). The procedure may have impact on the Core MM as well, since it redirects the traffic to a new Iu interface (e.g. a possible change of CN node will result in a location update).
The following example show sRNC relocation when the source RNC and target RNC are connected to different CN nodes (MSC and SGSN) and therefore having effect on the Core MM. Figure 3-30 and Figure 3-31 respectively show the situation before and after sRNC relocation.
Before the sRNC relocation
The RNC1 is acting as sRNC and the RNC2 is acting as dRNC. The MS is registered in SGSN1 and in MSC1, thus HLR contains LA1 and RA1 as location information (however the MS is already in LA2 and RA2). The MS is in CS-CONNECTED state towards the MSC1 and in PS-IDLE state towards the SGSN1.
After the sRNC relocation
The RNC2 becomes the sRNC. The MS remains in CS-CONNECTED towards the CS domain, and in PS-IDLE state towards the PS domain. The MS remains registered in MSC1, because his serving MSC1 does not change, and that is why his location area is still marked by LA1. On the other hand, the registration in the IP domain has changed from SGSN1 to SGSN2. Consequently the routing area has changed also from RA1 to RA2 requiring a subsequent RA update.
48/100
LA1, RA1
MSC1 SGSN2SGSN1 MSC2
RNC1 RNC2
UE
LA2, RA2
HLR
Figure 3-30: Before the sRNC relocation
LA1, RA1
MSC1 SGSN2SGSN1 MSC2
RNC1 RNC2
UE
LA2, RA2
HLR
Figure 3-31: After the sRNC relocation and location registration
References
TS 25.401 describes the requirements on sRNC relocation and in TS 23.060 you find the description of how sRNC relocation takes place. The relation between sRNC relocation and Location registration can be found in TS 23.121.
URA location management
URA location management is related to the internal registration areas of UTRAN (URA). When a MS is in RRC-CONNECTED mode and his connection slows down, the tracking level of this MS can be expanded from cell-level to URA-level (the MS will switch to URA-connected state). This will lower the MM activity required from UTRAN without releasing the dedicated RRC connection12.
For instance, in URA-connected state the MS does not need to execute cell update at every cell selection, but instead reads URA identities from the broadcast channel, and only if the URA changes (after cell reselection) does the MS reports its location to the sRNC. This is called URA update.
12 In case RRC connection is released, the UE goes to idle state and the MM function will be performed by the Core network.
49/100
In URA-connected state paging messages are sent out to each cell that belongs to the URA where the MS is currently located13.
References
TS 23.121 describes of the URA concept, and an elaboration of URA location management implemented in RRC can be found in TS 25.331. For more details on the difference between URA paging and Core paging see TS 23.060.
3.4.2 Core network-related procedures
MM system information procedure
Any location covered by a mobile network can be identified by the identity of the various system areas covering this particular location. For instance, if we have the cell identity, the location area code (e.g. LAI or RAI) and the network code as co-ordinates, we can determine the corresponding location as precise as the coverage of the cell. The MM system information is basically the location information given in terms of system area codes.
Every time, when the MS moves to a new cell (cell selection), his location as well as the corresponding MM system information changes. The MM system information procedure is the procedure by which the network informs the MS about this change and updates the MS with new “location co-ordinates”.
In RRC idle mode, when the MS camps on one cell, it receives all MM system information valid for this cell on the broadcast channel of the cell. In RRC connected mode, however, the dedicated RRC connection is used for transferring the new MM system information to the MS.
The MM system information procedure assists other Mobility Management procedures. For instance, a location update procedure is performed when the MS recognises that his new “location co-ordinates” differ from his previous “location co-ordinates” by reading the received MM system information.
References
In TS 23.003 the location area codes are defined. More information on the MM system information procedure can be found in TS 23.121.
Paging
Paging is an important core network related procedure which is best described in the context of setting up a mobile terminated call. See subsection 4.2.2 for this description.
Attach (or registration)
The attach is a Core MM procedure initiated by the MS being in PS/CS-DETACHED state. When performing Attach, the MS informs the Core network that he is reachable again (e.g. when switching on). This procedure is also referred to as registration indicating that the MS gets registered to the local CN node for the service.
CS attach is performed when the MS gets registered to the local MSC/VLR for CS service; and PS attach is performed when the MS gets registered to the local SGSN for PS service. The two procedures can be combined if the Gs interface exists between the new MSC/VLR and the new SGSN.
13 The size of the paging area depends on the state of the connection which the UE has with the network. In cell-connected state the UE is paged in the corresponding cell, in URA-connected state the UE is paged in the corresponding URA and in RRC-idle state the UE is paged by CN in the corresponding RA or LA.
50/100
The attach in its simplest form is just a procedure to set the attach flag14 in the subscriber databases (e.g. VLR, HLR, SGSN and GGSN). In most cases (especially when the MS changes location between detach and attach), it is rather a complex procedure invoking many other Core MM procedures (e.g. location update). In Figure 3-32 a flow chart of a combined PS/CS attach is shown, where the attach is requested via the PS domain.
Figure 3-32: Combined PS/CS Attach
Main steps of the procedure can be detailed as follows:
An Attach request is sent to the local SGSN. In the request message the “type” field indicates whether single or combined attach is to be performed (here: combined PS/CS Attach).
Identification is concerned with finding out the IMSI15 of the MS. The procedure as part of the Temporary Identity Management procedure is described on page 55.
The MS is authenticated via an advanced ciphering mechanism. The authentication is described on page 56.
The validity of the terminal equipment can be checked (optionally). The equipment identity check is described in on page 57.
The new location indicator of the MS (here: routing area number) is updated in the new SGSN and in the HLR and the old location indicator is deleted from the old SGSN. These procedures are performed together and commonly called Routing area update, which will be detailed as Location update procedure on page 54.Note that this update procedure may not need to be performed if the location of the user (here: SGSN number) has not changed since the previous detach.
If combined PS/CS Attach was requested in the Attach request and the Gs interface is installed, then a CS attach together with a CS location update is requested from the new SGSN to the new MSC/VLR. The MSC/VLR creates an association with the SGSN by storing the SGSN number.
14 The attach flag for CS and for PS services are separated. The CS attach flag (also called IMSI detach flag) is stored in the VLR, the PS attach flag (also called MS Not Reachable for GPRS flag) is stored consistently in the HLR, the SGSN and the GGSN. 15 IMSI stands for International Mobile Subscriber Identity. The IMSI is a unique identity of a given subscriber, which is used as a reference to retrieve and store subscriber data in the distributed databases of the mobile network.
51/100
The new location indicator of the MS (here: location area number) is updated in the new MSC/VLR and in the HLR and the old location indicator is deleted from the old MSC/VLR. These procedures are performed together and commonly called Location area update, which will be detailed on page 54.Note that this update procedure does not need to be performed if the location of the user (here: MSC/VLR number) has not changed since the last detach.
The SGSN sends an Attach accept message to the MS (e.g. as a result a logo of the operator appears on the screen of the terminal).
A single PS attach procedure can be described with the same flow chart by omitting the location update messages.
A single CS Attach entails the same MM procedures (e.g. identification, authentication, location update etc.) as a single PS attach, but the attach request is issued to the MSC/VLR and then carried out through the CS domain.
References
TS 23.012 describes the CS attach; the description of both PS attach and combined PS/CS attach can be found in TS 23.060. More details on the requirements of the combined PS/CS attach are in TS 23.121. For identifiers, flags and numbers stored in databases see TS 23.008.
Detach
Detach is a Core MM procedure that enables (or forces) the MS to stop having access to the service by setting the Attach flag to zero (and moving the MS to PS/CS-DETACHED state). Detach can be requested explicitly or can occur implicitly without request.
When requested explicitly, the Detach procedure can be initiated by the MS or by the network: The MS-initiated Detach informs the network that the MS does not want to access the
service any longer (e.g. because of switch-off).
The network-initiated Detach informs the MS that he does not have access to the service any more (e.g. HLR initiates the detach for operator-determined purposes to request the removal of subscriber’s MM and PDP context at the SGSN).
Implicit detach operation is the action taken by the network to mark a MS as detached when there has been no successful contact between the MS and the network for a time determined by the mobile reachable timer. Since in this case the connection has been irrecoverably disconnected, the MS can not be notified of the detach.
There are three different types of detach: CS detach, PS detach or combined CS/PS detach (that is MS-initiated only). Normally the CS detach is just a simple request to/from MSC/VLR to clear the Attach flag. In case of a PS detach the Attach flag is first cleared in the SGSN, and then the SGSN deactivates the active PDP context of the MS (see 4.3.2) in the GGSN. An example of PS Detach procedure when initiated by the MS is illustrated in Figure 3-33.
52/100
Figure 3-33: MS-Initiated PS Detach Procedure
Each step is explained in the following list. The MS detaches by sending a Detach Request (Detach Type, Switch Off) to the
SGSN. Detach Type indicates which type of detach that is to be performed, i.e., PS Detach only, CS Detach only or combined Detach. Switch Off indicates whether the detach is due to a switch off situation or not.
The active PDP contexts regarding this particular MS are deactivated in the GGSNs. The SGSN however may, as an implementation option, keep or delete the MM and PDP contexts. If the SGSN keeps these contexts, then they can be reused at a later attach without accessing the HLR.
If the SGSN deletes the MM and PDP contexts, then it has to be signalled to the HLR by a so-called purge procedure.
If Switch Off in the Detach Request message indicates that the detach is not due to a switch off situation, the SGSN sends a Detach Accept to the MS.
In case of a combined CS/PS detach the MS sends only one detach request to get deregistered from both the MSC/VLR and the SGSN rather than sending separate request messages. For this the Gs interface is required.
References
TS 23.012 describes the CS detach; the description of both PS detach and combined PS/CS detach can be found in TS 23.060. More details on the requirements of the combined PS/CS detach are in TS 23.121.
Location Update
The location update is a typical Core MM procedure that is performed every time when a MS in IDLE state crosses the border of CN system areas. Four different types of location update can be distinguished depending on the system area it is related to: intra-MSC/VLR LA update: the MS crosses the border of two LAs belonging to the
same MSC/VLR of the CS domain. inter-MSC/VLR LA update: the MS crosses the border of two LAs belonging to
different MSC/VLRs of the CS domain. The change of MSC/VLR area has to be signalled to the HLR.
intra-SGSN RA update: the MS crosses the border of two RAs belonging to the same SGSN of the PS domain.
inter-SGSN RA update: the MS crosses the border of two RAs belonging to different SGSNs of the PS domain. The change of SGSN area has to be signalled to the HLR.
Upon entering a new cell, the MS detects whether a location update shall be performed by comparing the area code (RAI, LAI) stored previously in the MS with the area code received as MM information from the new cell. If a location update is needed, the MS initiates the request to the local CN node that detects if it is an intra-CN or an inter-CN location update by noticing if it also handles the old system area of the MS.
53/100
Figure 3-34: Inter-MSC/VLR Location Area update procedure
In Figure 3-34 the flowchart of an inter-MSC/VLR LA update is shown.
The MS sends the initial message Location Area Update to the new 3G_MSC/VLR. The identity (LAI) of the new and old location areas of the MS are added to the message before passing it to the new 3G_MSC/VLR.
Note that sending the Location Area Update Request message to the 3G_MSC/VLR requires a signalling connection between the MS and 3G_MSC/VLR (made up of a RRC-connection and an Iu signalling connection). This signalling connection may be kept or released after the LA update has been completed.
The new 3G_MSC/VLR detects that the MS’s old LAI is handled by another 3G_MSC/VLR (inter-MSC/VLR LA update) and sends an identification request to this CN node. Identification is concerned with finding out the IMSI of the MS. The procedure as part of the Temporary Identity Management procedure is described on page 55.
The MS is authenticated via an advanced ciphering mechanism. The authentication is described in on page 56.
The new 3G_MSC/VLR informs the HLR of the change of 3G_MSC/VLR by sending Update Location (new MSC/VLR number) to the HLR.
The HLR cancels the MM context in the old 3G_MSC/VLR by sending Cancel Location. The old 3G_MSC/VLR removes the context and acknowledges with Cancel Location Acknowledgement.
The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_MSC/VLR. The new 3G_MSC/VLR constructs a new MM context for the MS and returns an Insert Subscriber Data Acknowledgement to the HLR.
The HLR acknowledges the Update Location by sending Update Location Ack to the new 3G_MSC/VLR.
The new 3G_MSC/VLR allocates a new temporary identity (TMSI) for the MS and responds to the MS with Location Area Update Accept (new TMSI, new LAI). The role of TMSI will be further explained in subclause “TMSI management” on page 55.
54/100
The MS acknowledges the new TMSI with a TMSI reallocation Complete.
The Routing Area update procedure entails the same MM procedures (e.g. identification, authentication, location cancellation etc.) as the Location Area update, but the location update request is issued to the SGSN and then carried out through the PS domain.
Another characteristics of the RA update is that it can be performed even when the MS has already a PDP context activated with the network. When the RA update is an inter-SGSN RA update, the tunnel between the serving SGSN and the GGSN, which is established at PDP activation has to be redirected towards the new SGSN by means of PDP context update procedure (see Figure 3-17).
Note that if the MS is in PS-IDLE state, the PDP context update is part of the RA update procedure, however if it is in PS-CONNECTED state, the PDP context update will be included in the sRNC relocation procedure (see subsection 3.4.1).
If the period between two normal location updates takes too long, a periodic location update may be performed. By doing this, the MS notifies the network that he is still switched on in the same location.
Combined CS/PS location update is also possible, if the Gs interface is present.
References
TS 23.012 describes the CS location management procedures, with more specific the LA update in TS 23.121. The description of the RA update and the combined LA/RA update can be found in TS 23.060.
TMSI management
In UMTS, like in GSM, every mobile subscriber is identified in the core network by means of a unique number called International Mobile Subscriber Identity (IMSI). Because of its uniqueness, the IMSI must be kept confidential. The risk of eavesdropping the IMSI is especially high when it is sent over the radio interface. In order to lower this risk, instead of the IMSI, a random Temporary Mobile Subscriber Identity (TMSI)16 is used on the radio interface.
The management of the TMSI is closely related to the Mobility Management of the MS. Every time the MS enters a new serving CN area (e.g. attach, location update), he receives a new TMSI allocated by the serving CN node, whereby an association is created between the IMSI and the TMSI. The new TMSI is valid as long as the MS stays within the same LA or RA.
An example of TMSI management executed as part of an inter-MSC/VLR location update procedure is shown in Figure 3-34. The relevant steps can be described briefly as follows: Upon registering to a new CN node (here MSC/VLR), the old TMSI and the old LAI
(Location Area Identity) are included in the Location Update Request message. The new MSC/VLR uses the old LAI to derive the address of the old MSC/VLR.
On the number derived from the old LAI, the old MSC/VLR can be interrogated for the IMSI of the MS. The old TMSI is used here as pointer in the old MSC/VLR.
After the IMSI has been retrieved by the new MSC/VLR, a new TMSI can be allocated for the MS in association with his IMSI.
As a result the MS has been identified without sending the IMSI over the radio interface.
References
TS 23.003 defines the structure of IMSI, TMSI and LAI. The requirements on (the use of) the TMSI are in TS 23.122 and TS 23.060.
16 Separate temporary identity is used in the CS domain (called CS-IMSI) and in the PS domain (called PS-IMSI). The CS-IMSI is allocated by the serving MSC/VLR, whilst the PS-IMSI allocated by the serving SGSN.
55/100
Security mgmt (authentication, equipment identity check)
Authentication
Whenever the user attempts to get access to mobile services, first he must be authenticated to the network. The authentication procedure verifies whether the user is really the person he claims to be.
"UMTS authentication" is an enhanced method compared to its predecessor, the "GSM authentication". The main properties of the two mechanisms as follows: "GSM authentication" implies authentication of the MS by the network and establishment of a new
GSM ciphering key agreement between the serving CN node and the MS. This agreement is established via a triplet17 of keying material.
"UMTS authentication" implies mutual authentication, i.e., authentication of the MS by the network and authentication of the network by the MS. It also implies establishment of a new UMTS ciphering key and integrity key agreement between the serving CN node and the MS. This agreement is established via a quintet18 of keying material. Further more, an improved identification procedure has been implemented and can be used optionally in UMTS. With this procedure the validity of the TMSI can be verified, when it is used together with a TMSI signature derived from the quintet.
Ciphering and data integrity are two important elements of UMTS security mechanism. Ciphering provides confidentiality of transmitted data (e.g. encryption). In UMTS an enhanced ciphering method, the so-called UMTS Encryption Algorithm is used. The UMTS Ciphering Key is an input to the algorithm.Data integrity protects transmitted data from fraudulent modifications. The UMTS Integrity Key is used for integrity purposes.The authentication of UMTS subscriber is illustrated in Figure 3-35.
Figure 3-35: Authentication of UMTS subscriber procedure
If the CN node does not have previously stored quintet of keying material, a Send Authentication Info message is sent to the HLR. Upon receipt of this message, the HLR/AuC generates the quintet for the UMTS user and responds with a Send Authentication Info Acknowledgement message including the requested quintet.
The CN initiates the authentication of the UMTS subscriber through the quintets. After executing the security algorithm with the quintets, the Authentication Response
and the secret keys used for ciphering and integrity are generated.
Equipment identity check
If a mobile terminal gets stolen or is malfunctioning, the equipment will be put on a so-called black list in the Equipment Identity Register (EIR). When the user attempts to get access to the network again by using this terminal, the status of the terminal will be
17 A triplet consists of three elements: a) a network-initiated challenge that is random number (RAND), b) an
expected user response (SRES) for the challenge and c) a cipher key (Kc).
18 A quintet consists of five elements: a) a network-initiated challenge that is random number (RAND), b) an expected user response (XRES) for the challenge, c) a cipher key (CK), d) an integrity key (IK) and e) a network authentication token (AUTN).
56/100
checked in the EIR and the access will be denied or restricted. This procedure is called equipment identity check, which is usually part of the registration procedure.
The Equipment identity check procedure is illustrated in Figure 3-36.
Figure 3-36: Equipment identity check procedure
The CN node sends Identity Request to the MS and the MS returns with Identity Response including the International Mobile Equipment Identity (IMEI).
If the CN node decides to check the IMEI against the EIR, it sends Check IMEI to EIR. The EIR returns with a positive or a negative response in the Check IMEI Acknowledgement message.
References
The requirements on 3G security are specified in TS 33.120. The UMTS security architecture and details on keying material and algorithms to satisfy these requirements are described in TS 33.102. For the combination of GSM and UMTS there are “UMTS-GSM Security Integration Guidelines” in TS 33.103. Additional information regarding PS domain security can be found in TS 23.060.
57/100
4 Communication Management
This chapter first explains the differences between circuit switched and packet switched services. Section 4.2 describes the circuit switched call with a focus on the establishment of different kinds of calls. With a similar focus, section 4.3 describes the packet switched session. Finally, the last section describes some enabling technologies for IP based services.
4.1 Circuit switched and Packet switched services
In UMTS, a circuit switched and a packet switched part can be distinguished. For circuit switched services a dedicated channel is set up through the network. All data flows through the same circuit in the network from A to B, as can be seen in Figure 4-37. Circuits are mostly used for services with a continuous user data flow, or for services that require a guaranteed constant connection like a phone call.
12
1212
A
B
Figure 4-37: Circuit switched network
In packet switched networks, data is transferred in packets which do not all necessarily have to follow the same route in the network (e.g. the Internet using IP). Instead, each packet is routed separately through the network. At the destination, all packets are aligned in the correct order again. The traffic of a packet switched service has often a bursty character, i.e. periods with many packets alternate with periods of almost no packets. Refer for an illustration to Figure 4-38.
12 1
2
2
12
A
B
Figure 4-38: Packet switched network
For packet switched traffic it is possible to share channels among different users, whereas for circuit switched services, each user is assigned a dedicated channel. This is indicated in Figure 4-39, where the upper channels are each dedicated to one user, and the lower channels are shared among several users. The sharing of channels leads to a more efficient use of resources.
58/100
Circuit Switched Data
Packet Switched Data
Figure 4-39: Circuit Switched and Packet Switched data.
The sharing of channels of the packet switched traffic asks for a new way of billing, as the user is not using the connection all the time. With a packet switched connection the user can be always online, but will only be charged for the amount of data received or sent. This is a big difference in billing compared to the circuit switched connections where billing is based on the duration of the call, regardless on how much traffic is sent and received.
Not all traffic is suited for packet switched connections, e.g. video applications or speech, because of the best effort characteristic of packet switched services. For speech a 9.6 kbps circuit switched connection is usual. For video applications UMTS provides the ability to set up a circuit switched data service capability of 64 kbps.
4.2 Call control (circuit-switched)
This section describes the establishment of calls. Three main parts will be described: a mobile originated (MO), a mobile terminated (MT) call and the retrieval of routing information. A basic mobile to mobile call is treated as the concatenation of a MO and a MT call.
Note that in this chapter the term ISUP is used to denote the telephony signalling system used between exchanges.
4.2.1 Establishing a mobile originated call
A basic mobile originated call involves signalling between the MS and its Visited MSC (VMSC, the MSC serving the area the MS is in) via the
RNS, between the VMSC and the VLR and between the VMSC and the destination exchange.
This is depicted in Figure 4-40.
59/100
Architecture for a MO call
MS
VMSC
VLRVPLMN
Radio I/F signalling
SIFOCComplete call
IAM (ISUP)RNS
Iu or A I/F signalling
Figure 4-40: Architecture for a basic mobile originated call
When the MS wishes to set up a call, the MS establishes communication with the network using radio interface signalling, and sends a message containing the address of the called party. The VMSC requests information to handle the outgoing call (SIFOC: Send Information For Outgoing Call) from the VLR, over an internal interface of the MSC/VLR. If the VLR determines that the outgoing call is allowed, it responds with a Complete Call. The VMSC: establishes a traffic channel to the MS constructs an ISUP IAM using the called party address and sends it to the destination
exchange to set up the traffic channel to the destination.
Information flow for a MO call
The information flow for the MO call is given in Figure 4-41.
60/100
MS RNS VMSC VLR
Authenticate
Ciphering
CM service accept
CM service request
Process access req.CM service request
Process access req.ack.
CM service accept
SetupSIFOC
Complete CallCall proceeding
Channel assignmentIAM
ACM
ANMAlert
Connect
Connect ack
Note 1
Note 2
Figure 4-41: Information flow for a basic mobile originated call.
Note 1: Authentication may occur at any stage during the establishment of a MO call; its position in this message flow diagram is an example.
Note 2: Security procedures may be initiated at any stage after authentication; the position in this message flow diagram is an example.
Note 3: (not shown in the diagram) The network may request the IMEI from the MS, and may check the IMEI (see subsection 3.1.4), at any stage during the establishment of a MO call, either as part of the procedure to start security procedures or explicitly after security procedures have started.
When the user wishes to originate a call, the MS establishes a signalling connection with the RNS and sends a Connection Management (CM) service request to the RNS, which relays it to the VMSC.
The VMSC sends a Process Access Request to the VLR. The VLR may then initiate authentication and may also initiate security procedures at this stage. If the user originates one or more new MO calls in a multicall configuration, the MS sends a CM service request through the existing signalling connection for each new call.
If the VLR determines that the MS is allowed the requested service, it sends a Process Access Request acknowledgement to the VMSC.
If the VMSC has received a Start security procedures message from the VLR, the Process Access Request ack message triggers a Start security procedures message towards the RNS; otherwise the VMSC sends a CM Service Accept message towards the RNS. If the RNS receives a Start security procedures message from the VMSC, it initiates the security procedures and when the security procedures have been successfully initiated, the MS interprets this in the same way as a CM Service Accept.. If the security procedures are not required at this stage, the RNS relays the CM Service Accept to the MS.
When the MS has received the CM Service Accept, or security procedures have been successfully initiated, it sends a Set-up message containing the B-subscriber address via the RNS to the VMSC. The Set-up message also indicates which bearer capability is required for the call.
61/100
The VMSC translates this bearer capability into a basic service and determines whether an interworking function is required. Interworking functions like a fax modem or data modem might be required if the circuit is used for fax or data. It then sends to the VLR a request for information to handle the outgoing call, using a Send Info For Outgoing Call (SIFOC) message containing the B subscriber address.
If the VLR determines that the call should be connected, it sends a Complete Call message to the VMSC. This one sends a Call Proceeding message via the RNS to the MS, to indicate that the call request has been accepted, and sends an Allocate channel message to the RNS for the Channel Assignment. The RNS and MS are triggered by this to set up a traffic channel over the radio interface. The Call Proceeding message includes bearer capability information if any of the negotiable parameters of the bearer capability has to be changed.
When the traffic channel assignment process is complete, the VMSC constructs an ISUP Initial Address Message (IAM) using the B subscriber address and sends it to the destination exchange. When the destination exchange returns an ISUP Address Complete Message (ACM), the VMSC sends an Alerting message via the RNS to the MS, to indicate to the calling user that the B subscriber is being alerted.
When the destination exchange returns an ISUP ANswer Message (ANM), the VMSC sends a Connect message via the RNS to the MS, to instruct the MS to connect the speech path.
The network then waits for the call to be cleared.
For an emergency call, a different CM service type (emergency call) is used, and the mobile may identify itself by an IMEI. It is a network operator option whether to allow an emergency call when the mobile identifies itself by an IMEI.
4.2.2 Establishing a mobile terminated call
A basic mobile terminated call involves signalling between the PSTN and the Gateway MSC (GMSC), the GMSC and the Visited MSC (VMSC), the MS and its VMSC via the RNS, the VLR and the VMSC in the visited PLMN, the HLR en de GMSC in the home PLMN, the HLR and VLR,
This is depicted in Figure 4-42.
Note that the home PLMN and the visited PLMN can be the same network.
Architecture for a MT call
When the Gateway MSC (GMSC, a MSC with an interface to the PSTN) receives an ISUP IAM, it requests routing information from the HLR using the MAP protocol. The HLR requests a roaming number from the VLR, also using the MAP protocol, and it returns a roaming number in the Provide Roaming Number Ack. The HLR returns the roaming number to the GMSC in the Send Routing Info ack. The GMSC uses the roaming number to construct an ISUP IAM, which it sends to the VMSC.
62/100
GMSC
VPLMN
HLR
HPLMN
IAM(ISUP)
IAM(ISUP)
Send RouteingInfo/ack
Provide RoamingNumber/ack
Radio I/Fsignalling
MS
VLR
VMSC
SIFICPage/ackComplete call
RNS
Figure 4-42: Architecture for a basic mobile terminated call.
Upon reception of the IAM by the VMSC, it requests information to handle the incoming call (SIFIC: Send Information For Incomming Call) from the VLR, over an internal interface of the MSC/VLR. If the VLR determines that the incoming call is allowed, it requests the VMSC to page the MS. The VMSC pages the MS using radio interface signalling. When the MS responds, the VMSC informs the VLR in the Page ack message. The VLR instructs the VMSC to connect the call in the Complete call, and the VMSC establishes a traffic channel to the MS.
Information flow for a MT call
GMSC VLR VMSC RNS MS
IAM
Paging
SIFIC
Call arrived
Complete call
Channel allocation
Setup
Call confirm
ACM
ANM
Alert
Connect
Connect ack
Complete call ack
Note 1
Note 2
IAM
ACM
ANM
Figure 4-43: Information flow for a basic mobile terminated call
63/100
Note 1: The paging procedure is described at the end of this paragraph. If a connection between MSC and MS has been established as a result of pre-paging, the paging procedure is not performed.
Note 2: If a connection between the MSC and the MS has been established as a result of pre-paging, the VLR sends the Call arrived message to the MSC to stop the guard timer for the release of the radio connection.
Note 3: (Not in figure) This message flow diagram assumes that the MS has already been authenticated on location registration. If this is not so (for the first MT call after VLR restoration), the network may initiate authentication after the MS responds to paging.
Note 4: (Not in figure) The network may request the IMEI from the MS, and may check the IMEI, at any stage after the MS responds to paging, either as part of the procedure to start security procedures or explicitly after security procedures have been started; this is not shown in this message flow diagram.
When the GMSC receives an IAM it communicates with the HLR as described above (not shown in Figure 4-43) and then forwards the IAM, with the destination number replaced by the roaming number, to the VMSC serving the MS.
When the VMSC receives an IAM from the GMSC, it sends a request for information to handle the incoming call to the VLR, using a Send Info For Incoming Call (SIFIC) message. This message contains the roaming number received in the IAM.
If the VLR recognises the roaming number, and the MS is allowed the requested service, it sends a request to the VMSC to page the MS. If a radio connection between the network and the MS is already established, the VMSC responds immediately to the page request. If no radio connection exists, the VMSC sends a page request to the RNS, and the RNS broadcasts the page on the paging channel.
If VPLMN supports GPRS and the Gs interface between VLR and the SGSN is implemented and there is a valid association between VLR and the SGSN for the MS, the paging signal towards the MS goes from VMSC via VLR and the SGSN to the RNS (in this way, the MS only needs to monitor on one paging channel.
During the paging procedure (described at the end of this paragraph) a signalling channel is set up between the MS and the RNS. The VLR may initiate authentication and ciphering procedures.
After the paging procedure is completed, the VLR then sends a Complete call message to the VMSC, which sends a Set-up message towards the MS. The Set-up message may include bearer capability information for the call.
When the MS receives the Set-up message from the RNS, it responds with a Call confirmed message, which includes bearer capability information if any of the negotiable parameters of the bearer capability has to be changed.
After reception of the Call confirmed message, the channel allocation takes place. When the MS has tuned to the specified traffic channel and the allocation procedure is finished with an Assignment complete message, the MS sends an Alerting message to indicate that the called user is being alerted. The VMSC sends an ACM to the GMSC, which relays it to the originating exchange.
When the called user answers, the MS sends a Connect message, which the RNS relays to the VMSC.
The VMSC: responds with a Connect ack message towards the MS sends an ANM to the GMSC, which relays it to the originating exchange sends a Complete call ack to the VLR
The network then waits for the call to be cleared.
Information flow for paging
64/100
VLR VMSC RNS MS
Note 1
Note 3
Page MS
Page
Page
Chan req.
Imm ass.
Page resp.
MS conn. estab.
Process access req.
Start security proc.
Process access req.ack.
Start securityprocedures
Security controlcommand
Security controlresponse
Note 2
Figure 4-44: Information flow for paging.
Note 1: The VMSC starts a timer for the release of radio resources after it sends the Process Access Request message to the VLR. The VMSC releases the radio resource allocated for the MT call if the timer expires before the IAM is received.
Note 2: Security procedures may be initiated at any stage after the network has accepted the page response; the position in this message flow diagram is an example.
Note 3: If security procedures are not required, the MSC may send a Start security procedures message indicating that no ciphering is required.
(Refer also flow diagram for a mobile terminated call in Figure 4-43.)If no radio connection exists, the VMSC sends a page request to the RNS, and the RNS broadcasts the page on the paging channel. If the MS detects the page, it sends a channel request to the RNS, which responds with an immediate assignment command, to instruct the MS to use the specified signalling channel. The MS then sends a page response on the signalling channel. The RNS relays this to VMSC and this one sends a Process access request message to the VLR, to indicate that the MS has responded to paging. The VLR may then initiate authentication and security procedures at this stage.If the VLR determines that the MS is allowed the requested service, it sends a Process access request ack to the VMSC. The Process access request ack message triggers a Start security procedures message towards the RNS; if the VMSC has not received a Start security procedures message from the VLR, the Start security procedures message indicates no ciphering.
4.2.3 Maintaining a call
If the user has an active call the Mobility Management tracking is done in the UTRAN, at cell level (refer to 3.2.1 & 3.2.2), as long as the SRNC is not changing. Moving from one cell to another, the call will be maintained by soft (or softer) handovers (see 3.4.1). In case the user changes RNC, SRNS relocation takes place, in which the core network is involved (refer to 3.4.1).
65/100
References
The call handling procedures can be found in TS 23.018, Basic Call Handling.
Most ISDN supplementary services are supported within UMTS. A description of these services can be found in the TS 23-series of the specifications.
4.3 Session control (packet-switched)
A packet switched session is described in the core network by a PDP context. A PDP context is a set of information regarding a certain packet data flow. This information includes among others the endpoints of the data flow (addresses) and the quality of service. Different nodes involved in the data flow hold different, but overlapping subsets of this set of information.
The PDP address allows to address a UMTS user from an external Packet Data Network. Internally however, the PDP context is not identified by the PDP address but instead, lower layer identifiers (e.g. Network Service Access Point Identifier) and the IMSI is used.
The Access Point Name is a symbolic name for an interface on a GGSN to an external PDN. An APN identifies to which external PDN the data transmission takes place. The MS may provide an APN when setting up a PDP context, or the SGSN may retrieve the APN from the subscription information when a PDP context is set up.
A GPRS-attached MS can initiate the activation, modification, and deactivation functions at any time for a PDP context in the MS, the SGSN, and the GGSN. A GGSN may request the activation of a PDP context to a GPRS-attached subscriber and can initiate the deactivation of a PDP context. If the MS is in PMM-IDLE state, it needs to perform a service request procedure to enter the PMM-CONNECTED state before initiating these procedures.
Upon receiving an Activate PDP Context Request message or an Activate Secondary PDP Context Request message, the SGSN initiates procedures to set up PDP contexts. The first procedure includes subscription checking, APN selection, and host configuration. In case of a secondary context setup, the APN selection, host configuration and subscription checking are excluded. These PDP context parameters are reused and only the QoS parameters can be changed. Once activated, all PDP contexts that share the same PDP address and APN (but which can have a different QoS profile) are managed equally.
At least one PDP context shall be activated for a PDP address before a Secondary PDP Context Activation procedure may be initiated. When the MS performs a RA update procedure to change from a release 99 to a release 97 or 98 system, only one active PDP context per PDP address and APN shall be preserved. This PDP context is selected taking the QoS profile and the Network Service Access Point Identifier value into account.
Upon receiving a Deactivate PDP Context Request message, the SGSN initiates procedures to deactivate the PDP context. When the final PDP context, associated with a PDP address, is deactivated, the Network-Packet Data Unit transfer for this PDP address is disabled.
The preservation function allows active PDP contexts to be preserved, in case the associated RABs are released. There is no modification in the CN, and the RABs can be re-established at a later stage. By sending a RAB Release Request or Iu Release Request message to the SGSN, the UTRAN initiates the release of one or more RABs.
4.3.1 Static and Dynamic PDP Addresses
PDP addresses can be allocated to a MS in four different ways:
66/100
the HPLMN operator assigns a PDP address permanently to the MS (static PDP address);
the HPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic HPLMN PDP address);
the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDP address); or
the PDN operator or administrator assigns a permanent or dynamic IP address to the MS (External PDN Address Allocation).
It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can be used.
For every IMSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. For every IMSI, zero, one, or more static PDP addresses per PDP type can be subscribed to.
When dynamic addressing from the HPLMN or the VPLMN is used, it is the responsibility of the GGSN to allocate and release the dynamic PDP address. The GGSN allocates a client that contacts a server that allocates a PDP address. The client and the server interact according to protocols such as RADIUS or DHCP.
In dynamic PDP address allocation there is a distinction between the case of transparent access and the case of non-transparent access. Transparent access means that UMTS is not involved at IP level. The network provides a transparent IP bearer between the external PDN and the MS, and is not involved in the user authentication and authorisation process at IP level. Non-transparent access means that UMTS is involved in user authentication and authorisation. Before UMTS provides the IP bearer, it requires the user to be authenticated and authorised. As authentication and authorisation are functions related to address allocation, transparent access and non-transparent access differ also from address allocation point of view.
In case of transparent access the server is part of the UMTS operator domain. The PDP address that is allocated belongs to the address range of the UMTS operator.
In the network-requested PDP context activation case, currently static PDP addressing is required. For the future other mechanisms are studied.
4.3.2 Establishing a session
The PDP Context Activation procedure is illustrated in Figure 4-45
67/100
MS UTRAN 3G-SGSN 3G-GGSN
Activate PDP Context Request
Invoke trace
Activate PDP Context Accept
Note 1Radio Access Bearer Setup
Create PDP context request
Create PDP context response
Figure 4-45: PDP Context Activation Procedure for UMTS
Note 1: In Iu mode, the RAB setup is done by the RAB Assignment procedure, described at the end of this paragraph.
The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN. In case the MS uses a static PDP address, it can also include this in the activate PDP context request. To select a reference point to a certain external network and/or to select a specific service, the MS uses the Access Point Name. QoS Requested indicates the desired QoS profile and PDP Configuration Options (sent transparently through the SGSN) may be used to request optional PDP parameters from the GGSN.
After the RAB setup, the SGSN validates the Activate PDP Context Request using the PDP context subscription records and some optional parameters like: PDP Type, PDP Address, and Access Point Name, provided by the MS. (Validation takes place according to rules described in the specification 23.060).
- If no GGSN address can be derived or if the SGSN has determined that the Activate PDP Context Request is not valid, the SGSN rejects the PDP context activation request.
- If a GGSN address can be derived, the SGSN creates a Tunnel End point IDentifier for the requested PDP context. The SGSN lets the GGSN allocate the dynamic address (if required).
After validation, the SGSN sends a Create PDP Context Request (SGSN address, Access Point Name, QoS Negotiated, TEID, NSAPI, MSISDN) message to the affected GGSN. The Access Point Name indicates the port on the GGSN to the subscribed external PDN. In case a static PDP address is used, this is also included in the create PDP context request. The SGSN address is used for the GGSN to be able to set up the context to the right SGSN.
The GGSN creates a new entry in its PDP context table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs between the SGSN and the external PDP network, and to start charging.
The GGSN then returns a Create PDP Context Response (TEID, PDP Address, QoS Negotiated, Charging Id, GGSN address) message to the SGSN. The PDP Address is
68/100
included if the GGSN allocated a PDP address. In case the external PDN assigns the PDP Address, it is not included in the response message.
If the QoS Negotiated received from the SGSN is incompatible with the PDP context being activated, the GGSN rejects the Create PDP Context Request message. The GGSN operator configures the compatible QoS profiles.
If the PDP Context Activation Procedure fails or if the SGSN returns an Activate PDP Context Reject (Cause, PDP Configuration Options) message, the MS can attempt another activation to the same APN up to a maximum number of attempts.
For each PDP Context and Address, a different quality of service (QoS) profile may be requested. For example, some PDP addresses may be associated with E-mail that can tolerate lengthy response times. Other applications cannot tolerate delay and demand a very high level of throughput, interactive applications being one example. These different requirements are reflected in the QoS profile. If a QoS requirement is beyond the capabilities of a PLMN, the PLMN negotiates the QoS profile as close as possible to the requested QoS profile. The MS either accepts the negotiated QoS profile, or deactivates the PDP context.
Secondary and network initiated PDP context activation
The Secondary PDP Context Activation procedure may be used to activate a PDP context while reusing the PDP address and other PDP context information from an already active PDP context, but with a different QoS profile. Procedures for APN selection and PDP address negotiation are not executed. Each PDP context sharing the same PDP address and APN shall be identified by a unique TI and a unique NSAPI. The procedure is described in TS 3G 23.060
The Network-Requested PDP Context Activation procedure allows the GGSN to initiate the activation of a PDP context. When receiving a PDP PDU the GGSN checks if a PDP context is established for that PDP address. If no PDP context has been previously established, the GGSN may try to deliver the PDP PDU by initiating the Network-Requested PDP Context Activation procedure. The procedure is described in TS 3G 23.060
Radio Access Bearer Assignment procedure.
The purpose of the RAB Assignment procedure is to enable establishment of new RABs for a given MS and/or modification and/or release of already established RABs. When this procedure is executed and if there is any PDP context without radio access bearer assigned, all the radio access bearer are re-established. The same messages are used for the three mentioned actions and it is only the content carried by the messages that is different. The RAB Assignment procedure is shown below in Figure 4-46. is specified in 3G TS 25.413. The RRC protocol is specified in 3G TS 25.331.
MS RNC SGSN
RAB Assignment request
RRC: Establish / Release / Modify
Radio Bearers
RAB Assignment response
*
* It can be several responses
Figure 4-46: RAB Assignment procedure
The SGSN sends a RAB Assignment Request message to the RNC to establish, modify, or release one or several RABs. For each RAB requested to be established or modified, if the RAB is allowed for queuing and the resource situation requires it, the RNC may place the RAB in the establishment queue.
69/100
The RNC establishes, modifies, or releases the appropriate radio bearers.
The RNC returns a RAB Assignment Response message to the SGSN. If the request to establish or modify one or several RABs has been queued, the RNC will report the outcome of the establishment or modification in subsequent RAB Assignment Response messages. If the SGSN receives a RAB Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided (e.g., "Requested Maximum Bit Rate not Available"), then the SGSN may send a new RAB Assignment Request message with different QoS profile(s). The number of re-attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent.
4.3.3 Maintaining a session
The maintenance of a session is more or less equal to that of a call. In case a mobile subscriber leaves the coverage area of cells controlled by a specific RNC, and arrives into an area where he has dedicated channel(s) established to cell(s) whitin the coverage area of another RNC, SRNC relocation may take place. In case a new RA is entered, a RA update will be performed. If the new RA is served by another SGSN, then an inter-SGSN RA update procedure takes place, otherwise this is an intra SGSN RA update procedure (See for more information 3.4.1 SRNS relocation).
References
More information on PDP context setup and related matters can be found in TS 23.060.
For a MS with GPRS-CSI defined, CAMEL interaction may be performed, for further details the reader is referenced to TS 23.078.
4.4 Use of IP based services
The UMTS standards do not specify in detail the services to be offered to subscribers. Instead, mechanisms that support a range of services are defined. In this section some of these mechanisms are described. This section pays no attention to the supplementary services; though there are more supplementary services are some are enhanced, most of them are known from ISDN and GSM.
4.4.1 Access to intranet and Internet
The packet domain bearer for GSM (GPRS) and UMTS have been explained in section 4.3. Access to the intranet or Internet (through an ISP) is based on these bearers.
Typically in the IP networks, the interworking with subnetworks is done via IP routers. From the external IP network's point of view, the GGSN at the Gi reference point is seen as a normal IP router.
Interworking with user defined ISPs and private/public IP networks is subject to interconnection agreements between the network operators.
The access to external PDNs, i.e. Internet, intranet or ISP, may involve specific functions such as: user authentication, user authorisation, end-to-end encryption between MS and intranet/ISP, allocation of a dynamic address belonging to the PLMN/intranet/ISP addressing space, etc. For Internet, intranet or ISP access the Packet Domain offers: either direct transparent access to the IP network; or a non-transparent access to the IP network. In this case the GGSN takes part in the
functions listed above.
Transparent access to an intranet or ISP
In this case the mobile station receives
70/100
a static IP address when taking a subscription, or a dynamic IP address from the IP address pool managed by the mobile operator at
PDP context activation.
At activation of a PDP context the mobile station needs no authentication and the Packet Domain does not take part in the authentication and authorisation. The Packet Domain provides a transparent bearer between the mobile station and the intranet or ISP. Authentication and encryption of user data is done between mobile station and Intranet/ISP, using e.g. IPsec.
An operator providing static IP addresses needs a lot of IP addresses. An operator providing transparent access to an intranet or ISP with dynamic IP addresses should have sufficient IP addresses to be able to allocate one for the maximum number of concurrently activated PDP contexts.
Non-transparent access to an intranet or ISP
In this case the MS is given an address belonging to the intranet/ISP addressing space. The address is given either at subscription in which case it is a static address or at PDP context activation in which case it is a dynamic address. This address is used for packet forwarding within the GGSN and for packet forwarding on the intranet/ISP. This requires a link between the GGSN and an address allocation server, e.g. Radius or DHCP, belonging to the intranet/ISP.
The MS shall send an authentication request at PDP context activation and the GGSN requests user authentication from a server, e.g. Radius or DHCP. From the server, belonging to the intranet/ISP, the protocol configuration options are retrieved.
The communication between the Packet Domain and the intranet/ISP may be performed over any network, even an “insecure” one like the Internet. In case of an “insecure” connection between the GGSN and the intranet/ISP there may be a specific security protocol in between. This security protocol is defined by mutual agreement between PLMN operator and intranet/ISP administrator.
The Packet Domain (i.e. the GGSN) acts towards the intranet/ISP on behalf of the subscriber. The path between terminal equipment and intranet/ISP is therefore non-transparent.
Access using Mobile IP
Mobile IP is an IP technology originally aimed at radio LANs where a mobile node can ‘roam’ from one radio LAN segment to another radio LAN segment. This technology can also be used in the Internet and in GPRS/UMTS networks. It is a step towards seamles coverage for data.
71/100
Figure 4-47: The concept of Mobile IP.
The basics of Mobile IP, see Figure 4-47, are the address of a mobile station is replaced by the address of the so-called Home
Agent (HA), the last router towards the mobile station is called Foreign Agent (FA); the address of
the FA is called Care-of-Address (CoA) and stored at the HA, a communication partner, called Corresponding Node (CN), sends data to the HA
which tunnels it to the CoA, i.e. to the FA, the FA ends the tunnel and, being the last router, sends the data directly to the
mobile station, the data from the mobile station is sent by the FA (first router in this direction) directly
to the CN.
In UMTS (GPRS) a FA is located in the GGSN. The interface between the GGSN and the FA will probably not be standardised as the GGSN/FA is considered being one integrated node (refer to Figure 4-48). The mapping between these two is a matter of implementation. Each FA must be configured with at least one CoA. In addition a FA must maintain a list that combines IP addresses with the so-called Tunnel Endpoint IDentifiers (TEIDs) of all the visiting MSs that have registered with the FA. IP packets destined for the MS are intercepted by the HA and tunneled to the MS's CoA, i.e. the FA. The FA de-tunnels the packets and forwards the packets to the MS. Mobile IP related signalling between the MS and the FA is done in the user plane. MIP registration messages are sent with UDP.
72/100
Figure 4-48: The protocol stacks in the GGSN with the Gi interface for MIP signalling
For those faminiar with (wireless) LANs: when Mobile IP is used to connect to e.g. an intranet, the HA is in that intranet. To the intranet, the UMTS network looks like another (wireless) LAN segment.
References
TS 29.061 describes the interworking between the Public Land Mobile Network (PLMN) supporting packet based services and the Packet Data Network (PDN)This standard describes, in addition to this section and the protocol stacks from section 2.5, Numbering and Addressing, Charging, the DNS and DHCP servers, and various message flows in detail. For Mobile IP a reference is made to RFC 2002 and in RFC 1825 IPsec is fully described.
4.4.2 Virtual Home Environment / Open Services Architecture
Virtual Home Environment (VHE) is defined as a concept for personal service environment portability across network boundaries and between terminals. The concept of the VHE is such that users are consistently presented with the same personalised features, user interface customisation and services in whatever network and whatever terminal (within the capabilities of the terminal and network). In other words, the user should always feel `at home’.
The key requirements of the VHE are to provide a user with a personal service environment (PSE) which consist of: personalised services; personalised user interface (within the capabilities of terminals); consistent set of services from the user's perspective irrespective of access (e.g.
fixed, mobile, wireless etc.). Global service availability when roaming.
In fact these requirements imply that service portability is to be provided when roaming between mobile networks, between fixed and mobile network and between private and public networks.
The home environment provides and controls services to the user in a consistent manner. The Personal Service Environment (PSE) describes how the user wishes to manage and interact with her communication services. It is a combination of a list of subscribed to services, service preferences and terminal interface preferences. PSE also encompasses the user management of multiple subscriptions, e.g. business and private, multiple
73/100
terminal types and location preferences. The PSE is defined in terms of one or more user profiles.
The user profiles consist of two kinds of information: interface related information (User Interface Profile); and service related information (User Services profile).
In order to implement a VHE, including not known end user services/applications today, a highly flexible Open Service Architecture (OSA) is required. The Open Service Architecture (OSA) is an architecture, enabling applications to make use of network capabilities such as e.g. locating the subscriber.
Network functionality offered to applications is defined as a set of Service Capability Features (SCFs) in the OSA API, which are supported by different Service Capability Servers (SCS). These SCFs provide access to the network capabilities on which the application developers can rely when designing applications. The different features of the different SCSs can be combined as appropriate.
Figure 4-49: Overview of Open Service Architecture
The standardised OSA API satisfies all things operators like: provides an extendible and scalable architecture that allows for inclusion of new
service capability features and SCSs in future releases of UMTS with a minimum impact on the applications using the OSA API
is secure, is independent of vendor specific solutions and independent of programming
languages, operating systems, etc used in the service capabilities. is independent of the location within the home environment where service capabilities
are implemented and independent of supported server capabilities in the network. is based on lower layers using main stream information technology and protocols. is possibly distributed: the Service Capability Servers that provide the OSA interfaces
are functional entities that can be distributed across one or more physical nodes.
The VHE/OSA combination offers a lot of potential; implementations of these standards have to prove that this potential provides real benefit to subscriber and operator(s). So far the enabling technologies described in the following subsections provide steps towards the full VHE, but more steps need to be taken.
References
The requirements for the Virtual Home Environment are specified in TS 22.121, and the description on how applications will access the network through the OSA API specified in
74/100
TS 23.127. In TS 29.198 and TR 29.998 the OSA API itself is defined using OMG Interface Description Language™: for each method (function) it provides the name of the method, direction of use, parameters, result and possible errors.
4.4.3 Multimedia Messaging Services
Multimedia Messaging Services combine different networks and network types and integrate messaging systems already existent within these networks. It creates a VHE with respect to messaging services.
Figure 4-50: General view of MMS provision within the different networks
Figure 4-50 shows a generalised view of the Multimedia Message Service architecture for a third generation messaging system. The mobile station operates with the Multimedia Messaging Service Environment, MMSE. This environment may comprise 2G and 3G networks, 3G networks with islands of coverage within a 2G network and roamed networks. The MMSE provides all the necessary service elements, e.g. delivery, storage and notification functionality. These service elements may be located within one network or distributed across several networks or network types.
Figure 4-51 shows that multimedia messaging may encompass many different network types. The basis of connectivity between these different networks shall be provided by the Internet protocol and its associated set of messaging protocols. This approach enables messaging in 2G and 3G wireless networks to be compatible with messaging systems found on the Internet.
MMS shall support the use of E-Mail addresses or MSISDN to address the recipient of a Multimedia Message (MM). In the case of E-Mail addresses standard Internet message routing should be used.
The usage of MSISDN for addressing a recipient in a different MMS service providers domain shall be possible. This requires MSISDN translation to a routable address. The mapping for the MSISDN to the correct recipient's MMS Relay or Server is not yet standardised (left for standardisation in future releases).
75/100
Figure 4-51: MMS Architectural Elements
MMSE
The Multimedia Message Service Environment encompasses all the various elements that provide a complete MMS to a user. In the case of roaming, the visited network (B) is considered part of that user's MMSE. However, subscribers to the mobile network B are considered to be part of a separate MMSE.
MMS Relay and MMS Server
The MMS Server is responsible for storage and handling of incoming and outgoing messages. Associated with the MMS Server, is the MMS Relay, which is responsible for the transfer of messages between different messaging systems. Depending on the business model, the MMS Server and the MMS Relay may be combined, separate or distributed across different domains.
The MMS Relay should be able to generate charging data (CDR) when receiving MMs or when delivering MMs to the MMS User Agent or to another MMSE.
The MMS Relay may include protocol conversion (including type and format conversion) as shown in the figure below. This protocol framework provides implementation flexibility, integration of existing and new services together with interoperability across different networks and terminals. In this framework the MMS User agent communicates through the MMS Relay with the MMS Server. This MMS Relay shall provide convergence functionality between server and MMS user agent and thus enabling the integration of different server types across different networks. It should be possible to combine Server and Relay functionality.
76/100
Figure 4-52: Protocol conversion in the MMS Relay
The case of WAP as MM Transfer Protocol A is elaborated in TS 23.140. When the MMS Server is an e-mail server, the MM Transfer Protocol B could e.g. be SMTP.
In addition the MMS Relay provides the following functions: receiving and sending MM; enabling/disabling MMS function; personalising MMS based on user profile information; MM deletion based on user profile or filtering information; message content retrieval; MM forwarding; screening of MM; negotiation of terminal capabilities; checking terminal availability; MM notification to the MMS User Agent; generating charging data records (CDR); address translation.
MMS User Databases
This element may be comprised of one or more entities that contain user related information such as subscription and configuration (e.g. user profile database, subscription database, HLR). These databases should provide MMS user subscription information; information for the control of access to the MMS; information for the control of the extent of available service capability (e.g. server
storage space); a set of rules how to handle incoming messages and their delivery; information of the current capabilities of the users terminal.
MMS User Agent
The User Agent resides on a MS or on an external device connected to a MS. It is an application layer function that provides the users with the ability to view, compose and handle MMs. The basic functions it supports are the MM composition, the MM
77/100
presentation, the presentation of notifications to the user and the retrieval of MMs (initiate MM delivery to the User Agent). Optionally the MMS User Agent supports e.g. the signing of a MM (allowing the reciever to verify the sender is realy the person he claims to be) on an end-user to end-user basis, the decryption and encryption of a MM on an end-user to end-user basis, all aspects of storing MMs on the terminal and/or USIM, the handling of external devices and the user profile management.
Supported multimedia element types
Multiple media elements shall be combined into a composite single MM using MIME multipart format.
In order to guarantee a minimum level of compatibility between multimedia messaging capable terminals, the following media formats shall be at least supported. Text formats: plain text. Any character encoding (charset) that contains a subset of
the logical characters in Unicode shall be used SMS: the SMS MIME type shall be used as soon as the MIME registration has been
completed. Audio: AMR / EFR; organised in octet format, MP3, MIDI, WAV. Image: JPEG, GIF 89a. Video: MPEG 4 (Visual Simple Profile, Level 1), ITU-T H.263, Quicktime.
References
TS 22.140 and TS 23.140 describe the non realtime Multimedia Messaging Service, MMS. It contains the core functions for a non realtime Multimedia Messaging Service, MMS, which are sufficient to provide a basic service. Where possible references are given to existing standards for protocols, e.g. WAP in TS 23.140, and standardised formats (RFC 822 for email addresses, RFC 2046 for MIME, TS 26.101 for the AMR/EFR octet format, etc.).
4.4.4 Location Services
Location Services may be considered as a network provided enabling technology consisting of standardised service capabilities, which enable the provision of location applications. The application(s) may be service provider specific. The description of the numerous and varied possible location applications which are enabled by this technology are outside the scope of standardisation.
By making use of the radio signals the capability to determine the (geographic) location of specific mobile station shall be provided, based on the IMSI or MSISDN of the mobile. The location information may be requested by and reported to a client (application) associated with the MS, or by a client within or attached to the core network (including lawful interception and emergency calls). The location information may also be utilised internally by UMTS; for example, for location assisted handover or to support other features such as home location billing. The position information shall be reported in standard, i.e. geographical co-ordinates, together with the time-of-day and the estimated errors (uncertainty) of the location of the MS.
It shall be possible for the majority of the MS (active or idle) within a network to use the feature without compromising the radio transmission or signalling capabilities of the UMTS.
Both GSM BSS and UTRAN should be used for determination of the location of a mobile station. However, it should be noted that the UTRAN will include support for LCS in release 1999, however full system support for LCS with UTRAN will be a part of release 2000. UMTS Release 99 supports only cell coverage based LCS in the circuit switched domain, i.e. the location of the mobile station is based on the serving cell – the estimated location of all mobile stations in a cell is the same. In addition UMTS Release 99 also contains LCS "hooks" for compatibility with future releases.
78/100
Quality of Service for LCS is defined in terms like horizontal accuracy (10m – 1km), vertical accuracy, delay (no, low or any delay), priority, security, support of roaming MSs, timestamp and privacy. In most cases these will be determined by the operator and/or national authorities. Depending on the application some parameters can be set by the subscriber in a user profile (see subsection 4.4.2).
Functions
A range of functions is specified from which the LCS is built. Their relation is shown in the functional diagram in Figure 4-53.
The Location Client Function (LCF) provides a logical interface between the LCS client and the LCS server. This function is responsible for requesting location information for one or more MSs, with a specified "QoS" and receiving a response, which contains either location information or a failure indicator.
The Location Client Control Function (LCCF) manages the external interface towards LCF. The LCCF identifies the LCS client by requesting client verification and authorisation ( i.e. verifies that the LCS client is allowed to position the subscriber) through interaction with the Location Client Authorisation Function (LCAF). The LCCF handles mobility management for location services (LCS) e.g., forwarding of positioning requests to 3G-VMSC. The LCCF determines if the final positioning estimate satisfies the QoS for the purpose of retry/reject. The LCCF provides flow control of positioning requests between simultaneous positioning requests. It may order the Location Client Co-ordinate Transformation Function (LCCTF) to perform a transformation to local co-ordinates. It also generates charging and billing related data for LCS via the Location System Billing Function (LSBF).
79/100
Figure 4-53: UMTS LCS capability server Functional Diagram
The Location System Control Function (LSCF) is responsible for co-ordinating location requests. This function manages call-related and non-call-related positioning requests of LCS and allocates network resources for handling them. The LSCF retrieves MS capabilities, indicated by the so-called classmark, for the purpose of determining a positioning method. The LSCF performs call set-up if required as part of a LCS e.g., putting the MS on dedicated radio resources. It also caters for co-ordinating resources and activities with regard to requests related to providing assistance data needed for positioning.
The Access Network Location System Control Function (U-LSCF) is responsible for co-ordinating location requests. This function manages call-related and non-call-related location requests and allocates network resources for handling them. This function "insulates" the Location clients in the Core Network from the detailed operation of the location method in order that the Access Network may be used by several types of core network and with several location methods.
The Location System Billing Function (LSBF) is responsible for charging and billing activity within the network related to location services. This includes charging and billing of both clients and subscribers. Specifically, it collects charging related data and data for accounting between PLMNs.
The Location System Operations Function (LSOF) is responsible for provisioning of data, positioning capabilities, data related to clients and subscription (LCS client data and MS data), validation, fault management and performance management of UMTS LCS.
80/100
The Location Subscriber Authorisation Function (LSAF) is responsible for authorising the provision of a location service (LCS) for a particular mobile station. Specifically, this function validates that a LCS can be applied to a given subscriber. In case LCF is in the MS then LSAF verifies that the MS subscriber has subscribed to the requested LCS service.
The Location Subscriber Privacy Function (LSPF) performs all privacy-related authorisations. For a target MS it authorises the positioning request versus the privacy options of the target MS, if any.
The positioning components UMTS Access Network - Positioning Radio Co-ordination Function (U-PRCF), UMTS Access Network Positioning Calculation Function (U-PCF), UMTS Access Network - Positioning Signal Measurement Function (U-PSMF) and UMTS Access Network - Positioning Radio Resource Management (U-PRRM) are described in documents specific to each Access Network type (GSM, UTRAN, etc.).
Architecture
Figure 4-54 depicts the logical architecture, with the functions described above allocated to network elements.
Figure 4-54: Generic LCS Logical Architecture
Most functions are allocated to existing network elements. One new network element is introduced, the Gateway Mobile Location Centre (GMLC), which contains functionality required to support LCS. In one PLMN, there may be more than one GMLC.
The GMLC is the first node an external LCS client accesses in a GSM PLMN (i.e. the Le reference point is supported by the GMLC). The GMLC may request routing information from the HLR via the Lh interface. After performing registration authorisation, it sends positioning requests to and receives final location estimates from the 3G-MSC via the Lg interface.
81/100
References
TS 22.071 and TS 23.171 describe the LoCation Services (LCS) feature in UMTS. This latter document covers the LCS system functional model for the whole system, the LCS system architecture, state descriptions, message flows, etc. TS 23.032 specifies how the geographical co-ordinates should be described with the Universal Geographic Area Description (GAD).
TR 25.305 describes the positioning components of the UMTS Access Network. This includes e.g. the definition of Location Measurement Units.
4.4.5 CAMEL
CAMEL means Customised Applications for Mobile Network Enhanced Logic and is implementation of Intelligent Network technology in the GSM/UMTS network. This enables the provisioning of Operator Specific Services across network boundaries (which is not possible with the conventional Intelligent Network technique). CAMEL was developed for call-related services. However, with CAMEL phase 3, additions have been incorporated to support also packet switched services and SMS. For packet switched services and SMS there is no IN equivalent (in fixed networks).
CAMEL basics
The general principle of CAMEL is as follows. For a customer roaming in another network, the visiting network registers the location of the customer. In this registration procedure the HLR sends some information to the VLR (about IMSI, Call Forwarding settings, etc.). Among these parameters is also the so-called Camel Subscription Information (CSI), which contains some service information and the CAMEL Service Control Point (SCP) address in the home network.
Figure 4-55: Mobile Originating call with CAMEL
If the roaming customer starts a call set-up, the MSC in the visiting network detects from the CSI information in the VLR that this customer needs a CAMEL service and the MSC will establish a signalling relation with the SCP in the home network (refer to Figure 4-55).
The SCP performs the service logic (e.g. a number translation) and sends instructions back to the MSC, which continues the call set-up procedure.
It is also possible for a customer to have a terminating CAMEL service (refer to Figure 4-56). If someone calls the roaming customer, the call is routed to a MSC in the home network. This MSC contacts the HLR for information on the location of the subscriber, but will also receive the CSI. Then the MSC in the home network will contact the CAMEL SCP, before continuing call set-up.
82/100
Figure 4-56: Mobile Terminating call with CAMEL
In CAMEL it is also possible for the SCP to request some information from the HLR, such as status of the terminal, or its location.
Types of services related to CAMEL
CAMEL is a building block for services, not a service itself. Types of services that can benefit from CAMEL are e.g.:
rerouting of calls (barring, number translation, time or location dependent routing) charging of calls (tariff changing, Prepaid) rerouting of SMS (prevent delivery of SMS) charging of SMS changing of SGSN to which the GPRS terminal is attached (when terminal is moving) changing of Access Point name (GGSN) installing and monitoring data packet thresholds (and react on reaching the threshold) view and block USSD messages sent or received by the user.
CAMEL related network elements
The network operator decides on the availability of CAMEL in a network, because the network operator owns the Service Sswitching Function (SSF, located in a switch, or located on a dedicated switch, or located in the SGSN) and the HLR (in which the trigger detection points are stored).
At the moment network operator X allows for CAMEL services, the roaming customers of other network operators can activate their CAMEL services. Network operator X has to provide the CAMEL SSFs. However, network operator X has no influence on the services, those are provided by the PLMN the roaming subscribers belong to.
The Network Operator can install a SCF in its network to offer CAMEL based services to its own customers. In the HLR it is registered for which users in which situations these CAMEL services can become active.
CAMEL related interfaces
SSF – SCF
As described above, this interface is crucial for the operation of CAMEL. The owner of the SCF can decide which SSFs may access the SCF. CAMEL is developed in phases (versions), which are backward compatible. Each phase (version) means an update in the
83/100
interface protocol. Both SSF and SCF should support the same version in order to exploit the capabilities of this version.
SCF – HLR
Some services in CAMEL need contact with the HLR. The owner of the HLR can decide which SCFs may access the information in the HLR. In most cases the same party owns both HLR and SCF.
References
TS 22.078 and TS 23.078 describe the third phase of CAMEL, which provides the mechanisms to support services of operators which are not covered by standardised GSM services even when roaming outside the HPLMN. TS 23.078 addresses especially the need for information exchange between the visited PLMN (VPLMN) and the home PLMN (HPLMN) for support of operator specific services.
TS 29.078 specifies in detail the CAMEL Application Part (CAP) signalling messages and their parameters supporting the third phase of CAMEL.
4.4.6 Terminal Based Services
More and more processing power is incorporated in the coming generations of mobile terminals, and the number of types of terminals is expected to grow: phone like terminals, PDA like terminals, screens of various sizes, etc. In standardisation two important directions of work on terminals support these trends:
USIM Application Toolkit (USAT) Mobile station application Execution Environment (MExE)
USAT
SAT/USAT19 provides a standardised execution environment for applications stored on the USIM card and the ability to utilize certain functions of the supporting mobile equipment. USAT provides mechanisms which allow applications, existing in the USIM, to interact and operate with any ME which supports the specified mechanism(s). Thus interoperability between a USIM and a ME is ensured, independent of the respective manufacturers and operators. A transport mechanism is provided enabling applications to be down-loaded and/or updated.
A significant aspect of USAT is the highly secure environment provided by the USIM card. This is further enhanced by the fact that the subscriber and the issuer of the USIM and also the USAT applications have a "trusted relationship" (e.g. the subscriber trusts the issuer of the card to charge correctly for the resources used). This allows certain features, such as call control, to be implemented with a degree of freedom which would not be acceptable in a "non-trusted relationship".
More precise, the USAT provides mechanisms which allow applications, existing in the Universal Integrated Circuit Card (UICC)20, to interact and operate with any ME which supports the specific mechanism(s) required by the application. For some mechanisms additional functionality should be supported by the ME. This is indicated by the so-called class of the ME. If class "a" is supported, a USIM supporting USAT shall be able to communicate with
the additional card(s) and get information about the additional reader(s) via the ME. Such an additional reader might for instance read a bank card with electronic purse.
19 In the sequel USAT is used instead of SAT/USAT and USIM is used for SIM/USIM.20 Note that a USIM is a special kind of UICC. Often one can read USIM for UICC, but sometimes there are other UICCs.
84/100
If class “b” is supported, the ME running an AT command received from the USIM, and returning the result to the USIM.
If class “c” is supported, the ME can launch a browser and display the contents associated with a given URL.
If class “d” is supported, the ME supports “soft keys”. If class “e” is supported, the ME is able to establish and manage a bearer
independent protocol.
The following USAT mechanisms have been defined.
Profile Download
Profile downloading provides a mechanism for the ME to tell the UICC what it is capable of.
Proactive UICC
Proactive UICC gives a mechanism whereby the USIM can initiate actions to be taken by the ME. These actions include displaying text from the USIM to the ME, sending a short message, setting up a voice call to a number held by the USIM, setting up a data call to a number and bearer capabilities held by the USIM, sending a Ssupplementary service control string, playing a tone in the earpiece, initiating a dialogue with the user, managing timers running physically in the ME, sending DTMF tones, and certain actions depending on the supported class.
For each command involved in the dialog with the user, a help information may be available, either for each item of a list of items proposed to the user, or with each command requesting a response from the user. If a proactive command involved in the dialog with the user indicates the availability of the help feature, the support of this feature is optional for the ME.
Data download to UICC
Data downloading to the USIM uses either dedicated commands (the transport mechanisms of SMS point-to-point and Cell Broadcast) or the Bearer independent protocol.
Menu selection
A set of possible menu entries is supplied by the UICC in a proactive UICC command. The menu selection mechanism is used to transfer the UICC application menu item which has been selected by the user to the UICC. The menu selection mechanism may also be used for requesting help information on the items of the UICC application menu.
Call control by USIM
When this service is activated by the USIM, all dialled digit strings, supplementary service control strings and USSD strings are first passed to a USIM application before the ME sets up the call or the supplementary service operation. The ME shall also pass to the USIM application at the same time its current serving cell. The USIM application has the ability to allow, bar or modify the call or the supplementary service operation. The USIM application also has the ability to replace a call request or a supplementary service operation by another call request or supplementary service operation. For example, a call request can be replaced by a supplementary service operation, and vice-versa.
MO Short Message control by USIM
When this service is activated by the USIM, all MO short messages are first passed to the USIM application before the ME sends the short message. At the same time the ME also passes its current serving cell to the USIM application. The USIM application can to allow the sending, bar the sending or modify the destination address of the short message before sending it.
85/100
Event download
In a proactive UICC command the USIM can supply to the ME a set of events to monitor for. The event download mechanism is used to transfer details of the event to the USIM, when it occurs. Events that the ME can report to the USIM include incoming calls, location status, and availability of the screen for applications.
Security
Applications designed using the features in the present document may require methods to ensure data confidentiality, data integrity, and data sender validation, or any subset of these.
Multiple card
One event and a set of proactive commands are supplied to monitor and control Card x behaviour. This applies only if class "a" is supported.
Timer Expiration
The USIM is able to manage timers running physically in the ME with a proactive command. The Timer Expiration mechanism is used to inform the USIM when a timer expires.
Bearer Independent Protocol
The set of proactive commands and events allows the USIM to establish a data channel with the ME, and through the ME to a remote Server in the Network. The USIM provides information for the ME to select an available bearer at the time of channel establishment. The ME then allows the USIM and the Server to exchange data on this channel, transparently. This applies if class "e" is supported.
MExE
Considering the wide and diverse range of current and future technology and devices that (will) use wireless communication and provide services based on them, a one-size-fits-all approach is unrealistic. A generic MExE architecture to overcome this is shown in Figure 4-57. The UMTS standard categorises devices by giving them different MExE classmarks21. Currently two MExE classmarks are defined:
MExE classmark 1 - based on WAP (Wireless Application Protocol) - requires limited input and output facilities (e.g. as simple as a 3 lines by 15 characters display and a numeric keypad) on the client side, and is designed to provide quick information access even over narrow and slow data connections.
MExE classmark 2 - based on Personal-Java - provides and utilises a run-time system requiring more processing, storage, display and network resources, but supports more powerful applications and more flexible man-machine interfaces. MExE Classmark 2 also includes support for MExE classmark 1 applications (via the WML browser.)
Future classmarks may require other Java-packages, APIs, and/or support of other features such as speech-recognition, video-I/O with online (de)-compression, minimal storage requirements, high-speed local communication, etc., but these are subject to future standardisation efforts.
Content negotiation allows for flexible choice of formats available from a server or adaptation of a service to the actual classmark of a specific client device.
21 Note that the MexE classmark is independent of the USAT class.
86/100
GSM air interface
signalling channel
• b-channel control
data bearer
• mm mail control & xfer• Web access• software downloads• backup / file synch.• user-user applications
voice bearer• voice channel
SMSC• SMS store & forward
3rd partyservices
notificationservice
faxservice
databackup
GSMSwitching
Fabric
• personal messaging(text, …)
• mail notification• other notifications
Short Message Service
**Possible configuration
network accessserver
• data fan-out• protocol translations
Mobile Station
MExE Service Environment**
Figure 4-57: Generic MExE architecture
Bi-directional capability negotiation between the MExE Service Environment (MSE) and MExE device (including MExE classmark), supports the transfer of capabilities between the client and the server. Communication between the MExE MS and the MSE supports:
Capability negotiation
The MExE MS connects to the MSE by using HTTP/1.1 or an HTTP/1.1 derived protocol. Capability negotiation between the MExE MS and the MSE only takes place for the first time after the MExE MS has connected to the MSE, and the MSE is informed about the MExE MS.
Capability negotiation represents the mechanism by which the MExE MS and the MSE interact to inform each other of the specific mechanisms, capabilities and support which each is able to provide or support within the scope of a MExE service interaction. The capability negotiation normally takes place prior to any content transfer between the two entities. The MExE MS may also spontaneously inform the MSE of its capabilities (i.e. following a change in MExE support, such as removal of MExE MS from a docking station with its keyboard, mouse and monitor).
Content negotiation
Content negotiation represents the means by which the MExE MS and the MSE inform each other of the requested and available form of content. If needed, the content negotiation may take place following capability negotiation between the two.
Content negotiation is used to select the best representation of an entity when there are multiple representations of the entity available from the MSE. The entity (e.g. a service, an image, etc) is located behind a Uniform Resource Identifier (URI), and the application in the MExE MS connects to the URI by using HTTP/1.1 or an HTTP/1.1 derived protocol. The best representation of an entity can be decided by the server (server-driven negotiation) or by the client application (agent-driven negotiation).
Both the capability and the content negotiation has the same purpose: to optimise the content according to client’s capabilities. The term "content negotiation" has been used
87/100
e.g. in the HTTP specification. The HTTP/1.1 and the WSP contain headers to perform the content negotiation. However, the capability negotiation in MExE aims at extending the basic HTTP and WSP methods for content negotiation. MExE terminal is free to use both the existing HTTP/WSP content negotiation methods and the new MExE capability negotiation methods.
References
TS 22.038 contains the general description of the SIM/USIM application Toolkit (SAT/USAT) where TS 31.111 provides a more detailled view on USAT.
TS 22.057 defines the Mobile Station Application Execution Environment (MExE) in general and TS 23.057 provides the details with, among others, the functional capabilities and information flows needed to support the service.
88/100
5 Introduction to CDMA (UMTS) for core network specialists
This chapter is included to allow core network specialists to get a basic understanding of UMTS radio principles. For CDMA there are many good books (ask your radio network colleagues), so references in this chapter to the UMTS standard are not included.
5.1 Multiple access: CDMA principles
It is easier to understand a more complicated concept (UMTS) by comparing it to a rather more familiar concept (e.g GSM). Figure 5-58 shows graphically a comparison of multiple access scheme between UMTS and GSM. UMTS deploys multiple 5 MHz carriers. It uses CDMA to enable multiple users to share the bandwidth. In comparison, GSM uses 125 carriers of 200 KHz and uses TDMA to divide each carrier in 8 different physical channels (timeslots).
Figure 5-58: Comparison of multiple access scheme in GSM (left) and UMTS (right)
In a CDMA (Code Division Multiple Access) system, users share the same frequency bandwidth to communicate. For UMTS a CDMA channel of 5 MHz bandwidth (WCDMA or Wideband CDMA) for each carrier is used.
In order for several users to be able to use the same bandwidth at the same time, a multiple access scheme is needed. To achieve this, each user is assigned a unique code sequence it uses to encode its information-bearing signal. Naturally, this code must also be known at the receiver. Since the bandwidth for the code is chosen to be much larger than for the information-bearing signal, the encoding process enlarges (spreads) the spectrum of the signal and is therefore also known as spread spectrum modulation.
Some of the most common modulation techniques that generate spread-spectrum signals are: frequency hopping (FH), time hopping (TH) and direct sequence (DS). In FH and TH, the assignment of partial frequency bands and time slots, respectively, to the users is changing to hopping patterns instead of being fixed. In DS, the information-bearing signal is multiplied directly by a high rate of spreading code. This DS-CDMA is used for the UMTS Terrestrial Radio Access Network (UTRAN).
The use of such spreading code in UMTS makes it possible, in principle, to admit every new call. The number of codes does not limit the number of admitted calls. However, high number of calls decreases the quality of active calls because of the interference. In
89/100
other words, the capacity of a CDMA system is primarily interference limited rather than bandwidth limited (as in GSM).
This situation can be illustrated by an analogy of an international cocktail party in a large room (a wideband carrier) where pairs of people enter. Since every pair uses a different language (a unique code in CDMA), people speaking Dutch will hear virtually nothing from those speaking French, etc. So, they can all use the air in the room as a carrier for their voices and experience little interference from the other pairs. More and more pairs can enter the room as long as they use different language (the unique code in CDMA) until a situation where their conversation (message signal) can not tolerate the overall "background noise" (interference from other users). The number of conversations which can take place in the room is maximum (the maximum number of users per carrier) when the voice volume (signal strength) of all users create the maximum allowable interference. Consequently, the maximum number of users (effective traffic channels) per carrier depends on the amount of activity that is going on in each channel, and is therefore not fixed (soft limit). That is to say more users (or conversation, in our analogy) can usually be accommodated if necessary, at the "cost" of a bit more interference to the other users.
We can however, determine the number of simultaneous users that can be accommodated by the system if we make a few assumptions about the system. Firstly, assume that all signals have identical average powers at the base station. With such power control, if there are M simultaneous users, the desired signal (C) to noise (I) interference power ratio at the receiver is given by
Here we implicitly assumed that the code sequences used by the various users are orthogonal and that the inference from the other users on the channel adds on a power basis only (neglecting the thermal noise). This is extremely hard to achieve in practice, however the method described below to determine the maximum number of users in the system will give a rough approximation.
The key ratio in CDMA is the energy-per-bit to interference-plus-noise-power-density ratio which is denoted by Eb/NO. This term is directly related to the frame error rate (FER), hence the quality of service of the conversation. In developing a CDMA system, we need to consider the system performance under all possible conditions and to come up with the specified Eb/NO. To do this we use the following equation (assume that all users are constantly active), where Rb is the user information plus overhead bit rate, Bs is the system (UMTS) bandwidth :
Solving the two equations above for Mmax, the maximum number of simultaneous users, we have :
The variable G denotes processing gain,
90/100
We can see here that within any given channel bandwidth (chip rate) we will have a higher processing gain for lower user data bit rates than for high bit rates.
Typically, for a user data bit rates of 1 Mbps the processing gain is,
while a user data bit rates of 100 Kbps has processing gain,
5.2 Demodulation
5.2.1 Multipath
The received signal is ideally reconstructed from only a single direct path of transmitted signal. However in a real wireless cellular environment there are variations of structures along the path between transmitter and receiver, ranging from direct line-of-sight (LOS) to severely obstructing structures such as buildings, mountains, or foliage. These variations give rise to physical phenomena such as reflections, refractions and diffractions in addition to path loss.
In a multipath channel a receiver receives several copies of the same transmitted signal with different delays. However, the receiver can separate those multipath components and combine them to obtain multipath diversity if the signals arrive more than one chip apart from each other. The chip duration at 3.84 Mcps is 0.26 s. So, if the time difference of the multipath components is at least 0.26 s, the receiver can resolve them. The corresponding path difference for time difference of 0.26 s is 78 m (78 obtained by speed of light, that is 3 x 108 m s-1, divided by chip rate of 3.84 Mcps). Accordingly, the receiver can also resolve the multipath components if the path difference is at least 78 m, which is reasonably small for cell size.
5.2.2 Rake receiver
A multipath signal gives an advantage to CDMA, since the CDMA rake receiver can use multipath to improve a signal. The CDMA receiver comprises a number of correlation receivers, termed "fingers", which are capable of receiving the various multipath signals. The receiver selects the three strongest received multipath signals, time shifts them, and then sums them together to produce a signal that is better than any of the individual signal components.
A rake receiver block diagram using Maximal Ratio Combining (MRC) is shown in . Input signals from RF are received as digital complex-value on I- and Q-branches, where I and Q denote real and imaginary parts, respectively. A matched filter is used to select the current multipath delay profile of the channel based on the identification of time delay positions at which significant energy arrives. The selection results in allocation of the appropriate rake fingers. Code generators and correlator perform the despreading and integration to user data symbols. The channel estimator uses known pilot symbols for estimating the momentary channel state. Using this estimated value, the phase rotator rotates the received symbols back in order to compensate the phase rotation caused by the multipath channel. This
91/100
Figure 5-59: A Rake receiver block diagram
process is called Maximal Ratio Combining (MRC) and is illustrated in Figure 5-60. In each finger of CDMA rake receiver, the delay equalizer adjusts the time delay caused by multipath. Finally, the rake combiner sums the output of the equalizers across all active fingers and feeds them to the decoder for further processing.
Figure 5-60: The principle of MRC
5.2.3 Macro diversity
In CDMA it is possible for neighbouring cells to use the same frequency. As a consequence, a mobile can be served by more base stations (BTS) at the same time, which is called macro diversity.
When a mobile is close to the cell boundary its signal is usually not received well by the serving BTS. Using macro diversity, the mobile can be connected to more BTSs where the different signals can be combined, resulting in a better connection quality.
Macro diversity can also be used for soft handover (see subsection 3.4.1). Hard handover is used if the (new) target cells have different frequencies from the source cells. Hard handover means that the mobile first has to break its current connection with the source BTS before it can set up another connection with the target BTS. In contrast to the hard handover, soft handover allows a mobile to set up a new connection with the target BTS without breaking the active connection. Soft handover is smoother than hard handover.
In the downlink, from BTS to MS, macro diversity means the transmission originates from several sources and diversity reception is handled by one receiver unit in the mobile station. All extra transmissions increase some contribution to the interference. However, a rake receiver is able to combat this situation in a similar way it creates multipath diversity, where the number of separable paths increases the capability to resolve multipath signal. That is to say, with downlink macro diversity the rake receiver capability in obtaining gain from the extra diversity is depending on the number of available rake fingers. A limited number of rake fingers leads to failure to collect enough energy from the transmissions from two or more BTSs. In that situation, the gain obtained from the
92/100
downlink macro diversity is not able to overcome the high interference caused by the extra transmissions to the mobile.
In the uplink, the macro diversity has only positive impacts because the more BTSs try to detect signals, the higher the probability is for at least one to succeed.
5.3 Duplexing: FDD and TDD
In the UMTS standard two methods are defined to duplex the uplink and downlink: WCDMA which uses frequency devision duplex (FDD), and TDCDMA which uses time division duplex (TDD)
Figure 5-61 gives the operating principles for FDD and TDD methods. In FDD, the duplex method different frequencies are used for the uplink and downlink. One of the carriers from each pair is used for the uplink, the radio link from MS to BTS, and the other one for the downlink, the radio link from BTS to MS. In TDD, the same frequency band is used for both uplink and downlink but alternates the transmission direction in time. Since in TDD mode there is a TDMA component in the multiple access, in addition to DS-CDMA, the multiple access has often been denoted as TDMA/CDMA.
From points that can be directly compared, some advantages (marked as “+”) as well as disadvantages (marked as “–“) of TDD are compared to FDD as follows :
+ Asymmetric capacity allocation on up- and downlink. Since TDD divides uplink and downlink in the time domain, capacity can be moved between uplink to downlink by allocating more time to one of them. This is suitable for applications with asymmetric traffic, for example internet browsing which demands higher bit rates on the downlink than on the uplink.
Figure 5-61: Principles of FDD and TDD operation in UMTS
93/100
+ Reciprocal nature of the channel. A channel in TDD is reciprocal because the same frequency is used for up- and downlink. Consequently, since fast variation of signal strength is frequency dependent, TDD has the same fading for up- and downlink. Therefore, based on the uplink signal, the TDD receiver can estimate the fast fading, which then can be utilised in power control and adaptive antenna on the downlink.
− Cell size is limited by round trip delay and guard time. In TDD, a burst transmission can only be done after a complete reception. This results in round trip delay and guard times between burst. As a consequence, the cell size is limited by the round trip delay and guard time.
− Interference between uplink and downlink. Since uplink and downlink share the same frequency band, a timeslot can be used for the downlink by one (CDMA) user in cell A and for the uplink by another (in cell B). If these users are close together, those two transmission directions can interfere with each other. This interference can not be prevented by power control.
5.4 Radio interface protocol architecture
In every cellular systems certain functions are needed to set up, reconfigure (maintain) and release radio connections. These functions are provided by the Radio Interface Protocols (refer also to subsection 3.4.1).
In the Radio Interface Protocol architecture of UTRAN there are 3 groups of channels : logical channels, transport channels and physical channels. Subsection 5.4.1 deals with logical channels. Transport channels, described in subsection 5.4.2, are considered the lowest level of detail to be discussed in this document.
Figure 5-5 shows the radio interface protocol architecture for UMTS. There, the radio interface is layered into three protocol layers : the physical layer (L1), the data link layer (L2), with the sub layers
Media Access Control (MAC, and Radio Link Control (RLC),
network layer (L3).
The physical layer (L1) offers services to higher layers (data link layer). The access to these services is through the use of transport channels via the MAC sub-layer. The MAC sub-layer, in turn, offers services to the RLC sub-layer via the logical channels. The RLC sub-layer then offers services to the next higher layer by means of service access points (SAPs).
5.4.1 Logical Channels
The logical channels are characterised by what type of data is transferred. The logical channels can be classified into two groups : Control Channels for transferring control plane information. Traffic Channels for carrying user plane information.
94/100
Figure 5-62: Radio Interface Protocol architecture for UMTS
The Control Channels are : Broadcast Control Channel (BCCH) is a downlink channel for broadcasting system
control information, such as cell identities, spreading codes, access channel, and neighbouring cell lists. (See subsection on MM system information in 3.4.1.)
Paging Control Channel (PCCH) is a downlink control channel used for transferring paging information (refer to paging in subsection 4.2.2).
Dedicated Control Channel (DCCH) is a point-to-point bi-directional channel for exchanging signalling information such as handover measurements, service adaptation information, and power control information. If this channel is established, the MS is in RRC-CONNECTED state (refer to subsection 3.3.1).
Common Control Channel (CCCH) is a point-to-multi-point bi-directional channel for transmitting signalling information necessary for access management functions broadcast information, such as access request and access grant.
The Traffic Channels are : Dedicated Traffic Channel (DTCH) is a point-to-point bi-directional channel. A DTCH
is dedicated to one mobile. Common Traffic Channel (CTCH) is a point-to-multipoint downlink channel. A CTCH
is dedicated to all or a group of specified mobiles.
95/100
5.4.2 Transport Channels (FDD)
Transport channels are characterised by how and with what characteristics data is transferred. There are two types of transport channels : Dedicated Transport Channels are transport channels identified by a certain code on
a certain frequency. A dedicated channel is reserved for a single user only. These channels support soft handover.
A Common Transport Channel is a resource divided between all or a group of users in a cell. These channels do not have soft handover but some of them support fast power control.
There is only one type of channel in the Dedicated Transport Channel, namely dedicated channel (DCH). The DCH carries both user data, such as speech frames, and higher layer control information, such as handover commands or measurement report from the terminal. Both user information and control information carried on the DCH are not visible to the physical layer. The characteristics of DCH are determined by features such as fast power control, the possibility of fast data rate change (every 10ms) and the possibility of transmission to a certain part of the cell using beam-forming antennas.
The Common Transport Channels are : Broadcast Channel (BCH) is a downlink transport channel for broadcasting system
control information. such as the available random access codes and access slots in the cell. Since a terminal cannot log into the network without the possibility of decoding the broadcast channel, this channel is necessary to reach all users within the coverage and to allow them to decode the broadcast message, resulting in a relatively high power transmission as well as a low and fixed data rate of the broadcast channel.
Forward Access Channel (FACH) is downlink only and is transmitted over the entire cell or partly using beam-forming antennas. The FACH carries control information to terminals known to locate in the given cell. The information is sent after, for example, the base station has received a random access message. The FACH can also transmit packet data. The FACH uses slow power control.
Paging Channel (PCH) is a downlink transport channel that transfers paging information. Therefore, It is always transmitted over the entire cell to all users. The design of the paging channel affects the terminal’s power consumption in the standby mode. The less often the terminal receives a paging message, the longer the terminal can stay in the standby mode.
Random Access Channel (RACH) is an uplink transport channel. Since it is received from the entire desired cell coverage area, its practical data rates have to be rather low, at least for the initial system access. It is used to transmit control information such as requests to set up a connection from the terminal. It can also be used to send small amounts of packet data from the terminal to the network.
Common Packet Channel (CPCH) is an extension to the RACH channel that is used for transmission of bursty data traffic in the uplink direction. Its pair for transmitting data in the downlink is the FACH.
Downlink Shared Channel (DSCH) is a downlink transport channel for transfer dedicated user data and/or control information. It can be shared by several users. It supports fast power control and the variable bit rate. The DSCH can employ the different modes of transmit antenna diversity methods. It is always associated with a DCH.
The use of RACH, FACH and PCH is mandatory for a basic network operation, while the use of DSCH and CPCH is optional.
Logical channels are mapped onto the appropriate transport channels in the MAC layer. The mapping is shown in . The vertical lines show the relation between the logical channels and transport channels.
96/100
RACH PCHCPCH BCHDCH FACH DCHDSCHTransportChannels
CCCH PCCH BCCHDCCHDTCH CCCH
DCCHDTCHCTCH
LogicalChannels
Uplink Downlink
Figure 5-63: Logical channels to transport-channel mapping
97/100
6 References
In this chapter some references are provided, mainly to KPN Research reports with additional information on some of the topics addressed in this UMTS Bible – core network. Furthermore, a subsection is provided on the way to obtain the documents referenced as TS xx.yyy under the References headings in this UMTS Bible – core network.
Thee are many good books on UMTS radio. One of them is
WCDMA for UMTS, Radio Access For Third Generation Mobile Communications,Harri Holma, Antti Toskala (editors), 2000, John Wiley & Sons Ltd, ISBN 0 471 72051 8
6.1 KPN Research reports
The following reports can be obtained through the secretariat of KPN Research or via the authors.
All IP UMTS core network architecture based on 3GPP Release 2000 standard.This document aims to give KPN Mobile an understanding about the concept of the All-IP network architecture, part of the UMTS Release 2000 standard. It introduces the possibility to handle all traffic, whether voice or data (multimedia), over a new IP network, the IP Multimedia (IM) subsystem. This document also presents the important developments in the IP world for the future mobile networks (beyond Release 2000). Report 32595
Virtual Home EnvironmentIn this report the concept of Virtual Home Environment (VHE) is defined and explained and it is shown how it can satisfy the user’s desire to feel “at home” irrespective of the terminal or the network he is using. Also several technological developments (Camel, SAT, MexE) are described and it is indicated how this fit in the VHE. This report shows the importance of the VHE concept and the technical developments for mobile operators.Report 31707
Offering services with IP-based mobile networksA prominent characteristic of the evolution from 2nd to 3rd generation mobile networks is the change of the base technology from traditional circuit-switched to Internet Protocol (IP). This report aims to provide Operations and BU MT/BD with information regarding the consequences of this change, to assist them in developing a vision on the network architecture for the medium to long term. Report 31834
Inter-system Traffic Management - Inter-working of GSM/GPRS and UMTSIn the near future, KPN will introduce UMTS. The UMTS network will co-exist with the current GSM/GPRS network for many years. A number of services can run on either network (e.g. voice, e-mail). Hence, one has to decide on which network a certain service is carried, given network load and service characteristics. Preferably the decision is based on maximising the gain for KPN-Mobile. Implementing good traffic management algorithms potentially leads to better network quality and increased (or rather better used)
98/100
network capacity. In this report a framework is developed that can be used to design traffic management rules for resource management of co-existing GSM/GPRS and UMTS networks. Inter-system traffic management will prove to be a crucial issue when UMTS and GSM/GPRS networks exist in parallel. It is therefore recommended that this issue will be studied in more detail in the near future.Report 32574
UMTS network capacity and performance: a sensitivity analysis.The influence of six parameters on the UMTS network capacity and performance has been investigated. It was found that the parameters for terminal mobility, traffic load heterogeneity (hot spots), call burstiness, service mix, and Eb/N0 target values, all have a significant impact on system performance and should therefore be taken into account when planning a UMTS network. Only the path loss exponent showed a rather small impact on the performance. Report 32557
Planning and QoS issues for the UMTS fixed networkIn this report the challenges of planning and providing QoS for the fixed UMTS networks parts (UTRAN and core) are addressed. The most relevant planning and QoS issues are identified and illustrated and these issues are assessed regarding future solution alternatives. This inventory and assessment of planning and QoS issues provides input for KPN Mobile, regarding strategic decisions about the design of the UTRAN and UMTS core network. Report 32488/32413
6.2 Specifications Manual
"3GPP" is the "Third Generation Partnership Project". 3GPP is a co-operation between several standardisation organisations. The main purpose of 3GPP is to create the UMTS specifications. 3GPP has a website (http://www.3gpp.org/) where information on 3GPP can be found and UMTS specifications can be downloaded.
Specifications
In the "Document Area" you can find and download all UMTS specifications. Information on how the specifications are structured and on working procedures can be found by clicking on "3G specifications". This is a very informative page.
The following table displays the structuring of UMTS specifications into series:
GSMpre-Release 4
GSM Release 4 onwards
UMTS Release 1999 onwards
Requirements 01. 41. 21.Service aspects 02. 42. 22.Technical realization 03. 43. 23.Signalling protocols (user equipment to network) 04. 44. 24.Radio aspects 05. 45. 25.CODECs 06. 46. 26.Data 07. 47. 27.Signalling protocols (RSS-CN) 08. 48. 28.Signalling protocols (intra-fixed-network) 09. 49. 29.Programme management 10. 50. 30.User Identity Module (SIM / USIM) 11. 51. 31.O&M 12. 52. 32.Access requirements and test specifications 13.Security aspects 33.Test specifications 34.Security algorithms 35.
99/100
One easy and direct way to enter the specifications ftp site is to click on ftp://www.3gpp.org/ftp/ in the Document Area and click on Specs. Once every quarter the latest version of the specifications is put on the server. If a certain specification cannot be found in for example the directory 2001-3, there might not have been an update of this specification between 2000-12 and 2001-3. The last version can then be found in 2000-12, or maybe even in earlier versions.
The version numbering of the specs is x.y.z, x denotes the release, either Release99 (x=3), Release4 (x=4) or Release 5 (x=5).
Release 99 and Release 4 are frozen. This means that only "essential corrections" and "editorial corrections" can be put in.
y is updated in case of "essential corrections" z is updated in case of "editorial corrections"
Release99 is the first working UMTS release. In Release 4 and 5 more functionality will be added, refer to http://www.3gpp.org/3G_Specs/release-content.htm.
E-mail exploders
Each standardisation group has its own E-mail exploder. On the 3GPP website one can subscribe to one of these E-mail exploders. The exploders are used for submitting documents to meetings, but also to have lively discussions. One can also send questions regarding the specifications, and with a bit of luck get an answer from a real expert.
Downloading documents, or submitting to an E-mail exploder is free of charge.
100/100