Aplicación de la guía ATEX a un problema real

In 2G systems, mobility management has been performed by the core network. The location of the mobile device is known within the MSC/VLR for those devices which are circuit-switched-connected, and in the SGSN for those that are packet-switched-connected. For the packet switched network, GPRS introduces a new location entity, known as a

routing area (RA). Any LA (circuit switched) or RA (for packet switched) updates from the mobile device are passed transparently over the BSS to the core network to be stored in the correct device (MSC or SGSN). In this way, paging for a mobile device is achieved by first finding the correct MSC/VLR or the correct SGSN. Either of these devices will know the location of a mobile device to a precise cell, or to a number of cells (the LA or RA), depending on the state the mobile device is in. This can introduce a lot of signalling traffic. As shown in Figure 4.34, an RA is a subset of an LA, and is defined within the SGSN and not the MSC. An RA can be the same size as an LA but it cannot be larger, i.e. an RA cannot overlap separate LAs. There is no direct correlation between MSCs and SGSNs and the RA is identified by the following formula:

Routing area identifier (RAI)=Mobile country code (MCC)

+Mobile network code (MNC)

+Location area code (LAC)+Routing area code (RAC) There are three basic mobility states that a GPRS device can be in: idle, standby and ready state, as shown in Figure 4.35.

Idle mode

In the idle state the mobile device is not attached to the network and therefore the network holds no valid location or routing information for the device. Since the network does not

MSC 2 LA2 RA RA BTS BTS BTS BTS LA1 RA RA BTS BTS BTS BTS SGSN 1 MSC 1

Figure 4.34 GPRS routing area

SGSN MSC/VLR HLR IMSI:? RA:? Cell:? IDLEMode SGSN MSC/VLR HLR STANDBYMode SGSN MSC/VLR HLR IMSI:known LA:known SGSN:known IMSI:known LA:known SGSN:known IMSI:known RA:known Cell:known IMSI:known RA:known Cell:???? IMSI:known VLR:known SGSN:known IMSI:known VLR:known SGSN:known IMSI:known VLR:? SGSN:? IMSI:? LA:? SGSN:? READYMode IDLE Mode STANDBY Mode READY Mode GPRS Attach GPRS Detach Ready Timer Expires Packet Transmit / Receive Standby Timer Expires

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.

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 identified. 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 theready timer expires. The timer value is set by the operator, with the specifications having a default setting of 44 seconds after this time when no cell updates are performed. When the mobile device first 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 specifications 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 flow 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

HLR/AuC/ EIR UpdateLocation SecurityFunctions 1 5 4 3 2 6 10 9 8 7 14 13 12 11 BSS UE SGSN GGSN Insert ubscriberData Insert SubscriberDataAck. UpdateLocationAck. MSC/VLR LocationUpdateRequest Updateocation InsertSubscriberData InsertSubscriberDataAck. UpdateLocationAck. LocationUpdateAccept AttachAccept AttachComplete SecurityFunctions AttachRequest

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 anupdate location message to the HLR which will include the SGSN identifier 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 specific VLR can be ascertained from the RAI.

8. The VLR send an update location message to the HLR which will include the VLR identifier 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.

11. The HLR acknowledges theupdate location message from the VLR in step 10. 12. The VLR will now reply to the SGSN with thelocation update accept message

which includes the VLR identification and the TMSI of the mobile device. 13. The SGSN sends anattach 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 identifier, or the RA timer has expired. This latter case is referred to as aperiodic 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 identifier. 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 arouting 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 theSGSN 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

MSC/VLR

SGSN Standby state

Location Area Update

BSS Routing Area Update

MSC/VLR SGSN Cell Update BSS Cell Update GPRS ready state Figure 4.37 GPRS mobility management

SGSN Context Reponse

Security Functions

Update PDP Context Request Forward Packets RA Update Request HLR SGSN Context Request SGSN Context Ack. T1 Security Functions

Update PDP Context Response Update Location

Cancel Location Cancel Location Ack. Insert Subscriber Data Insert Subscriber Data Ack.

Update Location Ack.

RA Update Ack. RA Update Update Accept

1 5 4 3 2 6 10 9 8 7 14 13 12 11 16 15 BSS UE New SGSN Old SGSN GGSN

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.

10. The HLR will send acancel location to the old SGSN. The mobile device will be identified 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 thecancel locationmessage.

12. The HLR sends theinsert subscriber data message to the new SGSN. This includes the IMSI and GPRS subscription data.

13. The new SGSN acknowledges theinsert subscriber data message.

14. The HLR now acknowledges theupdate 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 therouting area update accept message.

16. The mobile device acknowledges the message by sending therouting 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 identified in Figure 4.38.