OsmocomBB

Initial l1gprs implementation can be found here:

https://cgit.osmocom.org/osmocom-bb/log/?h=fixeria/trxcon_gprs
https://cgit.osmocom.org/osmocom-bb/commit/?h=fixeria/trxcon_gprs&id=f74895cb89b4bfe4608262b66c57c3d94c408487

Currently it simply decodes Downlink RLC/MAC signalling blocks (using libosmo-gprs-rlcmac and prints them.

Here is the l1gprs_test application, which can be used for running TTCN-3 tests specifically against the RLC/MAC layer:

https://cgit.osmocom.org/osmocom-bb/commit/?h=fixeria/trxcon_gprs&id=5f03b0710b8d221d1708e596b9bf0af16ae6a689

The key idea is to allow attaching directly to the RLC/MAC layer, without the need to run a chain of fake_trx.py and osmo-bts-trx. This is similar to what we do in the ttcn3-pcu-test (attaching directly over the PCUIF), however instead of being the MS side the testsuite will be acting as the PCU. For the lower l1gprs_test/ttcn3 communication (towards the PHY) I propose to (re)use the L1CTL server and protocol, so that we can simply use the existing L1CTL records/templates: DATA.req and DATA.ind would carry Uplink and Downlink RLC/MAC blocks, respectively. For the upper communication (towards the LLC layer) we will likely need to extend the L1CTL protocol anyway.

Just to clarify: I have been working on the initial RLC/MAC sub-layer for trxcon (the libl1gprs) while Eric was absent. Somehow I overlooked this ticket, so it remained untouched until now. Sharing what have been done so far. I was assigned to work on #3400, plus will be following up on #5599. Once I am done with these tickets, I would like to get back here and continue working on the libl1gprs and the corresponding TTCN-3 tests. It does not mean I am willing to prevent anyone else from working on this ticket; we can work together as there's plenty of things to do here. Just indicating my preferences.

Quick status update:

I submitted Work-in-Progress GRR layer implementation to Gerrit:

https://gerrit.osmocom.org/c/osmocom-bb/+/30743 trxcon: add initial GPRS L1 implementation - libl1gprs.la [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/30744 trxcon: call trxcon_set_log_cfg() from trxcon_main.c [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/30745 trxcon: add (optional) l1gprs_test binary for TTCN-3 [NEW]

I also submitted a TTCN-3 testsuite skeleton for the GRR layer:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29816 gprs-modem: initial testsuite skeleton for GPRS modem [WIP]

as well as some improvements and patches adding send templates for L1CTL PDUs:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30737 library/L1CTL_Types: eliminate warning about missing 'h0h1' field [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30738 library/L1CTL_Types: add send template for L1CTL_DATA_IND [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30739 library/L1CTL_PortType: allow sending L1ctlDlMessage via L1CTL_PT [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30740 library: move tr_PTCCHDownlinkMsg to the proper module [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30741 library/RLCMAC_Templates: add ts_PTCCHDownlinkMsg [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30742 library/RLCMAC_Templates: add ts_RLCMAC_DL_DUMMY_CTRL [NEW]

At this stage I am able to send some Downlink RLC/MAC signalling messages and see them parsed by the GRR layer:

20221219195204577 DL1C NOTICE L1CTL server got a new connection (id=0) (l1ctl_server.c:171)
20221219195204577 DGRR NOTICE l1gprs[0x0x55b1d3eea160]: Resetting GRR state (l1gprs_test.c:82)
20221219195204656 DGRR DEBUG l1gprs[0x0x55b1d3eea160]: (PDCH-7) Rx PDTCH/D block (fn=1337, len=23): 47 94 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b  (gprs.c:136)
20221219195204671 DLCSN1 INFO osmo_csn1_stream_decode (type: Pkt DL Dummy Ctrl Block (37): MESSAGE_TYPE = 37 | PAGE_MODE = 0 | Exist_PERSISTENCE_LEVEL = 0 | Padding = 0|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43| (ts_44_060.c:4796)
20221219195204724 DGRR DEBUG l1gprs[0x0x55b1d3eea160]: (PDCH-7) Rx PDTCH/D block (fn=1337, len=23): 47 94 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b  (gprs.c:136)
20221219195204724 DLCSN1 INFO osmo_csn1_stream_decode (type: Pkt DL Dummy Ctrl Block (37): MESSAGE_TYPE = 37 | PAGE_MODE = 0 | Exist_PERSISTENCE_LEVEL = 0 | Padding = 0|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43| (ts_44_060.c:4796)
20221219195204724 DGRR DEBUG l1gprs[0x0x55b1d3eea160]: (PDCH-7) Rx PDTCH/D block (fn=1337, len=23): 47 94 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b  (gprs.c:136)
20221219195204724 DLCSN1 INFO osmo_csn1_stream_decode (type: Pkt DL Dummy Ctrl Block (37): MESSAGE_TYPE = 37 | PAGE_MODE = 0 | Exist_PERSISTENCE_LEVEL = 0 | Padding = 0|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43| (ts_44_060.c:4796)
20221219195204724 DGRR DEBUG l1gprs[0x0x55b1d3eea160]: (PDCH-7) Rx PTCCH/D block (fn=1337, len=23): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b 2b 2b  (gprs.c:164)
20221219195204724 DL1D NOTICE l1c[0x55b1d3eea060]: L1CTL connection error: read() failed (rc=0): Success (l1ctl_server.c:55)
20221219195204724 DL1C NOTICE l1c[0x55b1d3eea060]: Closing L1CTL connection (l1ctl_server.c:206)

Now I am implementing the TBF FSM (looking at the one in osmo-pcu.git as the reference).

I submitted a few patches for libosmo-gprs-rlcmac implementing the missing bits for decoding the IA Rest Octets IE:

https://gerrit.osmocom.org/c/libosmo-gprs/+/30797 rlcmac: add decoder and test vectors for IA Rest Octets [NEW]
https://gerrit.osmocom.org/c/libosmo-gprs/+/30798 rlcmac: fix coding of EGPRS Packet Uplink Assignment in IA RestOctets [NEW]
https://gerrit.osmocom.org/c/libosmo-gprs/+/30799 rlcmac: rename s/IA_EGPRS_00_t/IA_EGPRS_PktUlAss_t/ [NEW]
https://gerrit.osmocom.org/c/libosmo-gprs/+/30800 rlcmac: implement the missing IA_MultiBlock_PktDlAss_t [NEW]

This is needed for Uplink and Downlink TBF establishment via AGCH.

Quick status update:

Some time ago pespin merged the modem application skeleton:

https://gerrit.osmocom.org/c/osmocom-bb/+/30260 host/layer23: Add modem app

I reworked this skeleton into a layer23 app, and implemented passive decoding of SI{3,4,13} and IA Rest Octets:

https://gerrit.osmocom.org/c/osmocom-bb/+/30812 layer23/sysinfo: implement decoding of SI13 Rest Octets
https://gerrit.osmocom.org/c/osmocom-bb/+/30870 modem: passive decoding of SI{3,4,13} and IA Rest Octets

This is the minimum set of Rest Octets (except the SI4) the GRR layer needs to decode and process (according to TS 44.060).

Apart of this, I have a draft implementation of the logic triggering Uplink TBF allocation by sending RACH.req with specific RA values (as per 3GPP TS 44.018, 9.1.8) and the logic matching Immediate Assignment messages containing the Uplink TBF information for us. This is not really useful until we have implemented the lower layers (RLC/MAC) maintaining the TBF and the upper layers (LLC & at least GMM) sending and receiving data over the TBFs.

I will continue working on the GRR logic and will focus on integration with the upper LLC layer.

I submitted a patchset to libosmo-gprs-rlcmac to add APIs for the upper-side primitives (GRR and GMMRR SAPs):
https://gerrit.osmocom.org/c/libosmo-gprs/+/31075 rlcmac: Support extending log categories in the future
https://gerrit.osmocom.org/c/libosmo-gprs/+/31076 rlcmac: Introduce primitives for SAPs towards higher layers

And modem app is already using those with this patch:
https://gerrit.osmocom.org/c/osmocom-bb/+/31077 modem: Initial integration of libosmo-gprs-rlcmac

I started implementing some of the RLC state here:
remote: https://gerrit.osmocom.org/c/libosmo-gprs/+/31098 rlcmac: Enqueue LLC PDUs based on RadioPriority and SAPI [WIP] [NEW]
remote: https://gerrit.osmocom.org/c/libosmo-gprs/+/31099 WIP: rlcmac: Initial implementation [WIP] [NEW]

With current state I can already Enqueue a GMM Attach Request from the modem app (hardcoded blob since we have no libosmo-gprs-gmm yet), and it goes LLC->RLCMAC, where it is stored in a priority list.
RLC/MAC already detects it has new data to send and that there's no active UL TBF for that entity (MS, tlli), hence it allocates a new ul_tbf object for that entity and instructs it to start an UL ASS towards the network. FSMs already exist for that scenario, which waits to receive CCCH Imm.Ass, and then either goes 1phase or 2phase (Tx Pkt Resource Req + Rx Pkt Ul Ass + Tx Pkt Ctrl ACk).

I also implemented an initial scheduler which should be able to trigger transmit of the Ul pkts from the FSM above (encoding of packets themselves still not done). I couldn't test it yet because I lack RTS.ind from lower layers.

What I need to use in the library which is not yet available (fixeria you may want to help here):
- API to instruct lower layers to send a RACH.req
- API to receive the CCCH Imm Ass from lower layers
- API from lower layers to gets RTS.ind (with info: trx, ts, fn, and MAC header received from DL like USF).