I've been re-reading specs and thinking a bit more about implementation. They key part of this seems to be:

allocator¶

The allocator takes care of determining if a new SMSCB message of given size (number of pages), repetition period and category(priority) can still be sent over the given channel (basic/extended) at a given BTS.

This allocator then is executed for each cell in the list of cells where the message is to be broadcast, and the results from the allocator determine if we send a CBSP WRITE-REPLACE COMPLETE or a WRITE-REPLACE FAILURE. Where interestingly, the FAILURE can very well be a partial failure, containing a list of cells in which it failed and in which it succeeded.

scheduler¶

The scheduler runs for each BTS separately. It has a list of SMSCB which are to be broadcast in this BTS, and must determine which page of which SMSCB message to transmit at which given point in time to ensure the repetition period is respected

CBSP client¶

The CBSP client will connect/reconnect to the CBC, ensure the link works (keep-alive).

It will [optionally] use some Osmocom-propietary means to identify the BSC (and its served cells) to the CBC, avoiding the need for manual configuration of this data out-of-band to the CBC.

CBSP server¶

The spec appears to require the BSC to accept an inbound TCP connection from the CBC. We should support this for interoperability. Only one CBC can ever talk to a BSC, so we should have some kind of "either client or server" configuration. Only one connection shall be accepted in the server-side socket.

Implementation Strategy¶

Iterative approach¶

• assume that there's unlimited CBCH capacity, i.e. accept all WRITE-REPLACE even if they cannot be scheduled. Works for low CBCH load situations, which are likely in practise
• always broadcast each SMSCB on all cells in the BSC, avoiding implementing 5 different ways on how the Cell List can be encoded in CBSP

Test driven¶

Let's first implement BSC_Tests.ttcn coverage for SMSCB/CBSP and then use that to drive the implementation. Emulating a number of BTSs on the RSL side as well as the CBC on the CBSP side are sufficient for testing anything we need.

work on this has started a few days ago.

• handling of WRITE_REPLACE, KILL and RESET procedures via CBSP from the CBC
• VTY configuration for the CBSP link
• CBSP TCP client and server role

• CBSP LOAD QUERY
• CBSP MSG STATUS QUERY
• tests, tests, tests