4 GERAN Architecture

3GPP43.051GSM/EDGE Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 GERAN Reference Architecture

The reference architecture of GERAN is illustrated in Figure 1.

GERAN connects with 3 interfaces A, Gb and Iu interfaces to the core network. Any combination comprising one, two or three of these 3 interfaces is possible. Two Base Station Subsystems (BSS) may be connected to each other with an Iur-g interface. A BSS and an RNC may also be connected via an Iur-g interface.

The mobile station shall operate using only the following modes:

a) A/Gb mode, e.g. for pre-Release 5 terminals, for Release 5 terminals when connected to a GERAN with no I_u interface towards the Core Network;

b) Iu mode (i.e. I_u-CS and I_u-PS), e.g. for Release 5 terminals when connected to a GERAN with I_u interfaces towards the Core Network.

Both modes must be supported by the standard and no other modes (e.g. A / I_u-PS or I_u-CS / G_b) shall be allowed.

Figure 1: GERAN reference architecture

The functional split within a BSS is implementation-dependent.

4.2 UMTS Architecture applied to GERAN

This clause describes the GERAN architecture when it connects to the core network through an Iu interface. Figure 2 shows the assumed UMTS architecture as outlined in 3GPP TS 23.110. GERAN is showed instead of UTRAN. The figure below shows the UMTS architecture in terms of its entities Mobile Station, GERAN and Core Network. The respective reference points Um (Radio Interface) and Iu (CN-RAN reference) are shown. The figure illustrates furthermore the high-level functional grouping into the Access Stratum and the Non-Access Stratum.

The Access Stratum offers services through the following Service Access Points (SAP) to the Non-Access Stratum:

– General Control (GC) SAPs;

– Notification (Nt) SAPs; and

– Dedicated Control (DC) SAPs.

The SAPs are marked with circles in Figure 2.

Figure 2: UMTS Architecture applied to GERAN

This model can be further refined to distinguish the end AS entities, which provide the services to higher layers, from the local entities, which provide services over respectively the Um and the Iu reference point. Figure 3 presents the refined model.

Figure 3: Assumed GERAN Model

4.3 Protocol architecture in PS domain

4.3.1 General

Specifications and more detailed descriptions of the Iu-ps interface protocols and architecture can be found in [1-6].

Specifications and more detailed descriptions of the Gb interface protocols and architecture can be found in [7-9].

The Um interface protocols are described in clauses 5 and 6.

4.3.2 User plane

Figure 4 shows the user plane for GERAN connected to a packet switched core network domain. For reference, GPRS and UMTS protocol stacks when connected to the packet switched core network domain are described in 3GPP TS 23.060 [24].

Figure 4: User Plane protocols towards Packet Switched Core Network domain

The Iu-ps protocol stack is inherited from UMTS specifications (Ref. 1-6). However, GERAN expects more transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN").

4.3.3 Control plane

Figure 5 shows a high level view of the control plane for GERAN when connected to a packet switched core network domain. For reference, GPRS and UMTS Control Plane protocol stacks when connected to the packet switched core network domain are depicted in Figures 7 of [24] and 8 of [24] respectively.

Figure 5: Control Plane protocols towards Packet Switched Core Network domain

NOTE: The Iu-ps protocol stack is inherited from UMTS specifications (Ref. 1-6). However, GERAN expects more transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN").

NOTE: RRC uses the services of LAPDm only on broadcast control channels.

4.4 Protocol architecture in CS domain

4.4.1 General

Specifications and more detailed descriptions of the Iu-cs interface protocols and architecture can be found in [1‑6.].

Specifications and more detailed descriptions of the A interface protocols and architecture can be found in [13-18].

The RLP Protocol is found in [23].

The Um interface protocols are described in clauses 5 and 6.

Within GERAN, speech and data frames will be transmitted at the radio interface using a specific channel coding. As the support of transceivers with limited capabilities has to be assured, the capabilities provided by the GERAN have to be taken into account by the CN during call set-up and Relocation. Additionally, in case a RAB has to be established or relocated for CS services, it is required that the GERAN BSC receives specific information from the MSC-Server.

4.4.2 User plane

Figure 6 shows the user plane for GERAN connected to a circuit switched core network domain

Figure 6: User Plane protocols towards Circuit-Switched Core Network domain

NOTE: The figure only shows existing Release 99 Transport layer options for A and Iu-cs.

NOTE: The Iu-cs protocol stack is inherited from UMTS specifications [1-6]. However, GERAN expects more transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN").

4.4.3 Control plane

Figure 7 shows the control plane for GERAN connected to a circuit switched core network domain.

Figure 7: Control Plane Protocols towards Circuit-Switched Core Network Domain

NOTE: The Iu-cs protocol stack is inherited from UMTS specifications [1-6]. However, GERAN expects more transport layer options than ATM (3GPP Work Item "IP Transport in UTRAN").

NOTE: RRC uses the services of LAPDm only on broadcast control channels.

4.5 Iur-g interface

4.5.1 General principles

The support of the Iur-g interface in GERAN is optional. It should be noted however that this allows for registration areas to span across several BSS (and possibly RNS) areas. Registration areas may refer to GRAs or URAs.

The general principles for the specification of the Iur-g interface are as follows:

– the Iur-g interface should be open;

– the use of the Iur-g interface may be used for Mobile Stations operating in Iu mode but not for Mobile Stations operating in A/Gb mode;

– the Iur-g interface shall support the exchange of signaling information between two BSSs, or between a BSS and an RNC;

– from a logical standpoint, the Iur-g is a point to point interface between two BSSs or between a BSS and an RNC. A point to point logical interface should be feasible even in the absence of a physical direct connection between the two entities;

– the behaviour of the MS shall be independent of the presence of the Iur-g interface or of the presence of any of its planes.

When specifying the Iur-g interface, it is deemed necessary to introduce a separation between the Radio Network functionality and the Transport Network functionality to facilitate introduction of future technology (see Figure 8).

Figure 8: Separation of Radio Network Protocols and transport over the Iur-g interface

4.5.2 Protocol architecture

Figure 9 represents the protocol architecture for Iur-g interface. It is based on the UTRAN Iur protocol architecture, where only the control plane of the protocol is used for Iur-g. See [19-22].

The Radio Network Subsystem Application Part (RNSAP) for GERAN contains a sub-set of the UTRAN RNSAP procedures. However the contents of the messages used over Iur-g might differ.

NOTE: The Transport Network protocols shown here are adopted from UTRAN Release 99, although they are subject to change for GERAN Release 5 and this figure will be modified accordingly.

Figure 9: Iur-g Protocol Architecture

4.5.3 RNSAP protocol

The protocol responsible for providing signaling information across the Iur-g interface is called the Radio Network Subsystem Application Part (RNSAP). The RNSAP is terminated by the two BSSs or the BSS and the RNC inter-connected via the Iur-g interface RNSAP Procedure Modules.

RNSAP procedures as defined in UTRAN are divided into four modules as follows:

1. RNSAP Basic Mobility Procedures;

2. RNSAP DCH Procedures;

3. RNSAP Common Transport Channel Procedures;

4. RNSAP Global Procedures.

In case of GERAN Iur-g, only RNSAP Basic Mobility Procedures and RNSAP Global Procedures are adopted from UTRAN and modified as necessary. Table 1 lists elementary procedures that are used with RNSAP in Iur-g interface. These are Class 2 procedures that do not require response and are always considered successful.

The Basic Mobility Procedures module contains procedures used to handle the mobility within GERAN, while the Global Procedures module contains procedures that are not related to a specific MS.

Table 1: Elementary Procedures

Elementary Procedure	Initiating Message
Uplink Signaling Transfer	UPLINK SIGNALLING TRANSFER INDICATION
Downlink Signaling Transfer	DOWNLINK SIGNALLING TRANSFER REQUEST
SRNS Relocation Commit	SRNS RELOCATION COMMIT
Paging	PAGING REQUEST
Error Indication	ERROR INDICATION

4.6 Support for MSC/SGSN in pool

The stage 2 description on how the MSC/SGSN in pool concept is supported in the BSS and MS in GERAN Iu mode is described in [31].

4.7 CS services for GERAN Iu-mode

Call Set-up:

In case of a call set-up towards the CS domain, the BSC shall provide GERAN specific capabilities in the "GERAN Classmark" within the INITIAL UE MESSAGE to the MSC-Server of the serving cell that have to be taken into account by the MSC-Server during call set-up (e.g. to negotiate a speech codec [38]).

To be able to set-up an appropriate RB with the corresponding channel coding for a CS service, the BSC will receive specific information within the "GERAN BSC Container" from the MSC-Server within the RAB ASSIGNMENT REQUEST message.

In case the MS moves to a new cell during the period between the transmission of the INITIAL UE MESSAGE and the reception of the RAB ASSIGNMENT REQUEST message, the RAB Assignment may fail, as the BSC may not be able to set-up the requested RB, because different capabilities are provided in that new cell. In this case the BSC shall report the unsuccessful RAB establishment to the CN by indicating an appropriate cause value within the RAB ASSIGNMENT RESPONSE message and shall include the "GERAN Classmark" of the new cell. Based on the received "GERAN Classmark" the MSC-Server may re-attempt the RAB Assignment procedure.

Relocation:

In case the whole RAN provides the same capabilities with regard to CS services, the exchange of the "GERAN Classmark" between RAN and CN is not required during the Relocation procedure.

In case the whole RAN does not provide the same capabilities with regard to CS services, the exchange of the "GERAN Classmark" between RAN and CN is required during the Relocation procedure to avoid that the CN has to store cell related information and to be able to reuse the existing Relocation procedure inside the CN. The exchange of the "GERAN Classmark" shall be performed as follows: In case of Relocation to GERAN Iu-mode, the Source RAN-node shall transfer the "GERAN Classmark" of the GERAN target cell to the MSC-Server within the RELOCATION REQUIRED message, which has to be taken into account by the CN during the execution of the Relocation procedure.

To be able to set-up an appropriate RB with the corresponding channel coding in the target cell for a CS service, the Target BSC will receive the requested specific information within the "GERAN BSC Container" from the MSC-Server within the RELOCATION REQUEST message.

In case the target BSC cannot allocate radio resources corresponding to the "GERAN BSC Container" content, received within the RELOCATION REQUEST message, the BSC shall report this failure event by including an appropriate cause value within the RELOCATION FAILURE message to the MSC-Server. In this case the target BSC shall additionally include the "GERAN Classmark" of the target cell in the RELOCATION FAILURE message sent to the MSC-Server. If the MSC-Server receives a RELOCATION FAILURE message indicating "GERAN Iu-mode failure", the MSC-Server shall report this relocation failure to the source RAN node. Optionally, if the received "GERAN Classmark" shows that the requested CS service is incompatible with the transceiver capabilities of the target cell, the MSC-Server may initiate a second handover attempt towards the target BSC taking the received "GERAN Classmark" into account.

4.8 User Equipment Specific Behaviour Information (UESBI) in GERAN Iu mode

The Provision of User Equipment Specific Behaviour Information to network entities (PUESBINE) feature is described in 3GPP TS 23.195 [31]. The PUESBINE feature is supported in GERAN Iu mode as in UTRAN and in GERAN, it is applicable only to the UMTS functionality and GERAN to UTRAN handovers.