ETSI EN 301 344 V7.4ETSI EN 301 344 V7.4.1 (2000-09) European Standard (Telecommunications series) Digital cellular telecommunications system (Phase 2+); General Packet Radio Service

ETSI EN 301 344 V7.4.1 (2000-09)European Standard (Telecommunications series)

Digital cellular telecommunications system (Phase 2+);General Packet Radio Service (GPRS);

Service description;Stage 2

(GSM 03.60 version 7.4.1 Release 1998)

GLOBAL SYSTEM FORMOBILE COMMUNICATIONS

R

ETSI

ETSI EN 301 344 V7.4.1 (2000-09)2(GSM 03.60 version 7.4.1 Release 1998)

ReferenceREN/TSGS-020360Q7R2

KeywordsDigital cellular telecommunications system,Global System for Mobile communications

(GSM), GPRS

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing orperceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drivewithin ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status.Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/

If you find errors in the present document, send your comment to:[email protected]

Copyright Notification

No part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2000.All rights reserved.

http://www.etsi.org/

http://www.etsi.org/tb/status

[email protected]

ETSI


Contents

Intellectual Property Rights ................................................................................................................................8

Foreword.............................................................................................................................................................8

1 Scope ........................................................................................................................................................9

2 References ................................................................................................................................................9

3 Definitions, abbreviations and symbols .................................................................................................113.1 Definitions........................................................................................................................................................113.2 Abbreviations ...................................................................................................................................................113.3 Symbols............................................................................................................................................................13

4 Main Concepts........................................................................................................................................13

5 General GPRS Architecture and Transmission Mechanism...................................................................145.1 GPRS Access Interfaces and Reference Points ................................................................................................145.2 Network Interworking ......................................................................................................................................155.2.1 PSPDN Interworking ..................................................................................................................................155.2.2 Internet (IP) Interworking...........................................................................................................................155.3 High-Level Functions Required for GPRS.......................................................................................................155.3.1 Network Access Control Functions ............................................................................................................155.3.1.1 Registration Function ............................................................................................................................165.3.1.2 Authentication and Authorisation Function ..........................................................................................165.3.1.3 Admission Control Function .................................................................................................................165.3.1.4 Message Screening Function.................................................................................................................165.3.1.5 Packet Terminal Adaptation Function...................................................................................................165.3.1.6 Charging Data Collection Function.......................................................................................................165.3.2 Packet Routeing and Transfer Functions ....................................................................................................165.3.2.1 Relay Function ......................................................................................................................................165.3.2.2 Routeing Function.................................................................................................................................175.3.2.3 Address Translation and Mapping Function .........................................................................................175.3.2.4 Encapsulation Function.........................................................................................................................175.3.2.5 Tunnelling Function ..............................................................................................................................175.3.2.6 Compression Function ..........................................................................................................................175.3.2.7 Ciphering Function................................................................................................................................175.3.2.8 Domain Name Server Function.............................................................................................................175.3.3 Mobility Management Functions ................................................................................................................175.3.4 Logical Link Management Functions .........................................................................................................175.3.4.1 Logical Link Establishment Function ...................................................................................................185.3.4.2 Logical Link Maintenance Functions....................................................................................................185.3.4.3 Logical Link Release Function .............................................................................................................185.3.5 Radio Resource Management Functions.....................................................................................................185.3.5.1 Um Management Function....................................................................................................................185.3.5.2 Cell Selection Function .........................................................................................................................185.3.5.3 Um-tranx Function ................................................................................................................................185.3.5.4 Path Management Function...................................................................................................................185.3.6 Network Management Functions ................................................................................................................185.4 Logical Architecture.........................................................................................................................................195.4.1 GPRS Support Nodes..................................................................................................................................195.4.2 GPRS Backbone Networks .........................................................................................................................205.4.3 HLR ............................................................................................................................................................205.4.4 SMS-GMSC and SMS-IWMSC .................................................................................................................205.4.5 GPRS Mobile Stations ................................................................................................................................215.4.6 Charging Gateway Functionality ................................................................................................................215.5 Assignment of Functions to General Logical Architecture ..............................................................................215.6 Transmission and Signalling Planes .................................................................................................................225.6.1 Transmission Plane .....................................................................................................................................225.6.2 Signalling Plane ..........................................................................................................................................23

ETSI


5.6.2.1 MS - SGSN ...........................................................................................................................................235.6.2.2 SGSN - HLR .........................................................................................................................................235.6.2.3 SGSN - MSC/VLR................................................................................................................................245.6.2.4 SGSN - EIR...........................................................................................................................................245.6.2.5 SGSN - SMS-GMSC or SMS-IWMSC.................................................................................................245.6.2.6 GSN - GSN ...........................................................................................................................................255.6.2.7 GGSN - HLR ........................................................................................................................................255.6.2.7.1 MAP-based GGSN - HLR Signalling..............................................................................................255.6.2.7.2 GTP and MAP-based GGSN - HLR Signalling ..............................................................................26

6 Mobility Management Functionality......................................................................................................266.1 Definition of Mobility Management States ......................................................................................................266.1.1 IDLE (GPRS) State.....................................................................................................................................266.1.2 STANDBY State ........................................................................................................................................266.1.3 READY State..............................................................................................................................................276.2 IDLE / STANDBY / READY State Functionality ...........................................................................................286.2.1 State Transitions and Functions ..................................................................................................................286.2.2 READY Timer Function.............................................................................................................................306.2.3 Periodic RA Update Timer Function ..........................................................................................................306.2.4 Mobile Reachable Timer Function .............................................................................................................306.3 Interactions Between SGSN and MSC/VLR....................................................................................................316.3.1 Administration of the SGSN - MSC/VLR Association ..............................................................................316.3.2 Combined RA / LA Updating .....................................................................................................................326.3.3 CS Paging ...................................................................................................................................................326.3.3.1 Paging Co-ordination ............................................................................................................................336.3.4 Non-GPRS Alert .........................................................................................................................................346.3.5 MS Information Procedure .........................................................................................................................346.3.6 MM Information Procedure ........................................................................................................................356.4 MM Procedures ................................................................................................................................................356.5 Attach Function ................................................................................................................................................366.6 Detach Function ...............................................................................................................................................396.6.1 MS-Initiated Detach Procedure...................................................................................................................406.6.2 Network-Initiated Detach Procedure ..........................................................................................................406.6.2.1 SGSN-Initiated Detach Procedure ........................................................................................................406.6.2.2 HLR-Initiated Detach Procedure...........................................................................................................416.7 Purge Function .................................................................................................................................................416.8 Security Function .............................................................................................................................................426.8.1 Authentication of Subscriber ......................................................................................................................426.8.2 User Identity Confidentiality ......................................................................................................................436.8.2.1 P-TMSI Signature .................................................................................................................................436.8.2.2 P-TMSI Reallocation Procedure ...........................................................................................................436.8.3 User Data and GMM/SM Signalling Confidentiality .................................................................................436.8.3.1 Scope of Ciphering................................................................................................................................436.8.3.2 GPRS Ciphering Algorithm ..................................................................................................................446.8.4 Identity Check Procedures ..........................................................................................................................446.9 Location Management Function.......................................................................................................................446.9.1 Location Management Procedures..............................................................................................................456.9.1.1 Cell Update Procedure ..........................................................................................................................456.9.1.2 Routeing Area Update Procedure..........................................................................................................456.9.1.2.1 Intra SGSN Routeing Area Update..................................................................................................466.9.1.2.2 Inter SGSN Routeing Area Update..................................................................................................476.9.1.3 Combined RA / LA Update Procedure..................................................................................................496.9.1.3.1 Combined Intra SGSN RA / LA Update .........................................................................................496.9.1.3.2 Combined Inter SGSN RA / LA Update .........................................................................................516.9.1.4 Periodic RA and LA Updates................................................................................................................546.10 Subscriber Management Function....................................................................................................................546.10.1 Subscriber Management Procedures...........................................................................................................546.10.1.1 Insert Subscriber Data Procedure ..........................................................................................................546.10.1.2 Delete Subscriber Data Procedure.........................................................................................................556.11 Classmark Handling .........................................................................................................................................556.11.1 Radio Access Classmark.............................................................................................................................556.11.2 SGSN Classmark ........................................................................................................................................56

ETSI


7 Network Management Functionality......................................................................................................56

8 Radio Resource Functionality ................................................................................................................568.1 Cell Selection and Reselection .........................................................................................................................568.2 Discontinuous Reception..................................................................................................................................568.3 Radio Resource Management...........................................................................................................................568.3.1 Layer Functions ..........................................................................................................................................578.3.2 Model of Operation.....................................................................................................................................578.3.2.1 Dynamic Allocation of Radio Resources ..............................................................................................578.4 Paging for GPRS Downlink Transfer...............................................................................................................57

9 Packet Routeing and Transfer Functionality ..........................................................................................589.1 Definition of Packet Data Protocol States ........................................................................................................589.1.1 INACTIVE State ........................................................................................................................................589.1.2 ACTIVE State.............................................................................................................................................589.2 PDP Context Activation, Modification, and Deactivation Functions...............................................................599.2.1 Static and Dynamic PDP Addresses ...........................................................................................................599.2.2 Activation Procedures.................................................................................................................................609.2.2.1 PDP Context Activation Procedure.......................................................................................................609.2.2.2 Network-Requested PDP Context Activation Procedure ......................................................................619.2.2.2.1 Successful Network-Requested PDP Context Activation Procedure...............................................629.2.2.2.2 Unsuccessful Network-Requested PDP Context Activation Procedure ..........................................639.2.2.3 Anonymous Access PDP Context Activation Procedure ......................................................................649.2.3 Modification Procedures.............................................................................................................................659.2.3.1 PDP Context Modification Procedure...................................................................................................669.2.4 Deactivation Procedures .............................................................................................................................669.2.4.1 PDP Context Deactivation Initiated by MS Procedure .........................................................................669.2.4.2 PDP Context Deactivation Initiated by SGSN Procedure .....................................................................679.2.4.3 PDP Context Deactivation Initiated by GGSN Procedure ....................................................................679.2.4.4 Anonymous Access PDP Context Deactivation Initiated by MS Procedure.........................................689.2.4.5 Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure....................................689.3 Packet Routeing and Transfer Function ...........................................................................................................699.4 Relay Function .................................................................................................................................................699.5 Packet Terminal Adaptation Function..............................................................................................................699.6 Encapsulation Function ....................................................................................................................................709.6.1 Encapsulation Between SGSN and GGSN .................................................................................................709.6.2 Encapsulation Between SGSN and MS ......................................................................................................70

10 Message Screening Functionality...........................................................................................................70

11 Compatibility Issues ...............................................................................................................................70

12 Transmission ..........................................................................................................................................7112.1 Transmission Modes.........................................................................................................................................7112.1.1 GTP Transmission Modes ..........................................................................................................................7112.1.2 LLC Transmission Modes ..........................................................................................................................7112.1.3 RLC Transmission Modes ..........................................................................................................................7112.2 Logical Link Control Functionality..................................................................................................................7112.2.1 Addressing ..................................................................................................................................................7112.2.2 Services.......................................................................................................................................................7112.2.3 Functions ....................................................................................................................................................7212.3 Subnetwork Dependent Convergence Functionality ........................................................................................7212.3.1 Services.......................................................................................................................................................7312.3.2 Subfunctions ...............................................................................................................................................7312.4 Octet Stream Protocol Functionality ................................................................................................................7412.4.1 PAD Function .............................................................................................................................................7512.4.1.1 Packet Assembler ..................................................................................................................................7512.4.1.1.1 Buffer Full .......................................................................................................................................7512.4.1.1.2 Inactivity Timer Expiry ...................................................................................................................7512.4.1.1.3 Maximum Buffer Delay Timer Expiry ............................................................................................7512.4.1.1.4 Special Character.............................................................................................................................7512.4.1.1.5 Change in Flow Control State .........................................................................................................7512.4.1.1.6 Immediate Forwarding Request.......................................................................................................76

ETSI


12.4.1.2 Packet Disassembler..............................................................................................................................7612.4.2 Quality of Service .......................................................................................................................................7612.5 Point-to-Point Protocol Functionality...............................................................................................................7612.5.1 Transmission Plane for PDP Type PPP ......................................................................................................7612.5.2 Functions ....................................................................................................................................................7612.6 Gb Interface......................................................................................................................................................7712.6.1 Physical Layer Protocol ..............................................................................................................................7712.6.2 Link Layer Protocols ..................................................................................................................................7712.6.3 BSS GPRS Protocol....................................................................................................................................7712.6.3.1 Inter-dependency of the BSSGP and LLC Functions............................................................................7812.6.3.2 BSSGP Addressing ...............................................................................................................................7812.6.3.3 BVCI Contexts in BSS and in SGSN....................................................................................................7812.6.3.4 Flow Control Between SGSN and BSS over the Gb Interface..............................................................7912.7 Abis Interface ...................................................................................................................................................7912.7.1 Remote Packet Control Unit .......................................................................................................................80

13 Information Storage................................................................................................................................8013.1 HLR..................................................................................................................................................................8113.2 SGSN................................................................................................................................................................8213.3 GGSN...............................................................................................................................................................8313.4 MS....................................................................................................................................................................8413.5 MSC/VLR ........................................................................................................................................................8513.6 Recovery and Restoration Procedures..............................................................................................................8513.6.1 HLR Failure ................................................................................................................................................8613.6.2 SGSN Failure..............................................................................................................................................8613.6.3 GGSN Failure .............................................................................................................................................8613.6.4 VLR Failure ................................................................................................................................................86

14 Identities .................................................................................................................................................8714.1 IMSI .................................................................................................................................................................8714.2 Packet TMSI.....................................................................................................................................................8714.3 NSAPI and TLLI ..............................................................................................................................................8714.4 PDP Address ....................................................................................................................................................8814.5 TID ...................................................................................................................................................................8814.6 Routeing Area Identity .....................................................................................................................................8814.7 Cell Identity......................................................................................................................................................8914.8 GSN Addresses ................................................................................................................................................8914.8.1 GSN Address ..............................................................................................................................................8914.8.2 GSN Number ..............................................................................................................................................8914.9 Access Point Name...........................................................................................................................................89

15 Operational Aspects ...............................................................................................................................9015.1 Charging ...........................................................................................................................................................9015.1.1 Charging Information .................................................................................................................................9015.1.2 Reverse Charging........................................................................................................................................9015.2 Quality of Service Profile.................................................................................................................................9015.2.1 Precedence Class ........................................................................................................................................9115.2.2 Delay Class .................................................................................................................................................9115.2.3 Reliability Class..........................................................................................................................................9115.2.4 Throughput Classes.....................................................................................................................................9215.2.4.1 Peak Throughput Class .........................................................................................................................9215.2.4.2 Mean Throughput Class ........................................................................................................................93

16 Interactions with Other GSM Services...................................................................................................9316.1 Point-to-point Short Message Service ..............................................................................................................9316.1.1 Mobile-terminated SMS Transfer ...............................................................................................................9416.1.1.1 Unsuccessful Mobile-terminated SMS Transfer ...................................................................................9416.1.2 Mobile-originated SMS Transfer ................................................................................................................9616.2 Circuit-switched Services.................................................................................................................................9616.2.1 Suspension of GPRS Services ....................................................................................................................9616.2.2 GPRS and Dedicated Mode Priority Handling ...........................................................................................9716.3 Supplementary Services ...................................................................................................................................98

ETSI


Annex A (normative): APN and GGSN Selection .............................................................................99

A.1 Definitions..............................................................................................................................................99

A.2 APN Selection Rules ..............................................................................................................................99

Annex B (normative): Internet-Hosted Octet Stream Service .......................................................106

B.1 Direction of Connection Setup .............................................................................................................106

B.2 Bearer ...................................................................................................................................................106

B.3 Setup Data ............................................................................................................................................106B.3.1 Protocol Type – TCP or UDP.........................................................................................................................106B.3.2 Host Name......................................................................................................................................................107B.3.3 Port Number ...................................................................................................................................................107B.3.4 PAD Parameters .............................................................................................................................................107

B.4 Flow Control ........................................................................................................................................107

B.5 Break Signal .........................................................................................................................................107

B.6 Connection Establishment Procedure...................................................................................................107B.6.1 Fully User-Specified Establishment ...............................................................................................................108B.6.2 Default Internet Endpoint Parameters Establishment.....................................................................................108

B.7 Connection Termination.......................................................................................................................108B.7.1 MS-initiated TCP IHOSS Connection Termination .......................................................................................108B.7.2 MS-initiated UDP IHOSS Connection Termination ......................................................................................108B.7.3 Internet Host Initiated TCP IHOSS Connection Termination ........................................................................109

B.8 Quality of Service.................................................................................................................................109

B.9 Security.................................................................................................................................................109B.9.1 Authentication of the GPRS User...................................................................................................................109B.9.2 Malicious Reconfiguration of the GPRS Device............................................................................................109

B.10 Maintenance .........................................................................................................................................109

Annex C (informative): Data Transmission Routeing Examples .....................................................110

C.1 Data Routeing for an MS in its Home PLMN to and from an External PDN ......................................110

C.2 Data Routeing for a Roaming MS to and from an External PDN ........................................................111

C.3 MS-to-MS Data Routeing via the Same GGSN...................................................................................111

C.4 MS-to-MS Data Routeing via Different GGSNs..................................................................................112

Annex D (informative): Figures ..........................................................................................................113

Annex E (informative): Tables ............................................................................................................115

Annex F (informative): Document history.........................................................................................116

History ............................................................................................................................................................117

ETSI


Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI inrespect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Webserver (http://www.etsi.org/ipr).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Webserver) which are, or may be, or may become, essential to the present document.

ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical Committee Special MobileGroup (SMG).

The present document defines the stage-2 service description for a General Packet Radio Service (GPRS) within thedigital cellular telecommunications system (Phase 2+).

The contents of the present document are subject to continuing work within SMG and may change following formalSMG approval. Should SMG modify the contents of the present document it will then be re-submitted for OAP with anidentifying change of release date and an increase in version number as follows:

Version 7.x.y

where:

7 indicates GSM Release 1998 of Phase 2+

x the second digit is incremented for changes of substance, i.e. technical enhancements, corrections, updates,etc.

y the third digit is incremented when editorial only changes have been incorporated in the specification.

National transposition dates

Date of adoption of this EN: 18 August 2000

Date of latest announcement of this EN (doa): 30 November 2000

Date of latest publication of new National Standardor endorsement of this EN (dop/e): 31 May 2001

Date of withdrawal of any conflicting National Standard (dow): 31 May 2001

http://www.etsi.org/ipr

ETSI


1 ScopeThe present document defines the stage-2 service description for a General Packet Radio Service (GPRS) on GSM.CCITT I.130 [29] describes a three-stage method for characterisation of telecommunication services, and CCITTQ.65 [31] defines stage 2 of the method.

This version of the stage-2 service description covers the first phase of GPRS, and does not meet all the services andfunctionality described in GSM 02.60 [3].

The present document does not cover the lower layers of the GPRS GSM radio interface. GSM 03.64 [9] contains anoverall description of the radio interface.

2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.

• References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies.

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y).

[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations andacronyms".

[2] GSM 01.61: "Digital cellular telecommunications system (Phase 2+); GPRS ciphering algorithmrequirements".

[3] GSM 02.60: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Service description; Stage 1".

[4] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing andidentification".

[5] GSM 03.07: "Digital cellular telecommunications system (Phase 2+); Restoration procedures".

[6] GSM 03.20: "Digital cellular telecommunications system (Phase 2+); Security related networkfunctions".

[7] GSM 03.22: "Digital cellular telecommunications system (Phase 2+); Functions related to MobileStation (MS) in idle mode and group receive mode".

[8] GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of theShort Message Service (SMS); Point-to-Point (PP)".

[9] GSM 03.64: "Digital cellular telecommunications system (Phase 2+); Overall description of theGeneral Packet Radio Service (GPRS) Radio interface; Stage 2".

[10] GSM 04.07: "Digital cellular telecommunications system (Phase 2+); Mobile radio interfacesignalling layer 3; General aspects".

[11] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interfacelayer 3 specification".

ETSI


[12] GSM 04.60: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control /Medium Access Control (RLC/MAC) protocol".

[13] GSM 04.64: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Mobile Station – Serving GPRS Support Node (MS - SGSN) Logical LinkControl (LLC) layer specification".

[14] GSM 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Mobile Station (MS) – Serving GPRS Support Node (SGSN); SubnetworkDependent Convergence Protocol (SNDCP)".

[15] GSM 05.08: "Digital cellular telecommunications system (Phase 2+); Radio subsystem linkcontrol".

[16] GSM 07.60: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Mobile Station (MS) supporting GPRS".

[17] GSM 08.08: "Digital cellular telecommunications system (Phase 2+); Mobile Switching Centre -Base Station System (MSC - BSS) interface: Layer 3 specification".

[18] GSM 08.14: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Gbinterface layer 1".

[19] GSM 08.16: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface;Network Service".

[20] GSM 08.18: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRSProtocol (BSSGP)".

[21] GSM 08.60: "Digital cellular telecommunications system (Phase 2+); Inband control of remotetranscoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels".

[22] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part(MAP) specification".

[23] GSM 09.16: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gsinterface network service specification".

[24] GSM 09.18: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gsinterface layer 3 specification".

[25] GSM 09.60: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface".

[26] GSM 09.61: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Interworking between the Public Land Mobile Network (PLMN) supportingGPRS and Packet Data Networks (PDN)".

[27] GSM 11.11: "Digital cellular telecommunications system (Phase 2+); Specification of theSubscriber Identity Module - Mobile Equipment (SIM - ME) interface".

[28] GSM 12.15: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); GPRS Charging".

[29] CCITT Recommendations I.130: "General modelling methods – Method for the characterisation oftelecommunication services supported by an ISDN and network capabilities of an ISDN".

[30] CCITT Recommendation E.164: "Numbering plan for the ISDN era".

ETSI


[31] CCITT Recommendation Q.65: "Methodology – Stage 2 of the method for the characterization ofservices supported by an ISDN".

[32] CCITT Recommendation V.42 bis: "Data communication over the telephone network – Datacompression procedures for data circuit-terminating equipment (DCE) using error correctionprocedures".

[33] CCITT Recommendation X.3: "Packet assembly disassembly facility (PAD) in a public datanetwork".

[34] CCITT Recommendation X.25: "Interface between data terminal equipment (DTE) and datacircuit-terminating equipment (DCE) for terminals operating in the packet mode and connected topublic data networks by dedicated circuit".

[35] CCITT Recommendation X.28: "DTE / DCE interface for a start-stop mode data terminalequipment accessing the packet assembly / disassembly facility (PAD) in a public data networksituated in the same country".

[36] CCITT Recommendation X.29: "Procedures for the exchange of control information and user databetween a packet assembly / disassembly (PAD) facility and a packet mode DTE or another PAD".

[37] CCITT Recommendation X.75: "Packet-switched signalling system between public networksproviding data transmission services".

[38] CCITT Recommendation X.121: "International Numbering Plan for Public Data Networks".

[39] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6).

[40] IETF RFC 791 (1981): "Internet Protocol" (STD 5).

[41] IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5).

[42] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7).

[43] IETF RFC 1034 (1987): "Domain Names – Concepts and Facilities" (STD 7).

[44] IETF RFC 1661 (1994): "The Point-to-Point Protocol (PPP)" (STD 51).

[45] Bellcore GR-000301 Issue 2 December 1997: "Public Packet Switched Network GenericRequirements (PPSNGR)".

3 Definitions, abbreviations and symbols

3.1 DefinitionsFor the purposes of the present document, the terms and definitions given in GSM 02.60 apply.

3.2 AbbreviationsFor the purposes of the present document the following abbreviations apply. Additional applicable abbreviations can befound in GSM 01.04 [1].

AA Anonymous AccessAPN Access Point NameATM Asynchronous Transfer ModeBG Border GatewayBSSAP+ Base Station System Application Part +BSSGP Base Station System GPRS ProtocolBVCI BSSGP Virtual Connection IdentifierCCU Channel Codec UnitCDR Call Detail Record

ETSI


CGF Charging Gateway FunctionalityCGI Cell Global IdentificationCS Circuit SwitchedDNS Domain Name SystemGGSN Gateway GPRS Support NodeGMM/SM GPRS Mobility Management and Session ManagementGSN GPRS Support NodeGTP GPRS Tunnelling ProtocolICMP Internet Control Message ProtocolIETF Internet Engineering Task ForceIHOSS Internet-Hosted Octet Stream ServiceIP Internet ProtocolIPv4 Internet Protocol version 4IPv6 Internet Protocol version 6IPX Internet Packet eXchangeISP Internet Service ProviderL2TP Layer-2 Tunnelling ProtocolLL-PDU LLC PDULLC Logical Link ControlMAC Medium Access ControlMNRF Mobile station Not Reachable FlagMNRG Mobile station Not Reachable for GPRS flagMNRR Mobile station Not Reachable ReasonMTP2 Message Transfer Part layer 2MTP3 Message Transfer Part layer 3NGAF Non-GPRS Alert FlagNS Network ServiceNSAPI Network layer Service Access Point IdentifierNSS Network SubSystemOSP Octet Stream ProtocolP-TMSI Packet TMSIPCU Packet Control UnitPDCH Packet Data CHannelPDN Packet Data NetworkPDP Packet Data Protocol, e.g., IP or X.25 [34]PDU Protocol Data UnitPPF Paging Proceed FlagPPP Point-to-Point ProtocolPVC Permanent Virtual CircuitRA Routeing AreaRAC Routeing Area CodeRAI Routeing Area IdentityRLC Radio Link ControlSGSN Serving GPRS Support NodeSM Short MessageSM-SC Short Message service Service CentreSMS-GMSC Short Message Service Gateway MSCSMS-IWMSC Short Message Service Interworking MSCSN-PDU SNDCP PDUSNDC SubNetwork Dependent ConvergenceSNDCP SubNetwork Dependent Convergence ProtocolTCAP Transaction Capabilities Application PartTCP Transmission Control ProtocolTID Tunnel IdentifierTLLI Temporary Logical Link IdentityTRAU Transcoder and Rate Adaptor UnitUDP User Datagram Protocol

ETSI


3.3 SymbolsFor the purposes of the present document, the following symbols apply:

Ga Charging data collection interface between a CDR transmitting unit (e.g., an SGSN or a GGSN)and a CDR receiving functionality (a CGF).

Gb Interface between an SGSN and a BSS.Gc Interface between a GGSN and an HLR.Gd Interface between a SMS-GMSC and an SGSN, and between a SMS-IWMSC and an SGSN.Gf Interface between an SGSN and an EIR.Gi Reference point between GPRS and an external packet data network.Gn Interface between two GSNs within the same PLMN.Gp Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS

network services across areas served by the co-operating GPRS PLMNs.Gr Interface between an SGSN and an HLR.Gs Interface between an SGSN and an MSC/VLR.kbit/s Kilobits per second.R Reference point between a non-ISDN compatible TE and MT. Typically this reference point

supports a standard serial interface.Um Interface between the mobile station (MS) and the GPRS fixed network part. The Um interface is

the GPRS network interface for providing packet data services over the radio to the MS. The MTpart of the MS is used to access the GPRS services through this interface.

4 Main ConceptsGPRS uses a packet-mode technique to transfer high-speed and low-speed data and signalling in an efficient manner.GPRS optimises the use of network and radio resources. Strict separation between the radio subsystem and networksubsystem is maintained, allowing the network subsystem to be reused with other radio access technologies. GPRS doesnot mandate changes to an installed MSC base.

New GPRS radio channels are defined, and the allocation of these channels is flexible: from 1 to 8 radio interfacetimeslots can be allocated per TDMA frame, timeslots are shared by the active users, and up and downlink are allocatedseparately. The radio interface resources can be shared dynamically between speech and data services as a function ofservice load and operator preference. Various radio channel coding schemes are specified to allow bitrates from 9 tomore than 150 kbit/s per user.

Applications based on standard data protocols are supported, and interworking is defined with IP networks and X.25networks. GPRS allows SMS transfer over GPRS radio channels.

GPRS is designed to support from intermittent and bursty data transfers through to occasional transmission of largevolumes of data. Several quality of service profiles are supported. GPRS is designed for fast reservation to begintransmission of packets, typically 0,5 to 1 second. Charging should typically be based on the amount of data transferred.

Three GPRS MS modes of operation are supported: An MS in class-A mode of operation operates GPRS and otherGSM services simultaneously. An MS in class-B mode of operation monitors control channels for GPRS and otherGSM services simultaneously, but can only operate one set of services at one time. An MS in class-C mode of operationexclusively operates GPRS services.

GPRS introduces two new network nodes in the GSM PLMN: The Serving GPRS Support Node (SGSN), which is atthe same hierarchical level as the MSC, keeps track of the individual MSs' location and performs security functions andaccess control. The SGSN is connected to the base station system with Frame Relay. The Gateway GSN (GGSN)provides interworking with external packet-switched networks, and is connected with SGSNs via an IP-based GPRSbackbone network. The HLR is enhanced with GPRS subscriber information, and the SMS-GMSCs and SMS-IWMSCsare upgraded to support SMS transmission via the SGSN. Optionally, the MSC/VLR can be enhanced for more-efficientco-ordination of GPRS and non-GPRS services and functionality: e.g., paging for circuit-switched calls that can beperformed more efficiently via the SGSN, and combined GPRS and non-GPRS location updates.

GPRS security functionality is equivalent to the existing GSM security. The SGSN performs authentication and ciphersetting procedures based on the same algorithms, keys, and criteria as in existing GSM. GPRS uses a cipheringalgorithm optimised for packet data transmission. A GPRS ME can access the GPRS services with SIMs that are notGPRS-aware, and with GPRS-aware SIMs.

ETSI


Cell selection may be performed autonomously by an MS, or the base station system instructs the MS to select a certaincell. The MS informs the network when it re-selects another cell or group of cells known as a routeing area.

In order to access the GPRS services, an MS shall first make its presence known to the network by performing a GPRSattach. This operation establishes a logical link between the MS and the SGSN, and makes the MS available for SMSover GPRS, paging via SGSN, and notification of incoming GPRS data.

In order to send and receive GPRS data, the MS shall activate the packet data address that it wants to use. Thisoperation makes the MS known in the corresponding GGSN, and interworking with external data networks cancommence.

User data is transferred transparently between the MS and the external data networks with a method known asencapsulation and tunnelling: data packets are equipped with GPRS-specific protocol information and transferredbetween the MS and GGSN. This transparent transfer method lessens the requirement for the GPRS PLMN to interpretexternal data protocols, and it enables easy introduction of additional interworking protocols in the future. User data canbe compressed and protected with retransmission protocols for efficiency and reliability.

5 General GPRS Architecture and TransmissionMechanism

5.1 GPRS Access Interfaces and Reference PointsEach GPRS PLMN has two access points, the Um used for mobile access and the R reference point used for originationor reception of messages. The R reference point for the GPRS MSs is defined in GSM 07.60 [16].

An interface differs from a reference point in that an interface is defined where specific GPRS information is exchangedand needs to be fully recognised.

There is an inter-GPRS PLMN interface called Gp that connects two independent GPRS networks for messageexchange.

There is also a GPRS PLMN to fixed network (typically a packet data network) reference point called Gi. Gi is definedin GSM 09.61 [26].

Gi reference point

GPRS network 1

GPRS network 2

PDNs orother networksTE MT

Gp

UmR reference point

MS

Figure 1: GPRS Access Interfaces and Reference Points

There may be more than a single GPRS network interface to several different packet data (or other) networks. Thesenetworks may both differ in ownership as well as in communications protocol (e.g., X.25, TCP/IP etc.). The networkoperator should define and negotiate interconnect with each external (PDN or other) network.

ETSI


5.2 Network InterworkingNetwork interworking is required whenever a PLMN supporting GPRS and any other network are involved in theexecution of a GPRS service request. With reference to figure 1, interworking takes place through the Gi referencepoint and the Gp interface.

The GPRS internal mechanism for conveying the PDP PDU through the GSM PLMN is managed by the GSM GPRSnetwork operator and is not apparent to the data user. The use of this GSM data service may have an impact on andincrease the transfer time normally found for a message when communicated through a fixed packet data network.

5.2.1 PSPDN Interworking

GPRS shall support interworking with PSPDN networks. The interworking may be either direct or through a transitnetwork (e.g., ISDN). GPRS shall support both X.121 [38] and E.164 [30] addresses.

GPRS shall provide support for X.25 virtual circuits and X.25 fast select. X.75 [37] or X.75' [45] may be used forinterworking with X.25 PDNs.

The GPRS TEs have addresses provided by the GSM PLMN GPRS service operator and belong to the GPRS servicedomain. The PSPDN TE sends data to the GPRS TE by use of the GSM PLMN GPRS DNIC (Data NetworkIdentification Code) or equivalent that uniquely identifies the GPRS network.

5.2.2 Internet (IP) Interworking

GPRS shall support interworking with networks based on the internet protocol (IP). IP is defined in RFC 791 [40].GPRS may provide compression of the TCP/IP header when an IP-datagram is used within the context of a TCPconnection.

In a similar way to the PSPDN X.25 case, the GSM PLMN GPRS service is an IP domain, and mobile terminals offeredservice by a GSM service provider may be globally addressable through the network operator's addressing scheme.

5.3 High-Level Functions Required for GPRSThe following list gives the logical functions performed within the GPRS network. Several functional groupings (meta-functions) are defined which each encompasses a number of individual functions:

- Network Access Control Functions;

- Packet Routeing and Transfer Functions;

- Mobility Management Functions;

- Logical Link Management Functions;

- Radio Resource Management Functions;

- Network Management Functions.

5.3.1 Network Access Control Functions

Network access is the means by which a user is connected to a telecommunication network in order to use the servicesand/or facilities of that network. An access protocol is a defined set of procedures that enables the user to employ theservices and/or facilities of the network.

User network access may occur from either the mobile side or the fixed side of the GPRS network. The fixed networkinterface may support multiple access protocols to external data networks, for example X.25 or IP. The set of accessprotocols to be supported is determined by the PLMN operator.

ETSI


Individual PLMN administrations may require specific access-control procedures in order to limit the set of userspermitted to access the network, or to restrict the capabilities of individual users, for example by limiting the type ofservice available to an individual subscriber. Such access control procedures are beyond the scope of the GPRSspecifications.

In addition to the standard data transfer, GPRS may support anonymous access to the network. The service allows anMS to exchange data packets with a predefined host that can be addressed by the supported interworking protocols.Only a limited number of destination PDP addresses can be used within this service. IMSI or IMEI shall not be usedwhen accessing the network thus guaranteeing a high level of anonymity. Therefore, no authentication and cipheringfunctionalities are foreseen for anonymous access.

5.3.1.1 Registration Function

Registration is the means by which a user's Mobile Id is associated with the user's packet data protocol(s) andaddress(es) within the PLMN, and with the user's access point(s) to the external PDP network. The association can bestatic, i.e., stored in an HLR, or dynamic, i.e., allocated on a per need basis.

5.3.1.2 Authentication and Authorisation Function

This function performs the identification and authentication of the service requester, and the validation of the servicerequest type to ensure that the user is authorised to use the particular network services. The authentication function isperformed in association with the Mobility Management functions.

5.3.1.3 Admission Control Function

The purpose of admission control is to calculate which network resources are required to provide the quality of service(QoS) requested, determine if those resources are available, and then reserve those resources. Admission control isperformed in association with the Radio Resource Management functions in order to estimate the radio resourcerequirements within each cell.

5.3.1.4 Message Screening Function

A screening function concerned with filtering out unauthorised or unsolicited messages is required. This should besupported through packet filtering functions. Network-controlled screening is supported in the first phase of GPRS.Subscription-controlled and user-controlled screening may be provided in a later phase.

5.3.1.5 Packet Terminal Adaptation Function

This function adapts data packets received / transmitted from / to terminal equipment to a form suitable for transmissionacross the GPRS network.

5.3.1.6 Charging Data Collection Function

This function collects data necessary to support subscription and/or traffic fees.

5.3.2 Packet Routeing and Transfer Functions

A route is an ordered list of nodes used for the transfer of messages within and between the PLMN(s). Each routeconsists of the originating node, zero or more relay nodes and the destination node. Routeing is the process ofdetermining and using, in accordance with a set of rules, the route for transmission of a message within and between thePLMN(s).

5.3.2.1 Relay Function

The relay function is the means by which a node forwards data received from one node to the next node in the route.

ETSI


5.3.2.2 Routeing Function

The routeing function determines the network node to which a message should be forwarded and the underlyingservice(s) used to reach that GPRS Support Node (GSN), using the destination address of the message. The routeingfunction selects the transmission path for the "next hop" in the route.

Data transmission between GSNs may occur across external data networks that provide their own internal routeingfunctions, for example X.25, Frame Relay or ATM networks.

5.3.2.3 Address Translation and Mapping Function

Address translation is the conversion of one address to another address of a different type. Address translation may beused to convert an external network protocol address into an internal network address that can be used for routeingpackets within and between the PLMN(s).

Address mapping is used to map a network address to another network address of the same type for the routeing andrelaying of messages within and between the PLMN(s), for example to forward packets from one network node toanother.

5.3.2.4 Encapsulation Function

Encapsulation is the addition of address and control information to a data unit for routeing packets within and betweenthe PLMN(s). Decapsulation is the removal of the addressing and control information from a packet to reveal theoriginal data unit.

Encapsulation and decapsulation are performed between the support nodes of the GPRS PLMN(s), and between theserving support node and the MS.

5.3.2.5 Tunnelling Function

Tunnelling is the transfer of encapsulated data units within and between the PLMN(s) from the point of encapsulation tothe point of decapsulation. A tunnel is a two-way point-to-point path. Only the tunnel endpoints are identified.

5.3.2.6 Compression Function

The compression function optimises use of radio path capacity by transmitting as little of the SDU (i.e., the exteriorPDP PDU) as possible while at the same time as preserving the information contained within it.

5.3.2.7 Ciphering Function

The ciphering function preserves the confidentiality of user data and signalling across the radio channels and inherentlyprotects the PLMN from intruders.

5.3.2.8 Domain Name Server Function

The Domain Name Server function resolves logical GSN names to GSN addresses. This function is standard Internetfunctionality according to RFC 1034 [43], which allows to resolve any name for GSNs and other GPRS nodes withinthe GPRS backbone networks.

5.3.3 Mobility Management Functions

The mobility management functions are used to keep track of the current location of an MS within the PLMN or withinanother PLMN.

5.3.4 Logical Link Management Functions

Logical link management functions are concerned with the maintenance of a communication channel between anindividual MS and the PLMN across the radio interface. These functions involve the co-ordination of link stateinformation between the MS and the PLMN as well as the supervision of data transfer activity over the logical link.

ETSI


Refer to GSM 04.64 [13] for further information.

5.3.4.1 Logical Link Establishment Function

Logical link establishment is performed when the MS attaches to the GPRS service.

5.3.4.2 Logical Link Maintenance Functions

Logical link maintenance functions supervise the logical link status and control link state changes.

5.3.4.3 Logical Link Release Function

The logical link release function is used to de-allocate resources associated with the logical link connection.

5.3.5 Radio Resource Management Functions

Radio resource management functions are concerned with the allocation and maintenance of radio communicationpaths. GSM radio resources is shared between the circuit mode (voice and data) services and the GPRS.

Refer to GSM 03.64 for further information.

5.3.5.1 Um Management Function

This function manages the set of physical channels used in each cell and determines the amount of radio resources to beallocated for GPRS use. The amount of radio resources allocated for GPRS may vary from cell to cell depending uponlocal user demand or other policies established by the PLMN operator.

5.3.5.2 Cell Selection Function

This function enables the MS to select the optimal cell for use in establishing a communication path with the PLMN.This involves the measurement and evaluation of signal quality from nearby cells as well as the detection and avoidanceof congestion within candidate cells.

Refer to GSM 03.22 [7] and GSM 03.64 for further information.

5.3.5.3 Um-tranx Function

The Um-tranx function provides packet data transfer capability across the radio interface between the MS and the BSS.This function includes procedures that:

- Provide medium access control over radio channels;

- Provide packet multiplexing over common physical radio channels;

- Provide packet discrimination within the MS;

- Provide error detection and correction;

- Provide flow control procedures.

5.3.5.4 Path Management Function

This function manages the packet data communication paths between the BSS and the serving GSN nodes. Theestablishment and release of these paths may be dynamic based upon the amount of data traffic or may be static basedupon the maximum expected load within each cell.

5.3.6 Network Management Functions

Network management functions provide mechanisms to support O&M functions related to GPRS.

ETSI


5.4 Logical ArchitectureGPRS is logically implemented on the GSM structure through the addition of two network nodes, the Serving GPRSSupport Node and the Gateway GPRS Support Node. It is necessary to name a number of new interfaces. No inferenceshould be drawn about the physical configuration on an interface from figure 2.

Gf

D

Gi

Gn

Gb

Gc

CE

Gp

Gs

Signalling and Data Transfer Interface

Signalling Interface

MSC/VLR

TE MT BSS TEPDN

R Um

GrA

HLR

Other PLMN

SGSN

GGSN

Gd

SM-SCSMS-GMSC

SMS-IWMSC

GGSN

EIR

SGSN

Gn

CGF

GaGa

BillingSystem

Figure 2: Overview of the GPRS Logical Architecture

5.4.1 GPRS Support Nodes

A GPRS Support Node (GSN) contains functionality required to support GPRS. In one PLMN, there may be more thanone GSN.

The Gateway GPRS Support Node (GGSN) is the node that is accessed by the packet data network due to evaluation ofthe PDP address. It contains routeing information for attached GPRS users. The routeing information is used to tunnelN-PDUs to the MS's current point of attachment, i.e., the Serving GPRS Support Node. The GGSN may requestlocation information from the HLR via the optional Gc interface. The GGSN is the first point of PDN interconnectionwith a GSM PLMN supporting GPRS (i.e., the Gi reference point is supported by the GGSN).

The Serving GPRS Support Node (SGSN) is the node that is serving the MS (i.e., the Gb interface is supported by theSGSN). At GPRS attach, the SGSN establishes a mobility management context containing information pertaining toe.g., mobility and security for the MS. At PDP Context Activation, the SGSN establishes a PDP context, to be used forrouteing purposes, with the GGSN that the GPRS subscriber will be using.

The SGSN and GGSN functionalities may be combined in the same physical node, or they may reside in differentphysical nodes. SGSN and GGSN contain IP routeing functionality, and they may be interconnected with IP routers.When SGSN and GGSN are in different PLMNs, they are interconnected via the Gp interface. The Gp interfaceprovides the functionality of the Gn interface, plus security functionality required for inter-PLMN communication. Thesecurity functionality is based on mutual agreements between operators.

The SGSN may send location information to the MSC/VLR via the optional Gs interface. The SGSN may receivepaging requests from the MSC/VLR via the Gs interface.

ETSI


5.4.2 GPRS Backbone Networks

There are two kinds of GPRS backbone networks. These are called:

- intra-PLMN backbone network; and

- inter-PLMN backbone network.

The intra-PLMN backbone network is the IP network interconnecting GSNs within the same PLMN.

The inter-PLMN backbone network is the IP network interconnecting GSNs and intra-PLMN backbone networks indifferent PLMNs.

BG

SGSN

BG

SGSN

GGSN GGSN

SGSN

Intra-PLMN BackboneIntra-PLMN Backbone

Gi Gp Gi

PLMN A PLMN B

Packet Data Network

Inter-PLMN Backbone

Figure 3: Intra- and Inter-PLMN Backbone Networks

Every intra-PLMN backbone network is a private IP network intended for GPRS data and GPRS signalling only. Aprivate IP network is an IP network to which some access control mechanism is applied in order to achieve a requiredlevel of security. Two intra-PLMN backbone networks are connected via the Gp interface using Border Gateways(BGs) and an inter-PLMN backbone network. The inter-PLMN backbone network is selected by a roaming agreementthat includes the BG security functionality. The BG is not defined within the scope of GPRS. The inter-PLMNbackbone can be a Packet Data Network, e.g., the public Internet or a leased line.

5.4.3 HLR

The HLR contains GPRS subscription data and routeing information. The HLR is accessible from the SGSN via the Grinterface and from the GGSN via the Gc interface. For roaming MSs, HLR may be in a different PLMN than the currentSGSN.

5.4.4 SMS-GMSC and SMS-IWMSC

The SMS-GMSC and SMS-IWMSC are connected to the SGSN via the Gd interface to enable GPRS MSs to send andreceive SMs over GPRS radio channels.

ETSI


5.4.5 GPRS Mobile Stations

A GPRS MS can operate in one of three modes of operation. The mode of operation depends on the services that theMS is attached to, i.e., only GPRS or both GPRS and other GSM services, and upon the MS's capabilities to operateGPRS and other GSM services simultaneously.

- Class-A mode of operation: The MS is attached to both GPRS and other GSM services, and the MS supportssimultaneous operation of GPRS and other GSM services.

- Class-B mode of operation: The MS is attached to both GPRS and other GSM services, but the MS can onlyoperate one set of services at a time.

- Class-C mode of operation: The MS is exclusively attached to GPRS services.

The three modes of operation are defined in GSM 02.60.

NOTE: Other GSM technical specifications may refer to the MS modes of operation as GPRS class-A MS, GPRSclass-B MS, and GPRS class-C MS.

5.4.6 Charging Gateway Functionality

The Charging Gateway Functionality (CGF) is described in GSM 12.15 [28].

5.5 Assignment of Functions to General Logical ArchitectureThe functions identified in the functional model are assigned to the logical architecture.

Table 1: Mapping of Functions to Logical Architecture

Function MS BSS SGSN GGSN HLRNetwork Access Control:Registration XAuthentication and Authorisation X X XAdmission Control X X XMessage Screening XPacket Terminal Adaptation XCharging Data Collection X X

Packet Routeing & Transfer:Relay X X X XRouteing X X X XAddress Translation and Mapping X X XEncapsulation X X XTunnelling X XCompression X XCiphering X X X

Mobility Management: X X X X

Logical Link Management:Logical Link Establishment X XLogical Link Maintenance X XLogical Link Release X X

Radio Resource Management:Um Management X XCell Selection X XUm-Tranx X XPath Management X X

ETSI


5.6 Transmission and Signalling Planes

5.6.1 Transmission Plane

The transmission plane consists of a layered protocol structure providing user information transfer, along withassociated information transfer control procedures (e.g., flow control, error detection, error correction and errorrecovery). The transmission plane independence of the Network Subsystem (NSS) platform from the underlying radiointerface is preserved via the Gb interface. The following transmission plane is used in GPRS.

Relay

NetworkService

GTP

Application

IP / X.25

SNDCP

LLC

RLC

MAC

GSM RF

SNDCP

LLC

BSSGP

L1bis

RLC

MAC

GSM RF

BSSGP

L1bis

Relay

L2

L1

IP

L2

L1

IP

GTP

IP / X.25

Um Gb Gn GiMS BSS SGSN GGSN

NetworkService

UDP /TCP

UDP /TCP

Figure 4: Transmission Plane

Legend:

- GPRS Tunnelling Protocol (GTP): This protocol tunnels user data and signalling between GPRS Support Nodesin the GPRS backbone network. All PDP PDUs shall be encapsulated by the GPRS Tunnelling Protocol. GTP isspecified in GSM 09.60 [25].

- TCP carries GTP PDUs in the GPRS backbone network for protocols that need a reliable data link (e.g., X.25),and UDP carries GTP PDUs for protocols that do not need a reliable data link (e.g., IP). TCP provides flowcontrol and protection against lost and corrupted GTP PDUs. UDP provides protection against corrupted GTPPDUs. TCP is defined in RFC 793 [42]. UDP is defined in RFC 768 [39].

- IP: This is the GPRS backbone network protocol used for routeing user data and control signalling. The GPRSbackbone network may initially be based on the IP version 4 protocol. Ultimately, IP version 6 shall be used. IPversion 4 is defined in RFC 791.

- Subnetwork Dependent Convergence Protocol (SNDCP): This transmission functionality maps network-levelcharacteristics onto the characteristics of the underlying network. SNDCP is specified in GSM 04.65 [14].

- Logical Link Control (LLC): This layer provides a highly reliable ciphered logical link. LLC shall beindependent of the underlying radio interface protocols in order to allow introduction of alternative GPRS radiosolutions with minimum changes to the NSS. LLC is specified in GSM 04.64.

- Relay: In the BSS, this function relays LLC PDUs between the Um and Gb interfaces. In the SGSN, thisfunction relays PDP PDUs between the Gb and Gn interfaces.

- Base Station System GPRS Protocol (BSSGP): This layer conveys routeing- and QoS-related informationbetween BSS and SGSN. BSSGP does not perform error correction. BSSGP is specified in GSM 08.18 [20].

- Network Service (NS): This layer transports BSSGP PDUs. NS is based on the Frame Relay connection betweenBSS and SGSN, and may be multi-hop and traverse a network of Frame Relay switching nodes. NS is specifiedin GSM 08.16 [19].

- RLC/MAC: This layer contains two functions: The Radio Link Control function provides a radio-solution-dependent reliable link. The Medium Access Control function controls the access signalling (request and grant)procedures for the radio channel, and the mapping of LLC frames onto the GSM physical channel. RLC/MAC isdefined in GSM 04.60 [12].

ETSI


- GSM RF: As defined in GSM 05 series.

5.6.2 Signalling Plane

The signalling plane consists of protocols for control and support of the transmission plane functions:

- controlling the GPRS network access connections, such as attaching to and detaching from the GPRS network;

- controlling the attributes of an established network access connection, such as activation of a PDP address;

- controlling the routeing path of an established network connection in order to support user mobility; and

- controlling the assignment of network resources to meet changing user demands.

The following signalling planes are used in GPRS:

5.6.2.1 MS - SGSN

BSSGPRelay

GMM/SM

LLC

RLC

MAC

GSM RF

GMM/SM

LLC

BSSGP

L1bis

Um GbMS BSS SGSN

NetworkService

RLC

MAC

GSM RF L1bis

NetworkService

Figure 5: Signalling Plane MS - SGSN

Legend:

- GPRS Mobility Management and Session Management (GMM/SM): This protocol supports mobilitymanagement functionality such as GPRS attach, GPRS detach, security, routeing area update, location update,PDP context activation, and PDP context deactivation, as described in subclauses "Mobility ManagementFunctionality" and "PDP Context Activation, Modification, and Deactivation Functions".

5.6.2.2 SGSN - HLR

SCCP

MTP2

MTP3

MTP2

MTP3

SCCP

GrSGSN HLR

TCAP

MAP

TCAP

MAP

L1 L1

Figure 6: Signalling Plane SGSN - HLR

Legend:

- Mobile Application Part (MAP): This protocol supports signalling exchange with the HLR, as defined inGSM 09.02 [22], with enhancements for GPRS as described in the present document.

- TCAP, SCCP, MTP3, and MTP2 are the same protocols as used to support MAP in non-GPRS GSM PLMNs.

ETSI


5.6.2.3 SGSN - MSC/VLR

SCCP

MTP2

MTP3

MTP2

MTP3

SCCP

GsSGSN MSC/VLR

BSSAP+ BSSAP+

L1 L1

Figure 7: Signalling Plane SGSN - MSC/VLR

Legend:

- Base Station System Application Part + (BSSAP+): A subset of BSSAP procedures supports signalling betweenthe SGSN and MSC/VLR, as described in subclause "Mobility Management Functionality" and inGSM 09.18 [24]. The requirements for the lower layers are specified in GSM 09.16 [23].

5.6.2.4 SGSN - EIR

SCCP

MTP2

MTP3

MTP2

MTP3

SCCP

GfSGSN EIR

TCAP

MAP

TCAP

MAP

L1 L1

Figure 8: Signalling Plane SGSN - EIR

Legend:

- Mobile Application Part (MAP): This protocol supports signalling between the SGSN and the EIR, as describedin subclause "Identity Check Procedures".

5.6.2.5 SGSN - SMS-GMSC or SMS-IWMSC

SCCP

MTP2

MTP3

MTP2

MTP3

SCCP

GdSGSN SMS-MSC

TCAP

MAP

TCAP

MAP

L1 L1

Figure 9: Signalling Plane SGSN - SMS-GMSC and SGSN - SMS-IWMSC

Legend:

- Mobile Application Part (MAP): This protocol supports signalling between the SGSN and SMS-GMSC or SMS-IWMSC, as described in subclause "Point-to-point Short Message Service".

ETSI


5.6.2.6 GSN - GSN

UDP

L2

L1

IP

L2

L1

IP

UDP

GnGSN GSN

GTP GTP

Figure 10: Signalling Plane GSN - GSN

Legend:

- GPRS Tunnelling Protocol (GTP): This protocol tunnels user data and signalling messages between SGSNs andGGSNs, and between SGSNs, in the GPRS backbone network.

- User Datagram Protocol (UDP): This protocol transfers signalling messages between GSNs. UDP is defined inRFC 768.

5.6.2.7 GGSN - HLR

This optional signalling path allows a GGSN to exchange signalling information with an HLR. There are twoalternative ways to implement this signalling path:

- If a SS7 interface is installed in the GGSN, the MAP protocol can be used between the GGSN and an HLR.

- If a SS7 interface is not installed in the GGSN, any GSN with a SS7 interface installed in the same PLMN as theGGSN can be used as a GTP-to-MAP protocol converter to allow signalling between the GGSN and an HLR.

5.6.2.7.1 MAP-based GGSN - HLR Signalling

SCCP

MTP2

MTP3

MTP2

MTP3

SCCP

GcGGSN HLR

TCAP

MAP

TCAP

MAP

L1 L1

Figure 11: Signalling Plane GGSN - HLR Using MAP

Legend:

- Mobile Application Part (MAP): This protocol supports signalling exchange with the HLR, as described insubclause "Network-Requested PDP Context Activation Procedure".

ETSI


5.6.2.7.2 GTP and MAP-based GGSN - HLR Signalling

Gn

UDP

L2

IP

GGSN

L1

L2

IP

GSN

GTP

L1

MTP2

MTP3

SCCP

MAP

L1

MTP2

MTP3

SCCP

HLR

TCAP

MAP

L1

GTP

Gc

Interworking

TCAP

UDP

Figure 12: Signalling Plane GGSN - HLR Using GTP and MAP

Legend:

- GPRS Tunnelling Protocol (GTP): This protocol tunnels signalling messages between the GGSN and theprotocol-converting GSN in the GPRS backbone network.

- Interworking: This function provides interworking between GTP and MAP for GGSN - HLR signalling.

6 Mobility Management Functionality

6.1 Definition of Mobility Management StatesThe Mobility Management (MM) activities related to a GPRS subscriber are characterised by one of three different MMstates. Each state describes a certain level of functionality and information allocated. The information sets held at theMS and SGSN are denoted MM context.

In the non-anonymous access case, the MM state relates only to GPRS MM activities of a subscriber. The MM state isindependent of the number and state of PDP contexts for that subscriber.

In the anonymous access case, the MM state relates to GPRS MM activities of an MS represented only by an AuxiliaryTLLI.

6.1.1 IDLE (GPRS) State

In GPRS IDLE state, the subscriber is not attached to the GPRS mobility management. The MS and SGSN context holdno valid location or routeing information for the subscriber. The subscriber-related mobility management procedures arenot performed.

PLMN selection and GPRS cell selection and re-selection processes are performed by the MS.

Data transmission to and from the mobile subscriber as well as the paging of the subscriber are not possible. The GPRSMS is seen as not reachable in this case.

In order to establish MM contexts in the MS and the SGSN, the MS shall perform the GPRS Attach procedure.

6.1.2 STANDBY State

In STANDBY state, the subscriber is attached to GPRS mobility management. The MS and SGSN have establishedMM contexts for the subscriber's IMSI as described in clause "Information Storage".

Pages for data or signalling information transfers may be received. It is also possible to receive pages for the CSservices via the SGSN. Data reception and transmission are not possible in this state.

ETSI


The MS performs GPRS Routeing Area (RA) and GPRS cell selection and re-selection locally. The MS executesmobility management procedures to inform the SGSN when it has entered a new RA. The MS does not inform theSGSN on a change of cell in the same RA. Therefore, the location information in the SGSN MM context contains onlythe GPRS RAI for MSs in STANDBY state.

The MS may initiate activation or deactivation of PDP contexts while in STANDBY state. A PDP context shall beactivated before data can be transmitted or received for this PDP context.

The SGSN may have to send data or signalling information to an MS in STANDBY state. The SGSN then sends aPaging Request in the routeing area where the MS is located if PPF is set. If PPF is cleared, then paging is not done.The MM state in the MS is changed to READY when the MS responds to the page, and in the SGSN when the pageresponse is received. Also, the MM state in the MS is changed to READY when data or signalling information is sentfrom the MS and, accordingly, the MM state in the SGSN is changed to READY when data or signalling information isreceived from the MS.

The MS or the network may initiate the GPRS Detach procedure to move to the IDLE state. After expiry of the mobilereachable timer the SGSN may perform an implicit detach in order to return the MM contexts in the SGSN to IDLEstate. The MM and PDP contexts may then be deleted.

6.1.3 READY State

In READY state, the SGSN MM context corresponds to the STANDBY MM context extended by location informationfor the subscriber on cell level. The MS performs mobility management procedures to provide the network with theactual selected cell. GPRS cell selection and re-selection is done locally by the MS, or may optionally be controlled bythe network.

An identifier of the cell, the Cell Global Identity including RAC and LAC, is included in the BSSGP header of the datapacket from the MS, see GSM 08.18.

The MS may send and receive PDP PDUs in this state. The network initiates no GPRS pages for an MS in READYstate, pages for other services may be done via the SGSN. The SGSN transfers downlink data to the BSS responsible forthe subscriber's actual GPRS cell.

The MS may activate or deactivate PDP contexts while in READY state.

Regardless if a radio resource is allocated to the subscriber or not, the MM context remains in the READY state evenwhen there is no data being communicated. The READY state is supervised by a timer. An MM context moves fromREADY state to STANDBY state when the READY timer expires. In order to move from READY state to IDLE state,the MS initiates the GPRS Detach procedure.

ETSI


6.2 IDLE / STANDBY / READY State Functionality

6.2.1 State Transitions and Functions

The movement from one state to the next is dependent on the current state (IDLE, STANDBY, or READY) and theevent occurred (e.g., GPRS attach).

PDU transmission

Implicit Detachor

Cancel Location

GPRS Attach

READY timer expiryorForce to STANDBY

GPRS Detach GPRS Attach

PDU reception

GPRS Detachor

Cancel Location

MM State Model of MS MM State Model of SGSN

IDLE

READY

STANDBY

IDLE

READY

STANDBY

READY timer expiryorForce to STANDBYorAbnormal RLC condition

Figure 13: Functional Mobility Management State Model

Figure 13 describes the following state transitions:

Moving from IDLE to READY:

- GPRS Attach: The MS requests access and a logical link to an SGSN is initiated. MM contexts are established atthe MS and SGSN.

Moving from STANDBY to IDLE:

- Implicit Detach: The MM and PDP contexts in the SGSN shall return to IDLE and INACTIVE state. The MMand PDP contexts in the SGSN may be deleted. The GGSN PDP contexts shall be deleted.

- Cancel Location: The SGSN receives a MAP Cancel Location message from the HLR, and removes the MM andPDP contexts.

Moving from STANDBY to READY:

- PDU transmission: The MS sends an LLC PDU to the SGSN, possibly in response to a page.

- PDU reception: The SGSN receives an LLC PDU from the MS.

ETSI


Moving from READY to STANDBY:

- READY timer expiry: The MS and the SGSN MM contexts return to STANDBY state.

- Force to STANDBY: The SGSN indicates an immediate return to STANDBY state before the READY timerexpires.

- Abnormal RLC condition: The SGSN MM context returns to STANDBY state in case of delivery problems onthe radio interface or in case of irrecoverable disruption of a radio transmission.

Moving from READY to IDLE:

- GPRS Detach: The MS or the network requests that the MM contexts return to IDLE state and that the PDPcontexts return to INACTIVE state. The SGSN may delete the MM and PDP contexts. The PDP contexts in theGGSN shall be deleted.

- Cancel Location: The SGSN receives a MAP Cancel Location message from the HLR, and removes the MM andPDP contexts.

For anonymous access, a reduced Mobility Management State Model consisting of IDLE and READY states is used.The AA MM state machine is independently handled by the MS and the network and may coexist with an IMSI-basedMM state machine. Several AA MM state machines may coexist in the same MS and SGSN simultaneously.

READY timer expiryor

AA PDP ContextDeactivation

AA PDP ContextActivation

AA MM State Model of MS

IDLE

READY

READY timer expiryor

Abnormal RLC conditionor

AA PDP ContextDeactivation

AA PDP ContextActivation

AA MM State Model of SGSN

IDLE

READY

Figure 14: Functional Anonymous Access Mobility Management State Model

Figure 14 describes the following state transitions for anonymous access:

Moving from IDLE to READY:

- AA PDP Context Activation: The MS requests an anonymous access and a logical link to an SGSN is initiated.MM contexts are established at the MS and SGSN, and PDP contexts are established at the MS, the SGSN, and aGGSN.

Moving from READY to IDLE:

- READY timer expiry: The MM and PDP contexts in the MS, the SGSN, and the GGSN are deleted.

- Abnormal RLC condition: The SGSN MM context shall be deleted in case of delivery problems on the radiointerface or in case of irrecoverable disruption of a radio transmission.

- AA PDP Context Deactivation: The network (either the SGSN or the GGSN) initiates the AA PDP ContextDeactivation procedure, e.g., due to malicious usage of the anonymous service. The MM and PDP contexts inthe MS, the SGSN, and the GGSN shall be deleted.

ETSI


6.2.2 READY Timer Function

The READY timer function maintains the READY timer in the MS and SGSN. The READY timer controls the time anMS remains in READY state in the MS and the SGSN. The READY timer shall be reset and begin running in the MSwhen an LLC PDU is transmitted, and in the SGSN when an LLC PDU is correctly received. When the READY timerexpires, the MS and SGSN MM contexts shall return to STANDBY state. In case of anonymous access the MM contextshall be deleted.

The length of the READY timer shall be the same in the MS and SGSN. The initial length of the READY timer shall bedefined by a default value. The SGSN, and only the SGSN, may change the length of the READY timer by transmittinga new value in the Attach Accept, Routeing Area Update Accept, or AA PDP Context Accept messages.

If the READY timer length is set to zero, the MS shall immediately be forced into STANDBY state. If the timer lengthis set to all 1s (binary), then the READY timer function shall be deactivated, i.e., the timer no longer runs and the MSremains in READY state.

6.2.3 Periodic RA Update Timer Function

The Periodic RA Update Timer function monitors the periodic RA update procedure in the MS. The length of theperiodic RA update timer is sent in the Routeing Area Update Accept or Attach Accept message. The periodic RAupdate timer is unique within an RA. Upon expiry of the periodic RA update timer, the MS shall start a periodicrouteing area update procedure.

If the MS is in coverage but out of GPRS coverage when the periodic RA update timer expires, then, if the MS is IMSI-attached to a network in network operation mode I, the periodic location update procedure (or other appropriate locationupdate procedure) shall be started immediately. In addition, and irrespective of whether or not the MS was IMSI-attached, regardless of the network operation mode, the periodic RA update procedure (or other appropriate updateprocedure) shall be started as soon as the MS returns to GPRS coverage.

If the MS is out of coverage when the periodic RA update timer expires then:

- if the MS is both IMSI and GPRS-attached and returns to coverage in a cell that supports GPRS in networkoperation mode I, then the combined RA / LA update procedure with IMSI attach requested shall be started assoon as the MS returns to coverage;

- if the MS is both IMSI and GPRS-attached and returns to coverage in a cell that supports GPRS in networkoperation mode II or III, or if a GPRS only-attached MS returns to coverage in a cell that supports GPRS, thenthe periodic RA update procedure shall be started as soon as the MS returns to coverage; or

- if the MS returns to coverage in a cell that does not support GPRS, and if the MS is IMSI-attached, then theperiodic location update procedure (or other appropriate location update procedure) shall be started as soon asthe MS returns to coverage in that cell. In addition, and irrespective of whether or not the MS was IMSI-attached, the periodic RA update procedure (or other appropriate update procedure) shall be started as soon asthe MS returns to GPRS coverage.

If the MS lost GPRS coverage but the periodic RA update timer did not expire while out of GPRS coverage, then, theMS shall not perform the periodic RA update procedure because of the MS's return to GPRS coverage.

If the MS lost coverage but the periodic RA update timer did not expire while out of coverage, then the MS shall notperform the periodic RA update procedure because of the MS's return to coverage.

6.2.4 Mobile Reachable Timer Function

The Mobile Reachable Timer function monitors the periodic RA update procedure in the SGSN. The mobile reachabletimer shall be slightly longer than the periodic RA update timer used by an MS.

The mobile reachable timer is stopped when the READY state is entered. The mobile reachable timer is reset andstarted when the state returns to STANDBY.

ETSI


If the mobile reachable timer expires, the SGSN shall clear PPF. Typically, this causes the SGSN to stop sending GPRSpaging or CS paging messages to the MS, but other features (e.g., MSC/VLR-based call forwarding) may happenimmediately. PPF is set when the next activity from the MS is detected. The MM and PDP contexts shall be kept in theSGSN.

When an MS first registers in an SGSN, then PPF is set.

6.3 Interactions Between SGSN and MSC/VLRThe interactions described in this subclause shall be supported if the optional Gs interface is installed.

An association is created between SGSN and MSC/VLR to provide for interactions between SGSN and MSC/VLR. Theassociation is created when the VLR stores the SGSN number and the SGSN stores the VLR number. The association isused for co-ordinating MSs that are both GPRS-attached and IMSI-attached.

The association supports the following actions:

- IMSI attach and detach via SGSN. This makes combined GPRS / IMSI attach and combined GPRS / IMSIdetach possible, thus saving radio resources.

- Co-ordination of LA update and RA update, including periodic updates, thus saving radio resources. A combinedRA / LA update is sent from the MS to the SGSN. SGSN forwards the LA update to the VLR.

- Paging for a CS connection via the SGSN.

- Alert procedures for non-GPRS services.

- Identification procedure.

- MM Information procedure.

6.3.1 Administration of the SGSN - MSC/VLR Association

The SGSN - MSC/VLR association is created at the following occasions:

- Combined IMSI / GPRS attach;

- GPRS attach when the MS is already IMSI-attached;

- Combined RA / LA update when the MS performs IMSI attach and is already GPRS-attached;

Combined RA / LA update when an IMSI and GPRS-attached MS changes from an area of network operationmode II or III to an area of network operation mode I.

The association is initiated by the SGSN. The SGSN creates an association by sending a BSSAP+ message concerning aparticular MS to the VLR. To get the VLR number, the SGSN translates the current RAI to a VLR number via atranslation table. During a CS connection, an MS in class-B mode of operation cannot perform GPRS attach norrouteing area updates, only MSs in class-A mode of operation can perform these procedures. If a GPRS attach wasmade during a CS connection, the association shall be initiated by a combined RA / LA update after the CS connectionhas been released.

The association is updated on the following occasions:

- when an MS changes VLR;

- when an MS changes SGSN.

The association is not updated during a CS connection.

When the MS is in idle mode (see GSM 03.22), the association is updated with the combined RA / LA updatesprocedure.

ETSI


In relation with a CS connection, the association is managed in the following way:

MS in class-A mode of operation:

An MS in class-A mode of operation makes RA updates but no combined RA / LA updates during the CS connection.In the case when the MS changes SGSN, the SGSN (according to normal RA update procedures, see subclause "InterSGSN Routeing Area Update") updates the HLR and the GGSN, but not the VLR, about the new SGSN number.

In the case when the MS changes MSC during the CS connection, the subscriber data still remains in the old VLR untilthe CS connection is released and a combined RA / LA update or LA update is made. The association is also notupdated during the CS connection.

After the CS connection has been released, a combined RA / LA update is performed (if there has been a change of RA,or if a GPRS attach was performed and the new cell indicates network operation mode I), and the association is updatedaccording to combined RA / LA update procedures, see subclause "Combined RA / LA Update Procedure". If the newcell indicates network operation mode II or III, then the MS performs an LA update.

MS in class-B mode of operation:

An MS in class-B mode of operation does not make any RA updates during a CS connection. The SGSN numbertherefore remains the same during the CS connection and needs not be updated in the VLR. In the case when the MSchanges MSC during the CS connection, the subscriber data still remains in the old VLR until the CS connection hasbeen released and a combined RA / LA update or LA update is made. Therefore, the VLR number remains the sameduring the CS connection. After the CS connection has been released, the MS shall perform an RA update and an LAupdate if the RA has changed and the new cell indicates network operation mode II or III, or a combined RA / LAupdate if the RA has changed and the new cell indicates network operation mode I. The association is updatedaccording to the combined RA / LA update procedures, see subclauses "Inter SGSN Routeing Area Update" and"Combined RA / LA Update Procedure".

The SGSN - MSC/VLR association is removed at the following occasions:

- At IMSI detach.

- At GPRS detach.

When the MSC/VLR receives an LA update via the A interface from an MS for which an association exists, then theMSC/VLR shall remove the association without notifying the SGSN. When the SGSN receives a (non-combined) RAupdate from an MS for which an association exists, then the SGSN shall remove the association without notifying theMSC/VLR. When the MSC/VLR receives a BSSAP+ MS Unreachable message from the SGSN indicating that PPF iscleared, then the state of the association shall not be changed at the MSC/VLR.

6.3.2 Combined RA / LA Updating

When the MS is both IMSI and GPRS-attached, the LA and RA updating is done in a co-ordinated way to save radioresources if supported by the network operation mode. When the MS enters a new RA in network operation mode I,then the MS sends a Routeing Area Update Request message to the SGSN, as described in subclause "Combined RA /LA Update Procedure". The LA update is included in the RA update. The SGSN then forwards the LA update to theMSC/VLR. The MSC/VLR optionally returns a new VLR TMSI that is sent to the MS via the SGSN.

An MS in class-A mode of operation involved in a CS connection makes only RA updates and no combined RA / LAupdates to the SGSN.

An MS in class-B mode of operation involved in a CS connection does not make any updates during the CS connection.

An MS in class-C mode of operation never makes combined RA / LA updates.

6.3.3 CS Paging

When an MS is both IMSI and GPRS-attached in a network that operates in mode I, then the MSC/VLR executespaging for circuit-switched services via the SGSN. If the MS is in STANDBY state, then it is paged in the routeing areaand in the null routeing area (see subclause "Routeing Area Identity "). If the MS is in READY state, then it is paged inthe cell. The paging procedure is supervised in the MSC by a paging timer. The SGSN converts the MSC pagingmessage into an SGSN paging message.

ETSI


The CS Paging procedure is illustrated in figure 15. Each step is explained in the following list.

4. SABM (Paging Response)

5. SCCP Connection Request (Paging Response)

1. Page

3. Paging Request

2. Paging Request

MS BSS SGSN MSC/VLR

Figure 15: CS Paging Procedure

1) The SGSN receives a Page (IMSI, VLR TMSI, Channel Needed, Priority, Location Information) message fromthe MSC. Channel Needed is defined in GSM 08.08 [17] and indicates to the MS which type of CS channel isneeded to be requested in the response. VLR TMSI and Channel Needed are optional parameters. Priority is thecircuit-switched paging priority parameter as defined in GSM 08.08. The SGSN maps Priority to QoS.

2) The SGSN sends a BSSGP Paging Request (IMSI, TLLI, VLR TMSI, Area, Channel Needed, QoS) message tothe BSS serving the MS. Area is derived from either the MS's MM context in the SGSN or, if no suchinformation is available, from the Location Information received from the MSC/VLR. Area indicates a singlecell for a READY state MS or a routeing area for a STANDBY state MS. VLR TMSI and Channel Needed areincluded if received from the MSC. If Channel Needed was not received from the MSC, then a default ChannelNeeded parameter indicating circuit-switched paging is included by the SGSN. QoS indicates the priority of thisPaging Request relative to other Paging Request messages buffered in the BSS. If the location area where theMS was last known to be located has an associated null routeing area, then the SGSN shall send an additionalBSSGP Paging Request message to each BSS serving this null RA.

3) The BSS translates the incoming BSSGP Paging Request message into one radio Paging Request message percell. If a dedicated radio resource is assigned to the MS in a cell, then the BSS transmits one Paging Request(VLR TMSI or IMSI, Channel Needed) message on this radio resource, without stopping possibly ongoing datatransfers for the MS. Otherwise, the BSS pages the MS with one Paging Request (VLR TMSI or IMSI, ChannelNeeded) message on the appropriate paging channel in each addressed cell. This is described in GSM 03.64.

4) Upon receipt of a Paging Request message for a circuit-switched service the MS may accept to respond to thisrequest and shall then follow the CS procedures for paging response (random access, immediate assignment, andpaging response) as specified in GSM 04.08 [11].

5) When received at the BSS, the Paging Response message is sent to the MSC which shall then stop the pagingresponse timer.

6.3.3.1 Paging Co-ordination

The network may provide co-ordination of paging for circuit-switched and packet-switched services. Paging co-ordination means that the network sends paging messages for circuit-switched services on the same channel as used forpacket-switched services, i.e., on the GPRS paging channel or on the GPRS traffic channel, and the MS needs only tomonitor that channel. Three network operation modes are defined.

- Network operation mode I: the network sends a CS paging message for a GPRS-attached MS, either on the samechannel as the GPRS paging channel (i.e., the packet paging channel or the CCCH paging channel), or on aGPRS traffic channel. This means that the MS needs only to monitor one paging channel, and that it receives CSpaging messages on the packet data channel when it has been assigned a packet data channel.

- Network operation mode II: the network sends a CS paging message for a GPRS-attached MS on the CCCHpaging channel, and this channel is also used for GPRS paging. This means that the MS needs only to monitorthe CCCH paging channel, but that CS paging continues on this paging channel even if the MS has beenassigned a packet data channel.

ETSI


- Network operation mode III: the network sends a CS paging message for a GPRS-attached MS on the CCCHpaging channel, and sends a GPRS paging message on either the packet paging channel (if allocated in the cell)or on the CCCH paging channel. This means that an MS that wants to receive pages for both circuit-switchedand packet-switched services shall monitor both paging channels if the packet paging channel is allocated in thecell. No paging co-ordination is performed by the network.

Table 2: Network Operation Modes

Mode Circuit Paging Channel GPRS Paging Channel Paging co-ordinationPacket Paging Channel Packet Paging Channel

I CCCH Paging Channel CCCH Paging Channel YesPacket Data Channel Not Applicable

II CCCH Paging Channel CCCH Paging Channel NoIII CCCH Paging Channel Packet Paging Channel No

CCCH Paging Channel CCCH Paging Channel

When the Gs interface is present, all MSC-originated paging of GPRS-attached MSs shall go via the SGSN, thusallowing network co-ordination of paging. Paging co-ordination shall be made by the SGSN based on the IMSI, and isprovided independently of whether the MS is in STANDBY or in READY state. The network operates in mode I.

When the Gs interface is not present, all MSC-originated paging of GPRS-attached MSs shall go via the A interface,and co-ordination of paging cannot be performed. The network shall then either:

- operate in mode II, meaning that the packet common control channel shall not be allocated in the cell; or

- operate in mode III, meaning that the packet common control channel shall be used for GPRS paging when thepacket paging channel is allocated in the cell.

The network operation mode (mode I, II, or III) shall be indicated as system information to MSs. For proper operation,the mode of operation should be the same in each cell of a routeing area.

Based on the mode of operation provided by the network, the MS can then choose, according to its capabilities, whetherit can attach to GPRS services, to non-GPRS services, or to both.

6.3.4 Non-GPRS Alert

The MSC/VLR may request an SGSN to report activity from a specific MS. In this case, the MSC/VLR shall send aBSSAP+ Alert Request (IMSI) message to the SGSN where the MS is currently GPRS-attached.

Upon reception of the Alert Request (IMSI) message, the SGSN shall set NGAF. If NGAF is set for an MS, the SGSNshall inform the MSC/VLR when the next activity from that MS (and the MS is both IMSI- and GPRS-attached) isdetected, and shall clear NGAF.

If the activity detected by the SGSN leads to a procedure towards the MSC/VLR, the SGSN shall just follow thisprocedure. If the activity detected by the SGSN does not lead to any procedure towards the MSC/VLR, the SGSN shallsend an MS Activity Indication (IMSI) message towards the MSC/VLR.

6.3.5 MS Information Procedure

When the MS is marked at the VLR as both IMSI and GPRS attached, the VLR may perform the MS Informationprocedure via the SGSN. If the information requested by the VLR in the MS Information procedure is known by theSGSN, then the SGSN shall return this information to the VLR without interrogating the MS.

If the information requested is MS identity information (e.g., IMEI) that is not known by the SGSN but is known by theMS, then the SGSN shall interrogate the MS in a similar manner to that described in subclause "Identity CheckProcedures".

The MS Information procedure is illustrated in figure 16. Each step is explained in the following list.

ETSI


BSS SGSN MSC/VLR

1. MS Information Request

MS

2. Identity Request

4. MS Information Response

3. Identity Response

Figure 16: MS Information Procedure

1) The MSC/VLR sends an MS Information Request (IMSI, Information Type) message to the SGSN. InformationType indicates the information that the MSC/VLR is requesting for that IMSI.

2) If the information requested is not known by the SGSN but should be known by the MS, then the SGSNinterrogates the MS in a similar manner to that described in the subclause "Identity Check Procedures". TheSGSN sends an Identity Request (Identity Type) message to the MS.

3) The MS responds with an Identity Response (Mobile Identity) message to the SGSN.

4) The SGSN sends an MS Information Response (IMSI, Information) message to the MSC/VLR. Informationcontains the information requested by the MSC/VLR.

6.3.6 MM Information Procedure

When the MS is marked at the VLR as both IMSI and GPRS attached, the VLR may perform the MM Informationprocedure via the SGSN. The MM Information procedure is typically used to inform the MS about such things as thenetwork name and the local timezone of the mobile.

The MM Information procedure is illustrated in figure 17. Each step is explained in the following list.

BSS SGSN MSC/VLR

1. MM Information

MS

2. MM Information

Figure 17: MM Information Procedure

1) The SGSN receives an MM Information (IMSI, Information) message from the MSC/VLR. Information is theinformation that the MSC/VLR is sending to the MS.

2) The SGSN sends an MM Information (Information) message to the MS including the information received bythe MSC/VLR.

6.4 MM ProceduresThe GPRS and combined GPRS / CS MM procedures in the following subclauses shall use the LLC and RLC/MACprotocols for message transmission across the Um interface. The MM procedures shall provide information to theunderlying layers to enable reliable transmission of MM messages on the Um interface. GSM 03.64 defines themapping between LLC and the radio channels used.

Furthermore, the MM procedures use MAP interfaces between SGSN and HLR (Gr), and between SGSN and EIR (Gf),and a BSSAP+ interface between SGSN and MSC/VLR (Gs).

User data can in general be transmitted during MM signalling procedures. User data transmitted during attach,authentication, and routeing area update procedures may be lost and may therefore have to be retransmitted. In order tominimise the need for retransmission, the MS and SGSN should not transmit user data during the attach, authentication,and routeing area update procedures.

ETSI


6.5 Attach FunctionA GPRS attach is made to the SGSN. A GPRS-attached MS makes IMSI attach via the SGSN with the combined RA /LA update procedure if the network operation mode is I. In network operation modes II and III, or if the MS is notGPRS-attached, then the MS makes IMSI attach as already defined in GSM. An IMSI-attached MS in class-A mode ofoperation engaged in a CS connection shall use the (non-combined) GPRS Attach procedure when it performs a GPRSattach.

In the attach procedure, the MS shall provide its identity and an indication of which type of attach that is to be executed.The identity provided to the network shall be the MS's Packet TMSI (P-TMSI) or IMSI. P-TMSI and the RAIassociated with the P-TMSI shall be provided if the MS has a valid P-TMSI. If the MS does not have a valid P-TMSI,then the MS shall provide its IMSI. The different types of attach are GPRS attach and combined GPRS / IMSI attach.

At the RLC/MAC layer, the MS shall identify itself with a Local or Foreign TLLI if the MS is already GPRS-attachedand is performing an IMSI attach. Otherwise, the MS shall identify itself with a Foreign TLLI, or a Random TLLI if avalid P-TMSI is not available. The Foreign or Random TLLI is used as an identifier during the attach procedure until anew P-TMSI is allocated.

After having executed the GPRS attach, the MS is in READY state and MM contexts are established in the MS and theSGSN. The MS may then activate PDP contexts as described in subclause "Activation Procedures".

An IMSI-attached MS that can only operate in class-C mode of operation shall follow the normal IMSI detachprocedure before it makes a GPRS attach. A GPRS-attached MS in class-C mode of operation shall always perform aGPRS detach before it makes an IMSI attach.

If the network operates in mode I (see subclause "Paging Co-ordination"), then an MS that is both GPRS-attached andIMSI-attached shall perform the Combined RA / LA Update procedures.

If the network operates in mode II or III, then a GPRS-attached MS that has the capability to be simultaneously GPRS-attached and IMSI-attached shall perform the (non-combined) Routeing Area Update procedures, and either:

- access the non-GPRS common control channels for CS operation (the way that CS operation is performed inparallel with GPRS operation is an MS implementation issue outside the scope of the present document); or

- if CS operation is not desired, depending on system information that defines whether or not explicit detach shallbe used, either:

- avoid all CS signalling (in which case the MS may be implicitly IMSI detached after a while); or

- perform an explicit IMSI detach via the non-GPRS common control channels (if the MS was already IMSI-attached).

The Combined GPRS / IMSI Attach procedure is illustrated in figure 18. Each step is explained in the following list.

ETSI


7d. Cancel Location Ack

7c. Cancel Location

7b. Update Location

7g. Update Location Ack

7e. Insert Subscriber Data

7f. Insert Subscriber Data Ack

6d. Insert Subscriber Data

6c. Cancel Location Ack

6b. Cancel Location


2. Identification Response

2. Identification Request

1. Attach Request

5. IMEI Check

3. Identity Request

4. Authentication

6a. Update Location

7a. Location Update Request

7h. Location Update Accept

6f. Update Location Ack

6e. Insert Subscriber Data Ack

MS BSS new SGSN old SGSN GGSN HLREIR

oldMSC/VLR

newMSC/VLR

9. Attach Complete

8. Attach Accept

10. TMSI Reallocation Complete

Figure 18: Combined GPRS / IMSI Attach Procedure

1) The MS initiates the attach procedure by the transmission of an Attach Request (IMSI or P-TMSI and old RAI,Classmark, CKSN, Attach Type, DRX Parameters, old P-TMSI Signature) message to the SGSN. IMSI shall beincluded if the MS does not have a valid P-TMSI available. If the MS has a valid P-TMSI, then P-TMSI and theold RAI associated with P-TMSI shall be included. Classmark contains the MS's GPRS multislot capabilities andsupported GPRS ciphering algorithms in addition to the existing classmark parameters defined in GSM 04.08.Attach Type indicates which type of attach that is to be performed, i.e., GPRS attach only, GPRS Attach whilealready IMSI attached, or combined GPRS / IMSI attach. DRX Parameters indicates whether the MS usesdiscontinuous reception or not. If the MS uses discontinuous reception, then DRX Parameters also indicate whenthe MS is in a non-sleep mode able to receive paging requests and channel assignments. If the MS uses P-TMSIfor identifying itself and if it has also stored its old P-TMSI Signature, then the MS shall include the old P-TMSISignature in the Attach Request message.

ETSI


2) If the MS identifies itself with P-TMSI and the SGSN has changed since detach, the new SGSN sends anIdentification Request (P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to request the IMSI. The oldSGSN responds with Identification Response (IMSI, Authentication Triplets). If the MS is not known in the oldSGSN, the old SGSN responds with an appropriate error cause. The old SGSN also validates the old P-TMSISignature and responds with an appropriate error cause if it does not match the value stored in the old SGSN.

3) If the MS is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type =IMSI) to the MS. The MS responds with Identity Response (IMSI).

4) The authentication functions are defined in the subclause "Security Function". If no MM context for the MSexists anywhere in the network, then authentication is mandatory. Ciphering procedures are described insubclause "Security Function". If P-TMSI allocation is going to be done, and if ciphering is supported by thenetwork, ciphering mode shall be set.

5) The equipment checking functions are defined in the subclause "Identity Check Procedures". Equipmentchecking is optional.

6) If the SGSN number has changed since the GPRS detach, or if it is the very first attach, then the SGSN informsthe HLR:

a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI) to the HLR.

b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set toUpdate Procedure.

c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for thatMS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts.

d) The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new SGSN.

e) The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription restrictions theMS is not allowed to attach in the RA, the SGSN rejects the Attach Request with an appropriate cause, andmay return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If subscriptionchecking fails for other reasons, the SGSN rejects the Attach Request with an appropriate cause and returnsan Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all checks are successful then the SGSNconstructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.

f) The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN afterthe cancelling of old MM context and insertion of new MM context are finished. If the Update Location isrejected by the HLR, the SGSN rejects the Attach Request from the MS with an appropriate cause.

7) If Attach Type in step 1 indicated GPRS Attach while already IMSI attached, or combined GPRS / IMSI attach,then the VLR shall be updated if the Gs interface is installed. The VLR number is derived from the RAinformation. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the firstInsert Subscriber Data message from the HLR in step 6 d). This operation marks the MS as GPRS-attached inthe VLR.

a) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type)message to the VLR. Location Update Type shall indicate IMSI attach if Attach Type indicated combinedGPRS / IMSI attach. Otherwise, Location Update Type shall indicate normal location update. The VLRcreates an association with the SGSN by storing SGSN Number.

b) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR) to the HLR.

c) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old VLR.

d) The old VLR acknowledges with Cancel Location Ack (IMSI).

e) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to thenew VLR.

f) The VLR acknowledges with Insert Subscriber Data Ack (IMSI).

g) After finishing the inter-MSC location update procedures, the HLR responds with Update Location Ack(IMSI) to the new VLR.

ETSI


h) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN.

8) The SGSN selects Radio Priority SMS, and sends an Attach Accept (P-TMSI, VLR TMSI, P-TMSI Signature,Radio Priority SMS) message to the MS. P-TMSI is included if the SGSN allocates a new P-TMSI.

9) If P-TMSI or VLR TMSI was changed, the MS acknowledges the received TMSI(s) by returning an AttachComplete message to the SGSN.

10)If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-allocation by sending a TMSI ReallocationComplete message to the VLR.

If the Attach Request cannot be accepted, the SGSN returns an Attach Reject (IMSI, Cause) message to the MS.

6.6 Detach FunctionThe Detach function allows an MS to inform the network that it wants to make a GPRS and/or IMSI detach, and itallows the network to inform an MS that it has been GPRS-detached or IMSI-detached by the network. The differenttypes of detach are:

- IMSI detach;

- GPRS detach; and

- combined GPRS / IMSI detach (MS-initiated only).

The MS is detached from GPRS either explicitly or implicitly:

- Explicit detach: The network or the MS explicitly requests detach.

- Implicit detach: The network detaches the MS, without notifying the MS, a configuration-dependent time afterthe mobile reachable timer expired, or after an irrecoverable radio error causes disconnection of the logical link.

In the explicit detach case, a Detach Request (Cause) is sent by the SGSN to the MS, or by the MS to the SGSN.

The MS can make an IMSI detach in one of two ways depending on if it is GPRS-attached or not:

- A GPRS-attached MS sends a Detach Request message to the SGSN, indicating an IMSI detach. This can bemade in combination with GPRS detach.

- An MS not attached to the GPRS makes the IMSI detach as already defined in GSM.

In the MO Detach Request message there is an indication to tell if the detach is due to switch off or not. The indicationis needed to know whether a Detach Accept message should be returned or not.

In the network-originated Detach Request message there may be an indication to tell the MS that it is requested toinitiate GPRS Attach and PDP Context Activation procedures for the previously activated PDP contexts.

ETSI


6.6.1 MS-Initiated Detach Procedure

The MS-Initiated Detach procedure when initiated by the MS is illustrated in figure 19. Each step is explained in thefollowing list.

3. IMSI Detach Indication

2. Delete PDP Context Response

1. Detach Request

2. Delete PDP Context Request

5. Detach Accept

MS BSS GGSNSGSN MSC/VLR

4. GPRS Detach Indication

Figure 19: MS-Initiated Combined GPRS / IMSI Detach Procedure

1) The MS detaches by sending Detach Request (Detach Type, Switch Off) to the SGSN. Detach Type indicateswhich type of detach that is to be performed, i.e., GPRS Detach only, IMSI Detach only or combined GPRS andIMSI Detach. Switch Off indicates whether the detach is due to a switch off situation or not.

2) If GPRS detach, the active PDP contexts in the GGSNs regarding this particular MS are deactivated by theSGSN sending Delete PDP Context Request (TID) to the GGSNs. The GGSNs acknowledge with Delete PDPContext Response (TID).

3) If IMSI detach, the SGSN sends IMSI Detach Indication (IMSI) to the VLR.

4) If the MS wants to remain IMSI-attached and is doing a GPRS detach, the SGSN sends a GPRS DetachIndication (IMSI) message to the VLR. The VLR removes the association with the SGSN and handles pagingand location update without going via the SGSN.

5) If Switch Off indicates that the detach is not due to a switch off situation, the SGSN sends a Detach Accept tothe MS.

6.6.2 Network-Initiated Detach Procedure

6.6.2.1 SGSN-Initiated Detach Procedure

The SGSN-Initiated Detach procedure when initiated by the SGSN is illustrated in figure 20. Each step is explained inthe following list.


1. Detach Request


4. Detach Accept

MS BSS GGSNSGSN MSC/VLR


Figure 20: SGSN-Initiated GPRS Detach Procedure

1) The SGSN informs the MS that it has been detached by sending Detach Request (Detach Type) to the MS.Detach Type indicates if the MS is requested to make a new attach and PDP context activation for the previouslyactivated PDP contexts. If so, the attach procedure shall be initiated when the detach procedure is completed.

ETSI


2) The active PDP contexts in the GGSNs regarding this particular MS are deactivated by the SGSN sending DeletePDP Context Request (TID) messages to the GGSNs. The GGSNs acknowledge with Delete PDP ContextResponse (TID) messages.

3) If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach Indication (IMSI) message tothe VLR. The VLR removes the association with the SGSN and handles paging and location update withoutgoing via the SGSN.

4) The MS sends a Detach Accept message to the SGSN any time after step 1.

6.6.2.2 HLR-Initiated Detach Procedure

The HLR-Initiated Detach procedure is initiated by the HLR. The HLR uses this procedure for operator-determinedpurposes to request the removal of a subscriber's MM and PDP contexts at the SGSN. The HLR-Initiated DetachProcedure is illustrated in figure 21. Each step is explained in the following list.

HLRMS BSS GGSNSGSN MSC/VLR


1. Cancel Location


2. Detach Request

6. Cancel Location Ack


5. Detach Accept

Figure 21: HLR-Initiated GPRS Detach Procedure

1) If the HLR wants to request the immediate deletion of a subscriber's MM and PDP contexts from the SGSN, theHLR shall send a Cancel Location (IMSI, Cancellation Type) message to the SGSN with Cancellation Type setto Subscription Withdrawn.

2) The SGSN informs the MS that it has been detached by sending Detach Request (Detach Type) to the MS.Detach Type shall indicate that the MS is not requested to make a new attach and PDP context activation.

3) The active PDP contexts in the GGSNs regarding this particular MS are deactivated by the SGSN sending DeletePDP Context Request (TID) messages to the GGSNs. The GGSNs acknowledge with Delete PDP ContextResponse (TID) messages.

4) If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach Indication (IMSI) message tothe VLR. The VLR removes the association with the SGSN and handles paging and location update withoutgoing via the SGSN.

5) The MS sends a Detach Accept message to the SGSN any time after step 2.

6) The SGSN shall confirm the deletion of the MM and PDP contexts with a Cancel Location Ack (IMSI) message.

6.7 Purge FunctionThe Purge function allows an SGSN to inform the HLR that it has deleted the MM and PDP contexts of a detached MS.The SGSN may, as an implementation option, delete the MM and PDP contexts of an MS immediately after the implicitor explicit detach of the MS. Alternatively, the SGSN may keep for some time the MM and PDP contexts and theauthentication triplets of the detached MS, so that the contexts can be reused at a later GPRS attach without accessingthe HLR.

When the SGSN deletes the MM and PDP contexts, it shall initiate the Purge procedure as illustrated in figure 22. Eachstep is explained in the following list.

ETSI


1. Purge MS

2. Purge MS Ack

SGSN HLR

Figure 22: Purge Procedure

1) After deleting the MM and PDP contexts of a detached MS, the SGSN sends a Purge MS (IMSI) message to theHLR.

2) The HLR sets the MS Purged for GPRS flag and acknowledges with a Purge MS Ack message.

6.8 Security FunctionThe Security function:

- Guards against unauthorised GPRS service usage (authentication and service request validation).

- Provides user identity confidentiality (temporary identification and ciphering).

- Provides user data confidentiality (ciphering).

6.8.1 Authentication of Subscriber

Authentication procedures already defined in GSM shall be used, with the distinction that the procedures are executedfrom the SGSN. The GPRS Authentication procedure performs subscriber authentication, or selection of the cipheringalgorithm and the synchronisation of the start of ciphering, or both. Authentication triplets are stored in the SGSN. TheMSC/VLR shall not authenticate the MS via the SGSN upon IMSI attach, nor location update, but may authenticate theMS during CS connection establishment. Security-related network functions are described in GSM 03.20 [6].

The Authentication procedure is illustrated in figure 23. Each step is explained in the following list.

1. Send Authentication Info

2. Authentication and Ciphering Request

1. Send Authentication Info Ack

2. Authentication and Ciphering Response

MS BSS HLRSGSN

Figure 23: Authentication Procedure

1) If the SGSN does not have previously stored authentication triplets, a Send Authentication Info (IMSI) messageis sent to the HLR. The HLR responds with a Send Authentication Info Ack (Authentication Triplets) message.Each Authentication Triplet includes RAND, SRES, and Kc.

2) The SGSN sends an Authentication and Ciphering Request (RAND, CKSN, Ciphering Algorithm) message tothe MS. The MS responds with an Authentication and Ciphering Response (SRES) message.

The MS starts ciphering after sending the Authentication and Ciphering Response message. The SGSN starts cipheringwhen a valid Authentication and Ciphering Response is received from the MS. In the routeing area update case, ifciphering was used before the routeing area update, and if the Authentication procedure is omitted, then the SGSN shallresume ciphering with the same algorithm when a ciphered Routeing Area Update Accept message is sent, and the MSshall resume ciphering when a ciphered Routeing Area Update Accept message is received.

ETSI


6.8.2 User Identity Confidentiality

A Temporary Logical Link Identity (TLLI) identifies a GPRS user. The relationship between TLLI and IMSI is knownonly in the MS and in the SGSN. TLLI is derived from the P-TMSI allocated by the SGSN or built by the MS asdescribed in subclause "NSAPI and TLLI".

The SGSN may reallocate the P-TMSI at any time when the MS is in READY state. The reallocation procedure can beperformed by the P-TMSI Reallocation procedure, or it can be included in the Attach or Routeing Area Updateprocedures.

6.8.2.1 P-TMSI Signature

P-TMSI Signature is optionally sent by the SGSN to the MS in Attach Accept and Routeing Area Update Acceptmessages. If the P-TMSI Signature has been sent by the SGSN to the MS since the current P-TMSI was allocated, thenthe MS shall include the P-TMSI Signature in the next Routeing Area Update Request and Attach Request foridentification checking purposes. In the Attach and Routeing Area Update procedures, the SGSN shall compare theP-TMSI Signature sent by the MS with the signature stored in the SGSN. If the values do not match, the SGSN shoulduse the security functions to authenticate the MS. If the values match or if the P-TMSI Signature is missing, the SGSNmay use the security functions to authenticate the MS. The P-TMSI Signature parameter has only local significance inthe SGSN that allocated the signature.

If ciphering is supported by the network, the SGSN shall send the P-TMSI Signature ciphered to the MS. Routeing AreaUpdate Request and Attach Request, into which the MS includes the P-TMSI Signature, are not ciphered.

6.8.2.2 P-TMSI Reallocation Procedure

The P-TMSI Reallocation procedure is illustrated in figure 24. Each step is explained in the following list.

2. P-TMSI Reallocation Complete

1. P-TMSI Reallocation Command

MS BSS SGSN

Figure 24: P-TMSI Reallocation Procedure

1) The SGSN sends a P-TMSI Reallocation Command (new P-TMSI, P-TMSI Signature, RAI) message to the MS.P-TMSI Signature is an optional parameter that the MS, if received, shall return to the SGSN in the next Attachand Routeing Area Update procedures.

2) The MS returns a P-TMSI Reallocation Complete message to the SGSN.

6.8.3 User Data and GMM/SM Signalling Confidentiality

6.8.3.1 Scope of Ciphering

In contrast to the scope of ciphering in existing GSM (a single logical channel between BTS and MS), the scope ofGPRS ciphering is from the ciphering function at the SGSN to the ciphering function in the MS.

Ciphering is done in the LLC layer, and from the perspective of the existing GSM MS-BTS radio path, an LLC PDU istransmitted as plain text.

ETSI


MS BTS+BSC SGSN

Scope of GPRS ciphering

Scope of existing GSM ciphering

Figure 25: Scope of GPRS Ciphering

6.8.3.2 GPRS Ciphering Algorithm

A ciphering algorithm to be used for GPRS ciphering shall be selected. A new ciphering algorithm may be designed.GSM 01.61 [2] contains the requirements for the GPRS ciphering algorithm. The TDMA frame number is not known atthe SGSN. Therefore, a Logical Link Control frame number may replace the TDMA frame number as an input to thealgorithm.

The standard key management procedures for the Kc shall be used.

6.8.4 Identity Check Procedures

MS identity check procedures already defined in GSM shall be used, with the distinction that the procedures areexecuted from the SGSN.

The Identity Check procedure is illustrated in figure 26. Each step is explained in the following list.


2. Check IMEI

1. Identity Request

2. Check IMEI Ack

MS BSS EIRSGSN

Figure 26: Identity Check Procedure

1) The SGSN sends Identity Request (Identity Type) to the MS. The MS responds with Identity Response (MobileIdentity).

2) If the SGSN decides to check the IMEI against the EIR, it sends Check IMEI (IMEI) to EIR. The EIR respondswith Check IMEI Ack (IMEI).

6.9 Location Management FunctionThe Location Management function:

- provides mechanisms for cell and PLMN selection;

- provides a mechanism for the network to know the Routeing Area for MSs in STANDBY and READY states;and

- provides a mechanism for the network to know the cell identity for MSs in READY state.

Routeing Area (RA) is defined in subclause "Routeing Area Identity".

ETSI


6.9.1 Location Management Procedures

The PLMN shall provide information for the MS to be able to:

- detect when it has entered a new cell or a new RA; and

- determine when to perform periodic RA updates.

The MS detects that a new cell has been entered by comparing the cell's identity with the cell identity stored in the MS'sMM context. The MS detects that a new RA has been entered by periodically comparing the RAI stored in its MMcontext with that received from the new cell. The MS shall consider hysteresis in signal strength measurements.

When the MS camps on a new cell, possibly in a new RA, this indicates one of three possible scenarios:

- a cell update is required;

- a routeing area update is required; or

- a combined routeing area and location area update is required.

In all three scenarios the MS stores the cell identity in its MM context.

If the MS enters a new PLMN, the MS shall either perform a routeing area update, or enter IDLE state.

In network mode of operation II and III, whenever an MS determines that it shall perform both an LA update and an RAupdate, the MS shall perform the LA update first.

Routeing Area Update Request messages shall be sent unciphered, since in the inter SGSN routeing area update case thenew SGSN shall be able to process the request.

6.9.1.1 Cell Update Procedure

A cell update takes place when the MS enters a new cell inside the current RA and the MS is in READY state. If theRA has changed, a routeing area update is executed instead of a cell update.

The MS performs the cell update procedure by sending an uplink LLC frame of any type containing the MS's identity tothe SGSN. In the direction towards the SGSN, the BSS shall add the Cell Global Identity including RAC and LAC to allBSSGP frames, see GSM 08.18. A cell update is any correctly received and valid LLC PDU carried inside a BSSGPPDU containing a new identifier of the cell.

The SGSN records this MS's change of cell, and further traffic directed towards the MS is conveyed over the new cell.

6.9.1.2 Routeing Area Update Procedure

A routeing area update takes place when a GPRS-attached MS detects that it has entered a new RA, when the periodicRA update timer has expired, or when a suspended MS is not resumed by the BSS (see subclause "Suspension of GPRSServices"). The SGSN detects that it is an intra SGSN routeing area update by noticing that it also handles the old RA.In this case, the SGSN has the necessary information about the MS and there is no need to inform the GGSNs or theHLR about the new MS location. A periodic RA update is always an intra SGSN routeing area update.

An MS in READY state due to anonymous access shall not perform routeing area updates for the AA MM context. Ifthe MS has entered a new routeing area, a new Anonymous Access PDP Context Activation procedure shall beinitiated. The old context is implicitly deleted upon expiry of the READY timer.

ETSI


6.9.1.2.1 Intra SGSN Routeing Area Update

The Intra SGSN Routeing Area Update procedure is illustrated in figure 27. Each step is explained in the following list.

1. Routeing Area Update Request

3. Routeing Area Update Accept

2. Security Functions

MS BSS SGSN

4. Routeing Area Update Complete

Figure 27: Intra SGSN Routeing Area Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the SGSN.Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Global Identityincluding the RAC and LAC of the cell where the message was received before passing the message to theSGSN, see GSM 08.18.

2) Security functions may be executed. These procedures are defined in subclause "Security Function".

3) The SGSN validates the MS's presence in the new RA. If due to regional subscription restrictions the MS is notallowed to be attached in the RA, or if subscription checking fails, then the SGSN rejects the routeing areaupdate with an appropriate cause. If all checks are successful then the SGSN updates the MM context for theMS. A new P-TMSI may be allocated. A Routeing Area Update Accept (P-TMSI, P-TMSI Signature) is returnedto the MS.

4) If P-TMSI was reallocated, the MS acknowledges the new P-TMSI by returning a Routeing Area UpdateComplete message to the SGSN.

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a RouteingArea Update Reject (Cause) message, the MS shall enter IDLE state.

ETSI


6.9.1.2.2 Inter SGSN Routeing Area Update

The Inter SGSN Routeing Area Update procedure is illustrated in figure 28. Each step is explained in the following list.

MS BSS new SGSN HLRGGSNold SGSN

2. SGSN Context Response



2. SGSN Context Request

6. Update PDP Context Request

6. Update PDP Context Response

7. Update Location

10. Update Location Ack


8. Cancel Location


9. Insert Subscriber Data Ack

9. Insert Subscriber Data


5. Forward Packets

4. SGSN Context Acknowledge

Figure 28: Inter SGSN Routeing Area Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the newSGSN. Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Global Identityincluding the RAC and LAC of the cell where the message was received before passing the message to theSGSN.

2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) tothe old SGSN to get the MM and PDP contexts for the MS. The old SGSN validates the old P-TMSI Signatureand responds with an appropriate error cause if it does not match the value stored in the old SGSN. This shouldinitiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the newSGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message tothe old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSISignature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigningSNDCP N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MMContext, PDP Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriateerror cause. The old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to thenew SGSN. Each PDP Context includes the SNDCP Send N-PDU Number for the next downlink N-PDU to besent in acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink N-PDU to bereceived in acknowledged mode from the MS, the GTP sequence number for the next downlink N-PDU to besent to the MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. The oldSGSN starts a timer and stops the transmission of N-PDUs to the MS.

3) Security functions may be executed. These procedures are defined in subclause "Security Function". Cipheringmode shall be set if ciphering is supported.

ETSI


4) The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSNthat the new SGSN is ready to receive data packets belonging to the activated PDP contexts. The old SGSNmarks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid.This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area updateprocedure back to the old SGSN before completing the ongoing routeing area update procedure. If the securityfunctions do not authenticate the MS correctly, then the routeing area update shall be rejected, and the newSGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN ContextRequest was never received.

5) The old SGSN duplicates the buffered N-PDUs and starts tunnelling them to the new SGSN. Additional N-PDUsreceived from the GGSN before the timer described in step 2 expires are also duplicated and tunnelled to the newSGSN. N-PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged bythe MS are tunnelled together with the SNDCP N-PDU number. No N-PDUs shall be forwarded to the newSGSN after expiry of the timer described in step 2.

6) The new SGSN sends Update PDP Context Request (new SGSN Address, TID, QoS Negotiated) to the GGSNsconcerned. The GGSNs update their PDP context fields and return Update PDP Context Response (TID).

7) The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSNAddress, IMSI) to the HLR.

8) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set toUpdate Procedure. If the timer described in step 2 is not running, then the old SGSN removes the MM and PDPcontexts. Otherwise, the contexts are removed only when the timer expires. This allows the old SGSN tocomplete the forwarding of N-PDUs. It also ensures that the MM and PDP contexts are kept in the old SGSN incase the MS initiates another inter SGSN routeing area update before completing the ongoing routeing areaupdate to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI).

9) The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new SGSN. The new SGSNvalidates the MS's presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed tobe attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause, and mayreturn an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If all checks aresuccessful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack(IMSI) message to the HLR.

10)The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.

11)The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowedto be attached in the SGSN, or if subscription checking fails, then the new SGSN rejects the routeing area updatewith an appropriate cause. If all checks are successful then the new SGSN constructs MM and PDP contexts forthe MS. A logical link is established between the new SGSN and the MS. The new SGSN responds to the MSwith Routeing Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU Number). Receive N-PDUNumber contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, therebyconfirming all mobile-originated N-PDUs successfully transferred before the start of the update procedure.

12)The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete (Receive N-PDUNumber) message to the SGSN. Receive N-PDU Number contains the acknowledgements for eachacknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfullytransferred before the start of the update procedure. If Receive N-PDU Number confirms reception of N-PDUsthat were forwarded from the old SGSN, then these N-PDUs shall be discarded by the new SGSN. LLC andSNDCP in the MS are reset.

In the case of a rejected routeing area update operation, due to regional subscription or roaming restrictions, the newSGSN shall not construct an MM context. A reject shall be returned to the MS with an appropriate cause. The MS shallnot re-attempt a routeing area update to that RA. The RAI value shall be deleted when the MS is powered-up.

If the SGSN is unable to update the PDP context in one or more GGSNs, then the SGSN shall deactivate thecorresponding PDP contexts as described in subclause "PDP Context Deactivation Initiated by SGSN Procedure". Thisshall not cause the SGSN to reject the routeing area update.

If the timer described in step 2 expires and no Cancel Location (IMSI) was received from the HLR, then the old SGSNshall stop forwarding N-PDUs to the new SGSN.

ETSI



6.9.1.3 Combined RA / LA Update Procedure

A combined RA / LA update takes place in network operation mode I when the MS enters a new RA or when a GPRS-attached MS performs IMSI attach. The MS sends a Routeing Area Update Request indicating that an LA update mayalso need to be performed, in which case the SGSN forwards the LA update to the VLR. This concerns only idle mode(see GSM 03.22), as no combined RA / LA updates are performed during a CS connection.

6.9.1.3.1 Combined Intra SGSN RA / LA Update

The Combined RA / LA Update (intra SGSN) procedure is illustrated in figure 29. Each step is explained in thefollowing list.

4b. Cancel Location




HLRMS BSS

newMSC/VLRSGSN

oldMSC/VLR

3. Location Update Request



4a. Update Location




5. Location Update Accept


Figure 29: Combined RA / LA Update in the Case of Intra SGSN RA Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the SGSN.Update Type shall indicate combined RA / LA update, or, if the MS wants to perform an IMSI attach, combinedRA / LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC andLAC of the cell where the message was received before passing the message to the SGSN.

2) Security functions may be executed. This procedure is defined in subclause "Security Function".

3) If the association has to be established, if Update Type indicates combined RA / LA update with IMSI attachrequested, or if the LA changed with the routeing area update, then the SGSN sends a Location Update Request(new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSIattach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested. Otherwise,Location Update Type shall indicate normal location update. The VLR number is translated from the RAI via atable in the SGSN. The VLR creates or updates the association with the SGSN by storing SGSN Number.

ETSI


4) If the subscriber data in the VLR is marked as not confirmed by the HLR, then the new VLR informs the HLR.The HLR cancels the data in the old VLR and inserts subscriber data in the new VLR (this signalling is notmodified from existing GSM signalling and is included here for illustrative purposes):

a) The new VLR sends an Update Location (new VLR) to the HLR.

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.

c) The old VLR acknowledges with Cancel Location Ack (IMSI).

d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).

f) The HLR responds with Update Location Ack (IMSI) to the new VLR.

5) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to theSGSN. VLR TMSI is optional if the VLR has not changed.

6) The SGSN validates the MS's presence in the new RA. If due to regional subscription restrictions the MS is notallowed to be attached in the RA, or if subscription checking fails, then the SGSN rejects the routeing areaupdate with an appropriate cause. If all checks are successful then the SGSN updates the MM context for theMS. A new P-TMSI may be allocated. The SGSN responds to the MS with Routeing Area Update Accept(P-TMSI, VLR TMSI, P-TMSI Signature).

7) If a new P-TMSI or VLR TMSI was received, then the MS confirms the reallocation of the TMSIs by returning aRouteing Area Update Complete message to the SGSN.

8) The SGSN sends a TMSI Reallocation Complete message to the VLR if the VLR TMSI is confirmed by the MS.


If the Location Update Accept message indicates a reject, then this should be indicated to the MS, and the MS shall notaccess non-GPRS services until a successful Location Update is performed.

ETSI


6.9.1.3.2 Combined Inter SGSN RA / LA Update

The Combined RA / LA Update (inter SGSN) procedure is illustrated in figure 30. Each step is explained in thefollowing list.

12b. Cancel Location





13. Location Update Accept



8. Cancel Location




7. Update Location

10. Update Location Ack

12a. Update Location

11. Location Update Request

2. SGSN Context Response


2. SGSN Context Request





MS BSS GGSNold SGSNnew SGSN HLR

newMSC/VLR

oldMSC/VLR

5. Forward Packets

4. SGSN Context Acknowledge

Figure 30: Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure

1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the newSGSN. Update Type shall indicate combined RA / LA update, or, if the MS wants to perform an IMSI attach,combined RA / LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including theRAC and LAC of the cell where the message was received before passing the message to the SGSN.

ETSI


2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) tothe old SGSN to get the MM and PDP contexts for the MS. The old SGSN validates the old P-TMSI Signatureand responds with an appropriate error cause if it does not match the value stored in the old SGSN. This shouldinitiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the newSGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message tothe old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSISignature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigningSNDCP N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MMContext, PDP Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriateerror cause. The old SGSN stores New SGSN Address until the old MM context is cancelled, to allow the oldSGSN to forward data packets to the new SGSN. Each PDP Context includes the SNDCP Send N-PDU Numberfor the next downlink N-PDU to be sent in acknowledged mode to the MS, the SNDCP Receive N-PDU Numberfor the next uplink N-PDU to be received in acknowledged mode from the MS, the GTP sequence number forthe next downlink N-PDU to be sent to the MS and the GTP sequence number for the next uplink N-PDU to betunnelled to the GGSN. The old SGSN starts a timer and stops the downlink transfer.

3) Security functions may be executed. These procedures are defined in subclause "Security Function". Cipheringmode shall be set if ciphering is supported.

4) The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSNthat the new SGSN is ready to receive data packets belonging to the activated PDP contexts. The old SGSNmarks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid.This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area updateprocedure back to the old SGSN before completing the ongoing routeing area update procedure. If the securityfunctions do not authenticate the MS correctly, then the routeing area update shall be rejected, and the newSGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN ContextRequest was never received.

5) The old SGSN duplicates the buffered N-PDUs and starts tunnelling them to the new SGSN. Additional N-PDUsreceived from the GGSN before the timer described in step 2 expires are also duplicated and tunnelled to the newSGSN. N-PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged bythe MS are tunnelled together with the SNDCP N-PDU number. No N-PDUs shall be forwarded to the newSGSN after expiry of the timer described in step 2.

6) The new SGSN sends Update PDP Context Request (new SGSN Address, TID, QoS Negotiated) to the GGSNsconcerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (TID).

7) The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSNAddress, IMSI) to the HLR.

8) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set toUpdate Procedure. If the timer described in step 2 is not running, then the old SGSN removes the MM and PDPcontexts. Otherwise, the contexts are removed only when the timer expires. This allows the old SGSN tocomplete the forwarding of N-PDUs. It also ensures that the MM and PDP contexts are kept in the old SGSN incase the MS initiates another inter SGSN routeing area update before completing the ongoing routeing areaupdate to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI).

9) The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new SGSN. The new SGSNvalidates the MS's presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed tobe attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause, and mayreturn an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If all checks aresuccessful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack(IMSI) message to the HLR.

10)The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.

11)If the association has to be established, if Update Type indicates combined RA / LA update with IMSI attachrequested, or if the LA changed with the routeing area update, then the new SGSN sends a Location UpdateRequest (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shallindicate IMSI attach if Update Type in step 1 indicated combined RA / LA update with IMSI attach requested.Otherwise, Location Update Type shall indicate normal location update. The VLR number is translated from theRAI via a table in the SGSN. The SGSN starts the location update procedure towards the new MSC/VLR uponreceipt of the first Insert Subscriber Data message from the HLR in step 9). The VLR creates or updates theassociation with the SGSN by storing SGSN Number.

ETSI


12)If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. TheHLR cancels the old VLR and inserts subscriber data in the new VLR (this signalling is not modified fromexisting GSM signalling and is included here for illustrative purposes):

a) The new VLR sends an Update Location (new VLR) to the HLR.

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.

c) The old VLR acknowledges with Cancel Location Ack (IMSI).

d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).

f) The HLR responds with Update Location Ack (IMSI) to the new VLR.

13)The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN.VLR TMSI is optional if the VLR has not changed.

14)The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowedto be attached in the SGSN, or if subscription checking fails, then the SGSN rejects the routeing area update withan appropriate cause. If all checks are successful then the new SGSN establishes MM and PDP contexts for theMS. A logical link is established between the new SGSN and the MS. The new SGSN responds to the MS withRouteing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature, Receive N-PDU Number). ReceiveN-PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, therebyconfirming all mobile-originated N-PDUs successfully transferred before the start of the update procedure.

15)The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete (ReceiveN-PDU Number) message to the SGSN. Receive N-PDU Number contains the acknowledgements for eachacknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfullytransferred before the start of the update procedure. If Receive N-PDU Number confirms reception of N-PDUsthat were forwarded from the old SGSN, then these N-PDUs shall be discarded by the new SGSN. LLC andSNDCP in the MS are reset.

16)The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the VLR TMSI is confirmedby the MS.

In the case of a rejected routeing area update operation, due to regional subscription or roaming restrictions, the newSGSN shall not construct an MM context. A reject shall be returned to the MS with an appropriate cause. The MS shallnot re-attempt a routeing area update to that RA. The RAI value shall be deleted when the MS is powered-up.

If the SGSN is unable to update the PDP context in one or more GGSNs, then the SGSN shall deactivate thecorresponding PDP contexts as described in subclause "PDP Context Deactivation Initiated by SGSN Procedure". Thisshall not cause the SGSN to reject the routeing area update.


If the timer described in step 2 expires and no Cancel Location (IMSI) was received from the HLR, then the old SGSNshall stop forwarding N-PDUs to the new SGSN.

If the Location Update Accept message indicates a reject, then this should be indicated to the MS, and the MS shall notaccess non-GPRS services until a successful location update is performed.

ETSI


6.9.1.4 Periodic RA and LA Updates

All GPRS-attached MSs, except MSs in class-B mode of operation engaged in CS communication, shall performperiodic RA updates. MSs that are IMSI-attached and not GPRS-attached shall perform periodic LA updates. PeriodicRA updates are equivalent to intra SGSN routeing area updates as described in subclause "Intra SGSN Routeing AreaUpdate", with Update Type indicating periodic RA update. For MSs that are both IMSI-attached and GPRS-attached,the periodic updates depend on the mode of operation of the network.

- If the network operates in mode I, periodic RA updates shall be performed, and periodic LA updates shall not beperformed. In this case, the MSC/VLR shall disable implicit detach for GPRS-attached MSs and instead rely onthe SGSN to receive periodic RA updates. If periodic RA updates are not received in the SGSN and the SGSNdetaches the MS, the SGSN shall notify the MSC/VLR by sending an IMSI Detach Indication message.

- If the network operates in mode II or mode III, both periodic RA updates and periodic LA updates shall beperformed independently. RA updates are performed via the Gb interface, and LA updates are performed via theA interface.

The periodic RA update timer in the MS is stopped when an LLC PDU is sent since all sent LLC PDUs set the MMcontext state to READY. The periodic RA update timer is reset and started when the state returns to STANDBY.

If the MS could not successfully complete the periodic RA update procedure after a retry scheme while the MS was inGPRS coverage, then the MS shall wait a backoff time equal to the periodic LA update timer broadcast by the networkbefore re-starting the periodic RA update procedure.

6.10 Subscriber Management FunctionThe Subscriber Management function provides a mechanism to inform the GPRS nodes about changes of the GPRSsubscription data for a specific GPRS subscriber.

6.10.1 Subscriber Management Procedures

Whenever the GPRS subscription data is changed for a GPRS subscriber in the HLR, and the changes affect the GPRSsubscription data stored in the SGSN, then the SGSN node shall be informed about these changes by means of thefollowing procedures:

- Insert Subscriber Data procedure, used to add or modify GPRS subscription data in the SGSN; or

- Delete Subscriber Data procedure, used to remove GPRS subscription data in the SGSN.

6.10.1.1 Insert Subscriber Data Procedure

In addition to the insertion and modification of general GPRS subscription data for a GPRS subscriber, see GSM 09.02,the HLR may request the insertion or modification of one or several new or existing PDP contexts in the SGSN. Itshould be noted that the modification may trigger a PDP Context Modification procedure as described in subclause"Modification Procedures". In particular, the following PDP context parameters may be modified by the HLR:

- QoS Profile Subscribed; and

- VPLMN Address Allowed.

The Insert Subscriber Data procedure is illustrated in figure 31. Each step is explained in the following list.



SGSN HLR

Figure 31: Insert Subscriber Data Procedure

1) The HLR sends an Insert Subscriber Data (IMSI, GPRS Subscription Data) message to the SGSN.

ETSI


2) The SGSN updates its GPRS subscription data and acknowledges the Insert Subscriber Data message byreturning an Insert Subscriber Data Ack (IMSI) message. For each PDP context that is included in GPRSSubscription Data the SGSN shall check whether it is a new, an active, or an inactive PDP context:

- For a new or inactive PDP context, no further action is required except storage in the SGSN.

- For an active PDP context, the SGSN shall in addition compare the new QoS Subscribed with QoSNegotiated and shall, if necessary, initiate a PDP Context Modification procedure as described in subclause"Modification Procedures". Furthermore, if VPLMN Address Allowed is changed, the SGSN shall, ifnecessary (e.g., if the PDP context is currently routed via a GGSN in the VPLMN and VPLMN AddressAllowed is changed to not allowed), initiate a PDP Context Deactivation procedure as explained in subclause"Deactivation Procedures".

6.10.1.2 Delete Subscriber Data Procedure

In addition to the deletion of general GPRS subscription data for a GPRS subscriber, see GSM 09.02, the HLR mayrequest the deletion of one or several PDP contexts from the SGSN.

The Delete Subscriber Data procedure is illustrated in figure 32. Each step is explained in the following list.

1. Delete Subscriber Data

2. Delete Subscriber Data Ack

SGSN HLR

Figure 32: Delete Subscriber Data Procedure

1) The HLR sends a Delete Subscriber Data (IMSI, PDP Context Identifiers List) message to the SGSN.

2) The SGSN acknowledges the Delete Subscriber Data message by returning a Delete Subscriber Data Ack (IMSI)message. For each PDP context identifier included in PDP Context Identifiers List, the SGSN shall checkwhether it belongs to an active or an inactive PDP context:

- for an inactive PDP context no further action is required except deletion of the PDP context;

- for an active PDP context, the SGSN shall initiate the PDP Context Deactivation Initiated by SGSNprocedure as explained in subclause "Deactivation Procedures" before the PDP context is deleted.

6.11 Classmark HandlingTo support efficient radio interface usage in GPRS, the MS classmark is handled differently for SGSN-based servicesthan for MSC-based services. In particular, the classmark is sent in MM messages to the network and stored in thenetwork as long as the MS is GPRS-attached, avoiding redundant classmark retransmissions over the radio interface.This is sometimes called the "idle-mode classmark" principle.

In order to allow introduction of new radio access technologies in the future, the MS classmark is split into two distinctand independent information elements, the radio access classmark, and the SGSN classmark.

6.11.1 Radio Access Classmark

The radio access classmark contains the radio capabilities of the MS (e.g., multislot capability, power class), and moregenerally all the information that should be known by the BSS in order to handle radio resources for that MS.

ETSI


The radio access classmark is a container for a multiplicity of radio access technology-dependent information,i.e., within the radio access classmark there are independent sub-fields for various technologies such as GSM 900,GSM 1800, Satellite, UMTS, etc. The coding shall allow a BSS to extract only the sub-fields relevant to it withoutinterpreting the other sub-fields. This ensures that the radio classmark does not need to be interpreted by the NSS, andthe full radio classmark is always sent by the MS to the SGSN, and thereafter provided to the BSS irrespective of theactual BSS capabilities.

The SGSN shall provide the radio access classmark as an information element on the Gb interface. It is theresponsibility of the SGSN to provide the BSS with the most recent classmark received from the MS. The classmarkinformation element can be included in a downlink transfer request, or be sent in a specific message that updates theradio classmark information in the BSS. The BSS may at any time request the radio classmark for a given MS to betransmitted from the SGSN to the BSS.

A specific optimisation allows the BSS to receive a reduced radio access classmark at initial access directly from theMS. This enables the BSS not to wait for the full radio access classmark to be provided by the SGSN, and is thereforequicker for the initial MS-originated transmission. The reduced classmark can be carried is several RR messagesdepending on the access method, e.g., in the initial random access message, or in the first uplink radio block. Details areprovided in GSM 04.08 and GSM 04.60.

6.11.2 SGSN Classmark

The SGSN classmark contains non radio-related capabilities, e.g., the ciphering capability. The SGSN stores the SGSNclassmark which is used both locally by the SGSN and for transfer to the new SGSN at all types of inter SGSN RAupdate.

7 Network Management FunctionalityThe Network Management function provides mechanisms to support O&M functions related to GPRS.

8 Radio Resource Functionality

8.1 Cell Selection and ReselectionAn MS (in any mode of operation (A, B, or C)) cannot camp on more than one cell. If the MS is in idle mode, seeGSM 03.22, then it shall use cell selection and reselection procedures as described in GSM 03.64 and specified inGSM 03.22 and GSM 05.08 [15].

8.2 Discontinuous ReceptionA GPRS MS may be able to choose if it wants to use discontinuous reception (DRX) or not. If using DRX, the MS shallalso be able to specify other DRX parameters that indicate the delay for the network to send a page request or a channelassignment to the MS (see GSM 03.64).

The DRX parameters shall be indicated by the MS in the attach procedure. The SGSN shall then in each page requestsend these parameters to the BSS that uses this information and the IMSI to calculate the correct paging group.

DRX usage is independent of the MM states IDLE, STANDBY and READY. As DRX can be used by a GPRS MS inREADY state, DRX has to be considered also when assigning a packet data channel for downlink transfer. The SGSNshall therefore indicate the DRX parameters for the MS in all packet transmission requests to the BSS.

A GPRS MS shall not apply DRX in READY state during the GPRS attach and routeing area update procedures.

8.3 Radio Resource ManagementGSM Radio Resource Management functions are defined in GSM 04.07 [10]. The radio interface layer 3 protocol isspecified in GSM 04.08.

ETSI


8.3.1 Layer Functions

GPRS radio resource management procedures are required for the following functions:

- allocation and release of physical resources (i.e., timeslots) associated with a GPRS channel;

- monitoring GPRS channel utilisation to detect under-utilised or congested GPRS channels;

- initiating congestion control procedures; and

- distribution of GPRS channel configuration information for broadcasting to the MSs.

8.3.2 Model of Operation

8.3.2.1 Dynamic Allocation of Radio Resources

A cell may or may not support GPRS.

A cell supporting GPRS may have GPRS radio resources allocated at a given instance. If no GPRS radio resources areallocated, an MS can request allocation of such resources. MSs may then use these radio resources. The PLMN maydynamically increase, to a PLMN operator-defined maximum, or, decrease to an operator-defined minimum, the radioresources allocated.

The network broadcasts GPRS system information on the common control channels.

GSM radio resources are dynamically shared between GPRS and other GSM services.

8.4 Paging for GPRS Downlink TransferAn MS in STANDBY state is paged by the SGSN before a downlink transfer to that MS. The paging procedure shallmove the MM state to READY to allow the SGSN to forward downlink data to the radio resource. Therefore, anyuplink data from the MS that moves the MM context at the SGSN to READY state is a valid response to paging.

The SGSN supervises the paging procedure with a timer. If the SGSN receives no response from the MS to the PagingRequest message, it shall repeat the paging. The repetition strategy is implementation dependent.

The MS shall accept pages also in READY state if no radio resource is assigned. This supports recovery frominconsistent MM states in MS and SGSN.

The GPRS Paging procedure is illustrated in figure 33. Each step is explained in the following list.

5. Any LLC Frame

4. Any LLC Frame

3. GPRS Paging Request

2. Paging Request

1. PDP PDU

MS BSS SGSN

Figure 33: GPRS Paging Procedure

1) The SGSN receives a downlink PDP PDU for an MS in STANDBY state. Downlink signalling to a STANDBYstate MS initiates paging as well.

ETSI


2) The SGSN sends a BSSGP Paging Request (IMSI, P-TMSI, Area, Channel Needed, QoS, DRX Parameters)message to the BSS serving the MS. IMSI is needed by the BSS in order to calculate the MS paging group.P-TMSI is the identifier by which the MS is paged. Area indicates the routeing area in which the MS is paged.Channel Needed indicates GPRS paging. QoS is the negotiated QoS for the PDP context that initiates the pagingprocedure, and indicates the priority of this Paging Request relative to other Paging Request messages bufferedin the BSS. DRX Parameters indicates whether the MS uses discontinuous reception or not. If the MS usesdiscontinuous reception, then DRX Parameters also indicate when the MS is in a non-sleep mode able to receivepaging requests.

3) The BSS pages the MS with one Paging Request (P-TMSI, Channel Needed) message in each cell belonging tothe addressed routeing area. This is described in GSM 03.64.

4) Upon receipt of a GPRS Paging Request message, the MS shall respond with either any single valid LLC frame(e.g., a Receive Ready or Information frame) that implicitly is interpreted as a page response message by theSGSN. When responding, the MS changes MM state to READY. The response is preceded by the PacketChannel Request and Packet Immediate Assignment procedures as described in GSM 03.64.

5) Upon reception of the LLC frame, the BSS adds the Cell Global Identity including the RAC and LAC of the celland sends the LLC frame to the SGSN. The SGSN shall then consider the LLC frame to be an implicit pagingresponse message and stop the paging response timer.

9 Packet Routeing and Transfer Functionality

9.1 Definition of Packet Data Protocol StatesA GPRS subscription contains the subscription of one or more PDP addresses. Each PDP address is described by anindividual PDP context in the MS, the SGSN, and the GGSN. Every PDP context exists independently in one of twoPDP states. The PDP state indicates whether the PDP address is activated for data transfer or not. Activation anddeactivation are described in subclause "PDP Context Activation, Modification, and Deactivation Functions". All PDPcontexts of a subscriber are associated with the same MM context for the IMSI of that subscriber.

9.1.1 INACTIVE State

The INACTIVE state characterises the data service for a certain PDP address of the subscriber as not activated. ThePDP context contains no routeing or mapping information to process PDP PDUs related to that PDP address. No datacan be transferred. A changing location of a subscriber causes no update for the PDP context in INACTIVE state even ifthe subscriber is attached to the GPRS MM.

Mobile-terminated PDP PDUs received in INACTIVE state by the GGSN may initiate the Network-Requested PDPContext Activation procedure if the GGSN is allowed to initiate the activation of the PDP context for that PDP address.Otherwise, mobile-terminated PDP PDUs received in INACTIVE state invoke error procedures in the GGSN relevantto the external network protocol, for example, an IP packet is discarded and an ICMP (see RFC 792 [41]) packet (errornotification) is returned to the source of the received packet. Other error procedures may be introduced on theapplication level, but this is outside the scope of the present document.

The MS initiates the movement from INACTIVE to ACTIVE state by initiating the PDP Context Activation procedure.

9.1.2 ACTIVE State

In ACTIVE state, the PDP context for the PDP address in use is activated in MS, SGSN and GGSN. The PDP contextcontains mapping and routeing information for transferring PDP PDUs for that particular PDP address between MS andGGSN. The PDP state ACTIVE is permitted only when the mobility management state of the subscriber is STANDBYor READY.

An active PDP context for an MS is moved to INACTIVE state when the deactivation procedure is initiated.

All active PDP contexts for an MS are moved to INACTIVE state when the MM state changes to IDLE.

ETSI


Deactivate PDP Contextor

MM state change to IDLE

Activate PDPContext

INACTIVE

ACTIVE

Figure 34: Functional PDP State Model

9.2 PDP Context Activation, Modification, and DeactivationFunctions

These functions are only meaningful at the NSS level and in the MS, and do not directly involve the BSS. An MS inSTANDBY or READY state can initiate these functions at any time to activate or deactivate 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. AGGSN may initiate the deactivation of a PDP context.

Upon receiving an Activate PDP Context Request message, the SGSN shall initiate procedures to set up PDP contexts.Upon receiving a Deactivate PDP Context Request message, the SGSN shall initiate procedures to deactivate PDPcontexts.

An MS does not have to receive the (De-)Activate PDP Context Accept message before issuing another (De-)ActivatePDP Context Request. However, only one request can be outstanding for every NSAPI.

9.2.1 Static and Dynamic PDP Addresses

PDP addresses can be allocated to an MS in three different ways:

- 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 PDPaddress); or

- the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDPaddress).

It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can beused.

For every IMSI, zero, one, or more dynamic PDP address per PDP type can be assigned. For every IMSI, zero, one, ormore static PDP addresses per PDP type can be subscribed to.

When dynamic addressing is used, it is the responsibility of the GGSN to allocate and release the dynamic PDP address.

Only static PDP addressing is applicable in the network-requested PDP context activation case.

ETSI


9.2.2 Activation Procedures

9.2.2.1 PDP Context Activation Procedure

The PDP Context Activation procedure is illustrated in figure 35. Each step is explained in the following list.

GGSN

4. Activate PDP Context Accept

3. Create PDP Context Response

3. Create PDP Context Request

1. Activate PDP Context Request

SGSNMS


Figure 35: PDP Context Activation Procedure

1) The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name,QoS Requested, PDP Configuration Options) message to the SGSN. The MS shall use PDP Address to indicatewhether it requires the use of a static PDP address or whether it requires the use of a dynamic PDP address. TheMS shall leave PDP Address empty to request a dynamic PDP address. The MS may use Access Point Name toselect a reference point to a certain external network. Access Point Name is a logical name referring to theexternal packet data network that the subscriber wishes to connect to. QoS Requested indicates the desired QoSprofile. PDP Configuration Options may be used to request optional PDP parameters from the GGSN (seeGSM 09.60). PDP Configuration Options is sent transparently through the SGSN.


3) The SGSN validates the Activate PDP Context Request using PDP Type (optional), PDP Address (optional), andAccess Point Name (optional) provided by the MS and the PDP context subscription records. The validationcriteria, the APN selection criteria, and the mapping from APN to a GGSN are described in annex A.

If no GGSN address can be derived or if the SGSN has determined that the Activate PDP Context Request is notvalid according to the rules described in annex A, then the SGSN rejects the PDP context activation request.

ETSI


If a GGSN address can be derived, the SGSN creates a TID for the requested PDP context by combining theIMSI stored in the MM context with the NSAPI received from the MS. If the MS requests a dynamic address,then the SGSN lets a GGSN allocate the dynamic address. The SGSN may restrict the requested QoS attributesgiven its capabilities, the current load, and the subscribed QoS profile. The SGSN sends a Create PDP ContextRequest (PDP Type, PDP Address, Access Point Name, QoS Negotiated, TID, MSISDN, Selection Mode, PDPConfiguration Options) message to the affected GGSN. Access Point Name shall be the APN Network Identifierof the APN selected according to the procedure described in annex A. PDP Address shall be empty if a dynamicaddress is requested. The GGSN may use Access Point Name to find an external network. Selection Modeindicates whether a subscribed APN was selected, or whether a non-subscribed APN sent by MS or a non-subscribed APN chosen by SGSN was selected. Selection Mode is set according to annex A. The GGSN mayuse Selection Mode when deciding whether to accept or reject the PDP context activation. For example, if anAPN requires subscription, then the GGSN is configured to accept only the PDP context activation that requestsa subscribed APN as indicated by the SGSN with Selection Mode. The GGSN creates a new entry in its PDPcontext table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs between theSGSN and the external PDP network, and to start charging. The GGSN may further restrict QoS Negotiatedgiven its capabilities and the current load. The GGSN then returns a Create PDP Context Response (TID, PDPAddress, Reordering Required, PDP Configuration Options, QoS Negotiated, Charging Id, Cause) message tothe SGSN. PDP Address is included if the GGSN allocated a PDP address. Reordering Required indicateswhether the SGSN shall reorder N-PDUs before delivering the N-PDUs to the MS. PDP Configuration Optionscontain optional PDP parameters that the GGSN may transfer to the MS. These optional PDP parameters may berequested by the MS in the Activate PDP Context Request message, or may be sent unsolicited by the GGSN.PDP Configuration Options is sent transparently through the SGSN. The Create PDP Context messages are sentover the GPRS backbone network.

If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated (e.g., thereliability class is insufficient to support the PDP type), then the GGSN rejects the Create PDP Context Requestmessage. The compatible QoS profiles are configured by the GGSN operator.

4) The SGSN inserts the NSAPI along with the GGSN address in its PDP context. If the MS has requested adynamic address, the PDP address received from the GGSN is inserted in the PDP context. The SGSN selectsRadio Priority based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address,TI, QoS Negotiated, Radio Priority, PDP Configuration Options) message to the MS. The SGSN is now able toroute PDP PDUs between the GGSN and the MS, and to start charging.

For each PDP Address a different quality of service (QoS) profile may be requested. For example, some PDP addressesmay be associated with E-mail that can tolerate lengthy response times. Other applications cannot tolerate delay anddemand a very high level of throughput, interactive applications being one example. These different requirements arereflected in the QoS profile. The QoS profile is defined in subclause "Quality of Service Profile". If a QoS requirementis beyond the capabilities of a PLMN, the PLMN negotiates the QoS profile as close as possible to the requested QoSprofile. The MS either accepts the negotiated QoS profile, or deactivates the PDP context.

After an SGSN has successfully updated the GGSN, the PDP contexts associated with an MS is distributed as shown inclause "Information Storage".

If the PDP Context Activation Procedure fails or if the SGSN returns an Activate PDP Context Reject (Cause, PDPConfiguration Options) message, then the MS may attempt another activation to the same APN up to a maximumnumber of attempts.

9.2.2.2 Network-Requested PDP Context Activation Procedure

The Network-Requested PDP Context Activation procedure allows the GGSN to initiate the activation of a PDPcontext. When receiving a PDP PDU the GGSN checks if a PDP context is established for that PDP address. If no PDPcontext has been previously established the GGSN may try to deliver the PDP PDU by initiating the Network-Requested PDP Context Activation procedure. The criteria used by the GGSN to determine whether trying to deliverthe PDP PDU to the MS may be based on subscription information and are outside the scope of GPRS standardisation.

To support Network-Requested PDP Context Activation the GGSN has to have static PDP information about the PDPaddress. To determine whether Network-Requested PDP Context Activation is supported for a PDP address the GGSNchecks if there is static PDP information for that PDP address.

Once these checks have been performed the GGSN may initiate the Network-Requested PDP Context Activationprocedure.

ETSI


The network operator may implement the following techniques to prevent unnecessary enquires to the HLR:

- implementation of the Mobile station Not Reachable for GPRS flag (MNRG) technique in GGSN, SGSN, andHLR (see subclause "Unsuccessful Network-Requested PDP Context Activation Procedure");

- the GGSN may reject or discard PDP PDUs after a previous unsuccessful delivery attempt. This systematicrejection of PDP PDUs would be performed during a certain time after the unsuccessful delivery;

- the GGSN may store the address of the SGSN with which the GGSN established the last PDP context. Thiswould prevent an enquiry to the HLR. This SGSN address would be considered as valid during a certain time.

9.2.2.2.1 Successful Network-Requested PDP Context Activation Procedure

The Successful Network-Requested PDP Context Activation procedure is illustrated in figure 36. Each step is explainedin the following list.

MS SGSN GGSN

3. PDU Notification Request

HLR

1. PDP PDU

2. Send Routeing Info for GPRS

2. Send Routeing Info for GPRS Ack

4. Request PDP Context Activation

5. PDP Context Activation procedure

3. PDU Notification Response

Figure 36: Successful Network-Requested PDP Context Activation Procedure

1) When receiving a PDP PDU the GGSN determines if the Network-Requested PDP Context Activation procedurehas to be initiated. The GGSN may store subsequent PDP PDUs received for the same PDP address.

2) The GGSN may send a Send Routeing Information for GPRS (IMSI) message to the HLR. If the HLRdetermines that the request can be served, it returns a Send Routeing Information for GPRS Ack (IMSI, SGSNAddress, Mobile Station Not Reachable Reason) message to the GGSN. The Mobile Station Not ReachableReason parameter is included if the MNRG flag is set in the HLR. The Mobile Station Not Reachable Reasonparameter indicates the reason for the setting of the MNRG flag as stored in the MNRR record (see GSM 03.40).If the MNRR record indicates a reason other than 'No Paging Response', the HLR shall include the GGSNnumber in the GGSN-list of the subscriber.

If the HLR determines that the request cannot be served (e.g., IMSI unknown in HLR), the HLR shall send aSend Routeing Information for GPRS Ack (IMSI, MAP Error Cause) message. Map Error Cause indicates thereason for the negative response.

3) If the SGSN address is present and either Mobile Station Not Reachable Reason is not present or Mobile StationNot Reachable Reason indicates 'No Paging Response', the GGSN shall send a PDU Notification Request (IMSI,PDP Type, PDP Address) message to the SGSN indicated by the HLR. Otherwise, the GGSN shall set theMNRG flag for that MS. The SGSN returns a PDU Notification Response (Cause) message to the GGSN inorder to acknowledge that it shall request the MS to activate the PDP context indicated with PDP Address.

4) The SGSN sends a Request PDP Context Activation (TI, PDP Type, PDP Address) message to request the MS toactivate the indicated PDP context.

5) The PDP context is activated with the PDP Context Activation procedure (see subclause "PDP ContextActivation Procedure").

ETSI


9.2.2.2.2 Unsuccessful Network-Requested PDP Context Activation Procedure

If the PDP context requested by the GGSN cannot be established, the SGSN sends a PDU Notification Response(Cause) or a PDU Notification Reject Request (IMSI, PDP Type, PDP Address, Cause) message to the GGSNdepending on if the context activation fails before or after the SGSN has sent a Request PDP Context Activationmessage to the MS. Cause indicates the reason why the PDP context could not be established:

- 'IMSI Not Known'. The SGSN has no MM context for that IMSI (Cause in PDU Notification Response);

- 'MS GPRS Detached'. The MM state of the MS is IDLE (Cause in PDU Notification Response);

- 'MS Not GPRS Responding'. The MS is GPRS-attached to the SGSN but the MS does not respond. This may bedue to the lack of a response to a GPRS Paging Request, due to an Abnormal RLC condition, or due to noActivate PDP Context Request message received within a certain time after the Request PDP Context Activationmessage was delivered to the MS (Cause in PDU Notification Reject Request);

- 'MS Refuses'. The MS refuses explicitly the network-requested PDP context (Cause in PDU Notification RejectRequest).

When receiving the PDU Notification Response or the PDU Notification Reject Request message the GGSN may rejector discard the PDP PDU depending on the PDP type.

After an unsuccessful Network-Requested PDP Context Activation procedure the network may perform some actions toprevent unnecessary enquires to the HLR. The actions taken depend on the cause of the delivery failure.

- If the MS is not reachable or if the MS refuses the PDP PDU (Cause value 'MS Not GPRS Responding' or 'MSRefuses'), then the SGSN shall not change the setting of MNRG for this MS. The GGSN may refuse any PDPPDU for that PDP address during a certain period. The GGSN may store the SGSN address during a certainperiod and send subsequent PDU Notification Request messages to that SGSN.

- If the MS is GPRS-detached or if the IMSI is not known in the SGSN (Cause value 'MS GPRS Detached' or'IMSI Not Known'), then the SGSN, the GGSN, and the HLR may perform the Protection and Mobile UserActivity procedures.

The Protection procedure is illustrated in figure 37. Each step is explained in the following list.

SGSN HLR GGSN

1. PDU Notification Response

3. Send Routeing Info for GPRS

3. Send Routeing Info for GPRS Ack

4. Failure Report

4. Failure Report Ack

2. PDU Notification Reject Response

2. PDU Notification Reject Request

Figure 37: Protection Procedure

1) If the MM context of the mobile is IDLE or if the SGSN has no information about that user, the SGSN returns aPDU Notification Response (Cause) message to the GGSN with Cause equal to 'MS GPRS Detached' or 'IMSINot Known', otherwise the Cause shall be 'Activation Proceeds'. If the Cause is 'MS GPRS Detached' or 'IMSINot Known' and if the SGSN has an MM context for that user, the SGSN sets MNRG to indicate the need toreport to the HLR when the next contact with that MS is performed.

2) If the MS does not respond or refuses the activation request, the SGSN sends a PDU Notification Reject Request(IMSI, PDP Type, PDP Address, Cause) message to the GGSN with Cause equal to 'MS Not GPRS Responding'or 'MS Refuses'. The GGSN returns a PDU Notification Reject Response message to the SGSN.

ETSI


3) If Cause equals 'IMSI Not Known' the GGSN may send a Send Routeing Information for GPRS (IMSI) messageto the HLR. The HLR returns a Send Routeing Information for GPRS Ack (IMSI, SGSN Address, Cause)message to the GGSN indicating the address of the SGSN that currently serves the MS. If SGSN Address isdifferent from the one previously stored by the GGSN, then steps 3, 4, and 5 in figure 37 are followed.

4) If SGSN Address is the same as the one previously stored in the GGSN, or if the Cause value returned in step 1equals 'MS GPRS Detached', then the GGSN sets MNRG for that PDP address and sends a Failure Report(IMSI, GGSN Number, GGSN Address) message to the HLR to request MNRG to be set in the HLR. The HLRsets (if not already set) MNRG for the IMSI and adds GGSN Number and GGSN Address to the list of GGSNsto report to when activity from that IMSI is detected. GGSN Number is either the number of the GGSN, or, if aprotocol-converting GSN is used as an intermediate node, the number of the protocol-converting GSN. GGSNAddress is an optional parameter that shall be included if a protocol-converting GSN is used.

The Mobile User Activity procedure is illustrated in figure 38. Each step is explained in the following list.

3. Note MS GPRS Present

SGSN HLR GGSN

1. Attach Request

2a. Ready for SM

2b. Update Location

MS

Figure 38: Mobile User Activity Procedure

1) The SGSN receives an indication that an MS is reachable, e.g., an Attach Request message from the MS.

2a) If the SGSN contains an MM context of the MS and MNRG for that MS is set, the SGSN shall send a Ready forSM (IMSI, MS Reachable) message to the HLR and clears MNRG for that MS.

2b)If the SGSN does not keep the MM context of the MS, the SGSN shall send an Update Location message (seesubclause "Attach Function") to the HLR.

3) When the HLR receives the Ready for SM message or the Update Location message for an MS that has MNRGset, it clears MNRG for that MS and sends a Note MS GPRS Present (IMSI, SGSN Address) message to all theGGSNs in the list of the subscriber. (The Ready for SM message also triggers the SMS alert procedure asdescribed in subclause "Unsuccessful Mobile-terminated SMS Transfer".) SGSN Address contains the address ofthe SGSN that currently serves the MS. Upon reception of Note MS Present, each GGSN shall clear MNRG.

9.2.2.3 Anonymous Access PDP Context Activation Procedure

The MS can anonymously initiate PDP Context Activation in IDLE, STANDBY, and READY states. An existing MMcontext in the SGSN is neither required nor used in this case. Only dynamic PDP addressing is applicable.

The Anonymous Access PDP Context Activation procedure is illustrated in figure 39. Each step is explained in thefollowing list.

3. Activate AA PDP Context Accept

2. Create AA PDP Context Response

2. Create AA PDP Context Request

1. Activate AA PDP Context Request

SGSN GGSNMS

Figure 39: Anonymous Access PDP Context Activation Procedure

ETSI


1) The MS sends an Activate AA PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name,QoS Requested, PDP Configuration Options) message to the SGSN. The MS shall use a Random TLLI at theRLC/MAC layer for identification purposes. The MS shall use PDP Address to indicate that it requires the use ofa dynamic PDP address. The MS shall use Access Point Name to select a reference point to a certain externalnetwork that provides anonymous services. QoS Requested indicates the desired QoS profile. PDP ConfigurationOptions may be used to request optional PDP parameters from the GGSN (see GSM 09.60). PDP ConfigurationOptions is sent transparently through the SGSN.

2) The SGSN may restrict the requested QoS value given its capabilities and the current load. The SGSN assigns anAuxiliary TLLI and creates an AA-TID for the PDP-Context. The SGSN sends a Create AA PDP ContextRequest (PDP Type, PDP Address, Access Point Name, QoS Negotiated, AA-TID, Selection Mode, PDPConfiguration Options) message to the GGSN indicated by Access Point Name in the Activate AA PDP ContextRequest message. Selection Mode indicates how the APN was selected. The GGSN creates a new entry in itsPDP context table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs betweenthe SGSN and the server(s) that provide services for anonymous MSs, and to start charging. The GGSN may useAccess Point Name to find an external network that provides anonymous services. The GGSN may furtherrestrict QoS Negotiated given its capabilities and the current load. The GGSN then allocates a dynamic PDPAddress and returns a Create AA PDP Context Response (AA-TID, PDP Address, Reordering Required, PDPConfiguration Options, QoS Negotiated, Charging Id, Cause) message to the SGSN. Reordering Requiredindicates whether the SGSN shall reorder N-PDUs before delivering the N-PDUs to the MS. PDP ConfigurationOptions contain optional PDP parameters that the GGSN may transfer to the MS. These optional PDPparameters may be requested by the MS in the Activate PDP Context Request, or may be sent unsolicited by theGGSN. PDP Configuration Options is sent transparently through the SGSN. The GGSN shall check the sourceand destination address in all subsequent anonymous MO PDP PDUs received from the SGSN. If the GGSNdetects a not allowed address in an MO PDP PDU, then the PDP PDU shall be discarded and the MM and PDPcontexts shall be deleted in the GGSN, SGSN, and MS, as defined in subclause "Anonymous Access PDPContext Deactivation Initiated by GGSN Procedure".

If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated (e.g., thereliability class is insufficient to support the PDP type), then the GGSN rejects the Create AA PDP ContextRequest message. The compatible QoS profiles are configured by the GGSN operator.

3) The SGSN inserts the NSAPI along with the PDP address received from the GGSN in its PDP context. TheSGSN selects Radio Priority based on QoS Negotiated and returns an Activate AA PDP Context Accept(A-TLLI, PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, PDP Configuration Options) message tothe MS. The SGSN is now able to route anonymous PDP PDUs between the GGSN and the MS and to startcharging.

After an SGSN has successfully updated the GGSN, the MM and PDP contexts associated with an MS is distributed asshown in clause "Information Storage".

If the AA PDP Context Activation procedure fails or if the SGSN returns an Activate AA PDP Context Reject (Cause,PDP Configuration Options) message, then the MS may attempt another activation to the same GGSN up to a maximumnumber of attempts.

9.2.3 Modification Procedures

An SGSN can decide, possibly triggered by the HLR as explained in subclause "Insert Subscriber Data Procedure", tomodify parameters that were negotiated during an activation procedure for one or several PDP contexts. The followingparameters can be modified:

- QoS Negotiated; and

- Radio Priority.

The SGSN can request the modification of parameters by sending a Modify PDP Context Request message to the MS.

ETSI


9.2.3.1 PDP Context Modification Procedure

The PDP Context Modification procedure is illustrated in figure 40. Each step is explained in the following list.

4. Modify PDP Context Accept



3. Modify PDP Context Request

SGSN GGSNMS

Figure 40: PDP Context Modification Procedure

1) The SGSN may send an Update PDP Context Request (TID, QoS Negotiated) message to the GGSN. If QoSNegotiated received from the SGSN is incompatible with the PDP context being modified (e.g., the reliabilityclass is insufficient to support the PDP type), then the GGSN rejects the Update PDP Context Request. Thecompatible QoS profiles are configured by the GGSN operator.

2) The GGSN may restrict QoS Negotiated given its capabilities and the current load. The GGSN stores QoSNegotiated and returns an Update PDP Context Response (TID, QoS Negotiated) message.

3) The SGSN sends a Modify PDP Context Request (TI, QoS Negotiated, Radio Priority) message to the MS.

4) The MS acknowledges by returning a Modify PDP Context Accept message. If the MS does not accept the newQoS Negotiated it shall de-activate the PDP context with the PDP Context Deactivation Initiated by MSprocedure.

9.2.4 Deactivation Procedures

9.2.4.1 PDP Context Deactivation Initiated by MS Procedure

The PDP Context Deactivation Initiated by MS procedure is illustrated in figure 41. Each step is explained in thefollowing list.

GGSN

4. Deactivate PDP Context Accept



1. Deactivate PDP Context Request

SGSNMS


Figure 41: PDP Context Deactivation Initiated by MS Procedure

1) The MS sends a Deactivate PDP Context Request (TI) message to the SGSN.


3) The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. The GGSN removes the PDPcontext and returns a Delete PDP Context Response (TID) message to the SGSN. If the MS was using a dynamicPDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by otherMSs. The Delete PDP Context messages are sent over the GPRS backbone network.

4) The SGSN returns a Deactivate PDP Context Accept (TI) message to the MS.

ETSI


At GPRS detach, all PDP contexts for the MS are implicitly deactivated.

If the SGSN receives a Deactivate PDP Context Request (TI) message for a PDP context that is currently beingactivated, then the SGSN shall stop the PDP Context Activation procedure without responding to the MS, and continuewith the PDP Context Deactivation initiated by MS procedure.

9.2.4.2 PDP Context Deactivation Initiated by SGSN Procedure

The PDP Context Deactivation Initiated by SGSN procedure is illustrated in figure 42. Each step is explained in thefollowing list.

GGSN


SGSN




MS

Figure 42: PDP Context Deactivation Initiated by SGSN Procedure

1) The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. The GGSN removes the PDPcontext and returns a Delete PDP Context Response (TID) message to the SGSN. If the MS was using a dynamicPDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by otherMSs. The Delete PDP Context messages are sent over the GPRS backbone network. The SGSN may not wait forthe response from the GGSN before sending the Deactivate PDP Context Request message.

2) The SGSN sends a Deactivate PDP Context Request (TI) message to the MS. The MS removes the PDP contextand returns a Deactivate PDP Context Accept (TI) message to the SGSN.

9.2.4.3 PDP Context Deactivation Initiated by GGSN Procedure

The PDP Context Deactivation Initiated by GGSN procedure is illustrated in figure 43. Each step is explained in thefollowing list.

GGSN


SGSN




MS

Figure 43: PDP Context Deactivation Initiated by GGSN Procedure

1) The GGSN sends a Delete PDP Context Request (TID) message to the SGSN.

2) The SGSN sends a Deactivate PDP Context Request (TI) message to the MS. The MS removes the PDP contextand returns a Deactivate PDP Context Accept (TI) message to the SGSN.

3) The SGSN returns a Delete PDP Context Response (TID) message to the GGSN. If the MS was using a dynamicPDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by otherMSs. The Delete PDP Context messages are sent over the GPRS backbone network. The SGSN may not wait forthe response from the MS before sending the Delete PDP Context Response message.

ETSI


9.2.4.4 Anonymous Access PDP Context Deactivation Initiated by MS Procedure

The MS shall not issue explicit deactivation request messages to delete anonymous contexts in the network. Instead, theREADY timer shall be used as an implicit deactivation timer to save signalling traffic on the radio interface.

The Anonymous Access PDP Context Deactivation Initiated by MS procedure is illustrated in figure 44. Each step isexplained in the following list.

2. Delete AA PDP Context Response

2. Delete AA PDP Context Request

1. READY timer expiry

MS SGSN GGSN

Figure 44: Anonymous Access PDP Context Deactivation Initiated by MS Procedure

1) The READY timer expires in the MS and SGSN.

2) The SGSN sends a Delete AA PDP Context Request (AA-TID) message. The GGSN removes the PDP contextand returns a Delete AA PDP Context Response (AA-TID) message to the SGSN. The GGSN releases this PDPaddress and makes it available for subsequent anonymous activation by other MSs.

9.2.4.5 Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure

If the GGSN detects a misuse or fraud of the anonymous context as described in subclause "Anonymous Access PDPContext Activation Procedure", step 2, it shall initiate the deactivation independently of the READY timer expiry.

If the anonymous server detects a misuse or fraud, it may request the GGSN to deactivate the AA context. The methodthat the anonymous server uses to inform the GGSN is outside the scope of the GSM specifications.

The Anonymous Access PDP Context Deactivation Initiated by GGSN procedure is illustrated in figure 45. Each step isexplained in the following list.

GGSN

1. Delete AA PDP Context Request

SGSN

4. Delete AA PDP Context Response

3. Deactivate AA PDP Context Accept

3. Deactivate AA PDP Context Request

MS


2. Identity Request

Figure 45: Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure

1) The GGSN sends a Delete AA PDP Context Request (AA-TID) message to the SGSN.

2) The SGSN may send an Identity Request (Identity Type = IMSI or IMEI) message to the MS. The MS shallrespond with an Identity Response (IMSI or IMEI) message.

3) The SGSN sends a Deactivate AA PDP Context Request (TI) message to the MS. The MS removes the PDPcontext and returns a Deactivate AA PDP Context Accept (TI) message to the SGSN.

4) The SGSN returns a Delete AA PDP Context Response (AA-TID) message to the GGSN. The GGSN releasesthis PDP address and makes it available for subsequent activation by other MSs. The Delete AA PDP Contextmessages are sent over the GPRS backbone network. The SGSN may not wait for the accept from the MS beforesending the Delete AA PDP Context Response message.

ETSI


9.3 Packet Routeing and Transfer FunctionThe packet routeing and transfer function:

- routes and transfers packets between a mobile TE and an external network, i.e., between reference point R andreference point Gi;

- routes and transfers packets between mobile TE and other GPRS PLMN, i.e., between reference point R andreference point Gi via interface Gp; and

- routes and transfers packets between TEs, i.e., between the R reference point in different MSs.

The PDP PDUs shall be routed and transferred between the MS and the GGSN as N-PDUs. In case of PDP type PPP,the maximum size of each N-PDU shall be 1 502 octets. In other cases, the maximum size of each N-PDU shall be1 500 octets. When the MS or the GGSN receives a PDP PDU that results in an N-PDU that is not larger than themaximum N-PDU size, then the PDP PDU shall be routed and transferred as one N-PDU. When the MS or the GGSNreceives a PDP PDU that results in an N-PDU that is larger than the maximum N-PDU size, then the PDP PDU shall besegmented, discarded or rejected, depending on the PDP type and the implementation. The packet data protocol in theMS may limit the maximum size of the PDP PDUs that are routed and transferred, e.g., due to MS memory limitations.

Between the SGSN and the MS, PDP PDUs are transferred with the SNDCP.

Between the SGSN and the GGSN, PDP PDUs are routed and transferred with either the TCP/IP or the UDP/IPprotocols. The GPRS Tunnelling Protocol transfers data through tunnels. A tunnel is identified by a tunnel identifier(TID) and a GSN address.

To support roaming GPRS subscribers, and for forward compatibility, the SGSN is not required to know the tunnelledPDP. Every SGSN shall have the capability to transfer PDUs belonging to PDPs not supported in the PLMN of theSGSN.

9.4 Relay FunctionThe relay function of a network node transfers the PDP PDUs received from the incoming link to the appropriateoutgoing link. At SGSN and GGSN the relay function stores all valid PDP PDUs until they are forwarded to the nextnetwork node or until the maximum holding time of the PDP PDUs is reached. The PDP PDUs are discarded whenbuffering is longer than their maximum holding time. This maximum holding time is implementation dependent and canbe influenced by the PDP type, the QoS of the PDP PDU, the resource load status, and by buffer conditions. Thediscarding protects resources from useless transfer attempts, especially the radio resource. Impacts on user protocoloperation by too short holding time shall be avoided.

The SGSN and GGSN relay functions add sequence numbers to PDP PDUs received from SNDCP and from the Gireference point, respectively. The SGSN relay function may perform re-sequencing of PDP PDUs before passing thePDP PDUs to SNDCP. The GGSN relay function may perform re-sequencing of PDP PDUs before passing the PDPPDUs to the Gi reference point.

9.5 Packet Terminal Adaptation FunctionThe Packet Terminal Adaptation function adapts packets received from and transmitted to the Terminal Equipment to aform suitable for transmission within GSM.

A range of MT versions providing different standard interfaces towards the TE can be used, e.g.:

- MT with asynchronous serial interface and PAD (Packet Assembly / Disassembly) support (e.g., AT commandset PAD, X.28 [35] / X.29 [36] / X.3 [33] PAD). In the case when the PAD function does not exist in the MT, itexists in the TE;

- "Embedded MT" integrated with the TE, possibly via an industry-standard application program interface;

- MT with synchronous serial interface.

ETSI


9.6 Encapsulation FunctionGPRS transparently transports PDP PDUs between external networks and MSs. All PDP PDUs are encapsulated anddecapsulated for GPRS routeing purposes. Encapsulation functionality exists at the MS, at the SGSN, and at the GGSN.Encapsulation allows PDP PDUs to be delivered to and associated with the correct PDP context in the MS, the SGSN,or the GGSN. Two different encapsulation schemes are used; one for the GPRS backbone network between two GSNs,and one for the GPRS connection between SGSN and MS.

Encapsulation requires that the MS is attached to GPRS, and that the PDP Context Activation procedure has beenexecuted. If the GPRS Attach or PDP Context Activation procedures cannot be successfully executed, then uplink PDPPDUs are discarded in the MS. If these procedures have not been executed when a downlink PDP PDU arrives in theGGSN, then the downlink PDP PDU shall be discarded, rejected, or the Network-Requested PDP Context Activationprocedure shall be initiated.

9.6.1 Encapsulation Between SGSN and GGSN

The GPRS backbone network encapsulates a PDP PDU with a GPRS Tunnelling Protocol header, and inserts this GTPPDU in a TCP PDU or UDP PDU that again is inserted in an IP PDU. The IP and GTP PDU headers contain the GSNaddresses and tunnel endpoint identifier necessary to uniquely address a GSN PDP context.

9.6.2 Encapsulation Between SGSN and MS

Between SGSN and MS, an SGSN or MS PDP context is uniquely addressed with a temporary logical link identity anda network layer service access point identifier pair. TLLI is derived from the P-TMSI. An NSAPI is assigned when theMS initiates the PDP Context Activation function. The relationship between TLLI / NSAPI and LLC / SNDCP isillustrated in figure 46. TLLI and NSAPI are described in subclause "NSAPI and TLLI".

10 Message Screening FunctionalityThis screening mechanism may be performed by routers and firewalls, and performs the selection of which packets toallow and which to deny.

Only network-controlled message screening shall be supported. Network-controlled screening is used to protect theGPRS network from known security problems, and the screening provided by a certain PLMN is applied independentlyof the MS user. Network-controlled screening is outside the scope of GPRS standardisation.

11 Compatibility IssuesNon-GPRS MSs in GSM PLMNs that support GPRS shall, without changes, be able to continue operation.

GSM PLMNs that do not support GPRS shall, without changes, be able to continue interworking with GSM PLMNsthat do support GPRS.

A GPRS ME shall be able to access GPRS services with GPRS-aware SIMs, and with SIMs that are not GPRS-aware.A GPRS-aware SIM is able to store information in the elementary files EFKcGPRS and EFLOCIGPRS ,as defined in

GSM 11.11 [27].

GPRS Release 98 shall be backwards compatible with Release 97. Messages, information elements, and code pointsthat are not recognised by Release 97 equipment shall be rejected with appropriate error causes.

ETSI


12 Transmission

12.1 Transmission ModesThe GTP, LLC, and RLC protocols offer various transmission modes. The combinations of the GTP, LLC, and RLCtransmission modes define the QoS reliability classes (see subclause "Reliability Class").

12.1.1 GTP Transmission Modes

Two modes of operation of the GTP layer are supported for information transfer between the GGSN and SGSN;unacknowledged (UDP/IP) and acknowledged (TCP/IP). The GTP layer shall support both modes simultaneously.

12.1.2 LLC Transmission Modes

Two modes of operation of the LLC layer are defined for information transfer; unacknowledged and acknowledged.The LLC layer shall support both modes simultaneously.

- In acknowledged mode, the receipt of LL-PDUs are confirmed. The LLC layer retransmits LL-PDUs ifconfirmation has not been received within a timeout period.

- In unacknowledged mode, there is no confirmation required for LL-PDUs.

Signalling and SMS shall be transferred in unacknowledged mode.

In unacknowledged mode, the LLC layer shall offer the following two options:

- transport of "protected" information, such that errors within the LLC information field result in the frame beingdiscarded; and

- transport of "unprotected" information, such that errors within the LLC information field do not result in theframe being discarded.

The LLC layer shall support several different QoS delay classes with different transfer delay characteristics.

12.1.3 RLC Transmission Modes

Two modes of operation of the RLC layer are defined for information transfer; unacknowledged and acknowledged.The RLC layer shall support both modes simultaneously.

12.2 Logical Link Control FunctionalityThe Logical Link Control (LLC) protocol provides a reliable logical link between the MS and its SGSN. As shown insubclause "Transmission and Signalling Planes", the LLC layer is situated below the SNDC layer.

12.2.1 Addressing

TLLI is used for addressing at the LLC layer. TLLI is described in subclause "NSAPI and TLLI".

12.2.2 Services

LLC provides the services necessary to maintain a ciphered data link between an MS and an SGSN. The LLC layerdoes not support direct communication between two MSs.

The LLC connection is maintained as the MS moves between cells served by the same SGSN. When the MS moves to acell being served by a different SGSN, the existing connection is released and a new logical connection is establishedwith the new SGSN.

ETSI


LLC shall be independent of the underlying radio interface protocols. In order to allow LLC to operate with a variety ofdifferent radio interface protocols, and to ensure optimum performance, it may be necessary to adjust e.g., themaximum LLC PDU length and the LLC protocol timer values. Such adjustments can be made through negotiationbetween the MS and the SGSN. The maximum length of an LLC PDU shall not be greater than 1 600 octets minus theBSSGP protocol control information.

12.2.3 Functions

The Logical Link Control layer supports:

- service primitives allowing the transfer of SNDCP Protocol Data Units (SN-PDUs) between the SubnetworkDependent Convergence layer and the Logical Link Control layer;

- procedures for transferring LL-PDUs between the MS and SGSN, including:

- procedures for unacknowledged delivery of LL-PDUs between the MS and the SGSN; and

- procedures for acknowledged, reliable delivery of LL-PDUs between the MS and SGSN;

- procedures for detecting and recovering from lost or corrupted LL-PDUs;

- procedures for flow control of LL-PDUs between the MS and the SGSN; and

- procedures for ciphering of LL-PDUs. The procedures are applicable to both unacknowledged andacknowledged LL-PDU delivery.

The layer functions are organised in such a way that ciphering resides immediately above the RLC/MAC layer in theMS, and immediately above the BSSGP layer in the SGSN.

12.3 Subnetwork Dependent Convergence FunctionalityThe Subnetwork Dependent Convergence (SNDC) protocol is situated below the network layer and above the LogicalLink Control layer in the MS and the SGSN, as shown in subclause "Transmission and Signalling Planes". A variety ofnetwork layers are supported, e.g., IP and X.25. The network-layer packet data protocols share the same SNDCP, thatthen performs multiplexing of data coming from the different sources to be sent across LLC. This is illustrated infigure 46.

Packet DataProtocol

SNDCP

LLC Information

Signalling SMS

LLC

NSAPI

NSAPI + Control

DataControl

SNDC Header

LLC Header

TLLI

RLC or BSSGP

Data

N-PDU

SAPI

Figure 46: Multiplexing of Network Protocols

ETSI


The following identities and control information is needed:

- NSAPI identifies the network layer. The SNDCP control part contains compression information.

- TLLI identifies the MS. The LLC control part contains the rest of the LLC protocol header including cipheringinformation.

The Subnetwork Dependent Convergence function is defined in terms of offered services and sub-functions.

12.3.1 Services

The SNDC function provides the following services to the network layer:

- transmission and reception of N-PDUs in acknowledged and unacknowledged LLC mode. In acknowledgedmode, the receipt of data shall be confirmed at the LLC layer, and the data shall be transmitted and received inorder per NSAPI. In unacknowledged mode, the receipt of data shall not be confirmed at the SNDCP layer nor atthe LLC layer;

- transmission and reception between the MS and SGSN of variable-length N-PDUs;

- transmission and reception of N-PDUs between the SGSN and MS according to the negotiated QoS profile;

- transfer of the minimum amount of data possible between the SGSN and MS through compression techniques.

The SNDC function requires the following services from the LLC layer:

- acknowledged and unacknowledged data transfer;

- ciphered transmission of SN-PDUs;

- in-order delivery of SN-PDUs per LLC SAPI;

- support for variable-length SN-PDUs.

12.3.2 Subfunctions

Compression

Segmentation Reassembly

De-compression

SNDC Primitive SNDC Primitive

LLC Primitive LLC Primitive

Network Layer

SNDC Layer

LLC Layer

Figure 47: Sequential Invocation of SNDC Functionality

SNDCP performs the following subfunctions:

- mapping of SNDC primitives received from the network layer into corresponding LLC primitives to be passed tothe LLC layer, and vice versa;

- multiplexing of N-PDUs from one or several NSAPIs onto one LLC SAPI. NSAPIs that are multiplexed onto thesame SAPI shall use the same radio priority level, QoS delay class, and precedence class;

ETSI


- compression of redundant protocol control information and user data. This may include e.g., TCP/IP headercompression and V.42 bis [32] data compression. Compression may be performed independently for each QoSdelay class and precedence class. If several network layers use the same QoS delay class and precedence class,then one common compressor may be used for these network layers. The relationship between NSAPIs,compressors, and SAPIs is defined in GSM 04.65. Compression parameters are negotiated between the MS andthe SGSN. Compression is an optional SNDC function;

- segmentation and reassembly. The output of the compression subfunctions are segmented to maximum-lengthLLC frames.

12.4 Octet Stream Protocol FunctionalityThe Octet Stream Protocol (OSP) is used to carry an unstructured octet (character) stream between the MS and GGSN.It is used to provide a character pipe to allow an MS to communicate (via the GGSN) with an arbitrary Internet host, orother character-based service. PDP type shall be selected as OSP for this purpose. Unlike PDP types IP and X.25, OSPhas no existence outside the PLMN. In the MS there is a character stream at the R reference point together with someoptional control signals. In the GGSN there is a relay function, carrying the same character stream and control signalsbetween OSP and a fixed-network protocol stack.

OSP has two modes of operation. In octet mode, it uses a Packet Assembly function to assemble a number of user octetsinto a single packet for more efficient transport by the underlying protocols. A complementary Packet Disassemblyfunction performs the reverse operation in the peer OSP. In block mode, the Packet Assembly / Disassembly (PAD)function is bypassed. In this case, data is transferred between the OSP user and OSP in blocks of octets. Each block ofoctets is delivered as a single OSP PDU to the underlying protocol. The selection of octet or block mode is madeindependently for each OSP connection as an implementation or configuration decision before the connection isestablished, and remains fixed for the duration of the connection. An example of the use of the block mode is when OSPis used for interworking with a fixed network where the octets are also carried in packets. This avoids the use of back-to-back PADs. It could also be used in an embedded MT where the application transfers data in blocks of octets.

OSP uses the services of SNDCP between the MS and SGSN, and the services of GTP between the SGSN and GGSN.The quality of service is determined mainly by that provided by the underlying layers. However, the end-to-end delaymay be affected by the presence of the PAD function. A reliable (acknowledged) service shall be provided by the layersbelow SNDCP and GTP.

The main functions of OSP are:

- transport of an unstructured octet stream;

- packet assembly and disassembly to make efficient use of network resources; and

- end-to-end flow control.

OSP may additionally provide:

- transport of a "break" signal;

- transport of control information blocks between the OSP users;

- user control of packet assembly buffer forwarding; and

- direct OSP user access to the underlying packet service, bypassing the PAD.

ETSI


Figure 48 illustrates the OSP transmission plane.

Relay

NetworkService

GTPSNDCP

LLC

RLC

MAC

GSM RF

SNDCP

LLC

BSSGP

L1bis

RLC

MAC

GSM RF

BSSGP

L1bis

Relay

L2

L1

IP

L2

L1

IP

GTP

Um Gb Gn GiMT BSS SGSN GGSN

NetworkService

TCP(UDP)

TCP(UDP)

Fixed-networkprotocol

stack

(e.g.,TCP/IPover theInternet)

R

Relay

OSP

R ref.point

protocolstack

(e.g.,async.

charactersover

V.28)

Relay

OSP

Figure 48: Relationship of OSP to the Rest of the GPRS Protocol Architecture

12.4.1 PAD Function

In order to make efficient use of the network resources, particularly the radio resource, octets received from the OSPuser are not forwarded immediately but are placed in a buffer. When some forwarding criterion is satisfied, the contentsof the buffer are forwarded in the payload of an N-PDU to the SNDCP layer. At the receiving end, the payload of anN-PDU received from the SNDCP layer is placed in a buffer and the octets are delivered to the OSP user as an octetstream.

The PAD is used only when OSP operates in octet mode. It is not used when OSP operates in block mode.

12.4.1.1 Packet Assembler

The packet assembler shall be able to detect the following forwarding criteria. When any one criterion is satisfied, thecontents of the buffer shall be forwarded in an N-PDU to the SNDCP layer, subject to any flow control condition.

12.4.1.1.1 Buffer Full

The buffer contents are forwarded when the number of octets in the buffer reaches the value of the maximum buffersize parameter.

12.4.1.1.2 Inactivity Timer Expiry

The inactivity timer shall be started whenever an octet is placed in the buffer. When the timer expires, the buffercontents shall be forwarded. The inactivity timer shall be stopped whenever a buffer is forwarded.

12.4.1.1.3 Maximum Buffer Delay Timer Expiry

A maximum buffer delay timer may be started when the first octet is placed in the (empty) buffer,. When the timerexpires, the buffer contents shall be forwarded. This optional timer ensures that no octet is delayed in the buffer forlonger than the specified time. The maximum buffer delay timer shall be stopped whenever a buffer is forwarded.

12.4.1.1.4 Special Character

Whenever an octet has been placed in the buffer, its least significant 7 bits shall be compared with a list of 7-bit specialcharacters. If the bits match, the buffer shall be forwarded. The possible characters and combinations of characters shallbe the same as specified for the X.3 PAD access to X.25.

12.4.1.1.5 Change in Flow Control State

The buffer may be forwarded when there is a need to signal a change in the ready to receive condition.

ETSI


12.4.1.1.6 Immediate Forwarding Request

When the OSP receives an immediate forward request from its user, it shall immediately forward the buffer unless it isempty.

12.4.1.2 Packet Disassembler

The packet disassembler shall forward the contents of the N-PDU payload to the OSP user, subject to any local flowcontrol condition.

12.4.2 Quality of Service

The QoS provided by the OSP layer is determined by that provided by the underlying protocol layers. However, thePAD functions introduce an additional variable delay into the transmission path. This delay can be limited at the risk ofmaking less efficient use of network resources, in particular the radio resources.

12.5 Point-to-Point Protocol FunctionalityThe PPP protocol is specified in RFC 1661 [44].

12.5.1 Transmission Plane for PDP Type PPP

The transmission plane for the PDP type PPP consists of a PPP protocol stack above SNDCP in the MS and above GTPin the GGSN. The GGSN may either terminate the PPP protocol and access the packet data network at the IP level, orfurther tunnel PPP PDUs via e.g., L2TP.

In case the application above PPP uses a different protocol than IP (e.g., IPX or AppleTalk), the interconnection to thepacket data network is outside the scope of this specification.

Relay

NetworkService

GTPSNDCP

LLC

RLC

MAC

GSM RF

SNDCP

LLC

BSSGP

L1bis

RLC

MAC

GSM RF

BSSGP

L1bis

Relay

L2

L1

IP

L2

L1

IP

GTP

Um Gb Gn GiMT BSS SGSN GGSN

NetworkService

UDP /TCP

UDP /TCP

E.g.,L2TP orIP tunnel

R

Relay

PPP

R ref.point

Relay

PPP

L1

L2 L2

L1

IP

Figure 49: Transmission Plane for PDP Type PPP

12.5.2 Functions

The PPP peers at the MS and GGSN handle the PPP protocol as specified in RFC 1661. PPP requires in-sequencepacket delivery by the underlying protocols. Concerning GTP, this shall be achieved by enabling Reordering Requiredupon GTP tunnel establishment. Concerning SNDCP, out-of-sequence packets, which may be present if LLC operatesin unacknowledged mode, shall be discarded. SNDCP shall not use TCP/IP header compression because PPP may notcarry IP packets at all, or because PPP may carry IP packets with already compressed TCP/IP headers. These PPPoptions are negotiated during the RFC 1661 Network Control Protocol establishment phase.

ETSI


12.6 Gb InterfaceThe Gb interface connects the BSS and the SGSN, allowing the exchange of signalling information and user data. TheGb interface shall allow many users to be multiplexed over the same physical resource. Resources are given to a userupon activity (when data is sent or received) and are reallocated immediately thereafter. This is in contrast to the Ainterface where a single user has the sole use of a dedicated physical resource throughout the lifetime of a callirrespective of activity.

GPRS signalling and user data are sent in the same transmission plane. No dedicated physical resources are required tobe allocated for signalling purposes.

Access rates per user may vary without restriction from zero data to the maximum possible line rate (e.g., 1 984 kbit/sfor the available bitrate of an E1 trunk).

12.6.1 Physical Layer Protocol

Several physical layer configurations and protocols are possible, as defined in GSM 08.14 [18].

The physical resources shall be allocated by O&M procedures.

12.6.2 Link Layer Protocols

The Gb interface link layer is based on Frame Relay, as defined in GSM 08.16. Frame Relay virtual circuits areestablished between SGSN and BSS. LLC PDUs from many users are multiplexed on these virtual circuits. The virtualcircuits may be multi-hop and traverse a network of Frame Relay switching nodes. Frame Relay shall be used forsignalling and data transmission.

The following characteristics apply for the Frame Relay connection:

- the maximum Frame Relay information field size shall be 1 600 octets;

- the Frame Relay address length shall be 2 octets;

- the BSS and the SGSN shall both implement Frame Relay DTE functionality. The SGSN may optionally alsoimplement DCE functionality;

- frame Relay PVCs shall be used;

- the Frame Relay layer offers detection of but no recovery from transmission errors;

- one or more Frame Relay PVCs shall be used between one SGSN and one BSS to transport BSSGP PDUs.

12.6.3 BSS GPRS Protocol

The primary function of BSSGP is to provide the radio-related, QoS, and routeing information that is required totransmit user data between a BSS and an SGSN. In the BSS, it acts as an interface between LLC frames and RLC/MACblocks. In the SGSN, it forms an interface between RLC/MAC-derived information and LLC frames. A secondaryfunction is to enable two physically distinct nodes, the SGSN and BSS, to operate node management control functions.

GbBSS

NetworkService

RLC

MAC

BSSGP

L1

Relay

LLC

BSSGP

L1

SGSN

NetworkService

Figure 50: BSSGP Protocol Position

ETSI


There is a one-to-one relationship between the BSSGP protocol in the SGSN and in the BSS. If one SGSN handlesmultiple BSSs, the SGSN has to have one BSSGP protocol machine for each BSS.

The main functions for the BSSGP protocol are to:

- provide a connection-less link between the SGSN and the BSS;

- transfer data unconfirmed between the SGSN and the BSS;

- provide tools for bi-directional control of the flow of data between the SGSN and the BSS;

- handle paging requests from the SGSN to the BSS;

- give support for flushing of old messages in the BSS e.g., when an MS changes BSS; and

- support multiple layer 2 links between the SGSN and one BSS.

BSSGP is defined in GSM 08.18.

12.6.3.1 Inter-dependency of the BSSGP and LLC Functions

The functions of the BSSGP shall be defined in the context of the LLC function in order to avoid duplication offunctions and information flows. The following functional model indicates each layer's functional responsibilities.

Table 3: Mapping of High-level Functions Across the Gb Architecture

NetworkNode andFunction

MS BSS SGSN

LLC:GSM 04.64

Same as forthe SGSN.

Provides transfer of frames between the SGSN andMS.

BSSGP:GSM 08.18

MS←PLMN:Using BSSGP information,RLC/MAC operations areinvoked.

MS→PLMN:Using RLC/MAC-derivedinformation, a BSSGP PDU isconstructed. An identifier ofthe cell including RAC andLAC in which an LLC framewas received is inserted intothe BSSGP PDU.

Same as for SGSN.

Individual MS radio-related information is used bythe BSS to transfer LLC frames across the Gb andUm.

Provides flow control and unconfirmed datadelivery services across the Gb interface (not theUm – this is the function of the LLC and RLC/MACfunction).

Provides SGSN-BSS node management functions.NetworkService:GSM 08.16

Same as for SGSN Provides a multiplexing, variable-bandwidth, frame-based, link layer transport mechanism across theGb interface, and load balancing.

12.6.3.2 BSSGP Addressing

For information transfer between the SGSN and the BSS the BSSGP is using a BSSGP Virtual Connection Identifier(BVCI) for addressing. Additionally, QoS profile, and the MS identification, e.g., TLLI, may be used to create queuesand contexts in both the SGSN and the BSS. The flow control mechanism is then based on these queues and contexts.

12.6.3.3 BVCI Contexts in BSS and in SGSN

A BVCI context in the BSS consists of at least one queue for LLC PDUs and of the available radio resource capacity.

ETSI


The BVCI context in the BSS is allocated for each cell supporting GPRS. For each new GPRS cell introduced in theBSS area, a new BVCI context shall be allocated.

In the SGSN the BVCI context consists of at least one queue for LLC PDUs and the allowed throughput on BSSGP.The allowed throughput is updated by BSSGP flow control messages.

12.6.3.4 Flow Control Between SGSN and BSS over the Gb Interface

The flow control mechanism controls the loading of the BSS LLC PDU queues per BVCI and per MS between theSGSN and the BSS in the downlink direction. No flow control is performed in the uplink direction. Buffers and linkcapacity shall be dimensioned to avoid loss of uplink data.

The downlink flow control mechanism is based on the following principles:

- in the SGSN, queues for LLC PDUs are provided per BVCI. These queues may be split further, e.g., per MS orper QoS delay class or precedence class. The SGSN shall pass LLC PDUs to LLC via BSSGP to the BSS as longas the allowed BSSGP throughput is not exceeded. The allowed BSSGP throughput is given per BVCI and for asingle MS on that BVCI. The SGSN schedules the BSSGP downlink traffic of all MSs of a BVCI according toboth throughput parameters and to the QoS profile related to each LLC PDU. The scheduling algorithm isimplementation dependent;

- in the BSS, queues per BVCI are provided at the BSSGP level. These queues may be split further, e.g., per MSor per QoS delay class or precedence class. Depending on the queuing conditions and the available radioresource capacity in the cell the BSS indicates the allowed BSSGP throughput per BVCI and the default allowedBSSGP throughput for each individual MS of that BVCI by BSSGP flow control messages to the SGSN.Additionally, the BSS may change the allowed BSSGP throughput for an individual MS by a BSSGP flowcontrol message.

12.7 Abis InterfaceWhen the GPRS MAC and RLC layer functions are positioned remote to the BTS the information between the ChannelCodec Unit (CCU) and the remote GPRS Packet Control Unit (PCU) is transferred in frames with a fixed length of 320bits (20 ms). In the present document these frames are denoted "PCU Frames" and are an extension to the "TRAUframes" defined in GSM 08.60 [21]. Within these frames both GPRS data and the GPRS RLC/MAC associated controlsignals are transferred.

The Abis interface should be the same if the PCU is positioned at the BSC site (option B in figure 51) or at the SGSNsite (option C in figure 51). In option B, the PCU could be implemented as an adjunct unit to the BSC. In option C, theBSC should be considered as transparent for 16†kbit/s channels. In configurations B and C the PCU is referred to asbeing a remote PCU.

The remote PCU is considered a part of the BSC, and the signalling between the BSC and the PCU may be performedby using BSC internal signals. The inband signalling between the CCU and the PCU functions, using PCU frames isrequired when the Abis interface is applied (options B and C in figure 51).

ETSI


Abis

BTS BSC site GSN site

BSC site GSN site

BSC site GSN site

CCU

PCUCCU

BTSCCU

CCU

BTSCCU

CCU

Um Gb

A

B

C

PCU

PCU

Key: Circuit-switching function (16 or 64 kbit/s)

Packet-switching function

Gb

Figure 51: Remote Packet Control Unit (PCU) Positions

The PCU is responsible for the following GPRS MAC and RLC layer functions as defined in GSM 03.64:

- LLC layer PDU segmentation into RLC blocks for downlink transmission;

- LLC layer PDU reassembly from RLC blocks for uplink transmissions;

- PDCH scheduling functions for the uplink and downlink data transfers;

- PDCH uplink ARQ functions, including RLC block ack / nak;

- PDCH downlink ARQ function, including buffering and retransmission of RLC blocks;

- channel access control functions, e.g., access requests and grants; and

- radio channel management functions, e.g., power control, congestion control, broadcast control information, etc.

The functions inside the Channel Codec Unit (CCU) are:

- the channel coding functions, including FEC and interleaving; and

- radio channel measurement functions, including received quality level, received signal level and informationrelated to timing advance measurements.

The BSS is responsible for allocation and de-allocation of radio resources. A PCU frame shall be transferred betweenthe PCU and the CCU every 20 ms.

12.7.1 Remote Packet Control Unit

When the Packet Control Unit (PCU) is remote to the BTS, the Channel Codec Unit (CCU) in the BTS may controlsome of the functions in the remote PCU in the BSC. As well, the PCU may control some of the functions of the CCU.This remote control is performed by inband signalling carried by the control bits (C-bits) in each PCU frame.

13 Information StorageThis clause describes information storage structures required for GPRS, and the recovery and restoration proceduresneeded to maintain service if inconsistencies in databases occur and at lost or invalid database information.

ETSI


13.1 HLRIMSI is the prime key to the GPRS subscription data stored in the HLR. There may be several sets of GPRSsubscription data per IMSI. This is illustrated in figure 52.

IMSI

Password CS GPRS Suppl. Services

BS1 BS3BS2

SS1Status

SS1Status

SS1Status

PDP1 PDP3PDP2 SS2Prov.

SS1Prov.

Supplementary Service 2Activation Status

Basic Services

Figure 52: GPRS Subscription Data

As figure 52 indicates, the GPRS subscription data is at the same level as basic services. Each PDP subscription is seenas a basic service. Supplementary services are provisioned as part of the overall subscription. Activation of SSs is eitherat the basic service level (SS1) or at the overall subscription level (SS2).

Table 4 shows the GPRS subscription data contained in the HLR.

Table 4: HLR GPRS Subscription Data

Field DescriptionIMSI IMSI is the main reference key.MSISDN The basic MSISDN of the MS.SGSN Number The SS7 number of the SGSN currently serving this MS.SGSN Address The IP address of the SGSN currently serving this MS.SMS Parameters SMS-related parameters, e.g., operator-determined barring.MS Purged for GPRS Indicates that the MM and PDP contexts of the MS are deleted from the SGSN.MNRG Indicates that the MS is not reachable through an SGSN, and that the MS is marked

as not reachable for GPRS at the SGSN and possibly at the GGSN.GGSN-list The GSN number and optional IP address pair related to the GGSN that shall be

contacted when activity from the MS is detected and MNRG is set. The GSN numbershall be either the number of the GGSN or the protocol-converting GSN as describedin the subclauses "MAP-based GGSN - HLR Signalling" and "GTP and MAP-basedGGSN - HLR Signalling".

Each IMSI contains zero or more of the following PDP context subscription records:PDP Context Identifier Index of the PDP context.PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address. This field shall be empty if dynamic addressing

is allowed.Access Point Name A label according to DNS naming conventions describing the access point to the

external packet data network.QoS Profile Subscribed The quality of service profile subscribed. QoS Profile Subscribed is the default level if

a particular QoS profile is not requested.VPLMN Address Allowed Specifies whether the MS is allowed to use the APN in the domain of the HPLMN

only, or additionally the APN in the domain of the VPLMN.

ETSI


13.2 SGSNSGSN maintains MM context and PDP context information for MSs in STANDBY and READY states. Table 5 showsthe context fields for one MS.

Table 5: SGSN MM and PDP Contexts

Field DescriptionIMSI IMSI is the main reference key.MM State Mobility management state, IDLE, STANDBY, or READY.P-TMSI Packet Temporary Mobile Subscriber Identity.P-TMSI Signature A signature used for identification checking purposes.IMEI International Mobile Equipment IdentityMSISDN The basic MSISDN of the MS.Routeing Area Current routeing area.Cell Identity Current cell in READY state, last known cell in STANDBY or IDLE state.Cell Identity Age Time elapsed since the last LLC PDU was received from the MS at the SGSN.VLR Number The VLR number of the MSC/VLR currently serving this MS.New SGSN Address The IP address of the new SGSN where buffered and not sent N-PDUs should be

forwarded to.Authentication Triplets Authentication and ciphering parameters.Kc Currently used ciphering key.CKSN Ciphering key sequence number of Kc.Ciphering algorithm Selected ciphering algorithm.Radio Access Classmark MS radio access capabilities.SGSN Classmark MS network capabilities.DRX Parameters Discontinuous reception parameters.MNRG Indicates whether activity from the MS shall be reported to the HLR.NGAF Indicates whether activity from the MS shall be reported to the MSC/VLR.PPF Indicates whether paging for GPRS and non-GPRS services can be initiated.SMS Parameters SMS-related parameters, e.g., operator-determined barring.Recovery Indicates if HLR or VLR is performing database recovery.Radio Priority SMS The RLC/MAC radio priority level for uplink SMS transmission.Each MM context contains zero or more of the following PDP contexts:PDP Context Identifier Index of the PDP context.PDP State Packet data protocol state, INACTIVE or ACTIVE.PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address.APN Subscribed The APN received from the HLR.APN in Use The APN currently used.NSAPI Network layer Service Access Point Identifier.TI Transaction Identifier.GGSN Address in Use The IP address of the GGSN currently used.VPLMN Address Allowed Specifies whether the MS is allowed to use the APN in the domain of the HPLMN

only, or additionally the APN in the domain of the VPLMN.QoS Profile Subscribed The quality of service profile subscribed.QoS Profile Requested The quality of service profile requested.QoS Profile Negotiated The quality of service profile negotiated.Radio Priority The RLC/MAC radio priority level for uplink user data transmission.Send N-PDU Number SNDCP sequence number of the next downlink N-PDU to be sent to the MS.Receive N-PDU Number SNDCP sequence number of the next uplink N-PDU expected from the MS.SND GTP sequence number of the next downlink N-PDU to be sent to the MS.SNU GTP sequence number of the next uplink N-PDU to be sent to the GGSN.Charging Id Charging identifier, identifies charging records generated by SGSN and GGSN.Reordering Required Specifies whether the SGSN shall reorder N-PDUs before delivering the N-PDUs to

the MS.

ETSI


In case of anonymous access the SGSN maintains the MM context and PDP context information for MSs in READYstate. Table 6 shows the context fields for one MS.

Table 6: SGSN MM and PDP Contexts for Anonymous Access

Field DescriptionA-TLLI Auxiliary Temporary Logical Link Identity.AA-TID Anonymous Access Tunnel Identifier.Routeing Area Current routeing area.Cell Identity Current cell.PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address.APN in Use The APN currently used.NSAPI Network layer Service Access Point Identifier.TI Transaction Identifier.GGSN Address in Use The IP address of the GGSN currently used.QoS Profile Requested The quality of service profile requested.QoS Profile Negotiated The quality of service profile negotiated.Radio Priority The RLC/MAC radio priority level for uplink user data transmission.Send N-PDU Number SNDCP sequence number of the next downlink N-PDU to be sent to the MS.Receive N-PDU Number SNDCP sequence number of the next uplink N-PDU expected from the MS.SND GTP sequence number of the next downlink N-PDU to be sent to the MS.SNU GTP sequence number of the next uplink N-PDU to be sent to the GGSN.Charging Id Charging identifier, identifies charging records generated by SGSN and GGSN.Reordering Required Specifies whether the SGSN shall reorder N-PDUs before delivering the N-PDUs to

the MS.

13.3 GGSNGGSN maintains activated PDP contexts. Table 7 shows the PDP context fields for one PDP Address.

Table 7: GGSN PDP Context

Field DescriptionIMSI International Mobile Subscriber Identity.NSAPI Network layer Service Access Point Identifier.MSISDN The basic MSISDN of the MS.PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address.Dynamic Address Indicates whether PDP Address is static or dynamic.APN in Use The APN Network Identifier currently used.QoS Profile Negotiated The quality of service profile negotiated.SGSN Address The IP address of the SGSN currently serving this MS.MNRG Indicates whether the MS is marked as not reachable for GPRS at the HLR.Recovery Indicates if the SGSN is performing database recovery.SND GTP sequence number of the next downlink N-PDU to be sent to the SGSN.SNU GTP sequence number of the next uplink N-PDU to be received from the SGSN.Charging Id Charging identifier, identifies charging records generated by SGSN and GGSN.Reordering Required Specifies whether the GGSN shall reorder N-PDUs received from the SGSN.

ETSI


If a PDP context is enabled for network-requested PDP context activation, then IMSI, PDP Type, PDP Address, SGSNAddress and MNRG contain valid information also when the PDP context is inactive and when the MS is GPRS-detached.

In case of anonymous access the GGSN maintains activated PDP contexts. Table 8 shows the PDP context fields forone MS.

Table 8: GGSN PDP Context for Anonymous Access

Field DescriptionAA-TID Anonymous Access Tunnel Identifier.PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address.APN in Use The APN Network Identifier currently used.QoS Profile Negotiated The quality of service profile negotiated.SGSN Address The IP address of the SGSN serving this MS.SND GTP sequence number of the next downlink N-PDU to be sent to the SGSN.SNU GTP sequence number of the next uplink N-PDU to be received from the SGSN.Charging Id Charging identifier, identifies charging records generated by SGSN and GGSN.Reordering Required Specifies whether the GGSN shall reorder N-PDUs received from the SGSN.

A GGSN that supports anonymous access shall have a list of server addresses that are allowed to be accessed byanonymous MSs. The method to maintain the list of the servers is outside the scope of the present document.

13.4 MSEach GPRS MS maintains MM and PDP context information in IDLE, STANDBY and READY states. Theinformation may be contained in the MS and the TE. Table 9 shows the MS context fields.

Table 9: MS MM and PDP Contexts

Field SIM DescriptionIMSI X International Mobile Subscriber Identity.MM State Mobility management state, IDLE, STANDBY, or READY.P-TMSI X Packet Temporary Mobile Subscriber Identity.P-TMSI Signature X A signature used for identification checking purposes.Routeing Area X Current routeing area.Cell Identity Current cell.Kc X Currently used ciphering key.CKSN X Ciphering key sequence number of Kc.Ciphering algorithm Selected ciphering algorithm.Classmark MS classmark.DRX Parameters Discontinuous reception parameters.Radio Priority SMS The RLC/MAC radio priority level for uplink SMS transmission.Each MM context contains zero or more of the following PDP contexts:PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address.PDP State Packet data protocol state, INACTIVE or ACTIVE.Dynamic Address Allowed Specifies whether the MS is allowed to use a dynamic address.APN Requested The APN requested.NSAPI Network layer Service Access Point Identifier.TI Transaction Identifier.QoS Profile Requested The quality of service profile requested.QoS Profile Negotiated The quality of service profile negotiated.Radio Priority The RLC/MAC radio priority level for uplink user data transmission.Send N-PDU Number SNDCP sequence number of the next uplink N-PDU to be sent to the SGSN.Receive N-PDU Number SNDCP sequence number of the next downlink N-PDU expected from the SGSN.

ETSI


The information marked with an "X" in table 9:

- shall be stored in the SIM if the connected SIM is GPRS-aware; and

- may be stored in the ME after GPRS detach if the connected SIM is not GPRS-aware.

If the SIM is GPRS-aware, then the IMSI, P-TMSI, P-TMSI Signature, Routeing Area, Kc, and CKSN stored in theSIM shall be used when accessing the GPRS services.

If the SIM is not GPRS-aware, then the P-TMSI, P-TMSI Signature, Routeing Area, Kc, and CKSN stored in the MEshall be used if and only if the IMSI stored in the SIM is identical to the IMSI image maintained in the ME. If the IMSIstored in the SIM is different from the IMSI image in the ME, then the IMSI image in the ME shall not be used, and theMS shall identify itself with the IMSI stored in the SIM when performing a GPRS attach. IMSI, P-TMSI, P-TMSISignature, Routeing Area, Kc, and CKSN may be stored in the ME after the GPRS attach has been successfullyperformed.

For anonymous access each GPRS MS maintains MM and PDP context information in READY state. The informationmay be contained in the ME and the TE. Table 10 shows the MS context fields.

Table 10: MS MM and PDP Contexts for Anonymous Access

Field DescriptionA-TLLI Auxiliary Temporary Logical Link Identity.Routeing Area Current routeing area.Cell Identity Current cell.PDP Type PDP type, e.g., X.25, PPP, or IP.PDP Address PDP address, e.g., an X.121 address.NSAPI Network layer Service Access Point Identifier.TI Transaction Identifier.APN Requested The APN requested.QoS Profile Requested The quality of service profile requested.QoS Profile Negotiated The quality of service profile negotiated.Radio Priority The RLC/MAC radio priority level for uplink user data transmission.Send N-PDU Number SNDCP sequence number of the next uplink N-PDU to be sent to the SGSN.Receive N-PDU Number SNDCP sequence number of the next downlink N-PDU expected from the SGSN.

13.5 MSC/VLRThe MSC/VLR may store the SGSN number of GPRS-attached MSs that are also IMSI-attached. Table 11 shows theMSC/VLR association for one MS.

Table 11: MSC/VLR Association

Field DescriptionIMSI IMSI is the main reference key.SGSN Number The SGSN number of the SGSN currently serving this MS.

13.6 Recovery and Restoration ProceduresThe recovery and restoration procedures are intended to maintain service if inconsistencies in databases occur and atlost or invalid database information. "Invalid" in this context means that the database entry cannot be regarded asreliable.

ETSI


13.6.1 HLR Failure

When an HLR restarts, it sends to each SGSN where one or more of its MSs are registered a Reset message. This causesthe SGSN to mark the relevant MM contexts as invalid, and to set NGAF if an SGSN – MSC/VLR association exists.After receipt of the first valid LLC frame from a marked MS, the SGSN performs an update location to the HLR as inthe attach or inter SGSN RA update procedures, and, if NGAF is set, the procedure in subclause "Non-GPRS Alert" isfollowed. The update location procedure and the procedure towards the MSC/VLR may be delayed by the SGSN for amaximum operator configuration-depending time period to avoid high signalling load. The periodic back-up of HLRdata to non-volatile storage is mandatory as described in GSM 03.07 [5].

13.6.2 SGSN Failure

When an SGSN fails, it deletes all MM and PDP contexts affected by the failure. SGSN storage of subscriber data isvolatile. Based on configuration data, the SGSN shall send a Reset message to each of its associated VLRs. The VLRsshall mark all associations containing the restarted SGSN as unreliable. See GSM 03.07.

If data or signalling, except GPRS attach and RA update, is received in an SGSN from an MS for which no MM contextexists in the SGSN, then the SGSN shall discard the data or signalling.

If an RA update request is received in an SGSN from an MS for which no MM context exists neither in the SGSN, norin the old SGSN for the inter-SGSN RA update case, then the SGSN shall reject the RA update with an appropriatecause. In order to remain GPRS-attached, the MS shall then perform a new GPRS attach and should (re-)activate PDPcontexts.

NOTE: In some cases, user interaction may be required, and then the MS cannot (re-)activate the PDP contextsautomatically.

When the SGSN receives a GTP PDU for which no PDP context exists it discards the GTP PDU and sends an errorindication to the originating GGSN. The GGSN marks the related PDP context as invalid. If there is no MM context forthe MS, the SGSN may search the MS by paging with the IMSI in the SGSN area. An MS that is paged for GPRSservices with IMSI as the identifier shall perform a new GPRS attach and should (re-)activate PDP contexts.

When the SGSN receives a mobile-terminated SM from the SMS-GMSC for an IMSI unknown in the SGSN, it rejectsthe request.

When the SGSN receives a paging request over the Gs interface for an IMSI unknown in the SGSN and the SGSN hasnot completed recovery, then the SGSN may page the MS for packet services with IMSI as identifier in the areaspecified by the location information provided by the MSC/VLR. If no such location information is provided, then theSGSN may page the MS in the routeing areas corresponding to that MSC/VLR. After the MS performs a combinedGPRS attach, the SGSN may continue serving the Gs interface paging request.

13.6.3 GGSN Failure

When a GGSN fails, all its PDP contexts affected by the failure become invalid and may be deleted. GGSN storage ofsubscriber data is volatile.

When the GGSN receives a GTP PDU for which no PDP context exists, it shall discard the GTP PDU and return anerror indication to the originating SGSN. The SGSN shall mark the related PDP context as invalid and send aDeactivate PDP Context Request message to the MS. The MS may then reactivate the PDP context.

13.6.4 VLR Failure

When a VLR fails, all its associations with SGSNs affected by the failure become invalid and may be deleted. Based onconfiguration data, the MSC/VLR sends a BSSAP+ Reset message to each of its associated SGSNs. The SGSNs markall associations containing the restarted VLR as invalid. After receipt of the first valid LLC frame from an MS that isboth GPRS-attached and IMSI-attached, the SGSN shall return a Detach Request (Detach Type) message in order torequest the MS to perform a combined RA / LA update. Detach Type shall be set to IMSI Detach. The detach proceduremay be delayed by the SGSN for a maximum operator-configuration depending time period to avoid high signallingload.

ETSI


14 Identities

14.1 IMSIA unique International Mobile Subscriber Identity (IMSI) shall be allocated to each mobile subscriber in GSM. This isalso the case for GPRS-only mobile subscribers, except for anonymous-only access subscribers. IMSI is defined inGSM 03.03 [4].

14.2 Packet TMSIA Packet Temporary Mobile Subscriber Identity shall be allocated to each GPRS-attached MS. P-TMSI is defined inGSM 03.03.

14.3 NSAPI and TLLIThe Network layer Service Access Point Identifier (NSAPI) and Temporary Logical Link Identity (TLLI) are used fornetwork layer routeing. An NSAPI / TLLI pair is unambiguous within a routeing area.

In the MS, NSAPI identifies the PDP-SAP. In the SGSN and GGSN, NSAPI identifies the PDP context associated witha PDP address. Between the MS and SGSN, TLLI unambiguously identifies the logical link.

When the MS requests the activation of a PDP context, the MS selects one of its unused NSAPIs.

NSAPI is a part of the tunnel identifier (TID).

For example (shown figuratively below), an X.25 packet is received by the MS from a connected TE at the X.121address SAP. The X.25 PDU is encapsulated and NSAPI is initialised to NSAPI-1. TLLI is set to the MS's TLLI beforethe encapsulated X.25 packet is passed to the SNDC function.

GGSN associated with:X.121 address

TLLI

X.121 address SAP

IP address SAP

NSAPI-1

NSAPI-2

Gi

GGSN associated with:IP address

Gi

GPRS MS

SGSN

X.25 /X.75

IP

Figure 53: Use of NSAPI and TLLI

Within a routeing area, there is a one-to-one correspondence between TLLI and IMSI that is only known in the MS andSGSN. If it is not clear from the context which routeing area a TLLI belongs to, then TLLI is used together with RAI.TLLI is derived from a P-TMSI, and does then provide user identity confidentiality as described in subclause "UserIdentity Confidentiality".

The TLLI address range is divided into four ranges: Local, Foreign, Random, and Auxiliary. The TLLI structure allowsthe MS and SGSN to deduce the range that a TLLI belongs to. A Local TLLI is derived from the P-TMSI allocated bythe SGSN, and is valid only in the RA associated with the P-TMSI. A Foreign TLLI is derived from a P-TMSI allocatedin another RA. A Random TLLI is selected randomly by the MS, and is used when the MS does not have a validP-TMSI available, or when the MS originates an anonymous access. An Auxiliary TLLI is selected by the SGSN and isused by the SGSN and MS to unambiguously identify an Anonymous Access MM and PDP Context.

ETSI


If the MS has a valid P-TMSI associated with the RA where the MS is currently located, then the MS shall use a LocalTLLI derived from its P-TMSI, unless the MS performs a GPRS attach.

If the MS does not have a valid P-TMSI associated with the current RA, or if the MS performs a GPRS attach, then itshall derive a Foreign TLLI from its P-TMSI, or allocate a Random TLLI if no valid P-TMSI is available.

When a TLLI is exchanged between the MS and an SGSN, then the TLLI is transmitted at the RLC/MAC layer withinthe Um protocol stack, and at the BSSGP layer within the Gb protocol stack. NSAPI is transmitted within the SNDCPlayer in the transmission plane, and within the GMM/SM layer in the signalling plane. NSAPI is represented by atransaction identifier (TI) in some SM signalling messages. The TI is dynamically allocated by the MS for MS-requested (AA) PDP context activation, and by the network for network-requested PDP context activation. The TI isdeallocated when a PDP context has been deactivated. TI usage is defined in GSM 04.07 and GSM 04.08.

By default, unless explicitly specified in the procedures, the TLLI transmitted at the RLC/MAC and BSSGP layers shallbe used to identify the MS.

14.4 PDP AddressA GPRS subscriber identified by an IMSI, shall have one or more network layer addresses, i.e., PDP addresses,temporarily and/or permanently associated with it that conforms to the standard addressing scheme of the respectivenetwork layer service used, e.g.:

- an IP version 4 address;

- an IP version 6 address; or

- an X.121 address.

PDP addresses are activated and deactivated through MM procedures described in subclause "PDP Context Activation,Modification, and Deactivation Functions".

14.5 TIDA Tunnel Identifier (TID) is used by the GPRS Tunnelling protocol between GSNs to identify a PDP context. A TIDconsists of an IMSI and an NSAPI. The combination of IMSI and NSAPI uniquely identifies a single PDP context.

The TID is forwarded to the GGSN upon PDP Context Activation and it is used in subsequent tunnelling of user databetween the GGSN and the SGSN to identify the MS's PDP contexts in the SGSN and GGSN. The TID is also used toforward N-PDUs from the old SGSN to the new SGSN at and after an inter SGSN routeing area update.

In the anonymous access case, AA-TID is allocated locally by the SGSN. An AA-TID consists of an A-TLLI and anNSAPI similar to TID. Since the IMSI is longer than A-TLLI, the unused digits shall be used to create a unique identitywithin one PLMN. The allocated AA-TID shall not collide with the TID address space.

14.6 Routeing Area IdentityRouteing Area Identity (RAI), defined by an operator, identifies one or several cells. RAI is broadcast as systeminformation and is used by the MS to determine, when changing cell, if an RA border was crossed. If that was the case,the MS initiates the RA update procedure.

The location of an MS in STANDBY state is known in the SGSN on an RA level. Cells that do not support GPRSwithin an LA are grouped by the SGSN and BSS into a null RA. The MS is paged for packet services in the RA wherethe MS is located when mobile-terminated traffic arrives in the SGSN. The MS is paged for circuit-switched services bythe SGSN in the last known RA plus in the null RA.

NOTE: Cells not supporting GPRS and served by a BSC without a Gb interface should not be included in thesame location area as cells not supporting GPRS and served by a BSC with a Gb interface.

A Routeing Area is a subset of one, and only one, Location Area (LA), meaning that an RA cannot span more than oneLA. An RA is served by only one SGSN.

ETSI


The following rules apply for the Routeing Area Identity:

- RAC is only unique when presented together with LAI;

- CI is only unique when presented together with LAI or RAI;

- LAI = MCC + MNC + LAC;

- RAI = MCC + MNC + LAC + RAC;

- CGI = LAI + CI.

14.7 Cell IdentityCell Identity (CI) identifies one cell. CI is defined in GSM 03.03.

14.8 GSN Addresses

14.8.1 GSN Address

Each SGSN and GGSN shall have an IP address, either of type IPv4 or IPv6, for inter-communication over the GPRSbackbone network. The IP addresses of GSNs and other GPRS backbone nodes of all PLMNs build a private addressspace that is not accessible from the public Internet. For the GGSN and the SGSN, this IP address may also correspondto one or more DNS-type logical GSN names.

14.8.2 GSN Number

Each SGSN shall have an SGSN number for communication with e.g., HLR and EIR.

Each GGSN that supports the optional SS7-based Gc interface shall have a GGSN number for communication withHLRs.

14.9 Access Point NameIn the GPRS backbone, Access Point Name is a reference to the GGSN to be used. In addition, Access Point Namemay, in the GGSN, identify the external network. Access Point Name is composed of two parts as defined inGSM 03.03:

- the APN Network Identifier is mandatory and is a label (for example "corporation") or a set of labels separatedby dots which is a fully qualified domain name according to the DNS naming conventions (for example"company.com"). In order to guarantee the uniqueness of the APN, the GPRS PLMN should allocate, to an ISPor corporation, an APN Network Identifier identical to their domain name in the public Internet. The APNNetwork Identifier shall not end with ".gprs";

- the APN Operator Identifier is optional. It is a fully qualified domain name according to the DNS namingconventions, and consists of three labels. The APN Operator Identifier shall end in ".gprs". For example, it maybe "MNCyyyy.MCCzzzz.gprs". The exact format is defined in GSM 09.60.

The APN stored in the HLR shall not contain the APN Operator Identifier. A wild card may be stored in the HLRinstead of the APN. This wild card indicates that the user may select an APN that is not stored in the HLR. The use ofthe wild card is described in annex A.

ETSI


15 Operational Aspects

15.1 ChargingCharging information in the GPRS network is collected for each MS by SGSNs and GGSNs that are serving the MS.

The information that the operator uses to generate a bill to a subscriber is operator-specific. Billing aspects, e.g., aregular fee for a fixed period, are outside the scope of the present document.

Every GPRS operator collects and processes their own charging information.

The SGSN collects charging information for each MS related with the radio network usage while the GGSN collectscharging information for each MS related with the external data network usage. Both GSNs also collect charginginformation on usage of the GPRS network resources.

15.1.1 Charging Information

Charging information is collected for the GPRS subscriber.

As a minimum, the SGSN shall collect the following charging information:

- usage of the radio interface: the charging information shall describe the amount of data transmitted in MO andMT directions categorised with QoS and user protocols;

- usage of the packet data protocol addresses: the charging information shall describe how long the MS has usedthe packet data protocol addresses;

- usage of the general GPRS resources: the charging information shall describe the usage of other GPRS-relatedresources and the MS's GPRS network activity (e.g., mobility management); and

- location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information.

As a minimum, the GGSN shall collect the following charging information:

- destination and source: the charging information shall describe the destination and source addresses with a levelof accuracy as defined by the GPRS operator;

- usage of the external data networks: the charging information shall describe the amount of data sent and receivedto and from the external data network;

- usage of the packet data protocol addresses: the charging information shall describe how long the MS has usedthe PDP addresses; and

- location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information.

15.1.2 Reverse Charging

It shall be possible to provide reverse charging as a subscription option. However, reverse charging may not beapplicable to certain external data network protocols.

15.2 Quality of Service ProfileA QoS profile is associated with each PDP context. The QoS profile is considered to be a single parameter withmultiple data transfer attributes. It defines the quality of service expected in terms the following attributes:

- precedence class;

- delay class;

- reliability class;

ETSI


- peak throughput class; and

- mean throughput class.

There are many possible QoS profiles defined by the combinations of the attributes. A PLMN may support only alimited subset of the possible QoS profiles.

During the QoS profile negotiation defined in subclause "Activation Procedures", it shall be possible for the MS torequest a value for each of the QoS attributes, including the HLR-stored subscribed default values. The network shallnegotiate each attribute to a level that is in accordance with the available GPRS resources. The network shall alwaysattempt to provide adequate resources to support the negotiated QoS profiles.

The RLC/MAC layer supports four radio priority levels and an additional level for signalling messages as defined inGSM 03.64 and GSM 04.60. Upon uplink access the MS can indicate one of the four priority levels, and whether thecause for the uplink access is user data or signalling message transmission. This information is used by the BSS todetermine the radio access precedence (i.e., access priority) and the service precedence (i.e., transfer priority undercongested situation), see GSM 04.60. The radio priority levels to be used for transmission of MO SMS shall bedetermined by the SGSN and delivered to the MS in the Attach Accept message. The radio priority level to be used foruser data transmission shall be determined by the SGSN based on the negotiated QoS profile and shall be delivered tothe MS during the PDP Context Activation and PDP Context Modification procedures.

15.2.1 Precedence Class

Under normal operating conditions, the network shall attempt to meet the service commitments of all QoS profiles. Theservice precedence indicates the relative importance of maintaining the service commitments under abnormalconditions, for example which packets are discarded in the event of problems such as limited resources or networkcongestion. The precedence classes are defined in table 12.

Table 12: Precedence Classes

Precedence Precedence Name Interpretation1 High priority Service commitments shall be maintained ahead of precedence classes 2 and 3.2 Normal priority Service commitments shall be maintained ahead of precedence class 3.3 Low priority Service commitments shall be maintained after precedence classes 1 and 2.

15.2.2 Delay Class

GSM 02.60 defines four delay classes (1 to 4). The network operator should provision adequate transmission resourceson the radio and network communication channels in order to support the expected number of subscribers within eachcell at a given delay class. A PLMN may support only a subset of the delay classes. As a minimum, the PLMN shallsupport the best effort delay class (4).

15.2.3 Reliability Class

Data reliability is defined in terms of the residual error rates for the following cases (see GSM 02.60):

- probability of data loss;

- probability of data delivered out of sequence;

- probability of duplicate data delivery; and

- probability of corrupted data.

The reliability class specifies the requirements of the various network protocol layers. The combinations of the GTP,LLC, and RLC transmission modes support the reliability class performance requirements. TCP is used to transport userdata on the GPRS backbone network in acknowledged GTP mode, while UDP is used in unacknowledged GTP mode.The reliability classes are summarised in table 13.

ETSI


Table 13: Reliability Classes

ReliabilityClass

GTP Mode LLC Frame Mode LLC DataProtection

RLC Block Mode Traffic Type

1 Acknowledged Acknowledged Protected Acknowledged Non real-time traffic, error-sensitive application thatcannot cope with data loss.

2 Unacknowledged Acknowledged Protected Acknowledged Non real-time traffic, error-sensitive application thatcan cope with infrequentdata loss.

3 Unacknowledged Unacknowledged Protected Acknowledged Non real-time traffic, error-sensitive application thatcan cope with data loss,GMM/SM, and SMS.

4 Unacknowledged Unacknowledged Protected Unacknowledged Real-time traffic, error-sensitive application thatcan cope with data loss.

5 Unacknowledged Unacknowledged Unprotected Unacknowledged Real-time traffic, error non-sensitive application thatcan cope with data loss.

NOTE: For real-time traffic, the QoS profile also requires appropriate settings for delay and throughput.

Each reliability class in combination with the Reordering Required information specifies the target residual error ratesfor a PDP context. The residual error rate targets are given in GSM 02.60. A PLMN may support only a subset of thereliability classes. Signalling and SMS shall be transferred with reliability class 3.

15.2.4 Throughput Classes

User data throughput is specified in terms of a set of throughput classes that characterise the expected bandwidthrequired for a PDP context. The throughput is defined by both peak and mean classes.

15.2.4.1 Peak Throughput Class

The peak throughput is measured at the Gi and R reference points in units of octets per second. It specifies themaximum rate at which data is expected to be transferred across the network for an individual PDP context. There is noguarantee that this peak rate can be achieved or sustained for any time period, this depends upon the MS capability andavailable radio resources. The network may limit the subscriber to the negotiated peak data rate, even if additionaltransmission capacity is available. The peak throughput is independent of the delay class, that determines the per-packetGPRS network transit delay. The peak throughput classes are defined in table 14.

Table 14: Peak Throughput Classes

Peak Throughput Class Peak Throughput in octets per second1 Up to 1 000 (8 kbit/s).2 Up to 2 000 (16 kbit/s).3 Up to 4 000 (32 kbit/s).4 Up to 8 000 (64 kbit/s).5 Up to 16 000 (128 kbit/s).6 Up to 32 000 (256 kbit/s).7 Up to 64 000 (512 kbit/s).8 Up to 128 000 (1 024 kbit/s).9 Up to 256 000 (2 048 kbit/s).

ETSI


15.2.4.2 Mean Throughput Class

The mean throughput is measured at the Gi and R reference points in units of octets per hour. It specifies the averagerate at which data is expected to be transferred across the GPRS network during the remaining lifetime of an activatedPDP context. The network may limit the subscriber to the negotiated mean data rate (e.g., for flat-rate charging), even ifadditional transmission capacity is available. A "best effort" mean throughput class may be negotiated, and means thatthroughput shall be made available to the MS on a per need and availability basis.

The mean throughput classes are defined in table 15.

Table 15: Mean Throughput Classes

Mean Throughput Class Mean Throughput in octets per hour1 100 (~0.22 bit/s).2 200 (~0.44 bit/s).3 500 (~1.11 bit/s).4 1 000 (~2.2 bit/s).5 2 000 (~4.4 bit/s).6 5 000 (~11.1 bit/s).7 10 000 (~22 bit/s).8 20 000 (~44 bit/s).9 50 000 (~111 bit/s).

10 100 000 (~0.22 kbit/s).11 200 000 (~0.44 kbit/s).12 500 000 (~1.11 kbit/s).13 1 000 000 (~2.2 kbit/s).14 2 000 000 (~4.4 kbit/s).15 5 000 000 (~11.1 kbit/s).16 10 000 000 (~22 kbit/s).17 20 000 000 (~44 kbit/s).18 50 000 000 (~111 kbit/s).31 Best effort.

16 Interactions with Other GSM ServicesThis clause describes the interaction between GPRS and the following other GSM services:

- point-to-point Short Message Service (SMS);

- circuit-switched services; and

- supplementary services.

16.1 Point-to-point Short Message ServiceIt shall be possible for a GPRS-attached MS to send and receive short messages over GPRS radio channels. An MS thatis GPRS-attached and not IMSI-attached shall transfer SMs over GPRS channels. MSs that are both GPRS-attached andIMSI-attached shall transfer SMs over GPRS channels or over non-GPRS control channels (if non-GPRS controlchannels are used, then paging for MT SMS may go through the SGSN).

The following two subclauses define the operation of mobile-terminated and mobile-originated SMS routeing andtransfer over GPRS radio channels. More detailed definitions are contained in GSM 03.40 [8].

ETSI


16.1.1 Mobile-terminated SMS Transfer

Figure 54 and the description below show an example of a successful delivery of a SM to an MS over a GPRS radiochannel.

MS BSS SGSN GGSN MSC/VLR HLR SMS-G SM-SC| | | | | | | || | | | | | |<----| Message Transfer 1| | | | | | | | (SM, MS Address)| | | | | |<----| | Send Routeing Info For Short Message 2| | | | | | | || | | | | |---->| | Send Routeing Info For Short Message Result 3| | | | | | | | (SGSN Number, MSC Number)| | |<----|-----|-----|-----| | Forward Short Message 4| | | | | | | | (SM)|<----|---->| | | | | | Message Transfer 5| | | | | | | | (SM)| | |-----|-----|-----|---->| | Forward Short Message Result 6| | | | | | | || | | | | | |---->| Delivery Report 7| | | | | | | |

Figure 54: MT SMS Transfer, Successful

1) The short message service centre determines it shall send a SM to an MS. SM-SC forwards the SM to a SMSgateway MSC (SMS-GMSC).

2) SMS-GMSC examines the destination MS Address, and sends a Send Routeing Info For Short Message messageto the relevant HLR.

3) HLR returns a Send Routeing Info For Short Message Result message to the SMS-GMSC. The result maycontain the MS's current SGSN Number, the MSC Number, or both. If the result does not contain an SGSNNumber (i.e., the HLR knows that the MS is not reachable via an SGSN), and if the result does contain an MSCNumber, then non-GPRS SMS delivery procedures are followed. If the result contains an SGSN Number, theSMS transfer proceeds according to the following events.

NOTE: SMS delivery via the SGSN is normally more radio resource efficient than SMS delivery via theMSC/VLR. The preferred delivery path is selected by SMS-GMSC operator-specific action.

4) SMS-GMSC forwards the SM to the SGSN.

5) SGSN transfers the SM to the MS on the RP, CP, LLC layers, as defined in GSM 04.11 and GSM 04.64.

6) SGSN returns a Forward Short Message Result message to the SMS-GMSC indicating successful delivery of theSM.

7) SMS-GMSC returns a Delivery Report to the SM-SC indicating successful delivery of the SM.

16.1.1.1 Unsuccessful Mobile-terminated SMS Transfer

The SGSN may not be able to deliver the SM to the MS. This may for example happen when the MS is not attached toGPRS, or when the radio channel conditions are bad.

When the SGSN cannot deliver the SM to the MS, the SGSN sets the Mobile station Not Reachable for GPRS flag(MNRG), and returns a failure report to the SMS-GMSC. Based on the routeing information received from the HLR,the SMS-GMSC shall do one of the following:

- If an MSC/VLR is available for the MS, the SM is forwarded to the MS via the MSC/VLR. A successfuldelivery report shall be returned to the SM-SC.

- If an MSC/VLR is not available for the MS, the Message Waiting Indication information in the HLR shall beupdated and an unsuccessful delivery report shall be returned to the SM-SC.

ETSI


Figure 55 illustrates one possible traffic scenario when neither the SGSN nor the MSC is able to deliver the SM.

MS BSS SGSN GGSN MSC/VLR HLR SMS-G SM-SC| | | | | | | || | | | | | |<----| Message Transfer 1| | | | | | | | (SM, MS Address)| | | | | |<----| | Send Routeing Info For Short Message 2| | | | | | | || | | | | |---->| | Send Routeing Info For Short Message Result 3| | | | | | | | (SGSN Number, MSC Number)| | |<----|-----|-----|-----| | Forward Short Message 4| | | | | | | | (SM)|<----|---->| | | | | | Message Transfer: Failure 5| | | | | | | | (SM)| | |-----|-----|-----|---->| | Forward Short Message Result 6| | | | | | | || | | | |<----|-----| | Forward Short Message 7| | | | | | | | (SM)|<----|-----|-----|---->| | | | Message Transfer: Failure 8| | | | | | | | (SM)| | |<----|-----| | | | Alert Request 9| | | | | | | || | | | |-----|---->| | Forward Short Message Result 10| | | | | | | || | | | | |<----| | Report SM Delivery Status 11| | | | | | | || | | | | |---->| | Report SM Delivery Status Result 12| | | | | | | || | | | | | |---->| Failure Report 13| | | | | | | |

Figure 55: MT SMS Transfer, Unsuccessful

1) The short message service centre determines it shall send a SM to an MS. SM-SC forwards the SM to a SMS-GMSC.

2) SMS-GMSC examines the destination MS Address, and sends a Send Routeing Info For Short Message messageto the relevant HLR.

3) HLR returns a Send Routeing Info For Short Message Result message to the SMS-GMSC. The Result containsan SGSN Number and an MSC Number.

4) SMS-GMSC forwards the SM to the SGSN.

5) SGSN attempts to transfer the SM to the MS, but fails.

6) SGSN sets MNRG and returns a Forward Short Message Result message to SMS-GMSC indicating unsuccessfuldelivery of the SM.

7) SMS-GMSC selects an alternative route for the SMS, and forwards the SM to the MSC/VLR.

8) MSC/VLR attempts to transfer the SM to the MS, but fails.

9) The MSC/VLR requests the setting of the NGAF at the SGSN.

10)VLR sets MNRF and returns a Forward Short Message Result message to the SMS-GMSC indicatingunsuccessful delivery of the SM.

11)SMS-GMSC sends a Report SM Delivery message to the HLR.

12)HLR updates its Message Waiting Indication fields and returns a Report SM Delivery Result message to theSMS-GMSC.

13)SMS-GMSC returns a Failure Report to the SM-SC indicating unsuccessful delivery of the SM.

Figure 38 shows that the SGSN sends a Ready for SM (MS Reachable) message to the HLR when the MS becomesreachable and MNRG is set in the SGSN. The SGSN indicates also to the MSC/VLR when the MS becomes reachableand NGAF is set in the SGSN. If the MNRF is set at the MSC/VLR, the MSC/VLR sends a Ready for SM (MSReachable) message to the HLR. Reception of a Ready for SM message or Update Location message when MNRG isset in the HLR shall trigger the SMS alert procedure as defined in GSM 03.40.

ETSI


MNRG remains set in the SGSN independently of whether the MSC/VLR was successful in delivering the SM or not.This means that the SGSN in certain cases sends a Ready for SM message to the HLR when an MS becomes reachablevia the SGSN, even if no SM is waiting. This causes a small amount of duplicate signalling between SGSN and HLRonly.

16.1.2 Mobile-originated SMS Transfer

Figure 56 and the description below explain the steps involved in sending a SM from an MS over a GPRS radiochannel.

MS BSS SGSN GGSN MSC/VLR HLR SMS-IW SM-SC| | | | | | | ||<----|---->| | | | | | Message Transfer 1| | | | | | | | (SM)| | |-----|-----|-----|---->| | Forward Short Message 2| | | | | | | | (SM)| | | | | | |---->| Message Transfer 3| | | | | | | | (SM)| | | | | | |<----| Delivery Report 4| | | | | | | || | |<----|-----|-----|-----| | Forward Short Message Result 5| | | | | | | ||<----|-----| | | | | | Delivery Report 6| | | | | | | |

Figure 56: MO SMS Transfer, Successful

1) The MS has a SM to send, and transfers the SM to the SGSN via RP, CP, and LLC.

2) SGSN checks the MS subscription data, and determines that the MS is allowed to originate the SMS. SGSNforwards the SM to a SMS interworking MSC (SMS-IWMSC).

3) SMS-IWMSC passes the SM to the addressed SM-SC.

4) SM-SC returns a Delivery Report to the SMS-IWMSC indicating successful delivery of the SM.

5) SMS-IWMSC returns a Forward Short Message Result message to the SGSN indicating successful delivery ofthe SM.

6) SGSN returns a Delivery Report to the MS indicating successful delivery of the SM.

16.2 Circuit-switched ServicesThe ability for a GPRS user to access circuit-switched services depends on the subscription held, the networkcapabilities, and the MS capabilities. Interaction between GPRS and circuit-switched services is described in subclause"Interactions Between SGSN and MSC/VLR".

16.2.1 Suspension of GPRS Services

When a GPRS-attached MS enters dedicated mode, and when the MS limitations make it unable to communicate onGPRS channels, the MS shall request the network for suspension of GPRS services. The Suspend and Resumeprocedure is illustrated in figure 57. Each step is explained in the following list.

ETSI


2. Suspend


1. Dedicated Mode Entered

MS BSS SGSN MSC/VLR

3. Suspend

4. Resume

5. Channel Release

3. Suspend Ack

4. Resume Ack

Figure 57: Suspend and Resume Procedure

1) The MS enters dedicated mode.

2) The MS sends an RR Suspend (TLLI, RAI) message to the BSS. The BSS may terminate any ongoing GPRStraffic for this TLLI.

3) The BSS sends a Suspend (TLLI, RAI) message to the SGSN, and the SGSN acknowledges by returningSuspend Ack. The BSS shall store TLLI and RAI in order to be able to request the SGSN to resume GPRSservices when the MS leaves dedicated mode.

4) Eventually, the BSS determines that the circuit-switched radio channel shall be released. If the BSS is able torequest the SGSN to resume GPRS services, the BSS shall send a Resume (TLLI, RAI) message to the SGSN.The SGSN acknowledges the successful outcome of the resume by returning Resume Ack.

5) The BSS sends an RR Channel Release (Resume) message to the MS. Resume indicates whether the BSS hassuccessfully requested the SGSN to resume GPRS services for the MS, i.e., whether Resume Ack was receivedin the BSS before the RR Channel Release message was transmitted. The MS leaves dedicated mode.

6) If the BSS did not successfully request the SGSN to resume GPRS services, or if the RR Channel Releasemessage was not received before the MS left dedicated mode, then the MS shall resume GPRS services bysending a Routeing Area Update Request message to the SGSN, as described in subclause "Routeing AreaUpdate Procedure".

The full handling of suspended MSs in the BSS and the SGSN is implementation dependent. Typically, the SGSNshould not page suspended MSs.

If the MS performs an inter-BSC handover while suspended, then TLLI and RAI should be transferred as BSC-to-BSCinformation in the Handover Required and Handover Request messages, see GSM 08.08. This allows the new BSC toinitiate the Resume request procedure to the SGSN. In the case where the BSC-to-BSC information was not transferredor not understood, then the MS doesn’t receive an indication that resumption has been successful, and the MS shallresume GPRS services by initiating a Routeing Area Update Request procedure as described in step 6.

16.2.2 GPRS and Dedicated Mode Priority Handling

An MS in class-B mode of operation that communicates on GPRS radio channels when a dedicated channel is needed,shall immediately abort the GPRS communication and trigger the Suspend and Resume procedure.

Response to circuit-switched paging, non-emergency MO circuit-switched calls, MO SMS, and MO supplementaryservices are exceptions to the above rule. In these cases, it is an implementation choice whether to immediately abortGPRS communication or to delay the dedicated mode establishment.

ETSI


16.3 Supplementary ServicesNo supplementary services are defined for GPRS. Supplementary services may be available in the interworked-withnetworks (e.g., the X.25 Call Redirection user facility), but this is outside the scope of this specification.

ETSI


Annex A (normative):APN and GGSN SelectionThis annex contains the rules applied upon PDP context activation to determine the APN and the corresponding GGSN.

A.1 DefinitionsThe SGSN knows from the subscription data the parameters (S for Subscribed): PDP type (S), PDP address (S),APN (S), and VPLMN address allowed.

The SGSN may know from configuration the default APN supporting a given PDP type. This APN is calledAPN (SGSN) and does not include an APN Operator Identifier.

The SGSN knows the parameters requested by the MS (R for Requested): PDP type (R), PDP address (R), andAPN (R). APN (R) is the APN Network Identifier requested by the MS.

In case of "an APN chosen by the SGSN" the activated PDP context is always linked with a dynamic PDP address.

An MS may have multiple subscription records for the same PDP type and the same PDP address, but with differentAPNs.

An MS may have one or two subscription records with the same PDP type and the same APN: one with a static PDPaddress, one with a dynamic PDP address.

When the MS is in its HPLMN, if the MS requests an APN that does not correspond to any GGSN of its HPLMN, therequest shall be rejected by SGSN. When the MS is in a VPLMN, if the MS requests an APN that does not correspondto any GGSN of its HPLMN nor of this VPLMN, the request shall be rejected by SGSN.

If APN (S) = wild card (see GSM 03.03), it means either:

- that a default APN (a default PDN) has to be chosen by the SGSN (APN (SGSN)) if no APN (R) has beenprovided; or

- that a PDP context with dynamic PDP address may be activated towards any APN requested by the MS.

In order to derive APN (R) from the APN sent by the MS, the SGSN shall check if the APN sent by the user ends with".gprs". If not, then APN (R) is equal to APN sent by the MS. If yes, then APN (R) is the APN sent by the MS withoutthe three last labels.

A.2 APN Selection RulesThe SGSN shall select the APN to be used to derive the GGSN address, and set the selection mode parameter accordingto the rules in the SDL diagrams in this subclause. The following definitons apply to the SDL diagrams:

AddrMode: Addressing Mode.

APN-OI: APN Operator Identifier.

HPLMN-OI: HPLMN APN Operator Identifier.

Number <condition>: determines the PDP context subscription records that satisfy the given condition.

PDPaddr: PDP address.

SelMode := ChosenBySGSN: Network-provided APN, subscription not verified.

SelMode := SentByMS: MS-provided APN, subscription not verified.

SelMode := Subscribed: MS or Network-provided APN, subscription verified.

ETSI


SelMode: Selection Mode.

VPLMN-OI: VPLMN APN Operator Identifier.

+: concatenation operation.

Activate PDPContext Request

PDPtype(R)

PDPtype(R)pres entPDPaddr(R)

APN(R)

Single PDP contextsubscr ibed

PDPaddr(S) inPDP contex t

AddrMode :=Dynamic

AddrMode :=Static

APN(S) =wildcard

Activate PDPContext Reject

PDPtype :=PDPtype(S)SelMode :=

ChosenBySGSN

APN := APN(S)SelMode := Subscribed

2 3

present

not present

not present

present

not present

present

yes

no

no

yes

yes

no

Figure A.1: SDL Diagram 1

ETSI


PDPtype(R)present

NumberPDPtype(R) = PDPtype(S)

PDPaddr(R)

PDPaddr(R)present APN(R)

APN(R)not presentNumber

APN(R) = APN(S)

Num berAPN( S) = wildcard

APN := APN(R)SelMode := SentByMS

1

Activate PDPContex t Reject

NumberPDPaddr(S) = dynamic

AddrMode :=Dynamic

APN := APN( R)SelMode := Subscribed

1

PDPaddr( S) inPDP context

AddrMode :=Static

ELSE

present

not present

not presentpresent

0

1

ELSE

ELSE

1

0

1

no yes

0


ETSI


APN(R)not present

PDPaddr(R)present

NumberAPN(S) = wildc ard

NumberPDPaddr (R) = PDPaddr(S)

APN(R)

NumberPDPtype(R) = PDPtype(S)

APN(R)

NumberAPN(R) = APN(S)

SelMode :=ChosenBySGSN APN := APN(R)

SelMode := Subscr ibed

APN := APN(S)SelM ode := Subscribed

APN := APN(S)SelMode := Subscribed

2 3Activate PDPContext Reject 1 3

0

1ELSE

10

present

not present

1

ELSE

present

not present

1

0


ETSI


3The APN from the singlePDP context was selected

1 An APN was sent by the MS

APN-OI in APN(R)

APN-OI is HPLMN

VPLMN Address Allowed

APN-OI is VPLMN


c a bActivate PDPContext Reject

yes

no

no

yes

yes

no

yes

no

yes

no


ETSI


2A default APN is to bechosen by the SGSN

User locatedin HPLMN


APN(SGSN) forPDPtype known

APN :=APN(SGSN)

bActivate PDPContext Reject

APN(SGSN) forPDPtype known

APN :=APN(SGSN)

a

no

yes

yes

no

no

yes

yes

no


ETSI


a

Access requestedin HPLMN

Interrogate DNS withAPN + HPLMN-OI

DNS result

Activate PDPContext Reject

Create PDPContext Request

b

Access requestedin VPLMN only

Interrogate DNS withAPN + VPLMN-OI

c

Access requestedin VPLMN first

Interrogate DNS withAPN + VPLMN-OI

DNS result

a

fail

suc cess success

fail


ETSI


Annex B (normative):Internet-Hosted Octet Stream ServiceThe GPRS Internet-Hosted Octet Stream Service (IHOSS) is a connection-oriented service that can transport anunstructured octet (character) stream between a GPRS MS and an Internet host. The service uses the Octet StreamProtocol (OSP) PDP type to provide a 'character pipe' between the MS and the GGSN. In the GGSN there is aninterworking function which provides a relay function between the OSP and the Internet host.

Figure B.1 shows the scope of IHOSS and OSP.

Gi

InternetDTE

UmR

GPRS network

Host

IHOSS OSP

MT GGSN

Figure B.1: Scope of IHOSS and OSP

IHOSS is analogous to a virtual serial cable between the MS and the Internet host.

This service is intended to provide a very simple connection for early implementation and for simple low-cost deviceslater on in the life cycle of GPRS.

B.1 Direction of Connection SetupThis service shall be mobile-originated only.

B.2 BearerThe IHOSS shall use the unstructured Octet Stream Protocol as its bearer service.

The MT end of the IHOSS connection shall use the octet mode interface to the OSP as a Packet Assembler /Disassembler function is necessary.

The GGSN end of the IHOSS connection shall use the block mode interface to the OSP to remove the need for twoback-to-back PAD functions.

B.3 Setup DataThe following data items are required before an octet stream can be initiated.

B.3.1 Protocol Type – TCP or UDPThis refers to the protocol used over IP on the GGSN to Internet host segment of the connection. The options availableare TCP or UDP.

If no protocol is specified for a given context, TCP shall be used.

ETSI


B.3.2 Host NameThis refers to the Internet host to which the connection is made. It shall be a fully formed domain name extended hostname.

There shall be no default host name. If no host name is specified, the context activation shall fail.

B.3.3 Port NumberThis refers to the TCP or UDP port on the host name, which forms the endpoint of the Internet side of the connection.

If no port number is specified for a given context, a default value of 23 decimal shall be used.

B.3.4 PAD ParametersThe Packet Assembler / Disassembler parameters determine how to fill the outgoing packets. If the user requiresinteractive terminal style behaviour then the PAD shall be able to act in this way. If the user requires a streaming datalink then a different setup is necessary.

The default values for the PAD parameters are defined in GSM 07.60.

B.4 Flow ControlThe service shall use the flow control features provided by the OSP to provide simple start / stop flow control.

B.5 Break SignalThe OSP break signals are mapped onto the appropriate break signals at the R and Gi interfaces.

B.6 Connection Establishment ProcedureEstablishing an IHOSS connection involves setting up two segments, the PLMN segment (using the OSP) between theMS and the GGSN, and the fixed-network segment between the GGSN and the Internet host. Establishing the PLMNsegment shall be as described in subclause "PDP Context Activation Procedure". Figure B.2 illustrates the overallprocedure.

Internet connection setup

Activate OSP PDP context request

MS GGSN Internet Host

Figure B.2: IHOSS Connection Establishment

The MS requests that an OSP PDP context be activated by transmitting an Activate PDP Context Request (NSAPI, TI,PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN withthe following parameter values:

- NSAPI is selected by the MS.

- TI is selected by the MS.

ETSI


- PDP Type shall have a two-part value. The first part shall identify the protocol as OSP, and the second part shallidentify the service being used and thereby allow the SGSN to select a GGSN that can provide this service. ForIHOSS PDP Type shall be set to OSP:IHOSS.

- PDP Address shall be empty.

- APN is selected by the MS, may be empty.

- QoS Requested is selected by the MS.

- PDP Configuration Options may contain an Internet host name, a port number, a protocol type, and possiblyother parameters in order to enable the GGSN to set up a connection to the Internet host, or it may be empty.

The Activate PDP Context Accept message shall be returned to the MS only after the connection to the Internet host hasbeen established.

The activation parameters shall be provided as either interactive commands or via a system-default value. The followingsections describe how these parameters shall be derived for a number of different scenarios.

B.6.1 Fully User-Specified EstablishmentThe MS shall request an OSP:IHOSS connection, specifying the PAD parameters, the host name, the port, and theprotocol (UDP or TCP) in PDP Configuration Options.

The SGSN shall select an appropriate GGSN for the outgoing connection.

The GGSN shall attempt to establish a connection with the specified host. Connection failure shall be signalled back tothe MS and the session terminated. A successful connection establishment enables data transmission over theconnection.

B.6.2 Default Internet Endpoint Parameters EstablishmentThe MS shall request an OSP:IHOSS connection, specifying only PAD parameters that deviate from the systemdefaults.

The SGSN shall connect to the GGSN indicated by the APN in the HLR subscription record.

The GGSN shall use the APN to further select the host name, the port number, and the protocol. The method used toselect these parameters is manufacturer specific and outside of the scope of the specifications.

B.7 Connection TerminationEither the MS or the Internet host may request that a connection be cleared.

B.7.1 MS-initiated TCP IHOSS Connection TerminationThe MS clears the connection by sending a Deactivate PDP Context Request message to the SGSN. This shall result inthe TCP session closure procedures being executed by the GGSN. Once this is complete, the GGSN shall deallocate anyresources allocated for this session.

B.7.2 MS-initiated UDP IHOSS Connection TerminationNo further action is required by the GGSN towards the Internet endpoint, as the User Datagram Protocol isconnectionless. The GGSN shall deallocate any resources allocated for this session.

ETSI


B.7.3 Internet Host Initiated TCP IHOSS Connection TerminationWhen the GGSN receives a TCP clear request from the fixed network it shall follows the procedure described insubclause "PDP Context Deactivation Initiated by GGSN Procedure".

B.8 Quality of ServiceThe QoS profile shall be negotiated to the following QoS attribute values:

- precedence: as required;

- delay: as required, but consistent with PAD forwarding strategy;

- reliability: Class 1 for TCP. Class 3 for UDP;

- peak throughput: as required;

- mean throughput: as required.

B.9 Security

B.9.1 Authentication of the GPRS UserIdentification and authentication of the subscriber by the GPRS network is carried out as described elsewhere in thisdocument. The GPRS network shall not provide any identification of the GPRS subscriber to the Internet host. End-to-end security is provided at the application layer and is outside of the scope of this document.

B.9.2 Malicious Reconfiguration of the GPRS DeviceAn MS that can not hold protocol, host name, and port information, would render it impossible to gain unauthorisedaccess and subvert the system by providing alternative protocol, host name, or port information. This information wouldhave to be provided by the GGSN, which is potentially more physically secure than the embedded MT, and it wouldmake "man in the middle" type security breaches considerably more complex.

B.10 MaintenanceConfiguring the Internet endpoint by accepting a mandatory default endpoint from the GGSN enables a GPRS user toeffect system reconfiguration without the requirement for a site visit for each GPRS MS. The association between theAPN and the host name, port number and protocol in the GGSN would be updated to give a new host name and/or portnumber and/or protocol.

ETSI


Annex C (informative):Data Transmission Routeing ExamplesExamples of the PDP PDU routeing are given below to clarify the GPRS routeing concept. It is assumed here that theMS has subscribed to a PDP type and a PDP address in the home PLMN and that this PDP address has been activated.

The contexts and the main parameters in the figures indicate which information is used to route the data to the correctnetwork nodes.

C.1 Data Routeing for an MS in its Home PLMN to andfrom an External PDN

Figure C.1 describes how the MS sends a PDP PDU (data packet) to an external data network and how PDP PDUs froman external data network are sent to an MS.

- TLLI and NSAPI identify the PDP context of the MS in the SGSN.

- TID identifies the PDP context in the SGSN and GGSN.

- To route MO packets, an SGSN needs to have a mapping from TLLI + NSAPI to GGSN + TID.

- To route MT packets, an SGSN needs to have a mapping from TID to TLLI + NSAPI.

MS BSS SGSN GGSN external PDN| | | | ||-----|---->| | | SNDCP PDU (TLLI, NSAPI, PDP PDU)| || | O Context: TLLI + NSAPI -> GGSN + TID| || | | | || | |--------->| | GTP PDU (TID, PDP PDU)| | || | | O Context: TID -> PDP context (PDP Address)| | || | | | || | | |--------->| PDP PDU| | | | |

| | | | || | | |<---------| PDP PDU| | || | | O Context: PDP Address -> TID -> SGSN + TID| | || | | | || | |<---------| | GTP PDU (TID, PDP PDU)| || | O Context: TID -> TLLI + NSAPI + RAI + CI| || | | | ||<----|-----| | | SNDCP PDU (TLLI, NSAPI, PDP PDU)| | | | |

Figure C.1: Data Routeing in HPLMN to and from an External PDN

ETSI


C.2 Data Routeing for a Roaming MS to and from anExternal PDN

This example is almost the same as the previous one. In this case, the MS has roamed to another PLMN and the SGSNthat is currently serving the MS is in a visited PLMN while the GGSN is in the home PLMN.

A mobile-terminated GTP PDU is carried from the GGSN to the SGSN via the home intra-PLMN backbone network tothe inter-PLMN backbone network and finally to the visited intra-PLMN backbone network.

- The routeing for MO and MT packets can be optimised if the activated PDP address is dynamically assigned bythe visited PLMN.

Visited PLMN Home PLMNMS BSS SGSN GGSN PDN GGSN external PDN| | | | | | ||-----|---->| | | | | SNDCP PDU (TLLI, NSAPI, PDP PDU)| | | | | | || || | O Context: TLLI + NSAPI -> GGSN + TID| || | |---------------->| | GTP PDU (TID, PDP PDU)| | | | | | || | | | || | | | | O Context: TID -> PDP context (PDP Address)| | | | || | | | | |---->| PDP PDU| | | | | | |

| | | | | | || | | | | |<----| PDP PDU| | | | || | | | | O Context: PDP Address -> TID -> SGSN + TID| | | | || | | | | | || | |<----------------| | GTP PDU (TID, PDP PDU)| | | | | | || || | O Context: TID -> TLLI + NSAPI + RAI + CI| || | | | | | ||<----|-----| | | | | SNDCP PDU (TLLI, NSAPI, PDP PDU)| | | | | | |

Figure C.2: Data Routeing for a Roaming MS to and from an External PDN

C.3 MS-to-MS Data Routeing via the Same GGSNThis example is basically the same as described in subclause "Data Routeing for an MS in its Home PLMN to and froman External PDN". When the GGSN receives the GTP PDU and decapsulates the PDP PDU, it detects that thedestination address is also in the GPRS network. Then, the PDP PDU that is sent by one MS is treated the same way asthe PDP PDU that is received from the external data network.

- In case of connection-oriented protocols (e.g., X.25) an additional DTE/DCE conversion may need to beperformed in the GGSN.

ETSI


MS1 BSS1 SGSN1 GGSN PDN| | | | ||-----|---->| | | SNDCP PDU (TLLI1, NSAPI1, PDP PDU)| || | O Context: TLLI1 + NSAPI1 -> GGSN + TID1| || | | | || | |--------->| | GTP PDU (TID1, PDP PDU)| | | | || | |

O Context: TID1 -> PDP context1 (PDP Address1)O Context: PDP Address2 -> TID2 -> SGSN2 + TID2

MS2 BSS2 SGSN2 | || | | | || | |<---------| | GTP PDU (TID2, PDP PDU)| || | O Context: TID2 -> TLLI2 + NSAPI2 + RA2 +CI2| || | | | ||<----|-----| | | SNDCP PDU (TLLI2, NSAPI2, PDP PDU)| | | | |

Figure C.3: MS-to-MS Data Routeing via the Same GGSN

C.4 MS-to-MS Data Routeing via Different GGSNsThis example is basically the same as described in subclause "MS-to-MS Data Routeing via the Same GGSN", with thedifference that the same GGSN is not handling the first MS's outgoing traffic and the second MS's incoming traffic. Inpractice, this means that when the first GGSN has extracted the destination address from the PDP PDU and detected thedestination subnetwork, its routeing table has a "short-cut" to the second GGSN. Instead of routeing the PDP PDU viaan external data network, it is possible to route it via the inter-PLMN backbone network.

- If the first GGSN does not know the short-cut from one operator to another, the PDP PDUs are transmitted viathe external data network. From the first GGSN's point of view, the second MS then resembles a normal fixednetwork node.

- In case of connection-oriented protocols (e.g., X.25) an additional DTE / DCE conversion may need to beperformed in the GGSN.

MS1 BSS1 SGSN1 GGSN1 GGSN2| | | | ||-----|---->| | | SNDCP PDU (TLLI1, NSAPI1, PDP PDU)| | | | || || | O Context: TLLI1 + NSAPI1 -> GGSN + TID1| || | | | || | |--------->| | TID1, PDP PDU| | | | || | || | | O Context: TID1 -> PDP context1 (PDP Address1)| | || | | | || | | |--------->| GTP PDU (PDP PDU)| | | | || | | |

| O Context: PDP Address2 -> TID2 -> SGSN2 + TID2|

MS2 BSS2 SGSN2 | || | | | || | |<--------------------| GTP PDU (TID2, PDP PDU)| | | | || || | O Context: TID2 -> TLLI2 + NSAPI2 + RA2 + CI2| || | | | ||<----|-----| | | SNDCP PDU (TLLI2, NSAPI2, PDP PDU)| | | | |

Figure C.4: MS-to-MS Data Routeing via Different GGSNs

ETSI


Annex D (informative):FiguresFigure 1: GPRS Access Interfaces and Reference Points..................................................................................................14

Figure 2: Overview of the GPRS Logical Architecture.....................................................................................................19

Figure 3: Intra- and Inter-PLMN Backbone Networks......................................................................................................20

Figure 4: Transmission Plane ............................................................................................................................................22

Figure 5: Signalling Plane MS - SGSN.............................................................................................................................23

Figure 6: Signalling Plane SGSN - HLR...........................................................................................................................23

Figure 7: Signalling Plane SGSN - MSC/VLR .................................................................................................................24

Figure 8: Signalling Plane SGSN - EIR ............................................................................................................................24

Figure 9: Signalling Plane SGSN - SMS-GMSC and SGSN - SMS-IWMSC ..................................................................24

Figure 10: Signalling Plane GSN - GSN...........................................................................................................................25

Figure 11: Signalling Plane GGSN - HLR Using MAP ....................................................................................................25

Figure 12: Signalling Plane GGSN - HLR Using GTP and MAP.....................................................................................26

Figure 13: Functional Mobility Management State Model ...............................................................................................28

Figure 14: Functional Anonymous Access Mobility Management State Model...............................................................29

Figure 15: CS Paging Procedure .......................................................................................................................................33

Figure 16: MS Information Procedure ..............................................................................................................................35

Figure 17: MM Information Procedure .............................................................................................................................35

Figure 18: Combined GPRS / IMSI Attach Procedure......................................................................................................37

Figure 19: MS-Initiated Combined GPRS / IMSI Detach Procedure................................................................................40

Figure 20: SGSN-Initiated GPRS Detach Procedure ........................................................................................................40

Figure 21: HLR-Initiated GPRS Detach Procedure ..........................................................................................................41

Figure 22: Purge Procedure...............................................................................................................................................42

Figure 23: Authentication Procedure.................................................................................................................................42

Figure 24: P-TMSI Reallocation Procedure ......................................................................................................................43

Figure 25: Scope of GPRS Ciphering ...............................................................................................................................44

Figure 26: Identity Check Procedure.................................................................................................................................44

Figure 27: Intra SGSN Routeing Area Update Procedure.................................................................................................46

Figure 28: Inter SGSN Routeing Area Update Procedure.................................................................................................47

Figure 29: Combined RA / LA Update in the Case of Intra SGSN RA Update Procedure...............................................49

Figure 30: Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure...............................................51

Figure 31: Insert Subscriber Data Procedure.....................................................................................................................54

Figure 32: Delete Subscriber Data Procedure ...................................................................................................................55

ETSI


Figure 33: GPRS Paging Procedure ..................................................................................................................................57

Figure 34: Functional PDP State Model............................................................................................................................59

Figure 35: PDP Context Activation Procedure..................................................................................................................60

Figure 36: Successful Network-Requested PDP Context Activation Procedure...............................................................62

Figure 37: Protection Procedure........................................................................................................................................63

Figure 38: Mobile User Activity Procedure ......................................................................................................................64

Figure 39: Anonymous Access PDP Context Activation Procedure.................................................................................64

Figure 40: PDP Context Modification Procedure..............................................................................................................66

Figure 41: PDP Context Deactivation Initiated by MS Procedure ....................................................................................66

Figure 42: PDP Context Deactivation Initiated by SGSN Procedure................................................................................67

Figure 43: PDP Context Deactivation Initiated by GGSN Procedure ...............................................................................67

Figure 44: Anonymous Access PDP Context Deactivation Initiated by MS Procedure ...................................................68

Figure 45: Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure ..............................................68

Figure 46: Multiplexing of Network Protocols .................................................................................................................72

Figure 47: Sequential Invocation of SNDC Functionality ................................................................................................73

Figure 48: Relationship of OSP to the Rest of the GPRS Protocol Architecture ..............................................................75

Figure 49: Transmission Plane for PDP Type PPP ...........................................................................................................76

Figure 50: BSSGP Protocol Position.................................................................................................................................77

Figure 51: Remote Packet Control Unit (PCU) Positions .................................................................................................80

Figure 52: GPRS Subscription Data..................................................................................................................................81

Figure 53: Use of NSAPI and TLLI ..................................................................................................................................87

Figure 54: MT SMS Transfer, Successful .........................................................................................................................94

Figure 55: MT SMS Transfer, Unsuccessful.....................................................................................................................95

Figure 56: MO SMS Transfer, Successful ........................................................................................................................96

Figure 57: Suspend and Resume Procedure ......................................................................................................................97

ETSI


Annex E (informative):TablesTable 1: Mapping of Functions to Logical Architecture ...................................................................................................21

Table 2: Network Operation Modes..................................................................................................................................34

Table 3: Mapping of High-level Functions Across the Gb Architecture...........................................................................78

Table 4: HLR GPRS Subscription Data ............................................................................................................................81

Table 5: SGSN MM and PDP Contexts ............................................................................................................................82

Table 6: SGSN MM and PDP Contexts for Anonymous Access ......................................................................................83

Table 7: GGSN PDP Context ............................................................................................................................................83

Table 8: GGSN PDP Context for Anonymous Access......................................................................................................84

Table 9: MS MM and PDP Contexts.................................................................................................................................84

Table 10: MS MM and PDP Contexts for Anonymous Access ........................................................................................85

Table 11: MSC/VLR Association .....................................................................................................................................85

Table 12: Precedence Classes............................................................................................................................................91

Table 13: Reliability Classes.............................................................................................................................................92

Table 14: Peak Throughput Classes ..................................................................................................................................92

Table 15: Mean Throughput Classes .................................................................................................................................93

ETSI


Annex F (informative):Document history

Version Date Information about changes

5.0.0 June 1997 SMG#22 approved.

5.1.0 October 1997 Included SMG#23 approved change requests A001 through A010.

5.2.0 December 1997 Included SMG#24 approved change requests A011 through A019, A021 throughA026, A028, A030 through A033, and A035.

5.3.0 March 1998 Included SMG#25 approved change requests A027, A036 through A038, A040,A042, and A043.

6.0.0 March 1998 Included SMG#25 approved change request A044.

6.1.0 June 1998 Included SMG#26 approved change requests A045 through A048, A050 throughA055, and A057 through A062.

6.1.1 August 1998 ETSI version change due to change of Public Enquiry dates.

6.2.0 October 1998 Included SMG#27 approved change requests A065, A066, A068 through A080,A082, A088, and A090.

6.3.0 February 1999 Included SMG#28 approved change requests A092, A093, A095 through A098,A100 through A102, A105, and A108.

6.3.1 April 1999 Editorial correction.

7.0.0 April 1999 Included SMG#28 approved Release 98 change requests A087 and A091.

7.1.0 August 1999 Included SMG#29 approved Release 98 change requests A104, A115 and A150through A158.

7.2.0 October 1999 Included TSG CN#5 and SA#5 approved change requests A163r1, A167, A168r2,A169, and A171r2.

7.3.0 December 1999 Included TSG SA#6 approved change requests A173, A175, A177, A179, A181,and A182.

7.4.0 March 2000 Included TSG SA#7 approved change requests A183 and A185.

7.4.1 September 2000 Version update to 7.4.1 for Publication

ETSI


History

Document history

V7.1.0 August 1999 One-step Approval Procedure OAP 9956: 1999-08-25 to 1999-12-24

V7.1.1 January 2000 Publication

V7.3.0 February 2000 One-step Approval Procedure OAP 200024: 2000-02-16 to 2000-06-16

V7.4.0 April 2000 One-step Approval Procedure OAP 20000818: 2000-04-19 to 2000-08-18

V7.3.1 July 2000 Publication

V7.4.1 September 2000 Publication

ETSI EN 301 344 V7.4ETSI EN 301 344 V7.4.1 (2000-09) European Standard (Telecommunications series) Digital cellular telecommunications system (Phase 2+); General Packet Radio Service

Documents