Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

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.

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?

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

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

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?

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.