8 Signalling procedures between NM SAPs
3GPP48.018Base Station System (BSS) - Serving GPRS Support Node (SGSN)BSS GPRS protocol (BSSGP)General Packet Radio Service (GPRS)Release 17TS
8.1 FLUSH-LL (logical link) procedure
When an SGSN detects a cell change of an MS from a cell update or a routing area update, the SGSN shall send a FLUSH-LL PDU to the old BVC to initiate the following procedures:
– at a cell change within one NSE (e.g. the BSS is a NSE) and within one routing area, LLC-PDU(s) for a given TLLI stored at an "old" BVCI (corresponding to the old cell) are either deleted or transferred to a "new" BVCI (corresponding to the new cell) with which the TLLI is currently associated; or
– at a cell change between two NSEs within one routing area, LLC PDU(s) for a given TLLI stored at an "old" BVCI (corresponding to the old cell) are either deleted or transferred to a "new" BVCI (corresponding to the new cell) with which the TLLI is currently associated. In that case, transferring of LLC PDU(s) can only be requested by the SGSN if the NSE underlying the "old" BVCI indicated support for the "Inter-NSE re-routing";
– at a cell change within the same routing area, and within one NSE or between two NSEs, the on-going location procedure, if any, is either maintained in the BSS after the cell reselection or aborted by the BSS towards the SMLC; or
– at a cell change between two routing areas, LLC-PDU(s) stored at the "old" BVCI for the TLLI are deleted.
The SGSN provides the BSSGP with:
– a MS’s TLLI identifying the MS;
– the "old" BVCI identifying the cell in which to find buffered LLC-PDU(s) for the MS;
– the "new" BVCI identifying the cell to which the MS is currently associated (only when within the same routing area); and
– if the SGSN supports "Inter-NSE re-routing" or "LCS Procedures" and the old NSE supports the "Inter-NSE re-routing" or "LCS Procedures", the "new" NSEI identifying the cell to which the MS is currently associated (only when within the same routing area but between two NSEs). The NSEI associated to the "old" BVCI shall be assumed if the "new NSEI" field is not provided.
If there is a BSS context for the MS in the "old" BVCI and there is a "new" BVCI in the FLUSH-LL PDU, the BSS shall interpret this as a request to transfer the BSS context to the new cell. The BSS shall assume that the ABQP that was negotiated for each PFC in the "old" BVCI is requested in the "new" BVCI by the SGSN. Also, the values of the Packet Flow Timer and the Service UTRAN CCO Information Elements should be kept for each transferred PFC. If, when receiving the BSS context at the "new" BVCI, the BSS has already obtained the information related to one or several PFC(s) from the SGSN by means of the Create BSS PFC procedure (see sub-clause 8a.1), then the BSS shall disregard the information corresponding to this (these) PFC(s) within the BSS context transferred from the "old" BVCI. If a Create BSS PFC procedure is ongoing when receiving the BSS context at the "new" BVCI, the BSS shall either apply the received information or carry on with the currently used ABQP until the procedure completes.
If a "new" BVCI is not provided, then the FLUSH-LL PDU shall be interpreted as an instruction to delete the queued LLC-PDU(s) at the old BVC, and also to delete the BSS context associated to the MS identified by the TLLI, if any exists in the "old" BVCI.
Queued BSSGP signalling, e.g. pages, shall not be affected by this procedure.
In response to a FLUSH-LL PDU the BSS shall send a FLUSH-LL-ACK PDU to the SGSN containing:
– the TLLI received in the FLUSH-LL PDU;
– an indication of whether the LLC-PDU(s) were "transferred" or "deleted". In case the SDUs were "transferred" the BVCI (new) IE, and the NSEI (new) IE if present in the FLUSH-LL PDU, shall be included;
– the number of octets that have been transferred or deleted.
NOTE: In situations where the BSS was unable to transfer the queued LLC-PDUs upon a transfer request from the SGSN, the BSS may indicate in the FLUSH-LL-ACK PDU a flush action set to "deleted" together with the number of octets actually deleted.
On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC have been "deleted", the SGSN may choose to:
– immediately retransmit all unacknowledged LLC-PDU(s) (in acknowledged LLC operation) to the MS at the new BVC (i.e. new cell); or
– rely on LLC retransmission mechanism to transmit unacknowledged LLC-PDU(s).
On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC have been "transferred", the SGSN shall not take any of the above actions.
If the "new" BVCI could not accept the QoS characteristics of all PFCs of the BSS context, the BSS context shall still be transferred and the BSS shall then initiate in the "new" BVCI a Modify BSS PFC procedure for each PFC for which the requested ABQP could not be accepted. The BSS may resume the transfer of downlink LLC PDU(s) before the Modify BSS PFC procedure is completed.
In order to avoid desequencing DL LLC PDU (in LLC acknowledged or unacknowledged operation) during the FLUSH procedure, upon sending a FLUSH-LL PDU to the BSS requesting the rerouting of DL LLC PDUs to a new cell, the SGSN should wait for the receipt of the FLUSH-LL-ACK PDU or rely on an internal guard timer, before starting to transmit subsequent DL LLC PDUs on the new BVCI. In the case the SGSN does not request the BSS to reroute DL LLC PDUs to a new cell, it may immediately resume the transmission of subsequent DL LLC PDUs on the new BVCI, or start the Create BSS PFC procedure, without waiting for the receipt of the FLUSH-LL-ACK PDU.
8.1.1 Abnormal Conditions
If the BSS receives a FLUSH-LL PDU for an unknown BVCI or TLLI not associated with the given BVCI, then the FLUSH-LL PDU is discarded and no FLUSH-LL-ACK PDU is returned.
If the SGSN does not receive a FLUSH-LL-ACK PDU in response to a FLUSH-LL PDU, no further action is taken.
8.2 Flow Control procedure
8.2.1 General model of operation
From the perspective of the BSSGP, the flow control mechanism is based on the following model:
– there is a downlink buffer for each BVC, as identified by a BVCI, in a BSS;
– the transfer of BSSGP UNITDATA PDUs for an MS from the SGSN is controlled by the BSS; and
– only downlink BSSGP UNITDATA PDU transfer to the BSS is managed via flow control procedures. Uplink flow control is not performed.
8.2.2 Mode of operation
The flow control mechanism manages the transfer of BSSGP UNITDATA PDUs sent by the SGSN on the Gb interface to the BSS.
The BSS shall control the flow of BSSGP UNITDATA PDUs to its BVC buffers by indicating to the SGSN the maximum allowed throughput in total for each BVC. The BSS shall control the flow of BSSGP UNITDATA PDUs to the BVC buffer for an individual MS by indicating to the SGSN the maximum allowed throughput for a certain TLLI. If the PFC Flow Control feature is negotiated, the BSS may control the flow of BSSGP UNITDATA PDUs to the BVC buffer for a certain PFC of an individual MS by indicating to the SGSN the maximum allowed throughput for a certain PFI.
If the Gigabit Interface feature has been negotiated, the granularity of the Flow Control related information elements such as the BVC Bucket Size IE, the BVC Bucket Leak Rate IE and the PFC flow control parameters IE shall be indicated through the Flow Control Granularity IE included in the same PDU (see sub-clauses 10.4.4, 10.4.6 and 10.4.24).
The BSS uses flow control to adjust the flow of BSSGP UNITDATA PDUs to a BVC buffer. The amount of buffered BSSGP UNITDATA PDUs in the BSS should be optimised to efficiently use the available radio resource. The volume of buffered BSSGP UNITDATA PDUs for a BVC or MS or PFC should be low. BSSGP UNITDATA PDUs queued within the BSS that are not transferred across the radio interface before the PDU Lifetime expires shall be locally deleted from the BSS. The local deletion of BSSGP UNITDATA PDUs in the BSS shall be signalled to the SGSN by the transmission of a LLC-DISCARDED PDU.
For each FLOW-CONTROL PDU received by an SGSN, a confirmation shall always be sent across the Gb interface by the SGSN. The confirmation uses the Tag that was received in the FLOW-CONTROL PDU, which was set by the BSS to associate the response with the request. When receiving no confirmation to a FLOW-CONTROL PDU, the reasons that gave rise to the triggering of a flow control message may trigger another message, or, if the condition disappears, it may not. For the repetition of non-confirmed FLOW-CONTROL PDUs, the maximum repetition rate still applies in the BSS.
8.2.3 Flow Control of Traffic from an SGSN to BSS
8.2.3.1 Control of the downlink throughput by the SGSN
The principle of the BSSGP flow control procedures is that the BSS sends to the SGSN flow control parameters which allow the SGSN to locally control its transmission output in the SGSN to BSS direction. The SGSN shall perform flow control on each BVC, on each MS and optionally on each PFC for an MS. The flow control is performed on each LLC‑PDU first by the PFC flow control mechanism if applicable and if negotiated, then by the MS flow control mechanism and then by the BVC flow control mechanism.
If the PFC Flow Control feature has been negotiated and the LLC-PDU corresponds to a PFC for which the SGSN has received some flow control parameters, then the SGSN has to check that the LLC-PDU is passed by the individual PFC flow control. If it is passed or if the PFC flow control has not been negotiated, or if it has been negotiated but no flow control parameter has been received for the PFC corresponding to the LLC-PDU, the SGSN applies the MS flow control. If passed, the SGSN finally applies the BVC flow control to the LLC-PDU. If an LLC-PDU is passed by all flow control mechanisms, the entire LLC-PDU is delivered to the Network Services for transmission to the BSS (see figure 8.1).
Figure 8.1: BSSGP Flow control
The flow control parameters sent by the BSS to the SGSN consist of the following information:
– the bucket size (Bmax) for a given BVC or MS or PFC in the downlink direction; and
– the bucket leak rate (R) for a given BVC or MS or PFC in the downlink direction; and
– the bucket full ratio for a given BVC or MS or PFC in the downlink direction, if the Current Bucket Level (CBL) feature is negotiated.
NOTE: The information for a given PFC is only received if the PFC flow control feature is negotiated.
The SGSN shall perform flow control on an individual MS using SGSN determined values of Bmax and R unless it receives a FLOW-CONTROL-MS PDU from the BSS regarding that MS. The SGSN shall continue to perform flow control for a particular MS using the Bmax and R values received from the BSS for at least Th seconds after receiving a FLOW-CONTROL-MS PDU from the BSS regarding that MS. When timer Th has expired or when the MS changes cells, the SGSN may reinitialise the SGSN internal flow control variables for that MS and begin to use SGSN generated values for Bmax and R.
The SGSN shall start performing flow control on a given PFC for an individual MS as soon as it receives the first FLOW-CONTROL-PFC PDU for that PFC and the feature has been negotiated; it shall stop applying PFC flow control for a given PFC of an individual MS as soon as it receives subsequently a FLOW-CONTROL-MS PDU for that MS or if more than Tf seconds have elapsed since the last FLOW-CONTROL-PFC PDU was received for that PFC. When the MS changes cells, the SGSN shall stop performing flow control per PFC, until it receives a FLOW‑CONTROL-PFC PDU .
In case the MS flow control parameters needs to be updated and the PFC flow control feature is negotiated and the PFC flow control parameters for that MS remains unchanged then the FLOW-CONTROL-PFC PDU is used by the BSS to update the MS flow control parameters. The "Number of PFCs" IE within the "PFC Flow Control parameters" IE shall be set to "0" in this case.
The BSSGP flow control model is the algorithm shown in Figure 8.2. The model of the algorithm is that an LLC-PDU is passed by the algorithm as long as the bucket counter (B) plus the length of the LLC-PDU does not exceed the bucket size Bmax. When the LLC-PDU is passed, the LLC-PDU length is added to B. Any PDU not transmitted is delayed until B plus the LLC-PDU length is less than Bmax.
8.2.3.2 Flow Control Conformance Definition
A BSSGP flow control algorithm shall be implemented in the SGSN. The BSSGP flow control conformance algorithm is defined in figure 8.2.
The conformance definition is used to decide which LLC-PDUs are conforming to the flow to the PFC of an MS, to an MS or in a BSSGP virtual connection (BVC) over the Gb interface. The conformance definition should not be interpreted as the required implementation algorithm, as the SGSN manufacturer may use any algorithm as long as the operation of the BSSGP flow control does not violate the objectives of compliant BVCs or MSs or PFC. That is, the SGSN shall never transmit more data than can be accommodated within the BSS buffer for a BVC or individual MS or for a given PFC of an MS.
Figure 8.2: Conformance Definition Algorithm for BSSGP Flow Control
The variables used by the algorithm are:
Bmax Bucket Size. Set by the BSS for each cell and each mobile station and optionally for each PFC of an MS. Bmax shall be large enough to accommodate at least one LLC-PDU;
R leak rate of the bucket;
B bucket counter;
B* predicted value of the bucket counter;
L(p) length of LLC-PDU p;
Tp the time that the last LLC-PDU p was transferred; and
Tc arrival time of LLC-PDU p.
The initial conditions of these variables in the SGSN are:
– Bmax = 0 for BVCs or MSs. For BVCs, this value is valid until Bmax is received in the FLOW-CONTROL-BVC. For MSs, this value is valid until Bmax_default_ MS is received in the FLOW-CONTROL-BVC PDU. Thereafter, sub-clause 8.2.3.6, shall apply;
– Bmax = 0 for PFCs until a FLOW-CONTROL-BVC PDU is received for the cell in which the PFC is running. Thereafter, Bmax for a PFC shall not be greater than Bmax of the corresponding MS until PFC flow control applies for the PFC. As long as PFC flow control applies, Bmax shall then not be greater than the value of Bmax provided in the latest valid FLOW-CONTROL-PFC PDU ;
– R = 0 for BVC or MSs. For a BVC, this value is valid until a FLOW-CONTROL-BVC PDU is received. For an MS, this value is valid until a FLOW-CONTROL-BVC PDU is received. Thereafter, sub-clause 8.2.3.6 shall apply;
– R = 0 for PFCs until a FLOW-CONTROL-BVC PDU is received for the cell in which the PFC is running. Thereafter, R for a PFC shall not be greater than R of the corresponding MS until PFC flow control applies for the PFC. As long as PFC flow control applies, R shall then not be greater than the value of R provided in the latest valid FLOW-CONTROL-PFC PDU ;
– B = 0 (the bucket is empty); and Tp = the current time for the first LLC-PDU.
The SGSN shall not transmit a LLC-PDU on a BVC until a FLOW-CONTROL-BVC PDU is received from the BSS for that BVC.
When a LLC-PDU p arrives at current time Tc, the variable B* is set to the predicted bucket size if the LLC-PDU were to be transferred to the BSS. This is given by the previous bucket size plus the new LLC-PDU size, B* = B + L(p), less the amount that the bucket will have leaked away since the last compliant LLC-PDU, R x (Tc – Tp). If this is less than L(p) then the LLC-PDU is compliant and the bucket size B is reset to L(p) and the LLC-PDU is passed. When a compliant LLC-PDU is passed the last LLC-PDU transfer time is set to the current time, Tp = Tc.
If the bucket has not completely leaked away then the bucket has to be checked to see if the limit Bmax is going to be exceeded, B* > Bmax. If the limit is exceeded then the LLC-PDU is non compliant and is delayed for some time period, and no updates are done on the variables. If the bucket limit Bmax is not exceeded then the LLC-PDU is compliant and the bucket counter (B) is set equal to the value of B*. When a conforming LLC-PDU is passed then the last LLC-PDU transfer time is set to the current time, Tp = Tc.
On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC have been "deleted", the SGSN should update the value of the bucket counter (B) for the MS and for the old BVC, B = max (B – N, 0). N is provided by FLUSH-LL-ACK PDU, indicating the number of octets deleted by the BSS.
On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC have been "transferred" within the NSE, the SGSN should update the value of the bucket counter (B) for the old BVC, B = max (B – N, 0). The value of B for the new BVC should also be updated, B = min (B + N, Bmax). N is provided by FLUSH-LL-ACK PDU, indicating the number of octets transferred by the BSS.
On receipt of a LLC-DISCARDED PDU by the SGSN, indicating that the LLC-PDU(s) associated with the MS or the PFC of an MS have been locally deleted by the BSS, the SGSN should update the value of the bucket counter (B) for the MS or the PFC and for the BVC, B = max (B – N, 0). N is provided by LLC-DISCARDED PDU, indicating the number of octets deleted by the BSS.
The BSS may update the values of Bmax and R within the SGSN at any time by transmitting a new Flow Control PDU containing the new Bmax and R values. The variables B, B*, Tp and Tc are local to the SGSN and are not affected by the reception of a Flow-Control-BVC or Flow Control-MS PDU.
If the Current Bucket Level (CBL) feature is negotiated, the SGSN shall update the variable B based upon the Bucket_Full_Ratio information element received in the Flow Control PDU. During the time period when SGSN does not receive a Flow Control PDU, it shall continue computing the bucket counter (B) as defined above.
8.2.3.3 Response time within the SGSN to flow control messages
Upon reception of flow control requests from a BSS, the SGSN shall modify its downlink transmission as instructed within 100 ms.
8.2.3.4 Frequency of sending BVC or MS or PFC Flow Control PDUs
The rate at which the BSS is allowed to send flow control PDUs for a given BVC or MS or PFC is limited and defined by the following rule: the BSS may send a new Flow Control PDU every C seconds, where C is a value which is pre‑defined and common to the BSS and SGSN.
If the BSS detects a missing FLOW-CONTROL-ACK PDU from the SGSN and the condition which causes the sending of a FLOW-CONTROL PDU still remains, the FLOW-CONTROL PDU may be retransmitted immediately. In this case the BSS may violate the repetition rate defined by the C value.
After a BVC reset procedure, the BSS may send a BVC-BLOCK PDU. Otherwise, the BSS shall send a BVC-FLOW-CONTROL PDU. When the blocked BVC is unblocked, a BVC-FLOW-CONTROL PDU shall be sent.
8.2.3.5 FLOW-CONTROL PDUs
Based on the criteria for flow control, a BSS shall send to an SGSN a FLOW-CONTROL PDU containing a list of IEs.
For BVC Flow Control, the following information is sent:
– the maximum bucket size (Bmax) for the BVC on the Gb Interface;
– the leak rate parameter (R) to be applied to the bucket;
– the bucket full ratio to resynchronize the bucket counter for the BVC, if the Current Bucket Level (CBL) feature is negotiated;
– the default MS bucket size (Bmax_default_MS);
– the default MS leak rate (R_default_MS); and
– the optional measurement of the delay for PDU delivery inside that BVC.
For MS Flow Control, the following information is sent:
– the TLLI identifying the MS;
– the maximum bucket size (Bmax) for this MS on the Gb interface;
– the leak rate parameter (R) to be applied to the bucket; and
– the bucket full ratio to resynchronize the bucket counter for the MS, if the Current Bucket Level (CBL) feature is negotiated.
For PFC Flow Control, the following information is sent:
– the TLLI identifying the MS;
– the maximum bucket size (Bmax) for this MS on the Gb interface (optional);
– the leak rate parameter (R) to be applied to the bucket (optional);
– the bucket full ratio to resynchronize the bucket counter for the MS, if the Current Bucket Level (CBL) feature is negotiated (optional);
– the number of PFCs for which flow control parameters are included;
for each PFC:
– the PFI identifying the PFC for that MS;
– the maximum bucket size (Bmax) for this PFC on the Gb interface;
– the leak rate parameter (R) to be applied to the bucket;
– the bucket full ratio to resynchronize the bucket counter for the PFC, if the Current Bucket Level (CBL) feature is negotiated.
NOTE: The supply of the MS flow control parameters inside the FLOW-CONTROL-PFC PDU allows the SGSN utilising the most up-to-date parameters both for PFC and MS flow control. Also, because the receipt of a FLOW-CONTROL-MS PDU notifies the end of PFC flow control for a given MS, if the MS flow control parameters have changed since the last update, then it is necessary to provide the MS flow control parameters inside the FLOW-CONTROL-PFC PDU.
8.2.3.6 Condition of Bmax for MS after Initial Flow-Control-BVC
The SGSN may use the following (informative) equation to generate an initial bucket size, Bmax, for an MS.
Bmax (bits) = min (R_default_MS for 1 s, 72 000, max MS throughput for 1 s, (max MS throughput for 1 s + current throughput of all other MSs in the cell for 1 s) / number of MSs in the cell)
where, the number of MSs in the cell includes the MS being added.
Under no circumstance shall the SGSN use a value of Bmax greater than Bmax_default_MS for an MS unless it receives a FLOW-CONTROL-MS PDU from the BSS for that MS.
The SGSN shall not use a leak rate (R) for an MS greater than R_default_MS unless it receives a FLOW-CONTROL-MS PDU from the BSS for that MS.
8.2.4 Flow Control of Uplink Traffic from a BSS to an SGSN
No flow control procedures are defined between the BSS and the SGSN in uplink direction.
8.3 BVC blocking and unblocking procedure
8.3.1 PTP BVC
The following statement applies only for PTP BVC.
The BVC blocking and unblocking procedures are initiated by the BSS to remove from use, or bring in to use, a BVC.
A BSS may block one BVC because of:
– operation and Maintenance intervention for a cell;
– equipment failure at the BSS;
– cell equipment failure at the BSS; or
– other causes not regarded in phase 1 of the implementation of GPRS (Cause Value: "reserved for future use").
When a BSS wishes to block a BVC, the BSS shall mark that BVC as blocked, thereafter discarding any traffic sent to the BVC in the uplink direction. The cell associated with the BVC should not accept data in the downlink direction. The BSS shall send a BVC-BLOCK PDU to the SGSN and start timer T1. The BVC-BLOCK PDU contains:
– the BVCI of the BVC to be blocked; and
– a Cause element indicating the reason for blocking (typical cause values: O&M intervention, Equipment failure).
On receipt of a BVC-BLOCK PDU, the SGSN shall mark the indicated BVC as blocked and stop transmitting traffic addressed to this BVC. The SGSN shall then acknowledge the blocking of the BVC by sending a BVC-BLOCK-ACK PDU to the BSS.
The BVC-BLOCK-ACK PDU contains the BVCI received in the BVC-BLOCK PDU.
On receipt of the BVC-BLOCK-ACK PDU the BSS shall stop timer T1.
The BVC shall be seen as blocked by an SGSN until a BVC-UNBLOCK PDU is received indicating that the BVC’s status has changed.
During the BVC blocking procedure, traffic in transit to or from a cell is in an indetermined state and may be lost. When unblocking a BVC both the BSS and SGSN shall be in an operational state, i.e. the underlying network service and the BVC shall be available for use.
If a BSS wishes to unblock a blocked BVC it shall send a BVC-UNBLOCK PDU, and start timer T1.
The BVC-UNBLOCK PDU contains:
– the BVCI of the BVC to be unblocked.
If a BVC-UNBLOCK PDU is received by an SGSN for a blocked BVC, the BVC shall be marked as unblocked and a BVC-UNBLOCK-ACK PDU shall be returned to the BSS, containing the BVCI received in the BVC-UNBLOCK PDU.
The BSS shall stop timer T1 on receipt of the BVC-UNBLOCK-ACK PDU and mark the BVC as unblocked.
8.3.2 Signalling BVC
The blocking and unblocking procedure is not applicable for the signalling BVC. The signalling BVC shall never be blocked.
8.3.3 Abnormal Conditions
The following statements apply only for a signalling BVC.
If a BVC-BLOCK PDU is received by an SGSN for the signalling BVC, the PDU is ignored.
If a BVC-BLOCK-ACK PDU is received by a BSS for the signalling BVC, the PDU is ignored.
If BVC-UNBLOCK PDU is received by an SGSN for the signalling BVC, the PDU is ignored.
If BVC-UNBLOCK-ACK PDU is received by an BSS for the signalling BVC, the PDU is ignored.
The following statements apply only for PTP BVC.
If a BVC-BLOCK-ACK PDU is not received for a BVC-BLOCK PDU within T1 seconds, then the BVC-BLOCK PDU procedure shall be repeated a maximum of BVC-BLOCK-RETRIES attempts. After BVC-BLOCK-RETRIES attempts the BVC remains blocked, the procedure is stopped and the O&M system is informed.
If a BVC-UNBLOCK-ACK PDU is not received for a BVC-UNBLOCK PDU within T1 seconds, then the BVC-UNBLOCK PDU procedure shall be repeated a maximum of BVC-UNBLOCK-RETRIES attempts. After BVC-UNBLOCK-RETRIES attempts the status of the BVC remains blocked, the procedure is stopped and the O&M system is informed.
If traffic is received on a BVC that is marked at a BSS or at an SGSN as blocked, and no BVC-Unblocking procedure is pending, the received PDU shall not be accepted and a STATUS PDU (Cause value: BVC blocked) shall be sent to the peer entity on the signalling BVC. The STATUS PDU shall indicate the BVCI of the BVC upon which the error was detected.
If a BVC-BLOCK PDU is received by an SGSN for a blocked BVC, a BVC-BLOCK-ACK PDU shall be returned.
If a BVC-UNBLOCK PDU is received by an SGSN for an unblocked BVC, a BVC-UNBLOCK-ACK PDU shall be returned.
If an unexpected BVC-BLOCK-ACK PDU is received by a BSS, and it is related to a BVC that is locally blocked, the BVC-BLOCK-ACK PDU is discarded. If the BVC-BLOCK-ACK PDU is related to a BVC that is not locally blocked, then a BVC unblock procedure shall be performed.
If an unexpected BVC-UNBLOCK-ACK PDU is received by a BSS and it is related to a BVC that is locally not blocked, the BVC-UNBLOCK-ACK PDU is discarded. If the BVC-UNBLOCK-ACK PDU is related to a BVC that is locally blocked, then a BVC block procedure shall be performed.
8.4 BVC-RESET procedure
The purpose of the BVC-RESET procedure is to synchronise the initialisation of GPRS BVC related contexts at a BSS and SGSN. This enables the BSS and SGSN to begin communication in known states. A BVC-RESET procedure is performed because of recovery procedures related to:
– a system failure in the SGSN or BSS that affects GPRS BVC functionality (e.g. processor recovery);
– an underlying network service system failure; or
– a change in the transmission capability of the underlying network service, where the "change" is from zero kbps to greater-than-zero kbps;
– a change in mapping between the BVCI and cell identifier.
The BSS may also send BVC-RESET as a means to create the initial mapping between BVCIs and cell identifications.
After any of the possible events stated above, the status of the affected BVCs may be inconsistent at the SGSN and the BSS. After performing the BVC Reset procedure all affected BVCs are assumed to be unblocked at the SGSN. The reset procedure forces a consistent state upon SGSN and BSS by requiring that after the completion of the BVC-Reset procedure the BSS initiates the block procedure for all affected BVCs that are marked as blocked at the BSS.
Before a BSS (or SGSN) sends a BVC-RESET PDU, the operational status of the associated network service shall be obtained by the BSS (or SGSN).
If the associated network service is operational, the BSS (or SGSN) shall send a BVC-RESET PDU to its peer entity and start timer T2. The BSS (or SGSN) may receive BVC related signalling and UNITDATA PDUs before the procedure is acknowledged, but shall not transmit PDUs.
If the associated network service is not operational, the BVC-RESET procedure is postponed until internal periodic status checks indicate that it is operational.
The BVC-RESET PDU contains:
– the BVCI of the reset BVC;
– a cause element indicating the reason for reset;
– the cell identifier, when the reset is for a PTP BVC and BSS is initiator of the reset;
– feature bitmap, when the reset is for a signalling BVC.
After the SGSN (or BSS) has initialised all affected GPRS related contexts, a BVC-RESET-ACK PDU is returned.
The BVC-RESET-ACK PDU contains:
– the BVCI of the reset BVC;
– the cell identifier, when the reset is for a PTP BVC and SGSN is initiator of the reset.
Upon reception by a BSS (or SGSN) of the BVC-RESET-ACK PDU the timer T2 is stopped.
8.4.1 Signalling BVC
After any failure affecting the NSE, the party (BSS or SGSN) where the failure resided shall reset the signalling BVC. After sending or receiving a BVC-RESET PDU for the signalling BVC, the BSS shall stop all traffic and initiate the BVC-RESET procedure for all BVCs corresponding to PTP functional entities of the underlying network service entity. The BSS must complete the BVC-RESET procedure for signalling BVC before starting PTP BVC-RESET procedures.
The Feature bitmap is sent to identify the optional features that can be supported by the network service entity. After completion of the signalling BVC-RESET procedure both entities shall locally determine the common set of optional features supported by both NSEs. This is done by performing the bit AND operation of the received Feature bitmap with its own Feature bitmap.
If the Feature bitmap IE is missing in a signalling BVC-RESET or BVC-RESET-ACK PDU or if the result of the AND operation is ‘0’ then no optional features are activated.
After sending or receiving a BVC-RESET PDU for the signalling BVC, the SGSN shall stop all traffic in the PTP BVCs of the corresponding NSE.
8.4.2 PTP BVC
After any failure affecting only part of the BVC functionality not including the signalling BVC the party where the failure resided shall reset only the affected BVCs.
If the BSS was the initiator of the BVC-RESET procedure, the BSS may initiate the blocking procedure upon receipt of a BVC-RESET-ACK PDU. If the SGSN was the initiator of the BVC-RESET procedure while the affected BVC is marked as blocked at the BSS side, the BSS shall initiate the BVC-Blocking procedure after having returned the BVC‑RESET-ACK PDU to the SGSN.
Upon reception of a BVC-RESET PDU, the SGSN (or BSS) shall discard UNITDATA PDUs addressed to the reset BVC.
After reset of a PTP BVC, UNITDATA PDUs addressed to the BVC may then be received and transmitted, unless it is blocked.
8.4.3 Abnormal Conditions
The following statements are valid for both signalling and PTP BVC.
If a BSS (or SGSN) sends a BVC-RESET PDU to an SGSN (or BSS) and the BVC-RESET-ACK PDU is not returned within a period T2, the BVC-RESET procedure shall be repeated a maximum of BVC-RESET-RETRIES attempts. After BVC-RESET-RETRIES attempts the procedure is stopped and the O&M system is informed. In case of PTP BVC, the status of all affected BVCs at the BSS (or SGSN) shall be blocked as a consequence.
If the BSS receives a BVC-RESET PDU for a BVCI which is unknown in the BSS, then the BSS shall return a STATUS PDU towards the SGSN including the BVCI and the cause value ‘BVCI unknown’.
If the BSS (or SGSN) has sent a BVC-RESET PDU for a BVCI to the SGSN (or BSS) and is awaiting a BVC-RESET-ACK PDU in response, but instead receives a BVC-RESET PDU indicating the same BVCI, then this shall be interpreted as a BVC-RESET ACK PDU and the T2 timer shall be stopped.
The BVC_RESET for signalling BVC overrides all pending procedures for PTP BVC, i.e. other pending procedures are stopped and corresponding running timers are stopped.
If the BSS (or SGSN) receives an unexpected BVC-RESET ACK PDU, this shall be ignored.
If the BSS has sent a BVC-UNBLOCK PDU and receives a BVC-RESET PDU before the BVC-UNBLOCK-ACK PDU has been received from the SGSN, then the BSS shall consider the corresponding BVC marked as unblocked.
8.5 Trace procedure
The purpose of the trace invocation procedure is to inform the receiving entity that it should begin producing a trace record on an MS. The trace is invoked by an SGSN by sending an SGSN-INVOKE-TRACE PDU to the peer entity. The SGSN-INVOKE-TRACE PDU is not acknowledged.
The events and parameters to be recorded are indicated in the "Trace type" information element are defined in 3GPP TS 32.008.
The remaining elements, when received, are to be passed transparently to the OMC receiving the trace record.
The element "OMCId", if present, indicates the OMC to which the record is destined.
The PDU includes a trace reference which is allocated by the entity which triggered the trace.
The element "TriggerId", if present, indicates the entity which triggered the trace.
The Trace Reference and TriggerId IEs are used to tag the trace record to allow simpler construction of the total record by the entity which combines trace records.
8.6 Overload Control procedure
8.6.1 General
This procedure is defined to control the traffic to the SGSN from BSC when the SGSN is in an overload situation.
The philosophy used at BSS side is:
– If T15 is not running and an OVERLOAD PDU including the Priority Class Indicator IE is received, then traffic for the indicated priority class should be reduced by one step. At the same time, timers T15 and T16 should be started.
– During T15, all received OVERLOAD PDU should be ignored.
– If T16 expires, the traffic should be increased by one step and T16 should be re-started unless full load has been resumed.
– The number of steps and the method of reducing/increasing the load are considered to be an implementation specific function.
8.6.2 Overload Operation
The SGSN could indicate to the BSS that it is in a congested state by sending an OVERLOAD PDU and request the BSS to reduce the traffic for the category of MSs indicated in the Priority Class Indicator IE.
The BSS receiving the OVERLOAD PDU shall assume the SGSN sending the PDU as being in an overloaded state and reduce the traffic to the SGSN using the algorithm described in sub-clause 8.6.1.
The amount of traffic could be reduced by using the Access Control Class in the system information message defined in 3GPP TS 44.018. However it is implemention specific regarding how the BSS reduces the traffic in response to receiving an OVERLOAD PDU.