Project

General

Profile

Actions

Feature #5198

open

Support GPRS on Ericsson RBS

Added by pespin about 1 year ago. Updated 7 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Start date:
07/13/2021
Due date:
% Done:

10%

Spec Reference:


Checklist

  • libosmo-abis: encode and decode GPRS/EGPRS TRAU frames in E1 slots/subslots
  • libosmo-abis: SYNC / timing loop for GPRS/EGPRS TRAU frames
  • osmo-bsc: activation of PDCH via OM2000/RSL from BSC side
  • osmo-pcu support for opening e1 timeslots [like bsc, mgw]
  • osmo-pcu using GPRS/EGPRS TRAU frame decoders from above
  • osmo-pcu / osmo-bsc pcu socket interaction (paging, ...)
  • test everything end-to-end with DUG20

Related issues

Related to OsmoPCU - Feature #1823: Ericsson PCU TRAU frame encoding/decodingStalled10/15/2016

Actions
Actions #1

Updated by laforge about 1 year ago

  • Checklist item libosmo-abis: encode and decode GPRS/EGPRS TRAU frames in E1 slots/subslots added
  • Checklist item libosmo-abis: SYNC / timing loop for GPRS/EGPRS TRAU frames added
  • Checklist item osmo-bsc: activation of PDCH via OM2000/RSL from BSC side added
  • Checklist item osmo-pcu support for opening e1 timeslots [like bsc, mgw] added
  • Checklist item osmo-pcu using GPRS/EGPRS TRAU frame decoders from above added
  • Checklist item osmo-pcu / osmo-bsc pcu socket interaction (paging, ...) added
  • Checklist item test everything end-to-end with DUG20 added

a more easily digestible description:

  • GPRS/EGPRS is fully supported within Osmocom when using non-Ericsson BTS
  • E1 based BTS have the CCU in the BTS and the PCU co-located at the BSC
  • RLC/MAC blocks are transferred over E1 sub-slots (16k, GPRS) or slots (64k, EDGE)
  • Ericsson supports three different data formats for back-haul:
    • classic "channelized" Abis with 64k/16k slots/sub-slots as we implement it in osmo-bsc and osmo-mgw
    • PacketAbis over TDM: E1 line is unchannelized (31 concatenated timeslots) with HDLC inside, that ~ 2Mbps superchannel is then used with some LAPD-style protocol to transmit OM2000, RSL, voice frames and GPRS RLC/MAC blocks
    • PacketAbis over IP: Same as above but encapsulated in a slightly modified dialect of L2TP. This is what the Ericsson SIU-02 or TCU speak; they convert from PacketAbis/TDM to PacketAbis/IP
  • Osmocom has implemented GPRS-only support for PacketAbis/IP in osmo-el2tpd, tested with RBS2111 some years ago. As part of that, osmo-bsc received a PCU socket interface

For this ticket, we want to support "classic, channelized E1", so the current CS setup consisting of (DUG20, icE1usb, osmo-e1d, osmo-bsc, osmo-mgw) can be extended with PS services by osmo-pcu. I'm adding chekc-list items.

Actions #2

Updated by laforge 7 months ago

  • Related to Feature #1823: Ericsson PCU TRAU frame encoding/decoding added
Actions #3

Updated by dexter about 1 month ago

  • Status changed from New to In Progress
  • Assignee set to dexter

Currently in progress: libosmo-abis: encode and decode GPRS/EGPRS TRAU frames in E1 slots/subslots

I have some experimental code now that sends 16 PCU SYNC indications to the CCU. Unfortunately I do not get any response from the CCU. I would expect the CCU to respond with a PCU SYNC indication as well. I will clean up everything and try again. So far I didn't set the unused data bits to 1, this could be a reason why the CCU ignores the frames.

Actions #4

Updated by dexter about 1 month ago

I now get CCU-SYNC-IND indications from the CCU now, when I send PCU-SYNC-IND to the CCU I can see that it synchronizes (with a delta of 13) to the the frame number in the PCU-SYNC-IND messages. This means the that the SYNC indications I send are understood by the CCU. Unfortunately the channel does not stay open for very long. My best guess here is that the CCU expects to see CS-1 or CS-2 frames after a while.

I have implemented some code to generate PCU-DATA-IND indications. When I send those to the CCU the channel still closes but I see responses that seem to be CCU-DATA-IND frames. Unfortunately the sync gets lost since the synchronization pattern is different for DATA indications but C-Bits and the parity bits of the C and E bits match. I am not done with the decoder yet. Also the synchronizer in libosmo-abis needs to be extended to understand the different framing.

What still seems to be unknown is the CRC polynom of the CRC used in the TRAU frames. CS-2 has no CRC since the 320 bits barely fit the CS-2 frame but CS-1 is CRC protected. The CRC is not air interface related. It just to make sure the frame correctly arrives at the CCU.

Actions #5

Updated by laforge about 1 month ago

On Mon, Aug 29, 2022 at 08:20:47PM +0000, dexter wrote:

What still seems to be unknown is the CRC polynom of the CRC used in the TRAU frames. CS-2 has no CRC since the 320 bits barely fit the CS-2 frame but CS-1 is CRC protected. The CRC is not air interface related. It just to make sure the frame correctly arrives at the CCU.

I guess what we can do is to wait for CCU-DATA.ind with CS1 uplink frames, and then see which common 16bit
CRC (e.g. CCITT CRC16) matches the bits?

Switching to 64kBps slots is also not helping, as the {CCU,PCU}-DATA.ind for 64k also have CRC in case of a
CS1 frame.

Actions #6

Updated by dexter about 1 month ago

  • % Done changed from 0 to 10

I managed to get the CCU in a state where it continuously accepts data indications and responds with data indications. In that state the channel stays open. I also managed to verify the CRC in the CS1 blocks that are coming back from the PCU. The responses are still out of sync, but clearly visible. I also extended the encoder so that it can encode CS1 blocks with valid CRC.

The TRAU frame encoder/decoder still needs some cleanup. Also the Access-Burst decoding is still missing. Will do that next.

Actions #7

Updated by laforge about 1 month ago

On Wed, Aug 31, 2022 at 04:35:31PM +0000, dexter wrote:

I managed to get the CCU in a state where it continuously accepts data indications and responds with data indications. In that state the channel stays open. [...]

excellent news!

The TRAU frame encoder/decoder still needs some cleanup. Also the Access-Burst decoding is still missing. Will do that next.

Access Burst decoding is only needed for PTCCH / timing advance loop much later. I would suggest to focus on getting the CS1 TRAU frames working robus in both ways and then use that to get the full chain working, i.e. signaling + user data on a CS1-constrained OsmoPCU with Ericsson RBS and some random MS.

Once that works, you can move to handling of AB and finally CS2..4 as
well as later MCS1..9

Actions #8

Updated by dexter about 1 month ago

Ok, I thought the access burst would be a mandatory thing. Then we do that later. I have now moved the code to libosmo-abis and also added a synchronization pattern. The pattern that is defined for the data indications seems to be enough. It now syncs fine on both data and sync indications.

Actions #9

Updated by dexter 12 days ago

I am currently adding the TRAU frame handling to osmo-pcu. The sync procedure works fine so far. I can get frame numbers from the CCU and once in sync the frame number computation can continue internally until the next sync indication arrives.

There are still some open questions. Judging by the frame numbers I get via the sync indications it seems that there is no PTCCH. My best guess here is that the BTS is generating it internally. This would also make sense since the TRAU frames have TAV (timing advance) flags. What also is not exactly clear to me is why there is a separate FN for uplink and downlink. The FN for downlink points to the beginning of a block while the FN for uplink seems to point to the end of a block. However the downlink FN makes sense and increments as one would expect it.


T = Single traffic channel burst
D = PDTCH
P = PTCCH
                                                                                                    1
          1         2         3         4         5         6         7         8         9         0
01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
            v            v            v            v            v            v            v            v

interval start                                                                              interval end
|------------------------------------------------------------------------------------------------------|
TTTTTTTTTTTTPTTTTTTTTTTTTITTTTTTTTTTTTPTTTTTTTTTTTTITTTTTTTTTTTTPTTTTTTTTTTTTITTTTTTTTTTTTPTTTTTTTTTTTTI
D   D   D   PD   D   D    D   D   D    D   D   D    D   D   D    D   D   D    D   D   D    D   D   D    
0   1   2    3   4   5    6   7   8    9   10  11   0   1   2    3   4   5    6   7   8    9   10  11 <-- blk nr.

So far I have everything I need to call pcu_rx_rts_req_pdtch(). To my suprise the channel now stays open without sending data indications. Maybe I made a mistake in my hacks at the beginning.

Unfortunately the protocol that is spoken at the pcu_sock has evolved a bit. The BSC seems to lack some messages here and there, so that needs to be updated as well.

Actions #10

Updated by pespin 12 days ago

dexter do you have your osmo-pcu WIP in some branch?

AFAIU having different FNs for DL and UL makes totally sense and we also do that usually in osmo-bts/osmo-pcu AFAIU, since you want to prepare DL frames with enough time before they have to be scheduled in the radio interface.
This is actually implemented in osmo-bts towards osmo-pcu by means of "osmotrx rts-advance <0-30>", have a look at osmo-bts User Manual.

Actions #11

Updated by dexter 7 days ago

Thanks for your input pespin I was just wondering. At the DL FN is indeed a little behind the UL FN, so it makes sense for now. I am using the DL FN to request DL blocks from the PCU. The blocks are encoded and the CCU accepts them. I have two test mobiles next to the BTS. I see the packat channel requests on the BSC side. I also see activity on the PCU side. My expectation was to see at least some good blocks comming back from the CCU when the MS tries to respond on the PDCH but all I see at the moment is noise.

I also noticed that the assigned TS look very unhealthy. That may be due to the fact that I am currently applying a hack to enable the PDCH. The PCU presumably now operates on partially uninitialized data, so this needs fixing before trying again.

Wed Sep 28 17:23:50 2022 <0001> pcu_l1_if.cpp:624 RACH request received: sapi=1 qta=0, ra=0x7b, fn=37691, cur_fn=-1, is_11bit=0
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:744 Race condition between rfn (37691) and m_cur_fn (4294967295) detected: rfn belongs to the previous modulus 42432 cycle, wrapping...
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:748 Cornercase detected: wrapping crosses 2715648 border
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:744 Race condition between rfn (37691) and m_cur_fn (4294967295) detected: rfn belongs to the previous modulus 42432 cycle, wrapping...
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:748 Cornercase detected: wrapping crosses 2715648 border
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:928 MS requests Uplink resource on CCCH/RACH: ra=0x7b (8 bit) Fn=2710651 qta=0
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:945 MS requests single TS uplink transmission (one phase packet access)
Wed Sep 28 17:23:50 2022 <0002> gprs_ms.c:111 Creating MS object, TLLI = 0xffffffff
Wed Sep 28 17:23:50 2022 <000f> rate_ctr.c:84 validating counter group 0x55cc2d984060(pcu:ms) with 1 counters
Wed Sep 28 17:23:50 2022 <0008> tbf_ul.cpp:114 MS(TLLI=0xffffffff, IMSI=, TA=220, 0/0,) ********** UL-TBF starts here **********
Wed Sep 28 17:23:50 2022 <0008> tbf_ul.cpp:115 MS(TLLI=0xffffffff, IMSI=, TA=220, 0/0,) Allocating UL TBF
Wed Sep 28 17:23:50 2022 <0008> fsm.c:456 TBF[0x55cc2eb03270]{NEW}: Allocated
Wed Sep 28 17:23:50 2022 <0008> fsm.c:456 UL_ASS_TBF[0x55cc2eb03420]{NONE}: Allocated
Wed Sep 28 17:23:50 2022 <0008> fsm.c:456 DL_ASS_TBF[0x55cc2eb035e0]{NONE}: Allocated
Wed Sep 28 17:23:50 2022 <000a> fsm.c:456 UL_ACK_TBF[0x55cc2eb04770]{NONE}: Allocated
Wed Sep 28 17:23:50 2022 <0002> gprs_rlcmac_ts_alloc.cpp:874 [UL] algo B <single> (suggested TRX: -1): Alloc start
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:661 Found first unallocated TRX=0 TFI=1
Wed Sep 28 17:23:50 2022 <0002> gprs_rlcmac_ts_alloc.cpp:548 - Possible DL/UL slots: (TS=0)"CCCCCCCC"(TS=7)
Wed Sep 28 17:23:50 2022 <0002> mslot_class.c:196 Rx=4 Tx=4 Sum Rx+Tx=5, Tta=2 Ttb=1, Tra=2 Trb=1, Type=1
Selected UL slots: (TS=0)".u....U."(TS=7), single
Wed Sep 28 17:23:50 2022 <0002> gprs_rlcmac_ts_alloc.cpp:936 [UL] algo B <single> (suggested TRX: -1): using single slot at TS 6
Wed Sep 28 17:23:50 2022 <0002> gprs_rlcmac_ts_alloc.cpp:799 - Reserved DL/UL slots: (TS=0)"DDDD..C."(TS=7)
Wed Sep 28 17:23:50 2022 <0002> gprs_rlcmac_ts_alloc.cpp:821 - Assigning UL TS 6
Wed Sep 28 17:23:50 2022 <0002> pdch.cpp:1172 PDCH(bts=0,trx=0,ts=6) Attaching TBF(TFI=1 TLLI=0xffffffff DIR=UL STATE=NEW), 1 TBFs, USFs = 01, TFIs = 00000002.
Wed Sep 28 17:23:50 2022 <0008> tbf.cpp:341 TBF(TFI=1 TLLI=0xffffffff DIR=UL STATE=NEW) Setting Control TS 6
Wed Sep 28 17:23:50 2022 <0008> tbf.cpp:676 TBF(TFI=1 TLLI=0xffffffff DIR=UL STATE=NEW) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
Wed Sep 28 17:23:50 2022 <000f> rate_ctr.c:84 validating counter group 0x55cc2d9843c0(pcu:tbf) with 1 counters
Wed Sep 28 17:23:50 2022 <0002> gprs_ms.c:291 MS(TLLI=0xffffffff, IMSI=, TA=220, 0/0,) Attaching UL TBF: TBF(TFI=1 TLLI=0xffffffff DIR=UL STATE=NEW)
Wed Sep 28 17:23:50 2022 <000f> rate_ctr.c:84 validating counter group 0x55cc2d9845c0(tbf:egprs) with 9 counters
Wed Sep 28 17:23:50 2022 <000f> rate_ctr.c:84 validating counter group 0x55cc2d9845a0(tbf:gprs) with 4 counters
Wed Sep 28 17:23:50 2022 <0008> tbf_ul.cpp:185 TBF(UL-TFI_1)[0x55cc2eb03270]{NEW}: Received Event ASSIGN_ADD_CCCH
Wed Sep 28 17:23:50 2022 <0008> tbf_fsm.c:85 TBF(TFI=1 TLLI=0xffffffff DIR=UL STATE=NEW) set ass. type CCCH [prev CCCH:0, PACCH:0]
Wed Sep 28 17:23:50 2022 <0008> tbf_fsm.c:103 TBF(UL-TFI_1)[0x55cc2eb03270]{NEW}: state_chg to FLOW
Wed Sep 28 17:23:50 2022 <0008> tbf_ul.cpp:314 TBF(TFI=1 TLLI=0xffffffff DIR=UL STATE=FLOW) starting timer T3141 [Contention resolution (UL-TBF, CCCH)] with 10 sec. 0 microsec, cur_fn=-1
Wed Sep 28 17:23:50 2022 <0002> gprs_ms.c:535 Modifying MS object, TLLI = 0xffffffff, TA 220 -> 0
Wed Sep 28 17:23:50 2022 <0002> bts.cpp:991 Tx Immediate Assignment on AGCH: TRX=0 (ARFCN 875) TS=6 TA=0 TSC=0 TFI=1 USF=0
Wed Sep 28 17:23:50 2022 <0001> pcu_l1_if.cpp:197 (bts=0,trx=0,ts=0) FN=0 Sending data request: sapi=2 arfcn=0 cur_fn=-1 block=0 data=2d 06 3f 10 0e 03 6b 7b e0 35 00 00 c8 40 70 0b 2b 2b 2b 2b 2b 2b 2b 
Wed Sep 28 17:23:50 2022 <0014> input/dahdi.c:452 E1TS(0:3) RAW CHAN RX: d5 d5 15 15 15 15 95 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 15 15 15 15 15 15 15 15 95 95 d5 95 d5 15 55 d5 15 15 15 55 95 d5 d5 55 15 15 15 95 d5 95 15 

At the moment I have no SGSN/GGSN running. I have compared the behavior to osmo-bts-trx with a similar configuration. There I see activity from the MS and the log also presents correct TS numbers. My best guess at the moment is that the MS does not see an USF and never responds due to that.

I have pushed all code (osmo-bsc, osmo-pcu, libosmo-abis) to branches named pmaier/e1gprs

(btw: I am getting a lot of Access Burst blocks, but the contents appear to be noise.)

Actions #12

Updated by dexter 7 days ago

Note: the one and only PDCH is on GSM TS 4

Actions #13

Updated by pespin 7 days ago

Hi dexter ,

First of all, those FN jumps at the start of the log doesn't look really good to me.

Second, the assignment of the single PDCH slot for the MS to transmit is done through AGCH. IIUC you have osmo-pcu attached through PCUIF to osmo-bsc, so the "Immediate Assignment on AGCH" you see (data request) is perhaps expected to go to osmo-bsc through PCUIF and it should transmit it through RSL to the BTS? or there's no such RSL connection between osmo-bsc and your BTS? I'm saying because the assignment since its over AGCH, it's for TS0 and not for any PDCH TS you have configured, so it may have to follow a specific path when speaking to your BTS.

In summary, what you see is the MS doing a RACH request requesting a single PDCH slot to transmit on an UL PDCH slot. the BSS will provide such a single Ul slot using an Immediate Assignment in AGCH. The MS will then use this single UL slot it received to send a Packet Resource Request over PDCH TS (TS6 in this case) providing with info about its capabilities to the BSS, and the BSS will allocate a multislot for it to transmit on the UL.

You may want to give a try with a TEMS phone in order to find out whether the Immediate Assignment is received by the phone (or transmitted at all by your BTS).

In the future you may want to provide a pcap file with gsmtap_log and gsmtap to see the rlcmac blocks sent and recieved. I personally use this under "pcu" node in osmo-pcu.cfg:

 gsmtap-remote-host 192.168.30.1
 gsmtap-category dl-unknown
 gsmtap-category dl-ctrl
 gsmtap-category dl-data-gprs
 gsmtap-category dl-data-egprs
 gsmtap-category dl-agch
 gsmtap-category dl-pch
 gsmtap-category ul-unknown
 gsmtap-category ul-ctrl
 gsmtap-category ul-data-gprs
 gsmtap-category ul-data-egprs
 gsmtap-category ul-rach

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)