6.5 BSSGP Layer
This section describes the BSSGP layer. It is responsible for the management of the BVC that corresponds to the virtual connection in which all the signaling and data addressed to a particular cell is sent through.
The first section explains the layers to which BSSGP provides services. In the following sections, the procedures that are used to provide services to these layers are detailed. The second section describes the procedures that are used on the interface for the transfer of user data in both uplink and downlink. The third section describes the procedures that are used for the transfer of GMM signaling. The fourth section handles the procedure used for the management of the BVCs. The last section deals with PFM procedures.
6.5.1 BSSGP Service Model
Figure 6.20 describes the BSSGP service model. It presents all the layers to which BSSGP provides services, together with their service access points (SAPs). It provides services to the following layers:
Figure 6.20: BSSGP service model.
6.5.2 User Procedures Between LLC and RELAY SAPs
Figure 6.21 describes the procedures used for the transfer of LLC PDUs between the SGSN and the BSS.
Figure 6.21: Data PDUs transfer.
18.104.22.168 Transfer of LLC PDUs in Downlink
The transfer of LLC PDUs in downlink is performed in unacknowledged mode. The LLC PDU is transported within the DL-UNITDATA message. This message is sent on the BVC of the cell in which is located the addressed mobile.
The SGSN provides the BSS with MS-specific information, enabling the RLC/MAC entity in the BSS to transmit the LLC PDU to the MS in a user-specific manner. The information given to the RLC/MAC entity include:
The DL-UNITDATA message contains the current TLLI identifying the MS, the IMSI, the QoS profile, the PDU lifetime, and optionally the PFI, the MS radio access capability, and the DRX parameters. If the SGSN has valid DRX parameters (see Chapter 3) for a TLLI, it includes them in the PDU.
Note that during GMM attach procedure, it may happen that the SGSN does not have a valid IMSI, in which case the DL-UNITDATA PDU is sent without the IMSI.
The TLLI allows the BSS to identify the DL transfer. It could happen that during an uplink transfer on the air interface, the BSS receives a downlink LLC PDU that is addressed to the mobile performing the uplink transfer. The TLLI is used by the BSS to correlate the uplink and downlink transfer so that it allocates downlink resources that when taken in combination with the allocated uplink resources remain within the multislot class constraint of the mobile.
Note that the NSEI and the BVCI are not contained in the DL-UNITDATA message. The NS layer provides them together with the DL-UNITDATA message when it is received.
22.214.171.124 Transfer of LLC PDUs in Uplink
The transfer of LLC PDUs in uplink is performed in unacknowledged mode. One LLC PDU is encapsulated in one UL-UNIDATA PDU. This PDU is sent on the BVC of the cell in which it has been received.
The UL-UNITDATA message contains:
Note that the NSEI and BVCI are not part of the UL-UNIDATA message. The NS layer provides them together with the DL-UNITDATA message when it is received.
6.5.3 Signaling Procedures Between GMM SAPs
Two kinds of paging procedures can be initiated by the SGSN:
These paging PDUs contain information that is necessary for the BSS to initiate the paging for an MS within a group of cells. The level of resolution of this group of cells can be:
When the mobile is in GMM READY state, the cell in which the mobile is located is provided in the paging message. The paging message is then sent on the BVC associated with the cell.
When the mobile is in GMM IDLE state, the paging message contains one of the following locations for the mobile: LA, RA, or BSS. If the LA, RA, or BSS in which the mobile is located is mapped on different NS entities within the SGSN, it must send one paging message to each NS entity having cells that belong to the LA, RA, or BSS. In this case, the paging message is sent on each signaling BVC of the NSEs.
Figure 6.22 describes a paging PS procedure. The PAGING-PS PDU contains the following parameters:
Figure 6.22: Paging PS procedure.
In the case of paging for non-GPRS services, the SGSN provides the IMSI of the mobile, its location, and the DRX parameters. The TLLI and TMSI can also be provided by the SGSN. In this case, one of the parameters is used to page the mobile on the radio interface. The IMSI and DRX parameters are used by the BSS to derive the PAGING GROUP.
A PAGING-PS or PAGING-CS PDU is relayed in the BSS by a PACKET PAGING REQUEST message when PCCCH is present in the cell; otherwise by a PAGING REQUEST message that is sent on the air interface.
126.96.36.199 Radio Access Capability Update
The BSS triggers the RA capability update procedure to request an MS's current RA capability, its IMSI, or both. This is requested by sending an RA-CAPABILITY-UPDATE PDU (see Figure 6.23). This message includes the TLLI of the MS. It is sent on the BVC associated with the cell where the mobile is located.
Figure 6.23: Radio access capability update procedure.
The SGSN responds by sending an RA-CAPABILITY-UPDATE-ACK including the TLLI, the IMSI, and the RA capability if available.
188.8.131.52 Radio Status
This procedure is triggered by the BSS when it has been requested to send downlink LLC PDUs and, because of exception conditions, the transfer through the air interface of LLC PDUs is no longer possible. Exception conditions are occurrences in which:
Conditions 1 and 2 indicate to the SGSN that it should stop sending LLC PDUs to the cell for the concerned MS. Condition 3 indicates to the SGSN that it should wait for a cell update before resuming the transmission of LLC PDUs.
As described in Figure 6.24, the BSS uses the RADIO-STATUS PDU to signal these exception conditions to the SGSN. The RADIO STATUS PDU includes the identification of the MS (either the TLLI, IMSI, or TMSI) and the cause of the failure. It is sent on the BVC associated with the cell where the mobile was located.
Figure 6.24: Radio STATUS procedure.
6.5.4 Signaling Procedures Between NM SAPs
The flush procedure is initiated by the SGSN. This procedure is triggered when the SGSN detects that a mobile has performed a cell reselection during a downlink packet transfer. The SGSN detects the cell reselection after a cell update or RA update procedure. The procedure can be initiated for two purposes:
The flush procedure is described in Figure 6.25. The SGSN initiates the flush procedure by sending a FLUSH-LL PDU to the BSS on the NSE signaling BVC. This message contains the flowing parameters:
Figure 6.25: Flush procedure.
This procedure is acknowledged by the FLUSH-LL-ACK message, which contains the following parameters:
184.108.40.206 LLC Discarded
The LLC discarded procedure is described in Figure 6.26. In the procedure, the BSS sends an LLC-DISCARDED PDU on the NSE signaling BVC in order to inform the SGSN that an LLC PDU has been deleted within the BSS for one BVCI. This may occur, for instance, at a PDU lifetime expiry or cell reselection. The LLC-DISCARDED PDU includes the following parameters:
Figure 6.26: LLC discarded procedure.
These two last parameters are used for setting the flow control algorithm that is used between the SGSN and the BSS. This mechanism is described in the next section.
220.127.116.11 Flow Control
A flow control procedure between the BSS and the SGSN is necessary in order to manage buffers within the BSS. In the BSS, there is at least one buffer for each BVC and possibly for each MS. In order to avoid DL LLC PDU loss because of buffer overflow, the BSS controls the transfer of BSSGP UNITDATA PDUs for an MS.
Only downlink BSSGP UNITDATA PDU transfer is managed via a flow control procedure. There is no uplink flow control. Buffers and link capacity must be dimensioned in order to avoid loss of uplink data.
The basic principle of BSSGP flow control is that the BSS sends to the SGSN flow control parameters that allow the SGSN to locally control its transmission in the BSS direction. The BSS controls the flow of BSSGP UNIDATA PDUs by indicating the maximum allowed throughput in total for each BVC and for each MS.
The SGSN passes LLC PDUs to the BSS as long as the allowed BSSGP throughput is not exceeded. The allowed BSSGP throughput is given per BVCI and for a single MS on that BVCI. The SGSN schedules the BSSGP downlink traffic of all MSs of a BVCI according to the maximum and guaranteed bit rate attributes and to the QoS profile related to each LLC PDU.
Flow Control Scenario
The SGSN performs flow control at two levels: BVC level and MS level. The flow control is performed on each DL LLC PDU first at MS flow control level then at BVC flow control level.
If a DL LLC PDU is allowed to pass by an individual MS flow control, the SGSN then applies the BVC flow control to the DL LLC PDU. If a DL LLC PDU is passed by both flow control mechanisms (MS level and BVC level), the DL LLC PDU is delivered to the NS layer for transmission to the BSS.
The BSS evaluates flow control parameters for each MS (respectively each BVC) and sends them to the SGSN in the FLOW-CONTROL-MS (respectively, FLOW-CONTROL-BVC) PDUs. They are sent on the BVC associated with the cell. These flow control parameters provided by the BSS are used by the SGSN to tune and update its flow control algorithm.
Figure 6.27 describes the overall process of flow control at BSSGP layer. At the SGSN side, there is a hierarchical flow control mechanism that is applied first at MS level and cell level (BVC). The MS flow control mechanism is controlled by the BSS by using the message FLOW-CONTROL-MS. The BVC flow control is managed by the BSS by sending FLOW-CONTROL-BVC messages. At BSS side, there is a BVC flow control context that contains all the flow control contexts of the MSs that are located in the cell corresponding to the BVC.
Figure 6.27: BSSGP flow control procedure.
Upon receipt of FLOW-CONTROL-MS (respectively, FLOW-CONTROL-BVC) PDU, the SGSN sends a FLOW-CONTROL-MS-ACK (respectively, FLOW-CONTROL-BVC-ACK). A timer whose value is common to the BSS and the SGSN limits the rate at which the BSS is allowed to send flow control messages.
LLC PDUs queued within the BSS that are not transferred across the radio interface because of the PDU lifetime expiration are deleted. The SGSN is notified by an LLC-DISCARDED PDU that allows the BVC and MS flow control context to be updated.
Flow Control Algorithm
The BSSGP flow control mechanism is based on a bucket algorithm that is described below.
In principle, the BSS indicates the amount of memory available for each flow context within the BSS (for each BVC and each mobile within this BVC). This amount of memory is given by the maximum bucket size parameter(Bmax).
Every time an LLC PDU must be sent in downlink toward the BSS, the flow control mechanism at SGSN side verifies that if this PDU is sent to the BSS the maximum bucket size for the mobile and BVC context will not be reached. If both maximum bucket sizes are not reached, the PDU is sent toward the BSS.
However, the bucket on the BSS side empties as LLC PDUs are sent on the radio interface. In order to be able to estimate the bucket size at any time, the SGSN needs some information about the bucket leak rate (R) at mobile and BVC levels.
The flow control parameters that are provided by the BSS within the flow control PDUs are
The two first parameters are used to tune the algorithm in the SGSN and the last one is used to realign the bucket counter. It gives the exact amount of available space within the bucket.
Note that the FLOW-CONTROL-MS message also contains the TLLI identifying the mobile context. The FLOW-CONTROL-BVC message contains the default MS bucket parameters that must be used by the SGSN before it receives the first FLOW-CONTROL-MS message for the mobile.
Every time a new LLC PDU arrives, the flow control algorithm estimates the new value of the bucket counter (B*) if the LLC is passed.
If the new value of the bucket counter (B*) is lower than Bmax, the LLC PDU is passed; otherwise, it is delayed.
The value of the bucket counter must be updated upon receipt of a FLUSH-LL-ACK PDU or LLC-DISCARDED PDU indicating that LLC PDUs have been deleted for one cell or have been transferred toward a new BVCI.
18.104.22.168 BVC Management
A BVC is a virtual connection that handles the traffic of one cell between the SGSN and the BSS. It could be in one of the following two states: BLOCKED state or UNBLOCKED state. When the BVC is BLOCKED, there is no activity in the cell.
The BSS is responsible for the management of the BVC state. This means that it always initiates blocking or unblocking procedures that bring about the change of state of the BVC. One BVC could be blocked because of O&M intervention in a cell or equipment failure at the BSS side.
Figure 6.28 shows the BVC state transition diagram in the BSS and the SGSN. At BSS side, the transition between the two states is always triggered by O&M intervention. Within the SGSN, the transition between the two states is triggered by the blocking/unblocking procedure, which is always triggered by the BSS or the reset procedure.
Figure 6.28: BVC state transition in the BSS and SGSN.
BVC Blocking and Unblocking Procedure
The blocking of a BVC is initiated by the BSS by sending a BVC-BLOCK PDU on the NSE signaling BVC. This message contains the BVCI identifying the BVC that must be blocked and the cause of the blocking. On receipt of the BVC-BLOCK PDU, the SGSN marks the indicated BVC as BLOCKED and stops transmitting traffic addressed to this BVC. It acknowledges the blocking by sending a BVC-BLOCK-ACK PDU that contains the BVCI of the BLOCKED BVC on the NSE signaling BVC.
The BSS initiates the unblocking of the BVC by sending a BVC-UNBLOCK PDU containing the BVCI that identifies the BVC to be UNBLOCKED and the cause of the BVC unblocking. This message is sent on the NSE signaling BVC. Upon receipt of this message, the SGSN marks the BVC as UNBLOCKED and sends a BVC-UNBLOCK-ACK message containing the BVCI of the UNBLOCKED BVC. These procedures are described in Figure 6.29.
Figure 6.29: BVC blocking/unblocking and reset procedures.
Note that the blocking/unblocking procedure is not applicable to the signaling BVC. It will never be in the BLOCKED state.
BVC Reset Procedure
The reset procedure can be initiated either by the SGSN or the BSS. It is used to synchronize the initialization of GPRS BVC-related contexts at the BSS or SGSN. It is used by the BSS to map one BVCI on one cell.
It could be performed because of recovery procedures related to a system failure in the SGSN or BSS, an underlying NS system failure, a change in mapping between BVCI and CI, and creation of a new BVC. After a BVC reset procedure, the affected BVC is assumed to be UNBLOCKED at the SGSN side.
When one side sends a BVC-RESET PDU it will stop sending PDU until it receives the acknowledgment. The other side initializes all BVCs belonging to the NSE and returns a BVC-RESET-ACK PDU on the NSE signaling BVC. The BVC-RESET PDU contains the BVCI identifying the BVC, the corresponding CI, and the cause of the reset procedure. The BVC-RESET-ACK message contains the BVCI identifying the reset BVC. The reset procedure is described in Figure 6.29.
6.5.5 Signaling Procedures Between PFM SAPs
PFM procedures are used to create, modify, or delete a packet flow context within the BSS. These procedures are triggered every time a PDP context procedure is invoked at SGSN side. The definition of the packet flow context is in Chapter 3.
A TFI identifies each packet flow context, and the validity of the BSS packet flow context is managed by a timer within the BSS (packet flow timer PFT).
The BSS packet flow context procedures are as follows:
22.214.171.124 BSS Packet Flow Context Creation
The BSS packet flow context creation procedure is used to create a BSS packet flow context within the BSS. It can be initiated either by the SGSN or by the BSS.
The SGSN may request the creation of a BSS packet flow context at the activation of a PDP context.
The BSS packet flow context is negotiated by the BSS with the SGSN at the transmission of an uplink or downlink LLC PDU associated with an unknown PFI.
The procedure is described in Figure 6.30. The DOWNLOAD-BSS-PFC is sent only when the procedure is initiated by the BSS.
Figure 6.30: BSS packet flow context creation.
Note that when the BSS is unable to create the PFC, it returns a CREATE-BSS-PFC-NACK PDU that contains the TLLI, the PFI, and the cause.
126.96.36.199 BSS Packet Flow Context Modification
This procedure can be initiated by the SGSN or the BSS. When initiated by the SGSN, the procedure is the same as for BSS packet flow context creation. It can be triggered due to an increase or decrease of resources at the BSS side. Figure 6.31 describes the procedure when initiated by the BSS.
Figure 6.31: BSS PFC modification and deletion procedures.
188.8.131.52 BSS Packet Flow Context Deletion
This procedure is initiated by the SGSN. It may happen that the BSS deletes a packet flow context (e.g., due to a memory problem). However, in this case no notification issent to the SGSN. The procedure is described in Figure 6.31.
6.5.6 Summary of BSSGP PDUs
Table 6.1 gives for each BSSGP PDU its usage, the BVC type on which it is sent, and the direction.