https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-11-05T15:00:18ZOpen Source Mobile CommunicationsOsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=202742020-11-05T15:00:18Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed parent" href="/issues/4851">Feature #4851</a>: VCGS/VBS support in osmo-bts</i> added</li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=202762020-11-05T15:00:22Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed parent" href="/issues/4852">Feature #4852</a>: VGCS/VBS support in osm-bsc</i> added</li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=202782020-11-05T15:00:26Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/4853">Feature #4853</a>: VBS/VGCS support in osmo-mgw</i> added</li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=232702021-12-20T13:02:23Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/5364">Feature #5364</a>: VGCS/VBS support in osmocom-bb</i> added</li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=254892022-11-20T16:41:13Zlaforge
<ul><li><strong>Assignee</strong> set to <i>4368</i></li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=254992022-11-20T17:27:41Zlaforge
<ul></ul><p>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.</p>
<p>On the AoIP interface, we should probably advertise and implement (only) the <em>A-interface circuit sharing</em> 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.</p>
<p>Likewise, we should probably advertise and implement (only) the <em>A-interface link sharing</em>. 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.</p>
<p>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.</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=259522023-01-17T11:59:42Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Low</i> to <i>Normal</i></li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=266252023-04-03T09:13:37Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>jolly</i></li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=267462023-04-20T11:41:34Zjolly
<ul></ul><p>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.</p>
<p>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:</p>
<p>“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.</p>
<p>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.</p>
<p>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.</p>
<p>At the end of the call (terminated by the initiator) the channel is release via “CLEAR COMMAND” message and acknowledged via “CLEAR COMPLETE” message.</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=267482023-04-20T13:58:09Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>For inter-BSC handover, there is a procedure where the MSC initiates an SCCP conn (connection-oriented) towards the BSC.</p>
<p>See msc_ho.c:msc_ho_send_handover_request() --> msc_t.c:msc_t_fsm_pending_first_co_initial_msg()</p>
<p>Note the roles which are separated, because of inter-MSC handover support:<br />MSC-A: manages the subscriber<br />MSC-I: forwards DTAP to the BSC<br />MSC-T: transitory, to establish new connections</p>
<p>A chart of how messages travel through osmo-msc is here:<br /><a class="external" href="https://cgit.osmocom.org/osmo-msc/tree/include/osmocom/msc/sccp_ran.h">https://cgit.osmocom.org/osmo-msc/tree/include/osmocom/msc/sccp_ran.h</a></p>
<p>The inter-BSC handover does the SCCP CR via the MSC-T, I'm not sure whether that is needed here ... ?<br />The question to answer this is: how does this new feature relate to inter-MSC handover.<br />Is the MSC-A involved and do messages need to be forwarded to a remote MSC after inter-MSC handover?</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=267492023-04-20T14:03:06Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The osmo-bsc side accepting the connection is handle_n_connect_from_msc() in osmo_bsc_sigtran.c</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=267512023-04-20T19:09:58Zlaforge
<ul></ul><p>Note that we do not need Handover support for vgcs/vbs. It is out of score for our current work</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=267522023-04-20T20:55:02Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>For the record, jolly and I have had a long call discussing, he explained the <br />details to me, and I think I provided helpful pointers as to where to put<br />things in osmo-msc.</p>
<blockquote>
<p>Note that we do not need Handover support for vgcs/vbs. It is out of score for our current work</p>
</blockquote>
<p>The way we discussed it, the BSS connections for vgcs/vbs will completely <br />bypass the MSC-I <-> MSC-A abstraction used for inter-MSC handover.</p>
<p>Funnily enough, AFAICT the originial Calling Subscriber can still do an<br />inter-MSC handover for free because its own signalling already gets<br />transparently redirected via MSC-I. But naturally, the BSS links that the MSC<br />connects to for the BCC are tied where they are, and the BSS must be serviced <br />directly at the osmo-msc site where the Calling Subscriber has its initial<br />MSC-A (before any handovers, it all must be within the same MSC process. After <br />that, the Calling Subscriber can move with handover as usual conns do,<br />incidentally, because its MSC-A role always stays exactly where it was).</p>
<pre>
Calling Subscriber MSC
|---------------DTAP------->|
|------VGCS----->BSS
|------VGCS----->BSS2
|------VGCS----->BSS3
^ this side can do HO ^ but not this side
without any extra work
</pre>
<p>I'm a bit uncertain though whether the inter-MSC HO would then lose the voice channel.</p>
<p>So maybe we should artificially prevent any inter-MSC HO for the Calling Subscriber,<br />to properly not-support it?</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=267542023-04-20T22:34:23Zlaforge
<ul></ul><p>On Thu, Apr 20, 2023 at 08:55:03PM +0000, neels wrote:</p>
<blockquote>
<p>For the record, jolly and I have had a long call discussing, he explained the <br />details to me, and I think I provided helpful pointers as to where to put<br />things in osmo-msc.</p>
</blockquote>
<p>excellent.</p>
<blockquote>
<p>I'm a bit uncertain though whether the inter-MSC HO would then lose the voice channel.</p>
<p>So maybe we should artificially prevent any inter-MSC HO for the Calling Subscriber,<br />to properly not-support it?</p>
</blockquote>
<p>I guess we'll find out during testing if it works for the calling side, or if it doesn't work<br />and we should prevent it.</p>
<p>For the called side, I believe the MS will autonomously do cell re-selection,<br />and will listen to the NCH and pick up the right TCH for the VBS/VGCS call.</p> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=272182023-06-29T23:01:45Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/3294">Bug #3294</a>: transaction: refactor callref allocation</i> added</li></ul> OsmoMSC - Feature #4854: VGCS/VBS support in osmo-mschttps://projects.osmocom.org/issues/4854?journal_id=278332023-09-08T10:28:52Zjolly
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>VGCS/VBS calls are supported and successfully tested.</p>
<p>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.</p>
<p>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.</p>