Cellular Network Infrastructure » Radio Access Network » OsmoBSC

h1. Ericsson RBS2000 GPRS

{{>toc}}

This page collects some information regarding Ericsson RBS2000 GPRS support. This page is intended as an addition to

the [[OsmoBSC:]] and [[OsmoPCU:]] user manual.

h1. Test setup

In the following we describe a minimal test setup that can be used for development or evaluation. The core network side

of the test network is made of standard Osmocom components with standard configurations, which we will not discuss any

further here. (For more information in core components, see [[Cellular Network Infrastructure:]]). The RAN network side

consists of an Ericsson RBS BTS that is connected to [[OsmoBSC:]]. [[OsmoMGW:]] and [[OsmoPCU:]] run in co-location to

OsmoBSC. In the following we will focus on the configuration of OsmoPCU and OsmoBSC (in co-location).

{{graphviz_link()

digraph G {

    rankdir = LR;

    subgraph cluster_RAN {

        BTS [label="Ericsson RBS"];

        BSC [label="OsmoBSC", color=red,];

        MGW_RAN [label="OsmoMGW"];

        PCU [color=red, label="OsmoPCU"];	

        label = "RAN";

	{ rank=same MGW_RAN PCU BSC }

    }

    subgraph cluster_CN {

        MSC [label="OsmoMSC"];

        MGW_CN [label="OsmoMGW"];

        SGSN [label="OsmoSGSN"];

        label = "CN";

    }

    BTS -> BSC [label="Abis/E1"];

    BTS -> PCU [label="TRAU/E1"];

    BTS -> MGW_RAN [label="TRAU/E1"];

    MGW_RAN -> MGW_CN [label="RTP"];

    BSC -> MSC [label="AoIP"];    

    PCU -> SGSN [label="Gb"];

    BSC -> MGW_RAN [label="MGCP"];

    BSC -> PCU [label="pcu_sock"];

}

}}

h2. Differences to IP based Osmocom RAN

An Osmocom RAN is usually built using IP based base stations with integrated PCU. In those BTSs the PCU runs in

co-location to the BTS process. Also all connections towards the BTS are IP based. When using Ericsson RBS2000/RBS6000

base stations the connection towards the BTS is E1/TDM based. Also those BTSs do not include an integrated PCU, so the

PCU must run in co-location to the BSC. This is the fundamental architectural difference in the RAN setup that has to

be taken into account.

h2. BSC configuration

h3. E1 line

The link towards the BTS is an E1 line. The configuration is straight forward but it should be pointed out that the

E1 line number (0 in this example) must be consistent with the E1 line configuration of the PCU. The reason for this

is that the line number is used to identify lines on the BSC and the PCU side, so they must match up.

<pre>

e1_input

 e1_line 0 driver dahdi

 e1_line 0 port 2

</pre>

h3. Interface switch (IS)

For GPRS/EGPRS an Ericsson RBS2000/RBS6000 provides two interfaces. The first and older interface is a classic 16kbps

subslot based interface and supports only classic GPRS with CS1 and CS2. The second and more recent interface uses

full 64kbps E1 timeslots and offers full EGPRS support. Even though OsmoPCU and OsmoBSC support both interfaces, we

we will only focus on the 64kbps interface here.

The exact BTS type we use is a DUG 20 01, with an RRUS 02 B3 TRU. In the attached config file we configure the Interface

switch (IS) so that it points at the 64kbps interface TRU (first TRX only).

<pre>

bts 0

  is-connection-list add 4 712 36

</pre>

(For details on the IS configuration, see section "Configuring Ericsson RBS Interface Switch (IS)" in OsmoBSC User Manual)

h3. Channels

The BTS is configured to provide 5 TCH/F voice channels and one PDCH channel. The timeslot

number of the PDCH is randomly chosen. The PDCH channel is configured as TCH/F_TCH/H_SDCCH8_PDCH. This means that it is a

dynamic channel (osmocom style). This is due to the fact that the channel configuration in an Ericsson BTS is ipso facto

dynamic. The exact type of the channel is decided during channel activation.

<pre>

 trx 0

   rf_locked 0

   arfcn 875

   nominal power 42

   max_power_red 12

   rsl e1 line 0 timeslot 1 sub-slot full

   rsl e1 tei 0

   timeslot 0

    phys_chan_config CCCH

    hopping enabled 0

    e1 line 0 timeslot 1 sub-slot full

   timeslot 1

    phys_chan_config SDCCH8

    hopping enabled 0

    e1 line 0 timeslot 3 sub-slot full

   timeslot 2

    phys_chan_config TCH/F

    hopping enabled 0

    e1 line 0 timeslot 4 sub-slot full

   timeslot 3

    phys_chan_config TCH/F

    hopping enabled 0

    e1 line 0 timeslot 5 sub-slot full

   timeslot 4

    phys_chan_config TCH/F_TCH/H_SDCCH8_PDCH

    hopping enabled 0

    e1 line 0 timeslot 6 sub-slot full

   timeslot 5

    phys_chan_config TCH/F

    hopping enabled 0

    e1 line 0 timeslot 7 sub-slot full

   timeslot 6

    phys_chan_config TCH/F

    hopping enabled 0

    e1 line 0 timeslot 8 sub-slot full

   timeslot 7

    phys_chan_config TCH/F

    hopping enabled 0

    e1 line 0 timeslot 9 sub-slot full

</pre>

Since we make use of the 64kbps TRU interface. We must configure the sub-slots to use the full bandwidth of the E1

timeslot. The timeslots carrying voice traffic will still use an 16kbps I.460 timeslot, which is always the first

subslot. The remaining three subslots remain unused. This is to be compatible to existing MGWs that will naturally

use a 16kbps for voice. In this configuration OsmoMGW will be instructed by OsmoBSC accordingly. There is no

specific configuration in OsmoMGW required.

h3. PCU socket

When the PCU is co-located with the BTS it communicates directly with the BTS to handle channel requests, pagings,

and channel assignments. In the BSC co-located configuration, the PCU communicates with the BSC in the same way. It is

now the BSC's task to report channel requests and execute the paging requests and channel assignments ordered by the

PCU. The interface is the same Unix domain socket interface that is used in the BTS co-located configuration. It is

configured under the network node using the pcu-socket option.

<pre>

network

 pcu-socket /tmp/pcu_bts

</pre>

Since only one PCU instance runs in co-location to the BSC the PCU will serve multiple BTSs at a time. (Similar to an

MGW that also may serve multiple BTSs at once). OsmoPCU should be capable to serve multiple BTS at a time but the

current implementation (March 2023) has not seen much testing in this particular configuration yet, so it is likely

that there are still problems that require fixing.

h2. PCU configuration

h3. E1 line

Since OsmoBSC and OsmoPCU use the E1 implementation provided by libosmo-abis, the E1 configuration is exactly the

the same as in the BSC. Since (as mentioned above) the e1_line number is used to identify the E1 line through the

PCU socket interface, the E1 line number must match the E1 line number configured in the BSC.

<pre>

e1_input

 e1_line 0 driver dahdi

 e1_line 0 port 2

</pre>

h3. PCU Parameter

In the PCU itself no other parameters have to be configured. The configuration details (GPRS parameter, E1 timeslot,

E1 subslot etc.) are provided by the BSC through the PCU socket interface.

h3. Example configuration

The attached file (e1_egprs_testnetwork.tar) contains the OsmoBSC and OsmoBSC configuration files discussed above

along with all config files from all other network components. The files can be used as a starting point to reproduce

a working EGPRS setup using an Ericsson RBS2000/RBS6000 base station.

h1. Technical details

h2. PDCH timeslot configuration

It seems that in OM2000 all TCH (/F, /H, PDCH) are configued with a Combination "8", and no differentiation is made

The actual activation of the channel is expected via RSL.  So it's analogous to a RSL CHAN ACT for TCH/H or TCH/F, but

we also do this for a PDCH. In order to do so, we send a RSL CHAN ACT with Channel Number 0b11000 + the timeslot

number.  Deactivation works the same way.

h2. GPRS RACH requests

The BSC must identify the GPRS RACH requests (similar to osmo-bts currently) and pass them into the PCU.  This could

be done using the same pcu socket interface that already exists.

h2. GPRS paging

Thre's a RSL "Packet Paging Indication IE" (IEI = 0xF3) that the BSC can include when sending a paging request to the

BTS. It's currently not clear what this is used for and why it is required.

h2. TRAU frames

Classic GSM TRAU frames (for circuit switched voice) are transmitted on 16kBps sub-slots and are 39 octets (312 bits)

long. They thus occur every 19.5ms.  Four 16kbps sub-slots are multiplexed into a 64kbps E1 slots. For more information

see 3GPP TS 48.060.

Ericsson also introduces 64kbps TRAU frames (for higher EGPRS coding schemes).

The Synchronization of TRAU frames is based on a 16-bit all-zero field at the beginning of each TRAU frame (called the

T0 bits) followed by a single 1 bit (called the T1 bit).

A detailed description the TRAU frame format can also be found in the libosmo-abis code:

See also: https://gitea.osmocom.org/osmocom/libosmo-abis/src/branch/master/src/trau/trau_pcu_ericsson.c

h3. 16kBps sub-slots

h4. PCU-DATA.ind

This frame can be used by a CS-1 or CS-2 frame transmitted by the PCU, i.e. downlink.

|T|17|T0*16,T1*1|Sync Word|

|C|8|C1..C8|Control Bits (Frame Type, Time adjustmentValue,Uplink Frame Error)|

|PC|1|PC|Parity (C1..C8)|

|E|16|E1..E16|Codec Control, Uplink Channel Mode, Power Control|

|PE|1|PE|Parity (E1..E16)|

|D|273|D1..D273|Data bits|

|TA|4|TA1..TA4|Time Alignment|

h4. CCU-DATA.ind

This frame can be used by a CS-1 or CS-2 frame transmitted by the CCU, i.e. uplink.

h3. 64kBps slots

h4. PCU-DATA-64.ind

|T|65|T0*64,T1*1|Sync Word|

|D|48|D1..D48|Data bits|

|C|8|C1..C8|Control Bits|

|PC|1|PC|Parity (C1..C8)|

|E|36|E1..E36||

|PE|1|Parity (E1..E36)|

|S|21|S1..S21||

|D|1132|D1..D1132|Data bits|

|TA|16|TA1..TA16|Time Alignment bits|

|Total|1328|

h4. PCU-DATA-MCS9.ind

|T|17|T0*16,T1*1|Sync Word|

|D|48|D1..D48|Data bits|

|C|8|C1..C8|Control Bits|

|PC|1|PC|Parity (C1..C8)|

|E|9|E1..E9||

|PE|1|Parity (E1..E36)|

|D|1172|D49..D1228|Data bits|

|TA|16|TA1..TA16|Time Alignment bits|

|Total|1272|

h4. CCU-DATA-64.ind

|T|65|T0*64,T1*1|Sync Word|

|C|7|C1..C7|Control bits (FT, TAV)|

|PC|1|PC|Parity (C1..C7)|

|E|57|E1..E57|DBE, Codec Status, Receiver Level, Access Delay Deviation, Block Quality Measurement, Block Status Report,

Spare, MEAN_BEP, CV_BEP, Header Quality, Data Block Quality|

|PE|1|PE|Parity (E1..E57)|

|S|3|S1..S3|Spare (set to 1)|

|D|1138|D1..D1138|Data bits|

|TA|8|TA1..TA8|Time Alignment bits|

|Total|1280|

h4. CCU-DATA-MCS9.ind

|T|17|T0*16,T1*1|Sync Word|

|D|48|D1..D48|Data bits|

|C|7|C1..C7|Control bits|

|PC|1|PC|Parity (C1..C7)|

|E|23|E1..E23||

|PE|1|PE|Parity (E1..E23)|

|S|2|Spare|

|D|1165|D49..D1221|Data bits|

|TA|8|Time Alignment bits|

|Total|1272|

h4. CCU-SYNC-64.ind

Sent from CCU to PCU (uplink)

|T|17|T0*16+T1*1|Sync Word|

|C|8|C1..C8|Control bits (FT, TAV, DFE)|

|PC|1|PC|Parity (C1..C8)|

|E|1|E1|DBE (DownlinkBlockError)|

|PE|1|PE|Parity (E1)|

|D|44|D1..D44|Data bits|

|T|1|T1||

|D|55|D45..D99|Data bits|

|T|1|T1||

|D|1079|D100..D1178|Data bits (DPSEQ, DaFNu, DaFNd)|

|TA|8|TA1..TA8|Time Alignment bits|

|Total|1216|

h4. PCU-SYNC-64.ind

|T|65|T0*64+T1*1|Sync Word|

|C|8|C1..C8|Control|

|PC|1|Parity (C1..C8)|

|D|54|D1..D53|Data bits|

|T|1|T1||

|D|63||Data bits|

|T|1|T1||

|D|1071|..D1172|Data bits|

|TA|16|TA1..TA16|Time Alignment bits|

|Total|1280|

h2. Trau Procedures

h3. SYNC procedure

Whenever the uplink is idle, the CCU is sending CCU-SYNC.ind towards the PCU.  This frame includes:

* Time Adjustment Value

** 00: no change

** 01: delay 250us

** 10: advance 250us

* Downlink Frame Error: Set to '0' in case the CCU receives bad downlink frames from the PCU

** once we send valid frames in downlink, the bit should change to '1'

* Downlink Block Error: Set to '0' when a downlink block was not transmitted

* DPSEQ: ?

* afn_ul: Adjusted Frame Number Upliink

* afn_dl: Adjusted Frame Number Downlink

Whenever the downlink is idle, the PCU is sending PCU-SYNC.ind towards the CCU. This frame includes:

* Time Adjustment Value (see above)

* Uplink Frame Error: Set to '0' in case the PCU receives bad uplink frames from the CCU

* DPSEQ: PCU-internal counter which probably gets echo'ed back in uplink DPSEQ for the PCU to measure RTT?

* optional dss, dfn_u, dfn_ss, dfn_d and dls fields, ignored by PCU.

A detailed description of the synchronization procedure can be found in the libosmo-abis code:

https://gitea.osmocom.org/osmocom/libosmo-abis/src/branch/master/include/osmocom/trau/trau_pcu_ericsson.h