SIST EN 301 347 V6.4.1:2003

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Digital cellular telecommunications system (Phase 2+) (GSM); General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface; (GSM 09.60 version 6.4.1 Release 1997)33.070.50Globalni sistem za mobilno telekomunikacijo (GSM)Global System for Mobile Communication (GSM)ICS:Ta slovenski standard je istoveten z:EN 301 347 Version 6.4.1SIST EN 301 347 V6.4.1:2003en01-december-2003SIST EN 301 347 V6.4.1:2003SLOVENSKI
STANDARD
ETSI EN 301 347 V6.4.1 (1999-11)European Standard (Telecommunications series)Digital cellular telecommunications system (Phase 2+);General Packet Radio Service (GPRS);GPRS Tunnelling Protocol (GTP)across the Gn and Gp Interface;(GSM 09.60 version 6.4.1 Release 1997)GLOBAL SYSTEM
FOR MOBILE COMMUNICATIONSRSIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)2(GSM 09.60 version 6.4.1 Release 1997)ReferenceDEN/SMG-030960Q6 (ch0031co.PDF)KeywordsDigital cellular telecommunications system,Global System for Mobile communications (GSM)ETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frIndividual copies of this ETSI deliverablecan be downloaded fromhttp://www.etsi.orgIf you find errors in the present document, send yourcomment to: editor@etsi.frImportant noticeThis ETSI deliverable 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 should be the printing on ETSI printers of the PDF version kept on a specific networkdrive within ETSI Secretariat.Copyright NotificationNo 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 1999.All rights reserved.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)3(GSM 09.60 version 6.4.1 Release 1997)ContentsIntellectual Property Rights.6Foreword.61Scope.72References.73Definitions and abbreviations.83.1Definitions.83.2Abbreviations.94General.95Transmission order and bit definitions.106GTP header.117Signalling Plane.127.1Signalling protocol.127.2Signalling Message Formats.137.3Usage of the GTP Header.147.4Path Management messages.147.4.1Echo Request.147.4.2Echo Response.157.4.3Version Not Supported.157.5Tunnel Management messages.157.5.1Create PDP Context Request.157.5.2Create PDP Context Response.177.5.3Update PDP Context Request.197.5.4Update PDP Context Response.207.5.5Delete PDP Context Request.217.5.6Delete PDP Context Response.217.5.7Create AA PDP Context Request.227.5.8Create AA PDP Context Response.237.5.9Delete AA PDP Context Request.247.5.10Delete AA PDP Context Response.257.5.11Error Indication.257.5.12PDU Notification Request.267.5.13PDU Notification Response.267.5.14PDU Notification Reject Request.277.5.15PDU Notification Reject Response.277.6Location Management messages.287.6.1Send Routeing Information for GPRS Request.287.6.2Send Routeing Information for GPRS Response.297.6.3Failure Report Request.297.6.4Failure Report Response.307.6.5Note MS GPRS Present Request.307.6.6Note MS GPRS Present Response.317.7Mobility Management messages.317.7.1Identification Request.317.7.2Identification Response.327.7.3SGSN Context Request.327.7.4SGSN Context Response.337.7.5SGSN Context Acknowledge.347.8Reliable delivery of signalling messages.357.9Information elements.357.9.1Cause.367.9.2International Mobile Subscriber Identity (IMSI).38SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)4(GSM 09.60 version 6.4.1 Release 1997)7.9.3Routeing Area Identity (RAI).387.9.4Temporary Logical Link Identity (TLLI).397.9.5Packet TMSI (P-TMSI).397.9.6Quality of Service (QoS) Profile.407.9.7Spare.407.9.8Reordering Required.407.9.9Authentication Triplet.407.9.10Spare.417.9.11MAP Cause.417.9.12P-TMSI Signature.417.9.13MS Validated.417.9.14Recovery.427.9.15Selection mode.427.9.16Flow Label Data I.437.9.17Flow Label Signalling.437.9.18Flow Label Data II.437.9.19Charging ID.447.9.20End User Address.447.9.21MM Context.467.9.22PDP Context.477.9.23Access Point Name.507.9.24Protocol Configuration Options.507.9.25GSN Address.507.9.26Private Extension.518Transmission Plane.518.1Protocol Stack.528.1.1Usage of the GTP Header.528.1.1.1Usage of the Sequence Number.528.2Tunnelling between SGSNs.538.3Tunnelling between GGSNs.539Path Protocols.539.1UDP/IP.539.1.1UDP Header.539.1.1.1Signalling request messages.539.1.1.2Signalling response messages.539.1.1.3Encapsulated T-PDUs.539.1.2IP Header.539.1.2.1Signalling request messages and Encapsulated T-PDUs.539.1.2.2Signalling response messages.549.2TCP/IP.549.2.1TCP Header.549.2.2IP Header.5410Error handling.5410.1Protocol errors.5410.1.1Different GTP versions.5510.1.2GTP Message too short.5510.1.3Unknown GTP signalling message.5510.1.4Unexpected GTP signalling message.5510.1.5Missing mandatorily present information element.5510.1.6Invalid Length.5510.1.7Invalid mandatory information element.5510.1.8Invalid optional information element.5510.1.9Unknown information element.5610.1.10Out of sequence information elements.5610.1.11Unexpected information element.5610.1.12Repeated information elements.5610.1.13Incorrect optional information elements.5610.2Path failure.56SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)5(GSM 09.60 version 6.4.1 Release 1997)10.3MS detach.5610.4Restoration and Recovery.5711Inter-PLMN GTP communication over the Gp interface.5712IP, the networking technology used by GTP.5712.1IP version.5712.2IP fragmentation.5712.2.1MO direction.5712.2.2MT direction.5812.2.3Tunnelling from old to new SGSN.5813GTP parameters.5813.1Timers.5813.2Others.58Annex A (informative):Naming convention.63A.1Routing Area Identities.63A.2GPRS Support Nodes.63Annex B (Informative):A method for sequence number checking.64Annex C (Informative):Document change history.65History.66SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)6(GSM 09.60 version 6.4.1 Release 1997)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 SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server(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 SR 000 314 (or the updates on the ETSI Web server)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 Gn and Gp interfaces for the General Packet Radio Service (GPRS) within the digitalcellular 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 by ETSIwith an identifying change of release date and an increase in version number as follows:Version 6.x.ywhere:6indicates Release 1997 of GSM Phase 2+xthe second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates,etc.ythe third digit is incremented when editorial only changes have been incorporated in the specification.National transposition datesDate of adoption of this EN:5 November 1999Date of latest announcement of this EN (doa):29 February 2000Date of latest publication of new National Standardor endorsement of this EN (dop/e):31 August 2000Date of withdrawal of any conflicting National Standard (dow):31 August 2000SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)7(GSM 09.60 version 6.4.1 Release 1997)1ScopeThe present document defines the Gn and Gp interfaces for the General Packet Radio Service (GPRS).2ReferencesThe 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 1997 document, references to GSM documents are for Release 1997 versions (version 6.x.y).[1]GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations andacronyms".[2]GSM 03.03: “Digital cellular telecommunications system (Phase 2+); Numbering, addressing andidentification”.[3]GSM 03.07: “Digital cellular telecommunications system (Phase 2+); Restoration Procedures”[4]GSM 03.20: “Digital cellular telecommunications system (Phase 2+); Security related networkfunctions”[5]GSM 03.60: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Service Description; Stage 2".[6]GSM 03.64: “Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Overall description of the GPRS Radio Interface; Stage 2”[7]GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer3 - specification".[8]GSM 04.64: “Digital cellular telecommunications system (Phase 2+); Mobile Station - ServingGPRS Support Node (MS-SGSN) Logical Link Control (LLC) Layer Specification”[9]GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part(MAP) specification”.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)8(GSM 09.60 version 6.4.1 Release 1997)[10]STD 0005: “Internet Protocol”, J. Postel.[11]STD 0006: “User Datagram Protocol”, J. Postel.[12]STD 0007: “Transmission Control Protocol”, J. Postel.[13]RFC 1700: “Assigned Numbers”, J. Reynolds and J. Postel.[14]RFC 2181: “Clarifications to the DNS Specification”, R. Elz and R. Bush.[15]ITU-T Recommendation X.25: "Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to publicdata networks by dedicated circuit".[16]ITU-T Recommendation X.121: "International Numbering Plan for Public Data Networks".3Definitions and abbreviations3.1DefinitionsFor the purposes of the present document, the following terms and definitions apply:ConditionalWhen the presence requirement for the information element is conditional, the receivingprotocol level can check the presense or absence of an IE based on the receivedinformation.G-PDU: A T-PDU plus a GTP header. A G-PDU is sent in a path.GTP-Flow:A GTP flow is defined by the unidirectional virtual aggregation of G-PDUs and/orsignalling messages related to one or more GTP tunnels. A GTP flow is identified by a FlowLabel included in the GTP header. The meaning of the Flow Label is transparent for thetransmitter side, only the receiver may evaluate the Flow Label.GTP tunnel:A GTP tunnel is defined by two associated PDP Contexts in different GSN nodes and isidentified with a Tunnel ID. A GTP tunnel is necessary to forward packets between anexternal packet data network and a MS user.MM Context:The information sets held in MS and GSNs for a GPRS subscriber related to mobilitymanagement (MM) (please refer to the MM Context Information Element).MM Context ID:IMSI or equivalent for use in conjunction with Anonymous Access (please refer to sectionGTP Header).NSAPI:Network Service Access Point Identifier. An integer value in the range [0; 15], identifying acertain PDP Context. It identifies a PDP context belonging to a specific MM Context ID.Path:The UDP/IP path and TCP/IP path are examples of paths that may be used to multiplexGTP tunnels.Path Protocol:The Path Protocol is the protocol(s) used as a bearer of GTP between GSNs.PDP:A Packet Data Protocol (PDP) is a network protocol used by an external packet datanetwork interfacing to GPRS.PDP Context:The information sets held in MS and GSNs for a PDP address (please refer to the PDPContext Information Element).Quality of Service :Quality of Service may be applicable for the GPRS backbone if the path media supports it.Separate paths with different priorities may be defined between a GSN pair. However, thepossible use of QoS in the GGSN is outside the scope of the GTP specification.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)9(GSM 09.60 version 6.4.1 Release 1997)Signalling message:GTP signalling messages are exchanged between GSN pairs in a path. The signallingmessages are used to transfer GSN capability information between GSN pairs and to create,update and delete GTP tunnels.TCP/IP path:A TCP/IP path is a reliable connection-oriented path defined by two end-points and an end-point is defined by an IP address and a TCP port number. TCP/IP paths should be usedwhen the T-PDUs are based on connection-oriented protocols, such as the X.25 packet layerprotocol.T-PDU: An original packet, for example an IP datagram, from a MS or a network node in anexternal packet data network. A T-PDU is the payload that is tunnelled in the GTP tunnel.TID:A Tunnel ID (TID) consists of a MM Context ID and a NSAPI.UDP/IP path:A UDP/IP path is a connection-less path defined by two end-points and an end-point isdefined by an IP address and a UDP port number. A UDP/IP path carries G-PDUs betweenGSN nodes related to one or more GTP tunnels. A UDP/IP path should be used when the T-PDUs are based on connection-less protocols, such as IP.3.2AbbreviationsAbbreviations used in the present document are listed in GSM 01.04.For the purposes of the present document, the following additional abbreviations apply:BBBackbone BearerDFDon’t FragmentFFSFor Further StudyGTPGPRS Tunneling ProtocolIANAInternet Assigned Number AuthorityICMPInternet Control Message ProtocolIPInternet ProtocolIPv4Internet Protocol version 4IPv6Internet Protocol version 6MTUMaximum Transmission UnitQoSQuality of ServiceTIDTunnel IDentifierTCPTransmission Control ProtocolUDPUser Datagram ProtocolGn interfaceInterface between GPRS Support Nodes (GSNs) within a PLMNGp interfaceInterface between GPRS Support Nodes (GSNs) in different PLMNs4GeneralThe present document defines the GPRS Tunnelling Protocol (GTP), i.e. the protocol between GSN nodes in the GPRSbackbone network. It includes both the GTP signalling and data transfer procedures.GTP is defined both for the Gn interface, i.e. the interface between GSNs within a PLMN, and the Gp interface betweenGSNs in different PLMNs. These interfaces relevant to GTP are between the grey boxes shown in the figure below.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)10(GSM 09.60 version 6.4.1 Release 1997)GiGnGcGpSignalling and Data Transfer InterfaceSignalling InterfaceTEPDNUmGbTEMTBSSRGr or GcHLROther PLMNSGSNGGSNSGSNGTP-MAPprotocolconvertingGSNGnUmGbTEMTBSSRSGSNGnFigure 1: GPRS Logical Architecture with interface name denotationsGTP allows multiprotocol packets to be tunnelled through the GPRS Backbone between GPRS Support Nodes (GSNs).In the signalling plane, GTP specifies a tunnel control and management protocol which allows the SGSN to provideGPRS network access for a MS. Signalling is used to create, modify and delete tunnels.In the transmission plane, GTP uses a tunnelling mechanism to provide a service for carrying user data packets. Thechoice of path is dependent on whether the user data to be tunnelled requires a reliable link or not.The GTP protocol is implemented only by SGSNs and GGSNs. No other systems need to be aware of GTP. GPRS MSsare connected to a SGSN without being aware of GTP.It is assumed that there will be a many-to-many relationship between SGSNs and GGSNs. A SGSN may provide serviceto many GGSNs. A single GGSN may associate with many SGSNs to deliver traffic to a large number of geographicallydiverse mobile stations.5Transmission order and bit definitionsThe messages in this document shall be transmitted in network octet order starting with octet 1.The most significant bit of an octet in a GTP message is bit 8. If a value in a GTP message spans several octets andnothing else is stated, the most significant bit is bit 8 of the octet with the lowest number.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)11(GSM 09.60 version 6.4.1 Release 1997)6GTP headerThe GTP header shall be a fixed format 20-octet header used for all GTP messages.-Version shall be set to 0 to indicate this, the first version of GTP. For the treatment of other versions, see section10.1.1, "Different GTP versions".- Spare ‘1’: These unused bits shall be set to ‘1’ by the sending side and shall not be evaluated by the receivingside.-SNN is a flag indicating if SNDCP N-PDU Number is included or not.-Message Type indicates the type of GTP message.-Length indicates the length in octets of the GTP message (G-PDU), excluding the GTP header. Bit 8 of octet 3 isthe most significant bit and bit 1 of octet 4 is the least significant bit of the length field.-Sequence Number is a transaction identity for signalling messages and an increasing sequence number fortunnelled T-PDUs.-SNDCP N-PDU Number is used at the Inter SGSN Routeing Area Update procedure to co-ordinate the datatransmission between the MS and SGSN.-TID is the tunnel identifier that points out MM and PDP contexts (see Figure 3: Tunnel ID (TID) format).-The flow label identifies unambiguously a GTP flow.All fields in the GTP header shall always be present but the content of the fields differs depending on if the header isused for signalling messages (see the sub-section Usage of the GTP Header in the section Signalling Plane) or T-PDUs(see the sub-section Usage of the GTP Header in the section Transmission Plane).BitsOctets876543211Version Spare ‘ 1 1 1 1 ‘SNN2Message Type3-4Length5-6Sequence Number7-8Flow Label9SNDCP N-PDU Number10Spare ‘ 1 1 1 1 1 1 1 1 ‘11Spare ‘ 1 1 1 1 1 1 1 1 ‘12Spare ‘ 1 1 1 1 1 1 1 1 ‘13-20TIDFigure 2: Outline of GTP headerSIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)12(GSM 09.60 version 6.4.1 Release 1997)MNC digit 1MCC digit 287643215 Bits Octets24531678MCC digit 1MCC digit 3MSIN digit 1MNC digit 2MSIN digit 3MSIN digit 2MSIN digit 5MSIN digit 4MSIN digit 7MSIN digit 6MSIN digit 9MSIN digit 8NSAPIMSIN digit 10NOTE 1:The MCC, MNC and MSIN are parts of the IMSI defined in GSM 03.03. For Anonymous Access, theMSIN shall be replaced by a number assigned by the particular PLMN. The assigned number shall notcollide with any MSIN used in the PLMN and shall be unique within the PLMN.NOTE 2:MSIN digits not used shall be set to F (HEX).Figure 3: Tunnel ID (TID) format7Signalling PlaneThe signalling plane in this case relates to GPRS Mobility Management functions like for example GPRS Attach, GPRSRouteing Area Update and Activation of PDP Contexts. The signalling between GSN nodes shall be performed by theGPRS Tunnelling Protocol (GTP).GSNGn, GpGSNGTPPath ProtocolGTPPath ProtocolFigure 4: Signalling Plane - Protocol stack7.1Signalling protocolThe GTP signalling flow shall be logically associated with, but separate from, the GTP tunnels. For each GSN-GSN pairone or more paths exist. One or more tunnels may use each path. GTP shall be the means by which tunnels areestablished, used, managed and released. A path may be maintained by keep-alive echo messages. This ensures that aconnectivity failure between GSNs can be detected in a timely manner.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)13(GSM 09.60 version 6.4.1 Release 1997)7.2Signalling Message FormatsGTP defines a set of signalling messages between two associated GSNs. The signalling messages to be used are definedin the table below.Table 1: Signalling messagesMessageType value(Decimal)Signalling messageReference0For future use. Shall not be sent. If received, shallbe treated as an Unknown message.1Echo Request7.4.12Echo Response7.4.23Version Not Supported7.4.34-15For future use. Shall not be sent. If received, shallbe treated as an Unknown message.16Create PDP Context Request7.5.117Create PDP Context Response7.5.218Update PDP Context Request7.5.319Update PDP Context Response7.5.420Delete PDP Context Request7.5.521Delete PDP Context Response7.5.622Create AA PDP Context Request7.5.723Create AA PDP Context Response7.5.824Delete AA PDP Context Request7.5.925Delete AA PDP Context Response7.5.1026Error Indication7.5.1127PDU Notification Request7.5.1228PDU Notification Response7.5.1329PDU Notification Reject Request7.5.1430PDU Notification Reject Response7.5.1531For future use. Shall not be sent. If received, shallbe treated as an Unknown message.32Send Routeing Information for GPRS Request7.6.133Send Routeing Information for GPRS Response7.6.234Failure Report Request7.6.335Failure Report Response7.6.436Note MS GPRS Present Request7.6.537Note MS GPRS Present Response7.6.638-47For future use. Shall not be sent. If received, shallbe treated as an Unknown message.48Identification Request7.7.149Identification Response7.7.250SGSN Context Request7.7.351SGSN Context Response7.7.452SGSN Context Acknowledge7.7.553-254For future use. Shall not be sent. If received, shallbe treated as an Unknown message.255T-PDU8.1.1SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)14(GSM 09.60 version 6.4.1 Release 1997)7.3Usage of the GTP HeaderFor signalling messages the GTP header shall be used as follows:-SNN shall be set to 0.-Message Type shall be set to the unique value that is used for each type of signalling message.-Length shall be the length, in octets, of the signalling message excluding the GTP header.-SNDCP N-PDU Number: this field is not yet used in signalling messages. It shall be set to 255 by the sender andshall be ignored by the receiver.-Sequence Number shall be a message number valid for a path or a tunnel. Within a given set of contiguousSequence Numbers from 0 to 65535, a given Sequence Number shall, if used, unambiguously define a GTPsignalling request message sent on the path or tunnel (see section Reliable delivery of signalling messages). TheSequence Number in a signalling response message shall be copied from the signalling request message that theGSN is replying to.-TID (see Figure 3: Tunnel ID (TID) format) shall be set to 0 in all Path Management messages (see section PathManagement messages), Location Management messages (see section Location Management messages ) andMobility Management messages (see section Mobility Management messages). In the Tunnel Managementmessages (see section Tunnel Management messages), TID shall be used to point out the MM and PDP Contextsin the destination GSN.-In all Path Management messages (see section Path Management messages) and Location Management messages(see section Location Management messages) the Flow Label is not used and shall be set to 0. In case of TunnelManagement message and Mobility Management messages the Flow Label is set to the requested value andpoints out the GTP flow except for the Create PDP Context Request message as well as IdentificationRequest/Response and SGSN Context Request message (see section Mobility Management messages).The GTP header may be followed by subsequent information elements dependent on the type of signalling message.Only one information element of each type is allowed in a single signalling message, except for the AuthenticationTriplet, the PDP Context and the Flow Label Data II information element where several occurrences of each type areallowed.BitsOctets876543211 - 20GTP header21 - nInformation Element(s)Figure 5: GTP header followed by subsequent Information Elements7.4Path Management messagesThe Path Management messages may be sent between any type of GSN pair.7.4.1Echo RequestAn Echo Request may be sent on a path to another GSN to find out if the peer GSN is alive (see section Path Failure).Echo Request messages may be sent for each path in use. A path is considered to be in use if at least one PDP contextuses the path to the other GSN. When and how often an Echo Request message may be sent is implementation specificbut an Echo Request shall not be sent more often than every 60 seconds on each path.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)15(GSM 09.60 version 6.4.1 Release 1997)A GSN shall be prepared to receive an Echo Request at any time and it shall reply with an Echo Response. A GSN mayoptionally send Echo Request messages.The optional Private Extension contains vendor or operator specific information.Table 2: Information elements in an Echo RequestInformation elementPresence requirementReferencePrivate ExtensionOptional7.9.267.4.2Echo ResponseThe message shall be sent as a response of a received Echo Request.The Recovery information element contains the local Restart Counter (see section Restoration and Recovery) value forthe GSN that sends the Echo Response message.The GSN that receives an Echo Response from a peer GSN shall compare the Restart Counter value received with theprevious Restart Counter value stored for that peer GSN. If no previous value was stored, the Restart Counter valuereceived in the Echo Response shall be stored for the peer GSN. If the value of a Restart Counter previously stored for a peer GSN differs from the Restart Counter value received in theEcho Response from that peer GSN, the GSN that sent the Echo Response shall be considered as restarted by the GSNthat received the Echo Response. The new Restart Counter value received shall be stored by the receiving entity,replacing the value previously stored for the sending GSN. If the sending GSN is a GGSN and the receiving GSN is aSGSN, the SGSN shall notify an affected MS next time the MS contacts the SGSN. An affected MS is an MS that has atleast one activated PDP context that was using the restarted GGSN. The SGSN shall consider all PDP contexts using thepath as inactive.The optional Private Extension contains vendor or operator specific information.Table 3: Information elements in an Echo ResponseInformation elementPresence requirementReferenceRecoveryMandatory7.9.14Private ExtensionOptional7.9.267.4.3Version Not SupportedThis message contains only the GTP header and indicates the latest GTP version that the GTP entity on the identifiedUDP/IP address can support.7.5Tunnel Management messagesThe Tunnel Management messages are the control and management messages, defined in GSM 03.60, used to create,update and delete tunnels to be able to route T-PDUs between a MS and an external packet data network via SGSN andGGSN. The GMM/SM messages that may trigger the sending of the Tunnel Management messages are defined in GSM04.08.7.5.1Create PDP Context RequestA Create PDP Context Request shall be sent from a SGSN node to a GGSN node as a part of the GPRS PDP ContextActivation procedure. The GGSN IP address where the SGSN sends the Create PDP Context Request is the first IPaddress in the list of IP addresses provided by the DNS server. After sending the Create PDP Context Request message,the SGSN marks the PDP context as ‘waiting for response’. In this state the SGSN shall accept G-PDUs from the GGSNbut shall not send these G-PDUs to the MS. A valid request initiates the creation of a tunnel between a PDP Context in aSGSN and a PDP Context in a GGSN. If the procedure is not successfully completed, the SGSN repeats the Create PDPContext Request message to the next GGSN address in the list of IP addresses, if there is one. If the list is exhausted theactivation procedure fails.SIST EN 301 347 V6.4.1:2003

ETSIETSI EN 301 347 V6.4.1 (1999-11)16(GSM 09.60 version 6.4.1 Release 1997)The Flow Label Data I field specifies a downlink flow label for G-PDUs which is chosen by the SGSN. The GGSN shallinclude this flow label in the GTP header of all subsequent downlink G-PDUs which are related to the requested PDPcontext.The Flow Label Signalling field specifies a downlink flow label for signalling messages which is chosen by the SGSN.The GGSN shall include this flow label in the GTP header of all subsequent downlink signalling messages which arerelated to the requested PDP context.The MSISDN of the MS is passed to the GGSN inside the Create PDP Context Request; This additional information canbe used when a secure access to a remote application residing on a server is needed. The GGSN would be in fact able toprovide the user id
...