8a Signalling procedures between PFM SAPs

3GPP48.018Base Station System (BSS) - Serving GPRS Support Node (SGSN)BSS GPRS protocol (BSSGP)General Packet Radio Service (GPRS)Release 17TS

8a.1 Create BSS PFC procedure

8a.1.0 General

If the BSS receives a request to transfer an uplink or downlink LLC PDU for which it currently does not have a BSS packet flow context and the PFI does not indicate best-effort or SMS or TOM8 or signalling then the BSS should send a DOWNLOAD-BSS-PFC PDU to the SGSN and start timer T6. In the uplink case the TLLI, optional Radio Priority, and optional Packet Flow ID are received from the MS as defined in 3GPP TS 44.060. Until the BSS receives the BSS PFC the BSS shall handle uplink and downlink transfers according to a best-effort default aggregate BSS QoS profile. For uplink transfers the best-effort default profile is specific to the radio priority level.

If the BSS receives a request to transfer an uplink or downlink LLC PDU associated to a PFI indicating best-effort or SMS or TOM8 or signalling then the BSS may handle the corresponding transfer according to an operator-defined aggregate BSS QoS profile. Indeed the latter cannot be negotiated with the SGSN for those flows. It is also up to the implementation what Allocation/Retention Priority is granted to those flows.

If the BSS does not receive a PFI from the MS, e.g. from a R97 or R98 MS, the BSS shall not send a DOWNLOAD-BSS-PFC PDU to the SGSN. In this case the QoS Profile IE is utilized instead.

Following a DOWNLOAD-BSS-PFC PDU if there is not an ongoing Delete PFC procedure for that corresponding PFI, the SGSN shall send a CREATE-BSS-PFC PDU to the BSS with a requested Aggregate BSS QoS Profile and start timer T7. On receipt of CREATE-BSS-PFC PDU the BSS stops timer T6 and responds with a CREATE-BSS-PFC-ACK PDU containing the negotiated Aggregate BSS QoS Profile. The BSS may restrict the requested ABQP given its capabilities and the current load. The SGSN may include the Service UTRAN CCO (Cell Change Order) information element in the PDU (relevant if the network initiated cell change order to UTRAN, network initiated cell change order to E-UTRAN, PS handover to UTRAN or PS Handover to E-UTRAN procedures are used). If this information element is received in multiple PDUs (either DL-UNITDATA PDU(s), CREATE-BSS-PFC PDU(s) or PS-HANDOVER-REQUEST PDU(s)), the information element contained in last received PDU shall take precedence. If there is an ongoing Delete PFC procedure the SGSN shall not send a CREATE-BSS-PFC-PDU (see subclause 8a.3).

The SGSN may also initiate the Create BSS PFC procedure. It is not required that the SGSN receive a DOWNLOAD‑BSS-PFC PDU before sending a CREATE-BSS-PFC request.

The CREATE-BSS-PFC PDU may trigger a call admission control algorithm in the BSS to check whether the requested ABQP can be served. If there is valid MS Radio Access Capability IE known by the SGSN for the associated MS, the SGSN shall include it in the CREATE-BSS-PFC PDU. If the MS Radio Access Capability IE are not present in the request, then the Radio Access Capability Update procedure may be called.

The BSS may return a CREATE-BSS-PFC-NACK with a cause if it is unable to create or modify the PFC. On receipt of a CREATE-BSS-PFC-ACK PDU which does not convey the cause ‘PFC queuing’ (cf. sub-clause 8a.1.0a) or of a CREATE-BSS-PFC-NACK PDU the SGSN shall stop timer T7.

The Packet Flow Timer (PFT) is provided to the BSS by the SGSN. It is defined as the maximum time the BSS may hold the PFC during periods of inactivity for a PFC. The timer is started upon the receipt of a CREATE-BSS-PFC PDU and restarted after the transmission of an uplink PDU for that PFC. The timer is also restarted upon the transfer of the corresponding PFC from an old to a new cell.

If a CREATE-BSS-PFC PDU is received for an MS which has a BSS PFC in the BSS, then this shall be interpreted by the BSS as a request to:

– create a new PFC if the PFI included in the PDU is not known in the BSS,

– modify an existing PFC if the PFI included in the PDU is already known in the BSS.

The SGSN may inform the BSS about the contents of SPID in the CREATE-BSS-PFC PDU. In this case the SPID is stored in the BSS.

8a.1.0a Allocation/Retention Priority handling

The SGSN may include the Allocation/Retention Priority information element in the CREATE-BSS-PFC- PDU. If this information element is received and the BSS supports ARP handling, the BSS shall establish or modify the resources according to the values of the Allocation/Retention Priority IE (priority level, pre-emption indicators, queuing) and the resource situation as follows:

– The BSS shall consider the priority level of the requested PFC, when deciding on the resource allocation.

– If the requested PFC is allowed for queuing and the resource situation so requires, the BSS may place the PFC in the establishment queue.

– The priority levels and the pre-emption indicators may (singularly or in combination) be used to determine whether the PFC assignment has to be performed unconditionally and immediately. If the requested PFC is marked as "may trigger pre-emption" and the resource situation so requires, the BSS may trigger the pre-emption procedure which may then cause the forced release of a lower priority PFC which is marked as "pre-emptable". Whilst the process and the extent of the pre-emption procedure is operator dependent, the pre-emption indicators, if given in the CREATE-BSS-PFC PDU, shall be treated as follows:

1. The values of the last received Pre-emption Vulnerability IE and Priority Level IE shall prevail.

2. If the Pre-emption Capability IE is set to "may trigger pre-emption", then this allocation request may trigger the pre-emption procedure.

3. If the Pre-emption Capability IE is set to "shall not trigger pre-emption", then this allocation request shall not trigger the pre-emption procedure.

4. If the Pre-emption Vulnerability IE is set to "pre-emptable", then this connection shall be included in the pre-emption process.

5. If the Pre-emption Vulnerability IE is set to "not pre-emptable", then this connection shall not be included in the pre-emption process.

6. If the Priority Level IE is set to "no priority" the given values for the Pre-emption Capability IE and Pre-emption Vulnerability IE shall not be considered. Instead the values "shall not trigger pre-emption" and "not pre-emptable" shall prevail.

– If the Allocation/Retention Priority IE is not given in the CREATE-BSS-PFC -PDU, the allocation request shall not trigger the pre-emption process and the connection may be pre-empted and considered to have the value "lowest" as priority level. Moreover, queuing shall not be allowed.

– The BSS pre-emption process shall keep the following rules:

1) The BSS shall only pre‑empt PFCs with lower priority, in ascending order of priority.

2) The pre-emption may be done for PFCs belonging to the same MS or to other MSs.

If the BSS is unable to create the PFC immediately and the ARP IE was present in the CREATE-BSS-PFC PDU indicating that queuing is allowed for the PFC, the BSS may put the PFC creation request or modification in a queue. In that case, it shall send a CREATE-BSS-PFC-ACK PDU including the cause ‘PFC queuing’ to the SGSN and start the timer T10. This timer specifies the maximum time for queuing of the request of establishment or modification; its value is provided by the SGSN in the CREATE-BSS-PFC PDU. Several PFCs for a given MS may be queued in parallel. While a PFC is queued, the BSS shall handle the corresponding uplink or downlink transfers according to a best-effort default aggregate BSS QoS profile.

For each PFC that is queued the following outcomes shall be possible:

– successfully established or modified;

– failed to establish or modify;

– failed due to expiry of the timer T10.

When the SGSN receives the response that the requested PFC is queued, the SGSN shall expect the BSS to provide the outcome of the queuing function for the PFC before expiry of T7. In case the timer T7 expires, the SGSN shall consider the create BSS PFC procedure terminated and failed.

The BSS shall report the outcome of the queuing for every queued PFC. The BSS shall stop the timer T10 associated to a given PFC when it has been successfully established or modified. The BSS shall then send a CREATE-BSS-PFC-ACK PDU with cause ‘PFC created successfully’ to the SGSN for that PFC, informing the SGSN of the negotiated ABQP. Upon receipt of the CREATE-BSS-PFC-ACK PDU with cause ‘PFC created successfully’ from the BSS, the SGSN shall stop timer T7.

In the case the timer T10 expires, the create BSS PFC procedure terminates in the BSS for the corresponding PFC and the BSS shall send a CREATE-BSS-PFC-NACK PDU with cause ‘PFC create failure’. The SGSN shall then consider the create BSS PFC procedure terminated and failed.

In case the SGSN wishes to delete a PFC which is being queued, it shall stop timer T7 and start the delete BSS PFC procedure. Upon receipt of the request to delete the PFC, the BSS shall take it out from the queue and proceed with the rest of the procedure, as described in sub-clause 8a.3.

In case the SGSN wishes to modify a PFC which is being queued, it shall restart timer T7 and send a CREATE-BSS-PFC PDU as described in sub-clause 8a.1. Upon receipt of the request to modify the PFC, the BSS shall take it out from the queue and treat the new request.

8a.1.1 Abnormal conditions

If the SGSN receives a DOWNLOAD-BSS-PFC PDU with an unknown PFI it shall not respond with a CREATE-BSS-PFC PDU.

If a CREATE-BSS-PFC PDU is not received for a DOWNLOAD-BSS-PFC PDU within T6 seconds, then the DOWNLOAD-BSS-PFC PDU shall be repeated a maximum of DOWNLOAD-BSS-PFC-RETRIES attempts. After DOWNLOAD-BSS-PFC-RETRIES + 1 attempts the procedure is stopped and the O&M system is informed. If a BSS PFC is not received then the BSS shall handle uplink and downlink transfers according to a best-effort default aggregate BSS QoS profile.

If a CREATE-BSS-PFC-ACK or CREATE-BSS-PFC-NACK PDU is not received in response to a CREATE-BSS-PFC PDU within T7 seconds, then the CREATE-BSS-PFC PDU shall be repeated a maximum of CREATE-BSS-PFC-RETRIES attempts. After CREATE-BSS-PFC-RETRIES+1 attempts the procedure is stopped and the O&M is informed.

If a BSS not supporting ARP handling is unable to create the PFC then a CREATE-BSS-PFC-NACK PDU is returned with a cause value (e.g. Cause value: PFC create failure). The SGSN shall stop the Create BSS PFC procedure.

If a BSS supporting ARP handling is unable to create the PFC immediately and the ARP IE was not present in the CREATE-BSS-PFC PDU or the ARP IE was present but queuing is not allowed for the PFC, then a CREATE-BSS-PFC-NACK PDU is returned with cause value ‘PFC create failure’. The SGSN shall then stop the Create BSS PFC procedure.

If a CREATE-BSS-PFC PDU is received in the BSS for an MS for which the PS Handover Required procedure is ongoing, the BSS shall ignore the CREATE-BSS-PFC PDU and return a CREATE-BSS-PFC-NACK PDU to the SGSN indicating Cause "MS under PS Handover treatment".

8a.2 Modify BSS PFC procedure

The BSS may request modification of the contents of an existing BSS PFC at any time via the MODIFY-BSS-PFC PDU, e.g. due to a change in resource availability at the BSS. The BSS sends the MODIFY-BSS-PFC PDU and start timer T8. The SGSN inserts the modified parameters in the MODIFY-BSS-PFC PDU into the relevant PDP contexts. The SGSN shall respond to a modify request with a MODIFY-BSS-PFC-ACK PDU except when there is an ongoing Delete BSS PFC procedure for that PFI (see sub-clause 8a.3). The SGSN may restrict the requested aggregate BSS QoS profile given its capabilities and current load. The Packet Flow Timer (PFT) may be provided to the BSS by the SGSN. This timer is (started or) restarted upon the receipt of the MODIFY‑BSS‑PFC-ACK PDU and restarted after the transmission of an uplink PDU for that PFC. On receipt of a response to the Modify procedure the BSS shall stop timer T8.

The SGSN can reject the profile proposed by the BSS by answering with a MODIFY-BSS-PFC-ACK PDU containing the previous ABQP. The SGSN may request the modification of the contents of a BSS PFC at any time via the CREATE-BSS-PFC PDU, e.g. due to the activation, modification, or deactivation of a PDP context. It shall not use the MODIFY-BSS-PFC PDU. If the BSS PFC already exists the BSS shall interpret the PDU as a modification request and the BSS shall reply with a CREATE-BSS-PFC-ACK. The BSS may restrict the requested ABQP given its capabilities and the current load.

The Modify BSS PFC procedure shall never be initiated for an MS for which the PS Handover Required procedure is ongoing.

8a.2.1 Abnormal conditions

If a MODIFY-BSS-PFC-ACK is not received in response to a MODIFY-BSS-PFC PDU within T8 seconds, then the MODIFY-BSS-PFC PDU shall be repeated a maximum of MODIFY-BSS-PFC-RETRIES attempts. After MODIFY‑BSS-PFC-RETRIES+1 attempts the procedure is stopped and the O&M is informed.

8a.3 Delete BSS PFC procedure

The SGSN may request the deletion of a BSS PFC at any time using the DELETE-BSS-PFC PDU. The BSS shall respond with a DELETE-BSS-PFC-ACK PDU. In case of user inactivity the BSS may delete a BSS packet flow context without notifying the SGSN. In case the BSS is no longer able to support the BSS PFC ABQP, it may send a DELETE-BSS-PFC-REQ PDU with cause ‘PFC pre-empted’ or ‘ABQP no more supported’ to the SGSN. The SGSN may either start the Delete BSS PFC procedure or a new Create BSS PFC procedure. In case the BSS receives neither a DELETE-BSS-PFC PDU nor a CREATE-BSS-PFC PDU the behaviour in the BSS is implementation specific.

The Delete BSS PFC procedure takes precedence over the Modify BSS PFC and the Create BSS PFC procedures, i.e. when the BSS receives a DELETE-BSS-PFC PDU it shall abort any ongoing Create BSS PFC or Modify BSS PFC procedure for that PFI.

If a DELETE-BSS-PFC PDU is received for an MS for which the PS Handover Required procedure is ongoing, the BSS shall initiate the PS Handover Cancel procedure and continue the Delete BSS PFC procedure for the corresponding MS.

8a.4 PS Handover Required procedure

In the case of an intra-BSS PS Handover or intra-BSS DTM Handover, the optimized intra-BSS handover procedure may be used (see 3GPP TS 44.060); in such case, the PS Handover Required procedure is not used.

When a BSS initiates a PS handover or DTM Handover it shall initiate the PS Handover Required procedure and send the PS-HANDOVER-REQUIRED PDU to the SGSN. Except in the case of DTM Handover, the BSS shall then start timer T12 (see NOTE).

NOTE: The DTM Handover procedure is guarded at the source BSS by the BSSMAP timer T23 (see 3GPP TS 48.008).

If DTM Handover is ongoing and was initiated for a reason specific to the packet resources, or PS Handover is ongoing, the Cause IE of the PS-HANDOVER-REQUIRED PDU should be set to an appropriate value (e.g. "Uplink quality", "Uplink strength", "Downlink quality", "Downlink strength", "Distance", "Better cell", "Traffic" or "O&M intervention").

NOTE: The radio related cause values are not applicable to the DTM Handover.

If DTM Handover is ongoing, and was initiated for a reason specific to the dedicated resource, the Cause IE shall indicate "CS cause".

The BSS should not initiate the PS handover required procedure in the case of an MOCN or a GWCN configuration if the Rerouting procedure is ongoing.

The BSS shall not initiate the PS handover required procedure in case CS to PS SRVCC from GERAN to UTRAN or to E-UTRAN [25] is ongoing. The reception of a PS-HANDOVER-REQUIRED PDU will initiate the PS Handover Required procedure in the SGSN and the allocation of resources in the target system.

If PS handover to A/Gb mode is required, the source BSS shall include the Source BSS to Target BSS Transparent Container IE and the Target Cell Identifier IE in the PS-HANDOVER-REQUIRED PDU.

If PS handover to Iu mode is required, the source BSS shall include the Source to Target Transparent Container IE and the Target RNC Identifier IE in the PS-HANDOVER-REQUIRED PDU. The Source to Target Transparent Container IE shall be encoded as the Source RNC to Target RNC Transparent Container IE as specified in 3GPP TS 25.413 or 3GPP TS 44.118.

If PS handover to a UTRAN CSG cell or hybrid cell is required, the source BSS shall include the Source to Target Transparent Container IE, Target RNC Identifier IE and the CSG Identifier IE in the PS-HANDOVER-REQUIRED PDU. The source BSS shall set the value of the Cell Access Mode field in the CSG Identifier IE according to the information received from the MS through measurement reporting as defined in 3GPP TS 44.060. The Source to Target Transparent Container IE shall be encoded as the Source RNC to Target RNC Transparent Container IE as specified in 3GPP TS 25.413.

NOTE: In this specification: A CSG cell is a reported cell for which the access mode indicates “Closed access mode” as defined in [39] and Hybrid Cell is a reported cell for which the access mode indicates “Hybrid access mode” as defined in [39].

If PS handover to E-UTRAN is required, the source BSS shall include the Source to Target Transparent Container IE and the Target eNB Identifier IE or the Target RNC Identifier IE (carrying the Corresponding RNC-ID of the target eNB) in the PS-HANDOVER-REQUIRED PDU. The Source to Target Transparent Container IE shall be encoded as the Source eNB to Target eNB Transparent Container IE as specified in 3GPP TS 36.413.

If PS handover to a E-UTRAN CSG cell or hybrid cell is required, the source BSS shall include the Source to Target Transparent Container IE, the Target eNB Identifier IE, Tracking Area Code IE and the CSG Identifier IE in the PS-HANDOVER-REQUIRED PDU. The source BSS shall set the value of the Cell Access Mode field in the CSG Identifier IE according to the information received from the MS through measurement reporting as defined in 3GPP TS 44.060. The Source to Target Transparent Container IE shall be encoded as the Source eNB to Target eNB Transparent Container IE as specified in 3GPP TS 36.413.

The Active PFCs List IE informs the SGSN about which PFCs that are active for the MS in the source cell at the time of sending the PS-HANDOVER-REQUIRED PDU. The concept of "Active PFCs" is defined in 3GPP TS 43.129. The Active PFCs List IE shall not contain any pre-defined PFIs.

For DTM Handover to A/Gb mode, the source BSS shall include the CS Indication IE in the Source BSS to Target BSS Transparent Container IE. The contents of the CS Indication IE shall uniquely identify, for this MS, the handover attempt, and shall be identical to the contents of the PS Indication IE included in the BSSMAP HANDOVER REQUIRED message (see 3GPP TS 48.008). The Target Cell Identifier IE shall identify the same cell as the one specified in the Cell Identifier List (preferred) IE in the corresponding BSSMAP HANDOVER REQUIRED message (see 3GPP TS 48.008).

For DTM Handover to UTRAN, the source BSS shall set the Number of Iu Instances IE equal to 2 in the Source RNC to Target RNC Transparent Container IE (see 3GPP TS 25.413)

When the resource allocation in the target system is complete, the SGSN shall send a PS-HANDOVER-REQUIRED-ACK PDU to the source BSS and end the PS Handover Required procedure.

The Target BSS to Source BSS Transparent Container IE, or the Target to Source Transparent Container IE as received from the target system, shall be included in the PS-HANDOVER-REQUIRED-ACK PDU.

Except in the case of DTM Handover, the source BSS shall, on reception of the PS-HANDOVER-REQUIRED-ACK PDU from the SGSN, stop timer T12, trigger the transmission of the PS HANDOVER COMMAND message towards the MS (as specified in 3GPP TS 44.060) and end the PS Handover Required procedure. In the case of DTM Handover, the PS Handover Required procedure is terminated when timer T23 is stopped for any reason or expires as specified in 3GPP TS 48.008. The subsequent behaviour of the network is specified in 3GPP TS 48.008.

In case of unsuccessful PS Handover, the source BSS shall be notified through the PS-HANDOVER-REQUIRED-NACK PDU.

When the SGSN terminates the PS Handover Required procedure by sending a PS-HANDOVER-REQUIRED-NACK PDU to the source BSS, the Cause IE should be set to an appropriate value (e.g. "PFC create failure", "Cell traffic congestion", "Equipment failure", "O&M intervention" , "PS Handover Target not allowed" or "PS Handover not Supported in Target BSS or Target System").

Except in the case of DTM Handover, upon reception of a PS-HANDOVER-REQUIRED-NACK PDU from the SGSN, the source BSS shall stop timer T12 and terminate the ongoing PS Handover Required procedure.

For DTM Handover, the source BSS behaviour on receipt of a PS-HANDOVER-REQUIRED-NACK PDU is described as part of the Handover Required procedure (see 3GPP TS 48.008).

The source BSS shall always include the “Reliable Inter RAT Handover Info” indicator set to ‘1’in the PS-HANDOVER-REQUIRED-PDU when the target is a GERAN A/Gb mode BSS if the Inter RAT Handover Info IE is available and was received from the SGSN in a PS-HANDOVER-COMPLETE-ACK or a CREATE-BSS-PFC PDU or a PS-HANDOVER-REQUEST PDU with “Reliable Inter RAT Handover Info Indicator” set to “1”. It shall be set to ‘0’ otherwise.

If the SGSN receives the CSG Identifier IE in the PS-HANDOVER-REQUIRED PDU and the Cell Access Mode field is set to “CSG cell”, it shall perform access control as specified in 3GPP TS29.060. If the MS is allowed to access the target cell, the SGSN shall continue the PS handover to the target side as specified in 3GPP TS 29.060. If the MS is not allowed to access the target cell, the SGSN shall send the PS-HANDOVER-REQUIRED-NACK PDU with the Cause IE set to “Invalid CSG cell”to the source BSS. If the Cell Access Mode field in the CSG Identifier IE is set to “Hybrid cell”, the SGSN shall provide the CSG membership status of the MS and the CSG Id to the target side as specified in 3GPP TS 29.060.

8a.4.1 Abnormal conditions

Except in the case of DTM Handover, if timer T12 expires in the source BSS and there has been no response from the SGSN to the PS-HANDOVER-REQUIRED PDU, the source BSS may initiate a new PS Handover Required procedure for the same mobile station, either directly or after first having cancelled the previous PS Handover Required procedure by initiating the PS Handover Cancel procedure with the value for the Cause IE set to "T12 expiry".

NOTE: For the case of DTM Handover, the abnormal condition caused by the expiry of BSSMAP timer T23 is described in 3GPP TS 48.008.

8a.5 PS Handover Request procedure

The SGSN shall initiate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST PDU, including the NAS container for PS Handover corresponding to the PFCs to be set-up (except in the case of intra-SGSN PS handover), to the target BSS and starting timer T13. The PS-HANDOVER-REQUEST PDU shall be sent on the point-to-point BVC indicated by the target Cell identity received from the old system.

On receipt of a PS-HANDOVER-REQUEST PDU containing a CS Indication IE (i.e. a DTM Handover procedure is ongoing), then the target BSS shall proceed as follows:

– If the timer T24 (see 3GPP TS 48.008) is not running, then the target BSS shall start timer T24.

– When both PS-HANDOVER-REQUEST PDU and BSSMAP HANDOVER REQUEST messages have been received and the contents of the CS Indication IE and PS Indication IE are identical, the target BSS shall stop timer T24 (see 3GPP TS 48.008), and, provided that a dedicated resource has been allocated (see 3GPP TS 48.008), attempt to create a new BSS Context for the MS, create PFCs according to the received ABQP parameters and allocate TBF resources within the capabilities of the mobile station.

On receipt of a PS-HANDOVER-REQUEST PDU which does not contain a CS Indication IE, the target BSS shall create a new BSS Context for the MS, create PFCs according to the received ABQP parameters and allocate TBFs for uplink and, if needed, for downlink transmission.

The SGSN may include the Service UTRAN CCO (Cell Change Order) information element in the PS-HANDOVER-REQUEST PDU (relevant if the network initiated cell change order to UTRAN, network intitiated cell change order to E-UTRAN,PS handover to UTRAN or PS Handover to E-UTRAN procedures are used). If this information element is received in multiple PDUs (either DL-UNITDATA PDU(s), CREATE-BSS-PFC PDU(s) or PS-HANDOVER-REQUEST PDU(s)), the information element contained in the last received PDU shall take precedence.

The SGSN receiving the Reliable Inter RAT Handover Info IE in the PS-HANDOVER-REQUIRED PDU shall forward this IE to the target BSS in the PS-HANDOVER-REQUEST PDU.

The Packet Flow Timer (PFT) is provided to the target BSS by the SGSN for each corresponding PFC. It is defined as the maximum time the BSS may hold the PFC during periods of inactivity for a PFC. The timer is started upon the initiation of the PS Handover Complete procedure (see sub-clause 8a.7) and restarted after the transmission of an uplink PDU for that PFC. The timer is also restarted upon the transfer of the corresponding PFC from an old to a new cell.

When resources have been successfully allocated by the target BSS, it shall send a PS-HANDOVER-REQUEST-ACK PDU to the SGSN. From this point in time, the target BSS shall be prepared to receive downlink LLC PDUs for the corresponding MS on the allocated resources. The target BSS shall also be prepared to receive uplink RLC data blocks or a PS HANDOVER ACCESS message upon successful MS access in the target cell (as specified in 3GPP TS 44.060).

The PS-HANDOVER-REQUEST-ACK PDU shall include the Target BSS to Source BSS Transparent Container IE (see sub-clause 11.3.79) which contains either a complete PS HANDOVER COMMAND message or, in the case of DTM Handover, a complete DTM HANDOVER COMMAND message. For the definition of the PS HANDOVER COMMAND and DTM HANDOVER COMMAND messages, see 3GPP TS 44.060. In addition, the BSS shall include in the Target BSS to Source BSS Transparent Container IE the SI/PSI Container IE (see sub-clause 11.3.95b) if the PS Handover Indications IE indicating "SI/PSI requested" was present in the Source BSS to Target BSS Transparent Container of the incoming PS-HANDOVER-REQUEST PDU. In the case where the target cell supports network sharing and the MS Radio Access Capability information element included in the Source BSS to Target BSS Transparent Container received in the PS-HANDOVER-REQUEST PDU indicates MS supporting network sharing , the target BSS shall include in the SI/PSI messages sent to the source BSS (if included in the Target BSS to Source BSS Transparent Container) the same PLMN ID as the one receieved in the Target Cell Identifier IE in the PS-HANDOVER-REQUEST PDU.

Upon reception of the PS-HANDOVER-REQUEST-ACK PDU, the SGSN shall stop timer T13, end the PS Handover Request procedure and start timer T14 for supervision of the PS Handover Complete procedure.

The target BSS may choose to terminate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN due to any of the following reasons:

– A BSS Context could not be allocated for the MS;

– None of the PFCs in the PFCs To Be Set-up List IE of the PS-HANDOVER-REQUEST PDU could be granted the requested QoS;

– No uplink TBF could be allocated for the MS in the BVCI.

In addition, the target BSS may choose to terminate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN if at least one of the PFCs in the PFCs To Be Set-up List IE of the PS-HANDOVER-REQUEST PDU could not be granted the requested QoS and the Cause IE indicates a non-critical PS or DTM handover.

NOTE: The cause values "Better cell", "Traffic" indicate a non-critical PS or DTM handover.

When a PS-HANDOVER-REQUEST-NACK PDU has been sent, no knowledge of the MS should be kept by the target BSS.

Except in case of an attempted DTM Handover, when the target BSS decides to terminate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN, the Cause IE should be set to an appropriate value (e.g. "PFC create failure", "Cell traffic congestion", "Equipment failure" or "O&M intervention").

In the case of an attempted DTM Handover, if the target BSS has failed to allocate PS resources, it shall send a PS-HANDOVER-REQUEST-NACK PDU with cause "DTM Handover – PS Allocation failure" to the SGSN. The target BSS may continue with the corresponding Handover Resource Allocation procedure, allocating only a dedicated resource (see 3GPP TS 48.008).

In the case of an attempted DTM Handover, if the target BSS does not allocate a CS resource, it shall not allocate any PS resources, and shall send a PS-HANDOVER-REQUEST-NACK PDU with cause "DTM Handover – No CS resource" to the SGSN.

The SGSN may inform the BSS about the contents of SPID in the PS-HANDOVER-REQUEST PDU. In this case the SPID is stored in the BSS.

8a.5.1 Abnormal conditions

If there is no response from the target BSS to the PS-HANDOVER-REQUEST PDU before timer T13 expires, the SGSN shall initiate the Delete BSS PFC procedure for each of the PFCs in the PFCs to be Set-up List IE for the corresponding MS.

If the timer T24 (see 3GPP TS 48.008) expires and the target BSS has received a PS-HANDOVER-REQUEST PDU (i.e. no corresponding BSSMAP HANDOVER REQUEST message has been received) the target BSS shall terminate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN with cause "DTM Handover – T24 expiry".

If a PS-HANDOVER-REQUEST PDU is received which contains a CS Indication IE which corresponds to a DTM Handover attempt which was previously terminated for this MS, then the BSS shall terminate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN with cause "DTM Handover – Invalid CS Indication IE". Any ongoing Handover Resource Allocation procedure (see 3GPP TS 48.008) for this mobile shall not be aborted in this case.

NOTE: Other failure cases related to the expiry of the A interface timer T24 are described in 3GPP TS 48.008).

If timer T14 expires before the SGSN receives a PS-HANDOVER-COMPLETE PDU, it shall initiate the Delete BSS PFC procedure for each allocated PFC (i.e. for each PFC included in the List of Set-up PFCs IE in the corresponding PS-HANDOVER-REQUEST-ACK PDU) towards the target BSS to release the resources allocated for all PFCs allocated for the MS.

8a.6 PS Handover Complete procedure

The target BSS shall initiate the PS Handover Complete procedure:

– in the case of PS Handover, on reception of the first correct RLC data block (sent in normal burst format as defined in 3GPP TS 44.060) from the MS in the target Cell;

– in the case of DTM Handover, on receipt of an RR HANDOVER COMPLETE message on the main DCCH in the target cell (see 3GPP TS 44.018).

The target BSS shall send a PS-HANDOVER-COMPLETE PDU to the SGSN.

From this point in time, the target BSS shall be prepared to receive uplink LLC PDUs from the corresponding MS on the allocated resources. Uplink LLC PDUs shall be sent from the target BSS to the SGSN with the TLLI received through the PS Handover Request procedure.

The target BSS supporting inter-RAT PS handover to UTRAN shall request the Inter RAT Handover Info IE from the SGSN upon successful PS handover completion in the following cases:

– PS handover from UTRAN to GERAN; in this case the BSS shall replace the Inter RAT Handover Info received from the source RNC with the new value received from the SGSN in the PS-HANDOVER-COMPLETE-ACK PDU.

– PS handover from GERAN A/Gb mode if it received PS-HANDOVER-REQUEST PDU with Reliable Inter RAT Handover Info IE missing or set to "0"; in this case the BSS shall replace the Inter RAT Handover Info received from the source BSS with the new value received from the SGSN in the PS-HANDOVER-COMPLETE-ACK PDU.

– PS handover from GERAN A/Gb mode if the "INTER RAT HANDOVER INFO" is missing in the Source BSS to Target BSS Transparent Container IE.

– PS handover from E-UTRAN if the "INTER RAT HANDOVER INFO" is missing in the Source BSS to Target BSS Transparent Container IE.

At reception of the PS-HANDOVER-COMPLETE PDU, the SGSN shall stop timer T14 (if running) and

– in case of non-optimised intra-BSS or intra-SGSN inter-BSS PS Handover, initiate the Delete BSS PFC procedure(s) towards the source BSS for each PFC corresponding to the MS in the source cell as described in sub-clause 8a.3; or

– in case of inter-SGSN PS Handover, send a Forward Relocation Complete message to the old SGSN (see 3GPP TS 29.060). The old SGSN shall initiate a Delete BSS PFC procedure for each PFC corresponding to the MS in the source cell towards the source BSS as described in sub-clause 8a.3.

8a.6.1 Abnormal conditions

If the SGSN does not receive a PS-HANDOVER-COMPLETE PDU before timer T14 expires, it shall initiate the Delete BSS PFC procedure towards the target BSS to release the resources for all PFCs allocated for the MS.

If a PS-HANDOVER-COMPLETE PDU refers to an MS which is unknown in the SGSN, it shall be ignored.

8a.7 PS Handover Cancel procedure

The source BSS may at any time, up to the time when the PS HANDOVER COMMAND or DTM HANDOVER COMMAND message is sent to the MS (as defined in 3GPP TS 44.060), initiate the PS Handover Cancel procedure. The reasons for cancellation could e.g. be "T12 expiry", "MS back on old channel", "Not all requested PFCs created" or "CS cause".

The source BSS shall initiate the PS Handover Cancel procedure if the cell change attempt fails and the MS returns to the old cell and sends either a PACKET CELL CHANGE FAILURE message as specified in 3GPP TS 44.060 (for PS Handover) or an RR HANDOVER FAILURE message as specified in 3GPP TS 44.018 (for DTM Handover) using the old radio resources.

During the normal intra-BSS or inter-BSS PS Handover, the source BSS shall also initiate the PS Handover Cancel procedure if it detects the loss of radio contact with MS (see 3GPP TS 44.060).The cause value in the PS-HANDOVER-CANCEL PDU shall be set to "Radio contact lost with MS". In the case of DTM Handover, the source BSS shall initiate the PS Handover Cancel procedure in the following additional cases defined in the list of Abnormal Cases for the Handover Required Indication procedure (see 3GPP TS 48.008):

a) Timer T23 expires and the source BSS has received a PS-HANDOVER-REQUIRED-ACK PDU from the SGSN;

b) The source BSS receives a PS-HANDOVER-REQUIRED-ACK PDU and a BSSMAP HANDOVER REQUIRED REJECT message (see 3GPP TS 48.008);

c) If the DTM Handover is ongoing and T8 expires (see 3GPP TS 48.008).

The cause value in the PS-HANDOVER-CANCEL PDU shall be set to:

in case a) above: "DTM Handover – T23 expiry";

in case b) above: "DTM Handover – MSC error";

in case c) above: "Radio contact lost with MS".

When the source BSS decides to cancel an ongoing PS handover or DTM Handover, it shall initiate the PS Handover Cancel procedure by sending a PS-HANDOVER-CANCEL PDU to the SGSN. The source BSS shall regard all procedures related to PS handover or DTM Handover for the given MS as terminated after having sent the PS-HANDOVER-CANCEL PDU to the SGSN.

Upon reception of a PS-HANDOVER-CANCEL PDU, (in the case of Inter-SGSN PS handover or Inter-SGSN DTM handover) the SGSN shall initiate a Forward Relocation Cancel procedure according to 3GPP TS 29.060.

Upon reception of a PS-HANDOVER-CANCEL PDU, (in the case of Intra-SGSN PS handover or Intra-SGSN DTM handover or Inter-RAT PS handover) the SGSN shall

– in case of GERAN A/Gb mode to GERAN A/Gb mode PS/DTM handover, initiate the Delete BSS PFC procedure towards the target BSS to release the resource allocated for the MS.

– in case of GERAN A/Gb mode to UTRAN PS/DTM handover, initiate the Iu Release procedure towards the target RNC to release the resource allocated for the UE (see 3GPP TS 25.413).

– in case of GERAN A/Gb mode to E-UTRAN PS handover, initiate the Relocation Cancel procedure towards target MME which initiates the release of the resources allocated for the UE by the target eNB (see 3GPP TS 36.413).

NOTE: In case of cancellation due to CS call establishment, current behaviour regarding possible suspension of GPRS services applies after the PS Handover Cancel procedure is completed.

8a.7.1 Abnormal conditions

If a PS-HANDOVER-CANCEL PDU refers to an MS/UE which is unknown in the SGSN, it shall be ignored.

An SGSN shall ignore a PS-HANDOVER-CANCEL PDU which refers to an MS for which the SGSN has already received a PS-HANDOVER-COMPLETE PDU from the target BSS (in the case of intra-SGSN PS handover) or a FORWARD RELOCATION COMPLETE message from the new SGSN (in the case of inter-SGSN PS handover).