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.
Комментариев нет:
Отправить комментарий