Work Plan, Work Items and Study Items

Work Item Description (“WID”) (also called WI Description) and Study Item (also called "Feasibility Studies") are forms which initial version provides the target to be reached before starting the technical work. Potential subsequent versions narrow the target and foreseen completion date according the actual progress. They are stored in:

 

http://www.3gpp.org/ftp/Information/WI_sheets/

 

The 3GPP Work Plan is a living document, updated roughly each month, which contains the full list of Work Items and Study Items, as well as summary information for each WI, as: the WG in charge of it, its starting date and (foreseen or actual) completion date, the actual progress, etc. The Work Plan is available at:

 

http://www.3gpp.org/ftp/Information/WORK_PLAN/

 

Change Request database

A specification is originally drafted and maintained by a rapporteur, who compiles the contents from discussions in the WGs and TSGs. When it is considered to be 80% complete, it is brought under a so-called "change control" process. After this, changes to the specification can only be made using Change Requests that are usually agreed by consensus in the Working Group responsible for the specification, and then formally approved by the relevant Technical Specification Group[1].

 

The Change Request database contains all available information on Change Requests, including a Work Item code, a Change Request number that is unique within the specification (different versions are possible, but only one can ever be approved), the status of each Change Request and references to relevant temporary document numbers and meetings. This database is available in:

 

http://www.3gpp.org/ftp/Information/Databases/Change_Request/

 

Further information on CR is available at:

http://www.3gpp.org/specs/CR.htm

 

New Features applicable to UMTS and GSM

Bearer Independent CS architecture (also called “Bearer Independent Core Network”)

 

Acronym: CSSPLIT / BICC

UID: 1322

Main responsibility: CN4

 

References for WI " Enable bearer independent CS architecture "

Document	Title/Contents
NP-000538	Bearer Independent Circuit-Switched Core Network
Impacted Specifications
TS 29.007	General requirements on Interworking between the PLMN and the ISDN or PSTN
TS 23.002	Network Architecture
New Dedicated Specifications
TS 23.205 TS 29.205   TS 29.232   TS 29.414	Bearer-independent circuit-switched core network – Stage 2 Application of Q.1900 Series to Bearer Independent CS Core Network Architecture – Stage 3 Media Gateway Controller (MGC) – Media Gateway (MGW) Interface; Stage 3 Core Network Nb Data Transport and Signalling Transport   And the re-use of the ITU-T Q.19xx series of recommendations, in particular the Q.1902.x, as defined in TS 29.205

 

Introduction

The objective of this feature is to dissociate the transport and the control in the Circuit Switched (CS) domain. The aim is to offer a better transport resource efficiency and a convergence with the Packet Switched (PS) domain transport. Also, this enables to use one single set of layer 3 protocols (e.g. DTAP in TS 24.008 or MAP in TS 29.002) on top of different transport resources, as ATM, IP, STM, or even new ones.

 

The users shall not notice whether they are connected to a “bearer independent CS network” or to a classical CS domain. This implies that both types of network offer the same bearer and teleservices, and have same external behaviour for the handling of the call control, related supplementary services, application services and mobility support. Also, none of the protocols used on the radio interface is modified by this feature. This means for example there is no need for the terminals to support IP even if IP is the transport protocol used in the network.

Architecture

The basic principle is that the MSC is split into an MSC server and a (Circuit-Switched) Media Gateway (CS-MGW), the external interfaces remaining the same as much as possible as for a monolithic MSC. The MSC server provides the call control and mobility management functions, and the CS-MGW provides the stream manipulating functions, i.e. bearer control and transmission resource functions.

The same applies to the GMSC, split into a GMSC server and a CS-MGW.

 

BICC Network Architecture

G)MSC Server

The MSC Server comprises all the call control and mobility control parts of an MSC. As such, it is responsible for the control of mobile originated and mobile terminated CS domain calls. It terminates the user to network signalling (see in particular TS 24.008) and translates it into the relevant network to network signalling (see in particular TS 29.002). It also contains the VLR.

The MSC Server controls the parts of the call state that pertain to connection control for media channels in a CS-MGW.

A GMSC Server is to a GMSC as an MSC Server is to an MSC.

2.1.2.2 Circuit Switched - Media Gateway (CS-MGW [2])

The CS-MGW interfaces the transport part of the UTRAN/BSC with the one of the core network, over Iu or the A interface. It interacts with the (G)MSC server for resource control.

A CS-MGW may also terminate bearer channels from a circuit switched network and media streams from a packet network (e.g., RTP streams in an IP network). As the entity interfacing the access and the core network, the CS-MGW operates the requested media conversion (it contains e.g. the TRAU), the bearer control and the payload processing (e.g. codec, echo canceller, conference bridge). It supports the different Iu options for CS services (AAL2/ATM based as well as RTP/UDP/IP based).

The CS-MGW bearer control and payload processing capabilities also need to support mobile specific functions such as SRNS relocation/handover and anchoring. Current H.248 standard mechanisms are applied to enable this. Further tailoring (i.e packages) of the H.248 may be required to support additional codecs and framing protocols, etc.

Note that no confusion should be made between the CS-MGW defined here and the IMS Media Gateway, the IM-MGW, defined in Release 5.

Interfaces and protocols