6.5 GPRS Attach Function

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.5.0 General

An MS shall perform a GPRS Attach to the SGSN in order to obtain access to the GPRS services. If the MS is connected in A/Gb mode, it shall perform an A/Gb mode GPRS Attach procedure. If the MS is connected via in Iu mode, it shall perform an Iu mode GPRS Attach procedure.

In the attach procedure, the MS shall provide its identity and an indication of which type of attach that is to be executed. The identity provided to the network shall be the MS’s Packet TMSI (P‑TMSI) if it has a valid P-TMSI, otherwise it shall be the IMSI. The P-TMSI may be derived from a GUTI when the MS is E-UTRAN capable or may be a stored native P-TMSI from a previous GPRS registration (e.g. upon mobility from the 5G System). If the MS does not have a valid P‑TMSI or a valid GUTI, the MS shall provide its IMSI. For emergency attach, the IMEI shall be included when the MS has no IMSI, no valid GUTI and no valid P‑TMSI.

In order to limit load on the network, only when performing a GPRS Attach with a new PLMN (i.e. not the registered PLMN or an equivalent PLMN of the registered PLMN), an MS configured to perform Attach with IMSI at PLMN change (see TS 24.368 [111]) shall identify itself with its IMSI instead of any stored temporary identifier.

During the Attach procedure, the MS provides its PS Handover and inter-RAT Handover capabilities in the Attach Request message. The SGSN uses the inter-RAT indicator and/or other indicators to ask the MS (using the Attach Accept message) to send the other RAT’s Radio Access Capabilities in Iu mode and UTRAN Radio Access Capabilities in A/Gb mode in the Attach Complete message.

6.5.1 A/Gb mode GPRS Attach Procedure

A GPRS attach is made to the SGSN. A GPRS-attached MS makes IMSI attach via the SGSN with the combined RA / LA update procedure if the network operation mode is I. In network operation mode II, or if the MS is not GPRS-attached, the MS makes an IMSI attach as already defined in A/Gb mode. An IMSI-attached MS in class‑A mode of operation engaged in a CS connection shall use the (non-combined) GPRS Attach procedures when it performs a GPRS attach.

The SGSN indicates "SMS-Supported" to the MS when the HSS has indicated "SMS in SGSN Support". It indicates to the MS that it can obtain SMS services via PS domain NAS from the SGSN. An MS that needs only PS services and SMS services via NAS should not perform any procedures via CS domain when it can obtain SMS services via PS domain NAS from SGSN.

At the RLC/MAC layer, the MS shall identify itself with a Local or Foreign TLLI if the MS is already GPRS-attached and is performing an IMSI attach. Otherwise, the MS shall identify itself with a Foreign TLLI, or a Random TLLI if a valid P‑TMSI is not available. The Foreign or Random TLLI is used as an identifier during the attach procedure until a new P‑TMSI is allocated.

After having executed the GPRS attach, the MS is in READY state and MM contexts are established in the MS and the SGSN. The MS may then activate PDP contexts as described in clause "Activation Procedures".

An IMSI-attached MS that can only operate in class‑C mode of operation shall follow the normal IMSI detach procedure before it makes a GPRS attach. A GPRS-attached MS in class‑C mode of operation shall always perform a GPRS detach before it makes an IMSI attach.

If the network operates in mode I (see clause "Paging Co-ordination in A/Gb mode"), then an MS that is both GPRS-attached and IMSI-attached shall perform the Combined RA / LA Update procedures.

If the network operates in mode II, then a GPRS-attached MS that has the capability to be simultaneously GPRS-attached and IMSI-attached shall perform the (non-combined) Routeing Area Update procedures, and either:

– access the non-GPRS common control channels for CS operation (the way that CS operation is performed in parallel with GPRS operation is an MS implementation issue outside the scope of the present document); or

– if CS operation is not desired, depending on system information that defines whether or not explicit detach shall be used, either:

– avoid all CS signalling (in which case the MS may be implicitly IMSI detached after a while); or

– perform an explicit IMSI detach via the non-GPRS common control channels (if the MS was already IMSI-attached).

The Combined GPRS / IMSI Attach procedure is illustrated in Figure 22.

If the MS needs to use extended idle mode DRX, the MS includes the extended idle mode DRX parameters information element in the Attach Request message. If the SGSN decides to enable extended idle mode DRX it includes the extended idle mode DRX parameters information element in the Attach Accept message.

The MS indicates its capability of supporting restriction of use of Enhanced Coverage in the Attach Request message. If the MS includes the capability of supporting restriction of use of Enhanced Coverage, SGSN sends Enhanced Coverage Restricted parameter received from the HLR to the MS in the Attach Accept message.

6.5.2 Iu mode GPRS Attach Procedure

A GPRS-attached MS makes an IMSI attach via the SGSN with the combined RA / LA update procedure if the network operates in mode I. If the network operates in mode II, or if the MS is not GPRS-attached, the MS makes a normal IMSI attach. An IMSI-attached MS engaged in a CS connection shall use the (non-combined) GPRS Attach procedure when it performs a GPRS attach.

After having executed the GPRS attach, the MS is in the PMM‑CONNECTED state and MM contexts are established in the MS and the SGSN. The MS may then activate PDP contexts as described in clause "Activation Procedures".

An IMSI-attached MS that cannot operate in CS/PS mode of operation shall follow the normal IMSI detach procedure before it makes a GPRS attach. A GPRS-attached MS that cannot operate in CS/PS mode of operation shall perform a GPRS detach before it makes an IMSI attach.

In networks that support network sharing as defined in TS 23.251 [83], the SGSN may be informed by the RNS about the identity of the selected core network operator when receiving the Attach Request message. If available, this information is stored in the SGSN MM context.

During the GPRS Attach procedure, if the SGSN supports SRVCC and if any of the conditions described in step 7 in Figure 22 are satisfied, if the UE SRVCC capability has changed, it notifies the HSS with the UE SRVCC capability e.g. for further IMS registration.

For emergency attach handling, see clause 5.10.3.

For Emergency Attach only GPRS emergency attach is performed and no combined GPRS and IMSI attach is specified.

6.5.3 Combined GPRS / IMSI Attach procedure

The Combined GPRS / IMSI Attach procedure is illustrated in Figure 22.

Figure 22: Combined GPRS / IMSI Attach Procedure

NOTE 1: All steps except steps 6 and 7d, 7e are common for architecture variants using Gn/Gp based interaction with GGSN and using S4-based interaction with S‑GW and P‑GW. For an S4-based interaction with S‑GW and P‑GW, procedure steps (A) are defined in clause 6.5.3A and procedure steps (B) are defined in clause 6.5.3B.

NOTE 2: For an Emergency Attach in which the MS was not successfully authenticated, steps 6, 7, 8 and 11 are not performed.

1) In A/Gb mode, the MS initiates the attach procedure by the transmission of an Attach Request (IMSI or P‑TMSI and old RAI, MS Radio Access Capability, MS Network Capability, CKSN, Attach Type, DRX Parameters, extended idle mode DRX parameters, old P‑TMSI Signature, additional P-TMSI, Voice domain preference and UE’s usage setting, SMS-only, Support for restriction of use of Enhanced Coverage) message to the SGSN. IMSI shall be included if the MS does not have a valid P‑TMSI available, or, if the MS is configured to perform Attach with IMSI at PLMN change and is accessing a new PLMN. If the MS has a valid P‑TMSI or a valid GUTI, then P‑TMSI and the old RAI associated with P‑TMSI shall be included. MS Radio Access Capability contains the MS’s GPRS multislot capabilities, frequency bands, etc. as defined in TS 24.008 [13]. Attach Type indicates which type of attach is to be performed, i.e. GPRS attach only, GPRS Attach while already IMSI attached, or combined GPRS / IMSI attach. If the MS uses P‑TMSI for identifying itself and if it has also stored its old P‑TMSI Signature, then the MS shall include the old P‑TMSI Signature in the Attach Request message. The MS includes the extended idle mode DRX parameters information element if the MS needs to enable extended idle mode DRX.

For Iu mode, the MS initiates the attach procedure by the transmission of an Attach Request (IMSI or P‑TMSI and old RAI, Core Network Classmark, KSI, Attach Type, old P‑TMSI Signature, Follow On Request, DRX Parameters, additional P-TMSI, SMS-only) message to the SGSN. IMSI shall be included if the MS does not have a valid P‑TMSI available or a valid GUTI. If the MS uses P‑TMSI for identifying itself and if it has also stored its old P‑TMSI Signature, then the MS shall include the old P‑TMSI Signature in the Attach Request message. If the MS has a valid P‑TMSI, then P‑TMSI and the old RAI associated with P‑TMSI shall be included. KSI shall be included if the MS has valid security parameters. Core Network Classmark is described in clause "MS Network Capability". The MS shall set "Follow On Request" if there is pending uplink traffic (signalling or user data). The SGSN may use, as an implementation option, the follow on request indication to release or keep the Iu connection after the completion of the GPRS Attach procedure. Attach Type indicates which type of attach is to be performed, i.e. GPRS attach only, GPRS Attach while already IMSI attached, or combined GPRS / IMSI attach.

In both A/Gb and Iu mode, the DRX Parameters contain information about DRX cycle length for GERAN, UTRAN and possibly other RATs, e.g. E-UTRAN.

If the MS initiates the Attach procedure at a CSG cell or a hybrid cell, the RAN indicates the CSG ID of the cell with the Attach Request message sent to the new SGSN. If the MS attaches via a hybrid cell, the RAN indicates the CSG access mode to the new SGSN. If the CSG access mode is not indicated but the CSG ID is indicated, the SGSN shall consider the cell as a CSG cell.

The E-UTRAN capable MS stores the TIN in detached state. If the MS’s TIN indicates "P-TMSI" or "RAT related TMSI" and the MS holds a valid P-TMSI then the "old P-TMSI" IE indicates this valid P-TMSI. If the MS’s TIN indicates "GUTI" and the MS holds a valid GUTI then the "old P-TMSI" IE indicates a P-TMSI mapped from the GUTI. If the UE has a valid NAS token, the truncated NAS token shall be included in the "old P-TMSI signature" IE as described in TS 33.401 [91]. Otherwise, an empty NAS token shall be included in the "old P-TMSI Signature" IE.

Mapping a GUTI to P‑TMSI/RAI is specified in TS 23.003 [4]. If the MS holds a valid P-TMSI then the MS indicates the P-TMSI as additional P-TMSI, regardless whether the "old P-TMSI" IE also indicates this P-TMSI or a P-TMSI mapped from a GUTI.

The UE sets the voice domain preference and UE’s usage setting according to its configuration, as described in clause 5.3.15.

For an Emergency Attach the MS shall indicate emergency service and the IMSI shall be included if the MS does not have a valid P-TMSI or a valid GUTI available. The IMEI shall be included when the MS has no valid IMSI, no valid P-TMSI and no valid GUTI. The UE shall set the "Follow On Request" to indicate that there is pending uplink traffic and the UE shall initiate the activation of an emergency PDP context after successful Emergency Attach.

If the SGSN is not configured to support Emergency Attach the SGSN shall reject any Attach Request that indicates emergency service.

The MS indicates its "SMS-only" capability during a combined GPRS / IMSI attach when the MS is requesting IMSI attach only for obtaining SMS and not any other services from CS domain.

2) If the MS identifies itself with P‑TMSI and the SGSN has changed since detach, the new SGSN sends an Identification Request (P‑TMSI, old RAI, old P‑TMSI Signature) to the old SGSN (this could be an old MME) to request the IMSI. If the new SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN from the old RAI and the old P-TMSI and send the Identification Request message to this old SGSN. Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI and relay the message to that actual old SGSN. The old SGSN responds with Identification Response (IMSI, Authentication Triplets or Authentication Quintets). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN also validates the old P‑TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. If the old SGSN is a MME and the truncated NAS token is included in the "old P-TMSI Signature" IE, this validation checks the NAS token as described in TS 33.401 [91].

For an Emergency Attach if the MS identifies itself with a temporary identity that is not known to the SGSN, the SGSN shall immediately request the IMSI from the MS. If the UE identifies itself with IMEI, the IMSI request shall be skipped.

3) If the MS is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type = IMSI) to the MS. The MS responds with Identity Response (IMSI).

4) The authentication functions are defined in the clause "Security Function". If no MM context for the MS exists anywhere in the network, then authentication is mandatory. Ciphering procedures are described in clause "Security Function". If P‑TMSI allocation is going to be done and the network supports ciphering, the network shall set the ciphering mode.

If the SGSN is configured to support Emergency Attach for unauthenticated IMSIs and the MS indicated emergency service, the SGSN skips the authentication and security setup or the SGSN accepts that the authentication may fail and continues the attach procedure. If the MS is emergency attached and not successfully authenticated, integrity protection and ciphering shall not be performed.

5) The equipment checking functions are defined in the clause "Identity Check Procedures". Equipment checking is optional.

For an Emergency Attach, the MS may have included the IMEI in the Attach Request message. If not, and the IMSI cannot be authenticated, the SGSN shall retrieve the IMEI from the MS.

For an Emergency Attach, the IMEI check to the EIR may be performed. If the IMEI is blocked, operator policies determine whether the Emergency Attach procedure continues or is stopped.

6) If there are active PDP contexts in the new SGSN for this particular MS (i.e. the MS re-attaches to the same SGSN without having properly detached before), the new SGSN deletes these PDP contexts by sending Delete PDP Context Request (TEID) messages to the GGSNs involved. The GGSNs acknowledge with Delete PDP Context Response (TEID) messages.

7) If the SGSN number has changed since the GPRS detach, or if it is the very first attach, or if the Automatic Device Detection (ADD) function is supported and the IMEISV has changed (see TS 22.101 [82] for ADD functional requirement), or if the MS provides an IMSI or the MS provides an old P-TMSI/RAI which doesn’t point to a valid context in the SGSN, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the RAI supplied by the RNC is different from that of the RAI in the UE’s context, then the SGSN informs the HLR:

a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI, IMEISV, Update Type, Homogenous Support of IMS Voice over PS Sessions, UE SRVCC capability, equivalent PLMN list, Registration For SMS Request, SMS in SGSN offered) to the HLR. IMEISV is sent if the ADD function is supported. Update Type indicates an initial attach via initial attach indicator as this is an Attach procedure. The inclusion of the equivalent PLMN list indicates that the SGSN supports the inter-PLMN handover to a CSG cell in an equivalent PLMN using the subscription information of the target PLMN. If the S6d interface is used between S4-SGSN and HSS, a parameter "SMS in SGSN offered" is included in the Update Location message. When Gr is used, this parameter is included in the Insert Subscriber Data Ack (Step 7g). "SMS in SGSN offered" indicates that the SGSN supports SMS services via SGSN.

The "Homogenous Support of IMS Voice over PS Sessions" indication (see clause 5.3.8A) shall not be included unless the SGSN has completed its evaluation of the support of "IMS voice over PS Session" as specified in clause 5.3.8.

NOTE 3: At this step, the SGSN may not have all the information needed to determine the setting of the IMS voice over PS Session Supported indication for this MS (see clause 5.3.8). Hence the SGSN can send the "Homogenous Support of IMS Voice over PS Sessions" later on in this procedure.

If the SGSN determines that only the UE SRVCC capability has changed, the SGSN sends a GPRS Update Location to the HSS to inform about the changed UE SRVCC capability.

b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN. Also, because the Update Type indicates an initial attach via initial attach indicator, if the HSS has the MME registration, the HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The Cancellation Type indicates the old MME or SGSN to release the old Serving GW / PDN GW resource.

c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that MS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts.

d) If there are active PDP contexts in the old SGSN for this particular MS, the old SGSN deletes these PDP contexts by sending Delete PDP Context Request (TEID) messages to the GGSNs involved.

e) The GGSNs acknowledge with Delete PDP Context Response (TEID) messages.

f) The HLR sends Insert Subscriber Data (IMSI, Subscription Data) to the new SGSN. If the S6d interface is used between an S4-SGSN and HSS the message "Insert Subscriber Data" is not used. Instead, the Subscription Data is sent by HSS in the message Update Location Ack. (Step 7h). The subscription data may contain the CSG subscription data for the PLMN and the WLAN offloadability indication (see clause 5.3.21).

The subscription data may contain Enhanced Coverage Restricted parameter. If received from the HLR, SGSN stores this Enhanced Coverage Allowed parameter in the SGSN MM context.

If the MS initiates the Attach procedure at a CSG cell, the new SGSN shall check whether the CSG ID and associated PLMN is contained in the CSG subscription and is not expired. If the CSG ID and associated PLMN is not present or expired, the SGSN shall send an Attach Reject message to the MS with an appropriate cause value. The MS shall remove the CSG ID and associated PLMN from its Allowed CSG list, if present.

g) The new SGSN validates the MS’s presence in the (new) RA. If due to regional subscription restrictions or access restrictions (see clause 5.3.19) e.g. CSG restrictions, the MS is not allowed to attach in the RA, the SGSN rejects the Attach Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If subscription checking fails for other reasons, the SGSN rejects the Attach Request with an appropriate cause and returns an Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a ‘Network Sharing Supporting MS’, in this case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of rejecting the Attach Request message. If all checks are successful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI, SMS in SGSN offered) message to the HLR. The "SMS in SGSN offered" indicates that the SGSN supports SMS services via SGSN. If the S6d interface is used between S4-SGSN and HSS the message "Insert Subscriber Data Ack" is not used. Instead the subscription data check performed by S4-SGSN is done when the S4-SGSN has received the message "Update Location Ack" from HSS (Step 7h).

h) The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after the cancelling of old MM context and insertion of new MM context are finished. If the S6d interface is used the Update Location Ack messages includes the subscription Data. The subscription data may contain Enhanced Coverage Restricted parameter. If received from the HSS, SGSN stores this Enhanced Coverage Allowed parameter in the SGSN MM context. The subscription data may contain the WLAN offloadability indication (see clause 5.3.21). If the Update Location is rejected by the HLR, the SGSN rejects the Attach Request from the MS with an appropriate cause. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a ‘Network Sharing Supporting MS’, in this case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of rejecting the Attach Request message.

If the HLR accepts to register the SGSN identity for terminating SMS services, the MS has indicated "SMS-only", then the HLR cancels the serving MSC if there is a serving MSC.

If the MS performs the attach procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the SGSN needs to retrieve the CSG subscription information of the MS from the CSS, the SGSN initiates the Update CSG Location Procedure with CSS as described in clause 6.16.

For an Emergency Attach in which the MS was not successfully authenticated, the SGSN shall not send an Update Location Request to the HLR.

For an Emergency Attach, the SGSN shall ignore any unsuccessful Update Location Ack from HLR and continue with the Attach procedure.

8) If Attach Type in step 1 indicated GPRS Attach while already IMSI attached, or combined GPRS / IMSI attached, then the VLR shall be updated if the Gs interface is installed. This step is not performed if:

– Subscription Data indicate by the Network Access Mode information that the subscription has no CS subscriber data; or

– Subscription Data have an HSS indication of "SMS in SGSN Support" and only SMS services are used in CS domain (the MS indicated "SMS-only" or the subscription is PS and SMS only) and the SGSN is configured to not establish Gs under that conditions.

When the SGSN does not provide functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the VLR number is derived from the RAI. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the VLR number. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HLR in step 6d). This operation marks the MS as GPRS-attached in the VLR.

a) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) message to the VLR. Location Update Type shall indicate IMSI attach if Attach Type indicated combined GPRS / IMSI attach. Otherwise, Location Update Type shall indicate normal location update. The VLR creates an association with the SGSN by storing SGSN Number. In networks that support network sharing, the Location Update Request includes the identity of the selected core network operator if the SGSN has received this information from the RAN, as described in TS 23.251 [83].

b) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR, equivalent PLMN list) to the HLR. The inclusion of the equivalent PLMN list indicates that the SGSN supports the inter-PLMN handover to a CSG cell in an equivalent PLMN using the subscription information of the target PLMN.

c) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old VLR.

d) The old VLR acknowledges with Cancel Location Ack (IMSI).

e) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, subscriber data) to the new VLR. The subscriber data may contain the CSG subscription data for the PLMNs.

f) The VLR acknowledges with Insert Subscriber Data Ack (IMSI).

g) After finishing the inter-MSC location update procedures, the HLR responds with Update Location Ack (IMSI) to the new VLR.

h) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN.

If the MS performs the attach procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the VLR needs to retrieve the CSG subscription information of the MS from the CSS, the VLR initiates the Update CSG Location Procedure with CSS as described in clause 6.16.

If the SGSN requires the RAN to check whether the UE capabilities are compatible with the network configuration to be able to set the IMS voice over PS Session Supported Indication (see clause 5.3.8) then the SGSN sends a UE Radio Capability Match Request to the RAN as defined in clause 6.9.5.

9) The SGSN selects Radio Priority SMS, and sends an Attach Accept (P‑TMSI, VLR TMSI, P‑TMSI Signature, Radio Priority SMS, IMS voice over PS Session Supported Indication, Emergency Service Support indicator, Enhanced Coverage Restricted parameter, SMS-Supported, Cause) message to the MS. P‑TMSI is included if the SGSN allocates a new P‑TMSI. The IMS voice over PS Session Supported Indication is set as described in clause 5.3.8.

If new SGSN has not received, from Step 8, Voice Support Match Indicator for the UE from the RAN then, based on implementation, the SGSN may set IMS Voice over PS session supported Indication and update it at a later stage.

The Emergency Service Support indicator informs the MS that Emergency PDP contexts are supported, i.e. the MS is allowed to request activation of emergency PDP contexts when needed.

"SMS-Supported" is indicated to the MS when the HSS has indicated "SMS in SGSN Support". It indicates to the MS that it can obtain SMS services via PS domain NAS from the SGSN. An MS that needs only PS services and SMS services via NAS should not perform any procedures via CS domain when it can obtain SMS services via PS domain NAS from SGSN. If step 8 was not performed, e.g. due to Subscription Data indicate by the Network Access Mode information that the subscription has no CS subscriber data, then SGSN indicates that the Attach was successful for GPRS only and a Cause indicates why the IMSI attach was not performed.

When receiving the Attach Accept message the E‑UTRAN capable UE shall set its TIN to "P‑TMSI" as no ISR Activated is indicated at Attach.

If the attach is initiated by manual CSG selection via a CSG cell, the MS upon receiving the Attach Accept message at a CSG cell shall add the CSG ID and associated PLMN of the cell where the MS has sent the Attach Request message to its Allowed CSG list if it is not already present. Manual CSG selection is not supported when an emergency service has been initiated.

If the SGSN decides to enable extended idle mode DRX for an MS that included the extended idle mode DRX parameters, it includes the extended idle mode DRX parameters information element.

If the MS initiates the Attach procedure at a hybrid mode CSG cell, the SGSN shall check whether the CSG ID is contained in the CSG subscription and is not expired. The SGSN shall send an indication whether the UE is a CSG member to the RAN along with the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members.

NOTE 4: If the MS receives a Attach Accept message via a hybrid cell, the MS does not add the corresponding CSG ID and associated PLMN to its Allowed CSG list. Adding a CSG ID and associated PLMN to the MS’s Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.

If the MS receives Enhanced Coverage Restricted parameter in the Attach Accept message, MS shall store this information and shall use the value of Enhanced Coverage Restricted parameter to determine if enhanced coverage feature should be used or not.

10) If P‑TMSI or VLR TMSI was changed, the MS acknowledges the received TMSI(s) by returning an Attach Complete message to the SGSN.

11) If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-allocation by sending a TMSI Reallocation Complete message to the VLR.

12) After step 7a, and in parallel to any of the preceding steps, the SGSN shall send either a GPRS Update Location (Homogeneous Support of IMS Voice over PS Sessions) to the HLR or, when the S6d interface is used, a Notify Request (Homogeneous Support of IMS Voice over PS Sessions) message to the HSS:

– if the SGSN has evaluated the support of IMS Voice over PS Sessions, see clause 5.3.8; and

– if the SGSN determines that it needs to update the Homogeneous Support of IMS Voice over PS Sessions, see clause 5.3.8A.

For an Emergency Attach the SGSN shall not check for access restrictions, regional restrictions, subscription restrictions (e.g. CSG restrictions) or perform CSG access control.

If the Attach Request cannot be accepted, the SGSN returns an Attach Reject (IMSI or IMEI, Cause) message to the MS. IMEI shall be sent if it is an Emergency Attach and no valid IMSI exists. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a ‘Network Sharing Supporting MS’, in this case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [83] instead of returning an Attach Reject (IMSI, Cause) message to the MS.

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]:

C1) CAMEL_GPRS_Attach and CAMEL_PS_Notification.

They are called in the following order:

– The procedure CAMEL_GPRS_Attach is called. In Figure 22, the procedure returns as result "Continue".

– Then the procedure CAMEL_PS_Notification is called. The procedure returns as result "Continue".

6.5.3A Combined GPRS / IMSI Attach procedure, Delete Bearer by the new SGSN, using S4

The procedure described in figures 22A shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given in clause 6.5.3.

Figure 22A: Combined GPRS / IMSI Attach Procedure

NOTE: Steps 6a and 6d are common for architecture variants with GTP based S5/S8 and PMIP‑based S5/S8. For a PMIP‑based S5/S8, procedure step (A) is defined in TS 23.402 [90]. Steps 6b and 6c concern GTP based S5/S8

6) If there are active PDP contexts in the new SGSN for this particular MS (i.e. the MS re‑attaches to the same SGSN without having properly detached before), the new SGSN deletes these PDP contexts by sending Delete Session Request (Cause, Operation Indication) messages to the GWs involved. If ISR is activated the Cause indicates that the old S‑GW shall delete the bearer resources on the other old CN node by sending Delete Session Request message to the other CN node. The Operation Indication flag is set by the new SGSN. This indicates to the S-GW that the S-GW shall initiate a delete procedure towards the PDN GW. The GWs acknowledges with Delete Session Response messages. If a PCRF is deployed, the PDN GW employs an IP‑CAN Session Termination procedure interacts with the PCRF to indicate that resources have been released.

6.5.3B Combined GPRS / IMSI Attach procedure, Delete Bearer by the old SGSN, using S4

The procedure described in figure 22B shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given by clause 6.5.3.

Figure 22B: Combined GPRS / IMSI Attach Procedure

NOTE: Steps 7d1 and 7e2 are common for architecture variants with GTP based S5/S8 and PMIP‑based S5/S8. For a PMIP‑based S5/S8, procedure step (A) is defined in TS 23.402 [90]. Steps 7d2 and 7e1 concern GTP based S5/S8.

d) If there are active PDP contexts in the old SGSN for this particular MS, the old SGSN deletes these PDP contexts by sending Delete Session Request (Cause, Operation Indication) messages to the GWs involved. If ISR is activated the Cause indicates that the old S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message to the other CN node. The Operation Indication flag is set by the old SGSN.This indicates to the S-GW that the S-GW shall initiate a delete procedure towards the PDN GW. The GWs return Delete Session Response message to the old SGSN. If a PCRF is deployed, the PDN GW employs an IP‑CAN Session Termination procedure.

e) The GWs acknowledge with Delete Session Response messages.