Muhammad Imran Shabir

Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 1 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference GPRS Mobility Management for GSM Access Copyright © Ericsson AB-. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document. Contents A4 XSEIF R5 Page 1 1.1 1.2 Introduction . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Scope .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Target Groups . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 4 4 5 2 Overview . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 5 - Mobility Management States for GSM Access . .. ... .. ... ... .. ... .. ... ... .. IDLE .. .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. READY . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. STANDBY_REACHABLE . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. STANDBY_NOT_REACHABLE .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 7 8 8 9 9 - MS Attach ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 9 Traffic Case for MS-Attach using Gn Interface . ... .. ... .. ... ... .. ... .. ... ... .. 10 Traffic Case for MS-Attach using S4 Interface .. ... .. ... .. ... ... .. ... .. ... ... .. 13 Attach Not Accepted .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 17 - MS Detach .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. MS-Initiated Detach . .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for MS-Initiated Detach using Gn Interface . ... ... .. ... .. ... ... .. Traffic Case for MS-Initiated Detach using S4 Interface . ... ... .. ... .. ... ... .. HLR-Initiated Detach . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for HLR-Initiated Detach using Gn Interface .. ... .. ... .. ... ... .. Traffic Case for HLR-Initiated Detach using S4 Interface ... ... .. ... .. ... ... .. SGSN-Initiated Detach .. .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for MS-Initiated Detach using Gn Interface . ... ... .. ... .. ... ... .. Traffic Case for MS-Initiated Detach using S4 Interface . ... ... .. ... .. ... ... .. Implicit Detach . ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. System Failure ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. - Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 2 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference - Paging . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Paging at GPRS Downlink Transfer . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Smart Paging .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Paging Sequence, Gb Interface .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. CS Paging over the Gs Interface . ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 7 Cell Update . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 30 - - Routing Area Update ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Intra-SGSN RAU . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for Intra-SGSN RAU using Gn Interface .. .. ... ... .. ... .. ... ... .. Traffic Case for Intra-SGSN RAU without SGW Relocation using S4 Interface ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for Intra-SGSN RAU with SGW Relocation using S4 Interface RAU Not Accepted .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Inter-SGSN RAU . ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for Inter-SGSN RAU using Gn Interface .. .. ... ... .. ... .. ... ... .. Traffic Case for Inter-SGSN RAU without SGW Relocation using S4 Interface ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case for Inter-SGSN RAU with SGW Relocation using S4 Interface Traffic Case for SGSN Pool .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. RAU Not Accepted .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Periodic RAU .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 9 9.1 Inter-BSC NACC Using RIM Transfer . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 52 Traffic Case .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 52 - Handover . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. PS Handover .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case Intra-BSS ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case Inter-BSS Intra-SGSN . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. Traffic Case Inter-BSS Inter-SGSN . .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. PS Handover Not Accepted .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. PS Handover Cancel . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 11 Cooperating SGSNs . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 65 12 Suspend and Resume . .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 66 - Shared Network Support ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 66 Selective Equivalent PLMN List .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 66 Support for Multiple PLMNs .. ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 67 - Restrictions . .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 67 Roaming Restrictions . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 67 Access Restriction .. .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 67 15 Capacity License Limit .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 68 16 Prioritize Payload Users . ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 69 - - - - Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 3 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 17 Multiple Time Zones . ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 69 18 Home Zone Charging Differentiation .. ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 69 19 Multiple SIM Support ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 70 20 Parameters .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 70 21 Counters . ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 72 22 Alarms . ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 73 23 References .. .. ... ... .. ... .. ... ... .. ... .. ... ... .. ... ... .. ... .. ... ... .. ... .. ... ... .. 74 Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 4 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 1 Date Rev - AA Reference Introduction This document describes General Packet Radio Service (GPRS) mobility management for Global System for Mobile communication (GSM) radio network access in the Serving GPRS Support Node and Mobility Management Entity (SGSN-MME). The mobility management procedures described in this document are only applicable for the Serving GPRS Support Node (SGSN). For information on mobility management procedures applicable for the Mobility Management Entity (MME), see EPS Mobility Management for LTE Access. Mobility management in the SGSN keeps track of the Mobile Stations (MSs). Since an MS is often moving from one place to another, the network must be aware of the location of the MS in order to maintain connectivity. Mobility management refers to the procedures that make this possible. It allows an MS to register in the network, keeps track of the Routing Area (RA) within the SGSN service area in which an MS is located, and minimizes service interruptions at change of RA. Mobility management also keeps track of the mobility management state of the MSs, and initiates paging. The information sets held by the MS and the SGSN with information about mobility management state, location, and subscriber data are denoted mobility management context. 1.1 Scope The document covers the following: • An overview presenting the mobility management context in the SGSN. • Descriptions of all mobility management states for GSM access. • Descriptions of supported mobility management procedures for GSM access. • Traffic cases for procedures describing message exchange between the MS, the SGSN, and the other nodes in the network. • Descriptions of how mobility management is influenced by SGSN Pool and the dual access mode. • Description of inter- Base Station Controller (BSC) Network Assisted Cell Change (NACC) using Radio Access Network (RAN) Information Management (RIM) transfer. • Description of Packet-Switched (PS) Handover. • Description of cooperating SGSNs. • Description of the support for network sharing. • Description of Roaming Restrictions and Access Restrictions. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 5 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 1.2 Date Rev - AA Reference • Description of prioritized payload users. • Parameters related to mobility management. For a description of each parameter and its default values, see Parameter Description. • Counters related to mobility management. For a description of each counter, see Counter Description. • Alarms related to mobility management. Each alarm is described in an Alarm and Event Description. For additional information on alarms, see Fault Management. Target Groups This document is intended as an introduction to mobility management for network operators, network and service planners, as well as system engineers and administrators. It assumes a basic knowledge of datacommunications and telecommunications. 2 Overview Mobility management keeps track of the MSs in the radio networks. The radio networks for both GSM and WCDMA Systems have a cellular structure, which is illustrated in Figure 1. For GSM, the sizes of the cells are static, while for WCDMA Systems they are dynamic, that is, they can change size depending on load. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 6 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference GPRS Service Area Cell Routing Area SGSN Service Area PLMN Area Figure 1 Example of GSM and WCDMA Systems Cellular Network Structure The cellular networks consist of the following geographical areas: • General Packet Radio Service (GPRS) service area • Public Land Mobile Network (PLMN) • SGSN service area or SGSN pool service area • Location Area • RA • Cell For further information on the cellular networks, see Ericsson Packet Core Network Overview. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 7 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference The following areas are described in this document: • MS Attach • MS Detach • Paging • Cell Update • Routing Area Update (RAU) • Inter-BSC NACC • PS Handover • Cooperating SGSNs • Suspend and resume GPRS services • Shared network support • Roaming and Access Restrictions • Capacity license limit • Prioritization of payload users • Multiple time zones • Differentiation of charging within a configured Home Zone area • Multiple SIM support For further information on how Ericsson supports the standards, see Statements of Compliance Reference [27] to Reference [38]. 3 Mobility Management States for GSM Access The GPRS mobility management states describe the state an MS resides in from the SGSN perspective. Different mobility management states apply for each radio network type. The following mobility management states apply for GSM MSs: • IDLE • READY • STANDBY_REACHABLE • STANDBY_NOT_REACHABLE Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 8 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference The mobility management states are shown in Figure 2. Timeout Implicit Detach timer or Detach IDLE STANDBY_NOT_ REACHABLE Packet from MS Timeout REACHABLE timer Detach Detach Attach Timeout READY timer, or Force to STANDBY READY STANDBY_ REACHABLE Packet from MS Figure 2 Mobility Management States for GSM Access With Dual Transfer Mode (DTM) an MS can handle Circuit-Switched (CS) and PS traffic simultaneously. The SGSN supports DTM by transparently transferring the Radio Access Capability (RAC) received from the MS to the Base Station Subsystem (BSS). The SGSN receives the RAC from the MS during the Attach Request procedure and RAU procedure. The SGSN then sends the RAC information in each BSS GPRS Protocol (BSSGP) Packet Data Unit (PDU) sent to the BSS. The IRAT PS Handover capability information is also sent to the BSS. 3.1 IDLE An MS in the IDLE state is not attached. Therefore, the SGSN can neither locate nor reach it, and no mobility management context exists for the subscriber. After a successful MS Attach procedure, the state is changed to READY. 3.2 READY An MS in the READY state is attached, and a mobility management context and possibly one or several Packet Data Protocol (PDP) contexts exist for the subscriber. A signaling procedure or payload transfer is ongoing or has recently ended. The current location information is on cell level, that is, the location is known by the SGSN with an accuracy of the serving cell, and no paging is required to reach the MS. A ready timer defines the time the MS remains in the READY state after a packet data transfer. When the timer expires, the state is changed to STANDBY_REACHABLE. After a successful MS Detach procedure, the state is changed to IDLE. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 9 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 3.3 Date Rev - AA Reference STANDBY_REACHABLE An MS in the STANDBY_REACHABLE state is attached. The location information is on RA level, that is, no information on cell level is available and paging is required to reach the MS. A mobile-reachable timer defines the time the MS remains in STANDBY_REACHABLE state. When the timer expires, the state is changed to STANDBY_NOT_REACHABLE. After a successful MS Detach procedure, the state is changed to IDLE. Uplink payload transfer or a signaling procedure initiated by the MS will change the state to READY. 3.4 STANDBY_NOT_REACHABLE An MS in the STANDBY_NOT_REACHABLE state is attached. The last known location information is on RA level, that is, no information on cell level is available. Contact is resumed as soon as the MS sends packet data and the state is changed to READY. If the MS sends no packet data, an implicit detach timer defines the time the MS remains in STANDBY_NOT_REACHABLE state. When the timer expires, the MS is implicitly detached, that is, the mobility management context and possible PDP context is deleted, and the state is changed to IDLE. After a successful MS Detach procedure, the state is changed to IDLE. A signaling procedure will change the state to READY. 4 MS Attach To announce its presence in the Packet-Switched (PS) network, the MS must initiate an MS Attach procedure by signaling to the SGSN. Upon completion, the GSM MS is in the READY state, and the mobility management contexts are established in the MS. An attached MS must perform a PDP Context Activation procedure to start PS data transfer. An attached MS can also send and receive Short Message Service (SMS) messages over GPRS. For GSM networks in network mode of operation 1 an MS may attach to both PS and CS services through the PS networks. In that case, to attach to the CS services as well, the MS must perform a combined GPRS and International Mobile Subscriber Identity (IMSI) attach. The optional Gs interface is used for the combined attach and for the CS signaling between the SGSN and the Mobile services Switching Center/Visitor Location Register (MSC/VLR). At attach, an MS can identify itself with its Packet Temporary Mobile Subscriber Identity (P-TMSI) or IMSI. If the P-TMSI is used for identification and the old Routing Area Identity (RAI) belongs to another SGSN than the one the MS is trying to attach to, the IMSI is requested from that other SGSN, if it is configured as a cooperating SGSN. If the SGSN to which the MS was previously attached is not a cooperating SGSN, the IMSI among other things are requested from the MS. Also for MSs unknown to both SGSNs, that is, new MSs, the IMSI is requested from the MS. If Roaming Restrictions (see Section 14.1 on page 67) are in force, the SGSN verifies that the IMSI is not restricted but allowed in the current Location Area (LA). Access restrictions may also be in force, see Section 14.2 on page 67. The Home Location Register (HLR) stores information Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 10 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference on which SGSN an MS last attached to. See Security for more information on the authentication procedure and the selective authentication procedure. A P-TMSI must be allocated to every GPRS-attached MS. For more information on P-TMSI, see SoC for 3GPP TS 23.236. At attach, the optional Gf interface enables the SGSN to check the legality of an MS by sending an International Mobile Equipment Identity (IMEI) check request to the Equipment Identity Register (EIR). If the SGSN is connected to multiple EIRs, the IMEI check request is sent to the appropriate EIR based on the IMSI number series or to the default EIR. For more information about the IMEI Check feature, see Security. The SGSN supports MSs that do not comply with the 3GPP standards regarding optional Information Elements (IEs). For example, a Non 3GPP compliant MS may not be able to handle the cell notification IE in the Attach Accept message. This leads to problems at attach and can ultimately cause the MS to reboot. In order to handle this the SGSN retransmits the Attach Accept message up to five times. If the problem persists, the SGSN alters the message and excludes some optional IEs known to cause problems with non-3GPP compliant MSs. The list of IEs that are omitted from the altered message is kept hardcoded in the SGSN and can only be changed by altering the actual code. When the MS attaches to an SGSN in an RA that belongs to a home zone, the RAU Accept message never includes the Cell Notification IE. An SGSN operating in a pool (see SGSN Pool for further information) is uniquely identified by its Network Resource Identifier (NRI) value included in the P-TMSI, which is allocated during the Attach procedure. Once assigned a P-TMSI with an NRI value, the MS normally remains attached to that SGSN as long as it remains in the area covered by the SGSN pool. If the SGSN becomes unavailable, the BSC routes the signaling for the MSs served by the SGSN to another SGSN in the pool. IMSI attaches are distributed among the SGSN pool members by the BSC. 4.1 Traffic Case for MS-Attach using Gn Interface The attach procedure is shown in Figure 3. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS old SGSN SGSN GGSN Date Rev - AA HLR MSC/VLR 1. Attach Request 2. Identification Request 3. Identification Response 4. Identity Request 5. Identity Response 6. Security functions 7. IMEI Check 8. Delete PDP Context Request 9. Delete PDP Context Response 10. Update Location 11. Insert Subscriber Data 12. Insert Subscriber Data Ack. 13. Update Location Ack. 14. Location Update Request 15. Location Update Accept 16. SGSN Activities 17. Attach Accept 18. Altered Attach Accept 19. Attach Complete 20. TMSI Reallocation Complete 21. GMM Information compulsory communication conditional or optional communication Figure 3 MS Attach Procedure using Gn Interface The following steps describe the MS Attach procedure: Reference EIR 11 ( 76 ) Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 12 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 1. Date Rev - AA Reference The MS sends an Attach Request message to the SGSN. The Attach Request message contains information about the MS, which can identify itself with IMSI or P-TMSI. The old RAI can correspond to either the SGSN trying to attach to, or an SGSN previously attached to. For SGSNs acting in a pool, the BSC sends the request to an SGSN in the pool by matching the NRI value, or, if not previously attached to an SGSN in the pool, the request is distributed to one of the SGSN pool members. 2. If the MS identifies itself with P-TMSI and the RAI corresponds to an RA served by another SGSN than the one the MS is trying to attach to, the SGSN sends an Identification Request message to fetch the mobility management context from the previously used SGSN. 3. The previously used SGSN returns the IMSI number and authentication information of the MS by sending an Identification Response message to the SGSN. If an Identification Response message is not received after a time specified by the Gn_T3-ResponseIdentification parameter, the SGSN retransmits the Identification Request message a number of times specified by the Gn_N3-RequestsIdentification parameter. After last retransmission the IMSI number is instead fetched from the MS, according to the next step. 4. If the IMSI number is not stored in the SGSN or in the old SGSN it is requested from the MS through an Identity Request message. 5. The MS sends the IMSI number to the SGSN in an Identity Response message. 6. If no mobility management context for the MS exists in the network, the SGSN fetches the authentication data from the HLR, and thereafter authenticates the MS. 7. If the optional Gf interface is used and the IMEI Check feature is enabled for GSM radio access, the IMEI is checked by sending an IMEI check request to the EIR. 8. The SGSN sends a Delete PDP Context Request message tothe GGSN. This message contains information about the default bearer that belongs to the PDN connection that is to be deleted. 9. The GGSN acknowledges the request by sending a Delete PDP Context Response message to the SGSN. 10. If the location of the MS is unknown in the HLR, the SGSN sends an Update Location message to the HLR. 11. The HLR sends the relevant subscriber data to the SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 13 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 12. The SGSN sends an acknowledgement to the HLR that the subscriber data has been received. 13. The HLR sends an acknowledgement to the SGSN that location update is performed. 14. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI attach, the SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 15. When the MSC/VLR number is stored, an association is created between the SGSN and the MSC/VLR through the Location Update Accept message. 16. The SGSN allocates a new P-TMSI and a P-TMSI signature and, if ciphering is enabled, enters ciphering mode. If the SGSN is a pool member, the SGSN unique NRI value is included in the P-TMSI. 17. The SGSN sends an Attach Accept message to the MS. The Attach Accept message can include a list of equivalent PLMNs, if such a list has been defined. It also includes a request to the MS to share its IRAT PS Handover capability. The P-TMSI and P-TMSI signature are included as well. 18. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions the SGSN sends an altered Attach Accept message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 19. The MS acknowledges the received P-TMSI and P-TMSI signature with an Attach Complete message. The IRAT PS Handover capability is included in the message. 20. In GSM networks in network mode of operation 1, if the optional Gs interface is used, and if the MSC/VLR has allocated a new Temporary Mobile Subscriber Identity (TMSI) for the MS, the SGSN sends a TMSI Reallocation Complete message to the MSC/VLR. 21. Based on the optional configuration of Gb_SendGmmInfo (GSM), the operator can choose to configure the SGSN to send network information in the GPRS Mobility Management (GMM) Information message to the MS. This may provide local time to the MS. 4.2 Traffic Case for MS-Attach using S4 Interface The attach procedure is shown in Figure 3. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS 14 ( 76 ) No. SGSN old SGSN SGW Date Rev - AA PGW 1. Attach Request 2. Identification Request 3. Identification Response 4. Identity Request 5. Identity Response 6. Security functions 7. IMEI Check 8. Delete Session Request 9. Delete Session Request 10. Delete Session Response 11. Delete Session Response 12. Update Location 13. Insert Subscriber Data 14. Insert Subscriber Data Ack. 15. Update Location Ack. 16. Location Update Request 17. Location Update Accept 18. SGSN Activities 19. Attach Accept 20. Altered Attach Accept 21. Attach Complete 22. TMSI Reallocation Complete 23. GMM Information compulsory communication conditional or optional communication HLR Reference MSC/VLR EIR Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Figure 4 15 ( 76 ) No. Date Rev - AA Reference MS Attach Procedure using S4 Interface The following steps describe the MS Attach procedure: 1. The MS sends an Attach Request message to the SGSN. The Attach Request message contains information about the MS, which can identify itself with IMSI or P-TMSI. The old RAI can correspond to either the SGSN trying to attach to, or an SGSN previously attached to. For SGSNs acting in a pool, the BSC sends the request to an SGSN in the pool by matching the NRI value, or, if not previously attached to an SGSN in the pool, the request is distributed to one of the SGSN pool members. 2. If the MS identifies itself with P-TMSI and the RAI corresponds to an RA served by another SGSN than the one the MS is trying to attach to, the SGSN sends an Identification Request message to fetch the mobility management context from the previously used SGSN. Note: 3. Only GTPv1 is being supported for the Identification Request and Identification Response messages. The previously used SGSN returns the IMSI number and authentication information of the MS by sending an Identification Response message to the SGSN. If an Identification Response message is not received after a time specified by the Gn_T3-ResponseIdentification parameter, the SGSN retransmits the Identification Request message a number of times specified by the Gn_N3-RequestsIdentification parameter. After last retransmission the IMSI number is instead fetched from the MS, according to the next step. 4. If the IMSI number is not stored in the SGSN or in the old SGSN it is requested from the MS through an Identity Request message. 5. The MS sends the IMSI number to the SGSN in an Identity Response message. 6. If no mobility management context for the MS exists in the network, the SGSN fetches the authentication data from the HLR, and thereafter authenticates the MS. 7. If the optional Gf interface is used and the IMEI Check feature is enabled for GSM radio access, the IMEI is checked by sending an IMEI check request to the EIR. 8. The SGSN sends a Delete Session Request message to the SGW for each PDN connection. 9. The SGW sends a Delete Session Request message to the PGW. This message contains information about the default bearer that belongs to the PDN connection that is to be deleted. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 16 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 10. The PGW acknowledges the request by sending a Delete Session Response message to the SGW. 11. The SGW sends the Delete Session Response message to the SGSN. 12. If the location of the MS is unknown in the HLR, the SGSN sends an Update Location message to the HLR. 13. The HLR sends the relevant subscriber data to the SGSN. 14. The SGSN sends an acknowledgement to the HLR that the subscriber data has been received. 15. The HLR sends an acknowledgement to the SGSN that location update is performed. 16. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI attach, the SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 17. When the MSC/VLR number is stored, an association is created between the SGSN and the MSC/VLR through the Location Update Accept message. 18. The SGSN allocates a new P-TMSI and a P-TMSI signature and, if ciphering is enabled, enters ciphering mode. If the SGSN is a pool member, the SGSN unique NRI value is included in the P-TMSI. 19. The SGSN sends an Attach Accept message to the MS. The Attach Accept message can include a list of equivalent PLMNs, if such a list has been defined. It also includes a request to the MS to share its IRAT PS Handover capability. The P-TMSI and P-TMSI signature are included as well. 20. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions the SGSN sends an altered Attach Accept message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 21. The MS acknowledges the received P-TMSI and P-TMSI signature with an Attach Complete message. The IRAT PS Handover capability is included in the message. 22. In GSM networks in network mode of operation 1, if the optional Gs interface is used, and if the MSC/VLR has allocated a new Temporary Mobile Subscriber Identity (TMSI) for the MS, the SGSN sends a TMSI Reallocation Complete message to the MSC/VLR. 23. Based on the optional configuration of Gb_SendGmmInfo (GSM), the operator can choose to configure the SGSN to send network information in the GPRS Mobility Management (GMM) Information message to the MS. This may provide local time to the MS. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 17 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 4.3 Date Rev - AA Reference Attach Not Accepted If the Attach procedure is not accepted, either an Attach Reject message including a cause for the rejection, is sent to the MS, or the Attach procedure is aborted or ignored without notifying the MS. All Attach Reject messages due to network failure are logged. The attach is silently aborted when the response of an identity check is negative, for example, when the SGSN requests the IMSI of the MS. The attach can also be silently aborted if the MS is not accepted during authentication. An Attach Reject message is sent if the IMSI analysis fails, the SGSN is congested, authentication fails, a protocol error in the Attach Request message is detected, an update of location is not accepted by the HLR, the MS tries to attach to a PLMN where GPRS services are not allowed, or the subscriber data for the MS does not allow an attach. In addition, if roaming for an MS is restricted according to the Roaming Restriction, see Section 14.1 on page 67, and the MS tries to attach in a restricted LA, the attach is rejected with an Attach Reject message. Attach can also be rejected due to Access Restrictions, see chapter Section 14.2 on page 67, or Capacity License Limits, see Section 15 on page 68. If an Attach Complete message from an MS is not received after a time specified by the attach complete timer, the SGSN retransmits the Attach Accept message. After all retransmissions and if no Attach Complete message is received from the MS, the Attach procedure is aborted and the SGSN considers both the old and currently used P-TMSI and the P-TMSI signature as valid. At a combined attach attempt over the optional Gs interface, an MS can be allowed to attach to the PS network even though the attach to the CS network is rejected. The SGSN then answers the attach with an Attach Accept message, including a cause code about the failed CS attach. 5 MS Detach An MS can explicitly detach from the GPRS network. It can also be explicitly or implicitly detached by the HLR or SGSN. After a successfully completed MS Detach procedure the GSM MS is in the IDLE state, and the MS cannot send or receive data. When using combined procedures over the Gs interface, an MS can be either combined detached or IMSI detached from the CS services. 5.1 MS-Initiated Detach The MS-Initiated Detach procedure informs the network that an MS wants to detach. The SGSN detaches the MS but retains the P-TMSI, P-TMSI signature, IMSI number, subscription data, and the unused authentication vectors. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 18 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference Therefore, normally, the SGSN does not have to contact the HLR when the MS reattaches, provided that it is still within the same SGSN service area. The detach request can be refused, for example, if the P-TMSI signature is not valid or not included in the request. In the following sections, the MS-initiated detach procedure is explained using the Gn and S4 interfaces. 5.1.1 Traffic Case for MS-Initiated Detach using Gn Interface The MS-initiated detach procedure using the Gn interface is shown in Figure 5. MS SGSN GGSN MSC/VLR 1. Detach Request 2. Delete PDP Context Request 3. Delete PDP Context Response 4. GPRS Detach Indication 5. Detach Accept compulsory communication conditional or optional communication Figure 5 MS-Initiated Detach Procedure using the Gn Interface The following steps describe the MS-initiated detach procedure: 1. The MS sends a Detach Request message to the SGSN. The Detach Request message mentions if the detach is due to a switch-off. 2. If the SGSN has active PDP contexts for each PDN connection, the SGSN starts the deactivation of active PDP contexts by sending a Delete PDP Context Request message to the Gateway GPRS Support Node (GGSN). 3. The GGSN acknowledges the deletion with a Delete PDP Context Response message. 4. For an IMSI-attached MS in GSM, the SGSN sends a GPRS Detach Indication message to the MSC/VLR, which deletes the association with the SGSN. Afterwards the MSC/VLR handles the paging and location update without involving the SGSN. 5. If the detach is not due to a switch-off, the SGSN sends a Detach Accept message to the MS. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 19 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 5.1.2 Date Rev - AA Reference Traffic Case for MS-Initiated Detach using S4 Interface The MS-Initiated detach procedure using the S4 interface is shown in Figure 6. MS SGSN SGW PGW MSC/ VLR 1. Detach Request 2. Delete Session Request 3. Delete Session Request 4. Delete Session Response 5. Delete Session Response 6. GPRS Detach Indication 7. Detach Accept compulsory communication conditional or optional communication Figure 6 MS-Initiated Detach Procedure using the S4 Interface The following steps describe the MS-initiated detach procedure: 1. The MS sends a Detach Request message to the SGSN. The Detach Request message mentions if the detach is due to a switch-off. 2. If the SGSN has active EPS Bearers for each PDN connection, the SGSN starts the deactivation of active EPS Bearers by sending a Delete Session Request message to the SGW. 3. The SGW sends a Delete Session Request message to the PGW. 4. The PGW acknowledges the bearer deactivation by sending a Delete Session Response message to the SGW. 5. The SGW acknowledges the deletion by sending a Delete Session Response message to the SGSN. 6. For an IMSI-attached MS in GSM, the SGSN sends a GPRS Detach Indication message to the MSC/VLR, which deletes the association with Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 20 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference the SGSN. Afterwards, the MSC/VLR handles the paging and location update without involving the SGSN. 7. 5.2 If the detach is not due to a switch-off, the SGSN sends a Detach Accept message to the MS. HLR-Initiated Detach An HLR uses the HLR-Initiated Detach procedure for operator-determined purposes to request the deletion of a subscriber’s mobility management context and PDP contexts in the SGSN. The HLR-Initiated Detach procedure, also called the Cancel Location procedure, is further described in Subscriber Data Management. In the following sections, the HLR-initiated detach procedures are explained using the Gn and S4 interfaces. 5.2.1 Traffic Case for HLR-Initiated Detach using Gn Interface The HLR-Initiated Detach procedure using the Gn interface is shown in Figure 7. MS SGSN GGSN HLR MSC/VLR 1. Cancel Location 2. Detach Request 3. Delete PDP Context Request 4. Delete PDP Context Response 5. GPRS Detach Indication 6. Detach Accept 7. Cancel Location Ack compulsory communication conditional or optional communication Figure 7 HLR-Initiated Detach Procedure using the Gn Interface The following steps describe the HLR-initiated detach procedure: 1. The HLR, requesting the immediate deletion of a subscriber’s mobility management and PDP contexts, sends a Cancel Location message to the SGSN. 2. The SGSN informs the MS that it has been detached by sending a Detach Request message to the MS. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 21 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 5.2.2 Date Rev - AA Reference 3. If the SGSN has active PDP contexts for each PDN connection, the SGSN starts the deactivation of active PDP contexts by sending a PDP Context Request message to the GGSN. 4. The GGSN acknowledges the deletion by sending a Delete PDP Context Response message to the SGSN. 5. For an IMSI-attached MS in GSM, the SGSN sends a GPRS Detach Indication message to the MSC/VLR, which deletes the association with the SGSN. Afterwards the MSC/VLR handles the paging and location update without involving the SGSN. 6. The MS sends a Detach Accept message to the SGSN any time after step 2. 7. The SGSN confirms the deletion of the mobility management and PDP contexts with a Cancel Location Acknowledgement message. Traffic Case for HLR-Initiated Detach using S4 Interface The HLR-initiated detach procedure using the S4 interface is shown in Figure 8. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 22 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS SGSN Date Rev - AA SGW PGW Reference HLR 1. Cancel Location 2. Detach Request 3. Delete Session Request 4. Delete Session Resquest 5. Delete Session Response 6. Delete Session Response 7. GPRS Detach Indication 8. Detach Accept 9. Cancel Location ACK compulsory communication conditional or optional communication Figure 8 HLR-Initiated Detach Procedure using the S4 Interface The following steps describe the HLR-initiated detach procedure: 1. The HLR, requesting the immediate deletion of a subscriber’s mobility management and PDP contexts, sends a Cancel Location message to the SGSN. 2. The SGSN informs the MS that it has been detached by sending a Detach Request message to the MS. 3. If the SGSN has active EPS Bearers for each PDN connection, the SGSN starts the deactivation of active EPS Bearers by sending a Delete Session Request message to the SGW. 4. The SGW sends a Delete Session Request message to the PGW. 5. The PGW acknowledges the bearer deactivation by sending a Delete Session Response message to the SGW. 6. The SGW acknowledges the deletion by sending a Delete Session Response message to the SGSN. MSC/ VLR Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 23 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 5.3 Date Rev - AA Reference 7. For an IMSI-attached MS in GSM, the SGSN sends a GPRS Detach Indication message to the MSC/VLR, which deletes the association with the SGSN. Afterwards the MSC/VLR handles the paging and location update without involving the SGSN. 8. The MS sends a Detach Accept message to the SGSN any time after step 2. 9. The SGSN confirms the deletion of the mobility management and PDP contexts with a Cancel Location Acknowledgement message. SGSN-Initiated Detach The SGSN uses the SGSN-Initiated Detach procedure to request the deletion of a subscriber’s mobility management context and PDP contexts in the SGSN. If the operator triggers this procedure using the delete_subscriber CLI command, the SGSN will delete the P-TMSI, P-TMSI signature, IMSI number, and the unused authentication and subscription data. Also, if the detach procedure is triggered through this CLI command, the MS can optionally be requested to reattach. The SGSN may also initiate an SGSN-Initated Detach during a move within an SGSN Pool, for more information see SGSN Pool. The SGSN can be configured to detach inactive subscribers. If an attached MS does not activate a PDP context within a time specified by a configurable parameter, it might be detached next time it performs a RAU or sends a periodic update message. In the following sections, the SGSN-initiated detach procedures are explained using the Gn and S4 interfaces. 5.3.1 Traffic Case for MS-Initiated Detach using Gn Interface The SGSN-initiated detach procedure using the Gn interface is shown in Figure 9. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 24 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS Date Rev - AA SGSN GGSN Reference MSC/VLR 1. Detach Request 2. Delete PDP Context Request 3. Delete PDP Context Response 4. GPRS Detach Indication 5. Detach Accept 6. Attach Request compulsory communication conditional or optional communication Figure 9 SGSN-Initiated Detach Procedure using the Gn Interface The following steps describe the SGSN-initiated detach procedure: 5.3.2 1. If the operator requests the immediate deletion of a subscriber’s mobility management and PDP contexts, the SGSN informs the MS that it has been detached by sending a Detach Request message to the MS. If the detach procedure is triggered through the delete_subscriber CLI command, the MS can optionally be requested to reattach. 2. If the SGSN has active PDP contexts for each PDN connection, the SGSN starts the deactivation of active PDP contexts by sending a Delete Session Request message to the GGSN. 3. The GGSN acknowledges the deletion with a Delete PDP Context Response message. 4. For an IMSI-attached MS in GSM, the SGSN sends a GPRS Detach Indication message to the MSC/VLR, which deletes the association with the SGSN. Afterwards the MSC/VLR handles the paging and location update without involving the SGSN. 5. The MS sends a Detach Accept message to the SGSN any time after step 1. 6. If the SGSN has requested the MS to reattach, the MS sends an attach request. For information on the attach procedure, see Section 4 on page 9. Traffic Case for MS-Initiated Detach using S4 Interface The SGSN-initiated detach procedure using the S4 interface is shown in Figure 10. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 25 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS SGSN Date Rev - AA SGW PGW Reference MSC/ VLR 1. Detach Request 2. Delete Session Request 3. Delete Session Request 4. Delete Session Response 5. Delete Session Response 6. GPRS Detach Indication 7. Detach Accept 8. Attach Request compulsory communication conditional or optional communication Figure 10 SGSN-Initiated Detach Procedure using the S4 Interface The following steps describe the SGSN-initiated detach procedure: 1. If the operator requests the immediate deletion of a subscriber’s mobility management and PDP contexts, the SGSN informs the MS that it has been detached by sending a Detach Request message to the MS. If the detach procedure is triggered using the delete_subscriber CLI command, the MS can optionally be requested to reattach. 2. If the SGSN has active EPS bearers for each PDN connection, the SGSN starts the deactivation of active EPS bearers by sending a Delete Session Request message to the SGW. 3. The SGW sends a Delete Session Request message to the PGW. 4. The PGW acknowledges the bearer deactivation by sending a Delete Session Response message to the SGW. 5. The SGW acknowledges the deletion with a Delete Session Response message to the SGSN. 6. For an IMSI-attached MS in GSM, the SGSN sends a GPRS Detach Indication message to the MSC/VLR, which deletes the association with the SGSN. Afterwards the MSC/VLR handles the paging and location update without involving the SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 26 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 5.4 Date Rev - AA Reference 7. The MS sends a Detach Accept message to the SGSN any time after step 1. 8. If the SGSN has requested the MS to reattach, the MS sends an Attach Request message. For information on the attach procedure, see Section 4 on page 9 . Implicit Detach The network detaches the MS implicitly without notifying it, either due to expiry of the configuration-dependent implicit detach timer which is started when the mobile reachable timer has expired, or due to an irrecoverable radio error causing a loss of the logical link. The subscriber’s mobility management context and PDP contexts are deleted from the SGSN, but the P-TMSI, P-TMSI signature, IMSI number, and the unused authentication data is kept. When combined procedures over the optional Gs interface is used, if required, the information in the MSC/VLR is updated at an implicit detach. 5.5 System Failure At system failure, due to an SGSN restart or a loss of connection between the SGSN and the HLR during subscriber data modification, the SGSN detaches the MS. The subscriber’s mobility management context and PDP contexts are deleted from the SGSN. When an SGSN belonging to an SGSN pool goes down, the failure is detected by the BSS Network Service Entity (NSE) for the inaccessible SGSN. Signaling from MSs served by the SGSN is thereafter distributed to other SGSNs in the SGSN pool. However, these SGSNs do not recognize the MSs, so the MSs are consequently forced to reattach. When an MS reattaches, it reattaches to a randomly selected SGSN in the pool and receives a new P-TMSI with an NRI value belonging to the selected SGSN. Thus, the MS is able to immediately reestablish its services independent of the recovery of the old SGSN. 6 Paging The Paging procedure is used for an MS in STANDBY_REACHABLE state. A successful Paging procedure changes the state of the mobility management context to READY, allowing the SGSN to forward data or signaling messages to the MS. 6.1 Paging at GPRS Downlink Transfer Paging is performed when the SGSN receives downlink PDU or signaling to an MS in the STANDBY_REACHABLE state, or through the SGSN when the MSC/VLR wants the MS to enter the READY state. A Paging Request Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 27 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference message is sent to the BSC belonging to the RA where the MS is currently registered. The current P-TMSI is used as identifier. 6.1.1 Traffic Case The GSM Paging procedure for GPRS downlink transfer is shown in Figure 11. MS BSC SGSN 1. Downlink PDU or Signaling 2. Paging Request 3. Paging Request 4. LLC Frame 5. LLC Frame Figure 11 6.2 GSM Paging Procedure for GPRS Downlink Transfer 1. The SGSN receives a downlink PDU or signaling for an MS in STANDBY state. 2. The SGSN sends a BSSGP Paging Request message, including IMSI number, P-TMSI, RA, and other parameters, to the BSC serving the MS. 3. The BSC pages the MS with one Paging Request message in each cell belonging to the addressed RA. 4. The MS responds with any single valid Logical Link Control (LLC) frame (that is, a Receive Ready or an Information frame). When responding, the MS changes the state to READY. 5. The BSC adds the Cell Global Identity, including the Routing Area Code (RAC) and Location Area Code (LAC) of the cell, and sends the LLC frame further to the SGSN which considers the LLC frame as an implicit paging response message. Smart Paging By using smart paging it is possible to reduce the signaling load generated by unsuccessful paging procedures in radio networks that have a massive paging load. Smart paging allows customization of the paging in the network through configurable parameters controlling timers and number of paging attempts. When configuring the smart paging restrictions it is important to consider the current network situation. Note: The smart paging handling of the paging over the Gb interface differs from the handling of the paging over the Iu interface. For Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 28 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference information on how the paging procedure over the Gb interface is handled, see Section 6.2.1 on page 28. For information on how the paging procedure over the Iu interface is handled, see GPRS Mobility Management for WCDMA Access. Smart paging allows configuration of the following properties: • The number of paging attempts using the current P-TMSI A high number of paging attempts using the current P-TMSI increases the probability to get a successful paging. • The number of paging attempts using the old P-TMSI Paging attempts based on the old P-TMSI are only possible when the old P-TMSI is available. • The time interval between the paging attempts A longer time interval between the paging attempts increases the possibility for the mobile to reach coverage. • The quarantine time until the next paging procedure can begin It is possible to gradually increase the time between the paging attempts. For more information, see Section 6.2.1.1 on page 29. 6.2.1 Paging Sequence, Gb Interface Paging on the Gb interface is initiated by downlink payload or control signaling. The first paging attempt is sent to the RA level using the current P-TMSI. By using smart paging, the load on the BSS can be decreased and overload of the BSS can be avoided. The procedure is described in Figure 12. Gb_N3313_Paging Gb_N3313_OldPtmsi downlink PDU Gb_RepeatPaging Gb_T3313_PagingTimer Figure 12 Paging Procedure, Gb Interface The following parameters (used for smart paging configuration) can be configured using the set_nodeprop CLI command: Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 29 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) • Gb_N3313-Paging • Gb_N3313-OldPtmsi • Gb_T3313-PagingTimer • Gb_RepeatPagingStep • Gb_Repeat_paging Date Rev - AA Reference For a description on each parameter, see Parameter Description. 6.2.1.1 Gradually Increased Quarantine Time, Gb Interface During the time configured in the paging timers the MS is unreachable and a new paging process triggered by downlink payload cannot be initiated during this time, also referred to as the quarantine time. Smart paging introduces a gradually increasing quarantine time that can be used to reduce the paging load by less frequently paging. The paging using gradually increasing quarantine time is further described in Figure 13. The quarantine time is increased as follows: T1 Gb_Repeat_paging T2 T1 + 1 * Gb_RepeatPagingStep T3 T1 + 2 * Gb_RepeatPagingStep T4 T1 + 3 * Gb_RepeatPagingStep The paging procedure is repeated using this pattern until the MS responds or the mobile reachable timer expires. If all retransmissions of the Paging Request message fail the paging is rejected. T1 T2 T3 T4 downlink PDU Figure 13 Gradually Increased Quarantine Time 6.3 CS Paging over the Gs Interface When the Gs interface between the SGSN and the MSC/VLR is used and an MS is both IMSI and GPRS attached, the MSC/VLR performs paging for CS services over the SGSN. The response from the MS is then transferred directly from the BSC to the MSC/VLR. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 30 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference The SGSN supports interworking with MSC in pool for CS services when using combined procedures over the Gs interface. More information about this feature can be found in SGSN Support for MSC in Pool. 6.3.1 Traffic Case The Paging procedure for CS paging over the Gs interface is shown in Figure 14. MS BSC SGSN MSC/VLR 1. Paging Request 2. Paging Request 3. Paging Request 4. Paging Response 5. SCCP Connection Request (Paging Response) Figure 14 CS Paging Procedure 1. The SGSN receives a Paging Request message from the MSC/VLR. 2. The SGSN sends a BSSGP Paging Request message, including IMSI number, VLR TMSI, RA, and other parameters, to the BSC serving the MS. If Global CN-ID is received in the Paging Request message from the MSC/VLR, it is included in the Paging Request message from the SGSN to the BSC. 7 3. The BSC translates the incoming BSSGP Paging Request message into a radio Paging Request message and pages the MS with one Paging Request message in each cell belonging to the addressed RA. 4. When receiving a Paging Request message for a CS service, the MS responds to the request with a Paging Response message to the BSC. 5. The BSC sends a request directly to the MSC/VLR to establish a Signaling Connection Control Part (SCCP) connection. Cell Update A GSM MS in the READY state, moving between cells within the same SGSN RA, updates the SGSN of its location by sending any Logical Link Control (LLC) Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 31 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference frame containing cell information. For MSs supporting the Cell Notification procedure, cell update is performed without resetting the ready timer. Note that in the STANDBY state, an MS may move between cells within the same RA without sending a cell update. Before sending traffic to an MS in the STANDBY state, a Paging procedure (see Section 6 on page 26) must be performed to determine in which cell the MS is located. 8 Routing Area Update The Routing Area Update (RAU) procedure updates the SGSN with information on the RA in which an MS is located. The procedure is started by the MS when it enters a new RA, when the periodic RAU timer has expired, or to resume service if the current BSC does not support the Service Resume procedure. The access modes GSM and WCDMA Systems must be configured to use different RAs. Parts of an RAU procedure is performed when PS Handover or IRAT PS Handover is completed. For more information see Section 10.1 on page 54, or Inter-System Mobility Management. During RAU the SGSN checks if the MS local time is changed. If the SGSN identifies a change, it will send the updated local time to the MS. The optional home zone configuration enables the SGSN to send an Update PDP Context Request whenever there is a home zone boundary crossing regardless of whether it is due to an Intra- or Inter RAU. The PDP Context Request will include the Radio Access Technology (RAT) type. The RAT type sent can be configured to indicate GAN or GERAN. For more information about home zone charging differentiation, see Section 18 on page 69. The configuration connected to home zone charging differentiation is described in Features and Functions Management. Both Intra-SGSN RAU and Inter-SGSN RAU are supported within and between PLMNs. For more information on Inter-SGSN RAU, see Inter-System Mobility Management. See Security for information on the authentication procedure and selective authentication. A GSM SGSN supports combined RA/LA update, where the Gs interface is used for the CS signaling between the SGSN and the MSC/VLR. The GSM SGSN can be configured to include the Force To Standby flag in the Routing Area Update Accept and Reject messages to the MS by setting the Gb_ForceToStandbyForInactiveSubscribers parameter. This flag requests the MS to turn off its ready timer and thereby avoid cell updates. At periodic RAUs, the Force To Standby flag is set in the Routing Area Update Accept messages, even if PDP contexts are active. At inter- and intra-SGSN RAU, the Force To Standby flag is set in Routing Area Update Accept and Reject messages if no PDP contexts are active. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 32 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference The SGSN supports MSs that do not comply with the 3GPP standards regarding optional IEs. During a RAU procedure a non-3GPP compliant MS may not be able to handle the Packet Data Protocol (PDP) context status IE in the Routing Area Update message. This leads to problems at attach and can ultimately cause the MS to reboot. In order to handle this the SGSN retransmits the RAU message up to five times. If the problem persists, the SGSN alters the message and excludes some optional IEs known to cause problems with non-3GPP compliant MSs. The list of IEs that are omitted from the altered message is kept hardcoded in the SGSN and can only be changed by altering the actual code. 8.1 Intra-SGSN RAU An MS moving between RAs controlled by the same SGSN performs an intra-SGSN RAU. When the periodic RAU timer expires, a periodic RAU is performed. As long as an MS remains in the same SGSN pool service area, a RAU will normally be an intra-SGSN RAU. If a Routing Area Update Complete message from the MS is not received after a time specified by the RAU complete timer, the SGSN retransmits the Routing Area Update Accept message. After the fourth retransmission the RAU procedure is concluded. The following sections describe the Intra-SGSN RAU procedures using the Gn or S4 interface. 8.1.1 Traffic Case for Intra-SGSN RAU using Gn Interface The Intra-SGSN RAU procedure using the Gn interface is shown in Figure 15. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 33 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA SGSN MS HLR Reference MSC/VLR GGSN 1. Routing Area Update Request 2. Security functions 3. Location Update Request 4. Location Update Accept 5. Update PDP Context Request 6. Update PDP Context Response 7. Routing Area Update Accept 8. Altered Routing Area Update Accept 9. Routing Area Update Complete 10. TMSI Reallocation Complete 11. GMM Information compulsory communication conditional or optional communication Figure 15 Intra-SGSN RAU Procedure using Gn Interface The following steps describe the Intra-SGSN RAU procedure using the Gn interface: 1. The MS sends a Routing Area Update Request message to the SGSN. The Routing Area Update Request message includes information on the old RA and old P-TMSI, and if it is a RAU following a change of RA or a periodic RAU. 2. Security functions may be performed. Selective authentication applies using the parameter Gb_SelectiveAuthenticationFrequency . The SGSN validates the MS’s presence in the new RA. If the check fails (for example, wrong P-TMSI signature) the SGSN authenticates the MS. If the authentication also fails, the SGSN logs the error and sends a Routing Area Update Reject message. If all checks are successful, the SGSN updates the mobility management context for the MS. A new P-TMSI, including NRI if the SGSN is a pool member and P-TMSI signature, is allocated. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 34 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 3. If the optional Gs interface is used, and if the MS requests a RAU and if the location area is changed when changing RA, the SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 4. As a response to the previous step the MSC/VLR number is stored in the SGSN through the reception of the Location Update Accept message. 5. If a home zone boundary crossing has occurred the SGSN sends an Update PDP Context Request message including RAT type to the GGSN. 6. The GGSN responds with an Update PDP Context Response message to the SGSN. 7. A Routing Area Update Accept message is returned to the MS. The Routing Area Update Accept message includes a request to the MS to share its IRAT PS Handover capability. This if the PS Handover feature is activated. It also includes the P-TMSI (including the NRI if the SGSN is a pool member). The Routing Area Update Accept message can also include a list of equivalent PLMNs, if such a list has been defined. If the MS is situated in an RA defined as a part of a home zone, the Routing Area Update Accept does not include the IE Cell Notification. 8. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions the SGSN sends an altered Routing Area Update message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 9. The MS acknowledges the new P-TMSI with a Routing Area Update Complete message. If requested the IRAT PS Handover capability is included in the message. 10. If the optional Gs interface is used, and if the MSC/VLR has allocated a new TMSI for the MS, the SGSN sends a TMSI Reallocation Complete message to the MSC/VLR over the optional Gs interface. 11. The SGSN sends network information to the MS in the GMM Information message. The conditions for when this will be included are either if the MS has changed PLMN since last RAU and the GMM Information shall be sent (dependent configuration parameter Gb_SendGmmInfo (GSM)), or if configuration indicates that time zone information shall be sent with GMM Information and the MS time zone has changed since previous sending of GMM Information (because the MS has moved into another time zone, or there has been a change between summer and winter time). This may provide local time to the MS. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 35 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 8.1.2 Date Rev - AA Reference Traffic Case for Intra-SGSN RAU without SGW Relocation using S4 Interface The Intra-SGSN RAU without the SGW Relocation procedure using the S4 interface is shown in Figure 16. MS SGSN MSC/ VLR SGW DNS PGW HLR 1. Routing Area Update Request 2. Security Functions 3. Serving Gateway Reselection 4. Location Update Request 5. Location Update Accept 6. Modify Bearer Request 7. Modify Bearer Request 8. Modify Bearer Response 9. Modify Bearer Response 10. Routing Area Update Accept 11. Altered Routing Area Update Accept 12. Routing Area Update Complete 13. TMSI Reallocation Complete Figure 16 Intra-SGSN RAU without SGW Relocation using S4 Interface The following steps describe the Intra-SGSN RAU without the SGW Relocation procedure using the S4 interface: 1. The MS sends a Routing Area Update Request message to the SGSN. The Routing Area Update Request message includes information on the old RA and old P-TMSI, and if it is a RAU following a change of RA or a periodic RAU. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 36 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 2. Date Rev - AA Reference Security functions may be performed. Selective authentication applies using the parameter Gb_SelectiveAuthenticationFrequency. The SGSN validates the presence of the MS in the new RA. If the check fails (for example, wrong P-TMSI signature) the SGSN authenticates the MS. If the authentication also fails, the SGSN logs the error and sends a Routing Area Update Reject message. If all checks are successful, the SGSN updates the mobility management context for the MS. A new P-TMSI, including NRI if the SGSN is a pool member and P-TMSI signature, is allocated. 3. The new SGSN checks if a change of SGW is necessary through the DNS query. In this case, the SGW is not relocated. 4. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI RAU and if the location area is changed when changing RA, the SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 5. As a response to the previous step, the MSC/VLR number is stored in the SGSN through the reception of the Location Update Accept message. 6. If a home zone boundary crossing has occurred, the SGSN sends a Modify Bearer Request message to the SGW to update the EPS Bearer contexts of each PDN connection. 7. The SGW sends a Modify Bearer Request message to the PGW to update the EPS Bearer contexts. 8. The PGW acknowledges the updates of the EPS Bearer contexts by sending a Modify Bearer Response message to the SGW. 9. The SGW acknowledges the updates of the EPS Bearer contexts by sending a Modify Bearer Response message to the SGSN. 10. A Routing Area Update Accept message is returned to the MS. The Routing Area Update Accept message includes the P-TMSI (including the NRI if the SGSN is a pool member). The Routing Area Update Accept message can also include a list of equivalent PLMNs, if such a list has been defined. If the MS is situated in an RA defined as a part of a home zone, the Routing Area Update Accept message does not include the IE Cell Notification. 11. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions, the SGSN sends an altered Routing Area Update Accept message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 12. The MS acknowledges the new P-TMSI with a Routing Area Update Complete message. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 37 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 13. If the optional Gs interface is used, and if the MSC/VLR has allocated a new TMSI for the MS, the SGSN sends a TMSI Reallocation Complete message to the MSC/VLR over the optional Gs interface. 8.1.3 Traffic Case for Intra-SGSN RAU with SGW Relocation using S4 Interface The Intra-SGSN RAU with the SGW Relocation procedure using the S4 interface is shown in Figure 17. MS SGSN MSC/ VLR Old SGW New SGW DNS 1. Routing Area Update Request 2. Security Functions 3. Serving Gateway Reselection 4. Location Update Request 5. Location Update Accept 6. Create Session Request 7. Modify Bearer Request 8. Modify Bearer Response 9. Create Session Response 10. Delete Session Request 11. Delete Session Response 12. Routing Area Update Accept 13. Altered Routing Area Update Accept 14. Routing Area Update Complete 15. TMSI Reallocation Complete Figure 17 Intra-SGSN RAU with SGW Relocation using S4 Interface PGW HLR Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 38 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference The following steps describe the Intra-SGSN RAU with the SGW Relocation procedure using the S4 interface: 1. The MS sends a Routing Area Update Request message to the SGSN. The Routing Area Update Request message includes information on the old RA and old P-TMSI, and if it is a RAU following a change of RA or a periodic RAU. 2. Security functions may be performed. Selective authentication applies using the parameter Gb_SelectiveAuthenticationFrequency. The SGSN validates the presence of the MS in the new RA. If the check fails (for example, wrong P-TMSI signature) the SGSN authenticates the MS. If the authentication also fails, the SGSN logs the error and sends a Routing Area Update Reject message. If all checks are successful, the SGSN updates the mobility management context for the MS. A new P-TMSI, including NRI if the SGSN is a pool member and P-TMSI signature, is allocated. 3. An SGW relocation procedure is performed. The new SGSN checks if a change of SGW is necessary and uses DNS in order to find a new one. 4. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI RAU and if the location area is changed when changing RA, the SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 5. As a response to the previous step the MSC/VLR number is stored in the SGSN through the reception of the Location Update Accept message. 6. The SGSN sends a Create Session Request message to the new SGW to create a new session of each PDN connection. 7. The new SGW sends a Modify Bearer Request message to the PGW to update the EPS Bearer contexts. 8. The PGW acknowledges the updates of the EPS Bearer contexts by sending a Modify Bearer Response message to the new SGW. 9. The new SGW acknowledges the creation of a new session by sending a Create Session Response message to the SGSN. 10. The SGSN sends a Delete Session Request message to the old SGW to remove the old session. 11. The old SGW acknowledges the removal of the old session by sending a Delete Session Response message to the SGSN. 12. A Routing Area Update Accept message is returned to the MS. The Routing Area Update Accept message includes the P-TMSI (including the NRI if the SGSN is a pool member). The Routing Area Update Accept message can also include a list of equivalent PLMNs, if such a list has been defined. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 39 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference If the MS is situated in an RA defined as a part of a home zone, the Routing Area Update Accept does not include the IE Cell Notification. 13. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions, the SGSN sends an altered Routing Area Update Accept message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 14. The MS acknowledges the new P-TMSI with a Routing Area Update Complete message. 15. If the optional Gs interface is used, and if the MSC/VLR has allocated a new TMSI for the MS, the SGSN sends a TMSI Reallocation Complete message to the MSC/VLR over the optional Gs interface. 8.1.4 RAU Not Accepted If the RAU request is not accepted either the RAU procedure is aborted without notifying the MS or a Routing Area Update Reject message including a cause for the rejection is sent to the MS. The RAU is silently aborted when the response to an identity check is negative, for example it can be silently aborted if the MS is not accepted during authentication. A Routing Area Update Reject message is sent in the following cases: • The RAI previously used is defined as a cooperating RA but the received P-TMSI is not known to the cooperating SGSN • The SGSN is congested • Authentication fails • A protocol error in the Routing Area Update Request message is detected • An update of location is not accepted by the HLR • The MS is in the IDLE state • The MS tries to perform a RAU in a PLMN where GPRS services are not allowed In addition, if roaming for an MS is restricted according to the Roaming Restriction (see Section 14.1 on page 67) and the MS tries to perform a RAU to a restricted LA, the RAU is rejected with a Routing Area Update Reject message. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 40 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 8.2 Date Rev - AA Reference Inter-SGSN RAU An MS moving between RAs controlled by different SGSNs performs an inter-SGSN RAU. At inter-SGSN RAU, the optional Gf interface enables the new SGSN to check the legality of an MS by sending an IMEI check request to the EIR. If the SGSN is connected to multiple EIRs, the IMEI check request is sent to the appropriate EIR based on the IMSI number series or to the default EIR. For more information about the IMEI Check feature, see Security. An MS attached to an SGSN which is a member of a pool can perform an inter-SGSN RAU to an SGSN outside the pool. If the SGSN outside the pool is able to identify the pool member, referred to as the old SGSN, through a Domain Name System (DNS) query including an NRI, it sends an SGSN Context Request message or a Context Request message directly to the identified SGSN holding the contexts of the MS. If not, the SGSN outside the pool sends an SGSN Context Request message or a Context Request message to the default SGSN in the pool serving the RA in question. If necessary, the default SGSN relays the request message further to the appropriate SGSN which responds directly to the SGSN outside the pool. The following sections describe the Inter-SGSN RAU procedures using the Gn or S4 interface. For information about the RAU procedure from the MME to the S4-SGSN using the S3 interface, see Inter-System Mobility Management 8.2.1 Traffic Case for Inter-SGSN RAU using Gn Interface The Inter-SGSN RAU procedure using the Gn interface is shown in Figure 18. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS 41 ( 76 ) No. NEW OLD SGSN SGSN Date Rev - AA GGSN HLR Reference MSC/VLR EIR 1. Routing Area Update Request 2. SGSN Context Request 3. SGSN Context Response 4. Security functions 5.IMEI Check 6. SGSN Context Acknowledge 7. Update PDP Context Request 8. Update PDP Context Response 9. Update Location 10. Cancel Location 11. Cancel Location Ack 12. Insert Subscriber Data 13. Insert Subscriber Data Ack 14. Update Location Ack 15. Location Update Request 16. Location Update Accept 17. Routing Area Update Accept 18. Altered Routing Area Update Accept 19. Routing Area Update Complete 20. TMSI Reallocation Complete 21. GMM Information compulsory communication conditional or optional communication Figure 18 Inter-SGSN RAU Procedure using Gn Interface The following steps describe the Inter-SGSN RAU procedure using the Gn interface: 1. The MS sends a Routing Area Update Request message to the new SGSN. The Routing Area Update Request message includes information on the old RA. The SGSN analyzes the received RA identification and starts the Inter-SGSN RAU procedure if the old RA is controlled by a cooperating SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 42 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 2. The new SGSN sends an SGSN Context Request message to the old SGSN to get the mobility management and PDP contexts for the MS. 3. The old SGSN validates the old P-TMSI and responds with an SGSN Context Response message containing the APN-OI, IMSI number, mobility management context, and possible PDP contexts for the MS. 4. Security functions may be performed. Selective authentication applies using the parameter GbIu_InterSgsnSelectiveAuthenticationF requency. 5. If the optional Gf interface is used and the IMEI Check feature is enabled for GSM radio access, the IMEI is checked by sending an IMEI check request to the EIR. 6. The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old SGSN sets a timer after which it removes the mobility management and PDP contexts for the MS. 7. The new SGSN sends an Update PDP Context Request message for each PDP context to the appropriate GGSN. The RAI of the new SGSN where the MS is registered, including MCC and MNC, is then forwarded to the GGSN. Also, when using GPRS Tunneling Protocol version 1 (GTPv1) and the MS is within a home zone, the RAT of the MS is forwarded to the GGSN. 8. The GGSNs update their PDP context fields and return Update PDP Context Response messages. 9. The new SGSN informs the HLR about the change of SGSN by sending an Update Location message to the HLR. 10. The HLR sends a Cancel Location message to the old SGSN. 11. The old SGSN acknowledges the location canceling with a Cancel Location Ack message. 12. The HLR sends an Insert Subscriber Data message to the new SGSN. 13. The new SGSN validates the presence of the MS in the new RA. If all checks are successful, the new SGSN returns an Insert Subscriber Data Ack message to the HLR. 14. The HLR acknowledges the Update Location message by sending an Update Location Ack message to the new SGSN. 15. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI RAU, the SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 43 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 16. When the MSC/VLR number is stored, an association is created between the SGSN and the MSC/VLR through the Location Update Accept message. 17. The new SGSN responds to the MS with a Routing Area Update Accept message, including a new P-TMSI with an NRI in case the new SGSN is a pool member. It also includes a request to the MS to share its IRAT PS Handover capability if the PS Handover feature is activated. The Routing Area Update Accept message can also include a list of equivalent PLMNs, if such a list has been defined. If the MS is situated in an RA defined as a part of a home zone, the Routing Area Update Accept does not include the IE Cell Notification. 18. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions the SGSN sends an altered Routing Area Update message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 19. The MS acknowledges the new P-TMSI with a Routing Area Update Complete message. If requested the IRAT PS Handover capability is included in the message. 20. If the optional Gs interface is used, and if the MSC/VLR has allocated a new TMSI for the MS the SGSN sends a TMSI Reallocation Complete message to the MSC/VLR. 21. Based on the optional configuration of Gb_SendGmmInfo (GSM), the operator can choose to configure the SGSN to send network information to the MS in the GMM Information message. This may provide local time to the MS. 8.2.2 Traffic Case for Inter-SGSN RAU without SGW Relocation using S4 Interface The Inter-SGSN RAU without the SGW Relocation procedure using the S4 interface is shown in Figure 19. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS New SGSN Old SGSN MSC/ VLR DNS Date Rev - AA SGW PGW Reference HLR 1. Routing Area Update Request 2. Find old SGSN 3. Context Request 4. Context Response 5. Security Functions 6. IMEI Check 7. Serving Gateway Reselection 8. Context Acknowledge 9. Modify Bearer Request 10. Modify Bearer Request 11. Modify Bearer Response 12. Modify Bearer Response 13. Update Location 14. Cancel Location 15. Cancel Location Acknowledge 16. Insert Subscriber Data 17. Insert Subscriber Data Acknowledge 18. Update Location Acknowledge 19. Location Update Request 20. Location Update Accept 21. Routing Area Update Accept 22. Altered Routing Area Update Accept 23. Routing Area Update Complete 24. TMSI Reallocation Complete EIR 44 ( 76 ) Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Figure 19 45 ( 76 ) No. Date Rev - AA Reference Inter-SGSN RAU without SGW Relocation using S4 Interface The following steps describe the Inter-SGSN RAU without the SGW Relocation procedure using the S4 interface: 1. The MS sends a Routing Area Update Request message to the new SGSN. The Routing Area Update Request message includes information on the old RA. The new SGSN analyzes the received RA identification and starts the Inter-SGSN RAU procedure if the old RA is controlled by a cooperating SGSN. 2. The new SGSN queries the DNS for the IP address of the old SGSN. If the old SGSN is a Gn-SGSN, refer to the traffic case described in Section 8.2.1 on page 40. 3. If the old SGSN is an S4-SGSN, the new SGSN sends a Context Request message to the old SGSN to get the Mobility Management and EPS Bearer contexts for the MS. If the old SGSN is a Gn-SGSN, refer to the traffic case described in Section 8.2.1 on page 40. 4. If the old SGSN is an S4-SGSN, it validates the old P-TMSI and responds with a Context Response message containing the IMSI number, Mobility Management and possible EPS Bearer contexts for the MS. 5. Security functions may be executed. Selective authentication applies using the parameter GbIu_InterSgsnSelectiveAuthenticationFrequency. 6. If the optional Gf interface is used and an EIR identity check is enabled through the configuration of the Gf_IdentityCheckEnable parameter, the IMEI is checked. 7. The new SGSN checks if a change of SGW is necessary through the DNS query. In this case, the SGW is not relocated. 8. If the old SGSN is an S4-SGSN, the new SGSN sends a Context Acknowledge message to the old SGSN. The old SGSN sets a timer after which it removes the Mobility Management and EPS Bearer contexts for the MS. 9. The new SGSN sends a Modify Bearer Request message to the SGW to update the EPS Bearer contexts of each PDN connection. 10. The SGW sends a Modify Bearer Request message to the PGW to update the EPS Bearer contexts. 11. The PGW acknowledges the updates of the EPS Bearer contexts by sending a Modify Bearer Response message to the SGW. 12. The SGW acknowledges the updates of the EPS Bearer contexts by sending a Modify Bearer Response message to the new SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 46 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 13. The new SGSN informs the HLR about the change of SGSN by sending an Update Location message to the HLR. 14. The HLR sends a Cancel Location message to the old SGSN. 15. The old SGSN acknowledges the location cancellation with a Cancel Location Acknowledge message. 16. The HLR sends an Insert Subscriber Data message to the new SGSN. 17. The new SGSN validates the presence of the MS in the new RA. If all checks are successful, the new SGSN returns an Insert Subscriber Data Acknowledge message to the HLR. 18. The HLR acknowledges the Update Location message by sending an Update Location Acknowledge message to the new SGSN. 19. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI RAU, the new SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 20. When the MSC/VLR number is stored, an association is created between the new SGSN and the MSC/VLR through the Location Update Accept message. 21. The new SGSN responds to the MS with a Routing Area Update Accept message, including a new P-TMSI with an NRI in case the new SGSN is a pool member. The Routing Area Update Accept message can also include a list of equivalent PLMNs, if such a list has been defined. If the MS is situated in an RA defined as a part of a home zone, the Routing Area Update Accept does not include the IE Cell Notification. 22. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions, the new SGSN sends an altered Routing Area Update Accept message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 23. The MS acknowledges the new P-TMSI with a Routing Area Update Complete message. 24. If the optional Gs interface is used, and if the MSC/VLR has allocated a new TMSI for the MS, the new SGSN sends a TMSI Reallocation Complete message to the MSC/VLR. 8.2.3 Traffic Case for Inter-SGSN RAU with SGW Relocation using S4 Interface The Inter-SGSN RAU with the SGW Relocation procedure using the S4 interface is shown in Figure 20. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS 47 ( 76 ) No. New SGSN Old SGSN MSC/ VLR New SGW Date Rev - AA DNS Old SGW 1. Routing Area Update Request 2. Find old SGSN 3. Context Request 4. Context Response 5. Security Functions 6. IMEI Check 7. Serving Gateway Reselection 8. Context Acknowledge 9. Create Session Request 10. Modify Bearer Request 11. Modify Bearer Response 12. Create Session Response 13. Update Location 14. Cancel Location 15. Cancel Location Acknowledge 16. Insert Subscriber Data 17. Insert Subscriber Data Acknowledge 18. Update Location Acknowledge 19. Location Update Request 20. Location Update Accept 21. Delete Session Request 22. Delete Session Response 23. Routing Area Update Accept 24. Altered Routing Area Update Accept 25. Routing Area Update Complete 26. TMSI Reallocation Complete Reference PGW HLR EIR Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Figure 20 48 ( 76 ) No. Date Rev - AA Reference Inter-SGSN RAU with SGW Relocation using S4 Interface The following steps describe the Inter-SGSN RAU with the SGW Relocation procedure using the S4 interface: 1. The MS sends a Routing Area Update Request message to the new SGSN. The Routing Area Update Request message includes information on the old RA. The new SGSN analyzes the received RA identification and starts the Inter-SGSN RAU procedure if the old RA is controlled by a cooperating SGSN. 2. The new SGSN queries the DNS for the IP address of the old SGSN. If the old SGSN is a Gn-SGSN, refer to the traffic case described in Section 8.2.1 on page 40. 3. If the old SGSN is an S4-SGSN, the new SGSN sends a Context Request message to the old SGSN to get the Mobility Management and EPS Bearer contexts for the MS. If the old SGSN is a Gn-SGSN, refer to the traffic case described in Section 8.2.1 on page 40. 4. If the old SGSN is an S4-SGSN, it validates the old P-TMSI and responds with a Context Response message containing the IMSI number, Mobility Management and possible EPS Bearer contexts for the MS. 5. Security functions may be executed. Selective authentication applies using the parameter GbIu_InterSgsnSelectiveAuthenticationFrequency. 6. If the optional Gf interface is used and an EIR identity check is enabled through the configuration of the Gf_IdentityCheckEnable parameter, the IMEI is checked. 7. An SGW relocation procedure is performed. The new SGSN checks if a change of SGW is necessary and uses DNS in order to find a new one. 8. If the old SGSN is an S4-SGSN, the new SGSN sends a Context Acknowledge message to the old SGSN. The old SGSN sets a timer after which it removes the Mobility Management and EPS Bearer contexts for the MS. 9. The new SGSN sends a Create Session Request message to the new SGW to create a new session of each PDN connection. 10. The new SGW sends a Modify Bearer Request message to the PGW to update the EPS Bearer contexts. 11. The PGW acknowledges the updates of the EPS Bearer contexts by sending a Modify Bearer Response message to the new SGW. 12. The new SGW acknowledges the creation of a new session by sending a Create Session Response message to the new SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 49 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 13. The new SGSN informs the HLR about the change of SGSN by sending an Update Location message to the HLR. 14. The HLR sends a Cancel Location message to the old SGSN. 15. The old SGSN acknowledges the location cancellation with a Cancel Location Acknowledge message. 16. The HLR sends an Insert Subscriber Data message to the new SGSN. 17. The new SGSN validates the presence of the MS in the new RA. If all checks are successful, the new SGSN returns an Insert Subscriber Data Acknowledge message to the HLR. 18. The HLR acknowledges the Update Location message by sending an Update Location Acknowledge message to the new SGSN. 19. If the optional Gs interface is used, and if the MS requests a combined GPRS and IMSI RAU, the new SGSN starts the Location Update procedure by sending the Location Update Request message to the selected MSC/VLR. 20. When the MSC/VLR number is stored, an association is created between the new SGSN and the MSC/VLR through the Location Update Accept message. 21. The old SGSN sends a Delete Session Request message to the old SGW to remove the old session. 22. The old SGW acknowledges the removal of the old session by sending a Delete Session Response message to the old SGSN. 23. The new SGSN responds to the MS with a Routing Area Update Accept message, including a new P-TMSI with an NRI in case the new SGSN is a pool member. The Routing Area Update Accept message can also include a list of equivalent PLMNs, if such a list has been defined. If the MS is situated in an RA defined as a part of a home zone, the Routing Area Update Accept does not include the IE Cell Notification. 24. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions, the new SGSN sends an altered Routing Area Update Accept message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 25. The MS acknowledges the new P-TMSI with a Routing Area Update Complete message. 26. If the optional Gs interface is used, and if the MSC/VLR has allocated a new TMSI for the MS, the new SGSN sends a TMSI Reallocation Complete message to the MSC/VLR. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 50 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 8.2.4 Date Rev - AA Reference Traffic Case for SGSN Pool Figure 21 shows how the signaling is handled between the SGSN pool members at an SGSN Context Request or a Context Request. However, relaying between SGSNs in the pool can be avoided when directly pointing out the SGSN holding the contexts through a DNS query including both NRI and RAI. See SGSN Pool for more information. This traffic case substitutes the first three steps in the Inter-SGSN RAU procedures described in Section 8.2.1 on page 40, Section 8.2.2 on page 43 and Section 8.2.3 on page 46. The continuation of the Inter-SGSN RAU works as for a non-pooled SGSN, see Section 8.2.1 on page 40, Section 8.2.2 on page 43 and Section 8.2.3 on page 46. SGSN Pool New Default SGSN SGSN Old SGSN 1. Routing Area Update Request 2. SGSN Context Request/Context Request 3. SGSN Context Request/Context Request 4. SGSN Context Response/Context Response compulsory communication conditional or optional communication Figure 21 SGSN Context Request/Context Request for SGSN Pool 1. The MS sends a Routing Area Update Request message to the new SGSN, which is outside the SGSN pool. The Routing Area Update Request message includes information on the old RA. The SGSN analyzes the received RA identification and starts the Inter-SGSN RAU procedure if the old RA is controlled by a cooperating SGSN. 2. The new SGSN sends an SGSN Context Request message or a Context Request message to the default SGSN in the SGSN pool, that is, to the cooperating SGSN, which is supposed to be the old SGSN. 3. If the default SGSN is not the same as the old SGSN, the default SGSN forwards the request to the old SGSN using GPRS Tunneling Protocol (GTP) relay. 4. The old SGSN handles the request and sends an SGSN Context Response message or a Context Response message to the new SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 51 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 8.2.5 Date Rev - AA Reference RAU Not Accepted If the RAU procedure is not accepted, either the RAU procedure is aborted or ignored without notifying the MS, or a Routing Area Update Reject message including a cause for the rejection is sent to the MS. The RAU is silently aborted when the response on an identity check is negative, for example, it can be silently aborted if the MS is not accepted during authentication. A Routing Area Update Reject message is sent in the following cases: • The MS is unknown to the new network, for example, due to that the RAI previously used is not defined as a cooperating RA in the new SGSN or in the DNS. • The IMSI analysis fails. • The SGSN is congested. • Authentication fails. • A protocol error in the Routing Area Update Request message is detected. • The MS tries to perform a RAU to a PLMN where GPRS services are not allowed. In addition, if roaming for an MS is restricted according to the Roaming Restrictions (see Section 14.1 on page 67) and the MS tries to perform a RAU to a restricted LA, the RAU is rejected with a Routing Area Update Reject message. If a Routing Area Update Complete message from the MS is not received after a time specified by the RAU complete timer, the SGSN retransmits the Routing Area Update Accept message. After the fourth retransmission the RAU procedure is concluded and both old and new P-TMSIs are considered valid. 8.3 Periodic RAU A periodic RAU is similar to an intra-SGSN RAU. GPRS-attached MSs residing in an RA perform periodic RAUs at regular intervals. The time between periodic RAUs is specified by a periodic RAU timer applicable to all the MSs in the RA. The timer is sent from the SGSN to the MS in the Routing Area Update Accept or Attach Accept message. The periodic RAU timer in the MS is stopped when a PDU is sent and the state is set to READY. It is then reset and started when the state returns to STANDBY_REACHABLE. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 52 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 9 Date Rev - AA Reference Inter-BSC NACC Using RIM Transfer Inter-BSC Network Assisted Cell Change (NACC) can be performed when an MS moves between cells served by different BSCs. With this procedure, the MS is provided with system information concerning the new cell while still remaining in the old cell which reduces the radio outage time at cell reselection. To perform Inter-BSC NACC, the optional RAN Information Management (RIM) procedure, which is used for transfer of radio network information between SGSNs and BSCs, is required to transfer relevant system information between the involved BSCs. The source BSC can initiate the Inter-BSC NACC procedure when an MS is about to change cells. System information, referred to as NACC information, is then included in containers as part of transparent RIM messages. The messages are sent transparently through the source SGSN to the target BSC identified by RAI and Cell-Identity (Cell-ID). If the target BSC is not served by the source SGSN, involvement of a cooperating SGSN is required and the procedure can be referred to as Inter-SGSN Inter-BSC NACC. In that case, the source SGSN uses the RAI to identify the target SGSN, and the RIM messages are transferred transparently through both SGSNs to the target BSC. For more information on cooperating SGSNs, see Section 11 on page 65. Thereafter, additional NACC information is included in RIM messages and transferred from the target BSC to the source BSC through the involved SGSNs. 9.1 Traffic Case The Inter-BSC NACC procedure is shown in Figure 22. Source Source Target Target BSC SGSN SGSN BSC 1. RIM Message 2. RIM Message Relay 3. RIM Message Relay RIM Message RIM Message 4. RIM Message Figure 22 Inter-BSC NACC Procedure The following steps describe the Inter-BSC NACC procedure: 1. The source BSC stores NACC information in a RIM message, and sends the message to the source SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 53 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 10 Date Rev - AA Reference 2. The source SGSN extracts the identity of the target BSC from the transparent RIM message, and forwards the content of the message to the BSC in question. If the BSCs are served by different SGSNs, the RIM message is transferred through the SGSN serving the target BSC. 3. The target BSC includes additional NACC information in a RIM message and sends it to the SGSN. If the BSCs are served by different SGSNs, the RIM message is relayed to the source SGSN. 4. The source SGSN forwards the RIM message to the source BSC. Handover Optionally supported in the SGSN, the PS Handover (GSM)/ IRAT PS Handover feature provides real-time packet-switched traffic with strict QoS requirements on low latency and packet loss. Handover reduces the service interruption of the payload at cell change, compared to cell reselection. Handover also enables bi-casting of downlink user plane data in order to reduce packet loss at cell-change. Handover functionality must be supported in the MS, RAN, and SGSN. The Handover procedure is initiated by the RAN and is used to handover an MS with one or more active Packet Flow Contexts (PFCs) or RABs from a source cell to a target cell. Handover is only initiated for MSs running payload, that is for MSs in the READY state. The Handover procedure is divided into two phases, the preparation phase and the execution phase. The preparation phase, where the MS still is in the source cell, includes the following steps: • Allocation of resources in the target network and target RAN prior to ordering the MS to move to target cell. • Restriction and admission control is performed. The controls checks the license activation, Access Restriction activation, and if the MS is allowed in the target RA. The execution phase starts when preparation phase is finished and includes the following steps: • Bi-casting by the old SGSN of the received downlink packets both to the source RAN, new SGSN (if Inter SGSN Handover) and to the target RAN as soon as radio resources are reserved in the target RAN. • Command sent by the source RAN to order the MS to handover to the target cell. • Notification by the MS of its presence in the target cell on the allocated radio resources. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 54 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference • Redirection by the SGSN of the downlink packets to the target RAN alone. • Release of the resources on the source side including Packet Flows Contexts or RABs and radio resources. Handover may be performed between cells within the same RAT, that is PS Handover, or between cells belonging to different RAT, that is IRAT PS Handover. For more information on IRAT PS Handover, see Inter-System Mobility Management. The support for non-3GPP compliant MSs enables the SGSN to handle MSs that do not comply with the 3GPP standards regarding optional information elements. For example, a Non 3GPP compliant MS may not be able to handle the information element PDP context status in the Routing Area Update message. This leads to problems at attach and can ultimately cause the MS to reboot. In order to handle this the SGSN retransmits the Routing Area Update message up to five times, but after a configurable number of times, the SGSN alters the message and excludes some optional information elements known to cause problems with non-3GPP compliant MSs. The list of information elements that are omitted from the altered message is predefined in the SGSN. 10.1 PS Handover The PS Handover procedure is used to handover an MS with one or more active PFCs from a source cell to a target cell. The source and target cells can be located within the same BSS (Intra-BSS PS Handover), different BSSs within the same SGSN (Inter-BSS Intra SGSN PS Handover), or belonging to different SGSNs (Inter-BSS Inter SGSN Handover). The PS Handover procedure is shown in Figure 23. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 55 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference HLR GGSN Gn SGSN Gb Gb Gb BSC BSC LA2, RA2 2 9w xy z ab c 6m no 3de f C C l jk 5 8 tu v # 6m no Inter BSS Intra SGSN + 4 ghi m 0 s 8 7 pqr * 6 c ab 2 9w xy z l jk 5 # 8 + m * 1 0 s 8 8 + 0 m 8 7 pqr 6 v 4 ghi Optimized and non-optimized no 12: 35 s ye v l jk 5 1 tu 3de f 6m no c ab 2 9w xy z 6 * T m 8 s Intra BSS Intra Cell Figure 23 7 pqr 6 * s ye tu tu 8 4 ghi 0 s T 7 pqr # 1 # 5 jk + 4 ghi 3de f C C 3de f 2 9w xy z ab c 6m no s ye v 1 no 12: 35 no 12: 35 l LA3, RA3 T no 12: 35 BSC T LA1, RA1 s ye SGSN Inter BSS Inter SGSN PS Handover Procedure The following traffic cases are described in the specified sections: • Intra-BSS with Intra-Cell,Section 10.1.1 on page 55 • Inter-BSS Intra-SGSN, Section 10.1.2 on page 58 • Inter-BSS Inter-SGSN, Section 10.1.3 on page 60 The cases when PS Handover are canceled or not accepted are described in Section 10.1.5 on page 64 and Section 10.1.4 on page 64. 10.1.1 Traffic Case Intra-BSS The intra-BSS handover procedure is a handover within the same BSS. Traffic Case Intra-Cell The Intra-Cell handover procedure is a handover within the same cell. This is handled internally in the BSS and the SGSN will usually not be involved. But if the new channel has limited resources and is unable to support the same QoS Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 56 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference for the BSS PFC as the old channel, the BSS must initiate a Modify-BSS-PFC procedure. Traffic Case Inter-Cell Intra-BSS Inter-Cell PS Handover is the case when the MS is moved between cells in the same BSS. The procedure is shown in Figure 24. The case is divided into a preparation phase and an execution phase. BSS MS Source Cell Target Cell SGSN GGSN Preparation Phase 1. Decision to perform A/Gb PS Handover 2. PS Handover Required GTP-U Packets LLC PDU Packets 3. PS Handover Request 4. The BSS reserves radio resources 5. PS Handover Request Acknowledge Execution Phase 1. GTP-U Packets LLC PDU Packets LLC PDU Packets 1. PS Handover Required Acknowledge 2. PS Handover Command 3. Access Procedures 4. RAU Request/Cell Update / LLC PDU Packets Sending of uplink data from target cell possible 5. PS Handover Complete 6. RAU / Cell Update / LLC PDU Packets 7. Delete BSS PFC 8. Delete BSS PFC Acknowledge LLC PDU Packets GTP-U Packets GTP-U Packets LLC PDU Packets 9. RAU Accept 10. Altered RAU Accept 11. RAU Complete 12. GMM Information Figure 24 Intra-BSS PS Handover (Inter-Cell ) The following steps describe the Intra-BSS Inter-Cell PS Handover procedure: Preparation Phase Uplink and downlink packets may be sent between the GGSN and the MS through the SGSN and BSS during the whole procedure. 1. The BSS initiates the PS Handover procedure. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 57 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 2. The BSS sends a PS Handover Required message to the SGSN. The SGSN verifies if the PS Handover feature is enabled and that no SGSN Pool Move operation is ongoing. If the feature Roaming Restrictions is activated, the SGSN also verifies that the IMSI number is not restricted within the target LA. 3. The SGSN determines the type of handover using Target Cell Identifier. If the RA part of Target Cell Identifier is controlled by this SGSN, it sends a PS Handover Request to the target cell and request the cell to establish radio resources and PFCs for all applicable PDP Contexts. 4. The BSS reserves radio resources for the target cell and establishes PFCs. 5. If the target cell is able to set up one or more of the requested PFCs, a PS Handover Request Acknowledge message is sent to the SGSN. If all of the requested PFCs are unable to be established, the SGSN will reject the PS handover attempt by sending a PS Handover Required Nack message to the source BSS. The procedure is then terminated. Execution Phase The SGSN starts bi-casting the downlink GTP-U packets received from the GGSN to both the source and target cell. 1. The SGSN acknowledges the request with a PS Handover Required Acknowledge message. 2. The PS Handover Command message is sent from the BSS source cell to the MS. 3. The MS executes the access procedures toward the target cell according to the parameters provided in the message delivered in the previous step. 4. A RAU Request, Cell Update or LLC PDU is sent to the target cell in the BSS. 5. PS Handover Complete message is sent to the SGSN from the target cell. The bi-casting will continue until the SGSN receives either a PS Handover Complete, a Cell Update, any LLC PDU, or a RAU Request message. These messages indicates to the SGSN that the MS has successfully moved to the target cell. 6. A RAU Request, Cell Update, or LLC PDU is sent to the SGSN and the Bi-casting is stopped. 7. The SGSN sends a Delete BSS PFC message for each PFC to the BSS source cell and the SGSN removes all PFCs towards the source cell. 8. The BSS acknowledge that all the PFCs towards the source cell are removed. 9. If the RAU Request message was sent in step 4 or step 6 the RAU Accept message is sent to the MS including a new P-TMSI. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 58 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 10. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions, the SGSN sends an altered Routing Area Update message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 11. The RAU Complete message is sent to the SGSN, if the RAU Request message was sent in step 4 or step 6. 12. Based on the optional configuration of Gb_SendGmmInfo (GSM), the operator can choose to configure the SGSN to send network information to the MS in the GMM Information message. This may provide local time to the MS. Inter-Cell Optimized If the BSS supports the optimized procedure an optimized handover can be performed. An optimized intra-BSS PS handover means that the MS is moved between cells belonging to the same BSS, NSE, and RA. The SGSN receives the PS Handover Complete message, accepts the message and downlink payload is sent to the target cell. The SGSN will accept the message and change to target cell without checking the PS Handover license. 10.1.2 Traffic Case Inter-BSS Intra-SGSN The Inter-BSS Intra-SGSN PS Handover traffic case describes when the MS is moved between cells belonging to different BSSs but within the same SGSN, as shown in Figure 25. The case is divided into a preparation phase and an execution phase. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 59 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) MS Source Target BSS BSS Date Rev - AA Reference SGSN GGSN Preparation Phase 1. Decision to perform A/Gb PS Handover GTP-U Packets LLC PDU Packets 2. PS Handover Required 3. PS Handover Request 4. The BSS reserves radio resources 5. PS Handover Request Acknowledge Execution Phase LLC PDU Packets 1. GTP-U Packets LLC PDU Packets 1. PS Handover Required Acknowledge 2. PS Handover Command 3. Access Procedures 4. RAU Request/Cell Update / LLC PDU Packets Sending of uplink data from target cell possible 5. PS Handover Complete 6. RAU / Cell Update / LLC PDU Packets 7. Delete BSS PFC 8. Delete BSS PFC Acknowledge LLC PDU Packets GTP-U Packets GTP-U Packets LLC PDU Packets 9. RAU Accept 10. Altered RAU Accept 11. RAU Complete 12. GMM Information Figure 25 Inter-BSS Intra-SGSN The following steps describe the Inter-BSS Intra-SGSN PS Handover procedure: Preparation Phase Uplink and downlink packets may be sent between the GGSN and the MS through the SGSN and BSS during the whole procedure. 1. The source BSS initiates the PS Handover procedure. 2. The BSS sends a PS Handover Required message to the SGSN. The SGSN verifies if the PS Handover feature is enabled and that no SGSN Pool Move operation is ongoing. If the feature Roaming Restrictions is activated the SGSN also verifies that the IMSI number is not restricted within the target LA. 3. The SGSN determines the type of handover using Target Cell Identifier. If the RA part of Target Cell Identifier is controlled by this SGSN, it sends a Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 60 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference PS Handover Request to the target BSS and request the BSS to establish radio resources and PFCs for all applicable PDP Contexts. 4. The target BSS reserves radio resources and establishes PFCs. 5. If the target cell is able to set up one or more of the requested PFCs, a PS Handover Request Acknowledge message is sent to the SGSN. If all of the requested PFCs are unable to be established, the SGSN will reject the PS handover attempt by sending a PS Handover Required Nack message to the source BSS. The procedure is then terminated. The execution phase is the same as the Intra-BSS Inter-Cell PS Handover execution phase procedure, see Section 10.1.1 on page 55. 10.1.3 Traffic Case Inter-BSS Inter-SGSN This traffic case describes when the MS is moved between cells belonging to different BSSs connected to different SGSNs as shown in Figure 26. The case is divided into a preparation phase and an execution phase. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 61 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Source BSS MS Date Rev - AA New Old Target SGSN BSS Reference SGSN GGSN Preparation Phase 1. Decision to perform A/Gb PS Handover GTP-U Packets LLC PDU Packets 2. PS Handover Required 3. Forward Relocation Request 4. PS Handover Request 5. Reservation of Radio Resources in target BSS 6. PS Handover Request Acknowledge 7. Forward Relocation Response Execution Phase GTP-U Packets LLC PDU Packets GTP-U Packets LLC PDU Packets 1. PS Handover Required Acknowledge 2. PS Handover Command 3. Access Procedures 4. XID Response 5. PS Handover Complete 6. XID Response Sending of uplink data possible 7. Forward Relocation Complete 8. Forward Relocation Complete Acknowledge 9. XID Command (empty) 10. XID Response 11. BSS Packet Flow Delete Procedures 12. Update PDP Context Request 13. Update PDP Context Response GTP-U Packets LLC PDU Packets 14. RAU Request RAU Procedure 15. Update Location 16. Cancel Location 17. Cancel Location Ack 18. Insert Subscriber Data 19 Insert Subscriber Data Ack 20. Update Location Ack 21. RAU Accept 22. Altered RAU Accept 23. RAU Complete 24. GMM Information Figure 26 Inter-BSS Inter-SGSN HLR Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 62 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference The following steps describe the Inter-BSS Inter-SGSN PS Handover procedure: Preparation Phase Uplink and downlink packets may be sent between the GGSN and the MS through the SGSN and BSS during the whole procedure. 1. The source BSS initiates the PS Handover procedure. 2. The BSS sends a PS Handover Required message to the old SGSN. The old SGSN verifies that the PS Handover feature is enabled and that target RA belongs to a cooperating SGSN. The SGSN selects new SGSN based on target RA either by using local SGSN configuration or DNS server. 3. The old SGSN sends a Forward Relocation Request message to the new SGSN. The new SGSN verifies that the PS Handover feature is enabled and that no SGSN Pool Move operation is ongoing. The IMSI number must be defined in the new SGSN. If the feature Roaming Restrictions is activated the SGSN also verifies that the IMSI number is not restricted within the target LA. 4. The SGSN requests the BSS to reserve radio resources for the target cell and establish PFCs for all applicable PDP contexts. 5. The target BSS reserves radio resources and establishes PFCs. 6. If the target cell is able to set up one or more of the requested PFCs, a PS Handover Request Acknowledge message is sent to the new SGSN. If all of the requested PFCs are unable to be established, the new SGSN will send a Forward Relocation Response (Reject) message to the old SGSN. The old SGSN rejects the PS handover attempt by sending a PS Handover Required Nack message to the source BSS. The procedure is then terminated. 7. The new SGSN sends a Forward Relocation Response message to the old SGSN including Packet Flow Identifiers (PFIs) for the established PFCs in the target BSS. Execution Phase The GTP-U packets from the GGSN are sent to the old SGSN which will forward the associated PDU payload to the MS through the source BSS. Packets are also sent to the target BSS through the new SGSN . 1. The old SGSN continues the PS handover by sending the PS Handover Required Acknowledge message to the source BSS. 2. The PS Handover Command message is sent to the MS from the source BSS. 3. The MS executes the access procedures toward the target BSS according to the parameters provided in the message delivered in the previous step. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 63 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 4. The MS sends an Exchange Identifier (XID) Response message to the target BSS. 5. The target BSS sends a PS Handover Complete message to the new SGSN to indicate the success of the handover procedure. This and the following message may be sent to the new SGSN in any order. 6. The XID Response message is forwarded to the new SGSN. 7. The new SGSN sends a Forward Relocation Complete message to the old SGSN and this completes the PS Handover procedures in the old SGSN. 8. The old SGSN acknowledges this with a Forward Relocation Complete Acknowledge message. 9. The XID Command message with an empty parameter list is sent to the MS. 10. The XID Response message is sent to the new SGSN from the MS. 11. The old SGSN initiates Delete PFC Management procedures towards the source cell to trigger the release of resources in the source cell. 12. The new SGSN sends Update PDP Context Request messages to the GGSN. 13. The GGSN updates the PDP contexts and returns Update PDP Context Response messages. The GGSN sends, from now on, the new incoming downlink GTP-U packets to the new SGSN instead of to the old SGSN. 14. The MS sends a RAU Request message to the new SGSN. Since the SGSN already acknowledged the handover for this MS, the RAU procedure is a somewhat compressed version of the ordinary RA Update procedure. 15. The new SGSN informs the HLR of the change of SGSN by sending an Update Location message to the HLR. 16. The HLR sends a Cancel Location message to the old SGSN with Cancellation Type set to Update Procedure. The packet forwarding towards the new SGSN is stopped. 17. The old SGSN acknowledges the Cancel Location message with a Cancel Location Acknowledge message. 18. The HLR sends Insert Subscriber Data message to the new SGSN. This validates the MS presence in the RA. 19. The new SGSN returns an Insert Subscriber Data Acknowledge message to the HLR. 20. The HLR acknowledges the Update Location message by sending an Update Location Acknowledge message to the new SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 64 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference 21. The new SGSN sends a RAU Accept message to the MS including a new P-TMSI. 22. If the MS does not acknowledge the received P-TMSI and P-TMSI signature after a specified number of retransmissions, the SGSN sends an altered Routing Area Update message to the MS. The altered message omits information elements known to cause problems with non-3GPP compliant MSs. 23. The MS responds with a RAU Complete message to the SGSN. 24. Based on the optional configuration of Gb_SendGmmInfo (GSM), the operator can choose to configure the SGSN to send network information to the MS in the GMM Information message. This may provide local time to the MS. 10.1.4 PS Handover Not Accepted The PS Handover procedure can not be performed if the PS Handover feature is inactive. The PS Handover Required Negative Acknowledge message is then sent to the source BSS. Examples of other cases when this message is sent are listed below: 10.1.5 • When an SGSN Pool move operation is in progress in new SGSN • Roaming Restrictions apply to the MS at new RA • All requested Radio resources cannot be established in the target BSS • Not a GTP version 1 on the Gn interface between SGSNs • The target RA or target cell is unknown • The target BSS does not support Packet Flow Management (PFM) • IMSI number not defined (valid for new SGSN only) PS Handover Cancel The source BSS may, until the MS has accessed the target BSS, cancel the handover. To initiate the cancelling process the source BSS sends a PS Handover Cancel message to the SGSN. The source BSS will initiate the cancellation when, for example, a timer expires. The PS Handover Cancel message is also sent when radio contact with the MS is lost or PS Handover fails and the MS returns to the old cell. This releases the resources reserved for the PS Handover in the target system. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 65 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 11 Date Rev - AA Reference Cooperating SGSNs Cooperating SGSNs are SGSNs with which the local SGSN can start the Identification Request procedure (required for an attach with P-TMSI and old RA) or the Context Request procedure (required for an Inter-SGSN RAU). RAs within the service area of a cooperating SGSN are denoted cooperating RAs. In order to support attach with only P-TMSI and old RA, both the cooperating SGSNs and the cooperating RAs must be registered in the local SGSN or in the DNS. Note: Defining a cooperating RA in the local SGSN is only applicable for the Gn-SGSN. For the S4-SGSN, cooperating RAs must be defined in the DNS. When defining a cooperating RA in the local SGSN the RAI is specified. The RAI consists of a Mobile Country Code (MCC), a Mobile Network Code (MNC), a Location Area Code (LAC), and a Routing Area Code (RAC). The combination of MCC and MNC distinguishes the identity of the PLMN. Since the cooperating SGSNs and RAs listed in the local SGSN may be distributed over several PLMNs, it is possible for an MS to perform an Inter-PLMN RAU from a PLMN other than the home PLMN. As an alternative to local registration of RAIs and corresponding IP addresses of cooperating SGSNs, the information can be stored in the DNS and reached by all SGSNs through DNS queries. In an SGSN pool where several SGSNs can serve one RA, one SGSN for each RA, referred to as the default SGSN, is registered as a cooperating SGSN, locally as well as in the DNS. When the default SGSN receives a context request, for instance during an inter-SGSN RAU procedure, relaying may be required to identify the SGSN holding the context in question, see Section 8.2 on page 40. However, since the default SGSN can have been removed from the pool, identifying an SGSN pool member based on the information stored locally or obtained through a DNS query involves a risk of single point of failure. To avoid unnecessary relaying and single point of failure, DNS queries containing both NRI and RAI are enabled through pool awareness supported in the SGSN (see SGSN Pool). This way, the SGSN can directly fetch the address of the pool member holding the context of the MS that has left the pool service area, that is, the old SGSN. Note that Note: To enable pool awareness, the NRI bit length must be between five and eight bits. PS Handover and Inter-SGSN Inter-BSC NACC requires cooperating SGSNs. However, for loadsharing purposes, none of the procedures include NRI values in DNS queries during the identification of an SGSN. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 66 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 12 Date Rev - AA Reference Suspend and Resume When a GPRS-attached GSM MS in class B mode of operation receives a circuit-switched call, it requests the network for suspension of GPRS services and enters circuit-switched mode. Optionally the SGSN can be configured to accept or reject an incorrect RAI if received in the suspend message. When the call is finished, the BSS releases the circuit-switched radio channel and requests the SGSN to resume GPRS services for the MS. When this request is acknowledged, the BSS requests the MS to leave dedicated mode. If the resumption is not successful, the MS resumes GPRS services by performing a RAU to the SGSN. The SGSN does not page suspended MSs. The GPRS services can also be suspended if the radio resources are so bad that loss of communication occurs. When communication is reestablished the GPRS services are resumed. Attached MSs without active PDP contexts can also use the Suspend and Resume procedures. A DTM capable MS, though, does not use them. 13 Shared Network Support Shared network support gives the operators the opportunity to reduce their costs by sharing networks with other operators. Ericsson offers common shared networks and geographical split networks to enable infrastructure share in the GPRS backbone network. These solutions are supported by the SGSN and enabled by the following functions: • Selective Equivalent PLMN List • Support for Multiple PLMNs • Roaming Restrictions The first two functions are described in the following sections. The third function, Roaming Restrictions, is described in Section 14.1 on page 67. 13.1 Selective Equivalent PLMN List The main purpose of Selective Equivalent PLMN List is to steer an MS into selecting a PLMN network, within the shared network group of networks, at cell selection and cell re-selection. The MS receives a list of equivalent PLMNs, and, together with the current registered network, all these equivalent PLMNs are considered equivalent with respect to cell selection and re-selection in the handset. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 67 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 13.2 Date Rev - AA Reference Support for Multiple PLMNs The SGSN provides support for multiple PLMNs, that is, one physical SGSN can serve several PLMNs, which renders the possibility to share one SGSN between different networks and different countries. 14 Restrictions Restrictions enables the SGSN to restrict the access for certain subscribers. 14.1 Roaming Restrictions The feature Roaming Restrictions enables the SGSN to restrict the access for certain subscribers in one or several Location Areas. In each Location Area, Roaming Restriction can be defined for subscribers belonging to different IMSI number series. Furthermore, for each of the IMSI number series, different cause codes can be sent to the MS, depending on the MS behavior. For the same IMSI, different Roaming Restriction Cause Code objects may be used for different Location Areas. The Roaming Restriction applies both to the attach and the RAU procedures. At attach, or when entering a new Location Area, the SGSN determines if the MS belongs to an IMSI number series that is not allowed to use the services (restricted) in that area. The cause code returned to the MS depends on the configuration. The MS will act differently depending on the cause code received. The following codes can be returned: • Cause Code #11 – PLMN not allowed • Cause Code #13 – Roaming not allowed in this Location Area • Cause Code #14 – GPRS services not allowed in this PLMN • Cause Code #15 – No suitable cells in Location Area Roaming Restriction is not related to the subscriber’s subscription data (defined in the HLR); it is only defined in the SGSNs. The restrictions should also be defined in the MSCs, to achieve consistent terminal behavior between the PS and CS domains, since the cause codes #13 and #15 influence both the PS and CS networks. Therefore, Roaming Restriction is used on Location Area and not on RA level. One or several RAs constitute an Location Area and a single RA may only belong to one Location Area. 14.2 Access Restriction Optionally supported in the SGSN, Access Restriction ensures that subscribers that are not allowed to access the GSM network are restricted from access. Using this feature, the SGSN acquires information on whether access to a Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 68 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference requested network is allowed by analyzing the information element Access Restriction Data received from the HLR as part of an Insert Subscriber Data message. The access restriction control is performed when the SGSN receives an Insert Subscriber Data message, with the included Access Restriction Data, during an MS Attach procedure, an Inter-SGSN RAU procedure, an Inter-System Change procedure, an IRAT PS Handover, or as a stand-alone message from the HLR. If a subscriber is restricted from accessing the requested network following an attach or RAU request, the SGSN sends an appropriate reject message to the MS with cause code #13 or #15 (see Section 14.1 on page 67). If the SGSN receives an Insert Subscriber Data message as a stand-alone message indicating access restriction to the network to which the subscriber at the present time has access, the SGSN initiates a Detach procedure with cause code #13 or #15. Access Restriction requires the HLR to have coherent support for the information element Access Restriction Data. 15 Capacity License Limit The Capacity License Limit enables a hard limit for the attach procedure for Simultaneously Attached Users (SAU). When hard limit is applied and the number of SAU reaches the licensed capacity limit, an Attach Reject message is sent to the MS with cause code #22 - Congestion. When the number of SAU is 80% of the licensed capacity limit, an alarm is raised indicating that the licensed capacity is soon reached. The alarm is cleared when the number of attached MSs drops below 70% of the licensed capacity. When the number of SAU is 100% of the licensed capacity limit, an alarm is raised indicating that the licensed capacity is reached. Further MS Attach requests will not be accepted while the limit is reached. The alarm is cleared when the number of SAU drops below 95% of the licensed capacity limit. If the license state of the SGSN is Sticky, Emergency1 or Emergency2 (see Operation and Maintenance Description) the licensed SAU capacity is temporarily set to the HW defined maximum SAU capacity. Soft limit is applied when a license exist for an SGSN Pool feature. Soft limit implies that further MS Attach requests are still accepted when the number of SAU exceeds the licensed capacity limit. When the number of SAU exceeds the licensed capacity limit, an alarm is raised. The alarm is cleared when the number of SAU drops below 95% of the licensed capacity limit. Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 69 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 16 Date Rev - AA Reference Prioritize Payload Users Using Prioritize Payload Users, the payload has the highest priority after an SGSN reload or a large restart. Subscribers not actively using the GPRS services is given a lower priority (for information on recovery, see Resilience). This improves the service availability and minimizes the impact on payload transfer due to SGSN reloads and large restarts. After an SGSN reload or a large restart, the attempts to reattach for a GSM MS are prioritized according to their priority class. The following priority classes exist, where class A has the highest priority: • Class A, activate PDP context requests and payload • Class B, attach requests • Class C, RAUs Since payload packets are of highest priority, MSs with payload traffic are requested by the SGSN to reattach, whereafter payload traffic can be resumed. This procedure is valid for all session management related Radio Interface Layer 3 (RIL3) messages, SMS messages, and payload packets. 17 Multiple Time Zones Multiple Time Zones (MTZ) is a basic function that provides the MS with local time. The RAs of a PLMN may be deployed over a geographically large area which may span over more than one time zone. MTZ provides the MS with the local time of the area where the MS is located. Local time is defined by assigning an optional time zone parameter to the local Routing Area configuration. When the MS moves between RAs the SGSN checks if there is a change in local time of the MS and updates the MS if it has changed. SGSN also checks if there is a change in local time when the node performs control signaling towards GGSN. MTZ also encompasses updates of local time in the GGSN if the optional feature AACE is enabled. The Serving GPRS Support Node-Charging Data Record (S-CDR) is updated with local time and a partial record is closed at a change in local time. The impact from the feature to the S-CDR is controlled by a parameter to allow generation of S-CDRs without proprietary information. 18 Home Zone Charging Differentiation Home Zone charging differentiation is an enhancement to the optional feature GTP ULI Support. The enhancement allows differentiation of the charging within a configured Home Zone area compared to outside the area. The feature Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 70 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference also allows charging information to be collected either from the S-CDRs or through the GGSN. Home Zone charging differentiation is supported on the GSM node and requires support in the GGSN and the charging systems for full functionality. Home Zone charging differentiation is based on that the SGSN can be configured to handle one or more Home Zone area(s). Each Home Zone area is configured to include one or more RAs. Within a Home Zone area, the SGSN includes the RAT type in the PDP Activation and Modification (SGSN- or BSS- initiated modification) messages towards the GGSN. When the MS crosses a Home Zone boundary, the Update PDP message including the RAT type is triggered to be sent towards the GGSN. This message is sent during Intra- and Inter- SGSN RAU. The information towards the GGSN can be configured to either GAN or GERAN to ensure backward compatibility. When a (partial) S-CDR is opened within a Home Zone area, the RAT type is set to either GAN or GERAN according to configuration to ensure backward compatibility. To allow charging based on whether the MS is in a Home Zone area or not, partial closure of S-CDRs when the MS crosses a Home Zone boundary can be configured. Note: The SGSN does not apply Home Zone charging functionality in conjunction with a PS handover or IRAT PS handover. For information on configuration related to Home Zone charging differentiation, see Features and Functions Management. For information about GTP ULI Support, see GPRS Session Management. 19 Multiple SIM Support The SGSN supports that multiple MSs with different IMSI numbers use the same MSISDN during a mobility management procedure. For example, a subscriber using several mobile devices, having the same MSISDN but different IMSIs, is supported. 20 Parameters For a description of each parameter and its default values, see Parameter Description. The following GSM parameters are related to mobility management: • Gb_AllowIncorrectImeisv • Gb_CellNotificationSupport Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA • Gb_Ciphering • Gb_ForceAttachAtUnknownRai • Gb_ForceToStandbyForInactiveSubscribers • Gb_IdentityImeiEnabled • Gb_MobileReachableTimer • Gb_MS_inactivity_time_limit • Gb_N3313-OldPtmsi • Gb_N3313-Paging • Gb_PdpContextStatusInRAUAccept • Gb_PeriodicAuthenticationTimer • Gb_ReAuthenticationEnabled • Gb_Repeat_paging • Gb_RepeatPagingStep • Gb_SelectiveAuthenticationFrequency • Gb_SendEqPlmnList3gOnly • Gb_SendGmmInfo • Gb_T13_PshoRequestAck • Gb_T14_PshoComplete • Gb_T3313-PagingTimer • Gb_T3314-ReadyTimer • Gb_T3314-ReadyTimerMax • Gb_T3314-ReadyTimerMin • Gb_UncipheredMode • GbIu_InterSgsnSelectiveAuthenticationFrequency • GbIu_IntraSgsnIscSelectiveAuthenticationFrequency • Gblu_Non3GPPCompliantRetransmissionLevel • Gn_N3_RequestsIdentification • Gn_N3_RequestsSGSNContext Reference 71 ( 76 ) Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 21 Date Rev - AA • Gn_N3_RequestsUpdate • Gn_T14_PshoFrwRelComplete • Gn_T3_ResponseIdentification • Gn_T3_ResponseSGSNContext • Gn_T3_ResponseUpdate • Gn_UseDnsMapRaToSgsnAddressDNS • Gn_UseFourDigitDnsMapRaToSGSN • Gn_UseNriInDnsQuery • Gr_TripletReUse • Gs_BSSAP+_SSN • Gs_N10-RequestsImplDetachIndCS • Gs_N12-RequestsSgsnReset • Gs_N8-RequestsExplDetachIndPS • Gs_N9-RequestsExplDetachIndCS • Gs_T10-ResponseImplDetachIndCS • Gs_T12-1-SgsnReset • Gs_T12-2-ResponseSgsnReset • Gs_T8-ResponseExplDetachIndPS • Gs_T9-ResponseExplDetachIndCS • Gs_T6-1-ResponseLocationUpdate • N3RequestResponseContext • T3ResponseAcknowledgeContext Counters For descriptions of the counters, see Counter Description. Reference 72 ( 76 ) Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 73 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 22 Date Rev - AA Reference Alarms Each alarm is described in a document entitled as the alarm. Refer to these documents for further information about the alarms. The following alarms are related to mobility management: • admAttachCapacityReached • admAttachLicenseApproaching • admAttachHardLicenseExceeded • admAttachSoftLicenseExceeded • nwcCoopRaExist Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) 23 Date Rev - AA Reference References Ericsson Documents [1] admAttachCapacityReached FAULT TRACING DIRECTIONS 3/154 51-CNA 250 087 [2] admAttachHardLicenseExceeded FAULT TRACING DIRECTIONS 17/154 51-CRA 250 56/1 [3] admAttachLicenseApproaching FAULT TRACING DIRECTIONS 18/154 51-CRA 250 56/1 [4] admAttachSoftLicenseExceeded FAULT TRACING DIRECTIONS 16/154 51-CRA 250 56/1 [5] Counter Description PARAMETER DESCRIPTION 3/190 84-AXB 250 05/8 [6] EPS Mobility Management for LTE Access TECHNICAL PRODUCT DESCRIPTION 44/221 02-AXB 250 05/8 [7] Ericsson Packet Core Network Overview DESCRIPTION 1/1551-CSH 113 02 [8] Fault Management TECHNICAL PRODUCT DESCRIPTION 12/221 02-AXB 250 05/8 [9] Features and Functions Management OPERATION DIRECTIONS 2/1543-AXB 250 05/8 [10] GPRS Mobility Management for WCDMA Access TECHNICAL PRODUCT DESCRIPTION 41/221 02-AXB 250 05/8 [11] GPRS Overview DESCRIPTION 67/1551-AXB 250 05 [12] GPRS Session Management TECHNICAL PRODUCT DESCRIPTION 38/221 02-AXB 250 05/8 [13] Inter-System Mobility Management TECHNICAL PRODUCT DESCRIPTION 37/221 02-AXB 250 05/8 [14] Node Property (CLI) MANUAL PAGE 51/190 80-CRA 250 56/1 [15] nwcCoopRaExist FAULT TRACING DIRECTIONS 10/154 51-CNA 250 006 [16] Operation and Maintenance Description DESCRIPTION 66/1551-AXB 250 05 74 ( 76 ) Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 75 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference [17] Parameter Description PARAMETER DESCRIPTION 10/190 84-AXB 250 05/8 [18] Resilience TECHNICAL PRODUCT DESCRIPTION 16/221 02-AXB 250 05/8 [19] Security TECHNICAL PRODUCT DESCRIPTION 7/221 02-AXB 250 05/8 [20] SGSN Pool TECHNICAL PRODUCT DESCRIPTION 18/221 02-AXB 250 05/8 [21] SGSN Support for MSC in Pool TECHNICAL PRODUCT DESCRIPTION 33/221 02-AXB 250 05/8 [22] Subscriber Data (CLI) MANUAL PAGE 98/190 80-CRA 250 56/1 [23] Subscriber Data Management TECHNICAL PRODUCT DESCRIPTION 21/221 02-AXB 250 05/8 Standards [24] General Packet Radio Service (GPRS); Service description; Stage 2 3GPP TS 23.060 [25] General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface 3GPP TS 29.060 [26] 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 3GPP TS 29.274 Statements of Compliance [27] SoC for 3GPP TS 25.413 Statement of Compliance, UTRAN Iu interface RANAP signaling 11/174 02-AXB 250 05/8 [28] SoC for 3GPP TS 48.018 Statement of Compliance, BSS GPRS Protocol (BSSGP) 34/174 02-AXB 250 05/8 [29] SoC for 3GPP TS 43.129 Statement of Compliance, Packet-switched handover for GERAN A/Gb mode 41/174 02-AXB 250 05/8 [30] SoC for 3GPP TS 29.018 Statement of Compliance, General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification 14/174 02-AXB 250 05/8 Ericsson Internal TECHNICAL PRODUCT DESCRIPTION Prepared (also subject responsible if other) 76 ( 76 ) No. / EANFUWU 40/221 02-AXB 250 05/8 Uen Approved Checked EAB/ FBA/TX ( Liselotte Wanhov) Date Rev - AA Reference [31] SoC for 3GPP TS 23.060 Statement of Compliance, General Packet Radio Service (GPRS); Service Description; Stage 2 4/174 02-AXB 250 05/8 [32] SoC for 3GPP TS 09.60 Statement of Compliance, GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface 1/174 02-AXB 250 05/8 [33] SoC for 3GPP TS 29.060 Statement of Compliance, GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface 15/174 02-AXB 250 05/8 [34] SoC for 3GPP TS 24.008 Statement of Compliance, Mobile Radio Interface Layer 3 Specification 8/174 02-AXB 250 05/8 [35] SoC for 3GPP TS 23.251 Statement of Compliance, Network sharing; Architecture and functional description 36/174 02-AXB 250 05/8 [36] SoC for 3GPP TS 29.274 STATEMENT OF COMPLIANCE GTPv2-C 47/174 02-AXB 250 05/8 [37] SoC for 3GPP TS 23.003 Statement of Compliance, Numbering, Addressing and Identification 39/174 02-AXB 250 05/8 [38] SoC for 3GPP TS 23.236 Statement of Compliance, Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes 7/174 02-AXB 250 05/8