aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2023-07-21ASCI: Send only NLN on Paging request type 1 rest octetsAndreas Eversberg1-6/+9
Do not send notifications here. The notifications are sent on the NCH. The NLN is used to indicate a change on the NCH, so that the MS will read the NCH then. If NLN is not sent towards MS, it will not read NCH to get an updated list of ongoing calls. Also, it will not allow making VGCS/VBS calls and might indicate that ASCI is not supported in this call. (Tested with GPH-610R.) Change-Id: I22e584b70fd14d8bdabb28cf5de3d4647f37425a Related: OS#5781
2023-07-21ASCI: Add support for rest octets in Paging request type 2 and 3Andreas Eversberg1-12/+127
Currently the rest octets contain Notification List Number (NLN) and NLN status and the "Channel Needed" (CN3 / CN4) fields for mobile identities. The existing encoding of CN3 / CN4 in Paging request type 3 has been replaced. The missing encoding of CN3 in Paging request type 2 has been added. Change-Id: I6e33a6d38d4c7b124de35b53d219b64bb881ba66 Related: OS#5781
2023-07-21ASCI: Add Notification CHannel (NCH) supportAndreas Eversberg8-26/+130
The location of the NCH is defined by the rest octet of System Information 1. If NCH is defined, the given CCCH blocks are used for NCH instead of AGCH/PCH. The current list of VGCS/VBS call notifications is transmitted on the NCH. If there is no notification, an empty notification is transmitted on the NCH. The Notification List Number (NLN) is used to indicated new notificaitons. Only the last notification (or empty notification) indicates NLN. This way the MS can determine after two equal NLN that the complete list has been recevied. Change-Id: I82fdaba3faaced76267a99ae14a5458a1b41fdaa Related: OS#5781
2023-07-21ASCI: Retrieve NCH position from System Information 1Andreas Eversberg6-0/+28
When BCCH INFO is received via RSL message, the rest octet of the System Information 1 message is parsed to get the position of the NCH. The position is stored in the gsm_bts structure. If the position is not present int the rest octet, the stored value is set to negative. Change-Id: I799a27179d478d4ff577d8bc47ae524834851e85 Related: OS#5781
2023-07-21osmo-bts-trx: document/clarify the meaning of BUFMAX=24Vadim Yanitskiy2-2/+4
Change-Id: I95d4e4ee3938cfabc1695959cc82a1efbbf0d7ed Related: OS#1572
2023-07-21osmo-bts-trx: tx_tch[fh]_fn(): fix NULL pointer dereferenceVadim Yanitskiy2-5/+10
It may happen that only FACCH is available for transmission, so msg_tch would be NULL in this case. Check it before dereferencing. Change-Id: I0e7d5634b5223bc246badbb8e94b620c967ab121 Related: OS#1572
2023-07-21omldummy: Claim to support VBS + VGCS towards BSCHarald Welte1-0/+2
This tells our TTCN3 BSC tests to perform VBS/VGCS related procedures on RSL. Change-Id: I9ed1b20985d2ce3be31942d3e9df5cad513a0bfd Related: OS#5778, OS#5779
2023-07-21sysmo: Enable VGSCS + VBS feature flagsHarald Welte1-0/+2
This tells the BSC that osmo-bts-sysmo supports VBS/VGCS Change-Id: I1625d2a0f4905437fad0b5220a551f81eba9a00e Related: OS#4851
2023-07-21ASCI: Add function to reactivate channelAndreas Eversberg1-13/+36
Reactivation will modify parameters on an already activated channel. On a VGCS/VBS channel it can be used to prepare channel for assignment of the mobile station to it. During assignment the channel is reactivated. The timing advance of the mobile station is given. The uplink is activated and is waiting for the mobile station to establish, to complete the assignment. For reference see patent EP 1 858 275 A1. Change-Id: I77f413cf70c2f5f8e8f525686eee40548521c71b Related: OS#4851
2023-07-21ASCI: VGCS/VBS RACH -> RSL TALKER/LISTENER DETECTHarald Welte14-20/+345
Random access is allowed on VGCS / VBS channels to access the uplink or to detect listeners. Uplink Access from a listener is only reported once after activating the channel. Uplink Access from a talker is reported each time the uplink becomes occupied. RSL TALKER/LISTENER DETECT messages are sent to the bsc. The VGCS UPLINK GRANT message is sent by the BTS itself. Timer T3115 is used to repeat the message up to NY2 times until one valid frame is received from the MS (CM service request). The UPLINK BUSY / UPLINK FREE message must be sent by the BSC. The uplink is released by UPLINK RELEASE message from the MS or from the BSC. Afterwards the UPLINK FREE message causes the MS to leave the uplink without any acknowlege. An RSL REL-REQ must be used to terminate the link locally. (Without layer 2 DISC procedure.) Change-Id: I1bd07ab6802341b09a06e89df356665ffaf6d2bf Related: OS#4851
2023-07-17paging: also accept zero length IMSI strings 3Philipp Maier1-10/+22
When an IMMEDIATE ASSIGNMENT MAC block (from PCUIF) is added to the paging queue, then also an IMSI is required. The paging queue uses the last three digits of the IMSI to calculate the paging group. In case no IMSI is given, the MAC block is rejected. This was handeled differently before. Even an IMSI of length 0 would still be interpreted as "000" and not rejected. See also: I9f3799916e8102bf1ce0f21891f2d24f43091f01 Let's restore the behaviour we had before and accept short IMSI strings again. Change-Id: Iab1c3f1c39dd59bb53aa74b2c9e9e135e3985e0b Related: OS#6099
2023-07-15osmo-bts-trx: change 'Received bad data' back to LOGL_DEBUGVadim Yanitskiy1-1/+1
In f2c902c2 I accidentally bumped the logging level for PDCH decoding errors to LOGL_NOTICE, making osmo-bts-trx spam the logging with hundreds of 'Received bad data' messsages. Revert this. Change-Id: Idb963f1a779dfa172825f6d481740cb0c4165485 Fixes: f2c902c2 "osmo-bts-trx: unify and enrich 'Received bad data' logging"
2023-07-13osmo-bts-trx: rx_tch[fh]_fn(): combine rc-checking ifsVadim Yanitskiy2-8/+2
Change-Id: I7bb341867e362bf2061608ff54c3596ad209af90
2023-07-13osmo-bts-trx: rx_tchf_fn(): move compute_ber10k() aboveVadim Yanitskiy1-2/+2
... for the sake of consistency with rx_tchh_fn(). Change-Id: Ie331da78eb3831e35d255583466e0d09b093b132
2023-07-13osmo-bts-trx: unify and enrich 'Received bad data' loggingVadim Yanitskiy5-27/+14
Change-Id: I7902f382e1d83ef9ad2cf6f92e31eeb16f6b797c
2023-07-13osmo-bts-trx: visualize rx_tch[fh]_fn() functionsVadim Yanitskiy3-2/+102
Change-Id: I373dbbc3d427858f76d07ff85633e07fe2600770 Related: OS#1572
2023-07-13osmo-bts-trx: implement TCH/F2.4 support for CSDVadim Yanitskiy2-12/+5
Change-Id: I31c59a78a362986b0cd1bc6650c325ee9f206519 Depends: libosmocore.git I4685376c8deb04db670684c9ebf685ad6fc989fa Related: OS#1572
2023-07-13osmo-bts-trx: implement FACCH/[FH] support for CSDVadim Yanitskiy2-57/+143
The FACCH/[FH] coding rules are specified in 3GPP TS 45.003, sections 4.2 and 4.3. The key difference is that unlike with speech channels, FACCH does not replace data frames completely, but disturb a fixed amount of bits fom them. This is why we need to use separate gsm0503_tch_[fh]r_facch_{en,de}code() API for data channels. Change-Id: I4c6736e84c271240d457998de688c0baf59fe578 Depends: libosmocore.git I0c7a9c180dcafe64e6aebe53518d3d11e1f29886 Related: OS#1572
2023-07-13osmo-bts-trx: implement CSD scheduling supportVadim Yanitskiy9-72/+268
* enlarge the maximum burst buffer size to 24 * (2 * 58) bytes; * enlarge per-l1cs Uplink burst mask to hold up to 32 bits; * enlarge per-l1cs Uplink meas ring buffer to 24 entries; * add new meas modes: SCHED_MEAS_AVG_M_{S22N22,S24N22}; Change-Id: I08ffbf8e79ce76a586d61f5463890c6e72a6d9b9 Depends: libosmocore.git Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d Related: OS#1572
2023-07-13osmo-bts-trx: pull the AMR header in tch_dl_dequeue()Vadim Yanitskiy2-12/+17
The goal is to unify encoding functions in tx_tch[fh]_fn(), so that in a follow-up change adding CSD we could use a switch statement. Change-Id: I15318e497b236128f779769e4fa99f307ea431ea Related: OS#1572
2023-07-12common: Make socket queue max. length configurablearehbein7-25/+46
Title refers to the maximum length of the osmo_wqueue used for the PCU socket connection. Related: OS#5774 Change-Id: Id6ba6e4eadce9ce82ef2407f4e28346e7fe4abfa
2023-07-11measurement: suppress unsupported tch_mode warnings for CSDVadim Yanitskiy1-0/+16
Change-Id: If6896b420d0fa50fa6622d24ef679ca65ef2dc50 Related: OS#1572
2023-07-11fix bts_supports_cm(): properly check feature flags for VGCS/VBSVadim Yanitskiy1-13/+15
cm->spd_ind can take only three values defined in enum rsl_cmod_spd: 0000 0001 RSL_CMOD_SPD_SPEECH 0000 0010 RSL_CMOD_SPD_DATA 0000 0011 RSL_CMOD_SPD_SIGN According to 3GPP TS 48.058, section 9.3.6, all other values are reserved, so expecting RSL_CMOD_CRT_TCH_{GROUP,BCAST}_{Lm,Bm} there is wrong. These values are part of enum rsl_cmod_crt, so the right field would be not cm->spd_ind, but cm->chan_rt. Let's check these channel types in a separate stage, before checking the requested codec. Group them with VAMOS specific types for the sake of consistency. Change-Id: I914c84be04da819df9e60e2f5ecc5bac9b61b2e5 Fixes: 44c94fdea "validate RSL "channel rate and type" against VGCS/VBS flags" Related: OS#4851
2023-07-10Store "Channel rate and type" from RSL Channel Mode IE in BTSHarald Welte2-0/+7
The RSL "Channel rate and type" field from the RSL Channel Mode IE in RSL_CHAN_ACTIV and RSL_MODE_MODIFY_REQ messages is the only place where the BSC differentiates between a normal TCH and the special TCH modes used in VGCS or VBS. Let's copy this field from the RSL message into the lchan state, so that BTS models can actually (in subsequent patches) reflect it when activating the L1. Change-Id: I6d531bf528bcb81f44d91336471a46ef790d7646 Related: OS#4851
2023-07-10Change return value of bts_supports_cm() from int to boolAndreas Eversberg4-23/+23
Change-Id: I72e30fe852ab69a162b117a534071ebddd4b16ba
2023-07-10validate RSL "channel rate and type" against VGCS/VBS flagsHarald Welte1-0/+14
We already have specfied (but not yet implemented BTS_FEAT_{VBS,VGCS}). Let's add code to validate "channel rate and type" compatibility in bts_supports_cm() once a BTS model would actually exhibit those feature flags. Change-Id: I5e7f65b44cef6e2f7ad4f152f80a1686a4f511e3 Related: OS#4851
2023-07-10ASCI: NCH / NOTIFICATION supportHarald Welte9-10/+299
This adds very minimalistic support for notification of VBS/VGCS calls. Minimalistic in that we * only notify via PCH (not via NCH or FACCH) * only include notification in otherwise empty PAGING TYPE 1 This means that notification will cease to work once the PCH becomes too loaded and we never would send otherwise empty PAGING TYPE 1 anymore. Change-Id: I6f6f72d9a0123cb519b341d72a124aaa2117370e Requires: libosmocore.git I9586b5cb8514010d9358fcfc97c3d34741294522 Related: OS#5781
2023-07-10Add ASCI (advanced speech call items) log sub-systemHarald Welte2-0/+8
As we subsequently add ASCI related features to the code, it makes sense to have a specific log sub-system for it. Change-Id: I8ea3e61df35175bd74110b2f41994c99da3e2858 Related: OS#4851
2023-07-10paging: Add support for generating NLN/NLN-Status in P1 Rest OctetsHarald Welte1-1/+13
The NLN + NLN-Status are optional parts of P1 rest octets; they can be used to support the "Reduced NCH monitoring mechanism" as described in Section 3.3.3.3 of TS 48.018. The patch just adds encoder capability but doesn't yet make use of it. Change-Id: I961842c3fec151e149f72a4f36279ce4b979795e Related: OS#5781
2023-07-10pcu_sock: use PCUIF version 11 (direct TLLI)Philipp Maier5-28/+42
OsmoBTS still uses the deprecated version 10 of the PCUIF protocol. OsmoPCU is still compatible to version 10, but to maintain a clean interface it is planned to drop the support for version 10 in the near future. Moving to PCUIF v.11 essentially means using the "Direct TLLI" method to convey IMMEDIATE ASSIGNMENT and also PAGING COMMAND messages through the PCU socket. This means in particular that we use a TLLI as an identifier to confirm IMMEDIATE ASSIGNMENT messages towards the PCU (PAGING COMMAND is not confirmed at all). Also we now use struct gsm_pcu_if_pch_dt to parse the incoming PCU_IF_SAPI_PCH_DT, which is much cleaner than using offsets in a buffer. Change-Id: I25816ac12e63cc6b641eb414e6bc7eaa9c85fc25 Depends: osmo-ttcn3-hacks.git I08de02e951e10bc8b4381cc2ad32e63f2747e3c4 Depends: docker-playground.git Ia28bc0d6d3cbfe63be19443db86631fb67bb80fb Related: OS#5927
2023-07-06scheduler: use size_t for data_len in _sched_compose_*_ind()Vadim Yanitskiy2-4/+4
The payload size for some CSD channel types is bigger than what an uint8_t can represent, for instance 290 bytes for TCH/F14.4. Change-Id: Id75c55509a017d14dfab2a7b4c67e0742125a113 Related: OS#1572
2023-07-06scheduler: constify *data pointer in _sched_compose_*_ind()Vadim Yanitskiy2-4/+4
Change-Id: I617e7ed50d27e047cc2851f5d44d31ad3111ce0a Related: OS#1572
2023-07-06scheduler: unify argument names/order for _sched_compose_*_ind()Vadim Yanitskiy6-42/+62
This commit aims to make the argument naming/ordering more consistent: * rename l2/l2_len and tch/tch_len to data/data_len; * common arguments first (consistent ordering), specific last. Change-Id: I3d8c90b82f2a55b0c5c2d6b4efb8fd962508534d Related: OS#1572
2023-07-06scheduler: use msgb_hexdump_l2() in _sched_compose_tch_ind()Vadim Yanitskiy1-1/+1
Change-Id: Iec8b6edaeb516eb5dc65eab52e3450e7330a6504 Related: OS#1572
2023-07-05scheduler: fix wrong union field in _sched_compose_tch_ind()Vadim Yanitskiy1-1/+1
Change-Id: I2f6794d229ad8219e3835a6eb74513672e497d5d Related: OS#1572
2023-07-04Increase PCUIF wqueue sizePau Espin Pedrol1-1/+1
The default of 10 messages introduced recently is too small, specially when using osmo-bts-trx, where clock drifting and CPU scheduling can cause skewing and hence generation of 2-3 FNs (* up to 8 TS) at once, hence filling the PCUIF queue with more than 10 messages in a given moment. Fixes: c938a95e255262f38aae9d4242cc86a87c46d172 Change-Id: I7ababfc6cdf20196889fb542a8040128b3c118b5
2023-07-02common: Have PCU socket connection use osmo_wqueuearehbein2-53/+38
Fixes memleak in case of connected PCU process being suspended without proper close on socket Related: OS#5774 Change-Id: Ia6e61dda4b3cd4bba76e6acb7771d70335062fe1
2023-06-28ECU in UL path: move it from trx model to l1sapMychaela N. Falconia3-69/+53
With this change the application of ECU in the uplink path becomes consistent across all OsmoBTS models, enabled or disabled per vty config setting "rtp internal-uplink-ecu". An additional behavioral change from the previous trx-model-only implementation is that ECU insertion is now done after the link quality check in l1sap, thereby fixing the bug where this quality check would sometimes suppress ECU output and replace it with BFI markers in RTP. In the new implementation when the internal ECU is enabled and available for the selected codec (currently FRv1 only), the RTP output will gap (standard representation of BFI in RTP) only during DTXu pauses as indicated by a received SID frame (either valid or invalid), and the SID frame that triggers the switch from ECU mode into pause mode is reliably emitted in RTP. Related: OS#6040 Depends: I3857be84bba12aaca0c2cca91458b7e13c5a642a (libosmocore) Change-Id: Iac577975c9ab50cb8ebbc035c661c1880e7cecec
2023-06-28ECU in UL path: move state alloc/free to l1sapMychaela N. Falconia2-20/+26
In preparation for moving the now-optional application of ECU in UL path from osmo-bts-trx model-specific code to the common layer, move ECU state allocation and freeing from trx model to l1sap. Related: OS#6040 Change-Id: Ic98a2eb26b5a99bc4a89ad07ae87c9a86b921418
2023-06-28ECU in UL path: make it optional per vty configMychaela N. Falconia5-3/+44
Current osmo-bts-trx includes a provision for invoking ECUs from libosmocodec in the UL path from the channel decoder to the RTP output. This pre-existing implementation is counter to the spirit of 3GPP specs (a BTS should merely mark BFI conditions in its UL output, as opposed to actively modifying the frame stream with an ECU), inconsistent between different osmo-bts models (only in -trx and no others), and inconsistent even within osmo-bts-trx itself, where the link quality check in l1sap will sometimes suppress the output of the ECU - a quirk which the designers of the current mechanism most certainly did not intend. The solution decided upon in OsmoDevCall on 2023-06-21 is to make this ECU optional per vty config, and move it from the trx model to the common layer to resolve the inconsistencies. Implement the first part: make the ECU application optional per vty config. For backward compatibility with existing deployments, the new "rtp internal-uplink-ecu" setting is enabled by default on osmo-bts-trx but not on any other models. Related: OS#6040 Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e
2023-06-27osmo-bts-sysmo: mute PHY until OML is readyOliver Smith2-8/+26
Connecting to OML and PHY is done in parallel. The PHY connection will always be done first, mute PHY until OML is also ready. As Pau suggested, move dispatch of NM_EV_SW_ACT to a callback of trx_rf_lock to have the events serialized and therefore deterministic. Fixes: SYS#6496 Change-Id: Ia1769f952fa787202a442a33db5ed4a1f7cbe9c3
2023-06-26osmo-bts-sysmo/l1_if: move mute_rf_compl_cb upOliver Smith1-98/+98
Prepare to use it in a new function above activate_rf_compl_cb. Change-Id: I19dbfbd595d3b42c0634a4c38e39cdb314a54266
2023-06-26osmo-bts-sysmo: activate_rf: no dispatch on failOliver Smith1-4/+5
Do not dispatch NM_EV_SW_ACT to trx->mo.fi and trx->bb_transc.mo.fi when RF-ACT.conf was not successful. Running this code path anyway looks like a leftover from when bts_shutdown used to exit osmo-bts. Change-Id: I342187604f4c72303e393ce6925b94d610bfa8fa
2023-06-26l1sap: use gsm0502_fn2ccch_block() from libosmogsmVadim Yanitskiy2-27/+2
Keep the l1sap specific wrapper because we still want to assert(). Change-Id: I7097ba87f42689d2336014da9173cadbdaa9fdab Depends: libosmocore.git I8cbd31226754e95887358ed83a928e2f567f4cf3
2023-06-23osmo-bts-sysmo: trx_mute_on_init_cb: call bts_update_statusOliver Smith1-0/+2
Run bts_update_status in trx_mute_on_init_cb like in the default callback mute_rf_compl_cb. Related: SYS#6496 Change-Id: Ib73a33a82fbb86ead3569a6bb22fb001c55354d4
2023-06-23gitignore: add arm-poky-linux-gnueabi-libtoolOliver Smith1-0/+2
This file gets copied into the tree when building with the SDK. Change-Id: I0fe4f96175ee94eb0a131c425bbeb110f1d55402
2023-06-14l1sap: cosmetic: rename payload_len to rtp_pl_lenPhilipp Maier1-2/+2
The function signature of rtppayload_is_octet_aligned has a parameter rtp_pl for the payload and a parameter payload_len for the length of the payload, while other functions use rtp_pl and rtp_pl_len. Change-Id: I8a0e0357aab2a78e25811f66b1b870e8c6ebffe9
2023-06-07pcu_sock: move variable declaration of imsi[4] into related scopePhilipp Maier1-1/+1
The variable imsi[4] may be moved into the scope of case PCU_IF_SAPI_PCH Related: OS#5927 Change-Id: I62aed4f1c600ce2a80d2df928a60b6a2e0ae1889
2023-06-07paging: do not confirm PAGING COMMAND messagesPhilipp Maier3-5/+15
when osmo-bts receives a MAC block from osmo-pcu through the PCUIF it puts it in the review queue without further interpreting it. This also means that it will send confirmations to the PCU for IMMEDIATE ASSIGNMENT and PAGING COMMAND. This is not entirely correct because only IMMEDIATE ASSIGNMENT messages should be confirmed. osmo-pcu has no problem with this since it silently drops the confirmations for PAGING COMMAND messages. This peculiarity of the PCUIF implementation makes the confirmation logic hard to understand, so let's add some logic to osmo-bts that makes sure that only IMMEDIATE ASSIGNMENT messages are confirmed. Related: OS#5927 Change-Id: I8b8264d28b1b1deb08774cdba58dd4c6dafe115d
2023-06-07paging: parse PCUIF data indication outside of paging.cPhilipp Maier3-16/+23
The function paging_add_macblock takes a data and length parameter. The first three byte of that string are the last three digits of the IMSI from which the paging group is calculated. As the layout of this data buffer is a property of the PCUIF interface API, we should do this separation outside of paging.c. Also we should supply the IMSI as a valid null terminated string since PCUIF v.11 also uses this format. Change-Id: I9f3799916e8102bf1ce0f21891f2d24f43091f01 Related: OS#5927
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-28 08:49:41 +0000