SlideShare uma empresa Scribd logo
1 de 26
Baixar para ler offline
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
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
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
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
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
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
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
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
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.
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
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
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
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)
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
                                                         ……
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.
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 )
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 )
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.
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 )
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.
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
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
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
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
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
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

Mais conteúdo relacionado

Mais procurados

Opinion: The Politics of SA vs NSA 5G & 4G Speeds
Opinion: The Politics of SA vs NSA 5G & 4G SpeedsOpinion: The Politics of SA vs NSA 5G & 4G Speeds
Opinion: The Politics of SA vs NSA 5G & 4G Speeds3G4G
 
LTE Call Processing and Handover
LTE Call Processing and HandoverLTE Call Processing and Handover
LTE Call Processing and HandoverSitha Sok
 
Chap 4. call processing and handover.eng
Chap 4. call processing and handover.engChap 4. call processing and handover.eng
Chap 4. call processing and handover.engsivakumar D
 
39018631 lte-overview
39018631 lte-overview39018631 lte-overview
39018631 lte-overviewcefer mecid
 
3GPP_Overall_Architecture_and_Specifications.pdf
3GPP_Overall_Architecture_and_Specifications.pdf3GPP_Overall_Architecture_and_Specifications.pdf
3GPP_Overall_Architecture_and_Specifications.pdfAbubakar416712
 
LTE network: How it all comes together architecture technical poster
LTE network: How it all comes together architecture technical posterLTE network: How it all comes together architecture technical poster
LTE network: How it all comes together architecture technical posterDavid Swift
 
Advanced: 5G Service Based Architecture (SBA)
Advanced: 5G Service Based Architecture (SBA)Advanced: 5G Service Based Architecture (SBA)
Advanced: 5G Service Based Architecture (SBA)3G4G
 
Lte attach-messaging
Lte attach-messagingLte attach-messaging
Lte attach-messagingPraveen Kumar
 
Best practices-lte-call-flow-guide
Best practices-lte-call-flow-guideBest practices-lte-call-flow-guide
Best practices-lte-call-flow-guideMorg
 
5G Standards: 3GPP Release 15, 16, and beyond
5G Standards: 3GPP Release 15, 16, and beyond5G Standards: 3GPP Release 15, 16, and beyond
5G Standards: 3GPP Release 15, 16, and beyond3G4G
 
Intermediate: 5G Network Architecture Options (Updated)
Intermediate: 5G Network Architecture Options (Updated)Intermediate: 5G Network Architecture Options (Updated)
Intermediate: 5G Network Architecture Options (Updated)3G4G
 
rrc-procedures-in-lte
rrc-procedures-in-lterrc-procedures-in-lte
rrc-procedures-in-lteMorg
 
End to End volte ims sip call flow Guide - Mobile originating and Mobile term...
End to End volte ims sip call flow Guide - Mobile originating and Mobile term...End to End volte ims sip call flow Guide - Mobile originating and Mobile term...
End to End volte ims sip call flow Guide - Mobile originating and Mobile term...Vikas Shokeen
 
Juniper mpls best practice part 1
Juniper mpls best practice   part 1Juniper mpls best practice   part 1
Juniper mpls best practice part 1Febrian ‎
 
Lte power control
Lte power controlLte power control
Lte power controlPranay Akul
 
E2 e+call+setup+time+(cst)+enhacenments p3_benchmarking
E2 e+call+setup+time+(cst)+enhacenments p3_benchmarkingE2 e+call+setup+time+(cst)+enhacenments p3_benchmarking
E2 e+call+setup+time+(cst)+enhacenments p3_benchmarkingOtseakemhe
 
Advanced: Control and User Plane Separation of EPC nodes (CUPS)
Advanced: Control and User Plane Separation of EPC nodes (CUPS)Advanced: Control and User Plane Separation of EPC nodes (CUPS)
Advanced: Control and User Plane Separation of EPC nodes (CUPS)3G4G
 
SGSN- serving gprs support node - Platform - HW, SW and CLI
SGSN- serving gprs support node  - Platform - HW, SW and CLI SGSN- serving gprs support node  - Platform - HW, SW and CLI
SGSN- serving gprs support node - Platform - HW, SW and CLI Mustafa Golam
 

Mais procurados (20)

Opinion: The Politics of SA vs NSA 5G & 4G Speeds
Opinion: The Politics of SA vs NSA 5G & 4G SpeedsOpinion: The Politics of SA vs NSA 5G & 4G Speeds
Opinion: The Politics of SA vs NSA 5G & 4G Speeds
 
LTE Call Processing and Handover
LTE Call Processing and HandoverLTE Call Processing and Handover
LTE Call Processing and Handover
 
Chap 4. call processing and handover.eng
Chap 4. call processing and handover.engChap 4. call processing and handover.eng
Chap 4. call processing and handover.eng
 
39018631 lte-overview
39018631 lte-overview39018631 lte-overview
39018631 lte-overview
 
3GPP_Overall_Architecture_and_Specifications.pdf
3GPP_Overall_Architecture_and_Specifications.pdf3GPP_Overall_Architecture_and_Specifications.pdf
3GPP_Overall_Architecture_and_Specifications.pdf
 
LTE network: How it all comes together architecture technical poster
LTE network: How it all comes together architecture technical posterLTE network: How it all comes together architecture technical poster
LTE network: How it all comes together architecture technical poster
 
Advanced: 5G Service Based Architecture (SBA)
Advanced: 5G Service Based Architecture (SBA)Advanced: 5G Service Based Architecture (SBA)
Advanced: 5G Service Based Architecture (SBA)
 
Lte attach-messaging
Lte attach-messagingLte attach-messaging
Lte attach-messaging
 
Best practices-lte-call-flow-guide
Best practices-lte-call-flow-guideBest practices-lte-call-flow-guide
Best practices-lte-call-flow-guide
 
Lte technical overview
Lte technical overviewLte technical overview
Lte technical overview
 
5G Standards: 3GPP Release 15, 16, and beyond
5G Standards: 3GPP Release 15, 16, and beyond5G Standards: 3GPP Release 15, 16, and beyond
5G Standards: 3GPP Release 15, 16, and beyond
 
Epc cups overview
Epc cups overviewEpc cups overview
Epc cups overview
 
Intermediate: 5G Network Architecture Options (Updated)
Intermediate: 5G Network Architecture Options (Updated)Intermediate: 5G Network Architecture Options (Updated)
Intermediate: 5G Network Architecture Options (Updated)
 
rrc-procedures-in-lte
rrc-procedures-in-lterrc-procedures-in-lte
rrc-procedures-in-lte
 
End to End volte ims sip call flow Guide - Mobile originating and Mobile term...
End to End volte ims sip call flow Guide - Mobile originating and Mobile term...End to End volte ims sip call flow Guide - Mobile originating and Mobile term...
End to End volte ims sip call flow Guide - Mobile originating and Mobile term...
 
Juniper mpls best practice part 1
Juniper mpls best practice   part 1Juniper mpls best practice   part 1
Juniper mpls best practice part 1
 
Lte power control
Lte power controlLte power control
Lte power control
 
E2 e+call+setup+time+(cst)+enhacenments p3_benchmarking
E2 e+call+setup+time+(cst)+enhacenments p3_benchmarkingE2 e+call+setup+time+(cst)+enhacenments p3_benchmarking
E2 e+call+setup+time+(cst)+enhacenments p3_benchmarking
 
Advanced: Control and User Plane Separation of EPC nodes (CUPS)
Advanced: Control and User Plane Separation of EPC nodes (CUPS)Advanced: Control and User Plane Separation of EPC nodes (CUPS)
Advanced: Control and User Plane Separation of EPC nodes (CUPS)
 
SGSN- serving gprs support node - Platform - HW, SW and CLI
SGSN- serving gprs support node  - Platform - HW, SW and CLI SGSN- serving gprs support node  - Platform - HW, SW and CLI
SGSN- serving gprs support node - Platform - HW, SW and CLI
 

Destaque

M'SIA PRESENTATION 2012
M'SIA PRESENTATION 2012M'SIA PRESENTATION 2012
M'SIA PRESENTATION 2012Ezz Ahmad
 
Economic Transformation Programme
Economic Transformation ProgrammeEconomic Transformation Programme
Economic Transformation Programmeimpak
 
Economic Transformation Programme Malaysia
Economic Transformation Programme Malaysia Economic Transformation Programme Malaysia
Economic Transformation Programme Malaysia Voice Malaysia
 
LTE @ Yogyakarta, 19 December 2001
LTE @ Yogyakarta, 19 December 2001LTE @ Yogyakarta, 19 December 2001
LTE @ Yogyakarta, 19 December 2001Arief Gunawan
 
Economic Transformation Plan Executive Summary_booklet
Economic Transformation Plan  Executive Summary_bookletEconomic Transformation Plan  Executive Summary_booklet
Economic Transformation Plan Executive Summary_bookletVoice Malaysia
 
04 sgsn&
04 sgsn&04 sgsn&
04 sgsn&kenkenzh
 
92863888 5g-technology-ppt-by-nasar
92863888 5g-technology-ppt-by-nasar92863888 5g-technology-ppt-by-nasar
92863888 5g-technology-ppt-by-nasarNasar Mohammed
 
MyLDS 2015_Day 3_Why Global Talent Programme (Junior)
MyLDS 2015_Day 3_Why Global Talent Programme (Junior)MyLDS 2015_Day 3_Why Global Talent Programme (Junior)
MyLDS 2015_Day 3_Why Global Talent Programme (Junior)aiesecmalaysia
 
Slp Process & Cleaning Validation Eng
Slp Process & Cleaning Validation EngSlp Process & Cleaning Validation Eng
Slp Process & Cleaning Validation Engtseener
 
Case studies of surveys involved in Railway Tunnel constructed under sea.
Case studies of surveys involved in Railway Tunnel constructed under sea.Case studies of surveys involved in Railway Tunnel constructed under sea.
Case studies of surveys involved in Railway Tunnel constructed under sea.Prudhvi Thota
 
analytical method validation of albendazole tablets.
analytical method validation of albendazole tablets.analytical method validation of albendazole tablets.
analytical method validation of albendazole tablets.Imran al
 
Philippe Langlois - Hacking HLR HSS and MME core network elements
Philippe Langlois - Hacking HLR HSS and MME core network elementsPhilippe Langlois - Hacking HLR HSS and MME core network elements
Philippe Langlois - Hacking HLR HSS and MME core network elementsP1Security
 
4 lte access transport network dimensioning issue 1.02
4 lte access transport network dimensioning issue 1.024 lte access transport network dimensioning issue 1.02
4 lte access transport network dimensioning issue 1.02saeed_sh65
 
Supply Chain & Logistics Basics: Maintaining End-to-End Cold Chain Integrity
Supply Chain & Logistics Basics: Maintaining End-to-End Cold Chain IntegritySupply Chain & Logistics Basics: Maintaining End-to-End Cold Chain Integrity
Supply Chain & Logistics Basics: Maintaining End-to-End Cold Chain IntegrityAngela Carver
 

Destaque (20)

M'SIA PRESENTATION 2012
M'SIA PRESENTATION 2012M'SIA PRESENTATION 2012
M'SIA PRESENTATION 2012
 
Economic Transformation Programme
Economic Transformation ProgrammeEconomic Transformation Programme
Economic Transformation Programme
 
Economic Transformation Programme Malaysia
Economic Transformation Programme Malaysia Economic Transformation Programme Malaysia
Economic Transformation Programme Malaysia
 
VISION 2020
VISION 2020VISION 2020
VISION 2020
 
LTE @ Yogyakarta, 19 December 2001
LTE @ Yogyakarta, 19 December 2001LTE @ Yogyakarta, 19 December 2001
LTE @ Yogyakarta, 19 December 2001
 
Economic Transformation Plan Executive Summary_booklet
Economic Transformation Plan  Executive Summary_bookletEconomic Transformation Plan  Executive Summary_booklet
Economic Transformation Plan Executive Summary_booklet
 
webconferences.com/nihoba/2003sep17
webconferences.com/nihoba/2003sep17webconferences.com/nihoba/2003sep17
webconferences.com/nihoba/2003sep17
 
10 fn s26
10 fn s2610 fn s26
10 fn s26
 
04 sgsn&
04 sgsn&04 sgsn&
04 sgsn&
 
Sales and distribution
Sales and distributionSales and distribution
Sales and distribution
 
92863888 5g-technology-ppt-by-nasar
92863888 5g-technology-ppt-by-nasar92863888 5g-technology-ppt-by-nasar
92863888 5g-technology-ppt-by-nasar
 
MyLDS 2015_Day 3_Why Global Talent Programme (Junior)
MyLDS 2015_Day 3_Why Global Talent Programme (Junior)MyLDS 2015_Day 3_Why Global Talent Programme (Junior)
MyLDS 2015_Day 3_Why Global Talent Programme (Junior)
 
Slp Process & Cleaning Validation Eng
Slp Process & Cleaning Validation EngSlp Process & Cleaning Validation Eng
Slp Process & Cleaning Validation Eng
 
Case studies of surveys involved in Railway Tunnel constructed under sea.
Case studies of surveys involved in Railway Tunnel constructed under sea.Case studies of surveys involved in Railway Tunnel constructed under sea.
Case studies of surveys involved in Railway Tunnel constructed under sea.
 
3 gpp lte-pdcp
3 gpp lte-pdcp3 gpp lte-pdcp
3 gpp lte-pdcp
 
analytical method validation of albendazole tablets.
analytical method validation of albendazole tablets.analytical method validation of albendazole tablets.
analytical method validation of albendazole tablets.
 
Philippe Langlois - Hacking HLR HSS and MME core network elements
Philippe Langlois - Hacking HLR HSS and MME core network elementsPhilippe Langlois - Hacking HLR HSS and MME core network elements
Philippe Langlois - Hacking HLR HSS and MME core network elements
 
4 lte access transport network dimensioning issue 1.02
4 lte access transport network dimensioning issue 1.024 lte access transport network dimensioning issue 1.02
4 lte access transport network dimensioning issue 1.02
 
Supply Chain & Logistics Basics: Maintaining End-to-End Cold Chain Integrity
Supply Chain & Logistics Basics: Maintaining End-to-End Cold Chain IntegritySupply Chain & Logistics Basics: Maintaining End-to-End Cold Chain Integrity
Supply Chain & Logistics Basics: Maintaining End-to-End Cold Chain Integrity
 
regulatory requirement for validation in pharma industry
regulatory requirement for validation in pharma industryregulatory requirement for validation in pharma industry
regulatory requirement for validation in pharma industry
 

Semelhante a Chap05 gtp 03_kh

【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf
【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf
【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdfRyuichi Yasunaga
 
Sec1 V1d0 Aug13 2008 Draft
Sec1 V1d0 Aug13 2008 DraftSec1 V1d0 Aug13 2008 Draft
Sec1 V1d0 Aug13 2008 Draftovophagy
 
Chap02 gprs pro_03t_kh
Chap02 gprs pro_03t_khChap02 gprs pro_03t_kh
Chap02 gprs pro_03t_khFarzad Ramin
 
HITB Labs: Practical Attacks Against 3G/4G Telecommunication Networks
HITB Labs: Practical Attacks Against 3G/4G Telecommunication NetworksHITB Labs: Practical Attacks Against 3G/4G Telecommunication Networks
HITB Labs: Practical Attacks Against 3G/4G Telecommunication NetworksJim Geovedi
 
Cellular J So
Cellular J SoCellular J So
Cellular J Soammar143
 
Computer network (16)
Computer network (16)Computer network (16)
Computer network (16)NYversity
 
Gtp load balancing 27.9.17
Gtp load balancing   27.9.17Gtp load balancing   27.9.17
Gtp load balancing 27.9.17Tamanna Bhatia
 
Sip technology overview
Sip technology overviewSip technology overview
Sip technology overviewOded Ben-Dori
 
UDP - User Datagram Protocol
UDP - User Datagram ProtocolUDP - User Datagram Protocol
UDP - User Datagram ProtocolPeter R. Egli
 
3gpp standards_for_iot
3gpp standards_for_iot3gpp standards_for_iot
3gpp standards_for_iotSaurabh Verma
 
GRE (generic routing encapsulation)
GRE (generic routing encapsulation)GRE (generic routing encapsulation)
GRE (generic routing encapsulation)Netwax Lab
 
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined NetworksOptimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks
Optimization of Low-efficiency Traffic in OpenFlow Software Defined NetworksJose Saldana
 
GGSN-Gateway GPRS Support Node
GGSN-Gateway GPRS Support NodeGGSN-Gateway GPRS Support Node
GGSN-Gateway GPRS Support NodeMustafa Golam
 
Chap07 sndcp 03t_kh
Chap07 sndcp 03t_khChap07 sndcp 03t_kh
Chap07 sndcp 03t_khFarzad Ramin
 
Gprs persentation
Gprs persentation Gprs persentation
Gprs persentation sumit singh
 

Semelhante a Chap05 gtp 03_kh (20)

【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf
【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf
【English version】3GPP 5G Standalone Handover Call flow_Rev4.13_20231224.pdf
 
Sec1 V1d0 Aug13 2008 Draft
Sec1 V1d0 Aug13 2008 DraftSec1 V1d0 Aug13 2008 Draft
Sec1 V1d0 Aug13 2008 Draft
 
Chap02 gprs pro_03t_kh
Chap02 gprs pro_03t_khChap02 gprs pro_03t_kh
Chap02 gprs pro_03t_kh
 
HITB Labs: Practical Attacks Against 3G/4G Telecommunication Networks
HITB Labs: Practical Attacks Against 3G/4G Telecommunication NetworksHITB Labs: Practical Attacks Against 3G/4G Telecommunication Networks
HITB Labs: Practical Attacks Against 3G/4G Telecommunication Networks
 
Wcdma Training
Wcdma TrainingWcdma Training
Wcdma Training
 
GPRS
GPRSGPRS
GPRS
 
Cellular J So
Cellular J SoCellular J So
Cellular J So
 
Computer network (16)
Computer network (16)Computer network (16)
Computer network (16)
 
Gtp load balancing 27.9.17
Gtp load balancing   27.9.17Gtp load balancing   27.9.17
Gtp load balancing 27.9.17
 
Sip technology overview
Sip technology overviewSip technology overview
Sip technology overview
 
IPTV lecture
IPTV lectureIPTV lecture
IPTV lecture
 
UDP - User Datagram Protocol
UDP - User Datagram ProtocolUDP - User Datagram Protocol
UDP - User Datagram Protocol
 
3gpp standards_for_iot
3gpp standards_for_iot3gpp standards_for_iot
3gpp standards_for_iot
 
07 coms 525 tcpip - udp
07    coms 525 tcpip - udp07    coms 525 tcpip - udp
07 coms 525 tcpip - udp
 
GRE (generic routing encapsulation)
GRE (generic routing encapsulation)GRE (generic routing encapsulation)
GRE (generic routing encapsulation)
 
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined NetworksOptimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks
Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks
 
GGSN-Gateway GPRS Support Node
GGSN-Gateway GPRS Support NodeGGSN-Gateway GPRS Support Node
GGSN-Gateway GPRS Support Node
 
Chap07 sndcp 03t_kh
Chap07 sndcp 03t_khChap07 sndcp 03t_kh
Chap07 sndcp 03t_kh
 
Gprs persentation
Gprs persentation Gprs persentation
Gprs persentation
 
GPRS
GPRSGPRS
GPRS
 

Mais de Farzad Ramin

Cellular network planning_and_optimization_part11
Cellular network planning_and_optimization_part11Cellular network planning_and_optimization_part11
Cellular network planning_and_optimization_part11Farzad Ramin
 
Radio network planning fundamentalsnew
Radio network planning fundamentalsnewRadio network planning fundamentalsnew
Radio network planning fundamentalsnewFarzad Ramin
 
Chap09 phys rlc_03 _kh
Chap09 phys rlc_03 _khChap09 phys rlc_03 _kh
Chap09 phys rlc_03 _khFarzad Ramin
 
Chap06 ll cprot_03_kh
Chap06 ll cprot_03_khChap06 ll cprot_03_kh
Chap06 ll cprot_03_khFarzad Ramin
 
Chap03 gmm prot_03_kh
Chap03 gmm prot_03_khChap03 gmm prot_03_kh
Chap03 gmm prot_03_khFarzad Ramin
 
Chap01 gprs intro_03_kh
Chap01 gprs intro_03_khChap01 gprs intro_03_kh
Chap01 gprs intro_03_khFarzad Ramin
 

Mais de Farzad Ramin (11)

Cellular network planning_and_optimization_part11
Cellular network planning_and_optimization_part11Cellular network planning_and_optimization_part11
Cellular network planning_and_optimization_part11
 
Nokia common bcch
Nokia common bcchNokia common bcch
Nokia common bcch
 
Radio network planning fundamentalsnew
Radio network planning fundamentalsnewRadio network planning fundamentalsnew
Radio network planning fundamentalsnew
 
Data base ex
Data base exData base ex
Data base ex
 
Chap09 phys rlc_03 _kh
Chap09 phys rlc_03 _khChap09 phys rlc_03 _kh
Chap09 phys rlc_03 _kh
 
Chap08 gb 03_kh
Chap08 gb 03_khChap08 gb 03_kh
Chap08 gb 03_kh
 
Chap06 ll cprot_03_kh
Chap06 ll cprot_03_khChap06 ll cprot_03_kh
Chap06 ll cprot_03_kh
 
Chap04 gs 03_kh
Chap04 gs 03_khChap04 gs 03_kh
Chap04 gs 03_kh
 
Chap03 gmm prot_03_kh
Chap03 gmm prot_03_khChap03 gmm prot_03_kh
Chap03 gmm prot_03_kh
 
Chap01 gprs intro_03_kh
Chap01 gprs intro_03_khChap01 gprs intro_03_kh
Chap01 gprs intro_03_kh
 
Chap10 edge 03_kh
Chap10 edge 03_khChap10 edge 03_kh
Chap10 edge 03_kh
 

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

Notas do Editor

  1. 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.
  2. 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).