Feature #3536
closed
BSC: support for repeated scheduling of SMSCB messages
Added by laforge over 5 years ago.
Updated over 4 years ago.
Description
So far, the only way to have a SMSCB message sent is to use the VTY to manually send a message to a specific BTS.
So the user needs to:
- know exactly which BTS to sen the message via
- repeat the comamnd or the commands to repeat the transmission of that message
What's missing is some kind of scheduler that would take care of
- repeatedly re-broadcasting messages until some expiration time is reached
- round-robin iterating over multiple messages
- allow messages to have CID/LAC or network-wide scope and take care of sending it to all CBCH-enabled BTSs within that scope
- properly prioritize emergency (ETWS/CMAS/...) messages
If this is implemented, it should be done with keeping TS 48.049 (CBSP) in mind. The capabilities required by CBSP should be supported to allow easy integration of CBSP.
- Related to Feature #3537: BSC support for CBSP (cell broadcast service protocol) added
- Status changed from New to In Progress
- % Done changed from 0 to 60
the bulk of the work on the scheduler has been implemented together with the CBSP protocol handing in the
laforge/cbsp
branch of osmo-bsc.git. It is currently untested, but should do the following things:
- handling of WRITE_REPLACE, KILL and RESET procedures via CBSP from the CBC
- building a scheduler data structure from the pages of the active SMSCB, taking into account their individual broadcast periods/intervals
- removing SMSCB from the scheduler once the requested number of broadcasts has completed
- providing a function to pull one SMSCB page from the scheduler
- VTY configuration for the CBSP link
- CBSP TCP client and server role
The scheduler runs separate for each BTS, and each BTS has separate scheduler instances for BASIC and EXTENDED CBCH
These parts are missing:
- actually sending the 'pulled' SMSCB pages to the BTS for actual transmission
- CBSP LOAD QUERY
- CBSP MSG STATUS QUERY
- tests, tests, tests
- Priority changed from Normal to Urgent
- % Done changed from 60 to 80
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Also available in: Atom
PDF