Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
Change-Id: If750003beb8653cf67fd192fa5c16343138155c9
|
|
Change-Id: I95f3a89af16e4a6b4aa1a6a48cf0d0c023f26170
|
|
Change-Id: Idc7a9ed558ed6897e15a0f6d3c23418db7cee0d0
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Change-Id: Icba90f52c40860262de9a4d5aebd418ddafde8d8
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
The 'mscpool roundrobin next' command is intended for use only by ttcn3 tests.
Hide it.
Change-Id: Ie8799b61b74cfb34acd5aa4aeb1fb69ae7d216e2
|
|
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
|
|
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
|
|
Change-Id: I978fbcd0c82658444b7603b082c236d23b0fa04b
|
|
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
|
|
Some SDRs may provide tx power below 0 dBm on some bands.
Related: OS#4583
Change-Id: Ia53c303d1bea23e219de42e1242cb8a5b357a2ae
|
|
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
|
|
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
|
|
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f
(osmo-ttcn3-hacks).
Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
|
|
Change-Id: I277d3236686dd5a5a21113ef2ddfd29341190086
|
|
Change-Id: Iae232d0616d6c0009e3abe2dcfcb9c51ddfc761e
|
|
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
|
|
Change-Id: Ia60afc8a91189c9de0d8e8065781ed463bf18d7e
|
|
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
|
|
Change-Id: Iac1158cff022b6365ce22bb70feaaff93e39172a
|
|
If applicable, choose MSC from NRI, extracted from TMSI MI.
Change-Id: Ifbdea197b26e88751a391c8a80c41f04e7d5e047
|
|
Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY
configuration.
Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
|
|
At this time, no MSC has been selected for handling this subscriber, so DMSC is
clearly the wrong logging category.
Change-Id: I9c6373e5f28c9c69a0609889188ef28ade11da3d
|
|
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: I71c3b4c65dbfdfa51409e09d4868aea83225338a
|
|
Use the new osmo_mobile_identity API to shed some code dup and simplify.
gsm48_paging_extract_mi() is now unused, drop.
(More refactoring to use osmo_mobile_identity follows in subsequent patch.)
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: Id6cccaac64392b737b3bba8f3a22a88009adb23b
|
|
Change-Id: I7c3432790a77ae9081d2c458ee9f598e435e089d
|
|
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built
before the docs.
Remove bsc_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-bsc --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: I5dc872149154e1a949bb6a2b9bbc1461e0fc51f6
|
|
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I316efedb2c1652791434ecf14a1e261367cd2fb7
|
|
This adds the assignment counters for the BTS as well and changes the
assignment_count() macro to increase both the counters for the BSC as
well as the BTS.
Related: SYS#4877
Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
|
|
Ticket: SYS#4877
Change-Id: I5c51956569223e802f4789dc5ed1605d18f80aea
|
|
Change-Id: I045cef207603074bd018e40f984263d03db31405
|
|
Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC
matching, fix the bsc_find_msc() implementation.
(Indicate the places relevant for NRI by "TODO" comments).
bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was
used. This has problems:
- Modifying the list affects VTY output, e.g. 'show running-config' and
'show mscs' change their order in which MSCs are shown, depending on how
often a round-robin selection has taken place.
- Emergency calls and normal calls potentially pick quite different sets of
eligible MSCs. When the round-robin choices between these sets affect each
other, the choice is not balanced. For example, if only the first MSC is
allow_emerg == true, every emergency call would reset the round-robin state
to the first MSC in the list, also for normal calls. If there are regular
emergency calls, normal calls will then tend to load more onto the first few
MSCs after those picked for emergency calls.
Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead,
keep a "next_nr" MSC index and determine the next round-robin target like that.
Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin
does no longer cause normal round-robin to skip MSCs.
Further problems in current bsc_find_msc():
- The "blind:" label should also do round-robin.
- The "paging:" part should not attempt to use disconnected MSCs.
- Both should also heed NRI matches (when they are added).
Fix: instead of code dup, determine Paging Response matching with an earlier
Paging Request right at the start. If that yields no usable MSC, continue into
the normal NRI and round-robin selection.
The loop in this patch is inspired by the upcoming implementation of MSC
pooling by NRI, as indicated by the two TODO comments. The point is that, in
the presence of an NRI from a TMSI identity, we always need to iterate all of
the MSCs to find possible NRI matches. The two round-robin sets (Emergency and
non-Emergency) are determined in the same loop iteration for cases that have no
or match no NRI, or where a matching MSC is currently disconnected.
Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
|
|
Change-Id: Ic29f3a7e6fb16955bc74cc163d45a243b373183a
|
|
Testing these functions is actually done in libosmocore. Also, with new
osmo_mobile_identity API, the functions being tested are marked deprecated. So
drop the test.
BTW, the test contained an IMSI of 16 digits, which is too long, yet was
expected to succeed. GSM23003_IMSI_MAX_DIGITS == 15. I first considered fixing
the test data, but the test is in the wrong place here anyway.
Change-Id: I902d31ecd72d71892fad7945f695a9f1fb403bf2
|
|
Change-Id: Ife25ed26214abf7aea95b0b7943d9fa585868529
|
|
Change-Id: Id752d3882645708b5b8e1058b6799d3d285286c4
|
|
Depends: I9ecbab16b45268f626950303d6ff8296dd6acda0 (libosmo-sccp)
Change-Id: I6a2710edeb9ba047ae70e6b49d4c2e5f06d41a4e
|
|
Change-Id: I264ba6a72ea93297cfbc99602eccfbf4a890f703
|
|
The value of the feature vector can not only be greater, but also
shorter than size of the buffer! This would potentially result
in a buffer overrun. Let's fix this.
Change-Id: I65e3228022865ea73de2e4821985df3097b9448b
|
|
Change-Id: I14be343578a64c1e4ce8ce4d28da9008eb309f3c
|
|
Change-Id: I74fbb46920c74a194c296feeeb1bb086fcbd572f
|