Some code that is disabled to be able to compile libmsc without libbsc is related to communication to the BTS, that is replaced by the new A-interface. However, the following bits are not; Any opinions about what to do with it:
- Report on which ARFCN and timeslot a silent call has occured. I would simply drop the ARFCN and timeslot information, saying "silent call successful". (same in two log messages)
static int scall_cbfn(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data) { struct scall_signal_data *sigdata = signal_data; struct vty *vty = sigdata->data;
switch (signal) { case S_SCALL_SUCCESS: vty_out(vty, "%% silent call on ARFCN %u timeslot %u%s", sigdata->conn->lchan->ts->trx->arfcn, sigdata->conn->lchan->ts->nr, VTY_NEWLINE); break; case S_SCALL_EXPIRED: vty_out(vty, "%% silent call expired paging%s", VTY_NEWLINE); break; } return 0; }
- Add Osmocom specific TLVs to SMPP
/* Append the Osmocom vendor-specific additional TLVs to a SMPP msg */ static void append_osmo_tlvs(tlv_t **req_tlv, const struct gsm_lchan *lchan) { int idx = calc_initial_idx(ARRAY_SIZE(lchan->meas_rep), lchan->meas_rep_idx, 1); const struct gsm_meas_rep *mr = &lchan->meas_rep[idx]; const struct gsm_meas_rep_unidir *ul_meas = &mr->ul; const struct gsm_meas_rep_unidir *dl_meas = &mr->dl;
/* Osmocom vendor-specific SMPP34 extensions */ append_tlv_u16(req_tlv, TLVID_osmo_arfcn, lchan->ts->trx->arfcn); if (mr->flags & MEAS_REP_F_MS_L1) { uint8_t ms_dbm; append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_l1.ta); ms_dbm = ms_pwr_dbm(lchan->ts->trx->bts->band, mr->ms_l1.pwr); append_tlv_u8(req_tlv, TLVID_osmo_ms_l1_txpwr, ms_dbm); } else if (mr->flags & MEAS_REP_F_MS_TO) /* Save Timing Offset field = MS Timing Offset + 63 */ append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_timing_offset + 63);
append_tlv_u16(req_tlv, TLVID_osmo_rxlev_ul, rxlev2dbm(ul_meas->full.rx_lev)); append_tlv_u8(req_tlv, TLVID_osmo_rxqual_ul, ul_meas->full.rx_qual);
if (mr->flags & MEAS_REP_F_DL_VALID) { append_tlv_u16(req_tlv, TLVID_osmo_rxlev_dl, rxlev2dbm(dl_meas->full.rx_lev)); append_tlv_u8(req_tlv, TLVID_osmo_rxqual_dl, dl_meas->full.rx_qual); }
if (lchan->conn && lchan->conn->vsub) { struct vlr_subscr *vsub = lchan->conn->vsub; size_t imei_len = strlen(vsub->imei); if (imei_len) append_tlv(req_tlv, TLVID_osmo_imei, (uint8_t *)vsub->imei, imei_len+1); } }
deliver_to_esme() { [...] if (esme->acl && esme->acl->osmocom_ext && conn->lchan) append_osmo_tlvs(&deliver.tlv, conn->lchan); [...] }
- Siemens BS11 MRPCI
/* see mail on openbsc@ 9 Feb 2016 22:30:15 +0100 * We need to hook sending of MRPCI to Siemens BS11 somewhere else */ if (is_siemens_bts(conn->bts)) send_siemens_mrpci(msg->lchan, classmark2-1);
- Debug log: report bts - trx - ts - ti in mncc_rcvmsg() (No BTS information available in OsmoMSC anymore)
- In gsm48_cc_rx_setup(), populate struct gsm_mncc setup with lchan type. (lchan information is no longer available in OsmoMSC)
- In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be dropped from libmsc.
/* * This will be run by the linker when loading the DSO. We use it to * do system initialization, e.g. registration of signal handlers. */ static __attribute__((constructor)) void on_dso_load_0408(void) { osmo_signal_register_handler(SS_ABISIP, handle_abisip_signal, NULL); }
~N
Hi Neels,
On Fri, Jul 21, 2017 at 12:47:35AM +0200, Neels Hofmeyr wrote:
Some code that is disabled to be able to compile libmsc without libbsc is related to communication to the BTS, that is replaced by the new A-interface. However, the following bits are not; Any opinions about what to do with it:
my suggestion here would be a set of optional, vendor-specific TLVs that we can introduce in the A interface to convey related information. Those extensions could be enabled by default using a vty command on the BSC, and could be disabled for strict interop with other implementations that don't understand them.
- Report on which ARFCN and timeslot a silent call has occured. I would simply drop the ARFCN and timeslot information, saying "silent call successful". (same in two log messages)
Would be easy to include information about the actual physical channel from BSC -> MSC, such as BTS number (maybe CGI=MCC+MNC+LAC+CID), ARFCN, timeslot/sub-slot (rsl chan_nr)...
This is generally useful for all kinds of debugging.
In a similar manner I would tranasport some kind of subscriber name/identification from the MSC to the BSC so the BSC can still show who has allocated a given channel. In its most generic form it could be as simple as a string TLV that the MSC can add to whatever downlink A interface message, and which the BSC accepts in every such message to talloc_replace_string() a field in its lchan, which can then be printed by various code (particularly logging) or used as log filter, or whatever else.
- Add Osmocom specific TLVs to SMPP
Could be handled the same way, but should be yet another option, as it adds a lot of verbosity to the A interface which it otherwise doesn't need. Not the highest priority, but definitely doable with reasonable effort.
Siemens BS11 MRPCI
/* see mail on openbsc@ 9 Feb 2016 22:30:15 +0100 * We need to hook sending of MRPCI to Siemens BS11 somewhere else */ if (is_siemens_bts(conn->bts)) send_siemens_mrpci(msg->lchan, classmark2-1);
this has to be moved to the BSC.
- Debug log: report bts - trx - ts - ti in mncc_rcvmsg() (No BTS information available in OsmoMSC anymore)
see above, can be retrieved from those TLVs which we send once when confirming the activation of a channel (= SCCP connection).
- In gsm48_cc_rx_setup(), populate struct gsm_mncc setup with lchan type. (lchan information is no longer available in OsmoMSC)
same as above.
- In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be dropped from libmsc.
well, who are the usrers of the signal?
On Fri, Jul 21, 2017 at 08:42:38AM +0200, Harald Welte wrote:
my suggestion here would be a set of optional, vendor-specific TLVs that we can introduce in the A interface to convey related information.
Would be easy to include information about the actual physical channel from BSC -> MSC, such as BTS number (maybe CGI=MCC+MNC+LAC+CID), ARFCN, timeslot/sub-slot (rsl chan_nr)...
This is generally useful for all kinds of debugging.
In a similar manner I would tranasport some kind of subscriber name/identification from the MSC to the BSC so the BSC can still show who has allocated a given channel. In its most generic form it could be as simple as a string TLV that the MSC can add to whatever downlink A interface message, and which the BSC accepts in every such message to talloc_replace_string() a field in its lchan, which can then be printed by various code (particularly logging) or used as log filter, or whatever else.
Agreed.
For the code review this means: we cannot sensibly add those kinds of TLVs before we actually have the A-interface in the MSC. So the MSCSPLIT stage of the code review in osmo-msc.git will drop the code and we shall re-add once we have osmocom-specific TLVs added to our A-interface code. I tend towards leaving the '#if BEFORE_MSCSPLIT' markings there to disable the code instead of dropping it, to be able to easily find it later and see what it was supposed to do.
- Add Osmocom specific TLVs to SMPP
Could be handled the same way, but should be yet another option, as it adds a lot of verbosity to the A interface which it otherwise doesn't need. Not the highest priority, but definitely doable with reasonable effort.
I notice that this uses lchan measurement reports... not sure whether / when we want to send those to the MSC, but am not familiar enough. OS#2390
- Siemens BS11 MRPCI
this has to be moved to the BSC.
OS#2389 -- also makes sense to drop in initial split and re-add in osmo-bsc after AoIP.
- In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be dropped from libmsc.
well, who are the usrers of the signal?
OsmoMSC no longer has an Abis interface, so it does not make sense to handle that signal. Anyway, in osmo-nitb, the consumer was handle_abisip_signal() in gsm_04_08.c, which apparently does RTP stream handling: - receives S_ABISIP_CRCX_ACK to connect an RTP socket; and flush pending pending tch_recv_mncc requests (which I don't fully understand, guess it's RTP also stream related) - receives S_ABISIP_DLCX_IND and frees an RTP socket. Since RTP is now handled via osmo-bsc_mgcp, I conclude that this is indeed obsolete.
~N
What about this one: I assume handover will be an entirely different issue to be tackled with the new A-interface and we can drop this VTY command without substitute for now?
DEFUN(ena_subscr_handover, ena_subscr_handover_cmd, "subscriber " SUBSCR_TYPES " ID handover BTS_NR", SUBSCR_HELP "Handover the active connection\n" "Number of the BTS to handover to\n") { #if BEFORE_MSCSPLIT int ret; struct gsm_subscriber_connection *conn; struct gsm_bts *bts; struct gsm_network *gsmnet = gsmnet_from_vty(vty); struct vlr_subscr *vsub = get_vsub_by_argv(gsmnet, argv[0], argv[1]);
if (!vsub) { vty_out(vty, "%% No subscriber found for %s %s.%s", argv[0], argv[1], VTY_NEWLINE); return CMD_WARNING; }
conn = connection_for_subscr(vsub); if (!conn) { vty_out(vty, "%% No active connection for subscriber %s %s.%s", argv[0], argv[1], VTY_NEWLINE); vlr_subscr_put(vsub); return CMD_WARNING; }
bts = gsm_bts_num(gsmnet, atoi(argv[2])); if (!bts) { vty_out(vty, "%% BTS with number(%d) could not be found.%s", atoi(argv[2]), VTY_NEWLINE); vlr_subscr_put(vsub); return CMD_WARNING; }
/* now start the handover */ ret = bsc_handover_start(conn->lchan, bts); if (ret != 0) { vty_out(vty, "%% Handover failed with errno %d.%s", ret, VTY_NEWLINE); } else { vty_out(vty, "%% Handover started from %s", gsm_lchan_name(conn->lchan)); vty_out(vty, " to %s.%s", gsm_lchan_name(conn->ho_lchan), VTY_NEWLINE); }
vlr_subscr_put(vsub); return CMD_SUCCESS; #else vty_out(vty, "%% Not implemented!%s", VTY_NEWLINE); return -1; #endif }
~N
Hi Neels,
On Mon, Jul 24, 2017 at 03:35:37PM +0200, Neels Hofmeyr wrote:
What about this one: I assume handover will be an entirely different issue to be tackled with the new A-interface and we can drop this VTY command without substitute for now?
You have to differentiate between intra-BSC hand-over and inter-BSC hand-over (or even inter-MSC hand-over).
Intra-BSC hand-over is exactly like it is now. The command you're referring to thus simply has to go to into the BSC. The only problem is that the subscriber will probably not be possible to be identified by the IMSI as the BSC doesn't normally cache that information. But what kind of identifier do we show in "show lchan"? TMSI? SCCP Connection ID?
This VTY command is quite essential to test hand-over during development and testing.
Once we have the Osmocom extension TLVs by which the MSC can provide a subscriber identity to the BSC, we can re-introduce identifying the subscriber connection by such identity/name.
Inter-BSC or Inter-MSC handover is something that we didn't have in NITB, but which is not really relevant to this question.
-
Harald Welte -
Neels Hofmeyr