This page shows the signalling of a TD-SCDMA packet call that opens two PDP contexts on one RRC connection. TD-SCDMA is UTRA TDD at 1.28 Mcps. So its RRC messages are the 25.331 messages that WCDMA also uses, and its NAS messages come from 24.008. The first PDP context needs the full setup: RRC connection, GMM service request, authentication and security. The second context reuses all of that. So it costs only a PDP context request, one radio bearer update and the two replies. Let's look at the whole list first, and then at each half of it.

• What does the two PDP call sequence look like ?
• How is the first PDP context set up ?
• What changes when the second PDP context is added ?
• Reference

What does the two PDP call sequence look like ?

The list below is the message order that a test setup shows for this call. Steps 1 to 15 are an ordinary packet call with one PDP context. Steps 16 to 20 add the second context while the UE is still connected. Watch the arrows while you read it. Every NAS request comes from the UE, and every RRC setup message comes from the network.

(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 (1st PDP)

(13) UE <-- NW : RADIO BEARER SETUP (Single Data Flow)

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

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

(16) UE : < Make another Packet Call triggering 2nd PDP >

(17) UE --> NW : ACTIVATE PDP CONTEXT REQUEST (2nd PDP)

(18) UE <-- NW : RADIO BEARER SETUP (Two Data Flow)

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

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

The steps belong to four different procedures, and each procedure is owned by a different part of the specifications. The table below groups them, so you can see which layer to check when one step fails.

• The NAS and RRC messages alternate : the network answers each ACTIVATE PDP CONTEXT REQUEST first with an RRC RADIO BEARER SETUP. The NAS ACCEPT comes after it.
• Only the first context pays for the connection : steps 4 to 11 appear once, because the RRC connection and the PS security stay in place for the second context.
• The direction of each message is fixed by its procedure : a PDP context request and a COMPLETE message always go from the UE to the network in this call.

How is the first PDP context set up ?

The UE starts from IDLE with no signalling connection to the PS domain. So it has to build an RRC connection and a secure PS signalling connection before it sends any session management message. Steps 4 to 11 do exactly that, and steps 12 to 15 then create the context itself.

Steps 4 to 6 are the RRC connection establishment. The UE sends RRC CONNECTION REQUEST on the CCCH, and the network answers with RRC CONNECTION SETUP. The UE then confirms with RRC CONNECTION SETUP COMPLETE on the new DCCH. The setup message decides whether the UE starts in CELL_DCH or CELL_FACH.

Step 7 opens the PS signalling connection. In 24.008, a UE in PMM-IDLE with a pending SM message sends SERVICE REQUEST with the service type "signalling". The UE has no active PDP context yet, so it does not ask for "data". The network then runs the GMM authentication and ciphering procedure in steps 8 and 9. This is the PS domain version of authentication, so the message names differ from the MM AUTHENTICATION REQUEST of a voice call.

Steps 10 and 11 are RRC security mode control. The RNC starts integrity protection and ciphering with the keys that the authentication produced. From step 11 on, every signalling message on the DCCH is integrity protected.

Step 12 is the actual request. The ACTIVATE PDP CONTEXT REQUEST carries the NSAPI that the UE picked, the PDP type and the requested QoS, and usually an APN. The network then sets up the radio side first. It sends RADIO BEARER SETUP in step 13, and the UE answers with RADIO BEARER SETUP COMPLETE in step 14. Only after that does the ACTIVATE PDP CONTEXT ACCEPT arrive in step 15. So the ACCEPT reaches a UE that can already carry user data. The test setup labels this bearer "Single Data Flow", because one PS RAB is now mapped onto the radio.

• Service type "signalling" is the normal case here : the UE has SM signalling to send and no user plane to resume, so 24.008 subclause 4.7.13 selects "signalling".
• Security is set once per CN domain : steps 8 to 11 protect the PS signalling connection, and the second PDP context reuses it.
• RADIO BEARER SETUP comes before the ACCEPT : if the radio bearer cannot be set up, no ACCEPT follows. The UE then relies on its SM timer T3380 to repeat or abandon the request.
• The NSAPI identifies the context from now on : 24.008 allows NSAPI 5 to 15, so one UE can hold at most 11 PDP contexts. The network or the UE can set a lower limit.

What changes when the second PDP context is added ?

When the second packet call starts in step 16, the UE is already in connected mode. The RRC connection, the PS signalling connection and the security context are all still there. So the UE goes straight to session management, and steps 4 to 11 are not repeated.

In step 17 the UE sends a new ACTIVATE PDP CONTEXT REQUEST with a new NSAPI and a new transaction identifier. This is a primary PDP context request, which is what a second APN needs. If the UE wants the same PDP address and APN with a different QoS, 24.008 uses ACTIVATE SECONDARY PDP CONTEXT REQUEST instead. The list on this page shows the primary form.

In step 18 the network sends another RADIO BEARER SETUP. This message sets up only the new RAB, and the first RAB stays as it is. But the transport channel and TFCS part of the message has to fit both data flows, because they now share the dedicated channels. That is why the test setup labels it "Two Data Flow". The UE answers with RADIO BEARER SETUP COMPLETE in step 19, and the network closes the procedure with ACTIVATE PDP CONTEXT ACCEPT in step 20.

When you compare a real log with this list, check the NSAPI in both ACCEPT messages first. The two values must differ. Next, check the transport channel part of the second RADIO BEARER SETUP. It has to keep a transport channel for the first RAB, or the first data flow stops when the second one starts.

• The second context needs no new connection : it goes straight from the user action in step 16 to the PDP context request in step 17.
• Primary and secondary contexts use different messages : a new APN needs ACTIVATE PDP CONTEXT REQUEST, and the same APN with other QoS needs ACTIVATE SECONDARY PDP CONTEXT REQUEST.
• The RRC side reconfigures the whole bearer set : the second RADIO BEARER SETUP adds one RAB, but its TFCS has to cover both data flows.
• The same pattern scales to more contexts : the Three PDP page repeats steps 16 to 20 once more.

Reference

• 24.008 v20.0.0 : Mobile radio interface Layer 3 specification; Core network protocols; Stage 3. Subclauses 4.7.7, 4.7.13, 6.1.3 and 10.5.6.2
• 25.331 v19.0.1 : Radio Resource Control; Protocol specification. Subclauses 8.1.3, 8.1.12 and 8.2.2
• Protocol Sequence - Packet Call : the single PDP version of this call