Project

General

Profile

Actions

Feature #4854

closed

VGCS/VBS support in osmo-msc

Added by laforge over 3 years ago. Updated 7 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
11/05/2020
Due date:
% Done:

100%

Resolution:
Spec Reference:
Tags:

Description

In order to support VBS/VGCS calls, we will need to
  • interface osmo-mgw to create a RTP endpoint that has
    • one RTP flow (in) from whoever is talking
    • one RTP flow (out) to each BSC[-MGW] where the group is active
  • implement the BCC L3 protocol as per TS 44.069
  • implement the GCC L3 protocol as per TS 44.068
  • implement the A/BSSMAP procedures for
    • VGCS/VBS setup
    • VGCS/VBS assignment

Subtasks 2 (0 open2 closed)

Feature #5776: VBS support in osmo-mscClosedjolly11/20/2022

Actions
Feature #5777: VGCS support in OsmoMSCClosedjolly11/20/2022

Actions

Related issues

Related to OsmoBTS - Feature #4851: VCGS/VBS support in osmo-btsResolvedjolly11/05/2020

Actions
Related to OsmoBSC - Feature #4852: VGCS/VBS support in osm-bscResolvedjolly11/05/2020

Actions
Related to OsmoMGW - Feature #4853: VBS/VGCS support in osmo-mgwClosedjolly11/05/2020

Actions
Related to OsmocomBB - Feature #5364: VGCS/VBS support in osmocom-bbResolvedjolly12/20/2021

Actions
Related to OsmoMSC - Bug #3294: transaction: refactor callref allocationStalledneels05/26/2018

Actions
Actions #1

Updated by laforge over 3 years ago

Actions #2

Updated by laforge over 3 years ago

Actions #3

Updated by laforge over 3 years ago

Actions #4

Updated by laforge over 2 years ago

Actions #5

Updated by laforge over 1 year ago

  • Assignee set to 4368
Actions #6

Updated by laforge over 1 year ago

For a simple implementation of a stand-alone/lab network with a single MSC, there is no need for implementing the GCR and the related procedures where the MSC is querying the GCR. We also don't need to support "relaying" broadcast call. We can always assume that we are the anchor MSC and responsible for all group calls. We can furthermore assume that all BSCs/cells are part of the broadcast call area. If needed, simple vty commands for configuring groups with relevant parameters of TS 43.069 Section 8.1.2 can be added.

On the AoIP interface, we should probably advertise and implement (only) the A-interface circuit sharing support as described in 43.069 section 7.1a. This means that every BSC only gets one RTP stream for each call, irrespective of the number of BTSs below that BSC. The same IP/Port will be signalled for all the cells. This way we have a clean architecture: The MSC-MGW sends the call once to each BSC-MGW, and each BSC-MGW sends the call to all relevant BTS.

Likewise, we should probably advertise and implement (only) the A-interface link sharing. This way there's only one logical A-interface control connection between a BSC and MSC, irrespective of the number of BTS in that BSC.

In terms of codec, it is probably safe to signal FR codec for broadcast calls only. VBS using EFR and AMR is only implemented from Rel-7 onwards.

Actions #7

Updated by laforge about 1 year ago

  • Priority changed from Low to Normal
Actions #9

Updated by laforge 12 months ago

  • Assignee changed from 4368 to jolly
Actions #10

Updated by jolly 11 months ago

A channel allocation of normal GSM call is always initiated by the mobile. In case of mobile terminating call, the channel allocation is initiated by the mobile after receiving a paging request.

This is different on a voice group/broadcast call. The initiator of the call will initiate the channel allocation similar to a normal call. The anchor MSC is provided with a list of cells where the call shall be broadcasted simultaneously. This can be one cell. Also there might be no mobile station attending to the call in a cell. It is task of the MSC to initiate the channel allocation. There is one SCCP connection for every cell. The following messages are used on the A-interface to perform this:

“VGCS/VBS SETUP” message will request VGCS/VBS capabilities from the MSC. If the MSC supports voice group/broadcast calls, it will respond with “VGCS/VBS SETUP ACK” message including the capabilities supported by both sides. Alternatively it may refuse the call with “VGCS/VBS SETUP REFUSE” message.

Then the MSC will send “VGCS/VBS ASSIGNMENT REQUEST” message with cell identification and parameters for the channel towards the MSC. The MSC will respond with “VGCS/VBS ASSIGNMENT RESULT” message, in case of no failure.

In case of a voice group call, several messages are used to control the access to the uplink. The MSC is responsible that there is only one mobile station accessing the uplink at a time.

At the end of the call (terminated by the initiator) the channel is release via “CLEAR COMMAND” message and acknowledged via “CLEAR COMPLETE” message.

Actions #11

Updated by neels 11 months ago

For inter-BSC handover, there is a procedure where the MSC initiates an SCCP conn (connection-oriented) towards the BSC.

See msc_ho.c:msc_ho_send_handover_request() --> msc_t.c:msc_t_fsm_pending_first_co_initial_msg()

Note the roles which are separated, because of inter-MSC handover support:
MSC-A: manages the subscriber
MSC-I: forwards DTAP to the BSC
MSC-T: transitory, to establish new connections

A chart of how messages travel through osmo-msc is here:
https://cgit.osmocom.org/osmo-msc/tree/include/osmocom/msc/sccp_ran.h

The inter-BSC handover does the SCCP CR via the MSC-T, I'm not sure whether that is needed here ... ?
The question to answer this is: how does this new feature relate to inter-MSC handover.
Is the MSC-A involved and do messages need to be forwarded to a remote MSC after inter-MSC handover?

Actions #12

Updated by neels 11 months ago

The osmo-bsc side accepting the connection is handle_n_connect_from_msc() in osmo_bsc_sigtran.c

Actions #13

Updated by laforge 11 months ago

Note that we do not need Handover support for vgcs/vbs. It is out of score for our current work

Actions #14

Updated by neels 11 months ago

For the record, jolly and I have had a long call discussing, he explained the
details to me, and I think I provided helpful pointers as to where to put
things in osmo-msc.

Note that we do not need Handover support for vgcs/vbs. It is out of score for our current work

The way we discussed it, the BSS connections for vgcs/vbs will completely
bypass the MSC-I <-> MSC-A abstraction used for inter-MSC handover.

Funnily enough, AFAICT the originial Calling Subscriber can still do an
inter-MSC handover for free because its own signalling already gets
transparently redirected via MSC-I. But naturally, the BSS links that the MSC
connects to for the BCC are tied where they are, and the BSS must be serviced
directly at the osmo-msc site where the Calling Subscriber has its initial
MSC-A (before any handovers, it all must be within the same MSC process. After
that, the Calling Subscriber can move with handover as usual conns do,
incidentally, because its MSC-A role always stays exactly where it was).

  Calling Subscriber             MSC
      |---------------DTAP------->|
                                  |------VGCS----->BSS
                                  |------VGCS----->BSS2
                                  |------VGCS----->BSS3

        ^ this side can do HO         ^ but not this side
          without any extra work

I'm a bit uncertain though whether the inter-MSC HO would then lose the voice channel.

So maybe we should artificially prevent any inter-MSC HO for the Calling Subscriber,
to properly not-support it?

Actions #15

Updated by laforge 11 months ago

On Thu, Apr 20, 2023 at 08:55:03PM +0000, neels wrote:

For the record, jolly and I have had a long call discussing, he explained the
details to me, and I think I provided helpful pointers as to where to put
things in osmo-msc.

excellent.

I'm a bit uncertain though whether the inter-MSC HO would then lose the voice channel.

So maybe we should artificially prevent any inter-MSC HO for the Calling Subscriber,
to properly not-support it?

I guess we'll find out during testing if it works for the calling side, or if it doesn't work
and we should prevent it.

For the called side, I believe the MS will autonomously do cell re-selection,
and will listen to the NCH and pick up the right TCH for the VBS/VGCS call.

Actions #16

Updated by neels 9 months ago

  • Related to Bug #3294: transaction: refactor callref allocation added
Actions #17

Updated by jolly 7 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

VGCS/VBS calls are supported and successfully tested.

The MSC controls the voice conference at OsmoMGW. Because OsmoMGW cannot transcode, the audio source is switched to the cell where the phone is accessing the uplink.

The implementation allows to have any number of BSCs with any number of cells for each call. The calls and the cells are defined via VTY, so that no extra group call register is required.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)