Chap05 gtp 03_kh
Download as PPT, PDF5 likes7,833 views
The document describes the GPRS Tunnelling Protocol (GTP) used in 2G and 3G mobile networks. It discusses GTP interfaces and tunnels, message formats including the GTP header, and message groups. The key points are: 1. GTP is used between GPRS Support Nodes (GSNs) and between SGSN and RNC to tunnel user data packets and control signaling messages. 2. The GTP header contains fields for version, message type, length, TEID, and optional fields for sequence number and N-PDU number. 3. GTP messages are grouped into path management messages for path verification, tunnel management messages for context creation/deletion, and location/mobility management messages
Chap05 gtp 03_kh
- 1. Chapter 5 GTP – the tunnel Contents: 5.1 GTP interfaces 1. Protocols for Combined Procedures 2. GTP interfaces 3. Control and User plane 4. Tunnel Endpoint Identifier 5. GTP and UDP 5.2 Message formats 1. The GTPv1 frame 2. Optional fields in the Header 3. GTP header for the G-PDU Example 5.3 GTP message groups 1. Message groups 2. Path Management Messages 3. Tunnel Management Messages 4. Location Management Messages 5. Mobility Management Messages 5.4 GTP messages
- 2. Chapter 5 GTP –the tunnel 5.1 GTP interfaces 1. Protocols for Combined Procedures 2. GTP interfaces 3. Control and User plane 4. Tunnel Endpoint Identifier 5. GTP and UDP
- 3. GTP interfaces In the 2nd generation mobile communication network GSM/GPRS, the GPRS Tunnelling Protocol (GTP) is used between the GPRS Support Nodes (GSN) and for 3 rd generation networks as well between SGSN and RNC (not covered here): •Gn-interface: The Gn interface is in use between SGSN and GGSN within one operator‘s network infrastructure and between SGSNs. The Gn-interface between SGSNs is required to support service continuation in case of inter-SGSN cell reselection. •Gp-interface: The SGSN is located in the visited network, where a roaming subscriber is currently registered, but the GGSN is located in a foreign network (normally, in the subscriber‘s home network). •(Ga-interface: This interface is used between the GSNs and the Charging Gateway Function (CGF). A derivate of the GTP is used, denoted GTP‘. Both CGF and GTP‘ are optional. The CGF may located in a stand-alone device, often called Charging Gateway. Alternatively, it may be implemented in the GSN units. The GTP‘ was designed to carry charging related information. GSM 12.15). GTP version 0 GTP version 1 versions of GTP: GSM 09.60 3GPP TS 29.060 GTP GTP GTP GTP There are important changes from GTP Release 98 to GTP Release UDP / UDP / UDP / UDP / 99. The main reason is that GTP shall also be used in the backbone of TCP TCP TCP TCP UMTS networks(Gn, Gp and Iu interfaces). To meet this requirement IP IP IP IP some additional messages for SGSN Relocation procedure have been defined. L2 L2 L2 L2 Furthermore some Information Elements have changed in Release 99. L1 L1 L1 L1 The most significant change in IEs is that a so-called Tunnel Endpoint Gn Gn Gp Identifier (TEID) substitutes the Tunnel ID (TID) and the Flow Labels. SGSN SGSN GGSN SGSN Anonymous PDP Contexts in Release 98 are not specified any longer in Release 99 Another PLMN
- 4. Control and User plane GTP-PDU: A GTP Protocol Data Unit is either a control plane (GTP-C) • Tunnel control message or a user plane (GTP-U) message. • Management protocol The control plane messages (GTP-C) are used to transfer GSN capability information between GSN pairs, to create, update and delete GTP tunnels and for path management. The tunnels for GTP-U protocol entities make a transport service for one Tunnelling mechanism PDP context. The user plane messages are used to carry user data for transfer of user packets and signalling messages for path management and error packet data indication. G-PDU: A G-PDU carries a user data message. It consists of a T-PDU (Original user packet data, for example an IP datagram) plus a GTP header. Note: All GSNs supporting GTPv1 must support a fallback to GTPv0. GSN UDP/IP is the only path protocol defined to transfer GTP messages in the GTP-C GTPv1 1 of GTP. A User version Datagram GTPv1 GTP-U Protocol (UDP) compliant with RFC 768 shall be used. UDP UDP IPvX In Rel 99 IPvX only L2 L2 UDP L1 L1 GSN Gn/Gp
- 5. Tunnel Endpoint Identifier A GTP tunnel in the GTP-U plane is defined for each PDP Context or each MBMS (MultiMedia Broadcast/Multicast Service) in the GSNs. It is necessary to forward packets between an external packet data network and an MS user. A GTP tunnel in the GTP-C plane is defined for all PDP Contexts with the same PDP address and APN (for Tunnel Management messages) or for each MS (for messages not related to Tunnel Management). A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The Tunnel Endpoint Identifier (TEID) unambiguously identifies a tunnel endpoint in the receiving GTP-U or GTP-C protocol entity. The receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between tunnel endpoints using GTP-C (or RANAP, over the Iu) messages. If the TEID ≠ 0, then one PDP Context is addressed. TEID = 0 holds messages not associated with one PDP context. PDP GTP-C PDP PDP TEIDGSN,control PDP PDP PDP PDP PDP GTP TEIDGSN,user GTP individual UDP PDP Contexts: UDP GTP-U PDP IP IP
- 6. GTP and UDP User data and GTP signalling and control information have to be exchanged between GSNs. The path between two network nodes is described by an IP address and the UDP port number. For GTP-C request messages, the UDP destination port number is always 2123, while the UDP source port number can be allocated locally. For GTP-U request messages, the UDP destination port number is always 2152, and the UDP source port number is allocated locally. In the response message, the destination port number is the source GSN‘s source port number, while the source port number is the source GSN‘s UDP destination port number. User data packets (so-called T-PDU) are transmitted in the same way as GTP-U request messages. The combination of UDP port number and IP address is often called UDP/IP path. UDP/IP Path: connection-less unidirectional or bidirectional path defined by two end-points An IP address and a UDP port number define an end-point. A UDP/IP path carries GTP messages between GSN nodes, and between GSN and RNC nodes related to one or more GTP tunnels. There is one GTP-entity for each used IP address. GSN GTP-C GSN TEIDGSN,control Source Port Dest. Port PDP Request ? 2123 PDP PDP PDP PDP Response 2123 ? PDP PDP TEIDGSN,user PDP GTP GTP GTP-U Source Port Dest. Port individual UDP Request ? 2152 PDP Contexts: UDP IP Response 2152 ? PDP IP
- 7. Chapter 5 GTP –the tunnel 5.2 Message formats 1. The GTPv1 frame 2. Optional fields in the Header 3. GTP header for the G-PDU Example
- 8. The GTPv1 frame I 8 7 6 5 4 3 2 1 The GTPv1 frame contains the following elements. version (3 bits): The version field 1 Version PT X E S PN indicates the differentiates between different GTP versions. GTP version 1 = binary value ‘001’. 2 Message Type PT (Protocol Type) (1 bit): The protocol type indicates GTP (PT = 1) or GTP' (PT = 3 0). Length X is a spare bit. It shall be sent as '0' 4 E (Extension Header Flag) (1 bit): This bit indicates whether the octet 12 of the 5 header shall be evaluated (E=1) or not (E=0) Tunnel S (Sequence Number Flag) (1 bit): This bit indicates whether the octets 9 and 10 6 shall be evaluated (S=1) or not (S=0). Endpoint Identifier PN (N-PDU Number Flag) (1 bit): This bit indicates whether the octet 11 shall be 7 (TEID) evaluated (PN = 1) or not (PN = 0). 8 Message Type (1 octet): The message type identifies a GTP message: Some messages exist for GTP-U, GTP-C, and GTP’ protocol entities, such as the message 9 Echo Request. But most of the messages are used by a single GTP protocol entity. Sequence Number For instance, the Create PDP Context Request is only a GTP-C protocol entity 10 message. Message Types defined for Rel 6 can be found in the end of this chapter 11 N-PDU Number 12 Next Extension Header Type
- 9. The GTPv1 frame II Length (2 octets): These two octets indicate the length of the payload 8 7 6 5 4 3 2 1 (without GTP header) in octet. The first 8 octets of the GTP header are mandatory. The length of the payload is counted from the 8 th octet onwards. 1 Version PT X E S PN TEID (Tunnel Endpoint ID) (4 octets): The tunnel endpoint identifier of 2 Message Type the destination. TEIDs exist both for GTP-C and GTP-U protocol entities. optional Sequence Number (2 octets): The sequence number is an optional field 3 in the G-PDU. If the sequence order for the payload that has to be transmitted in the Length GTP-U tunnel has be be preserved, then a strictly increasing sequence numbering 4 has to be added in the header field Sequence Number For control message frames (both GTP-C and GTP-U) the sequence number is used as a transaction identifier (in 5 other words: request and response have the same number). Tunnel optional N-PDU Number (1 octet): The N-PDU number represents a sequence 6 Endpoint number for network protocol data units (e.g. IP datagrams for external network). The Identifier number is used to coordinate data transmission in the acknowledged mode between 7 (TEID) the MS and the SGSN. It is used during inter-SGSN routing area updates and inter- system handovers to support loss-less data transmission. In an inter-SGSN routing 8 area update, the SNDCP N-PDU number is transmitted in the N-PDU Number field. 9 optional Next Extension Header Type (1 octet): This field is used to indicate Sequence Number which extension header follows after the standard header. Five Next Extension 10 Header field values have been defined so far: •0000 0000’ indicates, that there is no extension header to follow. 11 N-PDU Number •0000 0001’ MBMS (MultiMedia Broadcast/Multicast Service) support indication •1100 0000’ delivers a PDCP PDU number (UMTS use only). 12 Next Extension Header Type •1100 0001’ for a suspend request. For MS in Dual Transfer Mode (DTM) •1100 0010’ for a suspend response.
- 10. Optional fields in the Header GTP Optional header fields: optional Sequence Number: This field is an optional field in G -PDUs. In the user plane, an increasing sequence number for T-PDUs is transmitted via GTP-U tunnels, when transmission order must be preserved. For signalling messages it is used as a transaction identity having a response message defined for a request message, that is the Sequence Number value is copied from the request to the response message header. optional N-PDU Number: This field is used at the Inter SGSN Routeing Area Update procedure and some inter- system handover procedures (e.g. between 2G and 3G radio access networks). This field is used to co- ordinate the data transmission for acknowledged mode of communication between the MS and the SGSN. The exact meaning of this field depends upon the scenario. (For example, for GSM/GPRS to GSM/GPRS, the SNDCP N-PDU number is present in this field). optional Next Extension Header Type: This field defines the type of Extension Header that follows this field in the GTP‑PDU. If present the extension header has the following format: 8 7 6 5 4 3 2 1 Extension headers consist of three components: Extension Header Length (1 Extension Header Length octet), Extension Header Content (N*8-2 octets) and an Next Extension Header Type field (1 octet). Currently it is mainly used for 3G networks. Extension Header Content It allows future extensions of the GTP header, without the need to use another version number for the GTP. Next Extension Header Type
- 11. GTP header for the G-PDU Version PT X E S PN – Version shall be set to decimal 1 ('001'). – Protocol Type flag (PT) shall be set to '1'. 0 0 1 1 0 0 0 0 – If the Sequence Number flag (S) is set to '1' the sequence number field is present and meaningful, otherwise it is set to '0‘ (needed for in sequence 1 1 1 1 1 1 1 1 MT delivery of G-PDU). For GTP-U messages Echo Request, Echo Response, Error Indication and Supported Extension Headers Notification, the S flag shall be set to '1'. Length – The payload number (PN) may be set to 1. It is used during an Inter-SGSN routing area update. The old SGSN informs the new SGSN about the N- PDU number allocated to a T-PDU. Please note, that PN = 0 if unacknowledged mode of operation is used in the LLC). Tunnel – Message Type shall be set to the value 255 (11111111) when T-PDUs are Endpoint transmitted. Identifier – Length: This field indicates the length in octets of the payload, i.e. the rest (TEID) of the packet following the mandatory part of the GTP header (that is the first 8 octets). The Sequence Number, the N-PDU Number or any Extension headers shall be considered to be part of the payload, i.e. included in the length count. – TEID: Contains the Tunnel Endpoint Identifier for the tunnel to which this T-PDU belongs. The TEID shall be used by the receiving entity to find the User Data Packet PDP context. T-PDU SGSN L2 IP UDP GTP IP Transfer of User Data:G-PDU GGSN
- 12. Chapter 5 GTP –the tunnel 5.3 GTP message groups 1. Message groups 2. Path Management Messages 3. Tunnel Management Messages 4. Location Management Messages 5. Defined Messages
- 13. Message groups Path Management Messages • Path Management messages: are the Echo Request / Response messages and the message Version Not Supported. They are used to verify, whether a path between GSN peer entities is still alive. Tunnel Management Messages • Tunnel Management messages: are all messages, which are necessary to create and delete PDP Contexts and Network Initiated Contexts as well as PDU notification to allow the transmission of an individual PDU. optional Location Management Messages • Location Management messages: The location management is optional and required only, when network requested PDP context activation is supported and the GGSN supports no SS7 interface. Then GTP is used to transfer location management messages to a GTP-MAP protocol converter. (not further discussed) Mobility Management • Mobility Management messages: Messages Mobility Management messages are GTP-C messages, which are exchanged between SGSNs to perform an Inter-SGSN routing area update and GPRS attach (with a new SGSN). In both cases, the new SGSN retrieves information from the old SGSN, such as the IMSI. The old SGSN is identified via the old RAI, which is delivered with the MS‘s request. Also the Identification Request / Response messages belong to this group. MBMS Messages optional • The MBMS (MultiMedia Broadcast/Multicast Service) messages are control plane messages that are used in accordance with 3GPP TS 23.246. These are further categorised into control plane messages related to UE specific MBMS signalling, and control plane messages related to MBMS service specific signalling. (not further discussed)
- 14. Message groups The Signalling Messages (any GTP-PDU except the G-PDU) of the GTP are divided into five groups: Tunnel Management Messages Mobility Management Messages Create PDP Context Request Identification Request Create PDP Context Response Identification Response Update PDP Context Request SGSN Context Request Update PDP Context Response SGSN Context Response Delete PDP Context Request SGSN Context Acknowledge Delete PDP Context Response Forward Relocation Request Error Indication Forward Relocation Complete PDU Notification Request Relocation Cancel Request 3G only PDU Notification Response Forward Relocation Complete Acknowledge PDU Notification Reject Request Forward SRNS Context Acknowledge PDU Notification Reject Response Forward SRNS Context ….. Location Management Messages Send Routeing Information for GPRS Request Path Management Messages: Send Routeing Information for GPRS Response Echo Request Failure Report Request Echo Response Failure Report Response Version Not Supported Note MS GPRS Present Request optional Supported Extension Headers Notification Note MS GPRS Present Response MBMS Messages Optional MBMS Notification Request Rel 6 ……
- 15. Path Management Messages GSN Path Management Messages: UDP/IP path GSN Restart GSN Echo Request in use alive? Counter Echo Response Version Not Supported Echo Request Supported Extension Headers Notification Echo Response all PDP contexts yes Recovery ( Recovery: on this path value - GTP-C: restart counter changed? are inactive - GTP-U: 0 ) An Echo Request (ECHQ) message is send by any GSN to find out if the peer GSN is alive. It shall not be send more often than 60 seconds on each path. The answer to this ECHQ is the Echo Response (ECHR) message. The Echo Response contains a Recovery number as mandatory IE. This Recovery number is used in case of a system restart to synchronize the connected GSNs. The Message Version Not Supported (VNS) is send if the entities use different GTP versions – as indicated in the header of the messages. Two GTP versions currently exist. It may happen, that one network node supports GTPv0 only, while its peer-entity supports GTPv1. A GTPv1 network elements is always backwards compatible, i.e. it supports also GTPv0. If a GSN wants to figure out, which version number is supported by a peer-GSN, it sends the message Version Not Supported, which indicates the latest GTP version would be support by the other side on the used UDP/IP path. This message is only used for GTP-C and GTP‘. It consists of the GTP header fields only. Extension headers are allowed in GTP. If a GSN is internally marked as one which does not support all extensions, and when it is required to interpret a mandatory header extension which it does not support, then it must send to its peer GSN the list of extensions, it is capable to support. This is done with the message Supported Extension Headers Notifications. This message is used for GTP-C and GTP-U.
- 16. Path Management Messages Path Management Messages GSN GSN Version Not Supported ( ) mandatory G-PDU header extensions ( header extension: Y ) X: supported Y: not supported Z: supported Supported Extension Headers Notification ( Extension Header Type List )
- 17. Error indication There is only one GTP-U tunnel management message: Error Indication. Tunnel Management Messages A GSN receives a G-PDU, for which no active PDP context exists. It retrieves the TEID from the retrieved G- PDU. Then it creates the Error Indication message, adds the TEID and its GSN address, and sends the message to its peer-GSN entity. The G-PDU is deleted. If a GSN receives an Error Indication message, it deletes the PDP context. Especially, when an SGSN receives an error indication from the GGSN, it also has to indicate this event to the MS. It sends the session management message Deactivate PDP Context, including the cause „unknown PDP context“. MS BSS SGSN GGSN G-PDU Error Indication PDP Context Deactivation ( TEIDSGSN, GGSN Address ) ( cause: unknown PDP context ) Deactivate PDP Context Accept G-PDU Error Indication ( TEIDGGSN, SGSN Address )
- 18. PDP context creation GTP-C Tunnel Management Messages Tunnel Management Messages Create PDP Context Request Create PDP Context Response Update PDP Context Request With these messages PDP Update PDP Context Response Contexts are created. All Delete PDP Context Request signaling messages and all Delete PDP Context Response user data that belong to the PDU Notification Request same PDP Context have the messages are only required, PDU Notification Response same Tunnel ID (TID). when mobile terminating PDU Notification Reject Request PDPs are supported PDU Notification Reject Response SGSN GGSN Create PDP Context Request To set up a Mobile Originated PDP Context the SGSN sends ( TEIDSGSN data, TEIDSGSN control plane, a Create PDP Context Request (CPCQ) message. This CPCQ message contains a Flow Label (FL), a Flow NSAPI, QoS profile, End user address, Label Data (FLDatat) IE, a Flow Label Signaling (FLSign) IE, SGSN address for control plane the MSISDN and Quality of Service (QoS) as requested by and for user traffic, TFT ) the MS. After the PDP Context is created the FLData and FLSign of the CPCQ are used to indicate all data or signaling traffic in Create PDP Context Response downlink direction. ( TEIDGGSN data, TEIDCGSN control plane, Furthermore the CPCQ message contains the Signaling and NSAPI, QoS profile, End user address, User Traffic SGSN Address as mandatory parameter as well GGSN address for control plane as the End User Address and the Access Point Name (APN). and for user traffic ) The Create PDP Context Response contains a Cause IE that indicates whether the request was accepted or not.
- 19. PDP update / deletion Tunnel Management Messages SGSN GGSN Update PDP Context Request ( TEIDSGSN data, TEIDSGSN control plane, The GTP-C protocol provides the messages NSAPI, QoS profile, Update PDP Context Request and Update SGSN address for control plane PDP Context Response. These two and for user traffic ) messages enable the PDP context Update PDP Context Response modification between SGSN and GGSN. A ( TEIDGGSN data, TEIDCGSN control plane, GGSN and SGSN initiated PDP context QoS profile,, update is supported. Rel. 99 allows Update GGSN address for control plane PDP Context initiated by GGSN to change and for user traffic ) QoS. Between SGSN and GGSN the GTP-C Delete PDP Context Request protocol allows the deactivation with the ( NSAPI, Teardown indicator ) messages Delete PDP Context Request and Delete PDP Context Response. It can be initiated by the GGSN and by the SGSN. Delete PDP Context Response ( cause )
- 20. Unsuccessful PDP Context Activation by the Network Location Management Messages Mobile terminated GPRS session establishment signalling is is covered by the GTP-C tunnelling protocol. MTC may fail for many reasons. In the figure on the right hand side, we assume, that the GGSN is able to perform a HLR interrogation. It receives the GSN address of the SGSN, which is currently serving the MS. The GGSN sends a PDU Notification Request to the SGSN. A network originated PDP context activation is rejected, when the MS is unknown, when it is GPRS detached, when no resources are available, etc. The response is transmitted in the message PDU Notification Response. If the network orientated PDP context activation is accepted by the SGSN: 1. The SGSN sends a PDU Notification Response message to the GGSN. The message includes the cause „Request Accepted“. When a GGSN receives this message, it can already start to forward G-PDUs because it has received the right IP address of the Serving SGSN. 2. The SGSN sends a PDP Context Activation request message to the MS. The MS is not responding to a GPRS paging request, thus no response is returned to the SGSN. The MS may explicitly reject a network requested PDP context activation. Then the message PDP Context Activation Reject is returned. In both cases, the SGSN generates the message PDU Notification Reject Request. The cause for the reject request is added, which is either „MS Not GPRS Responding“ or „MS Refuse“. 3. The GGSN notifies the reject request by returning the PDU Notification Reject Response message.
- 21. Unsuccessful PDP Context Activation by the Network MS Location Management Messages ISP SGSN HLR GGSN PDP PDU Send Routing Info for GPRS ( IMSI) Send Routing Info for GPRS Ack ( IMSI, SGSN address ) PDU Notification Request ( IMSI, TEIDGGSN control plane, End user address, APN, GGSN address for control plane) PDU Notification Response Activate PDP ( cause: Request Accepted ) Context Request Activate PDP Context Reject PDU Notification Reject Request ( cause: MS Refuse ) ( cause: MS Refuse or MS Not GPRS Responding) PDU Notification Reject Response
- 22. Inter SGSN Routing Area update procedure Before the RA change Mobility Management After the RA change Messages HLR HLR GGSN GGSN old MSC/VLR old SGSN new SGSN new MSC/VLR old MSC/VLR old SGSN new SGSN new MSC/VLR Old new Old new BSC BSC BSC BSC LA1, RA1 LA2, RA2 LA1, RA1 LA2, RA2 MS MS Path of the packets MS initiates the procedure with a GMM Routeing Area Update Request sent to the new SGSN. Update Type shall indicate RA update or periodic RA update. The new SGSN sends SGSN Context Request to the old SGSN to get the MM and PDP contexts for . the MS. The new SGSN derives the old SGSN from the old RAI. If the old P ‑TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP N‑PDU numbers to downlink N‑PDUs received, and responds with SGSN Context Response (MM Context, PDP Contexts). The old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN. The old SGSN starts a timer and stops the transmission of N-PDUs to the MS
- 23. Inter SGSN Routing Area update procedure MS BSS new SGSN old SGSN GGSN HLR Routeing Area Update Request Mobility Management 1. SGSN Context Request Messages 2. SGSN Context Response Security Functions may be performed Security Functions may be performed 3. SGSN Context Acknowledge Mobility Management Messages: SGSN Context Request 4. Forward Packets SGSN Context SGSN Context Response 5. Update PDP Context Request SGSN Context Acknowledge 6. Update PDP Context Response Update PDP Context Request Update Location Update PDP Context Response Cancel Location Cancel Location Ack Insert Subscriber Data Insert Subscriber Data Ack Update Location Ack Routeing Area Update Accept Routeing Area Update Complete
- 24. 5.4 Defined messages for GTP (Rel 6) Message Message GTP-C GTP-U GTP' Type value 0 For future use. Shall not be sent. 1 Echo Request X X x 2 Echo Response X X x 3 Version Not Supported X x 4 Node Alive Request X 5 Node Alive Response X 6 Redirection Request X 7 Redirection Response X 8-15 For future use. Shall not be sent. 16 Create PDP Context Request X 17 Create PDP Context Response X 18 Update PDP Context Request X 19 Update PDP Context Response X 20 Delete PDP Context Request X 21 Delete PDP Context Response X 22-25 For future use. Shall not be sent. 26 Error Indication X 27 PDU Notification Request X 28 PDU Notification Response X
- 25. Defined messages for GTP II 29 PDU Notification Reject Request X 30 PDU Notification Reject Response X 31 Supported Extension Headers Notification X X 32 Send Routeing Information for GPRS Request X 33 Send Routeing Information for GPRS Response X 34 Failure Report Request X 35 Failure Report Response X 36 Note MS GPRS Present Request X 37 Note MS GPRS Present Response X 38-47 For future use. Shall not be sent. 48 Identification Request X 49 Identification Response X 50 SGSN Context Request X 51 SGSN Context Response X 52 SGSN Context Acknowledge X 53 Forward Relocation Request X 54 Forward Relocation Response X 55 Forward Relocation Complete X 56 Relocation Cancel Request X 57 Relocation Cancel Response X 58 Forward SRNS Context X 59 Forward Relocation Complete Acknowledge X 60 Forward SRNS Context Acknowledge X 61-69 For future use. Shall not be sent. 70 RAN Information Relay X
- 26. Defined messages for GTP III 71-95 For future use. Shall not be sent. 96 MBMS Notification Request X 97 MBMS Notification Response X 98 MBMS Notification Reject Request X 99 MBMS Notification Reject Response X 100 Create MBMS Context Request X 101 Create MBMS Context Response X 102 Update MBMS Context Request X 103 Update MBMS Context Response X 104 Delete MBMS Context Request X 105 Delete MBMS Context Response X 106 - 111 For future use. Shall not be sent. 112 MBMS Registration Request X 113 MBMS Registration Response X 114 MBMS De-Registration Request X 115 MBMS De-Registration Response X 116 MBMS Session Start Request X 117 MBMS Session Start Response X 118 MBMS Session Stop Request X 119 MBMS Session Stop Response X 120 -239 For future use. Shall not be sent. 240 Data Record Transfer Request X 241 Data Record Transfer Response X 242-254 For future use. Shall not be sent. 255 G-PDU X
Editor's Notes
- #21: TS 23.060 chap. 9.2.2.2.2 Es gibt noch weitere fälle, die im falle einer failure eine Signallisierung zum HLR bedeuten.
- #24: The procedure begins when the MS detects a new RAI that is different to the one stored on the SIM. It sends a Routing Area Update Request to the new SGSN. 1. The new SGSN has to get the IMSI for this MS. Therefore the new SGSN translates the old RAI from the MS into the old SGSN IP address using a DNS. Then the new SGSN sends the GTP message SGSN Context Request to the old SGSN. This SGSN Context Request message contains the old RAI, TLLI, and new SGSN address. Important IEs: - Flow Label for downlink data and signalling - QoS as negotiated between MS and SGSN - SGSN address of the new(!) SGSN 2. The old SGSN transfers all GMM context and all data about active PDP contexts back to the new SGSN using the GTP message SGSN Context Response . 3. The new SGSN now gets the IMSI and authentication data from the GMM context and all information about all PDP contexts. Hence the new SGSN can perform authentication. When authentication is successful the new SGSN will send the GTP message SGSN Context Acknowledge to the old SGSN which triggers the old SGSN to forward buffered user packet data to the new SGSN. Concurrently with the last step the new SGSN contacts the GGSN for the active PDP context. It sends the GTP message Update PDP Context Request to the GGSN. This message holds the SGSN IP address and TEID. Additionally the new SGSN can set a new quality of service for the PDP context. The new QoS can be lower or higher than the QoS before the update. But the QoS will never exceed the QoS requested by the user. The GGSN acknowledges the GTP message with the Update PDP Context Response . Rel. 99 allows Update PDP Context initiated by GGSN to change QoS ! Following values may be updated: QoS negotiated, packet flow identifier, radio priority, PDP-address (when initiated by the GGSN), and TFT (when initiated by the MS).