aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2023-08-08deprecation: use new log_set_print_timestamp2()neels/log_timestampsNeels Hofmeyr1-1/+1
Change-Id: Ic8466fbbfaf9676dd66bfc6162aabf607ee6dad5
2023-08-07rsl: rsl_handle_chan_mod_ie(): do not use legacy definesVadim Yanitskiy1-7/+7
Change-Id: I4e8f9ff5189af80bce13cfd1b27585aabda03f7a Related: OS#1572
2023-08-07rsl: rsl_handle_chan_mod_ie(): set lchan->csd_modeVadim Yanitskiy1-0/+18
Change-Id: I6b1b44cffae1484098709efe496efafacbd354a8 Related: ca418643 "csd_v110_rtp_encode(): properly set E1/E2/E3 bits" Related: OS#1572
2023-08-04Fix incorrect order of params passed to logging macroKeith1-1/+1
Stops log lines like: 'DOML unknown 0x239616 (bts=0,trx=0,ts=1,ss=0) [....]' Change-Id: Ie1ad41210280ae5dbe693de6bdc4378ff34621b7
2023-07-30osmo-bts-trx: bts_supports_cm_data(): allow non-transparent modesVadim Yanitskiy1-0/+3
The rate adaptation algorithm is the same for both transparent and non-transparent channel modes. The only difference is that the E-bits in the modified CSD frames carry data, like the D-bits. Change-Id: Ib0d9346d7a8e30b8a8e4b08ee04846ba7d12b3fb Related: OS#1572
2023-07-30csd_v110_rtp_encode(): properly set E1/E2/E3 bitsVadim Yanitskiy4-19/+46
The E1/E2/E3 bits are set based on out-of-band knowledge of the current user data rate. The actual bit values are defined in 3GPP TS 44.021, Figure 4 "Coding of data rates". TODO: this is only valid for transparent services, for non-transparent services see 3GPP TS 48.020. TODO: lchan->csd_mode is never set to the actual CSD mode... Change-Id: I1a14597dff746cf975140b294400a2cc05badccd Related: OS#1572
2023-07-30l1sap: proper rate adaptation for CSD (RFC4040 'clearmode')Vadim Yanitskiy13-14/+475
Since 95407f3f osmo-bts-trx supports scheduling all CSD specific channel rates, however the rate adaptation was missing. On the radio interface we deal with CSD-modified V.110 frames, which need to be converted to normal 80-bit V.110 frames (RA1'/RA1), which in turn need to be batched and sent in RFC4040 "clearmode" 160 octet RTP payloads (RA1/RA2 as per I.460). Note that this patch comments out TCH/F14.4 in bts_supports_cm_data(), so that all channel allocations for this mode would be NACKed. The reason for this is that the rate adaptation functions for TCH/F14.4 are different than the RA1'/RA1 and the RA1/RA2. For more information, see: * 3GPP TS 44.021, section 8 (functions RA1'/RA1) * ITU-T I.460, section 1.1 "Rate adaption of 8, 16 and 32 kbit/s streams" Change-Id: I5e3701ad52d5d428fd02caff037881045f2d0a02 Related: OS#1572
2023-07-21ASCI: Enable UPLINK ACCESS on various BTS modelsAndreas Eversberg4-4/+8
UPLINK ACCESS (RACH on TCH) was enabled for osmo-bts-sysmo only. Now it is also enabled for: * osmo-bts-lc15 * osmo-bts-oc2g * osmo-bts-trx * osmo-bts-virtual Change-Id: Iae0db6bfcf6629c114436a79648e832c82835abe
2023-07-21Add test cases for rest octets of Paging RequestsAndreas Eversberg3-52/+224
The abstract representation of the rest octets are moved to the header file, so that the test case can include it. append_p*_rest_octets() function become externally available for test. Change-Id: Ifa5be8998b671160e38af1be707e040b00d407b8 Related: OS#5781
2023-07-21ASCI: Repeat UPLINK FREE message until uplink becomes busyAndreas Eversberg4-0/+37
According to TS 44.018 the UPLINK FREE message must be repeated when the uplink is marked as free. The BSC sends the UPLINK FREE message once and the BTS repeats it until UPLINK BUSY (uplink blocked by BSC) or VGCS UPLINK GRANT (talker accesses the uplink) is sent. It is important to stop sending UPLINK FREE message when a talker accesses the uplink and before the VGCS UPLINK GRANT message is sent, so that stopping must be controlled by the BTS. Related: OS#5781 Change-Id: Ia23c59f5e9a73bbc384fbc317a2cfcf707e3c28f
2023-07-21ASCI: Add Notification/FACCH supportAndreas Eversberg3-0/+81
When a VGCS/VBS call is established in a cell, NCH is used to notify about ongoing calls to idle subscribers. Additionally Notification/FACCH is used to notify subscribers in dedicated mode. This is performed by broadcasting this messages to all active dedicated channels. The mobile station can then indicate the call, so the user can join the call. More importaint is the notification of the calling subscriber's MS, which initiated the call. This is done on the early assigned channel. The MS must know on which channel the call is placed. After leaving the uplink, it must know where to access the uplink the next time. Change-Id: I3ed14fa54a907891e492a7ada8e745a2c56cd46d Related: OS#4851, OS#5781
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 06:33:01 +0000