4 Network Service general description

08.163GPPBase Station System (BSS) - Serving GPRS Support Node (SGSN) interfaceGeneral Packet Radio Service (GPRS)Network serviceRelease 1999TS

4.1 Overview

The position of the Network Service within the protocol stack of the Gb interface is shown in Figure 1/3GPP TS 08.16.

NOTE: BSSGP, L1, LLC, MAC, RELAY, RLC are outside the scope of this Technical Specification, refer to TS 3GPP TS 03.60 [22] for further details.

Figure 1/3GPP TS 08.16: Position of the NS within the Gb interface protocol stack

The Network Service performs the transport of NS SDUs between the SGSN and BSS. The services provided to the NS user shall be:

– Network Service SDU transfer. The Network Service entity shall provide network service primitives allowing for transmission and reception of upper layer protocol data units between the BSS and SGSN. The NS SDUs are transferred in order by the Network Service, but under exceptional circumstances order may not be maintained.

– Network congestion indication. Congestion recovery control actions may be performed by the Sub-Network Service (e.g. Frame Relay). Congestion reporting mechanisms available in the Sub-Network Service implementation shall be used by the Network Service to report congestion.

– Status indication. Status indication shall be used to inform the NS user of the NS affecting events e.g. change in the available transmission capabilities.

The Network Service entity is composed of an entity dependent on the intermediate transmission network used on the Gb interface, the Sub-Network Service, and of a control entity independent from that network, the Network Service Control. There is a hierarchical relationship between both entities. This is reflected in Figure 1/3GPP TS 08.16. The detailed communication mechanisms between both entities is an internal matter for the Network Service and is not further standardized.

Figure 2/3GPP TS 08.16: Internal architecture of the Network Service

The Sub-Network Service entity provides a communication service to Network Service Control peer entities. The Network Service Control peer entities use the Sub-Network Service for communication with each other. The peer-to-peer communication accross the Gb interface between remote Network Service Control entities is performed over Network Service Virtual Connections (NS-VCs). An NS-VC is a virtual communication path between Network Service Control peer entities.

The Network Service entity provides a communication service to NS user peer entities: the peer-to-peer communication between remote NS user entities is performed over BSSGP Virtual Connections (BVCs). A BVC is a virtual communication path between Network Service user peer entities. A Network Service Entity communicates with only one peer Network Service Entity.

Addressing across the Gb interface is further detailed in the rest of this Technical Specification.

The Network Service Control entity is responsible for the following functions:

– NS SDU transmission: The NS SDUs shall be transmitted on the NS-VCs. The NS SDUs are encapsulated into Network Service Control PDUs which in turn are encapsulated into Sub-Network Service PDUs.

– Load sharing: The load sharing function distributes the NS SDU traffic amongst the available (i.e. unblocked) NS-VCs of a group.

– NS-VC management: A blocking procedure is used by an NS entity to inform an NS peer entity when an NS-VC becomes unavailable for NS user traffic. An unblocking procedure is used for the reverse operation. A reset procedure is used between peer NS entities in order to set an NS-VC to a determined state, after events resulting in possibly inconsistent states of the NS-VC at both sides of the Gb interface. A test procedure is used to check that an NS-VC is operating properly between peer NS entities.

4.2 Addressing

The purpose of this clause is to describe the addressing principles on the Gb interface in a generic way, i.e. irrespective of the exact configuration of the Gb interface and of the exact nature of the intermediate transmission network, when present. Therefore, this clause provides an abstract description of the addressing principles. These principles are then applied to real networks in clause "Sub-Network Service protocol".

In this clause, addressing is considered in the general case where an SGSN is connected to several BSSs via an intermediate transmission network. Point-to-point physical connections may also be used, addressing in this special case can be derived from the general case.

4.2.1 Network Service Virtual Link (NS-VL)

An SGSN and a BSS may use different physical links for connecting to each other (e.g. because of intermediate equipment or transmission network). Each physical link is locally (i.e. at each side of the Gb interface) identified by means of a physical link identifier. The exact structure of the physical link identifier is implementation dependent.

Each physical link supports one or more Network Service Virtual Links (NS-VLs). Each NS-VL is supported by one physical link. The exact nature of the NS-VL depends on the intermediate network used on the Gb interface. In the general case of an intermediate transmission network, the NS-VL is used to access the intermediate network. Communication means internal to the intermediate network are outside the scope of this Technical Specification. The NS-VLs may alternatively be used end-to-end between the BSS and SGSN, in case of a point-to-point configuration on the Gb interface.

Each NS-VL is identified by means of a Network Service Virtual Link Identifier (NS-VLI). The significance (i.e. local or end-to-end) and the exact structure of the NS-VLI depends on the configuration of the Gb interface and on the intermediate network used. For example, in the case of a Frame Relay network, the physical link is the FR bearer channel, the NS‑VL is the local link (at UNI) of the FR permanent virtual connection (PVC) and the NS-VLI is the association of the FR DLCI and bearer channel identifier.

4.2.2 Network Service Virtual Connection (NS-VC)

In order to provide end-to-end communication between the BSS and SGSN irrespective of the exact configuration of the Gb interface, the concept of Network Service Virtual Connection (NS-VC) is used.The NS-VCs are end-to-end virtual connections between the BSS and SGSN. At each side of the Gb interface there is a one-to-one correspondence between NS-VCs and NS-VLs.

For example, in the case of a Frame Relay network, the NS-VC is the FR permanent virtual connection (PVC).

Figure 2/GSM08 16 shows the relationship between NS-VCs and NS-VLs.

Figure 3/3GPP TS 08.16: Relationship between NS-VCs and NS-VLs

Each NS-VC is identified by means of a Network Service Virtual Connection Identifier (NS-VCI) having end-to-end significance across the Gb interface. An NS-VCI uniquely identifies an NS-VC within an SGSN.

The establishment of an NS-VC includes the establishment of physical links, see 3GPP TS 08.14 [23], and of NS-VLs.

NS-VCs and NS-VLs are permanently established by means of administrative procedures, NS-VCIs are allocated by administrative means as well. The mapping of NS-VCIs on NS-VLIs and on physical link identifiers is held in non-volatile memory.

4.2.3 Network Service Virtual Connection Group

The Network Service Virtual Connection Group groups together all NS-VCs providing communication between the same peer NS entities. One NS-VC group is configured between two peer NS entities. This grouping is performed by administrative means. At each side of the Gb interface, there is a one-to-one correspondence between a group of NS-VCs and an NSEI. The NSEI has an end-to-end significance across the Gb interface.

4.2.4 BSSGP Virtual Connection (BVC)

The Network Service provides communication paths between remote NS user entities. These communication paths are called BSSGP Virtual Connections (BVCs). Each BVC is used to transport NS SDUs between NS users.

A Network Service Entity provides one or more BVCs between peer NS user entities. Each BVC is supported by one group of NS-VCs. Each group of NS-VCs supports one or more BVCs. The NS entity maps between BVC and the related NS-VC group.

Each BVC is identified by means of a BSSGP Virtual Connection Identifier (BVCI) having an end-to-end significance across the Gb interface. The BVCI together with the NSEI uniquely identifies a BVC within an SGSN. The BVCI and NSEI are used on the Network Service-Service Access Point (NS-SAP) for layer-to-layer communication.

4.3 Sub-Network Service functions

The Sub-Network Service functions of the Network Service shall provide access to the intermediate network (or to the peer entity in case of direct point-to-point configuration) by means of NS-VLs and shall provide NS-VCs between NS peer entities.

On each NS-VC, data are transferred in order by the Sub-Network Service.

When the Sub-Network Service entity detects that an NS-VC becomes unavailable (e.g. upon failure detection), or when the NS-VC becomes available again (e.g. after failure recovery), the Network Service Control entity shall be informed. Failures may occur due to protocol errors, intermediate transmission network failure, equipment or link failure or other reasons.

4.4 Load sharing function

The load sharing function distributes the NS SDU traffic among the unblocked NS-VCs of the same group on the Gb interface. The use of load sharing also provides to the upper layer seamless service upon failure by re-organizing the NS SDU traffic between the unblocked NS-VCs of the same group. The re-organization may disturb the order of transferred NS SDUs. The load sharing function should be implemented in both the BSS and the SGSN.

Load sharing applies only to NS SDUs, not to NS signalling such as NS-VC management PDUs.

4.4.1 Requirements on load sharing function

All NS SDUs to be transmitted over the Gb interface are passed to the load sharing function along with the Link Selector Parameter (LSP) , the BVCI and the NSEI. LSP and BVCI are used by the NS entity to select amongst the unblocked NS-VCs within the group, addressed by means of the NSEI, where to send the NS SDU. The mapping between LSP and NS-VC is based on an implementation dependent function that meets the following requirements:

– For each BVC and NSEI, the NS entity selects the NS-VC out of the group based on the LSP. This is an internal matter for the NS entity and it is not subject to further standardization.

– For each BVC and NSEI, NS SDUs with the same Link Selector Parameter shall be sent on the same NS-VC. Thus, the load sharing function guarantees that, for each BVC, the order of all NS SDUs marked with the same LSP value is preserved. In the event of a link failure and subsequent re-organization of the NS SDU traffic between the unblocked NS-VCs, the receiver may get out of order NS SDUs. Further actions implemented to prevent this error are outside the scope of this Technical Specification.

– Load sharing functions at the BSS and the SGSN are independent. Therefore, uplink and downlink NS SDUs for a subscriber may be transferred over different NS-VCs.

– A change in NS-VCs available for NS user traffic (i.e. one or more NS-VCs become blocked or unblocked) shall result in a re-organization of the NS SDU traffic amongst the unblocked NS-VCs of the same group.

– For a BVC, when there is no unblocked NS-VC of the group left between a BSS and a SGSN, the corresponding traffic is discarded by the NS at the sending side.

The Link Selector Parameter is locally used at the BSS and at the SGSN and shall not be transmitted across the Gb interface.

4.5 NS-VC management function

The NS-VC management function is responsible for the blocking / unblocking, reset and test of NS-VCs.

4.5.1 Blocking / unblocking of an NS-VC

When a condition making an NS-VC unavailable for NS user traffic is locally detected at the BSS or at the SGSN, the NS-VC shall be marked as blocked by the local NS entity and the remote NS peer entity shall be informed by means of a blocking procedure. The remote NS entity shall then mark the NS-VC as blocked and shall consider it as unavailable for NS user traffic.

A BSS or SGSN may block an NS-VC because of:

– Operation and Maintenance intervention at the Gb interface making the NS-VC unavailable for NS user traffic;

– equipment failure at a BSS or an SGSN entity;

– equipment or link failure on a BSS or an SGSN site;

– failure in the transit network; or

– other causes.

When the NS-VC becomes available again for NS user traffic, the NS entity which initiated the blocking procedure may inform the remote NS peer entity by means of an unblocking procedure. The remote NS entity shall then mark the NS-VC as unblocked and shall consider it as available for NS user traffic.

The blocking / unblocking procedures are further detailed in the rest of this Technical Specification.

4.5.2 Reset of an NS-VC

This procedure is used to reset one NS-VC to a determined state between remote entities. This procedure is performed:

– when a new NS-VC is set-up;

– after a processor re-start;

– after a failure recovery when the state of an NS-VC must be set to blocked and alive; or

– at any local event restoring an existing NS-VC in the dead state or in an undetermined state.

When a reset procedure is initiated, data in transfer may be lost.

4.5.3 Test of an NS-VC

The test procedure is used to check that end-to-end communication exists between peer NS entities on a given NS-VC. When end-to-end communication exists, the NS-VC is in the "alive" state, otherwise it is in the "dead" state. A dead NS-VC can not be in the "unblocked" state.