Protocol Sequence - Packet Call (Single PDP)

This page lists the messages of a mobile originated packet call with one PDP context on a TD-SCDMA network. The UE is already attached to the PS domain and in idle mode when the data session starts. The call then needs three steps of setup. RRC gives the UE a signalling connection, a GMM service request makes that connection secure, and SM activates the PDP context with a radio bearer for the data. The messages are checked against 24.008 v20.0.0 and 25.331 v19.0.1.

The topics on this page are listed below.

Which messages make up an MO packet call ?

Let's look at the whole sequence first, and then split it by layer. Each line shows the direction of one message. "UE --> NW" is an uplink message, "UE <-- NW" is a downlink message, and a line in angle brackets is a state or a user action rather than a message.

(1) UE <--> NW : Registration (Combined or Non-Combined)

(2) UE <--> NW : < IDLE >

(3) UE : < Make a MO Packet Call >

(4) UE --> NW : RRC CONNECTION REQUEST

(5) UE <-- NW : RRC CONNECTION SETUP

(6) UE --> NW : RRC CONNECTION SETUP COMPLETE

(7) UE --> NW : GMM SERVICE REQUEST

(8) UE <-- NW : AUTHENTICATION AND CIPHERING REQUEST

(9) UE --> NW : AUTHENTICATION AND CIPHERING RESPONSE

(10) UE <-- NW : SECURITY MODE COMMAND

(11) UE --> NW : SECURITY MODE COMPLETE

(12) UE --> NW : ACTIVATE PDP CONTEXT REQUEST

(13) UE <-- NW : RADIO BEARER SETUP

(14) UE --> NW : RADIO BEARER SETUP COMPLETE

(15) UE <-- NW : ACTIVATE PDP CONTEXT ACCEPT

Steps 1 to 3 are the starting point. Step 1 is the registration, which runs as on the combined or the non-combined attach page. After that, the UE stays in idle mode until an application starts a data session in step 3.

The remaining twelve messages fall into three groups. Steps 4 to 6 set up the RRC connection. Steps 7 to 11 are the GMM service request, with authentication and security. Steps 12 to 15 activate the PDP context, and the radio bearer for the data is set up in the middle of them, in steps 13 and 14. The shape is the same as in the voice call sequence, with GMM in the place of MM and SM in the place of CC.

The packet call starts from idle : the UE has no RRC connection and no active PDP context when the session starts.
GMM secures the connection before SM : the UE sends ACTIVATE PDP CONTEXT REQUEST only after the security mode control of steps 10 and 11.
The data bearer comes before the accept : the RADIO BEARER SETUP arrives before ACTIVATE PDP CONTEXT ACCEPT, so the bearer is ready when the UE learns its PDP address.

Why does the UE send a SERVICE REQUEST first ?

The UE wants to send an SM message, but it is in PMM-IDLE mode and has no secure PS signalling connection. For this case, 24.008 requires the GMM service request procedure first. So the UE runs it to move to PMM-CONNECTED mode.

Steps 4 to 6 use the same RRC connection establishment as the attach pages. In TD-SCDMA, the UE first sends a SYNC_UL signature on the UpPCH and waits for the FPACH answer. It then sends the RRC CONNECTION REQUEST on the PRACH. The UL power control page shows the power used for this exchange. 25.331 offers an originating establishment cause for each traffic class, such as "originatingInteractiveCall" and "originatingBackgroundCall". The UE selects the cause from the request of its upper layers.

The SERVICE REQUEST in step 7 carries the service type "signalling", the value 000 in 24.008. The UE uses this value because it has SM signalling to send in PMM-IDLE mode. The other values, such as "data", apply when a PDP context already exists and only its radio access bearer must be re-established. The UE starts T3317 of 15 s. The SGSN then runs the GMM authentication and ciphering procedure in steps 8 and 9, and the RNC starts security for the PS domain in steps 10 and 11.

Note that the list has no SERVICE ACCEPT. For a SERVICE REQUEST sent in PMM-IDLE mode, the UE treats the completed security mode control as the successful end of the procedure. So at the SECURITY MODE COMPLETE in step 11, the UE stops T3317 and enters PMM-CONNECTED mode.

The service type follows the PDP state : with no active PDP context, the UE asks for "signalling". A UE with an active PDP context and no radio access bearer asks for "data" instead.
Security ends the service request : in PMM-IDLE mode, the SECURITY MODE COMPLETE completes the procedure. A SERVICE ACCEPT is not needed in this sequence.
Authentication is optional per request : the SGSN decides whether to run steps 8 and 9. A live log may skip them and continue directly with the SECURITY MODE COMMAND.

How does the PDP context get its radio bearer ?

Steps 12 to 15 are the SM part of the call. The UE asks the SGSN for a PDP context with a QoS and an address. The network must then build a radio bearer for that context before it confirms the context to the UE.

The ACTIVATE PDP CONTEXT REQUEST in step 12 has four mandatory information elements after the header. The Requested NSAPI identifies the context, and its value is between 5 and 15. The Requested LLC SAPI, the Requested QoS and the Requested PDP address follow. The Access point name and the Protocol configuration options are optional. When the PDP type is IP and the Requested PDP address carries no address, the UE asks for dynamic addressing. The UE starts T3380 of 30 s.

Next, the SGSN asks the RNC for a radio access bearer with the QoS of the context. The RNC sends the RADIO BEARER SETUP in step 13, and the UE answers with RADIO BEARER SETUP COMPLETE in step 14. After that, the SGSN sends ACTIVATE PDP CONTEXT ACCEPT in step 15, and the UE stops T3380. The accept carries the Negotiated LLC SAPI, the Negotiated QoS and the Radio priority as mandatory information elements. The PDP address is an optional information element, and it carries the address that the network allocated.

This page covers one PDP context. The UE can activate more contexts over the same RRC connection, and each one gets its own NSAPI and its own radio bearer. The two PDP and three PDP pages show those cases.

The NSAPI identifies the context : the UE picks a value from 5 to 15, and each further PDP context needs a different value.
The negotiated QoS can differ from the request : the network can return a lower QoS than the UE requested. So check the Negotiated QoS in step 15, not the Requested QoS in step 12.
The accept comes after the bearer : when step 15 arrives, the radio bearer from steps 13 and 14 is already in place, and the UE can send data at once.

Reference

24.008 Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 - v20.0.0, subclauses 4.7.13 Service request procedure, 9.5.1 and 9.5.2 ACTIVATE PDP CONTEXT REQUEST and ACCEPT, 10.5.5.20 Service type and 11.2 timers
25.331 Radio Resource Control RRC protocol specification - v19.0.1, subclauses 8.1.3 RRC connection establishment, 8.1.12 Security mode control and 10.3.3.11 Establishment cause