OsmocomBB

I started looking at this and took over the code initially pushed by fixeria to libosmo-gprs-llc.

Status there was that the enc/dec functionalitites were already ported, and the primitives and types descriptions were already put into a header file.

I looked at the related specs and I started adding what is going to be the public API based on "struct osmo_gprs_llc_prim" being pushed up and down by upper/lower layers.
Code I am working on can be found in libosmo-gprs.git branch "pespin/master".

Once I'm finished adding the required public APIs to generate the primitives, I'll continue implementing the osmo_gprs_llc_prim_upper_down() and osmo_gprs_llc_prim_lower_up() APIs.

For that, I'll basically need to integrate the data structures available already in osmo-sgsn. The code should be imported and modified to use the newly enc/dec functions prepared by fixeria.
OsmoSGSN already implements the 3GPP TS 44.064 C.2 FSM but without using an osmo-fsm. The idea is to try to import is first as it is, and later on move it to an osmo_fsm.

Hence the FSM and the dec/enc functions remain mainly private and not accessible from the upper/lower layers, which are expected to use mainly the primitive-based API.

Regarding the primitive API, something still not clear is what I should pass as "SAP" to them. I could add a "enum osmo_gprs_llc_sap { LLGM, LL, GRR, BSSGP }" and split enum osmo_gprs_llc_prim_type into per SAP enums, but I'm not sure if it's worth it?

pespin wrote in #note-6:

For that, I'll basically need to integrate the data structures available already in osmo-sgsn. The code should be imported and modified to use the newly enc/dec functions prepared by fixeria.
OsmoSGSN already implements the 3GPP TS 44.064 C.2 FSM but without using an osmo-fsm. The idea is to try to import is first as it is, and later on move it to an osmo_fsm.

Ack.

Hence the FSM and the dec/enc functions remain mainly private and not accessible from the upper/lower layers, which are expected to use mainly the primitive-based API.

Full ack.

Regarding the primitive API, something still not clear is what I should pass as "SAP" to them. I could add a "enum osmo_gprs_llc_sap { LLGM, LL, GRR, BSSGP }" and split enum osmo_gprs_llc_prim_type into per SAP enums, but I'm not sure if it's worth it?

AFAIR, something like that was already proposed during code review. I don't have a strong preference here.

I'm still WIP importing the SNDCP layer from osmo-sgsn.

I realized I need to create a new data structure to hold management data shared by all sne (sndcp_entity). What's called in TS 44.065 "SNDCP management entity". This is used to keep track of the XID params at SNDCP layer. In osmo-sgsn this data structure doesn't exist, because the data is stored doing layer violation in "llme" pointer, which is 1 to 1 with the new data structure I need to create.
Then I also have that structure "snme" accessible and refcounted by all "sne" (sndcp_entity" pointers.

I have been doing quite a lot of osmo-sgsn clean up and refactoring (bunch of patches in gerrit), in order to split stuff into different modules and make it easier to replace code with libosmo-gprs.

self note: Some info on TLLI+RAI and NSAPI to identify MS can be found at 3GPP TS 23.060 section "14.3 NSAPI and TLLI for A/Gb mode"

LLC layer seems to be working at least up to the point to do the full GMM attach + SM Activate PDP Ctx.

Stuff still needed to be tested (and which may still not work properly):
- encryption
- Transmit user data (tun->sndcp->llc)

I also noticed that when we receive LLC Dummy frames transmitted by PCU from the GRR-UNITdata.ind, the LLC code discards them due to wrong FCS reported 0x2b2b2b2 instead of the expected value.

The missing bits are right now a bit hard to test due to instabilities and missing features in the lower layers.