7 Specific Examples

23.2363GPPIntra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodesRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

This clause describes specific examples of Iu Flex. First, building blocks of Iu Flex are described in 7.1. These building blocks are then used in signalling flows starting from 7.2.

The changes to the signalling flows are indicated in italic.

7.1 Building blocks for signalling flows

7.1.1 RAN node selecting CN node in A interface mode

7.1.2 RAN node selecting CN node in Gb interface mode

7.1.3 RAN node selecting CN node in Iu interface mode

7.1.4 New CN node selecting old CN node

This building block describes how a new CN node selects the old CN node which was previously serving the MS. The new CN node has been allocated to serve the MS, and it may have to communicate with the old CN node e.g. in order to get IMSI of the MS or to get MM and PDP contexts of the MS.

7.1.5 Old CN node selecting new CN node

This building block describes how the old CN node selects a new CN node which starts to serve the MS. The old CN node has to select a new CN node e.g. when performing handover.

7.1.6 SGSN selecting MSC

7.2 Signalling flow for Attach (Iu interface mode)

At attach, the RNC selects an SGSN to serve the MS. The attach procedure is shown in the figure below.

Figure 4: Signalling flow for Attach (Iu interface mode)

1) The Attach Request (old P-TMSI, old RAI, old P-TMSI Signature) is carried in the Initial Direct Transfer message (RRC) from the MS to the RNC. The RNC selects an SGSN to serve the MS as described in clause 7.1.3 and relays the Attach Request to the SGSN in the Initial UE message (RANAP).

2) If the MS identifies itself with P‑TMSI and the SGSN has changed since detach, the new SGSN sends an Identification Request (P‑TMSI, old RAI, old P‑TMSI Signature) to the old SGSN to request the IMSI. The new SGSN selects the old SGSN as described in clause 7.1.4. The old SGSN responds with Identification Response (IMSI, Authentication Triplets (for GPRS) or Authentication Vectors (for UMTS)). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN also validates the old P‑TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN.

3) If the MS is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type = IMSI) to the MS. The MS responds with Identity Response (IMSI).

4) The authentication functions are defined in the clause "Security Function" of TS 23.060 [2]. If no MM context for the MS exists anywhere in the network, then authentication is mandatory. Ciphering procedures are described in clause "Security Function" of TS 23.060 [2]. If P‑TMSI allocation is going to be done and the network supports ciphering, the network shall set the ciphering mode.

5) The equipment checking functions are defined in the clause "Identity Check Procedures" of TS 23.060 [2]. Equipment checking is optional.

6) If the SGSN number has changed since the GPRS detach, or if it is the very first attach, then the SGSN informs the HLR:

a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI) to the HLR.

b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure.

c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that MS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts.

d) The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN.

e) The new SGSN validates the MS’s presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed to attach in the RA, the SGSN rejects the Attach Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If subscription checking fails for other reasons, the SGSN rejects the Attach Request with an appropriate cause and returns an Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all checks are successful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.

f) The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after the cancelling of old MM context and insertion of new MM context are finished. If the Update Location is rejected by the HLR, the SGSN rejects the Attach Request from the MS with an appropriate cause.

7) If Attach Type in step 1 indicated GPRS Attach while already IMSI attached, or combined GPRS / IMSI attached, then the VLR shall be updated if the Gs interface is installed. The VLR number is determined as described in 7.1.6. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HLR in step 6d). This operation marks the MS as GPRS-attached in the VLR.

a) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) message to the VLR. Location Update Type shall indicate IMSI attach if Attach Type indicated combined GPRS / IMSI attach. Otherwise, Location Update Type shall indicate normal location update. The VLR creates an association with the SGSN by storing SGSN Number.

b) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR) to the HLR.

c) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old VLR.

d) The old VLR acknowledges with Cancel Location Ack (IMSI).

e) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.

f) The VLR acknowledges with Insert Subscriber Data Ack (IMSI).

g) After finishing the inter-MSC location update procedures, the HLR responds with Update Location Ack (IMSI) to the new VLR.

h) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN. An Iu Flex aware VLR includes one of its (CS-)NRIs as part of VLR TMSI. The SGSN creates an association with the VLR by storing VLR number.

8) The SGSN selects Radio Priority SMS, and sends an Attach Accept (P‑TMSI, VLR TMSI, P‑TMSI Signature, Radio Priority SMS) message to the MS. P‑TMSI is included if the SGSN allocates a new P‑TMSI. An Iu Flex aware SGSN includes one of its (PS-)NRIs as part of P-TMSI.

9) If P‑TMSI or VLR TMSI was changed, the MS acknowledges the received TMSI(s) by returning an Attach Complete message to the SGSN.

10) If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-allocation by sending a TMSI Reallocation Complete message to the VLR.

7.3 Signalling flows for Service Request (Iu interface mode)

When performing service request, the signalling connection between the MS and the SGSN is re-established.

7.3.1 Service Request initiated by MS

The service request procedure initiated by the MS is shown in the figure below.

Figure 5: Signalling flows for Service Request initiated by MS (Iu interface mode)

1) The MS establishes an RRC connection, if none exists for CS traffic.

2) The MS sends a Service Request (P‑TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate one of the following: Data or Signalling. The Service Request is carried in the Initial Direct Transfer message (RRC) from the MS to the RNC. The RNC selects an SGSN to serve the MS as described in 7.1.3 and relays the Service Request to the SGSN in the Initial UE message (RANAP). At this point, the SGSN may perform the authentication procedure.

– If Service Type indicates Data, a signalling connection is established between the MS and the SGSN, and resources for active PDP context(s) are allocated, i.e., RAB establishment for the activated PDP context(s).

– If Service Type indicates Signalling, the signalling connection is established between the MS and the SGSN for sending upper-layer signalling messages, e.g., Activate PDP Context Request. The resources for active PDP context(s) are not allocated.

3) The SGSN shall perform the security functions if the MS in PMM-IDLE state initiated the service request.

4) If the network is in PMM-CONNECTED state and the Service Type indicates Data, the SGSN shall respond with a Service Accept message towards the MS, in case the service request can be accepted. In case Service Type indicates Data, the SGSN sends a Radio Access Bearer Assignment Request (NSAPIRAB ID(s), TEID(s), QoS Profile(s), SGSN IP Address(es)) message to re-establish radio access bearer for every activated PDP context.

5) The RNC indicates to the MS the new Radio Bearer Identity established and the corresponding RAB ID with the RRC radio bearer setup procedure.

6) SRNC responds with the Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), QoS Profile(s), RNC IP Address(es)) message. The GTP tunnel(s) are established on the Iu interface. If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided, e.g., "Requested Maximum Bit Rate not Available", the SGSN may send a new Radio Access Bearer Assignment Request message with different QoS profile(s). The number of re-attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent.

7) For each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification procedure to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP context.

8) The MS sends the uplink packet.

7.3.2 Service Request initiated by network

The service request procedure initiated by the network is shown in the figure below.

Figure 6: Signalling flows for Service Request initiated by network (Iu interface mode)

1) The SGSN receives a downlink PDP PDU for an MS in PMM‑IDLE state.

2) The SGSN sends a Paging message to the RNC. The RNC pages the MS by sending a Paging message to the MS. See clause "PS Paging Initiated by 3G‑SGSN without RRC Connection for CS" of TS 23.060 [2] for details.

3) The MS establishes an RRC connection if none exists for CS traffic.

4) The MS sends a Service Request (P‑TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies Paging Response. The Service Request is carried over the radio in an RRC Direct Transfer message. The RNC selects an SGSN to serve the MS as described in 7.1.3 and relays the Service Request to the SGSN in the Initial UE message (RANAP). At this point, the SGSN may perform the authentication procedure. The SGSN knows whether the downlink packet requires RAB establishment (e.g., downlink PDU) or not (e.g., Request PDP Context Activation or MT SMS).

5) The SGSN shall perform the security mode procedure.

6) If resources for the PDP contexts are re-established, the SGSN sends a Radio Access Bearer Assignment Request (RAB ID(s), TEID(s), QoS Profile(s), SGSN IP Address(es)) message to the RNC. The RNC sends a Radio Bearer Setup (RAB ID(s)) to the MS. The MS responds by returning a Radio Bearer Setup Complete message to the RNC. The RNC sends a Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), RNC IP Address(es)) message to the SGSN in order to indicate that GTP tunnels are established on the Iu interface and radio access bearers are established between the RNC and the MS. If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided, e.g., "Requested Maximum Bit Rate not Available", the SGSN may send a new Radio Access Bearer Assignment Request message with different QoS profile(s). The number of re-attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent.

8) The SGSN sends the downlink packet.

7.4 Signalling flow for Routing Area Update (Iu interface mode)

The routing area update procedure is shown in the figure below.

Figure 7: Signalling flow for Routing Area Update (Iu interface mode)

1) The RRC connection is established, if not already done. The Routeing Area Update Request (old P-TMSI, old RAI, old P-TMSI Signature) is carried in the Initial Direct Transfer message (RRC) from the MS to the RNC. The RNC selects an SGSN to serve the MS as described in 7.1.3 and relays the Routeing Area Update Request to the SGSN in the Initial UE message (RANAP).

2) If the RA update is an Inter-SGSN Routeing area update and if the MS was in PMM‑IDLE state, the new SGSN sends an SGSN Context Request message (old P‑TMSI, old RAI, old P‑TMSI Signature) to the old SGSN to get the MM and PDP contexts for the MS. The new SGSN selects the old SGSN as described in 7.1.4. The old SGSN validates the old P‑TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (IMSI, old RAI, MS Validated) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P‑TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN responds with SGSN Context Response (Cause, IMSI, MM Context, PDP contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN starts a timer. The new SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context Response only when it has previously received an MS Network Capability in the Routeing Area Request.

a) If the MS is PMM‑CONNECTED in the old 3G‑SGSN, the old SGSN shall send an SRNS Context Request (IMSI) message to the old SRNS to retrieve the sequence numbers for the PDP context for inclusion in the SGSN Context Response message from the SRNS. Upon reception of this message, the SRNS buffers and stops sending downlink PDUs to the MS and returns an SRNS Context Response (IMSI, GTP‑SNDs, GTP‑SNUs, PDCP‑SNUs) message. The SRNS shall include for each PDP context the next in-sequence GTP sequence number to be sent to the MS and the GTP sequence number of the next uplink PDU to be tunnelled to the GGSN. For each active PDP context using acknowledged mode, the SRNS also includes the uplink PDCP sequence number (PDCP‑SNU). PDCP‑SNU shall be the next in-sequence PDCP sequence number expected from the MS (per each active radio bearer).

3) Security functions may be executed. These procedures are defined in clause "Security Function" of TS 23.060 [2]. If the security functions do not authenticate the MS correctly, the routeing area update shall be rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN Context Request was never received.

4) If the RA update is an Inter-SGSN Routeing area update, the new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area update procedure back to the old SGSN before completing the ongoing routeing area update procedure.

5) If the RA update is an Inter-SGSN RA Update and if the MS was in PMM‑IDLE state, the new SGSN sends Update PDP Context Request (new SGSN Address, QoS Negotiated, Tunnel Endpoint Identifier) to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (Tunnel Endpoint Identifier). Note: If the RA update is an Inter-SGSN routeing area update initiated by an MS in PMM‑CONNECTED state, the Update PDP Context Request message is sent as described in clause "Serving RNS Relocation Procedures" of TS 23.060 [2].

6) If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI) to the HLR.

7) If the RA update is an inter-SGSN RA Update, the HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure. If the timer described in step 2 is not running, the old SGSN removes the MM context. Otherwise, the contexts are removed only when the timer expires. It also ensures that the MM context is kept in the old SGSN in case the MS initiates another inter SGSN routeing area update before completing the ongoing routeing area update to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI).

a) If the MS is PMM‑CONNECTED in the old 3G‑SGSN, the old 3G‑SGSN sends an Iu Release Command message to the old SRNC. The SRNC responds with an Iu Release Complete message.

8) If the RA update is an inter-SGSN RA Update, the HLR sends Insert Subscriber Data (IMSI, subscription data) to the new SGSN. The new SGSN validates the MS’s presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If all checks are successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.

9) If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.

10) If Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the routeing area update, the association has to be established. The VLR number is determined as described in 7.1.6. The new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1 indicated combined RA / LA update with ISI attach requested. Otherwise, Location Update Type shall indicate normal location update. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HLR in step 8). The VLR creates or updates the association with the SGSN by storing SGSN Number.

11) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data in the new VLR (this signalling is not modified from existing GSM signalling and is included here for illustrative purposes):

a) The new VLR sends an Update Location (new VLR) to the HLR.

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.

c) The old VLR acknowledges with Cancel Location Ack (IMSI).

d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).

f) The HLR responds with Update Location Ack (IMSI) to the new VLR.

12) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN. VLR TMSI is optional if the VLR has not changed. An Iu Flex aware VLR includes one of its (CS-)NRIs as part of VLR TMSI. The SGSN creates an association with the VLR by storing VLR number.

13) The new SGSN validates the MS’s presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the SGSN, or if subscription checking fails, the SGSN rejects the routeing area update with an appropriate cause. If all checks are successful, the new SGSN establishes MM context for the MS. The new SGSN responds to the MS with Routeing Area Update Accept (P‑TMSI, VLR TMSI, P‑TMSI Signature). An Iu Flex aware SGSN includes one of its (PS-)NRIs as part of P-TMSI.

14) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the SGSN.

15) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR TMSI.

7.5 IMSI attach procedure / Location area update with IMSI

This signalling flow shows the basic IMSI attach or location update procedure when a UMTS UE registers to a pool-area by mobile identity type IMSI.

Figure 8: IMSI attach procedure / Location area update with IMSI

1) UE requests the setup of the RRC connection and sends the Initial_DT including the Intra Domain NAS Node Selector (IDNNS). The IDNNS indicates that the routing parameter is derived from IMSI.

2) The RNC selects the MSC as described in 7.1.3. The Initial-UE message is generated on RANAP and sent via Iu-CS to the selected MSC/VLR.

3) The optional security functions can be executed.

4) Since the UE wasn’t registered in the MSC before the Map Update-location procedure to HLR is invoked by the MSC:

a) The update-location is sent to HLR;

b) In case the UE was registered in another VLR the HLR sends cancel location procedure to old VLR;

c) The old VLR acknowledges with Cancel location Ack;

d) The HLR sends insert-subscriber data to the new VLR;

e) The new VLR acknowledges with insert-subscriber data Ack;

f) After finishing the location update procedure the HLR responds with Update-location to the new VLR.

5) The MSC/VLR assigns a new TMSI to the UE and sends this TMSI value in the location-update accept to the UE. The TMSI contains the NRI of the VLR. The location update accept is carried in the NAS-PDU of the RANAP direct-transfer over Iu interface.

6) The RNC transparently forwards the NAS-PDU to the UE in the RRC downlink-DT message.

7) In the UE the new TMSI (including the NRI) and the LA are stored on SIM and the TMSI-reallocation complete is generated. This NAS message is returned to CN in the Uplink-DT via RRC. The mobile shall use this new TMSI next time it performs a mobile originating procedure.

8) The RNC forwards the NAS-PDU transparently to the MSC/VLR in the NAS-PDU of a Direct-transfer on Iu interface. If the TMSI-reallocation complete is received in the MSC/VLR the TMSI is considered as valid for the UE. From then on the UE will be addressed using this TMSI value.

Annex A (informative):
Network configuration examples

Editor’s note: This annex contains the examples for network configurations that have been discussed during the drafting meetings.