Project

General

Profile

Actions

Feature #5198

open

Support GPRS on Ericsson RBS

Added by pespin over 1 year ago. Updated 6 days ago.

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

80%

Spec Reference:


Files


Checklist

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

Related issues

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

Actions
Actions #1

Updated by laforge over 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 11 months ago

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

Updated by dexter 6 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 4 months 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 4 months ago

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

Actions #13

Updated by pespin 4 months 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 #14

Updated by dexter 4 months ago

  • % Done changed from 10 to 20

I now have some success in getting data from the PCU. There were problems in osmo-bsc that prevented proper forwarding of the Channel Required messages. This caused the MS to never properly receive the AGCH, so it never changed to PDCH. That was why MAC blocks were received at the PCU side. There were also missing bits in the l1 interface on the PCU side which prevented proper frame number counting as well. So the RFN / request reference sent on the AGCH was also always incorrect.

Now the CCU receives valid MAC blocks (correct CRC, GPRS parity correct, plausible RXLEV and RXQAL) but unfortunately the PCU cannot make sense of the received data:

Wed Oct 12 17:35:57 2022 <000f> trau/trau_sync.c:543 trau_sync(trau-sync)[0x55eff2f5b030]{FRAME_ALIGNED}: Received Event RX_BITS
Wed Oct 12 17:35:57 2022 <0001> ericsson-rbs/er_ccu_if.c:70 E1-I.460-RX: (line:0, ts:3, ss:0) receiving 320 TRAU frame bits from E1 subslot: 00000000000000001010110001000000100101011011100000000101000000111000010100000101111100101100101111111101110110000101111010100110101001101010011010100110101001101010011010100110101001101010011010100110101001101010011010100110101001101100111001010111111111111111111111111111111111111111111111111111111111111111111111111111...
===========> pseq=5150
===========> GOT: 00000000000000001010110001000000100101011011100000000101000000111000010100000101111100101100101111111101110110000101111010100110101001101010011010100110101001101010011010100110101001101010011010100110101001101010011010100110101001101100111001010111111111111111111111111111111111111111111111111111111111111111111111111111
==========> COMPUTED AFN UL: 2684329 37
==========> COMPUTED AFN DL: 2684322 30
==========> COMPUTED BLK UL: 8
==========> COMPUTED BLK DL: 7
 ccu_data_ind.tav=00
 ccu_data_ind.dbe=0
 ccu_data_ind.cs_hdr=1
 ccu_data_ind.gprs.rx_lev=10
 ccu_data_ind.gprs.est_acc_del_dev=0
 ccu_data_ind.u.gprs.block_qual=0
 ccu_data_ind.u.gprs.parity_ok=1
 ccu_data_ind.data=00a070a0be597fbb0bd4d4d4d4d4d4d4d4d4d4d4d4d4d40000000000000000000000000000000000...
========================================================================================
================================ INTRESTING RX ABOVE! ==================================
========================================================================================
Wed Oct 12 17:35:57 2022 <0005> pdch.cpp:960 PDCH(bts=0,trx=0,ts=4) Got RLC block, coding scheme: CS-1, length: 23 (23))
Wed Oct 12 17:35:57 2022 <0005> pdch.cpp:997 PDCH(bts=0,trx=0,ts=4)   UL data: 00 a0 70 a0 be 59 7f bb 0b d4 d4 d4 d4 d4 d4 d4 d4 d4 d4 d4 d4 d4 d4 
Wed Oct 12 17:35:57 2022 <0005> pdch.cpp:1014 PDCH(bts=0,trx=0,ts=4) Got CS-1 RLC block: R=0, SI=0, TFI=16, CPS=0, RSB=0, rc=184
Wed Oct 12 17:35:57 2022 <0005> pdch.cpp:1020 PDCH(bts=0,trx=0,ts=4) UL DATA unknown TFI=16
=========================> l1if_pdch_req(): ts=4, is_ptcch=0, fn=2684322, arfcn=875, block_nr=7, len=23
                           l1if_pdch_req(): data=47942b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b

The TFI is mostly 16, sometimes 24. Also the 4d filler pattern in the block above looks very suspicious. Shouldn't that be 2b instead. Are those inverted bits? d4 = 11010100 is the inverse of 2b = 00101011, but then the TFI still looks odd. This needs to be investigated. At least we can tell that the data must be correct as the CRC matches. Some more investigation is needed here.

Actions #15

Updated by keith 4 months ago

dexter wrote in #note-14:

the 4d filler pattern in the block above looks very suspicious. Shouldn't that be 2b instead. Are those inverted bits? d4 = 11010100 is the inverse of 2b = 00101011,

Interestingly, while it is the inverse, it is also the reverse order of the bits. I have no idea if such things are ever done in transmission protocols.

Actions #16

Updated by laforge 4 months ago

On Wed, Oct 12, 2022 at 04:15:27PM +0000, dexter wrote:

The TFI is mostly 16, sometimes 24. Also the 4d filler pattern in the block above looks very suspicious. Shouldn't that be 2b instead. Are those inverted bits? d4 = 11010100 is the inverse of 2b = 00101011, but then the TFI still looks odd. This needs to be investigated. At least we can tell that the data must be correct as the CRC matches. Some more investigation is needed here.

I would also have expected some bit-order related issue.

Actions #17

Updated by dexter 4 months ago

The hint with the bit ordering was actually very helpful. The bits were indeed in the wrong order. Now I can see plausible TFI, and even better (after fixing one more bug in the BSC), I now see IMSIs from my test phones arriving at the SGSN:

Thu Oct 13 18:36:37 2022 <0005> gprs_llc.c:1069 LLME(7e4c9f67/c0bfde96){ASSIGNED} LLGM Assign pre (c0bfde96 => ffffffff)
Thu Oct 13 18:36:37 2022 <0005> gprs_llc.c:1115 LLME(00000000/00000000){UNASSIGNED} LLGM Assign post (c0bfde96 => ffffffff)
Thu Oct 13 18:36:40 2022 <0000> gprs_gmm.c:359 MM(001010000000006/e8c002ac) <- GMM ATTACH REJECT: MS identity cannot be derived by the network
Thu Oct 13 18:36:40 2022 <0005> gprs_llc.c:1069 LLME(7bb923fe/e8c002ac){ASSIGNED} LLGM Assign pre (e8c002ac => ffffffff)
Thu Oct 13 18:36:40 2022 <0005> gprs_llc.c:1115 LLME(00000000/00000000){UNASSIGNED} LLGM Assign post (e8c002ac => ffffffff)
Thu Oct 13 18:36:40 2022 <0000> gprs_gmm.c:359 MM(001010000000003/d3242d33) <- GMM ATTACH REJECT: MS identity cannot be derived by the network
Thu Oct 13 18:36:40 2022 <0005> gprs_llc.c:1069 LLME(7c75740a/d3242d33){ASSIGNED} LLGM Assign pre (d3242d33 => ffffffff)
Thu Oct 13 18:36:40 2022 <0005> gprs_llc.c:1115 LLME(00000000/00000000){UNASSIGNED} LLGM Assign post (d3242d33 => ffffffff)
Actions #18

Updated by dexter 4 months ago

I had a lot of issues with the frame number alignment. One problem here is that the frame numbers the CCU reports via the SYNC indication are not the whole truth. There is also a latency that has to go into the calculation. The latency can be calculated by subtracting the local pseq value from the one the CCU reports. I initially assumed that this value does also have to be divided by 2 but that seems to be not true. What I find really confusing is that apparently the afn_ul is one block ahead of afn_dl. This is probably due to the wired format of afn_ul which always points towards the block end.

     * 1. The uplink related frame numbers sent by the ericsson CCU refer
     *    to the end of a block. This is compensated by subtracting three
     *    frames.
     * 2. The CCU downlink frame number runs one block past the uplink
     *    frame number. This needs to be compesated as well (+1).
     * 3. The difference between the local (PCU) and the returned (CCU)
     *    pseq counter value is the number of blocks that the PCU must
     *    shift its downlink alignment in order to compensate the link
     *    latency between PCU and CCU. */

So, when I compensate everything as I do it at the moment I can clearly see that the PCU starts reserving frame numbers once the RACH request is received. Then I can see that data is received at the first frame number the PCU has reserved. This leads me to the assumption that the frame number counting is now correct.

However, the PCU still has problems to pass data back and forth, leading to wired log output in the SGSN. I have attached the logs from osmo-bsc and osmo-pcu, as well as a trace with the llcgprs. One can see the ATTACH REQUESTs in the llcgprs. Then the SGSN sends an IDENTITY REQUEST but there seems to be no answer from the MS then. Eventually the SGSN rejects with ATTACH REJECT.

I was assuming that there may be blocks lost due to bit slips. What I currently do is looping back the timing alignment value (TAV) to the CCU. So whenever the CCU has a TAV set I set the same TAV in the next TRAU frame that is sent (the encoder then encodes a longer or shorter frame). In any case this seems not to change anything.

At the moment I am running out of ideas, hints where to look at next are very much appreciated. (see attached logs/traces, all branches are up to date)

Actions #19

Updated by pespin 4 months ago

Hi dexter , I see there's no gsmtap with the RLCMAC received at the PCU.
I suggest you enable it to have a clearer picture of what's going on between the MS and the PCU. See https://osmocom.org/issues/5198#note-13

Actions #20

Updated by keith 4 months ago

dexter wrote in #note-18:

One can see the ATTACH REQUESTs in the llcgprs. Then the SGSN sends an IDENTITY REQUEST but there seems to be no answer from the MS then. Eventually the SGSN rejects with ATTACH REJECT.

I wonder if it's worth mentioning that I happened to see this exact behaviour yesterday with an old Nokia 6070, that used to work, last time I would have used it, some years ago.
This is with osmo-bts-sysmo, with colo osmo-pcu at the BTS, nothing ericsson here.

Maybe we broke something for some phones in the SGSN?
Are you using only one test handset? Maybe test it against a known working setup, just to be sure?

Actions #21

Updated by dexter 4 months ago

I have checked the trace again. Yes, I messed it up, its was a wrong trace file. I have re-done the whole test now and attached an updated trace with gsmtap and gsmtap_log. The llcgprs now shows a different behavior I see very often. There is a ROUTING AREA UPDATE REQUEST and a XID out of nowhere. I believe the ATTACH REQUEST got lost somewhere and the next that the MS does is the the ROUTING ARE UPDATE REQUEST (and a XID). One thing I noticed while testing today was that I see the RACH request, then the FNs are reserved, but there is no answer. Then there is a RACH request again, FNs get reserved again and then I see an answer at the correct FN.

The handset I am using is a K800i and there are also some modems (I believe quectel) attached to the test rack. I will give it a try with another handset but I don't think that it will change much. Also I don't think that it can be a problem at the SGSN, there are missing/wired messages from the MS already in the llcgprs trace.

Actions #22

Updated by pespin 4 months ago

dexter looking at the trace.pcap, there seems to be something like 42-52 FN of delay between UL FN and DL FN scheduled by osmo-pcu. This is A LOT. Can the delay be tweaked somehow in the BTS?

Also, I see frame 9847, 9861 and 9876 the first UL blocks are transmitted by the MS, but they are FN 1043540, 1043549 and 1043557. That's 9 FNs between the first two, and 8 between the next two. I'd expect an offset of 4 there for consecutive data blocks (fixeria can say better here, maybe I'm wrong).

In frame 12075 the PCU polls the MS at N+13=1046625+13=1046638, and we can see the MS sending an UL CTRL ACK at that FN (frame 12158), so that seems correct.

I see lots of gsmtap_log messages like this:

9871    09:41:06.155173    Oct 20, 2022 11:41:06.155173000 CEST    127.0.0.1    32960    127.0.0.2    4729    GSMTAP    230    PDCH(bts=0,trx=0,ts=4) Expiring FN=1043557 but previous FN=1043553 is still reserved! 

This indicate smost probably that you are not ticking all FNs (informing the osmo-pcu from the BTS), hence osmo-pcu detects jumps in FN updates. You should check that.

I also see this one, which should be looked at:

9887    09:41:06.159335    Oct 20, 2022 11:41:06.159335000 CEST    127.0.0.1    54418    127.0.0.1    4729    GSMTAP    185    PCU Sends unknown paging request type 3f 

Do you have the code you are using in some public branch?

Actions #23

Updated by dexter 4 months ago

The 42-52 FN delay are the result of the difference between the local pseq counter and the remote value that is echoed via the CCU-SYNC-IND. The difference is around 11-12 blocks. I do not know how to reduce this. I also do not have much documentation. All I know is that the pseq counter is used to align the PCU in downlink. Since the MS responds at the expected point in time I think my assumptions around this are correct. Unfortunately I do not know how to reduce this offest.

I am only ticking the PCU with each block since the CCU sends one MAC block at a time. I thought that this was the correct way to do it. I use the functuon pcu_rx_block_time() for this.

I did not look at the paging yet. In theory the BSC should support it since it already has the pcu_sock interface in current master, however the PCU has seen a lot of changes since we last tried it so it is very likely that paging is broken.

The current code is at: pmaier/e1gprs in libosmo-abis, osmo-bsc, and osmo-pcu

Actions #24

Updated by laforge 4 months ago

I could imagine that the offset is sent via some om2000 attribute during bring up or as a ral is during pdch activation. Maybe check if there's any hard coded IE in there...

Actions #25

Updated by dexter 4 months ago

  • % Done changed from 20 to 30

I did more tests and experiments but I still have the problem I descried above.

I had a closer look at the hardcoded OML parameters now. There is indeed an FN offset that can be configured on a per TS. I have tried to change this setting to any value other than 0 but the BTS only accepts the parameter when it is set to the same value on all TS. Also it had no effect on the PSEQ counter difference between CCU and PCU.

I have also checked back the time alignment bits. Its indeed the case that the TAV value the BTS sends is indeed a request. So I think have correctly implemented the time alignment. I also check the sync in regular intervals. The synchronization is stable. What I find interesting though is that the CCU will not give me its PSEQ counter value when I passively ask for a CCU-SYNC-IND but I still get the frame numbers. So everything should be fine here as well.

Meanwhile I had a look at the unknown paging request type 3F. There is indeed something missing in the BSC. However, I still do not get why the PCU is paging just after it has sent the PDCH channel assignment via the AGCH. The MS by then should already be on the PDCH and not even see this paging request.

Actions #26

Updated by pespin 4 months ago

However, I still do not get why the PCU is paging just after it has sent the PDCH channel assignment via the AGCH. The MS by then should already be on the PDCH and not even see this paging request.

I think the "paging request" you are mentioning from the logs is most probably actually the "Immediate Assignment" sent PCU->BSC->BTS-[AGCH]->MS.

Actions #27

Updated by dexter 3 months ago

  • % Done changed from 30 to 40

I Have now integrated the last missing thing. There is this Ericsson specific immediate assignment where a paging group and a TLLI is prepended after the MAC block. I have now added that and now I get a pdp context. I can even ping the MS. It looks still a bit bumpy though but seems to work now. At least we have verified now that the TRAU frame implementation is correct.

Actions #28

Updated by keith 3 months ago

Nice Work!!

Actions #29

Updated by dexter 3 months ago

I have done another test today and recorded traces so everyone can have a look. It seems to work ok. The tests were done with a Sony Ericsson K800i. I am not sure if this is the best test phone anyways since I have the feeling that it gets confused by the consecutive restarts. To me it looks like if the phone was thinking that it still were attached so it directly sends a Routing Area Update Request. It should in fact begin with an Attach request and I also don't think that this behavior is due to lost MAC blocks. In any case, after a restart of the phone we can see the Attach request is going through without problems (at lest on llcgprs it seems to be fine). The K800i doesn't open a pdp context until something needs it, so I opened the browser to force a pdp context. Also that seems to work fine (the IP the phone tries to reach is unreachable). Then I sent a few pings from the core network side. I don't know if it is normal that the first few ICMP packets are lost. This is probably unusual since the phone has to be paged and TBF assignments have to take place, this all takes time of course.

In any case I still have the feeling that the PCU has to struggle a bit. However, it is difficult for me to say if this is normal or if there are real problems to it. In any case, I am very happy with the result so far.

Actions #30

Updated by keith 3 months ago

As regards phone sending RA Update, I see this ALL the time (see the error log I just posted on unrelated issue: #5725)

Actions #31

Updated by dexter 3 months ago

I had a closer look to the Time adjustment procedure. I am very sure now that what we currently do is correct. The TAV in the TRAU frames that are comming from the CCU are indeed a request. The TAV value in the TRAU frames that are sent from the PCU are an acknowledgement, so that the CCU knows that the timing adjustment was made. The subsequent frame is then delayed or advanced. This is a bit ambiguous but what they actually mean by this is that the T-Bits of the frame that carries the TAV value does the alignment by adding or removing T-Bits. This delays/advances the timing of the subsequent frame (naturally). I think there is nothing much do on the PCU side. We just execute the requested time alignment. The CCU may or may not manipulate the T-Bits on the frames it is sending. In any case, regardless if there are missing or added bits, the trau-sync will still lock on the alignment pattern of the frame. (I find it a bit surprising that the CCU originated T-Bits are not 4+4 but 2+2 - i am not even sure about the +2)

I am currently working on getting the synchronization procedure running on a 64K slot. I am still using the I.460 Mux but with OSMO_I460_RATE_64k since this would make switching between 64k and 16k easier. I would expect the Mux to be transparent in this configuration. In any case. I am currently not even getting a clean idle pattern. "101010001010100010101000101010001010100010101000101" looks a bit odd. The idle pattern should be "1010101010...." Probably I haven't found the correct IS settings yet.

Actions #32

Updated by dexter 3 months ago

I now managed to get proper 64K TRAU frames from the CCU. The concept of dTRU and sTRU that Ericsson has introduced is not immediately obvious. Early GPRS capable transceivers (TRU) were only supporting CS-1 and CS-2 over 16k subslots. Then dTRU (d=dual?) were introduced. Those TRUs have an additional set of 9 x 64K E1 timeslots to handle the higher data rates for EGPRS and CS-3/CS-4. One would think: They give each of the 8 possible PDCHs an extra 64K timeslot and the CCU is reachable on the 16k subslots and on the 64k at the same time. This is in fact not true. The old style interface seems only to exist due to compatibility reasons. When higher GPRS data rates should be used one would switch over to the new set of timeslots. The first timeslot of the 9 is RSL/OML, the rest is for traffic with the only difference that now 64k slots instead of 16k subslots are used.

To access the EGPRS capable part of the dTRU we need to change this:

is-connection-list add 4 512 12

to this:

is-connection-list add 4 712 36

osmo-bts seems to boot fine in this configuration since the signalling part hasn't changed. The PDCH is activated and I see the 64k sync indications on the correct time slot. This is ok for now. I can now write encoders/decoders for the TRAU frames. What makes me wonder though is what would happen to speech frames. Are they packed in some not yet known 64k TRAU frame format? Are they I.460 multiplexed but only the first subslot is used? I think there is also some research to be done here as well.

Actions #33

Updated by laforge 3 months ago

On Thu, Nov 03, 2022 at 05:02:10PM +0000, dexter wrote:

I now managed to get proper 64K TRAU frames from the CCU. The concept of dTRU and sTRU that Ericsson has
introduced is not immediately obvious. Early GPRS capable transceivers (TRU) were only supporting CS-1 and
CS-2 over 16k subslots. Then dTRU (d=dual?) were introduced. Those TRUs have an additional set of 9 x 64K E1
timeslots to handle the higher data rates for EGPRS and CS-3/CS-4.

One would think: They give each of the 8 possible PDCHs an extra 64K timeslot and the CCU is reachable on the 16k subslots and on the 64k at the same time. This is in fact not true.

I wouldn't have expected that. It's an either or choice.

The old style interface seems only to exist due to compatibility reasons.

Yes, I think it's for new BTS vs old BSC purposes.

What makes me wonder though is what would happen to speech frames. Are they packed in some not yet known 64k TRAU frame format? Are they I.460 multiplexed but only the first subslot is used? I think there is also some research to be done here as well.

that's indeed an interesting question. I have never seen any mention of 64k TRAU frames for voice, but will
have a look.

Actions #34

Updated by dexter 3 months ago

I have now encoders and decoders for the 64K SYNC indications. I am currently working on an encoder for the 64K DATA indications. Its almost done, but unfortunately the Ericsson CCU interface only tells me the header type instead of the exact MCS frame. This means I will have to look into the header and parse the CPS field to know which MCS is is used. This is important since the PCU expects the exact length. I have also already looked up the spec, the field is at a fixed position, so its not difficult to parse.

Actions #35

Updated by dexter 3 months ago

I am almost done with the 64K version of the decoders/encoders. For CS and the lower MCS they should be fine. At the moment I am struggling a bit with the support for MCS9. Ericsson did some hacks to cram an MCS9 block into a 64K TRAU frame. They not only introduced a dedicated TRAU frame format for MCS9, they are also stripping a few fields from the header (Spare, RSB and CPS). The values for those should be just constants but it the frame has to be mangled before it gets passed to the PCU. The other thing is that they use parts of the T0 sync bits for data. This is really problematic since it may upset our TRAU frame synchronizer. We probably will have to extend the synchroninizer FSM in a way so that it can be told to tolerate certain sync pattern deviations once it is locked.

So far I have tested sending 64K CS1 frames to the CCU and I see that the frames are getting accepted.

Actions #36

Updated by dexter 3 months ago

  • % Done changed from 40 to 60

I am currently reading the available documentation about access bursts. Apparantly four of them are mangled into one TRAU frame one after another. One Access burst item has the following fields:

Type 1:

CRC
Rxlev
Burst Qual
Frame Qual
Access Delay
Data

Type 2:

ABI (Access Burst Indicator)
Rxlev
Type
Access Delay
Data

I am not entirely sure yet if the CCU sends those Access Burst items by itself or if the PCU has to request them. There is a flag in the downlink DATA indication that specifies the demodulation to apply on RX data. One of the possible options is AB. When I am setting the flag, then the CCU sends me data indication with access bursts. They are probably just noise, but they clearly show the field layout and the padding bits are also plausible.

The big question is now what to do with that access burst data. The access bursts from the other BTS models seem to end up in pcu_l1_if.cpp:pcu_rx_rach_ind_ptcch(). The contained data also seems not to be of much interest for the PCU. At the moment I have enough info to implement a decoder but I am not yet entirely sure how to process the received data.

The 64K CS 1-4 and MCS 1-9 decoder/encoder is now done. Unfortunately the unit tests still lack some coverage since I do only have test vectors for CS1 and CS2 yet. I am thinking about making up some test vectors for the other coding schemes. In any case I have carefully counted out the bit offsets and length and double checked everything, but that of course is no grantee that nothing slipped through.

Actions #37

Updated by dexter 3 months ago

(I have now rebased and re-tested everything. I also managed to get CS2 working for 16K subslots this also means that we now have trustworthy test vectors for 16K CS1 and CS2.)

Actions #38

Updated by dexter 3 months ago

I have integrated the access bursts so far that the data (4 items) are copied to the data member of the indication struct. We can overlay a packed struct to access the fields.

Actions #39

Updated by pespin 3 months ago

dexter wrote in #note-38:

I have integrated the access bursts so far that the data (4 items) are copied to the data member of the indication struct. We can overlay a packed struct to access the fields.

I already wrote this in SOB a few days ago when I saw the last update, but I put it here to make sure you are aware:
We are currently not using nor supporting the CTRL_ACK mode which uses 4 access burst, we instead announce in SI and expect to receive an RLCMAC PKT_CTRL_ACK message from the MS.
That means as far as I'm aware osmo-bts-trx is not yet capable to pass those 4 access bursts together to osmo-pcu in the usual case where osmo-pcu is attached to osmo-bts.
Furthermore, I don't think as of today osmo-pcu supports handling those 4 access burst CTRL_ACKs, there's no code path for those (yet). Since we support the other mode, I'd say it's not high prio having those implemented.

Actions #40

Updated by dexter 3 months ago

Hello Pau,

Thanks for the info. When I get this right we do not need the access bursts in uplink at all (not even for timing info?). I have now implemented the decoder since it was not much effort anyway. So, that basically means that as far as TRAU frame encoding/decoding is concerned we are feature complete.

best regards.
Philipp

Actions #41

Updated by pespin 3 months ago

dexter I'm not sure we are even currently implementing properly the RACH.req in osmo-pcu for PTCCH, fixeria may be able to provide more info on that.
Support for that in PTCCH is of course welcome since we should implement/fix it in osmo-pcu upper layers at some point.

Actions #42

Updated by fixeria 3 months ago

pespin wrote in #note-41:

I'm not sure we are even currently implementing properly the RACH.req in osmo-pcu for PTCCH, fixeria may be able to provide more info on that.

Generally PTCCH support is there:

  • a) we do handle PTCCH/UL (Access Bursts) and update per-PDCH PTCCH state (TA values for all 16 TAIs),
  • b) we do generate PTCCH/DL messages based on per-PDCH PTCCH state and send blocks (Normal Bursts) to the BTS.

What's missing is the TAI (Timing Advance Index) assignment during TBF allocation. TAI basically tell the UEs when (i.e. on which TDMA Fn) to send Access Bursts on PTCCH/UL, and which Timing Advance value to apply from PTCCH/DL messages. The state of this feature is tracked in #1545 (Stalled). It's currently assigned to me, but I guess pespin is a better fit for implementing the missing TAI assignment logic.

Actions #43

Updated by fixeria 3 months ago

TBH, I am still not sure if dexter is referring to PDTCH/PRACH or PTCCH. You can distinguish them by looking at TDMA Fn and the PDCH multiframe layout (https://cgit.osmocom.org/osmocom-bb/tree/src/host/trxcon/src/sched_mframe.c#n1812).

Actions #44

Updated by dexter 3 months ago

  • Checklist item libosmo-abis: encode and decode GPRS/EGPRS TRAU frames in E1 slots/subslots set to Done
Actions #45

Updated by dexter about 1 month ago

I am currently working on getting the already existing patches merged. One missing thing in the pcu_sock communication is that we cannot activate PDCHs via pcu_sock commands at the moment. The PDCH is activated once on BSC startup and stays activated. I did a longer test with 16kbps today leaving the MS in idle for some time and then pinging it occasionally. This ran stable, no crashes or sync losses.

Actions #46

Updated by dexter 24 days ago

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

At the moment I am still working on the PCU controlled PDCH activation. I have also updated the checklist above to differentiate between 16 and 32 kbps since those are two different implementations and many of the 16kbps parts ware finished while some of the 32kbps parts are not yet finished.

Actions #47

Updated by dexter 24 days ago

It also may be noteworthy that an old bug in the frame number calculation of the channel request got fixed. In some cases the resulting frame number was just wrong. It might be imagination but I have the feeling that the packet channel request is more reliable now.

Actions #48

Updated by dexter 10 days ago

I am currently hanging a bit at the dynamic timeslot implementation. From what I can see the BSC seems not to handle an lchan for the PDCH. The TS FSM goes from NOT_INITIALIZED=>UNUSED=>WAIT_PDCH_ACT=>PDCH when we use TCH/F_TCH/H_SDCCH8_PDCH. When we use PDCH nothing happens. This is makes sense since a static PDCH is handled entirely in the BTS/PCU. The RBS seems to have no static PDCH is always dynamic channel that can be/must be configured be the BSC. That also explains why PDCH is not applicable here.

What I don't understand yet is how exactly the PCU controls the PDCH activation. The BSC reports via PCU_SOCK what TS are available for PDCH. Then the PCU selects one of those and tells the BSC to activate it. But apparantly that is not what happens. The BSC is activating the PDCH right away without caring much about what the PCU does. Also there seems to be no feedback whether the activation was successful or not. I think I will have to set everything up with osmoBTS and then monitor what happens in the FSMs and on the PCU socket.

Actions #49

Updated by laforge 10 days ago

stupid question: but did you check the available documentation? The osmocom specific
dynamic PDCH should be documented in our osmocom abis manual, and well as

also, the timeslot.{msc,png} in osmo-bsc/doc states rather explicitly your observations
regarding no activation of fixed vs. activation of dynamic PDCH.

On Mon, Jan 30, 2023 at 10:09:42AM +0000, dexter wrote:

The RBS seems to have no static PDCH is always dynamic channel that can be/must be configured be the BSC. That also explains why PDCH is not applicable here.

yes, and we should have code that prints ERROR messages if anyone ever tries to use a static PDCH on an
Ericsson RBS.

What I don't understand yet is how exactly the PCU controls the PDCH activation.

why would the PCU control it? activation and deactivation of lchan's is the job of the BSC.

The BSC is activating the PDCH right away without caring much about what the PCU does.

just like in a good old "static PDCH" case: The BSC configures the TS/lchan as PDCH and tells the
PCU that it can use it. Whethere or not the PCU exists or actually starts using it is up to the PCU.

Also there seems to be no feedback whether the activation was successful or not.

what kind of activation are you referring to? Are you saying the BSC does
not wait for the PDCH ACTIVATE ACK on RSL before telling the PCU that a
given PDCH is active/available (via INFO.ind, AFAIR)? If that's the
case, that would be a serious bug.

Actions #50

Updated by dexter 7 days ago

Just to provide an update I have attached a trace that is made with the current state. It shows the MS negotiating with the network, and some time later a ping to the assigned IP address 192.168.0.5. Everything seems to work reliable, however I am asking myself why it takes a few seconds until the MS responds to the paging.

Actions #51

Updated by pespin 7 days ago

I am asking myself why it takes a few seconds until the MS responds to the paging.

Which one exactly? can you reference a pcap frame number?

The main problem I see there which may be causing issues is that you have something like 72223 - 72171 = 52 FNs (see frame nr 3064 and3065 in the ethernet.pcap) of difference between UL and DL, which is really too much. This should never be more than 13 FNs ideally.

Actions #52

Updated by laforge 7 days ago

  • % Done changed from 60 to 80
Actions #53

Updated by dexter 6 days ago

The paging I am refering to is in trace_e1.pcap at frame 3224. There is only one MS in the system.

Actions #54

Updated by pespin 6 days ago

Which paging? I see none?

3224    16:45:19.994774    Feb  2, 2023 17:45:19.994774000 CET    127.0.0.1    41725    127.0.0.3    4729    GSM RLC/MAC    83    GPRS DL DATA: CS1 TFI=1 BSN=10 USF=0 Len=19
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)