GPRS Chap13

GPRS Signalling Messages and Procedures on the Air interface

1

GPRS Signalling messages on GRR, GMM and SM Dipl.-Ing. Reiner Stuhlfauth, ROHDE&SCHWARZ, Training Center Munich

Summary GPRS introduces a new kind of signalling to the existing GSM network. There will be an extension of the existing circuit switched protocol plane with a new one, the packet switched protocol plane. Therefore some new protocols are included in the GPRS network. The following figure summarizes the protocol plane between MS and network:

Maps network level characteristics onto characteristics of underlying protocols SNDCP

SNDCP

LLC

LLC (Note)

MAC

RLC

RLC

Access Control signalling + Mapping of LLC-Frames onto physical channels

MAC

MAC

Phys. Link

Phys. Link

Phys. RF

Phys. RF

RLC Reliable link + Radio Link Control functions

MS

Um

SNDCP = SubNetwork Dependent Convergence Protocol LLC = Logical Link Control

LLC = Logical Link Control

Logical Link between MS and SGSN. Independent from Radio Interface

Data Coding, Burst Forming, Interleaving, Convolutional Coding = Error protection Modulation, Timing and RF-Generation

Network RLC = Radio Link Control MAC = Medium Access Control

Figure: GPRS protocol plane between MS and network

The SNDCP layer is responsible for mapping the characteristics of the network level onto the underlying protocols, which are responsible for data transfer over the air interface. Furthermore, the SNDCP multiplexes the data of different applications, the so called PDP contexts, onto the one transmitting channel created by an established radio link. The LLC layer forms a logical link for data transfer between network and Mobile Station, MS. What is special about this data transfer link, is that it is completely independent from the underlying protocols describing or configuring the air interface. In addition, LLC offers some adjacent features like ciphering, acknowledged or unacknowledged data transfer or like inorder-delivery. 1MAT, St, Version 1.0


2

The RLC layer is responsible for establishing a radio link, for maintaining it or for releasing it. This protocol layer specifies a list of signalling messages to be exchanged between MS and the network to fulfill some tasks concerning the radio link. In this chapter the messages will be described in detail. The main task of the MAC layer is to organize the access to the radio network. One of its main parameters is, for example, the USF value field which identifies the right user of the succeeding radio block. The Physical link layer will build the transportation packets, i.e. the radio blocks, and will form the used GSM Normal Bursts. The training sequence will be included, the interleaving procedure will be done and the burst will be structured. This layer more or less describes the same features that are already known from a GSM network, the only difference is the block data encoding. While in GSM there was an encoding of speech data onto a Normal Burst, in GPRS there will be an encoding of user data, depending on the used Coding scheme. The Physical RF layer basically describes the air interface with its modulation scheme, output power control, frequency channel and timeslot allocation characteristics. Most of its parameters are already known in the GSM air interface. The only difference to GSM will be in a future development step the transition to the new modulation scheme 8PSK.

1MAT, St, Version 1.0


3

Signalling messages of GPRS Radio Resource management, GRR: The GRR uses a list of signalling messages to establish, maintain or release a radio link between MS and the network. The used messages of the RLC/MAC layer are the following:

GRR Signalling Messages (Via RLC/MAC) Downlink Messages

• • • • • • • • • •

•Packet TBF Release Packet Cell Change Order •Packet Uplink Ack / Nack Packet Downlink Assignment •Packet Uplink Assignment Packet Paging Request •Packet Downlink Dummy Control Block Packet PDCH Release •Packet System Information Type 1 Packet Polling Request •Packet System Information Type 2 Packet Power Control/Timing Advance •Packet System Information Type 3 Packet PRACH Parameters •Packet System Information Type 3 bis Packet Queueing Notification •Packet System Information Type 4 Packet Timeslot Reconfigure •Packet System Information Type 5 •Packet System Information Type 13 Packet Access Reject

GRR Signalling Messages (Via RLC/MAC) Uplink Messages

• • • • • • • •

Packet Cell Change Failure Packet Control Acknowledgement Packet Downlink Ack / Nack Packet Uplink Dummy Control Block Packet Measurement Report Packet Resource Request Packet Mobile TBF Status (SMG #30+) Packet PSI Status (SMG #30+)



4

But how do we distinguish between the different messages? In the RLC / MAC block we find a field “message type”. This field indicates which of the following messages is sent.

< Downlink RLC/MAC control message > ::= < MESSAGE_TYPE : bit (6) == 1 00001 > < Packet Access Reject message content > | < MESSAGE_TYPE : bit (6) == 0 00001 > < Packet Cell Change Order message content > | < MESSAGE_TYPE : bit (6) == 0 00010 > < Packet Downlink Assignment message content > | < MESSAGE_TYPE : bit (6) == 0 00011 > < Packet Measurement Order message content > | < MESSAGE_TYPE : bit (6) == 1 00010 > < Packet Paging Request message content > | < MESSAGE_TYPE : bit (6) == 1 00011 > < Packet PDCH Release message content > | < MESSAGE_TYPE : bit (6) == 0 00100 > < Packet Polling Request message content > | < MESSAGE_TYPE : bit (6) == 0 00101 > < Packet Power Control/Timing Advance message content > | < MESSAGE_TYPE : bit (6) == 1 00100 > < Packet PRACH Parameters message content > | < MESSAGE_TYPE : bit (6) == 0 00110 > < Packet Queueing Notification message content > | < MESSAGE_TYPE : bit (6) == 0 00111 > < Packet Timeslot Reconfigure message content > | < MESSAGE_TYPE : bit (6) == 0 01000 > < Packet TBF Release message content > | < MESSAGE_TYPE : bit (6) == 0 01001 > < Packet Uplink Ack/Nack message content > | < MESSAGE_TYPE : bit (6) == 0 01010 > < Packet Uplink Assignment message content > | < MESSAGE_TYPE : bit (6) == 1 00101 > < Packet Downlink Dummy Control Block message content > | < MESSAGE_TYPE : bit (6) == 1 10001 > < PSI1 message content > | < MESSAGE_TYPE : bit (6) == 1 10010 > < PSI2 message content > | < MESSAGE_TYPE : bit (6) == 1 10011 > < PSI3 message content > | < MESSAGE_TYPE : bit (6) == 1 10100 > < PSI3 bis message content > | < MESSAGE_TYPE : bit (6) == 1 10101 > < PSI4 message content > | < MESSAGE_TYPE : bit (6) == 1 10110 > < PSI5 message content > | < MESSAGE_TYPE : bit (6) == 1 10000 > < PSI6 message content > | < MESSAGE_TYPE : bit (6) == 1 11000 > < PSI7 message content > | < MESSAGE_TYPE : bit (6) == 1 11001 > < PSI8 message content > | < MESSAGE_TYPE : bit (6) == 1 10111 > < PSI13 message content > ! < Unknown message type : bit (6) = < no string > < Default downlink message content > > ;

< Uplink RLC/MAC control message > ::= < MESSAGE_TYPE : bit (6) == 000000 > < MESSAGE_TYPE : bit (6) == 000001 > < MESSAGE_TYPE : bit (6) == 000010 > < MESSAGE_TYPE : bit (6) == 000011 > < MESSAGE_TYPE : bit (6) == 000100 > < MESSAGE_TYPE : bit (6) == 001010 > < MESSAGE_TYPE : bit (6) == 000101 > < MESSAGE_TYPE : bit (6) == 000110 > < MESSAGE_TYPE : bit (6) == 000111 > < MESSAGE_TYPE : bit (6) == 001000 > < MESSAGE_TYPE : bit (6) == 001001 > < MESSAGE_TYPE : bit (6) == 001010 >


< Packet Cell Change Failure message content > | < Packet Control Acknowledgement message content > | < Packet Downlink Ack/Nack message content > | < Packet Uplink Dummy Control Block message content > | < Packet Measurement Report message content > | < Packet Enhanced Measurement Report message content > | < Packet Resource Request message content > | < Packet Mobile TBF Status message content > | < Packet PSI Status message content > | < EGPRS Packet Downlink Ack/Nack message content > | < Packet Pause message content > | < Additional MS Radio Access Capabilities message content>;


5

The description of the single messages is given as follows, in chronological order, corresponding to the message type field: Packet Access Reject This message is sent on the PCCCH or PACCH by the network to the mobile station to indicate that the network has rejected the MSs access request. This message may contain fields addressing more than one mobile station. The direction of this message is network to MS. Packet Control Acknowledgement This message is sent on the PACCH from the mobile station to the network. The message is formatted either as an RLC/MAC control block or as 4 identical access bursts. If sent as a response to a Packet Polling Request message, this latter message shall specify the format of the Packet Control Acknowledgement message. Otherwise, the System Information parameter CONTROL_ACK_TYPE indicates which format the mobile station shall use. The access burst format is 11 bits or 8 bits long. If the System Information parameter ACCESS_BURST_TYPE indicates 11-bit access, the mobile station shall transmit the 11-bit format. If the System Information parameter ACCESS_BURST_TYPE indicates 8-bit access, the mobile station shall transmit the 8-bit format. The mobile station shall transmit the access burst four times, once in each TDMA frame of the uplink radio block. This message is sent in the direction of mobile station to network. Packet Cell Change Failure This message is sent on the PACCH from the mobile station to the network to indicate that a commanded cell change order has failed. Packet Cell Change Order This message is sent on the PCCCH or PACCH by the network to the mobile station to tell the mobile station to leave the current cell and change to a new cell. This message is the GPRS replacement for the Handover command (HND_CMD) message in GSM. Packet Channel Request This message is sent in random mode on the PRACH. It does not follow the basic format of a GSM Normal Burst. For this message, the MS will use the short Access Burst, just as known in GSM. The possible formats of this burst are 8 or 11-bit format. The total length of this burst is still the same, only the synchronisation sequence of this burst will be shorter, while the message length will be enhanced to 11 bit instead of 8 bit length which is already known. The message is 11 bits or 8 bits long. If the System Information parameter ACCESS_BURST_TYPE indicates 11-bit access, the mobile station shall transmit the 11-bit format. If the System Information parameter ACCESS_BURST_TYPE indicates 8-bit access, the mobile station shall transmit the 8-bit format. EGPRS Packet Channel Request This message is sent by EGPRS capable MSs in cells supporting EGPRS and using 11 bit ACCESS BURST TYPE. This message is sent to perform EGPRS one-phase access request, EGPRS short access request or EGPRS two-phase access request. For all other purposes (page response, cell update etc.) the standard PACKET CHANNEL REQUEST message shall be used.



6

Packet Downlink Ack/Nack This message is sent on the PACCH from the mobile station to the network to indicate the status of downlink RLC data blocks received and to report the channel quality of the downlink. The mobile station may optionally initiate an uplink TBF. EGPRS Packet Downlink Ack/Nack This message is sent on the PACCH from the mobile station to the network to indicate the status of downlink RLC data blocks received and to report the channel quality of the downlink. The mobile station may optionally initiate an uplink TBF or request a temporary suspension of the downlink TBF. Packet Downlink Assignment This message is sent on the PCCCH or PACCH by the network to the mobile station to assign downlink resources to the mobile station. For a mobile station assigned to operate in the fixed allocation MAC mode, the network may assign regularly repeating intervals during which the mobile station shall measure neighbour cell power levels. A mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new assignment is received or each TBF of the MS is terminated. Packet Downlink Dummy Control Block This message is sent on the PCCCH or PACCH by the network to the mobile station as a fill message with either of the optional parameters PAGE_MODE and PERSISTENCE_LEVEL, or with no content. Packet Uplink Dummy Control Block This message is sent on the PACCH from the mobile station to the network when the mobile station has no other block to transmit. Packet Measurement Report This message is sent on the PACCH from the mobile station to the network to report measurement results. The message may contain measurement results from the Network Control measurements or from the Extended measurements, but not both simultaneously. More than one message may be required depending on the number of measurements to report. Packet Measurement Order This message is sent on the PCCCH or PACCH by the network to a mobile station giving information for NC and EXT measurement reporting and network controlled cell reselection. If not all information fits into one message, the remaining information will be sent in other instances of the Packet Measurement Order message. Packet Mobile TBF Status This message is sent from the mobile station to the network on the uplink PACCH to indicate erroneous messages have been received relating to either a downlink or an uplink TBF.



7

Packet Enhanced Measurement Report This message is sent either on the PACCH, if in packet transfer mode, or on an assigned block on a PDTCH, from the mobile station to the network to report enhanced measurement results. The message contains measurement results from the Network Control measurements. More than one message may be required depending on the number of measurements to report. Packet Paging Request This message is sent on the PCCCH by the network to trigger channel access by up to four mobile stations, for either TBF or RR connection establishment. It may also be sent on PACCH to a mobile station in packet transfer mode to indicate page request for RR connection establishment. The mobile stations are identified by either IMSI, TMSI or P-TMSI. Depending on the method used to identify the mobile station, 1 - 4 mobile stations can be addressed in the message. Special requirements for the transmission of this message on PACCH applies, see specifications GSM 05.02. Packet PDCH Release This message is sent on PACCH by the network to notify all mobile stations listening to that PDCH that one or more PDCHs will be immediately released and become unavailable for packet data traffic. Packet Polling Request This message is sent on the PCCCH or PACCH by the network to the mobile station to solicit a PACKET CONTROL ACKNOWLEDGEMENT message from the mobile station. Packet Power Control/Timing Advance This message is sent on PACCH by the network to the mobile station in order to update the mobile station timing advance or power control parameters. Packet PRACH Parameters This message is sent on the PCCCH by the network to all mobile stations within the cell to update the PRACH parameters in between Packet System Information messages containing PRACH parameters. Packet Queueing Notification This message is sent on the PCCCH by the network to the mobile station to notify the mobile station that it is being placed in a queue. The message allocates a Temporary Queueing Identity to the mobile station. Packet Resource Request This message is sent on the PACCH by the mobile station to the network to request a change in the uplink resources assigned. Packet PSI Status This message is sent on the PACCH from the mobile station to the network to indicate which PSI messages the mobile station has received.



8

Packet System Information Type 1 This message is sent by the network on the PBCCH or PACCH giving information for Cell selection, for control of the PRACH, for description of the control channel(s) and optional global power control parameters. Packet System Information Type 2 This message is sent by the network on PBCCH and PACCH giving information about reference frequency lists, cell allocation, GPRS mobile allocations and PCCCH descriptions being used in the cell. PSI2 also contains Non-GPRS cell options applicable for non-packet access. Packet System Information Type 3 This message is sent by the network on the PBCCH or PACCH giving information about the BCCH allocation (BA_GPRS) in the neighbour cells and cell selection parameters for serving cell and non-serving cells. Packet System Information Type 3 bis This message is sent by the network on the PBCCH and PACCH giving information about the BCCH allocation in the neighbour cells and cell selection parameters for non-serving cells. Packet System Information Type 4 This message is optionally sent by the network on the PBCCH and PACCH giving information directing the mobile station to make interference measurements. Packet System Information Type 5 This optional message is sent by the network on the PBCCH giving information for measurement reporting and network controlled cell reselection. Packet System Information Type 6 This optional message is sent by the network on the PBCCH or PACCH to provide broadcast information required by non-GSM networks. Packet System Information Type 7 This optional message is sent by the network on the PBCCH or PACCH to provide broadcast information required by non-GSM networks. Packet System Information Type 8 This message is optionally sent by the network on the PBCCH and PACCH giving information about Cell Broadcast Channel configuration. Packet System Information 13 This message may be broadcast by the network on the PACCH or on the PCCCH. The message provides the mobile station with GPRS cell specific access-related information. Packet TBF Release This message is sent on the PACCH by the network to the mobile station to initiate release of an uplink or downlink TBF.



9

Packet Uplink Ack/Nack This message is sent on the PACCH by the network to the mobile station indicating the status of the received RLC data blocks. This message may also update the timing advance and power control parameters. A fixed allocation mobile station may also be assigned uplink resources. Packet Uplink Assignment This message is sent on the PCCCH or PACCH by the network to the mobile station to assign uplink resources. The mobile station may be addressed by TFI (=Temporary Flow Identifier), TQI (=Temporary Queing Identifier), or Packet Request Reference, depending upon the procedure used. A mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new assignment is received or each TBF of the MS are terminated. Packet Timeslot Reconfigure This message is sent on the PACCH by the network to the mobile station to assign uplink and/or downlink resources. A mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new assignment is received or each TBF of the MS are terminated. Additional MS Radio Access Capabilities This message is sent on the PACCH by the mobile station to the network to inform about radio access capabilities of the mobile station.



10

Signalling messages for GPRS Mobility Management Ready Timer procedure The value of the READY timer may be negotiated between the MS and the network using the GPRS attach or GPRS routing area updating procedure. The READY timer, T3314 is used in the MS and in the network per each assigned P-TMSI to control the cell updating procedure. When the READY timer is running or has been deactivated, the MS shall perform cell update each time a new cell is selected. When the READY timer has expired the MS shall: - perform the routing area updating procedure when a routing area border is crossed; - not perform a cell update when a new cell is selected. All other GMM procedures are not affected by the READY timer. Periodic routing area updating Periodic routing area updating is used to periodically notify the availability of the MS to the network. The procedure is controlled in the MS by the periodic RA update timer, T3312. The value of timer T3312 is sent by the network to the MS in the messages ATTACH ACCEPT and ROUTING AREA UPDATE ACCEPT. The value of the timer T3312 shall be unique within an RA. The timer T3312 is reset and started with its the initial value when the READY timer is stopped or expires. The timer T3312 is stopped and shall be set to its initial value for the next start when the READY timer is started. If after a READY timer negotiation the READY timer value is set to zero, the timer T3312 is reset and started with its initial value .If the initial READY timer value is zero, the timer T3312 is reset and started with its initial value when the ROUTING AREA UPDATE REQUEST message is transmitted. When timer T3312 expires, the periodic routing area updating procedure shall be started and the timer shall be set to its initial value for the next start. GPRS attach procedure The GPRS attach procedure is used for two purposes: - normal GPRS attach, performed by the MS to IMSI attach for GPRS services only. The normal GPRS attach procedure shall be used by GPRS MSs in MS operation mode C, independent of the network operation mode. It shall also be used by GPRS MSs in MS operation modes A or B if the network operates in network operation mode II or III . - combined GPRS attach procedure, used by GPRS MSs in MS operation modes A or B to attach the IMSI for GPRS and non-GPRS services provided that the network operates in network operation mode I. With a successful GPRS attach procedure a GMM context is established.



11

GPRS detach procedure The GPRS detach procedure is used: to detach the IMSI for GPRS services only. Independent of the network operation mode, this procedure is used by all kind of GPRS MSs; as a combined GPRS detach procedure used by GPRS MSs operating in MS operation mode A or B to detach the IMSI for GPRS and non-GPRS services, or for nonGPRS services only, if the network operates in network operation mode I; or in the case of a network failure condition to indicate to the MS that a re-attach with successive activation of previously active PDP contexts shall be performed. After completion of a GPRS detach procedure or combined GPRS detach procedure for GPRS and non-GPRS services, the GMM context is released. The GPRS detach procedure shall be invoked by the MS if the MS is switched off, the SIM card is removed from the MS or if the GPRS or non-GPRS capability of the MS is disabled. The procedure may be invoked by the network to detach the IMSI for GPRS services. The GPRS detach procedure causes the MS to be marked as inactive in the network for GPRS services, non-GPRS services or both services. If the GPRS detach procedure is performed, the PDP contexts are deactivated locally without peer to peer signalling between the SM and LLC entities in the MS and the network. MS initiated GPRS detach procedure initiation The GPRS detach procedure is initiated by the MS by sending a DETACH REQUEST message. The detach type information element may indicate “GPRS detach with switching off”, “GPRS detach without switching off”, “IMSI detach”, “GPRS/IMSI detach with switching off” or “GPRS/IMSI detach without switching off”. If the MS is not switched off, timer T3321 shall be started after the DETACH REQUEST message has been sent. If the detach type information element value indicates “IMSI Detach” the MS shall enter GMMREGISTERED.IMSI-DETACH_INITIATED, otherwise the MS shall enter the state GMMDEREGISTERED-INITIATED. If the detach type information element value indicates “IMSI Detach” or “GPRS/IMSI Detach”, state MM IMSI DETACH PENDING is entered. Network initiated GPRS detach procedure initiation The network initiates the GPRS detach procedure by sending a DETACH REQUEST message to the MS. The DETACH REQUEST message shall include a detach type IE. In addition, the network may include a cause IE to specify the reason for the detach request. The network shall start timer T3322. If the detach type IE indicates “re-attach not required” or “reattach required", the network shall deactivate the PDP contexts and deactivate the logical link(s), if any, and shall change to state GMM-DEREGISTERED-INITIATED. Routing area updating procedure This procedure is used for: - normal routing area updating to update the registration of the actual routing area of an MS in the network. This procedure is used by GPRS MSs in MS operation mode C and by GPRS MSs in MS operation modes A or B that are IMSI attached for GPRS and nonGPRS services if the network operates in network operation mode II or III; - combined routing area updating to update the registration of the actual routing and location area of an MS in the network. This procedure is used by GPRS MSs in MS operation modes A or B that are IMSI attached for GPRS and non-GPRS services provided that the network operates in network operation mode I; or 1MAT, St, Version 1.0


12

- periodic routing area updating. This procedure is used by GPRS MSs in MS operation mode C and by GPRS MSs in MS operation modes A or B that are IMSI attached for GPRS or for GPRS and non-GPRS services independent of the network operation mode; -

IMSI attachment for non-GPRS services when the MS is IMSI attached for GPRS services. This procedure is used by GPRS MSs in MS operation modes A or B, if the network operates in network operation mode I.

P-TMSI reallocation procedure A temporary mobile station identity for GPRS services, the Packet-TMSI (P-TMSI), is used for identification within the radio interface signalling procedures. The structure of the P-TMSI is specified in GSM 03.03 [10]. The P-TMSI has significance only within a routing area. Outside the routing area it has to be combined with the routing area identification (RAI) to provide for an unambiguous identity. The purpose of the P-TMSI reallocation procedure is to provide identity confidentiality, i.e. to protect a user against being identified and located by an intruder. Usually, P-TMSI reallocation is performed at at least each change of a routing area. (Such choices are left to the network operator). The reallocation of a P-TMSI is performed by the unique procedure defined in this section. This procedure can only be initiated by the network in state GMM-REGISTERED. Authentication and ciphering procedure The purpose of the authentication and ciphering procedure is threefold: to permit the network to check whether the identity provided by the MS is acceptable or not. to provide parameters enabling the MS to calculate a new GPRS ciphering key; and to let the network set the ciphering mode (ciphering/no ciphering) and algorithm. The authentication and ciphering procedure can be used for either: authentication only; setting of the ciphering mode and the ciphering algorithm only; or authentication and the setting of the ciphering mode and the ciphering algorithm. The authentication and ciphering procedure is always initiated and controlled by the network. Identification procedure The identification procedure is used by the network to request an MS to provide specific identification parameters to the network e.g. International Mobile Subscriber Identity, International Mobile Equipment Identity



13

Paging for GPRS services Paging is used by the network to identify the cell the MS has currently selected, or to prompt the mobile to re-attach, if necessary, as a result of network failure. If the MS is not GPRS attached when it receives a paging for GPRS services, the MS shall ignore the paging. Paging for GPRS services using P-TMSI: The network shall initiate the paging procedure for GPRS services using P-TMSI when GMM signalling messages or user data is pending to be sent to the MS while the Mobile Reachable timer is running. The network may page only GPRS MSs which are GMM-REGISTERED and identified by a local P-TMSI. Paging for GPRS services using IMSI: Paging for GPRS services using IMSI is an abnormal procedure used for error recovery in the network. The network may initiate paging using IMSI if the P-TMSI is not available due to a network failure.

GPRS Session management The main function of the session management (SM) is to support PDP context handling of the user terminal. The SM comprises procedures for identified PDP context activation, deactivation and modification; and anonymous PDP context activation and deactivation. SM procedures for identified access can only be performed if a GMM context has been established between the MS and the network. If no GMM context has been established, the MM sublayer has to initiate the establishment of a GMM context by use of the GMM procedures as described in chapter 4. After GMM context establishment, SM uses services offered by GMM. Ongoing SM procedures are suspended during GMM procedure execution. For anonymous access, no GMM context is established.

Session management states In this section, the SM states are described for one SM entity. Each SM entity is associated with one PDP context. The following picture describes the SM states in the MS and on the network side.



14

Session management states in the MS In this section, the possible states of an SM entity in the mobile station are described. As illustrated in the figure, there are four SM states in the MS. PDP-INACTIVE

This state indicates that no PDP context exists. PDP-ACTIVE-PENDING

This state exists when PDP context activation is requested by the MS. PDP-INACTIVE-PENDING

This state exists when deactivation of the PDP contexts is requested by the MS. PDP-ACTIVE

This state indicates that the PDP context is active. DI (REQ PDP CONTX. ACTIV)

DI (DEACTIV. PDP CONTX. ACC)

PDP-INACTIVE

DR (ACTIV. PDP CONTX. REQ) DR (DEACTIV. PDP CONTX. ACC) DR (ACTIV. PDP CONTX. REQ)

DR (DEACTIV. PDP CONTX. ACC)

DI (ACTIV. PDP CONTX. REJ)

DI (DEACTIV. PDP CONTX. REQ)

DI (DEACTIV. PDP CONTX. REQ)

PDP-INACTIVEPENDING

PDP-ACTIVEPENDING

DI (ACTIV. PDP CONTX. ACC)

DR (DEACTIV. PDP CONTX. REQ)

PDP-ACTIVE

DI (MOD PDP CONTXT REQ)

DR (MOD PDP CONTXT ACC)

DR: GMMSM-DATA-REQUEST (Message), i.e. message sent by an MS DI: GMMSM-DATA-INDICATION (Message), i.e. message received by an MS

Figure: Session management states in the MS (overview)



15

Session management states on the network side In this section, the possible states of an SM entity on the network side are described. As illustrated in figure 6.2/GSM 04.08, there are five SM states on the network side. PDP-INACTIVE

This state indicates that the PDP context is not active. PDP-ACTIVE-PENDING

This state exists when the PDP context activation is initiated by the network. PDP-INACTIVE-PENDING

This state exists when deactivation of the PDP context is requested by the network. PDP-ACTIVE

This state indicates that the PDP context is active. PDP-MODIFY-PENDING

This state exists when modification of the PDP context is requested by the network. PDP-ACTIVEPEND

DI (ACTIV. PDP CONTX. REQ)

DI (REQ PDP CONTX. ACTIV. REJ)

DR (ACTIV. PDP CONTX. ACC)

DR (REQ PDP CONTX. ACTIV) DI (ACTIV. PDP CONTX. REQ)

DR (ACTIV. PDP CONTX. ACC)

PDP ACTIVE

PDP-INACTIVE

DR (ACTIV. PDP CONTX. REJ) DR (DEACTIV. PDP CONTX. ACC) DI (DEACTIV. PDP CONTX. REQ)

DR (MODIFY. PDP CONTX. REQ) DR (DEACTIV. PDP CONTX. REQ)

DI (DEACTIV. PDP CONTX. ACC)

DI (MODIFY. PDP CONTX. ACC)

PDP-INACTIVEPEND PDP-MODIFYPEND

DR: GMMSM-DATA-REQUEST (Message), i.e. message sent by network DI: GMMSM-DATA-INDICATION (Message), i.e. message received by the network

Figure Session management states on the network side (overview)



16

Session Management procedures PDP context activation The purpose of this procedure is to establish a PDP context between the MS and the network for a specific QoS on a specific NSAPI. The PDP context activation may be initiated by the MS or the initiation may be requested by the network. Successful PDP context activation initiated by the mobile station In order to request a PDP context activation, the MS sends an ACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-ACTIVE-PENDING and starts the timer T3380. The message contains the selected NSAPI, PDP type and, if the MS requests a static address, the PDP address. The MS shall ensure that the selected NSAPI is not currently being used by another Session Management entity in the MS. Upon receipt of an ACTIVATE PDP CONTEXT REQUEST message, the network selects a radio priority level based on the QoS negotiated and may reply with an ACTIVATE PDP CONTEXT ACCEPT message. Upon receipt of the message ACTIVATE PDP CONTEXT ACCEPT the MS shall stop timer T3380 and enter the state PDP-ACTIVE. The MS shall initiate establishment of the logical link for the LLC SAPI indicated by the network with the offered QoS and selected radio priority level if no logical link has been already established for that SAPI. If the offered QoS parameters received from the network differ from the QoS requested by the MS, the MS shall either accept the negotiated QoS or initiate the PDP context deactivation procedure. If the LLC SAPI indicated by the network can not be supported by the MS, the MS shall initiate the PDP context deactivation procedure. Successful PDP context activation requested by the network In order to request a PDP context activation, the network sends a REQUEST PDP CONTEXT ACTIVATION message to the MS and starts timer T3385. If available, the APN shall be included in the REQUEST PDP CONTEXT ACTIVATION message. Upon receipt of a REQUEST PDP CONTEXT ACTIVATION message, the MS shall than either initiate the PDP context activation procedure as described in the previous section or shall reject the activation request by sending a REQUEST PDP CONTEXT ACTIVATION REJECT message. The value of the reject cause IE of the REQUEST PDP CONTEXT ACTIVATION REJECT message shall indicate the reason for rejection, e.g. “insufficient resources to activate another context”. The ACTIVATE PDP CONTEXT REQUEST message sent by the MS in order to initiate the PDP context activation procedure shall contain the PDP address, PDP Type and APN requested by the network in the REQUEST PDP CONTEXT ACTIVATION message. Upon receipt of the ACTIVATE PDP CONTEXT REQUEST message, the network shall stop timer T3385. The same procedures then apply as described for MS initiated PDP context activation.



MS

17

Network ACTIVATE PDP CONTEXT REQUEST

Start T3380 ACTIVATE PDP CONTEXT ACCEPT

Stop T3380

or ACTIVATE PDP CONTEXT REJECT

Stop T3380

Figure: MS initiated PDP context activation procedure

MS

Network

REQUEST PDP CONTEXT Start T3385 ACTIVATE PDP CONTEXT REQUEST Start T3380

Stop T3385 ACTIVATE PDP CONTEXT ACCEPT

Stop T3380 or ACTIVATE PDP CONTEXT REJECT Stop T3380 or REQUEST PDP CONTEXT ACTIVATION REJECT

Stop T3385

Figure: Network initiated PDP context activation procedure PDP context modification procedure The PDP context modification procedure is invoked by the network in order to change the QoS negotiated during the PDP context activation procedure or at previously performed PDP context modification procedures. The procedure can be initiated by the network at any time when a PDP context is active. In order to initiate the procedure, the network sends the MODIFY PDP CONTEXT REQUEST message to the MS and starts the timer T3386. The message shall contain the new QoS and the radio priority level that shall be used by the MS at the lower layers for the transmission of data related to the PDP context. Upon receipt of this message the MS shall reply with the MODIFY PDP CONTEXT ACCEPT message if the MS accepts the new QoS and the indicated LLC SAPI. If the MS does not accept the new QoS or the indicated LLC SAPI, the MS shall initiate the PDP context deactivation procedure for the PDP context - the reject cause IE value of the DEACTIVATE PDP CONTEXT REQUEST message shall indicate “QoS not accepted”. 1MAT, St, Version 1.0


18

PDP context deactivation procedure The purpose of this procedure is to deactivate an existing PDP context between the MS and the network. The PDP context deactivation may be initiated by the MS or by the network. PDP context deactivation initiated by the MS In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-INACTIVE-PENDING and starts timer T3390. The message contains the transaction identifier in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes: # 25: LLC or SNDCP failure; # 26: insufficient resources; # 36: regular PDP context deactivation; or # 37: QoS not accepted. The network shall reply with the DEACTIVATE PDP CONTEXT ACCEPT message. Upon receipt of the DEACTIVATE PDP CONTEXT ACCEPT message, the MS shall stop timer T3390. Both the MS and the network shall initiate local release of the logical link if it is not used by another PDP context. PDP context deactivation initiated by the network In order to deactivate a PDP context, the network sends a DEACTIVATE PDP CONTEXT REQUEST message to the MS and starts timer T3395. The message contains the transaction identifier in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes: # 25: LLC or SNDCP failure; # 36: regular PDP context deactivation; # 38: network failure; or # 39: reactivation requested. The MS shall, upon receipt of this message, reply with a DEACTIVATE PDP CONTEXT ACCEPT message. Upon receipt of the DEACTIVATE PDP CONTEXT ACCEPT message, the network shall stop the timer T3395. Both the MS and the network shall initiate local release of the logical link if it is not used by another PDP context.



MS

19

Network DEACTIVATE PDP CONTEXT REQUEST

Start T3390 DEACTIVATE PDP CONTEXT ACCEPT

Stop T3390

Figure: MS initiated PDP context deactivation procedure

MS

Network DEACTIVATE PDP CONTEXT REQUEST Start T3395 DEACTIVATE PDP CONTEXT ACCEPT Stop T3395

Figure: Network initiated PDP context deactivation procedure Messages for GMM and SM P-TMSI reallocation command This message is sent by the network to the MS to reallocate a P-TMSI. P-TMSI reallocation complete This message is sent by the MS to the network to indicate that reallocation of a P-TMSI has taken place. Authentication and ciphering request This message is sent by the network to the MS to initiate authentication of the MS identity. In addition, the ciphering mode is set, indicating whether ciphering will be performed or not. Authentication and ciphering response This message is sent by the MS to the network in response to an Authentication and ciphering request message. Authentication and ciphering reject This message is sent by the network to the MS to indicate that authentication has failed (and that the receiving MS shall abort all activities). Identity request This message is sent by the network to the MS to request submission of the MS identity according to the specified identity type. E.g. responses are IMSI, TMSI, P-TMSI or IMEI.



20

Identity response This message is sent by the MS to the network in response to an identity request message providing the requested identity. Routing area update request This message is sent by the MS to the network either to request an update of its location file or to request an IMSI attach for non-GPRS services. Routing area update accept This message is sent by the network to the MS to provide the MS with GPRS mobility management related data in response to a routing area update request message. Routing area update complete This message shall be sent by the MS to the network in response to a routing area update accept message if a P-TMSI and/or a TMSI has been assigned and/or if there are established LLC connections. Routing area update reject This message is sent by the network to the MS in order to reject the routing area update procedure. GMM Status This message is sent by the MS or by the network at any time to report certain error conditions listed in the information element GMM cause. The purpose of the GMM cause information element is to indicate the reason why a GMM request from the mobile station is rejected by the network. Some possible field values are: • IMSI unknown in HLR • Illegal MS • Illegal ME • GPRS services not allowed • GPRS services and non-GPRS services not allowed • MS identity cannot be derived by the network • Implicitly detached • PLMN not allowed • Location Area not allowed • Roaming not allowed in this location area • MSC temporarily not reachable • Network failure • Congestion • Etc. GMM Information This message is sent by the network at any time to send certain information to the MS. This information could be: Full name for network, Short name for network, Network time zone, Universal time and time zone, LSA Identity, ...



21

Activate PDP context request This message is sent by the MS to the network to request activation of a PDP context. Activate PDP context accept This message is sent by the network to the MS to acknowledge activation of a PDP context. Activate PDP context reject This message is sent by the network to the MS to reject activation of a PDP context. Request PDP context activation This message is sent by the network to the MS to initiate activation of a PDP context. Request PDP context activation reject This message is sent by the MS to the network to reject initiation of a PDP context activation. Modify PDP context request This message is sent by the network to the MS to request modification of an active PDP context. Modify PDP context accept This message is sent by the MS to the network to acknowledge the modification of an active PDP context. Deactivate PDP context request This message is sent to request deactivation of an active PDP context. Deactivate PDP context accept This message is sent to acknowledge deactivation of the PDP context requested in the corresponding Deactivate PDP context request message. Activate AA PDP context request This message is sent by the MS to the network to initiate activation of an AA PDP context. AA = Anonymous Access PDP context request. Activate AA PDP context accept This message is sent by the network to the MS to acknowledge the activation of an AA PDP context. Activate AA PDP context reject This message is sent by the network to the MS to reject the activation of an AA PDP context. Deactivate AA PDP context request This message is sent to request deactivation of an active AA PDP context. Deactivate AA PDP context accept This message is sent to acknowledge deactivation of an AA PDP context requested by the corresponding Deactivate AA PDP context request message.



22

SM Status This message is sent by the network or the MS to pass information on the status of the indicated context and report certain error conditions. How can you identify the current GPRS MM or SM message? This is given by the information element type in the Layer 3 message: Message types for GPRS mobility management Bits 8 7 6 5 4 3 2 1 0 0 - - - - - -

Mobility management messages

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 1 1 1

0 1 1 0 0 1

1 0 1 0 1 0

Attach Attach Attach Attach Detach Detach

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

1 1 1 1

0 0 0 0

0 0 1 1

0 1 0 1

Routing Routing Routing Routing

0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 1 1

1 1 1 1 1 1 1 0 0

0 0 0 0 0 0 0 0 0

0 0 0 0 1 1 1 0 0

0 0 1 1 0 0 1 0 0

0 1 0 1 0 1 0 0 1

P-TMSI reallocation command P-TMSI reallocation complete Authentication and ciphering req Authentication and ciphering resp Authentication and ciphering rej Identity request Identity response GMM status GMM information

request accept complete reject request accept area area area area

update update update update

request accept complete reject

Message types for GPRS session management Bits 8 7 6 5 4 3 2 1


0 1 - - - - - -

Session management messages

0 1 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 1 0 0 0 0 1 1

Activate PDP context request Activate PDP context accept Activate PDP context reject

0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 1

Request PDP context activation Request PDP context activation rej.

0 1 0 0 0 1 1 0 0 1 0 0 0 1 1 1

Deactivate PDP context request Deactivate PDP context accept

0 1 0 0 1 0 0 0 0 1 0 0 1 0 0 1

Modify PDP context request Modify PDP context accept

0 1 0 1 0 0 0 0 0 1 0 1 0 0 0 1 0 1 0 1 0 0 1 0

Activate AA PDP context request Activate AA PDP context accept Activate AA PDP context reject

0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 0

Deactivate AA PDP context request Deactivate AA PDP context accept

0 1 0 1 0 1 0 1

SM Status


23

GPRS Radio Interface: Encapsulation: The user data will be encapsulated into the different protocol planes before transmitting over the GPRS air interface. The following figure indicates this encapsulation procedure in the example of a Mobile Station.

Protocol layer inside MS:

Application

Data

IP

TCP/IP

SNDCP

SNDCP Max length = 1600 octets

LLC

LLC

Information field

FCS

184 - 440 bit, depending on CS-1 - CS-4 16 or 40 bit, depending on CS

RLC/MAC

RLC/ MAC

Data field

BCS

= new data

Convolutional encoding

RF

456 bit

= previous layer

Figure: Encapsulation of user data in different protocol layer Please remark that there is no fixed relation between the protocol headers and the user data. More or less all protocol headers will have a dynamic length, depending on the context. This length will also vary through a communication link, result will be always an variating data rate of the output data. The Frame Check Sequence, FCS in the LLC frame structure is necessary, because in GPRS it is possible, that the air interface, let’s say the RLC / MAC layer is not using any kind of forward error correction. This will be in case of Coding Scheme CS-4. For this reason, the LLC layer must have an error detection mechanism. Together with the error detection mechanism in the RLC/MAC layer, the Block Check Sequence, BCS this will be a double error detection mechanism. But the length of the BCS is changing between 16 or 40 bit, i.e. the protection or detection quality is very good concerning the block header, the RLC and MAC header but it does not have the best quality of protection over all the data field.



24

GPRS: Identifiers on the data transport over the air interface In GPRS there are some questions to be answered before handing out the received data to the right application. For this reason, there are some different identifiers that have to be used in certain protocol layers. The following picture demonstrates these most important Identifiers, to be used for reaching the final destination if we transmit a Packet Data Unit, PDU. The 3 identifiers, TFI, SAP and NSAPI are cascaded in the following way:

PDP

PDP

PDP NSAPI

TOM

SMS

SM/GMM

SNDCP

SAPI LLC RLC/ MAC

Identifies MS

RF

Identifies Layer 3 Protocol

Identifies PDP context

PI I NSA TLLI or SAP TFI

Figure: Cascading of the identifiers in GPRS The first question to be answered, if a BTS transmits a PDU, is who is the owner of this data packet, i.e. which Mobile Station should receive this downlink data. For this reason there is an identifier, TLLI, Temporary Logical Link Identifier, that is derived or calculated out of the PTMSI, the subscriber identity number. Because of the length of this TLLI we also use a short form, the so called Temporary Flow Identifier, TFI. The TFI is only 5 bits in length, so there are maybe some mismatches after assignment, that’s the reason, why in the first downlink data blocks, there will always be the inclusion of the TLLI, that is much longer and therefore the probability of misunderstanding is much lower. This identifier is directly concerned to the air interface, it will be a question of the receiver, if he shall hand out this data unit to higher layers of if he shall discard it, because it was sent to somebody else. For this reason, the TLLI or TFI is included in the RLC/MAC header. If the right Mobile Station, MS has received the data unit, there are now some more possibilities. The next question to be answered is, which higher layer protocol should receive the data unit, for example, is this received data unit a signalling message of the GPRS mobility management or is it some user data, packed into an SNDCP header? To answer this question, we use the Service Access Point Identifier, SAPI included in the transport layer frame, the LLC frame. This identifier indicate the higher layer (in OSI Modell = Layer 3) protocol that will be the owner of the received packet data unit. In GPRS we can find here the 1MAT, St, Version 1.0


25

distinction between, GPRS Mobility Management, GPRS Session Management, SMS Transfer, User Data Unit via SNDCP or GSM foreign signalling messages, tunnelled with the Tunneling of Messeges protocol, TOM. In our next step, we assume that this received packet data unit is to be forwarded to the user application, i.e. by the received data it is about a SNDCP data unit. But as we have seen, in GPRS it is possible, that we can find more than one activated application, or the so called PDP context that is activated. Now it is the task of this receiving layer to forward the incoming data to the right application. Every PDP context is identified with this parameter, Network Service Access Point Identifier, NSAPI. Each NSAPI points to the corresponding application.



26

GPRS: Assignment of Radio Resource In GPRS there are in principle two different ways how to assign radio ressource. First we have to assure, that in GPRS uplink and downlink are completely different from each other and will be assigned in 2 steps. Packet Uplink Assignment and Packet Downlink Assignment. Packet Downlink Assignment: This assignment consists of the main parameters: TFI: Temporary Flow Identifier. Included in every RLC/MAC Block, identifies the owner of this radio block. Timeslot Allocation: Bitmap of 8 Bits, that indicates, which timeslot has been assigned for downlink data transfer. TBF Starting time: To indicate, when the data transfer will begin. Starting time refering to the GSM clock timing, or multiframe number. Frequency parameters: Which frequency channel shall be used .

Consequence will be for the Mobile Station, to receive every downlink radio block on the assigned timeslots and decide after receiving by checking the TFI field in the RLC header if the radio must to be forwarded to higher layer protocols or will be discarded.

Packet Uplink Assignment: This uplink assignment contains as important Information Elements, IE the following parameters: TFI and TLLI: Assignment of the identifier of the TBF, to be included in every radio block. Channel Coding Command: Which Coding Scheme should be used. Packet Timing Advance: Field that contains the Timing Advance value to be used, the Timing Advance Index for the update procedure on PTCCH and the timeslot, where the PTCCH is active. Frequency parameters: Which frequency channel shall be used . If dynamic allocation: USF value as 3 bit field, for every assigned timeslot Power control parameter: the necessary parameters to calculate the transmitting power of the MS. E. g. alpha, gamma and p0 parameter. See formula on other chapter for details. TBF Starting time: when will the TBF start.



27

Monitoring USF in Block B(n) Sends in Block B(n+1) or in Blocks B(n+1) - B(n+4) USF = R1

n) k B( c o l oB Radi downlink

USF = R2

USF

k uplin

USF = R3

1) B(n+ k c o o Bl Radi Fixed Allocation = Fixed number of octets to be transmitted in N bundled Timeslots

USF = Free USF = Free Monitoring Paging Channel Send Access Burst

Dynamic Allocation = USF points to next Radio Block on uplink RF-Channel for use by MS Extended Dynamic Allocation = USF points to next 4 Radio Blocks on uplink RF-Channel for use by MS

Figure: usage of the USF field in the uplink TBF establishment

If fixed allocation: Downlink control timeslot: This indicates, which downlink timeslot should be monitored for PACCH blocks. Timeslot allocation: to indicate which timeslots should be used by the MS on the uplink Bitmap allocation: Refering to the 52 Multiframe: which radio blocks will be assigned to the MS for uplink data transfer. Packet Timing Advance: Field that contains the Timing Advance value to be used, the Timing Advance Index for the update procedure on PTCCH and the timeslot, where the PTCCH is active. Power control parameter: the necessary parameters to calculate the transmitting power of the MS. E. g. alpha, gamma and p0 parameter. See formula on other chapter for details.



28

Bitmap example

Timeslot Allocation

00001011

012345 67 PDCH

Allocation Bitmap 010 111 000 110 111 000 111 000 101 001 100 111

example

52 TDMA Frames

TN4

B0 B1 B2 T B3 B4 B5 X B6 B7 B8 T B9

B10 B11X

TN6

B0 B1 B2 T B3 B4 B5 X B6 B7 B8 T B9

B10 B11X

TN7

B0 B1 B2 T B3 B4 B5 X B6 B7 B8 T B9

B10 B11X

B0 - B11 = Radio Blocks

T = Frame used for PTCCH

= not assigned Radio Block

X = Idle frame

= assigned Radio Block

Figure: Example: Assignment of radio ressource in fixed allocation mode


GPRS Chap13

Recommend Documents