This page extends the two PDP packet call by one more PDP context, so one TD-SCDMA RRC connection ends up carrying three PS RABs. TD-SCDMA is UTRA TDD at 1.28 Mcps. So the RRC messages come from 25.331, and the GMM and SM messages come from 24.008. The interesting part is not the third context itself. It is what stays the same each time a context is added, and what finally limits how many contexts a UE can hold.

• What does the three PDP call sequence look like ?
• Why does each extra context need only five steps ?
• What limits the number of PDP contexts ?
• Reference

What does the three PDP call sequence look like ?

The list below is the message order that a test setup shows for this call. It has three blocks. Steps 1 to 15 bring up the first context from IDLE, steps 16 to 20 add the second, and steps 21 to 25 add the third. In every block, the PDP context request and the COMPLETE message go from the UE to 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

(21) UE : < Make another Packet Call triggering 3rd PDP >

(22) UE --> NW : ACTIVATE PDP CONTEXT REQUEST (3rd PDP)

(23) UE <-- NW : RADIO BEARER SETUP (Three Data Flow)

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

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

The table below lines up the three blocks side by side. Read it row by row, and you can see that only the first context carries the connection setup.

• Each extra context is one fixed block : a user action, a PDP context request, a RADIO BEARER SETUP, its COMPLETE and the ACCEPT.
• The Data Flow label counts the PS RABs : the test setup names each RADIO BEARER SETUP by the number of data flows the UE carries after it.
• The UE never returns to IDLE between blocks : if a log shows a new RRC CONNECTION REQUEST before step 22, the connection was released in between.

Why does each extra context need only five steps ?

The second and the third contexts start from a UE that is already connected. The RRC connection, the PS signalling connection and the security context from steps 4 to 11 are still active. So there is nothing to set up except the session and its radio bearer.

Each new ACTIVATE PDP CONTEXT REQUEST picks an NSAPI that no other context uses. It also uses a new transaction identifier, so the ACCEPT can be matched to its request. In this list each request is a primary PDP context request, which is what a new APN needs. A context with the same APN and PDP address but a different QoS would use ACTIVATE SECONDARY PDP CONTEXT REQUEST instead.

On the radio side, the network adds one RAB per context with RADIO BEARER SETUP. The earlier RABs stay configured. But the transport channel and TFCS part of each new message has to fit all the data flows at once. So the third RADIO BEARER SETUP usually carries the largest configuration of the call. In a TD-SCDMA cell this configuration also has to fit the timeslots and codes that the Node B can give the UE.

When you check a log of this call, compare the three ACCEPT messages first. Their NSAPI values must all differ. Then check that the first two data flows still pass traffic after step 24. If they stop, look first at the transport channel part of the last RADIO BEARER SETUP, not at the NAS messages.

• Connection setup happens once per call : steps 4 to 11 are not repeated for the second and the third contexts.
• NSAPI and transaction identifier are new for every context : the NSAPI names the context, and the transaction identifier ties the ACCEPT to its request.
• Primary and secondary contexts use different messages : this list uses the primary form for all three contexts.
• The last RADIO BEARER SETUP carries the largest configuration : its TFCS has to serve all three data flows together.

What limits the number of PDP contexts ?

If you add contexts one by one, the network rejects one of them sooner or later. So it helps to know where the limits are, and which message shows each of them.

24.008 subclause 6.1.3.0 names three limits, and the lowest one applies. The first is the protocol. Only NSAPI 5 to 15 are usable, so a UE can hold at most 11 PDP contexts. The second is the PLMN, which can set its own maximum. The third is the UE implementation, which can support fewer contexts than the protocol allows.

The network shows its limit by rejecting the request with SM cause #65, "maximum number of PDP contexts reached". When the UE receives this cause, it takes the number of contexts it has now as the PLMN maximum. It then keeps that value for the PLMN until it is switched off or the USIM is removed. So one reject in a test run can affect later runs on the same PLMN. Power cycle the UE before you repeat the test.

The radio side has its own limits too. 25.331 allows up to 16 RABs in one setup list (maxRABsetup) and up to 32 radio bearers (maxRB). In practice the TFCS and the physical resources of the cell usually run out before these numbers. With three PS RABs, as on this page, the call stays well inside all of these limits.

• The protocol ceiling is 11 contexts : NSAPI values 5 to 15 are the only ones 24.008 allows.
• SM cause #65 reports the network limit : the UE stores the current count as the PLMN maximum until power off or USIM removal.
• The radio configuration is the practical limit : each extra RAB enlarges the TFCS that the cell has to support.

Reference

• 24.008 v20.0.0 : Mobile radio interface Layer 3 specification; Core network protocols; Stage 3. Subclauses 6.1.3.0, 6.1.3.1, 6.1.3.1.3.3 and 10.5.6.2
• 25.331 v19.0.1 : Radio Resource Control; Protocol specification. Subclause 8.2.2 and the constant definitions in 11.4
• Protocol Sequence - Packet Call - Two PDP : the step by step explanation of the first two contexts