BSSGP Layer

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:

  • LLC. BSSGP provides functions that control the transfer of LLC frames passed between the SGSN and the MS across the Gb interface.

  • GMM. BSSGP provides functions associated with mobility management between an SGSN and a BSS.

  • NM. This concerns the functions associated with the management of the virtual connections between the SGSN and BSS and the control of the BSS or SGSN nodes such as flow control.

  • Relay (RL). This layer acts as relay between the Gb interface and the radio interface. It controls the transfer of LLC frames between the RLC/MAC and BSSGP layers.

  • PFM. This handles the management of BSS packet flow contexts between the SGSN and the BSS.


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.

6.5.2.1 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:

  • MS radio access capability. This defines the radio capability of the mobile ( multislot class, power capability, frequency band supported).

  • PFI. This parameter identifies the packet flow context (when existing), containing the QoS parameters for the transfer of the LLC PDU.

  • QoS profile. This defines the peak bit rate, the type of BSSGP SDU (signaling or data), the type of LLC frame, the precedence class, and the transmission mode (ACK NACK, see Chapter 5).

  • PDU lifetime. This defines the remaining time period that the PDU is considered as valid within the BSS. If the PDU is held for a period exceeding the PDU lifetime time period, the PDU is discarded by the BSS.

  • DRXparameters. These parameters are used by the BSS to determine when the mobile operates in DRX or non-DRX mode.

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.

6.5.2.2 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:

  • The TLLI identifying the mobile that has sent the LLC PDU;

  • The QoS profile that has been used for the transfer of the LLC PDU on the air interface;

  • The LLC PDU;

  • The PFI identifying the packet flow context associated with the transfer (optional).

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

6.5.3.1 Paging

Two kinds of paging procedures can be initiated by the SGSN:

  1. Paging procedure for GPRS services, in which case the SGSN can send one or more PAGING-PS PDU to the BSS;

  2. Paging procedure for non-GPRS services requested by the MSC/ VLR, in which case the SGSN can send one or more PAGING-CS PDUs to the BSS.

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:

  • All cells within the BSS;

  • All cells within one LA;

  • All cells within one RA;

  • One cell (one BVCI).

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:

  • The IMSI of the paged mobile. It is used by the BSS to derive the PAGING GROUP of the mobile.

  • The location of the mobile: either cell, RA, LA or BSS.

  • The QoS profile.

  • The DRX parameters when available at SGSN side. They inform the BSS of the non-DRX and DRX period of the mobile.

  • The PFI when available. It indicates the associated packet flow context.

  • The P-TMSI when available at the SGSN side. When it is present in the message, it is used to page the mobile on the radio interface. Otherwise , the IMSI is used.


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.

6.5.3.2 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.

6.5.3.3 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:

  1. The MS goes out of coverage and is lost;

  2. The link quality is too poor to continue the transfer through the air interface;

  3. The BSS has ordered the MS to perform a cell reselection .

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

6.5.4.1 Flush

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:

  1. The cell reselection occurs between two cells that are not in the same RA or in the same NS entity, in which case the flush procedure ensures that LLC PDUs that are stored in the BSS at cell level, for the concerned mobile, are deleted.

  2. The cell reselection occurs between two cells that are in the same RA and in the same NS entity, in which case the flush procedure indicates the new cell (BVCI) where the LLC PDUs are to be transferred. The interruption of traffic due to the cell reselection is then reduced.

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:

  • The TLLI identifying the transfer;

  • The BVCI (old) for which the LLC PDUs must be deleted;

  • The BVCI (new) in which the LLC PDUs must be transferred (the new BVCI is only indicated when the two BVCI belongs to the same RA and NSE).


Figure 6.25: Flush procedure.

This procedure is acknowledged by the FLUSH-LL-ACK message, which contains the following parameters:

  • The TLLI;

  • The flush action indicating whether the LLC PDUs have been deleted or transferred toward the new BVCI;

  • The new BVCI in case of transfer of the LLC PDUs;

  • The number of octets that have been deleted or transferred (this parameter is used to calibrate the flow control algorithm that will be described in Section 6.5.4.3).

6.5.4.2 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:

  • The TLLI identifying the mobile;

  • The BVCI that is affected;

  • The number of LLC frames that have been discarded;

  • The number of octets that have been deleted.


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.

6.5.4.3 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( B max ).

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 bucket size ( B max );

  • The bucket leak rate ( R );

  • The bucket leak ratio (this parameter has been introduced as an optional feature and will be supported by both sides of the Gb in order to be used.

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.

(6.1)  

where

  • B stands for the evaluated bucket size at the time the last LLC PDU was transferred (Tlast_llc_transferred).

  • Tarrival is the time of arrival of the LLC PDU for which the flow control is triggered.

  • R (Tarrival - Tlast_llc_transferred) represents the bucket leak amount between the reception of the new LLC PDU and the transmission of the last one.

If the new value of the bucket counter ( B *) is lower than B max , 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.

6.5.4.4 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 :

  • BSS packet flow context creation procedure;

  • BSS packet flow context modification procedure;

  • BSS packet flow context deletion procedure.

6.5.5.1 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.

6.5.5.2 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.

6.5.5.3 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.

Table 6.1: Summary of BSSGP PDUs

PDU Name

Usage

BVC Type

Direction [*]

DL-UNITDATA

LLC

Cell BVC

DL

UL-UNITDATA

LLC

Cell BVC

UL

PAGING-PS

GMM

Signaling BVC or Cell BVC

DL

PAGING-CS

GMM

Signaling BVC or Cell BVC

DL

RA-CAPABILITY-UPDATE

GMM

Cell BVC

UL

RA-CAPABILITY-UPDATE-ACK

GMM

Cell BVC

DL

RADIO-STATUS

GMM

Cell BVC

UL

FLUSH-LL

NM

Signaling BVC

DL

FLUSH-LL-ACK

NM

Signaling BVC

UL

LLC-DISCARDED

NM

Signaling BVC

UL

FLOW-CONTROL-MS

NM

Cell BVC

UL

FLOW-CONTROL-MS-ACK

NM

Cell BVC

DL

FLOW-CONTROL-BVC

NM

Cell BVC

UL

FLOW-CONTROL-BVC-ACK

NM

Cell BVC

DL

BVC-BLOCK

NM

Signaling BVC

UL

BVC-BLOCK-ACK

NM

Signaling BVC

DL

BVC-UNBLOCK

NM

Signaling BVC

UL

BVC-UNBLOCK-ACK

NM

Signaling BVC

DL

BVC-RESET

NM

Signaling BVC

UL or DL

BVC-RESET-ACK

NM

Signaling BVC

DL or UL

CREATE-BSS-PFC

PFM

Signaling BVC

DL

CREATE-BSS-PFC-ACK

PFM

Signaling BVC

UL

CREATE-BSS-PFC-NACK

PFM

Signaling BVC

UL

MODIFY-BSS-PFC

PFM

Signaling BVC

UL

MODIFY-BSS-PFC-ACK

PFM

Signaling BVC

DL

DELETE-BSS-PFC

PFM

Signaling BVC

DL

DELETE-BSS-PFC-ACK

PFM

Signaling BVC

UL

DOWNLOAD-BSS-PFC

PFM

Signaling BVC

UL

[*] DL refers to the direction from SGSN to BSS, UL refers to the reverse direction.

 


GPRS for Mobile Internet
GPRS for Mobile Internet
ISBN: 158053600X
EAN: 2147483647
Year: 2003
Pages: 92

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net