The A-bis/IP RTP CSD Format IR Values need to be shifted by 4 bits
instead of 5. See OsmoBTS Abis Protocol Specification § 5.8.14
RSL_IE_IPAC_RTP_CSD_FORMAT.
Related: https://ftp.osmocom.org/docs/osmo-bts/master/osmobts-abis.pdf
Related: OS#4393
Change-Id: I9ce0b2d9b77eef61a6d4dce417efe4e853217dc5
EUTRAN neighbors can be deleted using the following command:
$ osmo_ctrl.py \
-d 127.0.0.1 -p 4249 \
-s "bts.0.si2quater-neighbor-list.del.earfcn" EARFCN
UTRAN neighbors can be deleted using the following command:
$ osmo_ctrl.py \
-d 127.0.0.1 -p 4249 \
-s "bts.0.si2quater-neighbor-list.del.uarfcn" UARFCN,SCRAMBLE
This commit implements only deletion, implementing the add command
would require slightly more effort (lots of manual string parsing),
so it's left as a TODO for later.
Change-Id: I890bffb003f2a0ee9438f6ea6e8067c092504f08
Related: SYS#6401
The BTS can immediatelly ACK the OPSTART, but that doesn't mean the TS
is already usable. It should only be used when the BTS reports it is in
Enabled state.
Related: OS#5973
Change-Id: I712aa22252d29ceea152c25a5da75542e1691faf
We don't want to have duplicate EARFCNs in the config file.
The desired behavior is modifying existing EARFCNs.
Change-Id: Ia2fd8bd86d9f093967c1b0b0135151d2d5386dc1
Related: SYS#6401
This way we print the proper message if the given UARFCN is already
added, no matter if the UTRAN neighbour list is full or not.
Change-Id: Ife83023f6a9e28d77e44e4757457d4d1c879e78f
Related: SYS#6401
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.
Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: I3a8418fb5841c71049ec91439143e1fe5553ed40
NSVC local port 0 is actually a valid value, which tells the PCU to
pick a random port for bind()ing. It was supported before 315af2f9e,
but now osmo-bsc would simply ignore NSVCs with 'local udp port 0'
and leave the respective MOs unconfigured in the BTS.
Change-Id: I0afd83e77f3daeeb082e7db911610428b5bc587c
Fixes: 315af2f9e "bts: ipa/osmo-bts/sysmobts: MO: add support for the second NSVC"
Related: OS#5979
The signal is already there but not being used.
Let's further split generic paging code from RSL specificites.
Change-Id: Iabc1c29908a5136501d6dc6e60f8777dab511b86
vty_read_config() returns an errno number or zero; add the appropriate error string in case of error
Change-Id: I0015824a29ebf8aaeaa996ab4d2cb2769ea48864
The old ones have been deprecated and shall not be used anymore·
Depends: libosmocore.git Change-Id I799e35dc8d4d153fa63bf50563a5482cdf4de2d7
Change-Id: Id3be8e38ec87ae39c4e1b4fab163563b24fb2cee
User reports a SEGV:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 send_assignment_complete (conn=conn@entry=0x557dbabb75a0) at assignment_fsm.c:188
#1 0x0000557db66aa6b0 in assignment_success (conn=0x557dbabb75a0) at assignment_fsm.c:277
#2 0x00007f6007afee82 in _osmo_fsm_inst_dispatch (fi=0x557db9615b80, event=4, data=0x0, file=0x7f6007a7dc21 "mgcp_client_endpoint_fsm.c", line=513) at fsm.c:875
#3 0x00007f6007a78c12 in ?? () from /lib/x86_64-linux-gnu/libosmo-mgcp-client.so.9
version: osmo-bsc 1.9.0.111.fc339.202212220009
The situation apparently is conn->lchan == NULL (primary lchan is gone),
but Assignment has just concluded. Apparently an unexpected / orthogonal
event has interrupted operations.
During assignment_success(), do not assume that conn->lchan is still
present. This should normally be true, but if not, fail the assignment
procedure instead of crashing osmo-bsc.
Related: SYS#6382
Change-Id: I4db25d0458f620954a1ca345282f5d8316341919
Do this by setting the minimal value for T3105 to 1 in its timer definition.
Fixes: Coverity scan CID#307389
Change-Id: I1fd0b92ab507a58fed6e9649eaa4770f1ad1cbad
The current PCU implementation has never been tested with multiple BTS
attached to it. This is due to the fact that it has been used
exclusively in an BTS co-located setup where naturally only one BTS is
present. The PCU sock protocol supports multiple BTSs in theory and we
should handle this correctly.
Related: OS#5198
Change-Id: I0b42c2c130106f6ffca2dd08d079e1a7bda41f0b
The flag PCU_IF_FLAG_DT is no longer needed. The PCU implementation will
distinguish by the version number instead.
Change-Id: I0dc20e351deb14906b2edffc39499bad9659cc35
Related: OS#5198
When updating the BTS information in the bsc co-located PCU, first check
if the BTS has a BSC co-located PCU at all. Also check if the BTS is E1
based since those type of BTS require extra information about the E1
connection.
Related: OS#5198
Change-Id: I8da26debc0e27f24fae4ee88f22f8875de13bc84
At the momemnt we use is_ericsson_bts() to check if the BTS uses a BSC
co-located PCU, this is a bit ambiguous, lets have a function that
explicitly checks for a BSC co-located PCU and nothing else.
Change-Id: I23ed4219e5ebd188867c17f387ca877efa9bc3b0
Related: OS#5198
Since there were complaints about this old parsing code during recent
code review in Ifdc9e04bf1d623da65bfb8a2fddea765601f6d9b, and now also
coverity finds something odd in it, just rewrite this.
Related: CID#310912
Change-Id: I96cd5d88ec6808a2915c6bccd0c0140216f328f2
In osmo-bsc, there's currently 0..1 Lb links and 0..N A links, where N
is the number of MSC, but links can be shared in the underlaying stack
(struct osmo_sccp_instance), hence range 0..N of different
osmo_sccp_instance (identified by PC).
Even more, the Lb and A link can share the same underlaying stack, so
osmo-bsc can end up with only 1 struct osmo_sccp_instance shared by all
the above mentioned links in case all are configured under the same PC.
Total range A+Lb is 0..(1+N).
A struct gsm_subscriber_conn stores 2 struct sccp_instance*, one for
Lb (conn->lcs.lb.*)and one for A (conn->sccp.*).
They can actually point to the same sccp_instance or to different ones,
as explained above, depending on the configured setup. In any case, a
gsm_subscriber_conn needs 2 rb_nodes since it can hold
any of the 2 conn_ids independently (A or Lb).
The previous patch forgot to add that 2nd rb_node as well as some
initialization and release code for the Lb conn. This patch addresses
that.
When the 2nd rb_node, a problem when iterating the rbtree appears: how to
find out the "conn" pointer from the rb_node pointer, since the rb_node pointer
can be any of the 2 rb_nodes inside the struct at a different offsets.
In order to solve that problem, a new struct bscp_sccp_conn_node is
added, which holds all the relevant information used by the rbtree lookup code
in a generic way (rb_node and conn_id), plus a backpointer to the struct
bsc_gsm_subcriber it relates too.
Fixes: 85062ccad3
Change-Id: If42d93adee71d646766929a09bc01ae92b734ef3
Calling talloc_free() on struct llist_head is wrong and will lead
to unexpected behavior. Call it on the containing struct instead.
Change-Id: Ib5eaa328aaf6881ae9621ca14859e4e255af2b00
It was found that on a busy osmo-bsc process (>1000 concurrent calls
spead over different BTSs), a good amount of time is spent iterating the
subscribers list trying to find a subscriber based on a TMSI (1.60% of
total CPU time used by osmo-bsc).
This patch introduces a new rbtree under struct bsc_subscr_store which
allows storing all the busbs ordered by TMSI.
This way, lookup time changes O(N) -> O(log(N)), at the expense of
increased insert/deletion time O(1) -> O(log(N)).
Related: SYS#6200
Change-Id: If27429e715ef4b327177e427249e68321a6e83cc
This allows keeping the bsc_subscriber storage internals outside of main
gsm_network code, while easily allowing making the internal
implementation more complex (in order to optimize it in a follow-up
commit).
It is also nice since we get rid of uncommon procedures being used in
this code, like allocating an llist directly as a talloc context, etc.
Change-Id: I616e8872af4ac63a6985f8900909e324ba889192
The function was currently in osmo_bsc_sigtran.c but was never used
there, and it really doesn't have any relation to that file.
Let's move it to the only place where it's used so far, and mark it as
static.
Change-Id: I8a8cef45aa378421e0ac328d3b29b9d194698a55
It was found that, on a busy osmo-bsc (>1000 concurrent calls spread over
several BTS), the CPU consumption looking up for gsm_subscriber_conn
based on SCCP conn_id can take a considerable amount of time (>5% of
osmo-bsc already taking 70% of the CPU time on the core it is running on).
The huge CPU consumption happens because a linear search is done (llist)
over the entire list of SCCP connections every time an SCCP message is
handled.
In order to optimize this lookup, this patch introduces a new struct
bsc_sccp_inst which becomes associated to the libosmo-sccp
osmo_sccp_instance. Each of this strucs maintains an rbtree of
gsm_subscriber_conn ordered by conn_id.
As a result algorithmic complexity adds O(log(N)) during insert, lookup
and delete of SCCP conns, but gets rid of O(N) previous lookup.
As a plus, finding a new conn_id now takes generally O(log(N)), while
before it used to take O(N).
Related: SYS#6200
Change-Id: I667d3ec1dad0ab7bc0fa4799d9611f3a914d07e5
Refactor the double loop to check a code path matching the sccp_instance
once instead of doing so for every subscr_conn.
If for instance let's say we have 1000 concurrent calls in progress,
which means we have 1000 subscr_conn, which means we at least do the
extra check regarding SMLC vs MSC 1000 times (at least, xN times if N
conn_id already used are already found).
That overhead happens every time a new subscr_conn is created (which in
a BSC with already 1000 concurrent calls can potentially happen quite
frequently).
Change-Id: Ic32b1eeb201fc51110e1ee130110824845f81e82
Function bsc_sccp_inst_next_conn_id() allocating conn_id creates address
spaces based on sccp_instance, aka conn_id values can be reused given
the sccp_instance (MSC) is different.
Hence, when looking up a bsc_conn based on a conn_id, it must also match
the sccp_instance, otherwise a bsc_conn from another MSC could be
returned.
Change-Id: I80a54bdec3973917e88483a62bfc2e968b8c0490
The 0x00FFFFFF source local reference is reserved in M3UA/SCCP, hence
avoid allocating a conn_id with that value since later on when reused as
a source local reference it would fail to be encoded.
Change-Id: I5c62bbfa89140d754edccb4404503cb70d5fde89
Currently, the conn_id is allocated in a range 0..0xffffff by
bsc_sccp_inst_next_conn_id(), and -1 means it is unset.
This means allocation expects "int" to be at least 32 bits integer,
in order to fit 24 bits for 0..0xffffff plus the -1.
Hence, let's define the variable as uint32_t, as already done in
libosmo-sccp. Use last value 0xFFFFFFFF ((uint32_t)-1) and avoid playing
with the value being unsigned sometimes and signed only for "unset"
value.
The value is actually already handled as unsigned (printed with %u) in
most places.
Change-Id: If019bcbc1e28929fe8d981fef9103835fc6ead2e
It's possible that a BTS gets disconnected, updated to a more recent
version or downgraded to an older version, and then connects to the
BSC again. That more recent or older BTS version may have a different
set of supported features, so osmo-bsc must not trust the previously
reported feature vector.
Change-Id: Ie93af849d7771b4fff3cdf647c82510cd8543975
All non ericsson BTSs we support use a BTS co-located PCU, so we must
not depend on a PCU connection in those cases.
Related: OS#5943
Fixes: ecf825dc ("pcu_sock: activate/deactivate PDCH on pcu reconnect")
Change-Id: I296dfacb451d7b9b5ef1cec940bc1a577f3c43ad
The variable rc holds the return code of accept(), which returns a file
descriptor on success. So lets call the variable "fd" to make this
clear.
Change-Id: Ic8d22c2af18477f110a3a9115434314ebca95b25
When the IMMEDIATE ASSIGNMENT is sent from the PCU to the BSC using the
"direct TLLI" method, the TLLI (and the last three digits of the IMSI)
is prepended to the MAC block. Currently we are taking the fields apart
manually using offsets. The code for this is difficult to read and the
method is error prone. Let's define a struct that we can just overlay
to access the fields directly. Let's also transfer the full IMSI.
Change-Id: Id6acbd243adf26169e5e8319dd66bb68dd6a3c22
Related: OS#5198
When the PCU is disconnected while the BSC keeps running the PDCH should
be closed. Also the PDCH should be reopened when the PCU is
reconnected.
Change-Id: I9ea0c53a5e68a51c781ef43bae71f947cdb95678
Related: OS#5198
When a data request is received from the PCU, some of the switch cases
allocate a message buffer but the message buffer is only used to pass
its data and length to other functions. The message buffer itself is not
passed anywhere and it is also not freed. Lets get rid of the message
buffer and avoid unnecessary memcopy calls.
Related: OS#5198
Change-Id: Ibfaae177585a4d42d797b6bbd90e402641620140
Omit the A-bis/IP specific RSL_IE_IPAC_SPEECH_MODE, as it doesn't make
sense for circuit switched data.
Related: OS#4393
Change-Id: I6641b713177276bcf798f08123e1dd2e88ffdce6
Use the full gsm0808_chan_indicator value throughout the lchan related
structs (assignment_fsm_data, gsm_lchan, lchan_activate_info,
lchan_modify_info) instead of reducing it to the boolean
requires_voice_stream.
This is needed so we don't lose the information whether an lchan was
requested for data or speech (both need an rtp stream).
Add a new bsc_chan_ind_requires_rtp_stream function and use it in
conditionals like the previous requires_voice_stream.
Related: OS#4393
Change-Id: I1538c1e6d5cd61559af7c1e2860afd0269dda367
Replace check_requires_voice_stream, which used to iterate over
ch_mode_rate_list and verify that all entries are either for speech or
signalling. Instead verify in check_chan_mode_rate_against_ch_indctr,
that all entries of ch_mode_rate_list have a chan_mode that matches the
ch_indctr (data, speech, signalling; called "speech / data indicator" in
3GPP TS 48.008 § 3.2.2.11).
This ensures that all of them are either data, speech or signalling and
not mixed.
Related: OS#4393
Change-Id: Iee5cbfee84d7f2ad59ee2d5a19891a2b59bbafff
Remove "speech mode" from the log message, as the log message is
relevant for CSD too. According to 3GPP TS 48.008 § 3.2.1.1 note 13 the
IE shall be included for AoIP unless channel type is signalling.
Related: OS#4393
Change-Id: Idfab0b7f6e97a6b67d140f967ddfe9b29818586e
Handle assignment requests for CSD. In this initial version, the code
for non-transparent data mode is a stub.
Related: OS#5763
Depends: libosmocore Ia965cdd9f53af756e5ffaff9b8f389b5ad629969
Change-Id: I350bea15fd2158eb6edc9bc92f2dca48930736e9
It looks like the idea was to translate the CSD rate from BSSAP to
lchan_csd_mode before translating it to RSL. But instead we can just
directly translate the BSSAP value to the RSL value.
The previous code was not used yet (nothing wrote to csd_mode).
Related: OS#4393
Depends: libosmocore I25bfd02aa1428a35492b20376a31635a442e545f
Change-Id: Ice914744da3a2084e82d125848fb69404b8e8a36
gsm_pchan_ids[] exists only to compose osmo_fsm compliant IDs. We do
have osmo_fsm_inst_update_id_f_sanitize() now, rather use that.
This removes some confusion about which value_string array has an effect
on the VTY command 'ts' / 'phys_chan_config'.
Note that tests/bsc_test.ok does not change, hence the new way of
composing FSM IDs is identical to using the old gsm_pchan_ids[].
Change-Id: Ib85b7aa4ea882ae37919dd3ea0c033e949c083e5
This patch affects *only* on osmo_fsm instance IDs, which are visible on
the CTRL and VTY interfaces to identify FSM instances, and in the log.
Why bother: An upcoming patch wants to replace gsm_pchan_ids[] with
osmo_fsm_inst_update_id_f_sanitize(gsm_pchan_name(x)), this is an
explicit step to match gsm_pchan_names[].
Change-Id: I4a540744cced466f0ca4fc605db4d0ec14ee8e87
Show the timeslot_fsm, lchan_fsm, assignment_fsm fi->id strings.
The IDs include the current pchan configuration. I want to tweak the
composition of these in an upcoming patch, so the test should show
whether any FSM IDs change from that.
Change-Id: If369f23fa140b9d7792f5a511815cbbd14b371e9
Change names of stat exports to be consistent with VTY,CTRL:
- from "chan_osmo_dyn" to "chan_dynamic_osmocom"
- from "chan_tch_f_pdch" to "chan_dynamic_ipaccess"
Change-Id: I863ad05e892563442041722bcd57f7c987e1f5ab
We already use "OSMO_DYN" as C name for "fully dynamic" timeslot config,
when working with osmo-bsc.cfg I dearly miss this short name, it is a
pain / has become ridiculous to write 'tch/f_tch/h_sdcch8_pdch'.
Introduce 'dynamic/osmocom' and 'dynamic/ipaccess' as default names for
our dynamic timeslots on VTY and CTRL. The old 'tch/f_tch/h_sdcch8_pdch'
and 'tch/f_pdch' are still supported.
Change-Id: I37719edd867c777d1ce944b8e2f1efffac38f00e
Add a static assert, and comments indicating the importance of the two
value_string arrays defining pchans on the VTY matching up.
Change-Id: I8118bec35400f7f00ca9ae43b603059ed701fa25
I'm going to add a regression test that probes lchan_fsm. I noticed that
I have to call lchan_fsm_init() for osmo_fsm_register(). Let's make this
implicit as we usually do now, to not have to register FSMs in tests.
Change-Id: I58760e743c78a370aedc9720f265c0f8da5c2045
The length parameter in rsl_imm_assign_cmd_common() may cause a buffer
overflow when it is chosen larger than GSM_MACBLOCK_LEN. Lets make sure
this cannot happen.
Change-Id: I9417b35fb8c0517f2555e17059bf8ac60fa59791
Comparing an array to null is not useful, since the test will
always evaluate as true (NO_EFFECT).
Change-Id: I8a41078070119bc22d594c0dfff5d98b5d16f970
Fixes: fbead4327 utils: store more fields from meas-feed in db
Fixes: CID#310821
The PCU is able to send OML alerts via the BTS to the BSC. When the PCU
operates in co-location to the BSC we just print the alerts in the log
directly
Change-Id: Id32553556356c2affe32e47ae1c3ae6a514efdce
Related: OS#5198
Move the check for the rate into an extra function, so it can be used
for CSD without checking a speech codec at the same time.
Related: OS#4393
Change-Id: Iea8a23ef3c66ed556110038fe9f3bc7f6eef3e96
Move the translation from osmo_sockaddr_to_str_and_uint into
bssmap_handle_ass_req_tp_rtp_addr, which will be used by
bssmap_handle_ass_req_ct_data in a future patch too.
Pass pointers to variables in req, instead of duplicating variables and
filling it in later (like in bssmap_handle_ass_req_ct_sign).
Related: OS#4393
Change-Id: I6bb16b26d89056dffa50bd8296fefe9315c587ca
Allow reusing common code in an upcoming bssmap_handle_ass_req_ct_data.
It won't use _osmux for now (maybe in the future?), but splitting it
out as well makes it consistent.
Related: OS#4393
Change-Id: I4d9a4df314b1e56b9c1f90c9d7914332b70b56f8
More fields need to be captured from meas-feed
to perform meaningful analysis of data from
multi-bts and multi-trx systems.
This patch adds expands the existing db utils
to record nearly all available fields from
meas-feed.
Change-Id: I509c939524b11a4ee455bcfc3ebee6c5c35b9fba
Remove "Helper function for match_codec_pref()" at the beginning of the
descriptions of these functions, looks like a leftover from before this
was moved to its own c file. Remove a duplicated "received" in a
comment.
Change-Id: I30f0744db9aebf2f05077fef840097c332b9dafd
tall_ctr_ctx is not defined or used in osmo-bsc and apparently was only
exported by accident from libosmocore. It's not exported anymore since
libosmocore.map was introduced in I13169c00a59fb59513dfc598de5a71d094492422.
Fix for:
/usr/bin/ld: osmo_bsc_main.o: in function `main':
osmo_bsc_main.c:(.text+0x830d): undefined reference to `tall_ctr_ctx'
/usr/bin/ld: osmo_bsc_main.c:(.text+0x8331): undefined reference to `tall_ctr_ctx'
Change-Id: I558e1ec722f3b1ff1f2e89b3cb97ed1dba9063e3
T23042 was a placeholder for timers to be filled in later. Replace it
with timers that can be configured via VTY.
Previous timeout for the states was 5s, from using the default of 5 for
undefined timers.
* ASSIGNMENT_ST_WAIT_MGW_ENDPOINT_TO_MSC and
HO_ST_WAIT_MGW_ENDPOINT_TO_MSC:
* Runs gscon_connect_mgw_to_msc() on enter, which waits for one MGCP
CRCX or MDCX response (or changes state immediately)
* Use existing X9 ("Timeout for availability of MGW endpoint"), 5s,
which is already being used by lchan_rtp_fsm for a similar purpose
* HO_ST_WAIT_RR_HO_DETECT:
* Handover initiation as described in 3GPP TS 04.08 § 3.4.4.1:
"The network initiates the handover procedure by sending a HANDOVER
COMMAND message to the mobile station on the main DCCH. It then
starts timer T3103."
* Use existing but unused timer T3103 ("Handover"), 5s
* HO_ST_WAIT_RR_HO_COMPLETE:
* Handover completion as described in 3GPP TS 04.08 § 3.4.4.3:
"When receiving the HANDOVER COMPLETE message, the network stops
timer T3103 and releases the old channels."
* Continue using T3103 with keep_timer = true
Closes: OS#5787
Change-Id: Id0d4d0788f609f3272fc81c80a754383dde25c16
Remove placeholder timer T23042. This handover fsm state waits for both
RSL/RR and RTP/MGW to be complete. I've added TTCN-3 tests to ensure
that both cases are covered by existing timer T3101 in lchan fsm state
LCHAN_ST_WAIT_RLL_RTP_ESTABLISH, which on timeout lets the handover
fail.
Related: OS#5787
Related: osmo-ttcn3-hacks I30e1811f97406cff6ba794fcd6882e2bb0205087
Related: osmo-ttcn3-hacks I2f79e3ff988a4315fbef3538f02403b818fa7839
Change-Id: I53468766c3c5fad7d7e275c0f20b5c20677fe4e8
Remove placeholder timer T23042.
Neels wrote:
> I think the right thing here is to remove this timeout; this needs
> no timeout at all because we can rely on the lchan_fsm to either
> return HO_EV_LCHAN_ACTIVE or HO_EV_LCHAN_ERROR after the usual
> timeouts set for lchan activation. IOW since it is internal to
> osmo-bsc one of the two events is guaranteed to occur.
>
> If we superimpose a timer on top of the lchan timeouts, configuring
> larger lchan activation timeouts becomes complex, because the user
> has to take care to also allow a larger timeout for the same
> procedure during HO.
Related: OS#5787
Change-Id: Ibf740aaa9bddc2de85cf8087ad90bab47aac12c2
In classic E1 based GSM networks the audio is usually transfered through
16bkps I.460 subslots while 4 16kbps subslots are multiplexed into one
E1 timeslot. However, there may be setups where still 16kbps subslots
are used, but with 1 instead of 4 channels per timeslot. In those cases
the bit offset is 0, while the rate is still 16kbps.
Change-Id: I0d2bc44acaa8e5a28cccfdf7cfb945bf14a4ed30
Related: OS#5198
osmo-bsc requires the PCU to tag IMMEDIATE ASSIGNMENTS that shall be
sent via PCU with a TLLI. This is required to confirm the sending of the
IMMEDIATE ASSIGNMENT messages to the PCU.
Related: OS#5198
Change-Id: Ib804143a57824632e5435f7ba68f2e94f5f3fb21
The BSC has all information about the E1 line configuration of each
timeslot/channel. The PCU is responsible for opening and managing the
CCU connection. To enable the CCU to do that, we have to transfer the E1
connection information (which TS, SS, rate) to the PCU.
Change-Id: I6d44373336b41009ff4c6e459d32d0a81081676c
Related: OS#5198
The PCU needs to be aware of the current system information in order to
work properly.
Change-Id: Ibbfbfaf588a4e406804c36570010aefdfc14328b
Related: OS#5198
We have introduced the function extract_paging_group() with the previous
patch. Lets use it for PCU_IF_SAPI_PCH as well to remove code
duplication
Change-Id: If4ffe8eafd2e54e323cbc075c09d457a74ebe83f
Related: OS#5198
The IMMEDIATE ASSIGNMENT for downlink TBFs needs to be sent through the
PCH instead of the AGCH. Since this method is not specified in RSL, it
is usually a vendor specific extension.
Change-Id: I4452f4973d1ec69c96aad527b057226e8a6edf99
Related: OS#5198
The current name of PCU_IF_SAPI_AGCH_DT is a bit misleading as it
describes a method to send immediate assignment messages (normally AGCH)
via the PCH. The name in the constant should reflect that correctly
Change-Id: I78abeb62d0267baa31a4727c4bdd027b7230f137
Related: OS#5198
A new VTY node was added in commit [1], but bsc_vty_go_parent() was
not updated. Because of that, commands following the MGW node may
crash osmo-bsc. In the example below:
network
network country code 901
mobile network code 70
...
mgw 0
remote-ip 127.0.0.1
local-ip 127.0.0.1
periodic location update 30
the 'periodic location update 30' will trigger a segfault:
(gdb) bt
#0 0x00005555555dfc09 in cfg_net_per_loc_upd ()
#1 0x00007ffff7af6c3f in cmd_execute_command_strict () from /usr/local/lib/libosmovty.so.9
#2 0x00007ffff7af6f1c in config_from_file () from /usr/local/lib/libosmovty.so.9
#3 0x00007ffff7afd4e1 in vty_read_config_filep () from /usr/local/lib/libosmovty.so.9
#4 0x00007ffff7afe375 in vty_read_config_file () from /usr/local/lib/libosmovty.so.9
#5 0x0000555555579616 in bsc_network_configure ()
#6 0x000055555557a352 in main ()
because vty->index would be NULL after returning from the MGW node.
Fix this by adding the missing case to bsc_vty_go_parent().
Change-Id: Id3050ff7e2402c33ee76c7bf0cc83603c0cc6dfc
Fixes: [1] 8d22e68706
The intended endienaess for the remote_port member is host byte order,
while the endianess in the nsvc struct is in network byte order.
(see also pcu_sock.c in osmo-bts.git)
Change-Id: Ib62dcceb80fd500e477dd5e1a0e43de47e16eeb0
Related: OS#5198
The Ericsson RBS is a BTS that natively works with dynamic timeslots.
This colides with the current understanding of static PDCH channels
because the BTSs we support so far get thier static PDCH information on
startup and then handle everything related internally. The BSC does not
actively manage the channel in those cases. In the case of Ericsson we
have to activate the PDCH via RSL like any other channel and the timeslot
FSM has to manage it. Lets not add work arouds for this, lets just print
and error message and use the BTS in the dynamic scheme as intended by
the manufacturer.
Change-Id: Icc7c2956fc934691e3bfacb283d896a8767baf27
Related: OS#5198
Before filling in the TS in the info indication, it is checked that the
MO opstate is enabled. Also it is checked that the TS serves a PDCH.
Lets restructure this check and move the PDCH check into a helper
function as we need to check for PDCH from other location as well later.
Change-Id: Icaab52ab73c38889dfadb523b89bb54cafacc99a
Related: OS#5198
We send the TS_EV_OML_READY event early, even though the TRX is not
fully done with all OML initialization steps. Lets complete the TRX
initialization first and then notify each timeslot FSM with
TS_EV_OML_READY.
Change-Id: If5251b102c8aa45dfc8cc4ee4e0223d7dc438938
Make sure that the TRX MO state is enabled and unlocked before filling
in any TRX information into the info indication
Change-Id: I7a93826e6b0df187425310cb82854e7d7fb47e72
Related: OS#5198
Make 'apply-config-file' check the neighbor config, just as is done after config parsing on startup
Related: OS#5866
Change-Id: I24ae8cd7e5e0d15eab9fd04b1858072bf0bad36a
The function pcu_tx_info_ind() fills the trx information in the info
indication. Since the function is already quite long, move the trx
related part into a sperate helper function.
Change-Id: Ic30185c9364adcc61d0a9d3483b0550ac1cdf894
Related: OS#5198
The pcuif only supports a limited but sufficient number of TRXs. When
filling in the TRX array in info_ind, we must guard against overflowing
the maximum number of TRXs
Change-Id: I351080a112f3d3fdf833ee7fa0d77c4cd1d13e42
Related: OS#5198
The formula that is used to recover the (relative) frame number from the
T1, T2, T3 parameters matches the definition in the spec, but since the
partial term t3-t2 can be negative special precaution is required when
performing the MOD 26 operation. This is due to the truncated modulo
implementation in C/C++, which has a very specific understanding on how
to deal with negative input parameters.
The libosmocore gsm_gsmtime2fn(() offers a correct implementation, so
lets use it.
Change-Id: I5fb2b0ada8d409730ac22963741fb4ab0026abdd
Related: OS#5198
The function trx_get_hlayer1() is defined as a prototype but it is not
used anywhere and there is also no implementation, lets drop it.
Related: OS#5198
Change-Id: I91ead9379140e971ccabc83cbf2b62b8aa1fc8a2
The (relative) frame number that is forwarded to the PCU is an
important parameter which is computed from t1,t3,t2.
Change-Id: I83d20ba9e0ce6488d458ccf4a85c8445c30e3a89
When a CHAN RQD is received via RSL, we show ra and other parameters.
Lets also show T1, T3 and T2.
Change-Id: I78499b49ae176b736e384e193fadc0bdd669dffa
The frame number calculation in rsl_rx_pchan_rqd() is done using a
specific formula. Lets add a spec reference and also restructure the
code a bit.
Change-Id: I60500c8694dbc2e6e2c4bbffd4ff7057bbc324e6
TTCN3 have been improved in osmo-ttcn3-hacks.git Change-Id
I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54 to use valid l3 data.
Related: SYS#6280
Change-Id: I4918f1741d465abf8b06a9c65199a44b09778299
IMEI may be used as MobileIdentity during MO emergency call
establishment if the MS has no valid IMSI assigned.
Related: OS#5849
Change-Id: I586b1ee30cbb26ddf58788168d56c962e03ccd5c
The second NSVC MO has been explicit skipped and never been interacted with.
osmo-bts is already supporting it for a long time as well the PCU is
supporting it at least since the NS2 code migration.
Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc.
Closes: OS#5835
Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
It was found in a BSC on the field that an MS sending an incorrect
MobileIdentity IE (wrong length) in PagingResponse was generating a
crash on the BSC.
When the MobileIdentity cannot be parsed right now we keep on instead of
rejecting the conn. This should change in the future, but it needs
further improvements in our TTCN3 tests. For now let's simply validate
the subscriber is not NULL; since recently paging optimizations made
paging_request_stop() require the subscriber to be non-null.
Fixes: 27cb5d3e24
Related: SYS#6280
Change-Id: If8b439ff74c5dd690d637d3e3278c75d6cd6b928
In send_assignment_complete(), obviously return the current channel
configuration from lchan->current_ch_mode_rate, which is the proper
place to get the channel mode after RSL Chan Activ Ack.
It is interesting to look at the history of this line of code.
lchan->current_ch_mode_rate was added later, so now the mistake is very
obvious.
Related: SYS#6229
Change-Id: I3bf8f5ea9ae2a3c12fc5b483818d550a069fe66e
This patch caches the counts of initial paging requests for each paging
group. This count is needed to estimate T3113 when a new incoming paging
request is received and it has to be inserted into the queue.
With this there's no need to traverse the whole initial_req_list every
time a new incoming paging request is receiving, potentially saving lots
of iteration and hence lots of CPU when the queue is long.
Related: SYS#6200
Change-Id: I6994127827d120a0b4dd3de51e1ddde39f2fe531
If queue size (in transmit delay of requests) is too long (above
threshold) when a new initial incoming request arrives, instead of
directly discarding it, see if we can drop a pending retransmission and
insert the new one instead, in order to avoid losing initial requests.
This is done under the assumption that it is more important to transmit
intial requests than to retransmit already transmitted ones. The
rationale is that there's lower chances that an MS which didn't answer
lately will answer now (aka being reachable at the cell), so it's better
to allocate resources for new requests (new MS) which may be available
in the cell.
Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d
Related: OS#5552
Initial requests: paging requests which haven't been yet transmitted
Retrans requests: paging requests which have already been transmitted at
least once.
Until now one queue was used (llist) to store both. The initial requests
were stored at the start of the queue in FIFO order. After the last
initial requests, the retrans requests followed also in FIFO.
This ordering was used in order to prioritze scheduling of initial
paging requests over retransmit paging requests.
In the end, having both types in the same list only make code handling
the list more complex.
Hence, this patch splits the shared llist into 2 llists.
Related: SYS#6200
Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
When adding a new incoming request (aka "initial_req"), if the queue is
full only of retransmis (no not-yet-ever-transmitted initial requests
queued), then the new incoming request is inserted at the start of the
queue, in order to take scheduling priority over retransmits.
This was already fine before this patch, but the counting of requests
before it (used to calculate its T3113) was wrong, because it counted all
the retransmissions. This patch fixes it to end up with
reqs_before(_same_group)=0.
Change-Id: Ib2e810b0bcc51eac117713584310272462c58867
This allows configuring the maximum delay of paging requests to be
queued according to other parameters, such as MSC paging request
timeouts, etc.
Related: OS#5552
Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
The default is to have a dynamic T3113. However, if the user wished to
set it statically, it would show up when writing the current VTY config.
Change-Id: If121a97bbb4a0234a0c162ef37c3692d6408404d
The BTS can be obtained easily from the backpointer in req->bts. Having
the extra param can only lead to confusion and introduction of bugs, as
happened in bug fixed by Change-Id
I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679.
Related: SYS#6200
Change-Id: I545fd853fdffce7f23f0d99203c66c3b39144e4b
When rewriting the loop, the pointer passed all the time to
paging_remove_request() was the one of the BTS which answered the
request, not the one actually handling the related unanwared still
active paging request.
Fixes: 70a1d60a83
Related: SYS#6200
Change-Id: I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679
This allows tracking each BTS active paging request queue length over
time, and evaluate CPU load based on the number of active paging
requests queued.
Related: SYS#6200
Change-Id: I6d296cdeba1392ef95fc31f6c04210c73f1b23e5
This way all paging related stats can be grouped (more will be added in
follow-up commits).
Related: SYS#6200
Change-Id: Iede1b6f68df468c7a3b3bf5fce7f68bb08b78832
Use spaces around equals signs inside structs, as expected from the
kernel coding style we mostly follow.
Neels wrote:
> IIUC "T=123" without spaces is my personal favorite that goes against
> the accepted linter standard, i guess rather than everyone else
> adapting to my weird style, i should start adding spaces in my
> patches.
Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
Neels wrote:
> i guess we can drop this comment now, it is a remnant from separating
> osmo-nitb -> osmo-bsc + osmo-ms
Change-Id: I2ce4d691715c1ea5c7c7896693a03b0aefbdb5b9
Prior to this patch the whole paging queue of each BTS was iterated.
After the patch only the active paging_req for a given subscriber are
iterated.
Related: SYS#6200
Change-Id: I225d5e08427c6bb9d92ce6a1dccb6ce36053eab5
This is triggered by BSC_Tests.TC_lcs_loc_req_no_subscriber.
Before, the NULL ptr was not a problem because paging_request_cancel()
only used the pointer to compare it against other pointers, but never
accessing it. A follow-up patch is, however, changing the implementation
to optimize the lookup by using the subscriber pointer, which generates
a crash.
Related: SYS#6200
Change-Id: Id0de43ac5bde0f52f258de6c9bf58b173301c8db
Before this patch, the entire queue of paging_request had to be iterated
in order to find if the subscriber already had an active paging request
(discarding duplicates).
Now that bsc_subscriber holds a list of its active paging requests, it's
easier to look at its list to find out if it is already active on that
BTS.
As a result, there's no need to unconditionally iterate the whole list
and we can optimize the loop finding the spot to insert the new queue:
- First the potentially way smaller loop over
bsub->active_paging_requests is done
- Second, only if the first loop allowed, the bts->pending_requests is
iterated and potentially early terminated.
Related: SYS#6200
Change-Id: I7912275026c4d4983269c8870aa5565c93277c5a
This allows havily decreasing the algorithmic cost of removing all
pending active paging requests for a given subscriber once it answers
on a given BTS.
Beforehand, the whole paging queue of all BTS were iterated. Now, only
the active requests for that subscriber are iterated.
Related: SYS#6200
Change-Id: I831d0fe01d7812c34500362b90f47cd65645b666
This saves the BSC from iterating twice the whole paging list of the BTS
which received the paging response.
Related: SYS#6200
Change-Id: I5f9215f31428ce0249cd9ece6d2d4e93155f429f
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
Unfortunately "-std=c99" is not sufficient to make gcc ignore cold that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: Ic92aa70d569778a776f4c5d24c455f71fd50b61b
The function rsl_ericsson_imm_assign_cmd has a comment "Chapter 8.5.6"
above it. However, thats only half true. The function implements
ericsson vendor specific RSL IEs, so lets be more clear about this in
the spec reference.
Change-Id: Id27662e208ca8ac0a48851583c11fbacf85f988c
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
In SCCPlite, the BSC receives the CN-side MGCP from the MSC through an
IPA conn, and it then forwards those messages to its co-located MGW
through a rawUDP socket created at startup.
This forwarding UDP socket still relied exclusively on the "mgw.conf"
struct which was filled only by the old VTY interface which was been
deprecated lately.
This patch moves the mgw-pool setup before the msc setup so that if the
VTY config file still uses the old VTY, the single MGW is added to the
MGW pool through mgcp_client_pool_register_single(). It then simply
picks the first available MGW from the pool when creating the raw UDP
MGCP-forwarding socket.
This means SCCPLite is still left with supporting only 1 MGW. If more
than one MGW is defined in the pool, then when the call is being set up
a different MGW could be picked from the pool while the CN-side MGCP
would still be sent to the MGW pool selected at osm-bsc startup.
This limitation coul be removed later on by adding a new VTY command
under the "msc" to pin calls for an MSC to an MGW with a given "mgw_nr"
from the pool, and that same MGW be looked for in the pool every time a
new call is being established.
Another possibility would be to avoid creating the "connected" UDP
socket at osmo-bsc startup, and rather use it in non-connected mode and
transmit (sendto) using the mgcp_client remote address during call
establishment.
In any case, this is left as future excercise since so far there hasn't
been any need for multiple MGWs in SCCPLite setups.
Related: SYS#5987
Change-Id: If105dee52b8d36161c759f979eaef4579b47d365
Commit 53b23c252e introduced a weird line
duplication that instead should have been the way this patch does it.
Change-Id: I5a9a983bb6135059ec01edf054ea3f7165bb6a6f
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Change-Id: Ib2f04d96ca846d2d61af0b0c0ea1924609004952
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
This feature allows pinning each BTS to a specific MGW from the
configured pool. The pinning can be soft or hard (strict). If strict
pinning is not set, the configured MGW is selected with priority, but
other MGWs can still be selected during each call setup if the
preferred MGW is found not available at that time, hence avoiding denial
of service for the entire BTS if that MGW goes down.
If strict mode is selected, the call will be refused if the configured
preferred MGW is not available at the time the call is set up.
It is useful to use this feature when Osmux is configured between
the BTS and the BSC and an MGW pool is in use. This way the BSC is
capable of grouping all the calls of a BTS towards one MGW, hence taking
advantage of the Osmux trunking optimizations to reduce link data usage
(AMR payload of several concurrent calls ending up sharing the same
underlaying UPD packet).
Furthermore, this allows the operator to intelligently spread load over
the MGW pool in order to avoid ending up with more than 256 concurrent
Osmux circuits on any of the co-located MGWs in the pool (maximum supported
at the moment).
Related: SYS#5987
Depends: osmo-mgw.git 5d8b5b093595e1203e288c3175c163c0994b1102
Change-Id: I9a7a5af72795faed0d12d9d73b59951b6a0e9c7d
The CHAN REQ entry is not deleted after its information was passed on to
the PCU. This causes the same entry to be used over and over again while
blocking other incoming CHAN RQD.
Change-Id: Ia4abc55fc6fcb1c00991cc84d09529131d014910
Related: OS#5198
There's no need to fail, simply make it a noop in that case,
everything's fine and everybody is happy (specially when using CTRL
command "apply-config-file" to load a .cfg file containing
modifications.
Related: SYS#6138
Change-Id: Ia4e70d20d48a28c46a21dd10358577e5c798744c
Current organization is totally mess, there's actually no organization
at all for lots of commands.
Let's organize most commands based on CTRL node where they are applied:
global, bts, trx, etc.
Specific set of commands such as neighbor-related, rf-related, etc.
are left in separate files as subsections inside the same node, so the
hierarchy is still clear.
Change-Id: I51a9b31780a4a8026aafb2d732369cdc10c8bb70
Matan Perelman
Oliver Smith
Neels Hofmeyr
Vadim Yanitskiy
Pau Espin
Philipp Maier
Harald Welte