6.6 PS Domain Mobility Management Procedures


6.6.1  MM Function Overview


The major role of Mobility Management (MM) is to track the current location of a subscriber in the home PLMN or other PLMNs. For instance, if a subscriber wants to log in to the GPRS network, the Attach procedure (which is a basic procedure of MM) must be executed first, so as to register his related information in the core network. The MM, SM (Session Management) and SMS (Short Message Services) together form the connection layer of the 3GPP protocols. Among them, MM is located above the RANAP layer to provide signaling transport for SM and SMS in the UMTS. The other functions of MM also include the subscriber detachment, security, routing area update and location update procedures.

1. Terminologies

l   GMM/PMM
GMM: GPRS Mobility Management (different from CMM Circuit Mobility Management)
PMM: Packet Mobility Management
Here we can simply regard the GMM as mobility management in the GSM system and the PMM as mobility management in the UMTS system. This document focuses on the PS domain MM features of the UMTS system.
l   RANAP
RANAP (Radio Access Network Application Part) encapsulates and transports higher-layer signaling, processes the signaling between the 3G-SGSN and the UTRAN, and manages the GTP connections at the Iu interface.
l   MM CONTEXT
The MM Context includes subscriber data and the authentication set.

6.6.2  Mobility Management State


The PMM states in the UMTS include PMM-DETACHED, PMM-IDLE and PMM-CONNECTED.
l   PMM DETACHED State
In this state, the MS does not communicate with the 3G-SGSN and there is no valid location or routing information. The MS is unreachable and the MS location is unknown.
l   PMM IDLE State
In this state, the MS location is known but the MS is idle.
l   PMM CONNECTED State
In this state, the MS location is known and the PS signaling connection has been established.
The specific state transitions of PMM are depicted in the following figure, where we can see that the SM may be in the active or inactive state when the PMM is in the connected or idle state, that is, the MM state is only related to the MM state of GPRS and it has nothing to do with the PDP Context state or quantity.
Note: In the case of errors, the MS state may be not synchronous with the network state and their synchronization can be achieved through the routing area update procedure.

6.6.3  Association Between SGSN and MSC/VLR


The Gs interface is specified between the SGSN and MSC/VLR in the UMTS. Their association is established through the following procedures:
l   Combined GPRS/IMSI Attach/Detach procedure
l   IMSI-attached GPRS Attach procedure
l   GPRS-attached IMSI Attach procedure (combined RA update)
After the Gs interface association has been established, the system can implement the following procedures now:
1)      CS Paging:
The MSC/VLR can send the CS paging information via the SGSN to a subscriber in the combined attachment procedure.
2)      Non-GPRS Alert
The MSC/VLR will request the SGSN to notify the activity information of the MS to itself and it will set the NGAF (Non-GPRS Alert Flag) so that the SGSN MM will notify the subscriber activity once detected to the MSC/VLR and the NGAF will be cleared then.
3)      MS Information Procedure
When the MSC/VLR needs the subscriber identity and location information, it may obtain such information via the Gs interface from the local SGSN or it may send a request for such information via the SGSN to get the needed information.
4)      MM Information Procedure        
The MSC/VLR may send the network information via the SGSN to a subscriber and the SGSN will pass on the information.

6.6.4  Combined GPRS/IMSI Attach Procedure


Note: The C1 as indicated in the above figure is a CAMEL point where intelligent services can be triggered or performed. In the subsequent flow charts such points as C1, C2 and C3 are all CAMEL points.
1)      The MS sends an Attach Request message to initiate the Attach procedure. The Attach Request message contains such parameters as IMSI or P-TMSI and old RAI, Attach Type, old P-TMSI Signature and Follow On Request. If the subscriber has no legal P-TMSI, the message will carry an IMSI; or if the subscriber has a legal P-TMSI, it should then carry the P-TMSI and the matched RAI or even the P-TMSI signature, if any. The Attach Type parameter indicates what kind of Attach procedure is requested by the MS: GPRS Attach, Combined Attach or IMSI-attached GPRS Attach. The SGNS may decide whether to release the packet service signaling connection of the MS upon end of the Attach procedure according to the Follow On Request indication.
2)      If the MS uses P-TMSI for attachment and the SGSN has been changed since the last attachment, the new SGSN should send an Identification Request to the old SGSN and this request should carry the P-TMSI of the MS, the corresponding RAI and the old P-TMSI signature, if any. The old SGSN should then respond with the Identification Response message that carries the subscriber’s IMSI and authentication set. If the MS is unknown to the old SGSN, the old SGSN shall return a response message with the related cause value; and if the P-TMSI of the MS does not match the signature, the old SGSN should return another response message along with the corresponding cause value.
3)      If the MS is unknown to the old SGSN, the new SGSN should initiate an Identity Request to the MS with the identity type indicating IMSI and the MS should then report its own IMSI to the SGSN.
4)      If the MM Context of the MS does not exist in the network, the authentication procedure is then needed. If P-TMSI reallocation is needed and the network supports ciphering, the ciphering mode should also be set in this step.
5)      The IMEI check as defined in the identity check procedure takes place. This function is currently not implemented.
6)      If the SGSN number has changed since the last detachment or if it is the first time of the MS to attach to the network, the SGSN should notify the HLR of such. The specific procedure is given as follows:
The SGSN sends an Update Location message (with the SGSN number, SGSN address and IMSI) to the HLR; the HLR sends the Cancel Location message (with the IMSI and the Cancel Type) to the old SGSN and sets the Cancel Type to Update Procedure; the old SGSN acknowledges the Cancel Location received from the HLR with the Cancel Location Ack message (with the IMSI); the HLR sends the Insert Subscriber Data message (with the IMSI and GPRS subscriber data) to the new SGSN; the new SGSN acknowledges the presence of the MS in the new routing area, and the SGSN should reject the attachment request of the MS with the appropriate cause value and it may return the Insert Subscriber Data Ack message to the HLR if the subscriber data do not allow the MS to attach to this routing area. If the subscriber data check fails due to other causes, the SGSN should reject the attachment request of the MS with the appropriate cause value and should also return the Insert Subscriber Data Ack message to the HLR (together with the IMSI and the cause value). If all the subscriber data have passed the check, the SGSN will construct an MM Context for the subscriber and at the same time return the Insert Subscriber Data Ack message (together with the IMSI in it) to the HLR. After deleting the old MM Context and inserting the new one, the HLR sends the Update Location Ack message to the SGSN to acknowledge the Update Location message from the SGSN. If the Update Location request is rejected by the HLR, the SGSN will carry the appropriate cause value to reject the attachment request of the MS.
7)      If the Attach Type discussed in Step 1 indicates the IMSI-attached GPRS Attach or Combined Attach, the VLR should be updated, provided that the Gs interface has been configured. The VLR number can be exported from the routing area information, that is, the Location Update procedure may start after the first Insert Subscriber Data message is received from the HLR. As a result, the subscriber will be flagged as GPRS Attached in the VLR.
8)      The SGSN selects the Radio Priority SMS and sends the Attach Accept message (with the P-TMSI, VLR number, TMSI, P-TMSI signature and Radio Priority SMS) to the MS. If another P-TMSI is reallocated, it should also be carried in this message.
9)      If the P-TMSI or TMSI has changed, the MS should send an Attach Complete message to the SGSN to acknowledge the new TMSI.
10)    If the TMSI has changed, the SGSN will send the TMSI Reallocation Complete message to the VLR to acknowledge the reallocated TMSI.
If the attachment request cannot be accepted, the SGSN should return the Attach Reject message (together with the IMSI and the Cause) to the MS.

6.6.5  Detach Procedures


The Detach procedure may be MS-initiated, SGSN-initiated and HLR-initiated. This section only describes the first two detachment procedures.

1. MS-initiated detachment

1)      The MS sends the Detach Request message (with Detach Type, P-TMSI, P-TMSI Signature and Switch Off) to the SGSN to initiate the detachment procedure. The Detach Type parameter indicates what kind of detachment procedure is to be performed: GPRS Detach, IMSI Detach or Combined Detach. The Switch Off parameter indicates whether the Attach procedure is triggered by the MS switch-off. The Detach Request message carries the P-TMSI and P-TMSI signature (to check the legality of the detachment message) of the MS. If the signature of the MS is illegal or not carried, the SGSN should initiate the authentication procedure.
2)      In the case of GPRS Detach, the deactivation of the active PDP Context that exists in the GGSN and belongs to the subscriber is implemented when the SGSN sends the Delete PDP Context Request message (with the TEID) to the GGSN. The GGSN should acknowledge it with the Delete PDP Context Response message.
3)      In the case of IMSI Detach, the SGSN should send the IMSI Detach Indication message to the VLR.
4)      If the subscriber needs to keep IMSI-attached while GPRS-detached, the SGSN should send the GPRS Detach Indication message to the VLR. The VLR removes its association with the SGSN and no longer initiates the Paging or Location Update procedure via the SGSN.
5)      If the Detach procedure is initiated due to other reasons than MS switch-off, the SGSN should return the Detach Accept message to the MS.
6)      If the MS initiates the GPRS Detach procedure, the SGSN will release the PS domain signaling connection.

2. SGSN-initiated detachment

1)      The SGSN notifies via the Detach Request message (with the Detach Type parameter) that the MS has been detached. The Detach Type parameter indicates whether the MS requests for re-attachment and re-activation of the original active PDP Context before the detachment procedure. If yes, the Attach procedure will be initiated upon completion of the Detach procedure.
2)      The SGSN notifies the GGSN of the Delete PDP Context Request message (with the TEID carried), so as to request the GGSN to deactivate the active PDP Context of the MS. The GGSN should acknowledge it with the Delete PDP Context Response message.
3)      In the case of combined attachment, the SGSN should send the GPRS Detach Indication message (with the MS IMSI) to notify the VLR of such. The VLR removes its association with the SGSN and no longer conducts paging and location updating via the SGSN.
4)      The MS may, upon receipt of the Detach Request from the SGSN, send the Detach Accept message at any time to the SGSN.
5)      Upon receipt of the Detach Accept message from the MS, the SGSN will release the PS signaling connection if the Detach Type does not indicate the reattachment request of the MS.

6.6.6  Security Procedure (Authentication & Ciphering)


1)      If the SGSN does not contain any old UMTS authentication quintuple, it will send a Send Authentication Info message (with IMSI). Upon receipt of this message, the HLR/AUC shall respond with the Send Authentication Info Ack message that includes the sequentially arranged quintuples. Each quintuple contains such information as RAND, XRES, AUTN, CK and IK. For the generation of such a quintuple, refer to 3G TS 33.102.
2)      During the authentication of the UMTS subscriber, the SGSN will select the next quintuple and carry the RAND and AUTN parameters of this quintuple in the Authentication and Ciphering Request message before sending the message to the MS. The SGSN will also select a CKSN and carries it in this message.
3)      Upon receipt of this message, the MS will have its USIM card authenticate the AUTN. If the AUTN is accepted, the MS will calculate the signed RES of the RAND according to the 3G TS 33.102 protocol. If the USIM card determines that the authentication succeeds, the MS will return the Authentication and Ciphering Response message (RES) to the SGSN. Meanwhile, the USIM card of the MS will also calculate the CK and IK. These keys will be stored together with the CKSN until the CKSN is updated at the next authentication.
If the USIM card determines that the authentication fails (e.g. authentication synchronization error), the MS will return the Authentication and Ciphering Failure message to the SGSN.

6.6.7  Location Management (Routing Area Update)


1)      The RRC connection must be established first if there is no existing RRC connection. The MS sends the Routing Area Update Request message (with such parameters as P-TMSI, Old RAI, Old P-TMSI Signature, Routing Area Update Type and Follow On Request) to the new SGSN. If the MS has signaling or data to be uploaded, the Follow On Request should be set. As an implementation option, the SGSN may decide whether to release the Iu connection upon end of the routing area update procedure according to the Follow On Request flag. The Routing Area Update Type parameter should indicate the following:
Routing area update, provided that the procedure is caused by routing area changes;
Periodic routing area update, provided that the procedure is caused by expiry of the periodic routing area update timer;
Combined routing area update, provided that the MS is IMSI attached and the location area update needs to be operated in the network operation mode I;
Combined routing area update with IMSI attach, provided that the MS wants the IMSI Attach procedure to take place in the network operation mode I;
The Serving RNC (SRNC) should add the RAI (including the routing area code and the location area code) of the subscriber location to the front of the Routing Area Update Request message before forwarding it to the SGSN.
2)      In the case of inter-SGSN routing area update and provided that the MS is in the PMM-IDLE state, the new SGSN will send the SGSN Context Request message (with the old P-TMSI, old RAI and old P-TMSI signature of the MS) to the old SGSN, so as to get the MM Context and the PDP Context of the MS. The old SGSN shall check the P-TMSI and signature of the MS and turn the appropriate cause value in the case of mismatch. In that case, the new SGSN will initiate the security procedure. If the MS passes authentication of the security procedure, the new SGSN should send the SGSN Context Request message (with the IMSI, old RAI and the MS authenticated flag) to the old SGSN. The MS authenticated flag indicates that the new SGSN has authenticated the MS. If the signature of the MS is legal or the new SGSN has successfully authenticated the MS, the old SGSN will return the SGSN Context Response message (with such parameters as Cause, IMSI, MM Context and PDP Context). If the MS is unknown to the old SGSN, the old SGSN should return the appropriate cause value and will start the timer.
3)      The security procedure may take place here. If the authentication fails, the routing area update request will be rejected and the new SGSN should send the Reject Indication to the old SGSN. The old SGSN should continue as if it had never received the SGSN Context Request message.
4)      In the case of inter-SGSN routing area update, the new SGSN should send the SGSN Context Ack message to the old SGSN. The old SGSN marks the MSC/VLR association and the information in the GGSN and HLR as illegal in its SGSN Context. If the MS initiates the routing area update to the old SGSN again before the ongoing routing area update procedure is complete, the update of MSC/VLR, GGSN and HLR will be triggered.
5)      In the case of inter-SGSN routing area update and provided that the MS is in the PMM-IDLE state, the new SGSN shall send the Modify PDP Context Request message (with the new SGSN address and the negotiated QoS and TEID information) to the relevant GGSN. The GGSN shall update its PDP Context and return the Modify PDP Context Response message (with TEID) to the SGSN.
6)      In the case of inter-SGSN routing area update, the SGSN shall send the Update Location message (with the SGSN number, SGSN address and IMSI) to the HLR, so as to notify the HLR of the SGSN change.
7)      In the case of inter-SGSN routing area update, the HLR shall send the Cancel Location message (with the IMSI and the Cancel Type parameters) to the old SGSN and the Cancel Type will be set to “Update Procedure”. The old SGSN shall return the Cancel Location Ack message (with the IMSI) to the HLR for acknowledgement.
8)      In the case of inter-SGSN routing area update, the HLR will send the Insert Subscriber Data message (with the IMSI and GPRS subscriber data) to the new SGSN. The new SGSN acknowledges the presence of the MS in the new routing area, and it should reject the attachment request of the MS with the appropriate cause value and may return the Insert Subscriber Data Ack message to the HLR if the subscriber data do not allow the MS to attach to this routing area. If the subscriber data check fails due to other causes, the SGSN should reject the attachment request of the MS with the appropriate cause value and should also return the Insert Subscriber Data Ack message to the HLR (together with the IMSI and the cause value). If all the subscriber data have passed the check, the SGSN will construct an MM Context for the subscriber and at the same time return the Insert Subscriber Data Ack message (together with the IMSI in it) to the HLR.
9)      In the case of inter-SGSN routing area update, the HLR will, after deleting the old MM Context and inserting the new one, send the Update Location Ack message to the SGSN to acknowledge the Update Location message from the SGSN.
10)    If the Routing Area Update Type indicates the Combined Routing Area Update with IMSI Attach or if the location area changes, the association between the SGSN and the VLR must be established. The new SGSN sends the Location Update Request message (with the new RAI, IMSI, SGSN number and Routing Area Update Type) to the VLR. If the Routing Area Update Type indicates the Combined Routing Area Update with IMSI Attach, the Location Area Update Type should indicate the IMSI Attach. Otherwise, it should indicate the normal location area update. The VLR number is obtained after the SGSN is queried with the RAI. At Step 8 described above, that is, upon receipt of the first Insert Subscriber Data message from the HLR, the SGSN may start the Location Update procedure now. The VLR creates or updates its association with the SGSN by storing the SGSN number.
11)    If the subscriber data in the VLR are marked as unacknowledged by the HLR, the new VLR will notify this to the HLR. And the HLR will delete the old VLR data and insert the subscriber data to the new VLR.
12)    The new VLR allocates a new TMSI and returns the Location Update Accept (with the VLR number and TMSI) to the SGSN. If the VLR does not change, the TMSI allocation here is optional.
13)    The new SGSN acknowledges the presence of the MS in the new routing area. If the subscriber data do not allow the MS to attach to this routing area or the subscriber data check fails, the SGSN should reject the attachment request of the MS with the appropriate cause value. If all the subscriber data have passed the check, the SGSN shall construct an MM Context for the MS. The new SGSN will return the Routing Area Update Accept message (with the P-TMSI, VLRTMSI and P-TMSI signature) to the MS.
14)    The MS sends the Attach Complete message to the SGSN to acknowledge the new TMSI.
15)    If the TMSI has changed, the SGSN will send the TMSI Reallocation Complete message to the VLR to acknowledge the reallocated TMSI.
If the attachment request cannot be accepted, the SGSN should return the Attach Reject message (together with the IMSI and the Cause) to the MS.
Note: Steps 11, 12 and 15 will not take place unless Step 10 takes place.

6.6.8  Service Request


1. MS-initiated service request

1)      The MS establishes the RRC connection first if there is no existing CS channel.
2)      The MS sends the Service Request message (with P-TMSI, PAI, CKSN and Service Type) to the SGSN. The Service Type parameter defines the required service. It is either data or signaling. At this time, the SGSN may initiate an authentication procedure.
If the Service Type parameter indicates data, the signaling connection between the MS and the SGSN will be established and resources will be reserved simultaneously for the active PDP Context.
If the Service Type parameter indicates signaling, the signaling connection for transmitting upper-layer signaling between the MS and the SGSN will be established.
3)      If the MS initiates a service request in the PMM-IDLE state, the SGSN will initiate the security procedure.
4)      If the network is in the PMM-CONNECTED state and the Service Type indicates data, the SGSN will return a Service Accept message to the MS to accept the service request; if the Service Type indicates data, the SGSN will send a Radio Access Bearer Assignment Request message that carries NSAPIRAB ID(s), TEID(s), QoS Profile(s) and SGSN IP Address(es) to re-establish the RAB to each active PDP Context.
5)      The RNC indicates to the MS that the new RAB has been established (together with the RAB ID).
6)      The SRNC sends a Radio Access Bearer Assignment Response that carries RAB ID(s), TEID(s), QoS Profile(s) and RNC IP Address(es). The GTP tunnel has already been established over the Iu interface. If the RNC returns the Radio Access Bearer Assignment Response message and the cause value indicates the required QoS cannot be provided (Requested Maximum Bit Rate not Available), the SGSN will send another Radio Access Bearer Assignment Request message that carries a different QoS. The number of retries and the new QoS value are implementation-dependent.
7)      For the modified QoS in each RAB re-establishment, the SGSN will initiate a PDP Context modification procedure to notify the MS and the GGSN of the new negotiated QoS.
8)      The MS sends an uplink PDU.
The Service Accept message does not mean that the RAB(s) reestablishment is successful.
Whatever Service Type, the network will return a Service Reject message with the appropriate cause value to the MS if the service request cannot be accepted.
When the Service Type indicates data and if the SGSN fails to reestablish the RAB(s), the SGSN will initiate a PDP Context modification procedure or deactivates the PDP Context. The specific conditions depend on the QoS negotiation.

2. Network-initiated service request

1)      The SGSN receives the downlink PDP PDU from the MS in the PMM-IDLE state.
2)      The SGSN sends a paging message to the RNC and the RNC sends the paging message to page the MS.
3)      The MS establishes the RRC connection first if there is no existing CS channel.
4)      The MS sends the Service Request message (with P-TMSI, PAI, CKSN and Service Type) to the SGSN. The Service Type is set as the paging response. At this time, the SGSN may initiate an authentication procedure. The SGSN knows whether the downlink PDU needs RAB reestablishment.
5)      The SGSN specifies the ciphering mode.
6)      The SRNC sends a Radio Access Bearer Assignment Request that carries RAB ID(s), TEID(s), QoS Profile(s) and SGSN IP Address(es) to the RNC if the resource reestablishment is needed for the PDP Context. The RNC sends the Radio Bearer Setup message that carries the RAB ID(s) to the MS. In return, the MS sends the Radio Bearer Setup Complete message to the RNC. The RNC sends the Radio Access Bearer Assignment Response message that carries RAB ID(s), TEID(s) and RNC IP Address(es) to the SGSN, indicating that the GTP tunnel has been established on the Iu interface and the RAB between the RNC and the MS has also been established. If the cause value carried in the Radio Access Bearer Assignment Response message returned by the RNC indicates that the required QoS is not available (“Requested Maximum Bit Rate not Available”), the SGSN will send the new Radio Access Bearer Assignment Request message that carries a different QoS. The number of retries and the new QoS parameter are related to the product implementation.
7)      For the modified QoS in each RAB re-establishment, the SGSN will initiate a PDP Context modification procedure to notify the MS and the GGSN of the new QoS.
8)      The SGSN sends a downlink PDU.
If the Service Type is set as paging response, the MS will regard the service request as having been successfully received by the SGSN upon receipt of the Secure Mode Control message from the RRC.

If the SGSN fails to reestablish the RAB(s), it will initiate a PDP Context modification procedure. 

Комментариев нет:

Отправка комментария