3GPP TSG GERAN

Adhoc on release 2000 and beyond #2

Tdoc GERAN Adhoc GAHW- 00044

Agenda Item 6.1.2

Munich, Germany
9th September 13th September 2000
Source: Alcatel

Inter-BSC Hard handover in GERAN for the PS domain

R2000
1 Introduction
SA WG2 made an answer to the LS issued by TSG-GERAN on Inter-BSC hard handover for
the packet switched domain [2]. In their answer, SA WG2 expressed some concern with the
working assumption taken by TSG-GERAN about the role of Iur-g with regards to the support of
user plane data.
This contribution tries to start a study that should determine the pros and cons of the support of
user plane data by the Iur-g.

2 Discussion
It has been agreed that the Iur-g supports a sub-set of RNSAP protocol as defined for UTRAN.
So, this discussion only talk about the user plane.
This section is intended to provide technical discussion on handovers and cell reselections in
the two cases: Iur-g only used for signalling, and Iur-g used for both signalling and GERAN
PDUs (RLC/MAC-PDUs).
Then, the consequences of requirements such as ciphering over A-bis and asynchronous
transport networks (ATM, IP) is analysed.
Eventually, the impacts of the introduction of an Iur-g user plane will be evaluated in order to
determine the pros and cons of such a solution.

2.1

Handovers and cell reselections

2.1.1

UMTS inter-RNC hard handovers for RT services

They are needed for example when the cells (controlled by different RNCs) are on different
frequencies.
In this case, the MAC-PDUs are sent over the Iur, and the Serving RNC does not change. See
[5] TR 25.931 v3.1.0 section 7.11.1.1.
Main advantages are:
-

Independence of Core Network from hard handovers, which should be treated at RAN
level only.

Independence of hard handovers and SRNC Relocations. Since the hard handovers do
not lead to simultaneous SRNC Relocation, the frequency of SRNS Relocations can be
very low. SRNC Relocations could be performed only to optimise the GGSN/SGSN path.

CN is less loaded since not involved in Hard Handovers (Relocation are a lot less
frequent than inter-BSC hard handovers).

Hard handovers will be much faster (since less nodes and less signalling messages are
used) and have a lower failure rate, improving the quality of service as perceived by the
end-user.

GAHW- 00044

Page 1/8

2.1.2

Inter-BSC GERAN handovers and relocations

The GERAN-BSC / SGSN functional split will be based on the same principles as the UTRANRNC / SGSN functional split since they use the same Iu-ps interface. Therefore, the Handover
and Relocation mechanisms adopted for UTRAN could be used for GERAN as well.
For inter-BSC handovers, it would be very beneficial to use the same mechanisms as UMTS
inter-RNC hard handovers, i.e. to use Iur to transfer Radio PDUs (RLC-PDUs or MAC-PDUs)
between a "Serving BSC" and the "Drift BSC".
It has the advantage to allow a simple and homogeneous way to handle Handovers in GERAN
and in UMTS since anchor points and mechanisms would be very similar.
However, these advantages have to be compared together with the additional functions implied
with the introduction of an Iur-g user plane.
The handovers and cell reselections without Iur-g user plane and with Iur-g user plane are
presented in flow charts below .
2.1.3

Inter-BSC Handover without the use of Iur-g user plane

The following flow chart takes principles from the UTRAN behaviour. It shows signalling
messages for an inter-BSC handover without the use of user plane over Iur-g, i.e. via Core
Network (PS domain only). Iur-g is only used for signalling (equivalent to a subset of UTRAN
RNSAP).
The flow chart comes from UTRAN specifications [5]. It is only for information, with UTRAN
message naming, but shows the main proposed principles. The messages and signalling layers
in GERAN may have different names.

2(8)

BTS
Source

BTS
Target

BSC
Source

RANAP

BSC
Target

1. Relocation Required

3G-SGSN
Source

3G-GGSN
Target

GGSN

RANAP
2. Fwd Relocation Request

4. Relocation Request
RANAP

NBAP

NBAP

6. Radio Link Setup Request

RANAP

NBAP

7. Radio Link Setup Response

NBAP

8. Data Transport Bearer Setup

10. Relocation Request

Acknowledge
RANAP

RANAP

PDP Context Update

procedure
Fwd Relocation Ack

RANAP

12. Relocation Command

RANAP

UE is sent to the target cell by a HO Command message

15. Relocation Detect
RANAP

RANAP

19. Relocation Complete

RANAP

RANAP

Fwd Relocation Complete

RANAP

20. Iu Release Command

RANAP

Release of source BTS/BSC resources

RANAP

2.1.4

23. Iu Release Complete

RANAP

Inter-BSC Handover with the use of Iur-g user plane

The following flow chart takes principles from the UTRAN behaviour. It shows signalling
messages for an inter-BSC handover with the use of user plane over Iur-g. In this case, the
Core Network is not involved.
BSC Relocation is not necessary.
The flow chart comes from UTRAN specifications [5]. It is only for information, with UTRAN
message naming, but shows the main proposed principles. The messages and signalling layers
in GERAN may have different names.

3(8)

UE

BTS
Source

BTS
Target

BSC
Source

BSC
target

Serving BSC

RNSAP
2. Radio Link Setup Request

NBAP

RNSAP

5. RL Setup
Response

RNSAP

NBAP

3. Radio Link Setup Response

NBAP

1. Radio Link
Setup Request

NBAP

4. Data Transport Bearer Setup

RNSAP

6. Iur-g Data Transport

Bearer Setup

UE is sent to the target cell by a Physical Reconfig. RRC message and answers via RRC message on the new cell

RNSAP

11. Radio Link Deletion Request

RNSAP

Release of source BTS/BSC resources

RNSAP

15. Radio Link Deletion Response

RNSAP

16. Iur-g Data Transport

Bearer Release

2.1.5

Inter-BSC Cell Reselection without the use of Iur-g user plane

The flow chart comes from UTRAN specifications [5]. It is only for information, with UTRAN
message naming, but shows the main proposed principles. The messages and signalling layers
in GERAN may have different names.

4(8)

UE

Drift-BSC
source

Drift-BSC
target

Serving-BSC

1. Cell Update
RRC

RRC-relay
2. Uplink Signalling Transfer
Indication
RNSAP

[new ident,,
UL message]

RNSAP

3. Common Transp. Channel Resources

Initialization Request
RNSAP

RNSAP

4. Common Transp. Channel Resources

Initialization Response
RNSAP

RNSAP

5. Iur-g bearer setup

RRC

6. Cell Update Confirm

RRC

7. RNTI Relocation Complete

RRC

RRC

RNSAP

2.1.6

8. Common Transp. Channel Resources Release

RNSAP

Inter-BSC Cell Reselection with the use of Iur-g user plane

The flow chart comes from UTRAN specifications [5]. It is only for information, with UTRAN
message naming, but shows the main proposed principles. The messages and signalling layers
in GERAN may have different names.

5(8)

UE

Drift-BSC
source

Drift-BSC
target

Serving-BSC

1. Cell Update
RRC

RRC-relay
2. Uplink Signalling Transfer
Indication
RNSAP

[new ident,
UL message]

RNSAP

3. Common Transp. Channel Resources

Initialization Request
RNSAP

RNSAP

4. Common Transp. Channel Resources

Initialization Response
RNSAP

RNSAP

5. Iur-g bearer setup

RRC

6. Cell Update Confirm

RRC

7. RNTI Relocation Complete

RRC

RRC

RNSAP

2.2
2.2.1

8. Common Transp. Channel Resources Release

RNSAP

Impacts of various requirements on GERAN Architecture

Impact of ciphering requirements

In UTRAN, SA WG3 has requested that UE-UTRAN user and signalling information over Iub be
ciphered mainly because Iub can make use of microwave links. In GPRS, ciphering is
performed in the SGSN. If the requirement is similar in GERAN over A-bis, ciphering should be
performed in the BSC.
In acknowledged and unacknowledged mode, ciphering is part of RLC layer. In transparent
mode, it has been proposed to perform ciphering in the MAC layer in order to align function to
UTRAN (Ciphering is in MAC layer to take benefit from the sequence numbering).
More exactly, in UTRAN:
In UTRAN, MAC layer is divided in MAC-d and MAC-c/sh sub-layers. MAC-d sub-layer being
the part of MAC that is dedicated to the UE, MAC-c/sh sub-layer being the performing the
multiplexing of several users in case of shared transport channels.
Dedicated Transport Channels (DCHs) only make use of MAC-d.
Downlink Common Transport Channels (FACH, DSCH) make use of MAC-d in the Serving
RNC, and MAC-c/sh in the Controlling RNC.
Ciphering is in MAC-d sub-layer in all the cases.
This implies that RLC and MAC-d layers be in the BSC. There is not anymore
implementation choice as it was for GSM/GPRS.

6(8)

2.2.2

Requirement for asynchronous transport on A-bis and associated impact

Today, A-bis is supported by PCM links.

In R2000, GERAN should support UMTS Iu-ps interface. This interface is ATM based in R99. In
UMTS, Iur interface, in most of the configurations, uses the same physical interface as Iu.
Furthermore, multi-standard RNC/BSCs and NodeB/BTSs are more than likely. UTRAN R2000
will have ATM and IP transport options.
Therefore, it is more than likely that GERAN Iur-g and GERAN A-bis have to support
Asynchronous Transport Networks such as ATM or IP networks.
In this requirement is confirmed, the delay variation of these asynchronous transport networks
has to be taken into account. Since the radio frames have to be sent every TTI (Transmission
Time Interval), there is a need for buffering in the BTS. A per call/session Time Adjustment
procedure, similar to the one existing in UMTS between SRNC and NodeB will be
necessary. This procedure is intended to minimise the buffers in the NodeB and is defined in
TS25.402 [3] and in TS25.427 for dedicated channels [4].
2.2.3

Conclusions

If these requirements are confirmed:

MAC-d PDUs should be standardised,

Time Adjustment procedure should be standardised,

Several L2 transport networks should be possible.

2.3

Impacts of the introduction of an Iur-g user plane

It is clear that, for multi-vendor interoperability reasons, Iur-g should be an open interface. The
impacts of the introduction of Iur-g user plane, i.e. allowing Iur-g to carry MAC-d PDUs are the
following:

Need of standardising MAC-d PDUs,

Need of standardising a Time Adjustment procedure,

Need of separating MAC into two parts: MAC-d in the Serving-BSC and MAC-c in
Controlling-BSC, as it is done in UTRAN,

Other additional needs to be find out.

The first two impacts are already needed anyway (if above requirements are confirmed). Only
the third one is additional impact.
It is proposed to study the amount of complexity lead by the separation of MAC layer into MACd and MAC-c/sh sub-layers, and by other possible additional needs, in order to evaluate
whether these additional developments might counterbalance the advantages described for
inter-BSC handover and cell reselection.

3 Proposal
It is proposed to take the above issues to start a study with pros and cons on the support of Iurg user plane.
For the sake of the study, it is proposed:
-

To send a Liaison Statement to SA WG3 to ask their opinion on whether GERAN A-bis
should be ciphered or not.

To clarify whether the transport network could be asynchronous (ATM, IP, etc).

It is proposed that, as output of the study, TSG-GERAN write a LS to SA WG2 which explains
the rationale of the study outcome as required by SA WG2 in its answer LS [2].

7(8)

4 References
[1] TSGG#01-000374 LS from TSG-GERAN to SA-WG2 on inter-BSC hard handover in
GERAN for the PS domain
[2] GAHW-00042 (original S2-001637) Answer LS from SA-WG2 to TSG-GERAN on interBSC hard handover in GERAN for the PS domain
[3] TS 25.402 v3.2.0, Synchronisation in UTRAN Stage 2
[4] TS 25.427 v3.3.0, UTRAN Iub/Iur Interface User Plane Protocol for DCH Data Streams
[5] TR 25.931 v3.1.0, UTRAN Functions, Examples on Signalling Procedures.

8(8)