aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-07-16RR Channel Release: pass Cause code from BSSMAP Clear to the BTSNeels Hofmeyr7-12/+64
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause value to lchan.release.cause_rr. In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause value, these are unrelated. Store in new lchan.release.cause_rr instead. The rsl_error_cause is apparently only used for logging, except for one place in lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so there should not be a functional difference by this fix. Propagate the BSSMAP Clear Command cause to the RR Channel Release: Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens in bssmap_handle_clear_cmd(). Adjust event handling in gscon_fsm_allstate(); there, pass the cause to gscon_release_lchans(). In gscon_release_lchans(), pass the cause to gscon_release_lchan(), and then lchan_release(), which sets the new lchan.release.cause_rr to the passed cause value. As soon as the lchan FSM enters the proper state, it calls gsm48_send_rr_release(). There, set the cause value in the encoded message to lchan.release.cause_rr. Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command cause code for normal release, it just passes 0 which amounts to GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC. This means in practice that we will now see an error cause in RR Channel Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc). A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b (osmo-ttcn3-hacks). Related: SYS#4872 Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
2020-07-16RR Release Cell selection IE: fix repeated EARFCNs encodingNeels Hofmeyr1-4/+8
3GPP 44.018 10.5.2.1e defines the EARFCNs encoded in the 'Cell selection indicator after release of all TCH and SDCCH IE' as follows: <Cell Selection Indicator after release of all TCH and SDCCH value part> ::= [...] | 011 { 1 <E-UTRAN Description : < E-UTRAN Description struct >> } ** 0 So after a 3-bit discriminator of '3' there can be multiple E-UTRAN Descriptions, and each of them starts with a '1' bit to indicate that another item follows. Finally there is a '0' bit to indicate the list end. Before this patch, osmo-bsc only encoded the first '1' bit, and failed to repeat this before each following E-UTRAN Description. Fix that by moving the '1' encoding into the loop. The final '0' was missing. Add it. With these changes, adjust the size calculation in CELL_SEL_IND_AFTER_REL_MAX_BITS to match. Also fix CELL_SEL_IND_AFTER_REL_MAX_BYTES by using OSMO_BYTES_FOR_BITS() instead of the inaccurate (n/8)+1. A test for this is in I882c5e1f70bcc4833fc837a95c900ce291919cc5 (osmo-ttcn3-hacks). Related: SYS#4871 SYS#4872 Change-Id: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab
2020-07-16ipaccess_nanobts: Log ipaccess_sign_link_down eventPau Espin Pedrol1-0/+4
Change-Id: I7c864e67fb2149685c687c137a59d567f5a03ca3
2020-07-16Add example configuration files for E1 BTSHarald Welte4-0/+343
This adds osmo-bsc config files for Ericsson RBS2308, Siemens BS-11 and Nokia InSite which were working in July 2020 to get the BTS initialized, recognized by MS and up to signalling. Voice/TRAU support is still missing in OsmoBSC, but should be added relatively soon. Change-Id: I1fe15cc3654025e52fc1110ac3052fb1f7a009a0 Depends: osmo-python-tests I896b99032d94ba0cdd340a8eed7c7b625661ad69 Closes: OS4651
2020-07-15doc/examples: remove deprecated 'dyn_ts_allow_tch_f'Vadim Yanitskiy2-2/+0
This option has been deprecated back in 2018 [1], but for some reason we still have it in the configuration examples, so it prevents osmo-bsc to allocate TCH/F on dynamic timeslots. [1] Ib2335d02ea545aff837aadd49f15b2fdb418c46e Change-Id: Icc82f6178d18dccc7207485b25dc3bdad91a0052 Related: SYS#5014
2020-07-15Fix trailing whitespace in several filesPau Espin Pedrol7-11/+9
Change-Id: Ide9921dfce3b6d7c580edaa612a3063c94319a02
2020-07-15gsm_data.h: Drop duplicated include stdint.hPau Espin Pedrol1-1/+0
Change-Id: I7610cffc3a641975e05ba4ea9f469e12c99e407f
2020-07-15Use OSMO_FD_* instead of deprecated BSC_FD_*Pau Espin Pedrol11-35/+35
New define is available since libosmocore 1.1.0, and we already require 1.3.0, so no need to update dependenices. Let's change it to avoid people re-using old BSC_FD_* symbols when copy-pasting somewhere else. Change-Id: Ia5a656567d212fa265aef1375d714d0c5fee5dd6
2020-07-15bts_nokia_site: Clean up loggingHarald Welte1-53/+37
We don't want to fprintf directly, and we want to make sure to always log as much context as possible. Change-Id: I29ec935669175a08cb42e1666559b681c50a6e72
2020-07-14Don't print 'bogus channel load sample' message if total == 0Harald Welte1-1/+3
Change-Id: I857fecc76dc16ba4431f3c0142bb0d798a9f73dc Closes: OS#4614
2020-07-14Bring timeslot FSMs on BS-11 out of NOT_INITIALIZED stateHarald Welte1-0/+5
When we introduced the timeslot FSMs in I82e3f918295daa83274a4cf803f046979f284366, the BS-11 stopped to work, as the timeslot FSMs are never brought out of NOT_INITIALIZED stage. Closes: OS#4666 Change-Id: I557cb105247552887ca47a0f2c1b06b71bca6cac
2020-07-14abis_nm: Avoid various "Unhandled message" errors on BS-11 startupHarald Welte1-0/+12
There are a number of OML messages which are not seen on IP based BTSs. Those are perfectly normal and expected on E1 based BTS. Change-Id: Icd87fc9f3652b21f9d569af2572d080c9ac89e8b Closes: OS#4665
2020-07-14ipaccess_sign_link_up: Log sign_link typePau Espin Pedrol1-1/+1
Change-Id: If16d6feae56785a2c60b605227c0602f80b6f407
2020-07-14bsc_main: Use LOG_TRX in log linePau Espin Pedrol1-3/+2
Change-Id: I88b5f572cb2bae8ffa551789e2c344ec2ebb7e7b
2020-07-14bsc_main: Improve log line on Lost E1 linkPau Espin Pedrol1-1/+1
Change-Id: Ia9f8d14d547b2443713fc406ac5c1005351f8cce
2020-07-08SI2quater: allow storing 48 EARFCNsNeels Hofmeyr1-1/+4
Up to 16 SI2quater are multiplexed; each fits 3 EARFCNS, so the practical maximum is 48 (of course depending on how many bits are used by other SI2quater elements). Change-Id: Iabeed10053ee5899b4def3509aedd25abb2410a9
2020-07-06si2quater: fix budget calculation for multiple EARFCNsNeels Hofmeyr2-67/+91
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25. Removing only 25 bits from the budget resulted in malformed SI2quater starting with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits. These malformed SI2quater were also expected in gsm0408_test.c. Update the expected SI2quater to what is being generated now. This patch passes the ttcn3 testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some confidence that the coding expected in gsm0408_test.c is now correct. Related: OS#4652 Change-Id: I5df269f713456a6ccbb874d6b7faac4a6f123c67
2020-07-03gsm_04_08_rr: fix hopping parameters in RR Assignment CommandVadim Yanitskiy1-3/+9
According to 3GPP TS 44.018, section 9.1.2.4, if at least one of the Channel Description IEs indicates frequency hopping, one and only one of the following IEs shall be present: - Mobile Allocation, after time (see 10.5.2.21); - Frequency List, after time (see 10.5.2.13). For some reason, osmo-bsc includes the GSM48_IE_MA_BEFORE instead of GSM48_IE_MA_AFTER - fix this. According to section 9.1.2.6 of the same document, if any of the Mobile Allocation IEs (before/after time) is present, then the network must ensure that either the MS has already received the the proper reference cell frequency list (CA), or that the Cell Channel Description IE (see 10.5.2.1b) is present. Without this IE, the phone I was using in my testing setup sends RR Status message with cause #100 "conditional IE error". Fortunately, we already have generate_cell_chan_list(), since we also need to include the Cell Channel Description in SI Type 1. Change-Id: I43ef66c109b107ebcaa1cb6197637701b13b3787 Related: SYS#4868, OS#4545, OS#4546
2020-07-03generate_ma_for_ts(): constify per cell/timeslot ARFCN bit-vectorsVadim Yanitskiy1-2/+2
Change-Id: If750003beb8653cf67fd192fa5c16343138155c9
2020-07-03system_information: constify bitvec in freq. list encoding APIVadim Yanitskiy1-3/+3
Change-Id: I95f3a89af16e4a6b4aa1a6a48cf0d0c023f26170
2020-07-03system_information: publicly declare generate_cell_chan_list()Vadim Yanitskiy4-5/+4
Change-Id: Idc7a9ed558ed6897e15a0f6d3c23418db7cee0d0
2020-07-01create ASP+AS only once per cs7 instanceNeels Hofmeyr1-86/+140
Refactor osmo_bsc_sigtran_init(): invoke osmo_sccp_simple_client_on_ss7_id() exactly once per cs7 instance. When introducing MSC pooling to the ttcn3-bsc-tests, it became apparent that osmo-bsc rapidly huts down and re-creates the SCTP link for each configured MSC. This manifested in an osmo-stp crash (fixed in libosmo-sccp I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa). I first tried to fix it by only restarting an ASP when it wasn't found in the AS yet, but that created obscure problems described in OS#4635 which in turn completely broke ttcn3-msc-tests. This solution keeps osmo_sccp_simple_client_on_ss7_id() unchanged and instead invokes it exactly once per cs7 instance. Keep the same auto-config logic, but change and improve the mechanisms to achieve it: Replace the fail_on_next_invalid_cfg flag with a more accurate check against remote PC collisions between configured MSCs. Before this patch, the code made sure that at most one MSC lacks an explicit remote address (and cs7 instance), so that no two MSCs get the same default remote PC. This patch more accurately checks that no two MSCs use the same remote PC on the same cs7 instance, period, whether implicitly or explicitly configured. Before this patch, the logic amounted to creating cs7 instance 0 implicitly, but it was not very obvious: If an 'msc' has an msc-addr configured, it is associated with the cs7 instance that has this addr in its address book. If it has no msc-addr configured, then msc->a.cs7_instance_valid == false. In that case, msc->a.cs7_instance is still 0 (from talloc_zero) and hence osmo_sccp_simple_client_on_ss7_id(ss7_id = 0) created cs7 instance 0. In this patch, that logic remains unchanged, but is written out more explicitly: if any msc has no cs7 instance associated, make sure to create cs7 instance 0 beforehand. Then iterate all osmo_ss7_instances. If at least one MSC uses it, set up the SCCP client on it and connect all MSCs as appropriate. Related: OS#4625 OS#4635 Change-Id: I16f4f7f447f69525a2f57c4649ab295112904d6a
2020-07-01vty: check with is_ipaccess_bts() before using IPACCPhilipp Maier1-1/+7
The IPACC protocol is an extension to the conventional RSL protocol to negotiate ip address and port for RTP/VoIP. This protocol is BTS specific (sysmobts, ip-access nanobts) and not used with E1 BTSs The bsc VTY is able to trigger certain IPACC functions for debug purposes. Some of those commands do not check if the BTS is really of type IP-access before trying to send an IPACC command. Let's add checks to prevent IPACC messages to be sent to E1 or otherwise incompatible BTSs models. Change-Id: I9ee78b6b1d342abaccc09a87dee6af79e76e5468 Related: OS#2547
2020-06-29abis_rsl: Mobile Allocation IE in CHANnel ACTIVation shall be emptyVadim Yanitskiy1-5/+4
According to 3GPP TS 48.058 (version 15.0.0), section 9.3.5, the 3GPP TS 24.008 "Mobile Allocation" shall for compatibility reasons be included but empty, i.e. the length shall be zero. Therefore, no matter if frequency hopping is in use or not, send it empty. Change-Id: Ie224a45f10522332eac653fa371564f022108c3f Related: OS#4545, OS#4546
2020-06-24lchan_rtp_fsm: fix out_state_maskPhilipp Maier1-0/+1
In the state LCHAN_RTP_ST_WAIT_MGW_ENDPOINT_CONFIGURED, the event LCHAN_RTP_EV_ROLLBACK is allowed and also handled in the action callback, which causes a change to LCHAN_RTP_ST_ROLLBACK. However, LCHAN_RTP_ST_ROLLBACK is missing from the out_state_mask. Change-Id: Ifca3892901c8389beee6e4f0fea03c33cfbdc265
2020-06-24osmo-bsc.spec.in: Use %config(noreplace) to retain current config fileHarald Welte1-1/+1
Change-Id: Icba90f52c40860262de9a4d5aebd418ddafde8d8
2020-06-24vty/bts_resend_cmd: Use gsm_bts_set_system_infos() to increment changemarkHarald Welte1-3/+1
We assume the SI shall be re-sent because something has changed. This means that change_mark should be incremented. Let's call gsm_bts_set_system_infos() which already does the trick. Change-Id: I73d9bd3cddc561f3a7af8bcc225fac126dca3f78 Closes: OS#3679
2020-06-24fix segfault introduced by recent segfault fixNeels Hofmeyr1-9/+12
This recently merged patch introduced a new bad segfault in bsc_compl_l3() by dereferencing conn->sccp.msc before it was set to the actual msc pointer: commit 6281d4f8692729dc0022ea7a6a2068972d58e9b6 "fix crashes due to OSMO_ASSERT(conn->lchan)" Change-Id Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1 Fix that by moving the new checks back further down in bsc_compl_l3(), to where conn->sccp.msc actually points at the msc. Change-Id: Ic5832da7c58fce583caa504a90f18c334fc234f2
2020-06-23Avoid selecting channels from administratively locked trxPau Espin Pedrol4-8/+11
Found while playing with "rf_locked 1" on a 2TRX setup with channel allocator descend. After applying the setting, the 1st TRX is still used to allocate the channels. After this patch is applied, the BSC correctly allocates channels from TRX0. Change-Id: I5201d2749363c9cbd0706177bde09117b163cbe3
2020-06-23fix crashes due to OSMO_ASSERT(conn->lchan)Vadim Yanitskiy9-25/+72
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed that osmo-bsc crashes with the following message: Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376 The cause of this is a recently merged patch that calls conn_get_bts() during assignment_fsm rate counter dispatch: "Count assignment rates per BTS as well" commit b5ccf09fc4042c7fb1fdaaa6263961c40b32564e Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a The root cause being that the assignment_fsm attempts to count an Assignment event for a BTS after the lchan has already been released and disassociated from the conn. The assertion is found in conn_get_bts(), which is used in various places. In fact, each caller is a potential DoS risk -- though most are in code paths that are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the relatively volatile presence of an lchan is not a good idea for osmo-bsc's stability and error resilience. - Change conn_get_bts() to return NULL in the lack of an lchan. - Adjust all callers of conn_get_bts() to gracefully handle a NULL return val. - Same for cgi_for_msc() and callers, closely related. Here is a backtrace: Program received signal SIGABRT pwndbg> bt 0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376 0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758 0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325 0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257 0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260 0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291 0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953 0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6 0x0000555555b61bbe in _start () In the case of the assignment_fsm counter, we now miss a chance to increase a BTS counter for a failed Assignment, but this is a separate problem. The main point of this patch is that osmo-bsc must not crash. Related: OS#4620, OS#4619 Patch-by: fixeria Tweaked-by: neels Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
2020-06-21system_information: Set BSS_PAGING_COORDINATION in SI13 for osmo-btsHarald Welte2-0/+6
osmo-bts (in combination with osmo-pcu) has been supporting paging for CS services via PCU/PACCH for a very long time. Let's make sure this is reflected by the correct BSS_PAGING_COORDINATION bit. Change-Id: I0e80ca5afc06737273b6699bde6e325e454b57f6 Requires: libosmocore.git Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38 Related: OS#2406
2020-06-21vty: hide 'mscpool roundrobin next'Neels Hofmeyr1-7/+7
The 'mscpool roundrobin next' command is intended for use only by ttcn3 tests. Hide it. Change-Id: Ie8799b61b74cfb34acd5aa4aeb1fb69ae7d216e2
2020-06-21Count RSL DELETE INDICATION received from BTSHarald Welte2-2/+5
If the BTS downlink CCCH (PCH + AGCH) queue is full, it sends us an RSL DELETE INDICATION. So far, osmo-bsc logs this as <0004> abis_rsl.c:2026 Unimplemented Abis RSL TRX message type 0x14 which is not very helpful. Instead, make the log message more descriptive and add a rate counter for monitoring. Change-Id: I9bd2966db90e39ccca442d6bc9abc91e9a9147d4 Closes: OS#3190
2020-06-21bs11_config: Print "Not Equipped" for MBCCU (TRX) that don't existHarald Welte1-0/+1
Particularly on BS-11 with only one TRX installed, this will improve the output of bs11_config from PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: unknown 0x8 Abis-link: Down to Change-Id: I10a77315d537681985f8390b838a4cabfb7d27f3 PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: Not equipped Abis-link: Down
2020-06-21[cosmetic] system_information: Values are not guesses; more commentsHarald Welte1-3/+2
Change-Id: I978fbcd0c82658444b7603b082c236d23b0fa04b
2020-06-19merge files: absorb osmo_bsc_vty.c into bsc_vty.cNeels Hofmeyr4-1033/+976
For historical reasons we had bsc_vty.c and osmo_bsc_vty.c. Ever since the osmo-nitb split, there is no reason to keep these files separate. Merge osmo_bsc_vty.c into bsc_vty.c (because osmo_bsc_vty.c is smaller). I noticed this particularly because adding the NRI configuration required adding things like #define NRI_STR in two separate files: once for the 'network' level vty, and once for the 'msc' level. Change-Id: I7fd2ee631b22e38f3d96d8159dc1deaaca6a7013
2020-06-19bsc: Allow setting negative nominal tx power through VTYPau Espin Pedrol1-1/+1
Some SDRs may provide tx power below 0 dBm on some bands. Related: OS#4583 Change-Id: Ia53c303d1bea23e219de42e1242cb8a5b357a2ae
2020-06-18abis_nm: fix length indicator in Set Channel AttributesVadim Yanitskiy1-5/+6
This message may contain optional IEs (HSN, MAIO, ARFCN list), so we cannot know the final length in advance. Let's set both msg->{l2h,l3h} pointers and use msgb_l3len() to get the length. Change-Id: I948ad4b847921324794a6eabd95d5583324da6e4 Related: OS#4545
2020-06-18abis_nm: fix ARFCN list encoding in Set Channel AttributesVadim Yanitskiy1-11/+28
3GPP TS 12.21 defines coding of 'ARFCN List' attribute as follows: +---------------------------+--------------------+ | Attribute Identifier | 1st octet | +---------------------------+--------------------+ | Length | 2-3 octets | +---------------------------+--------------------+ | ARFCN1 | 4-5 octets | +---------------------------+--------------------+ | ... | ... | +---------------------------+--------------------+ | ARFCNn | (n * 2 - 3) octets | +---------------------------+--------------------+ so this is basically TL16V, where L16 is the length of V. In the Siemens dialect of OML coding rules are different though: +---------------------------+--------------------+ | Attribute Identifier | 1st octet | +---------------------------+--------------------+ | ARFCN count | 2nd octet | +---------------------------+--------------------+ | ARFCN1 | 4-5 octets | +---------------------------+--------------------+ | ... | ... | +---------------------------+--------------------+ | ARFCNn | (n * 2 - 2) octets | +---------------------------+--------------------+ so this is TCV, where C is the amount of ARFCNs in V. This change fixes encoding of 'ARFCN List' for other dialects, in particular encoding of the 'Length' field (1 vs 2 octets). I verified the results in Wireshark (generic 3GPP TS 12.21 and ip.access dialect), everything looks good. Change-Id: Iec1826f55459ac8e9355328a1a6bb0949874db60 Related: OS#4545
2020-06-17MSC pooling: add rate countersNeels Hofmeyr4-1/+67
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f (osmo-ttcn3-hacks). Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
2020-06-17debug: log about matching Paging Response to earlier PagingNeels Hofmeyr1-1/+8
Change-Id: I277d3236686dd5a5a21113ef2ddfd29341190086
2020-06-17log: add MSC number to bsc_subscr_conn_fsm idNeels Hofmeyr1-1/+4
Change-Id: Iae232d0616d6c0009e3abe2dcfcb9c51ddfc761e
2020-06-17vty: add 'mscpool roundrobin next' for ttcn3 testsNeels Hofmeyr1-0/+13
In the ttcn3 tests, the MSC round robin algorithm is affected by what tests ran before, so an osmo-bsc test needs this to reset the round robin to get predictable behavior to test against. Change-Id: I2155d906505a26744966f442ffb1e87a6a9b494c
2020-06-17mscpool: add user manual chapterNeels Hofmeyr2-0/+215
Change-Id: Ia60afc8a91189c9de0d8e8065781ed463bf18d7e
2020-06-17MSC pooling: add 'no allow-attach' for MSC off-loadingNeels Hofmeyr5-1/+55
As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid attaching new subscribers to it: 4.5a.1: "UEs being moved from one CN node are stopped from registering to the same CN node again by an O&M command in BSCs and RNCs connected to the pool." Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
2020-06-17MSC pooling: LU: ignore TMSI NRI from a different PLMNNeels Hofmeyr1-0/+49
Change-Id: Iac1158cff022b6365ce22bb70feaaff93e39172a
2020-06-17MSC pooling: implement NAS node selection by NRI from TMSINeels Hofmeyr1-3/+42
If applicable, choose MSC from NRI, extracted from TMSI MI. Change-Id: Ifbdea197b26e88751a391c8a80c41f04e7d5e047
2020-06-17MSC pooling: make NRI mappings VTY configurableNeels Hofmeyr7-1/+367
Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-06-16tweak log category for Compl L3 errorNeels Hofmeyr1-1/+1
At this time, no MSC has been selected for handling this subscriber, so DMSC is clearly the wrong logging category. Change-Id: I9c6373e5f28c9c69a0609889188ef28ade11da3d
2020-06-16use osmo_mobile_identity API everywhereNeels Hofmeyr7-53/+64
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore) Change-Id: I71c3b4c65dbfdfa51409e09d4868aea83225338a
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-21 10:02:44 +0000