Ericsson RBS2000 GPRS » History » Version 2
laforge, 06/25/2016 02:46 PM
1 | 1 | laforge | h1. Ericsson RBS2000 GPRS |
---|---|---|---|
2 | |||
3 | This page collects some information regarding Ericsson RBS2000 GPRS support. |
||
4 | |||
5 | The fundamental difference between what we do so far (PCU co-located with BTS) and this architecture is that the PCU is co-located with the BSC! |
||
6 | |||
7 | In order to have (E)GPRS support using RBS2000, we need to solve the following parts: |
||
8 | * configuration / activation of timeslots using OML2000 / RSL? |
||
9 | * ensuring that GPRS related SI, particularly SI13 are broadcast via BCCH |
||
10 | * implementation of PCU TRAU frame format and converter between osmo-pcu PHY interface and them |
||
11 | ** 16k sub-slot and 64k slot formats |
||
12 | ** associated PCU SYNC protocol |
||
13 | ** all various coding schemes |
||
14 | * paging coordination between BSC and PCU |
||
15 | |||
16 | h2. PDCH timeslot configuration |
||
17 | |||
18 | It seems that in OM2000 all TCH (/F, /H, PDCH) are configued with a Combination "8", and no differentiation is made |
||
19 | |||
20 | 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. |
||
21 | |||
22 | 2 | laforge | h2. GPRS RACH requests |
23 | |||
24 | 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. |
||
25 | |||
26 | h2. GPRS paging |
||
27 | |||
28 | 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. |
||
29 | |||
30 | |||
31 | |||
32 | 1 | laforge | h2. TRAU frames |