SMG Meeting #26, Tdoc SMG 310/98 Helsinki, Finland June, CRs to and 08.18, agreed by SMG2. GPRS, Strategic

Transcription

1 SMG Meeting #26, Tdoc SMG 310/98 Helsinki, Finland June, 1998 Source : SMG 2 Title : CRs to and 08.18, agreed by SMG2. GPRS, Strategic Proposed Agenda Item : 6.2 Presented for : Approval Introduction : SPEC CR REV PHAS VERS SUBJECT CAT A007 3 R Independent configuration of NS-VCs and BVCIs. B A007 5 R Flush Procedure B A001 3 R Independent configuration of NS VCs and BVCIs B A012 2 R BSSGP Flow Control on the Gb Interface F A011 2 R Alignment w/ GSM (CR A051r3) on the Suspend/Resume F A011 R Detection of an incorrect configuration of NS-VCIs on NSEIs F A012 R Suppression of a not used cause F A018 R Suppression of not used cause F A019 R RAC is added to Cell Identity IE F A009 2 R General clean-up of GSM F A012 3 R BSSGP Flow Control on the Gb Interface F A010 R Modification of PAGING PS and PAGING CS messages F

2 ETSI STC SMG2 WPA Bad Aibling, Germany April 1998 CHANGE REQUEST No. A007r3 Technical Specification version Submitted to SMG for approval without presentation ("non-strategic") [ ] with presentation ("strategic") [ ] Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Tdoc SMG2 298A204 Revision of 298A188 Phase 1: [ ] Phase 2: [ ] Phase 2+: [Release 97] Work item: GPRS Other phase(s) affected: [ ] If yes, linked CR(s): Proposed change effects: SIM [ ] ME [ ] Network [X] Source: SMG2 Date: April 1998 Subject: Independent configuration of NS-VCs and BVCIs. Category: F - Correction [ ] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [X] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: The specification of the Gb interface specifies the need for a mapping between a BVCI and the group of NS-VCs that can carry the data stream associated to that BVC. This mapping is used by the load sharing entity at the SGSN (for downlink traffic). All the NS-VCs serving the same BVC have to end in the same BSS. This configuration has two main drawbacks: - A BVCI has to be unique within an SGSN, instead of only within a Gb interface (SGSN-BSS pair). - Implementations strictly following the standard will require updates to the SGSN s configuration data whenever a cell is added to a BSS or moved between BSSs. A sensible implementation at the SGSN will load share traffic to a BSS between all the NS-VCs that connect the BSS to the SGSN. In this case the pre-configuration of a cell in the SGSN and the constraint in the number of BVCs in an SGSN is not needed: - The SGSN keeps detailed MM information about an MS while the MS is in the READY state, i.e. the SGSN knows the BVCI which can be used to contact the mobile for downlink transmission. The BVCI is passed from BSSGP to the upper layers as a primitive parameter in every uplink packet received by the SGSN. - An SGSN in Standby state will page an MS before sending downlink traffic. The MS will respond with an LLC packet that will put the MM context in READY state and will deliver the BVCI to the user of BSSGP. It is proposed to define an SGSN internal identifier for the BSS. This identifier (called Network Service Entity Identifier, NSEI) is passed with the BVCI in every uplink packet to the upper layers of BSSGP. The NSEI is used by the load sharing entity to determine the NS-VCs that serve that BVCI (i.e. all the NS-VCs that connect the SGSN to the NSEI). With this internal identifier, the SGSN will not need to be updated when a new cell (BVCI) is added to a BSS (NSEI). A BVCI will only need to be unique within a Gb interface (the global identifier within an SGSN will be BVCI+NSEI). The initial version of this CR was presented at SMG2 WPA, Sophia Antipolis, Februray '98, and the principles were agreed. Sections affected, and additional explanations of details of change (if needed): 3.1: Definition of NSEI added. Editorial correction on NS-VCI definition. Clarification on NS-VC group. 3.3: NSEI introduced. 4.1: Definition of the Network Service Entity clarified, and NSEI introduced : Definition of the group of NS-VCs improved, and relationship with NSEI introduced (was 4.2.3): Definition of BVC and BVCI improved and aligned with the introduction of NSEI. 4.4 & 4.4.1: Load sharing aligned with the introduction of NSEI. 5 and included sub-clauses: Introduction of NSEI in the service primitives. Annex A: Aligned with the introduction of the NS-VC groups and NSEI. Annex C: New informative annex created in order to explain how to apply the normative part of and Attached revised pages: 10 to 18 (, 47 to 44, plus one new page for annex C. If other core Specifications are affected, necessary (and attached) Joint CRs: CR A001r3 Affects (possibly): MS Test Specifications[ ] BSS Test Specifications[ ] O&M Specifications[ ] Attached CRs?

3 ETSI STC SMG2 WPA Bad Aibling, Germany April 1998 Tdoc SMG2 298A204 Revision of 298A188 Cross Phase Compatibility: Change affects operation of: Other comments:

4 10 GSM V6.0.0 ( ) [10] ITU-T Q.931 (10/95): " ISDN user-network interface layer 3 specification for Basic Call Control". [11] ITU-T revised Q.933 (10/95): "Digital Subscriber Signalling System No. 1 (DSS 1) - Signalling specification for frame mode basic call control". [12] ITU-T I.370 (10/95): "Congestion management for the ISDN Frame Relaying Bearer Service". [13] CCITT X.200 (White Book): "Reference model of open systems interconnection for CCITT applications". 3 Definitions, symbols and abbreviations 3.1 Definitions For the purposes of this Technical Specification the following definitions apply. For additional applicable definitions refer to GSM [2]. BSSGP Virtual Connection (BVC): An end-to-end virtual communication path between remote Network Service user entities. BSSGP Virtual Connection Identifier (BVCI): The identifier of a BVC, having end-to-end significance across the Gb interface. Network Service Entity Identifier (NSEI): The identifier of an NS Entity. This identifier has only local significance at the BSS or SGSN. Network Service Virtual Connection (NS-VC): An end-to-end virtual communication path between Network Service peer entities. Network Service Virtual Connection Identifier (NS-VCI) Identifier: The identifier of an NS-VC having end-to-end significance across the Gb interface. Network Service Virtual Link (NS-VL): A virtual communication path between the BSS or the SGSN and the intermediate network, or between the BSS and the SGSN in case of direct point-to-point configuration. Network Service Virtual Link Identifier (NS-VLI): The identifier of an NS-VL, having local significance at the BSS or SGSN. Network Service Virtual Connection Group: Groups all NS-VCs together which provide communication between the same peer NS entities. This grouping has local significance at the BSS or SGSN. Blocked / unblocked: When an NS-VC can not be used for NS user traffic, it is blocked. When an NS-VC can be used for NS user traffic, it is unblocked. Dead / alive: When an NS-VC is able to provide communication between remote NS entities, it is alive. When it is not able, it is dead. These states are supervised by means of a test procedure, as further described in this Technical Specification. 3.2 Symbols Refer to GSM [3]. 3.3 Abbreviations For the purposes of this Technical Specification the following abbreviations apply. Additional applicable abbreviations can be found in GSM [1]. When there is conflict between this Technical Specification and GSM [1], the following list takes precedence. BECN Backward Explicit Congestion Notification BSSGP Base Station System GPRS Protocol BVC BSSGP Virtual Connection BVCI BSSGP Virtual Connection Identifier CLLM Consolidated Link Layer Management DE Discard Eligibility FECN Forward Explicit Congestion Notification FR Frame Relay FRF Frame Relay Forum LLC Logical Link Control LSP Link Selector Parameter MAC Medium Access Control

5 11 GSM V6.0.0 ( ) NS NSEI NS-SAP NS-VC NS-VCI NS-VL NS-VLI PDU PTP PTM PVC RLC SGSN UNI Network Service Network Service Entity Identifier Network Service Service Access Point Network Service Virtual Connection Network Service Virtual Connection Identifier Network Service Virtual Link Network Service Virtual Link Identifier Protocol Data Unit Point-To-Point Point-To-Multipoint Permanent Virtual Connection Radio Link Control Serving GPRS Support Node User-to-Network Interface 4 Network Service general description 4.1 Overview The position of the Network Service within the protocol stack of the Gb interface is shown in Figure 1/GSM LLC RLC MAC RELAY BSSGP NS L1 BSSGP NS L1 BSS Gb SGSN NOTE: BSSGP, L1, LLC, MAC, RELAY, RLC are outside the scope of this Technical Specification, refer to TS GSM [3] for further details. Figure 1/GSM 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 2/GSM The detailed communication mechanisms between both entities is an internal matter for the Network Service and is not further standardized.

6 12 GSM V6.0.0 ( ) Network Service Network Service Control / Network Service Control protocol Sub-Network Service / Sub-Network Service protocol Figure 2/GSM 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-topeer 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. A Network Service Entity is locally (at one side of the Gb interface) identified by a Network Service Entity Identifier (NSEI). 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. Annex A provides an informative illustration of the addressing concepts when applied to the case of a Frame Relay 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

7 13 GSM V6.0.0 ( ) 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 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 3/GSM08 16 shows the relationship between NS-VCs and NS-VLs. end-to-end NS-VC BSS intermediate transmission network SGSN NS-VL at the BSS side NS-VL at the SGSN side Figure 3/GSM 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 GSM [4], 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 nonvolatile memory Network Service Virtual Connection Group The Network Service Virtual Connection Group groups together all NS-VCs together which providinge communication between the same peer NS entities. One or more NS-VC groups isare configured between twothe same peer NS entities. This grouping is performed by administrative means. At each side of the Gb interface, there is a oneto-one correspondence between a group of NS-VCs and an NSEI. The significance of the grouping is locally at BSS and SGSN 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 areis used on the Network Service-Service Access Point (NS-SAP) for layer-to-layer communication.

8 14 GSM V6.0.0 ( ) 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 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 areis used by the NS entity to select amongst the unblocked NS-VCs within theof a group, addressed by means of the NSEIBVCI, 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 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.

9 15 GSM V6.0.0 ( ) 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 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 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. 5 Elements for layer-to-layer communication This chapter presents the Network Service in a generic way, no assumptions are made regarding the real protocols providing the network services. 5.1 Service primitive model The service primitive model shown in Figure 4/GSM is applicable to both BSS and SGSN. Network Service user GSM NS-SAP Network Service GSM Figure 4/GSM 08.16: Network Service primitive model The network services are provided at the Network Service-Service Access Point (NS-SAP). 5.2 Service primitives and parameters The Network Service primitives are summarized in table 1/GSM The general syntax of the Network Service primitives is: NS - Generic name - Type (Parameters)

10 16 GSM V6.0.0 ( ) Table 1/GSM Network Service primitives Generic name Type Parameters Request Indication Response Confirm UNITDATA X X - BVCI and NSEI - NS SDU - Link Selector Parameter (in Request only) CONGESTION X - BVCI and NSEI - congestion cause STATUS X - BVCI and NSEI - NS affecting cause - transfer capability Primitives NS-UNITDATA-Request This primitive is used by the NS user entity to send a NS SDU to its peer entity via a BVC. The NS entity sends the NS SDU in unacknowledged mode. The Link Selector Parameter is used to identify the NS SDUs which must be sent in order relatively to each other. The NSEIBVCI is used by the NS entity to select the group of NS-VCs corresponding to the addressed remote entity NS-UNITDATA-Indication This primitive is used by the NS entity to provide the NS user entity with a NS SDU received on a virtual connection. The NS SDU are received in unacknowledged mode. BVCI together with NSEI indicates which BVC the NS SDU was received on NS-CONGESTION-Indication The NS entity shall be able to detect when a congestion situation starts and ends on an NS-VC. This primitive is used by the NS entity to report to the NS user entity that congestion is detected or that the congestion situation has disappeared. The BVCI and NSEI of the affected BVC and the congestion cause are reported to the NS user entity. Typically, the cause indicates the direction of transmission affected by the congestion NS-STATUS-Indication There may be situations where an NS-VC becomes unavailable for NS user traffic. When this occurs, the NS user is informed of the degradation of the transfer capacity by means of this primitive including the "transfer capability" parameter. When an NS-VC previously unavailable for NS user traffic becomes available again, the NS user entity is also informed by means of this service primitive, indicating the current transfer capability. This primitive may be used in response to an NS-UNITDATA-Request primitive which the NS is unable to serve because of e.g. NS-VC failure. This primitive may also be used upon recovery after a failure affecting the NS Parameters NS SDU The NS SDUs are specified in GSM [5]. They shall never be inspected by the Network Service entity Link Selector Parameter The Link Selector Parameter is included in the NS-UNITDATA-Request primitive for load sharing purposes as described in clause "Requirements on load sharing function".

11 17 GSM V6.0.0 ( ) BVCI and NSEI ThisBVCI and NSEI parameters areis included in the servicens-unitdata-request/indication primitives to identify the BVC for which the service is provided. Theseis parameters areis used by the NS entity to multiplex the NS SDUs over the NS-VCsin order to direct the NS user traffic towards the proper NS-VCs corresponding to the indicated BVC Congestion cause The congestion cause shall indicate the affected direction of transmission and may be set to the following values: a) congestion detected, backward b) end of congestion, backward c) congestion detected, forward d) end of congestion, forward Transfer capability This parameter is used to report to the NS user entity the current transfer capacity available for a BVC, in terms of bandwidth. This parameter may be set to any value from "0" (zero) to the maximum bandwidth provided by the complete set of NS-VCs associated to the BVC NS affecting cause This parameter is used to indicate to the NS user entity the reason which caused the NS-STATUS-Indication primitive to be used. The cause values are: a) NS-VC failure: a failure is affecting one or more NS-VCs, the NS is still available. b) NS-VC recovery: one or more NS-VCs which were in failure are available again. c) NS failure: the NS can not provide data transfer services to the NS user. d) NS recovery: the NS can provide data transfer services again.

12 37 GSM V6.0.0 ( ) Annex A (informative): Illustration of the addressing scheme on the Gb interface This annex provides illustrative examples of the addressing scheme on the Gb interface. Refer to GSM [5] for the definition of PTP functional entities, PTM functional entities and signalling entities. Figure A.1/GSM shows an example of the addressing scheme when an intermediate Frame Relay network is used on the Gb interface. PTP, cell 1 BSS#1 BVCI=I NS-VCI=a NS-VCI=b DLCI=16 bearer chan. = 1 bearer chan. = 5 NS-VCI=a DLCI=98 NS-VCI=b DLCI=17 SGSN BVCI=I PTP, cell 2 PTM signalling BVCI=II BVCI=III BVCI=IV NS-VCI=c DLCI=51 DLCI=43 NS-VCI=d DLCI=137 bearer chan. = 2 Frame Relay network NS-VCI=e DLCI=16 BVCI=II BVCI=III BVCI=IV NS-VCI=c PTP, cell 3 PTM BSS#2 BVCI=V BVCI=VI NS-VCI=e DLCI=16 NS-VCI=f DLCI=259 bearer chan. = 3 bearer chan. = 4 bearer chan. = 6 DLCI=21 NS-VCI=d DLCI=302 NS-VCI=f DLCI=511 BVCI=V BVCI=VI BVCI=VII signalling BVCI=VII

13 38 GSM V6.0.0 ( ) PTP, cell 1 BSS#1 BVCI=I NS-VCI=a DLCI=16 NS-VCI=b bearer chan. = 1 bearer chan. = 5 NS-VCI=a DLCI=98 NS-VCI=b DLCI=17 SGSN BVCI=I PTP, cell 2 PTM signalling BVCI=II BVCI=III BVCI=IV 1 NS-VCI=c DLCI=51 DLCI=43 NS-VCI=d DLCI=137 bearer chan. = 2 Frame Relay network NS-VCI=e DLCI=16 3 BVCI=II BVCI=III BVCI=IV NS-VCI=c PTP, cell 3 PTM BSS#2 BVCI=V BVCI=VI 2 NS-VCI=e DLCI=16 NS-VCI=f DLCI=259 bearer chan. = 3 bearer chan. = 4 bearer chan. = 6 DLCI=21 NS-VCI=d DLCI=302 NS-VCI=f DLCI=511 4 BVCI=V BVCI=VI BVCI=VII signalling BVCI=VII Legend : 1 : NSEI=γ 2 : NSEI=δ 3 : NSEI=α 4 : NSEI=β Load sharing of BVC on NS-VCs group addressed by NSEI Figure A.1/GSM 08.16: Example of the Gb interface with an intermediate Frame Relay network

14 39 GSM V6.0.0 ( ) In this example, it is assumed that each BVC is supported by two NS-VCs. The two sides of the Gb interface use different physical links. BVCI=I, II and V are used to address the PTP functional entities responsible for cells 1, 2 and 3 respectively. BVCI=III and VI are used to address PTM functional entities in BSS#1 and #2 respectively (in this example, it is assumed there is one PTM functional entity per BSS). BVCI=IV and VII are used to address signalling entities in BSS#1 and #2 respectively (in this example, it is assumed there is one signalling entity per BSS). The following mapping tables correspond to the above example: Table A.1/GSM 08.16: Mapping table of the NS entity, SGSN side BVCI NS-VCI DLCI bearer channel Comments I a 98 5 load sharing between both NS-VCs c 21 6 II a 98 5 load sharing between both NS-VCs c 21 6 III b 17 5 load sharing between both NS-VCs c 21 6 IV b 17 5 load sharing between both NS-VCs d V e 16 5 load sharing between both NS-VCs f VI e 16 5 load sharing between both NS-VCs f VII e 16 5 load sharing between both NS-VCs f NSEI NS-VCI DLCI bearer channel Comments α a 98 5 Load sharing of BVCIs I, II, II and IV b 17 5 between NS-VCs a, b, c and d. c 21 6 d β e 16 5 Load sharing of BVCIs V, VI and VII f between NS-VCs e and f. Table A.2/GSM 08.16: Mapping table of the NS entity, BSS#1 side BVCI NS-VCI DLCI bearer channel Comments I a 16 1 load sharing between both NS-VCs c 51 2 II a 16 1 load sharing between both NS-VCs c 51 2 III b load sharing between both NS-VCs c 51 2 IV b load sharing between both NS-VCs d 43 2 NSEI BVCI NS-VCI DLCI bearer channel Comments γ all a 16 1 Load sharing (I, II, III and IV) b between all NS-VCs. c 51 2 d 43 2 Table A.3/GSM 08.16: Mapping table of the NS entity, BSS#2 side BVCI NS-VCI DLCI bearer channel Comments V e 16 3 load sharing between both NS-VCs f VI e 16 3 load sharing between both NS-VCs f VII e 16 3 load sharing between both NS-VCs f 259 4

15 40 GSM V6.0.0 ( ) NSEI BVCI NS-VCI DLCI bearer channel Comments δ all e 16 3 Load sharing (V, VI and VII) f between all NS-VCs. Table A.4/GSM 08.16: Mapping table of the NS user entity, SGSN side Cell / BSC BVCI NSEI PTP, cell 1 I α PTP, cell 2 II α PTP, cell 3 V β PTM, BSS#1 III α PTM, BSS#2 VI β signalling, BSS#1 IV α signalling, BSS#2 VII β Table A.5/GSM 08.16: Mapping table of the NS user entity, BSS#1 side Cell / BSC BVCI NSEI PTP, cell 1 I γ PTP, cell 2 II γ PTM III γ signalling IV γ Table A.6/GSM 08.16: Mapping table of the NS user entity, BSS#2 side Cell / BSC BVCI NSEI PTP, cell 3 V δ PTM VI δ signalling VII δ

16 41 GSM V6.0.0 ( ) Figure A.2 /GSM shows an example of the addressing scheme when point-to-point Frame Relay connections are used on the Gb interface. The BSS configuration is the same as in figure A.1/GSM BSS#1 NS-VCI=a NS-VCI=a SGSN PTP, cell 1 BVCI=I NS-VCI=b DLCI=98 bearer chan. = 1 NS-VCI=b BVCI=I PTP, cell 2 PTM BVCI=II BVCI=III NS-VCI=c NS-VCI=d DLCI=17 DLCI=21 bearer chan. = 2 NS-VCI=c NS-VCI=d BVCI=II BVCI=III BVCI=IV DLCI=302 BVCI=IV signalling BSS#2 NS-VCI=e DLCI=16 NS-VCI=e BVCI=V bearer chan. = 3 PTP, cell 3 BVCI=V NS-VCI=f NS-VCI=f BVCI=VI PTM BVCI=VI DLCI=511 bearer chan. = 4 BVCI=VII signalling BVCI=VII

17 42 GSM V6.0.0 ( ) BSS#1 NS-VCI=a NS-VCI=a SGSN PTP, cell 1 BVCI=I NS-VCI=b DLCI=98 bearer chan. = 1 NS-VCI=b BVCI=I PTP, cell 2 PTM BVCI=II BVCI=III 1 NS-VCI=c NS-VCI=d DLCI=17 DLCI=21 bearer chan. = 2 NS-VCI=c NS-VCI=d 3 BVCI=II BVCI=III BVCI=IV DLCI=302 BVCI=IV signalling BSS#2 NS-VCI=e DLCI=16 NS-VCI=e BVCI=V PTP, cell 3 BVCI=V 2 NS-VCI=f bearer chan. = 3 NS-VCI=f 4 BVCI=VI PTM BVCI=VI DLCI=511 bearer chan. = 4 BVCI=VII signalling BVCI=VII Legend : 1 : NSEI=γ 2 : NSEI=δ 3 : NSEI=α 4 : NSEI=β Load sharing of BVC on NS-VCs group addressed by NSEI Figure A.2 /GSM 08.16: Example of the the Gb interface, with point-to-point Frame Relay connections The two sides of the Gb interface use the same physical links. In figure A.2/GSM 08.16, it is assumed that, for each bearer channel, the bearer channel identifiers are set to the same value at both sides of the Gb interface. Alternatively, they could also have different values. The corresponding mapping tables are:

18 43 GSM V6.0.0 ( ) Table A.7/GSM 08.16: Mapping table of the NS entity, SGSN side BVCI NS-VCI DLCI bearer channel Comments I a 98 1 load sharing between both NS-VCs c 21 2 II a 98 1 load sharing between both NS-VCs c 21 2 III b 17 1 load sharing between both NS-VCs c 21 2 IV b 17 1 load sharing between both NS-VCs d V e 16 3 load sharing between both NS-VCs f VI e 16 3 load sharing between both NS-VCs f VII e 16 3 load sharing between both NS-VCs f NSEI NS-VCI DLCI bearer channel Comments α a 98 1 Load sharing of BVCIs I, II, II and IV b 17 1 between NS-VCs a, b, c and d. c 21 2 d β e 16 3 Load sharing of BVCIs V, VI and VII f between NS-VCs e and f. Table A.8/GSM 08.16: Mapping table of the NS entity, BSS#1 side BVCI NS-VCI DLCI bearer channel Comments I a 98 1 load sharing between both NS-VCs c 21 2 II ab 98 1 load sharing between both NS-VCs c 21 2 III b 17 1 load sharing between both NS-VCs c 21 2 IV b 17 1 load sharing between both NS-VCs d NSEI BVCI NS-VCI DLCI bearer channel Comments γ all a 98 1 Load sharing (I, II, III and IV) b 17 1 between all NS-VCs. c 21 2 d Table A.9/GSM 08.16: Mapping table of the NS entity, BSS#2 side BVCI NS-VCI DLCI bearer channel Comments V e 16 3 load sharing between both NS-VCs f VI e 16 3 load sharing between both NS-VCs f VII e 16 3 load sharing between both NS-VCs f NSEI BVCI NS-VCI DLCI bearer channel Comments δ all e 16 3 Load sharing (V, VI and VII) f between all NS-VCs.

19 44 GSM V6.0.0 ( ) Table A.10/GSM 08.16: Mapping table of the NS user entity, SGSN side Cell / BSC BVCI NSEI PTP, cell 1 I α PTP, cell 2 II α PTP, cell 3 V β PTM, BSS#1 III α PTM, BSS#2 VI β signalling, BSS#1 IV α signalling, BSS#2 VII β Table A.11/GSM 08.16: Mapping table of the NS user entity, BSS#1 side Cell / BSC BVCI NSEI PTP, cell 1 I γ PTP, cell 2 II γ PTM III γ signalling IV γ Table A.12/GSM 08.16: Mapping table of the NS user entity, BSS#2 side Cell / BSC BVCI NSEI PTP, cell 3 V δ PTM VI δ signalling VII δ

20 Annex C (informative): Recommended usage of BVCI and NSEI This annex recommends a way to use BVCIs and NSEIs, avoiding huge and unflexible configuration data at the SGSN. This annex uses concepts defined in GSM [5]. The key points are: - A BVCI needs not to be unique within an SGSN, a BVCI is unique within an NS Entity. BVCI together with NSEI uniquely identify a BVC within an SGSN (the global identifier within an SGSN is BVCI+NSEI). - BVCIs corresponding to PTP functional entities need not to be statically configured at the SGSN side: no fixed, permanent relationship is required in the SGSN between PTP BVCIs and NS-VCs. With the NSEI, the SGSN needs not to be updated when a new cell (BVCI) is added to a BSS (NSEI). The preconfiguration of a cell in the SGSN and the constraint in the number of BVCs in an SGSN are not needed: - The SGSN keeps detailed MM information about an MS while the MS is in the READY state, i.e. the SGSN knows the BVCI and NSEI which can be used to contact the MS for downlink transmission. The BVCI and NSEI are passed from NS to BSSGP and from BSSGP to the upper layers as a primitive parameter in every uplink packet received by the SGSN. Subsequent downlink LLC frames to this MS shall be transmitted by the SGSN over the BVC identified by this BVCI+NSEI. - An SGSN in STANDBY state will page an MS before sending downlink traffic. The MS will respond with an LLC packet that will put the MM context in READY state and will deliver the BVCI and NSEI to the user of BSSGP. For paging purposes, the SGSN only needs to know the correspondence between each Routeing Area and one or more NSEI(s) where to send the corresponding paging messages. Paging messages shall always be sent over BVCI=0. There may be NSEI(s) where BVCI=0 is not used.

21 ETSI STC SMG2/WPA TDoc SMG2 298A208 Bad Aibling Revision of TDoc SMG2 298A168 Germany April, 1998 CHANGE REQUEST No.A007 rev.5 Technical Specification GSM version Submitted to SMG for approval without presentation ("non-strategic") [ ] with presentation ("strategic") [ ] Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [ ] Phase 2+: [Release 97] Work item: GPRS Other phase(s) affected: [ ] If yes, linked CR(s): Proposed change affects: SIM [ ] ME [ ] Network [ ] Source: SMG2 Date: 2-6 February 1998 Subject: Flush Procedure Category: F - Correction [ ] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [x] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: To clarify that a FLUSH refers to an MS (TLLI) and not (as currently stated) to a logical link. According to TS 04.64, a logical link (connection) is identified by a DLCI, consisting of a TLLI and a SAPI. To simplify implementation of transfer of queued LLC-PDU(s) between cells within a BSS when an MS moves from one cell to another. Such a function of transferring queued LLC-PDU(s) for an MS from the old to the new cell within a BSS seems important as it may significantly improve LLC performance in a mobile environment with frequent cell changes. To perform this function with the current version of the specification, the BSS needs to analyse each uplink LLC-PDU transfer and determine if it should be used to initiate a transfer of queued LLC- PDU(s) within the BSS. What is proposed in this CR, is to add the BVCI of the new cell as a new information element in the FLUSH-LL PDU. The FLUSH-LL PDU can then be used to inform the BSS that an MS (TLLI) has moved from one cell (old BVCI) to another (new BVCI). Depending on implementation and whether the old and new BVCI belong to the same or different BSS, the BSS may use the information e.g. to initiate transfer of queued LLC-PDU(s) corresponding to the MS from the old to the new cell, or to delete the queued LLC-PDU(s). Initiation of transfer of queued LLC-PDU(s) may then be considerably simplified compared to analysing each transfer of an uplink LLC-PDU. A FLUSH-LL-ACK PDU is also introduced by which the BSS may inform the SGSN whether the queued LLC frames corresponding to the MS were transferred from the old to the new cell or if the queued frames were deleted. Sections affected, and additional explanation of details of change (if needed): The CR affects sections 5.2, 5.2.6, 5.3, 5.3.6, 8.1, , 11.3, and New sections 5.2.7, 5.3.7, , and are also inserted.

22 Attached revised pages: If other core Specifications are affected, necessary (and attached) Joint CRs: Affects MS Test Specifications [ ]BSS Test Specifications [ ]O&M Specifications [ ] (possibly): Attached CRs?: Cross Phase Compatibility:

23 5.2 Service primitives provided by the BSSGP at a BSS Table 5-1/GSM Service primitives provided by BSSGP at a BSS Generic nametype Parameters REQuestINDicationRESponseCoNFirm RL BSSGP RL-DL-UNITDATA-X--BVCI, Refer to DL-UNITDATA PDU RL-UL-UNITDATAX---BVCI, LSP, Refer to UL- UNITDATA PDU RL-PTM-UNITDATA-X--BVCI, Refer to PTM-UNITDATA PDU GMM BSSGP GMM-PAGING-X--BVCI, Refer to PAGING PS Refer to PDU PAGING CS PDU GMM-RADIO-STATUSX---BVCI, Refer to RADIO-STATUS PDU NM BSSGP NM-FLUSH-LL-XX--BVCI, Refer to FLUSH-LL PDU Refer to FLUSH-LL-ACK PDU NM-FLOW-CONTROLX---BVCI, Refer to FLOW- CONTROL PDU NM-STATUSXX--BVCI, Refer to STATUS PDU NM-BVC-BLOCKX--XBVCI, Refer to BVC-BLOCK PDU Refer to BVC-BLOCK- ACK PDU NM-BVC-UNBLOCKX--XBVCI, Refer to BVC-UNBLOCK PDU Refer to BVC-UNBLOCK- ACK PDU NM-BVC-RESETXXXXBVCI, Refer to BVC-RESET PDU Refer to BVC-RESET- ACK PDU NM-TRACE-X--BVCI, Refer to SGSN-INVOKE- TRACE PDU NM-FLUSH-LL.ind ROn receipt of a FLUSH-LL PDU from an SGSN by a BSS from a SGSN, instructing a BSS to delete queued LLC- PDU(s) corresponding to one logical link.the BSS will either delete queued LLC PDUs for a TLLI or move the queued LLC PDUs from an old to a new BVC.

24 5.2.7 NM-FLUSH-LL.res Sending of a FLUSH-LL-ACK PDU to the SGSN from a BSS to report if queued LLC-PDU(s) for an MS were deleted or transferred from the old to the new cell within the NSE.

25 5.3 Service primitives provided by the BSSGP at an SGSN Table 5-2/GSM Service primitives provided by BSSGP at an SGSN Generic nametype Parameters REQuestINDicationRESponseCoNFirm LL BSSGP BSSGP-DL-UNITDATAX---BVCI, LSP, Refer to DL-UNITDATA PDU BSSGP-UL-UNITDATA-X BVCI, Refer to UL-UNITDATA PDU BSSGP-PTM-UNITDATAX---BVCI, Refer to PTM-UNITDATA PDU GMM BSSGP GMM-PAGINGX---BVCI, Refer to PAGING PS PDU Refer to PAGING CS PDU GMM-RADIO-STATUS-X--BVCI, Refer to RADIO-STATUS PDU NM BSSGP NM-FLUSH-LLX---XBVCI, Refer to FLUSH-LL PDU Refer to FLUSH-LL-ACK PDU NM-FLOW-CONTROL-X--BVCI, Refer to FLOW- CONTROL PDU NM-STATUSXX--BVCI, Refer to STATUS PDU NM-BVC-BLOCK-X--BVCI, Refer to BVC-BLOCK PDU Refer to BVC-BLOCK- ACK PDU NM-BVC-UNBLOCK-X--BVCI, Refer to BVC-UNBLOCK PDU Refer to BVC-UNBLOCK- ACK PDU NM-BVC-RESETXXXXBVCI, Refer to BVC-RESET PDU Refer to BVC-RESET- ACK PDU NM-TRACEX---BVCI, Refer to SGSN-INVOKE- TRACE PDU NM-FLUSH-LL.req Request to send a FLUSH-LL PDU from an SGSN to a BSS, instructing a BSS to delete queued LLC-PDU(s) corresponding to one logical link.instructing the BSS to either delete queued LLC PDUs for a TLLI or move the queued LLC PDUs from an old to a new BVC.

26 5.3.7 NM-FLUSH-LL.cnf Receipt of a FLUSH-LL-ACK PDU at an SGSN informing if the queued LLC-PDU(s) for an MS were deleted or transferred from the old to the new cell within the NSE. 8.1 FLUSH-LL (logical link) procedure An SGSN shall send a FLUSH-LL PDU to a BSS to ensure that LLC-PDUs queued for transmission at a cell for an MS are deleted. When an SGSN detects a cell change of a 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, 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 NSE s, LLC-PDU(s) stored at the old BVCI for the TLLI are deleted. AnThe SGSN shall provides the BSSGP with: a an MS s TLLI identifying the MS;, and the old BVCI identifying the cell in which to find buffered LLC-PDU(s) for the MS;, and the new BVCI identifying the cell to which the MS is currently associated (only when within the same NSE). 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. 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; and an indication of whether the LLC-PDU(s) were transferred (when in the same NSE) or 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 un-acknowledged LLC-PDU(s) (in acknowledged LLC operation) to the MS at the new BVC (ie new cell); or relay on LLC retransmission mechanism to transmit un-acknowledged 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 within the NSE, the SGSN shall not take any of the above actions 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.

27 FLUSH-LL This PDU indicates that all buffered LLC-PDUs in a cell for an MS should be deletedinforms a BSS that an MS has moved from one cell to another. PDU type: Direction: FLUSH-LL SGSN to BSS Table 10-6/ GSM 08.18: FLUSH LL PDU content Information elements Type / Reference Presence Format Length PDU type M V 1 TLLI M TLV 6 BVCI (old) M TLV 4 BVCI (new) O TLV FLUSH-LL-ACK This PDU indicates that LLC-PDU(s) buffered for an MS in the old cell have been either deleted or transferred to the new cell within the NSE. PDU type: Direction: FLUSH-LL-ACK BSS to SGSN Table 10-7/ GSM 08.18: FLUSH LL ACK PDU content Information elements Type / Reference Presence Format Length PDU type M V 1 TLLI M TLV 6 Flush action M TLV 3

28 11.3 Information Element Identifier (IEI) An Information Element Identifier (IEI) is identified by the same coding in all BSSGP PDUs. Table 11-1/ GSM 08.18: IEI types IEI coding IEI Types (hexadecimal) x00 x01 x02 x03 x04 x05 x06 x07 x08 x09 x0a8 Alignment Octets Alpha BSS Area Indication BVCI BVC Measurement BVC Throughput Cause Cell Identifier Channel needed DRX Parameters Flush action RESERVED (...) All values not explicitly shown are reserved for future use and shall be treated by the recipient as an unknown IEI 11.3.x Flush Action The Flush action information element indicates to the SGSN the action taken by the BSS in response to the flush request. The element coding is: Table 11-12/ GSM 08.18: Flush Action IE octet 1 octet 2,2a octet IEI Length Indicator Action value Table 11-13/ GSM 08.18: Action coding Action value semantics of coding Hexadecimal All values not listed below are reserved for future use x01 x02 LLC-PDU(s) deleted LLC-PDU(s) transferred All values not explicitly shown are reserved for

29 future use and shall be treated by the recipient as an unknown IEI

30 PDU Type The first octet of a BSSGP PDU shall contain the PDU type ID. The PDU type IE is one octet long. Table 11-18/ GSM 08.18: PDU types PDU type coding (Hexadecimal) x00 x01 x02 x08 x09 x0a x10 x11 x12 x13 x14 x15 x16 PDU Types PDUs between RL and BSSGP SAPs - DL-UNITDATA - UL-UNITDATA - PTM-UNITDATA PDUs between GMM SAPs - PAGING PS - PAGING CS - RADIO-STATUS PDUs between NM SAPs - BVC-BLOCK - BVC-BLOCK-ACK - BVC-UNBLOCK - BVC-UNBLOCK-ACK - FLOW-CONTROL - FLUSH-LL - FLUSH-LL-ACK x20 x21 - BVC-RESET - BVC-RESET-ACK x30 x31 RESERVED - SGSN-INVOKE-TRACE - STATUS all values not explicitly shown are reserved for future use

31 ETSI STC SMG2 WPA Tdoc SMG2 298A214 Sophia Antipolis, France Revision of Tdoc SMG2 298A February 1998 CHANGE REQUEST No. A001r3 Technical Specification GSM version Submitted to SMG for approval without presentation ("non-strategic") [ ] with presentation ("strategic") [ ] Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ] Phase 1: [ ] Phase 2: [ ] Phase 2+: [Release 97] Work item: GPRS Other phase(s) affected: [ ] If yes, linked CR(s): Proposed change affects: SIM [ ] ME [ ] Network [X] Source: SMG2 Date: 15/4/98 Subject: Independent configuration of NS VCs and BVCIs Category: F - Correction [ ] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [x] C - Functional modification of Feature [ ] D - Editorial modification [ ] Reason for change: The specification of the Gb interface specifies the need for a mapping between a BVCI and the group of NS-VCs that can carry the data stream associated to that BVC. This mapping is used by the load sharing entity at the SGSN (for downlink traffic). All the NS-VCs serving the same BVC have to end in the same BSS. This configuration has two main drawbacks: - A BVCI has to be unique within an SGSN, instead of only within a Gb interface (SGSN- BSS pair). - Implementations strictly following the standard will require updates to the SGSN s configuration data whenever a cell is added to a BSS or moved between BSSs. A sensible implementation at the SGSN will load share traffic to a BSS between all the NS-VCs that connect the BSS to the SGSN. In this case the pre-configuration of a cell in the SGSN and the constraint in the number of BVCs in an SGSN is not needed: - The SGSN keeps detailed MM information about an MS while the MS is in the READY state, i.e. the SGSN knows the BVCI which can be used to contact the mobile for downlink transmission. The BVCI is passed from BSSGP to the upper layers as a primitive parameter in every uplink packet received by the SGSN. - An SGSN in Standby state will page an MS before sending downlink traffic. The MS will respond with an LLC packet that will put the MM context in READY state and will deliver the BVCI to the user of BSSGP. It is proposed to define an SGSN internal identifier for the BSS. This identifier (called Network Service Entity Identifier, NSEI) is passed with the BVCI in every uplink packet to the upper layers of BSSGP. The NSEI is used by the load sharing entity to determine the NS-VCs that serve that BVCI (i.e. all the NS-VCs that connect the SGSN to the NSEI). With this internal identifier, the SGSN will not need to be updated when a new cell (BVCI) is added to a BSS (NSEI). A BVCI will only need to be unique within a Gb interface (the global identifier within an SGSN will be BVCI+NSEI). Sections affected, and additional explanation of details of change (if needed): Sections 5.2, 5.3, 5.4.1, 5.4.2, 6.1, 6.2 Attached revised pages: If other core Specifications are affected, necessary (and attached) Joint CRs: CR A007r3 Affects (possibly): Attached CRs?: MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ] Cross Phase Compatibility: Change affects operation of: Phase 1 MS in Phase 2(+) NW [ ] Phase 2(+) MS in Phase 1 NW [ ] CR to attached: Change affects operation of: Phase 1 SIM in Phase 2(+) ME[ ] CR to attached: Phase 2(+) SIM in Phase 1 ME [ ] CR to attached: