Project

General

Profile

Feature #3537

BSC support for CBSP (cell broadcast service protocol)

Added by laforge over 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/06/2019
Due date:
05/06/2019
% Done:

100%

Spec Reference:
Tags:

Description

Right now, the only way to send cell broadcast messages is to use the BSC VTY.

3GPP Specifies CBSP in TS 48.049 as the protocol used between BSC and CBC to configure which kind of messages shall be broadcast where, and for how long.

It's a simple TLV based protocol encapsulated in TCP, so the protocol itself should be rather easy to support. However, it requires an underlying SMSCB scheduler that provides the required functionality for routing/scheduling. See #3536.


Related issues

Related to OsmoBSC - Feature #3536: BSC: support for repeated scheduling of SMSCB messagesResolved09/09/2018

Related to Cellular Network Infrastructure - Feature #3973: wireshark dissector for CBSP protocolResolved05/03/2019

Related to Cellular Network Infrastructure - Feature #3974: TTCN-3 ProtocolModule for CBSPResolved05/03/2019

Related to OsmoBSC - Feature #4046: BSC support for generating ETWS primary notificationsResolved06/05/2019

Is duplicate of OsmoBSC - Feature #2392: Support for BSC-CBC interface (CBSP) to a cell broadcast centreResolved07/24/2017

Follows libosmocore - Feature #3972: CBSP definitions, encoder, decoder for libosmocoreResolved05/03/2019

Associated revisions

Revision e87693c8 (diff)
Added by laforge almost 2 years ago

gsm0808_utils: Introduce gsm0808_msgb_put_cell_id_u()

This function is doing the bulk work of encoding a given Cell
ID List item. gsm0808_enc_cell_id_list2() is modified to be a
wrapper / loop around the new function.

The purpose of this is to expose Cell ID List Entry encoding
so that the upcoming CBSP protocol encoder can re-use this code.

Related: OS#3537
Change-Id: I6cc567798e20365e6587e6b2988e834306d8c80c

Revision ef7be49a (diff)
Added by laforge almost 2 years ago

gsm0808_utils: Add gsm0808_decode_cell_id_u()

This function parses a single Cell ID list element into a
'union gsm0808_cell_id_u'. This function is going to be used
by the upcoming CBSP support.

Related: OS#3537
Change-Id: I08b33881667aa32f01e53ccb70d44d5b79c7c986

Revision 07958e44 (diff)
Added by laforge over 1 year ago

CBSP (Cell Broadcast Service Protocol; 3GPP TS 48.049) support

This introduces definitions as well as a parser+encoder for the
Cell Broadcast Service Protocol (CBSP) as specified in 3GPP TS 48.049.

CBSP is used on the interface between CBC and BSC.

Related: OS#3537
Change-Id: I5b7ae08f67e415967b60ac4b824db9e22ca00935

Revision 06eb1089 (diff)
Added by laforge 9 months ago

WIP: gsm_412 Cell Broadcast

Related: OS#3537
Change-Id: I1a17c2ae8bf62150327956c10cb5bb896939e3fd

History

#1 Updated by laforge over 2 years ago

  • Related to Feature #3536: BSC: support for repeated scheduling of SMSCB messages added

#2 Updated by laforge over 2 years ago

  • Tags set to SMSCB

#3 Updated by laforge over 2 years ago

  • Is duplicate of Feature #2392: Support for BSC-CBC interface (CBSP) to a cell broadcast centre added

#4 Updated by laforge almost 2 years ago

  • Due date set to 05/06/2019
  • Start date changed from 09/09/2018 to 05/06/2019
  • Follows Feature #3972: CBSP definitions, encoder, decoder for libosmocore added

#5 Updated by laforge almost 2 years ago

  • Related to Feature #3973: wireshark dissector for CBSP protocol added

#6 Updated by laforge almost 2 years ago

  • Assignee set to laforge

#7 Updated by laforge almost 2 years ago

#8 Updated by laforge almost 2 years ago

  • Related to Feature #4046: BSC support for generating ETWS primary notifications added

#9 Updated by laforge almost 2 years ago

  • Priority changed from Low to Normal

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

In terms of an interative implementation approach, the following short-cuts could be taken while stubbing out some of the functionality:
  • 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.

#10 Updated by laforge over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

work on this has started a few days ago.

#11 Updated by laforge over 1 year ago

  • % Done changed from 10 to 60
the bulk of the work on the scheduler has been implemented together with the CBCH scheduler 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
  • VTY configuration for the CBSP link
  • CBSP TCP client and server role
These parts are missing:
  • CBSP LOAD QUERY
  • CBSP MSG STATUS QUERY
  • tests, tests, tests

#12 Updated by laforge over 1 year ago

  • Priority changed from Normal to High

#13 Updated by laforge over 1 year ago

  • % Done changed from 60 to 80

#14 Updated by laforge over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

code merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)