<<

. 29
( 132 .)



>>

Ready Packet
Timer Transmit / IMSI:?
Expires Receive RA:?
Cell:?
STANDBY
Mode SGSN


READYMode STANDBYMode
IMSI:known IMSI:known
LA:known LA:known
SGSN:known SGSN:known

IMSI:known IMSI:known
MSC/VLR MSC/VLR
VLR:known VLR:known
SGSN:known SGSN:known
HLR HLR

IMSI:known IMSI:known
RA:known RA:known
Cell:known Cell:????
SGSN SGSN

Figure 4.35 Mobility management states


know where the mobile device is, it cannot be reached by paging. The mobile device
must perform an attach procedure to establish a mobility management context so that it
is registered within the network. This procedure will move the mobile device from the
idle state to the ready state. It is usually done automatically when the device is switched
on. Idle state for GPRS is not the same as idle state for GSM.
4.9 CONNECTION MANAGEMENT 131


Standby state
In the standby state the subscriber is attached to the mobility management of the network
and information is stored about the location of the mobile device. The location of the
mobile device is known to the RA level, which usually includes a number of cells, i.e.
the actual cell is not identi¬ed. By only updating the network when it moves from one
RA to another rather than one cell to another, the mobile device sends fewer signalling
messages and also conserves its battery power. In this state the mobile device can activate
or deactivate the session management PDP context; in practice it automatically moves
to the ready state to do this. A PDP context is required to transfer data over the GPRS
network; however data transmission and reception are not possible until the mobile device
moves to the ready state. The mobile device can be paged in the standby state and asked
to move to the ready state. This state is very similar to the GSM idle state.

Ready state
In the ready state the location of the mobile device is known to the exact cell. Every
time the mobile device changes cell it will update the network with its new location. In
this state of operation the mobile device is capable of transferring data across the GPRS
network if there is a valid PDP context. The mobile device will remain in this state while
data transfer takes place. If no transfer takes place for a particular length of time, the
mobile device may move to the standby state when the ready timer expires. The timer
value is set by the operator, with the speci¬cations having a default setting of 44 seconds
after this time when no cell updates are performed. When the mobile device ¬rst switches
on it will normally move from idle to ready mode. If the subscriber does not initiate a
PDP context within the time allowed then the mobile device will move to the standby
mode. A mobile device will move from standby to idle at the expiration of another timer;
again, this is operator dependent but the speci¬cations set a default value of 54 minutes.
After this time the mobile device will perform a location update (even if it has not moved
to another cell) or it will be moved to idle mode.


4.9.1.1 GPRS attach procedure
Figure 4.36, shows the signalling ¬‚ow for a combined GPRS/IMSI attach procedure. Each
step in the procedure is explained below.

1. The mobile device initiates the attach procedure by sending the attach request
message to the HLR. This message will include either the IMSI or the P-TMSI and
the RAI that it was valid in (the IMSI will be sent if the mobile device does not
already have a valid P-TMSI), the attach type and the classmark of the mobile
device indicating its multislot capabilities. The attach type will indicate whether this
is simply a GPRS attach or a combined GPRS/IMSI attach.
2. The security functions can now be executed as described in Section 3.5. The SGSN
will query the HLR with the IMSI and be given the triplets back which include the
ciphering key (Kc), random number (RAND) and signed response (SRES). The
RAND will be passed to the mobile device and it will reply with an SRES™. The
132 GENERAL PACKET RADIO SERVICE


HLR/AuC/
UE BSS SGSN GGSN MSC/VLR
EIR


AttachRequest
1
SecurityFunctions SecurityFunctions
2
UpdateLocation
3
Insert ubscriberData
4
Insert SubscriberDataAck.
5
UpdateLocationAck.
6
LocationUpdateRequest
7
Updateocation
8
InsertSubscriberData
9
InsertSubscriberDataAck.
10
UpdateLocationAck.
11
LocationUpdateAccept
12
AttachAccept
13
AttachComplete
14



Figure 4.36 Combined GPRS/IMSI attach procedure

SGSN will compare the SRES from the AuC and the mobile device and if they are
the same then the IMSI is authenticated. The mobile device (IMEI) can now be
checked against the EIR; however, this is not compulsory.
3. The SGSN sends an update location message to the HLR which will include the
SGSN identi¬er and the IMSI of the mobile device.
4. The HLR will send an update subscriber data message back to the SGSN which
will contain the subscription data associated with the IMSI.
5. The SGSN validates the mobile device™s presence in the new RA and acknowledges
receipt of the update subscriber data message.
6. The HLR acknowledges the update location message from the SGSN in step 5.
7. If the attach type in the initial attach request indicated combined GPRS IMSI attach
then the VLR will be updated across the Gs interface. The speci¬c VLR can be
ascertained from the RAI.
8. The VLR send an update location message to the HLR which will include the VLR
identi¬er and the IMSI of the mobile device.
9. The HLR will send an update subscriber data message back to the VLR which will
contain the subscription data associated with the IMSI.
10. The VLR acknowledges receipt of the update subscriber data message.
4.9 CONNECTION MANAGEMENT 133


11. The HLR acknowledges the update location message from the VLR in step 10.
12. The VLR will now reply to the SGSN with the location update accept message
which includes the VLR identi¬cation and the TMSI of the mobile device.
13. The SGSN sends an attach accept message back to the mobile device which will
include the P-TMSI and the TMSI.
14. The mobile device acknowledges receipt of the P-TMSI and TMSI.


4.9.1.2 Location updating
Figure 4.37 illustrates how mobility management signalling is routed to the core network.
In GSM dedicated (connected) mode and GPRS ready state, cell updates are performed;
in GSM idle or GPRS standby states LA and RA updates are performed.
An RA update can take place because a subscriber moves into a new RA and the
mobile device detects the new RA identi¬er, or the RA timer has expired. This latter case
is referred to as a periodic routing area update. The RA update can take two forms:

• Intra SGSN RA update where the new RA is controlled by the same SGSN as the
current RA. The SGSN will have all information pertaining to the mobile device and
it does not need to inform the HLR or the GGSN. The mobile device will probably be
given a new P-TMSI identi¬er. All periodic RA updates are of this type.
• Inter SGSN RA update. In this case the mobile device has noticed a change from
one RA to another; however, these RAs are administered by different SGSNs. This
procedure is illustrated in Figure 4.38 and described below.

1. The mobile device sends a routing area update request which includes the old RAI,
the update type and the capability of the mobile device to the new SGSN.
2. The new SGSN sends the SGSN context request message to the old SGSN which
includes the TLLI, old RAI and new SGSN address. The old SGSN now knows
where to send packets that arrive from a GGSN over the Gn interface.
3. The old SGSN replies with the mobility context of the mobile device and any PDP
context information it has. It stops sending packets directly to the mobile device
and starts a timer. If the timer expires before the RA procedure is completed
successfully then the old SGSN will remain in control of the mobile device. This

Location Area Update Cell Update
MSC/VLR MSC/VLR

BSS BSS


Routing Area Update Cell Update
SGSN SGSN
Standby state GPRS ready state

Figure 4.37 GPRS mobility management
134 GENERAL PACKET RADIO SERVICE



BSS
UE New SGSN Old SGSN GGSN HLR

RA Update Request
1
SGSN Context Request
2
SGSN Context Reponse
3
T1
Security Functions
Security Functions
4
SGSN Context Ack.
5
Forward Packets
6
Update PDP Context Request
7
Update PDP Context Response
8
Update Location
9
Cancel Location
10
Cancel Location Ack.
11
Insert Subscriber Data
12
Insert Subscriber Data Ack.
13
Update Location Ack.
14
RA Update Update Accept
15
RA Update Ack.
16


Figure 4.38 Inter SGSN RA update


may be the case when a mobile subscriber changes geographical direction and
moves back into the old RA.
4. Standard security functions can now be performed.
5. The new SGSN sends an acknowledgement to the old SGSN. Its purpose is to
inform the old SGSN that it is now ready to receive packets destined for the mobile
device from any active PDP contexts.
6. The old SGSN starts to transfer packets via the new SGSN to the mobile device.
Note that the packets to and from a GGSN are tunnelled to the old SGSN and then
tunnelled from the old SGSN to the new SGSN.
7. The new SGSN informs each of the GGSNs that it is now handling the mobile
device and requests an update PDP context. This information includes the new
SGSN address, TEID and QoS that has been negotiated.
8. The GGSNs will update their databases and reply with an update PDP context
response.
9. The new SGSN now sends a location update message to inform the HLR that it is
now controlling the mobile device. This message will include the SGSN address
and the IMSI of the mobile device.
4.9 CONNECTION MANAGEMENT 135


10. The HLR will send a cancel location to the old SGSN. The mobile device will be
identi¬ed by its IMSI and all mobility management and PDP context information in
the old SGSN will be removed after the timer expires.
11. The old SGSN acknowledges the cancel location message.
12. The HLR sends the insert subscriber data message to the new SGSN. This includes
the IMSI and GPRS subscription data.
13. The new SGSN acknowledges the insert subscriber data message.
14. The HLR now acknowledges the update location message sent by the new SGSN in
step 9.
15. The new SGSN now establishes a logical link connection to the mobile device and
sends the routing area update accept message.
16. The mobile device acknowledges the message by sending the routing area update
compete message back to the new SGSN.

Figure 4.39 is an actual trace which shows the SGSN context request, SGSN context
response and SGSN context acknowledge messages that are identi¬ed in Figure 4.38.


<<

. 29
( 132 .)



>>