aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2023-09-15oml: refactor generation of Get Attribute ResponseVadim Yanitskiy1-113/+51
Change-Id: I531e88e789d09f8828a53813e3b2863faf0cc572 Related: OS#4505
2023-09-15oml: oml_tx_attr_resp(): pass *mo to handle_attrs_{bts,trx}()Vadim Yanitskiy1-14/+8
Change-Id: I78555d7226afd0c25efc100d95642634323a7b95
2023-09-15osmo-bts-{oc2g,lc15}: signal CBCH support to BSCVadim Yanitskiy2-0/+2
The model specific code seems to have everything needed for CBCH. Change-Id: I6b4d82223dc0bdcd94cd1269bfb02047cbebe480
2023-09-07rsl: Improve logic reactivating CCCH upon SI3 BS_AG_BLKS_RES changePau Espin Pedrol1-3/+15
The previous logic was wrong, since it was only reactivating the channel if the provided BS_AG_BLKS_RES was != 1. Example previously broken scenario: 1- osmo-bsc user sets "channel-descrption bs-ag-blks-res 2" during osmo-bsc startup in osmo-bsc.cfg 2- osmo-bsc user uses VTY to change it to "channel-descrption bs-ag-blks-res 1" 3- osmo-bsc user uses VTY to deploy the new config: "bts <0-255> resend-system-information" Step 3 would fail beforehand, ending up in a NO-OP. Change-Id: Ibc118e11c64f04de55cb7b94d8bf2c84b431774d
2023-09-07bts-trx: Fix CCCH not enabled if BS_AG_BLKS_RES!=1 is provided by BSCPau Espin Pedrol2-9/+16
Other bts models like sysmo,lc15,oc2g properly handled rel_act_kind=LCHAN_REL_ACT_REACT under the bts_model_lchan_deactivate() implementation, but bts-trx didn't. As a result, when BCCH_INFO(SYSINFO_TYPE_3) coming from BSC (RSL) containing a different BS_AG_BLKS_RES triggers CCCH re-activation, it would only deactivate it but not re-activate it. That means no SIs were being scheduled if bts was configured with "channel-descrption bs-ag-blks-res 2" in osmo-bsc.cfg, and phones would not see the cell. Related: OS#1575 Change-Id: I61e1681fbaa2c993b529d58b581c99166b62bda3
2023-08-31pcu_sock: print SAPI and msg_id when sending confirmationPhilipp Maier1-1/+2
At the moment we do not print the SAPI, nor the msg_id when we send a confirmation back to the PCU Change-Id: Ibd5b4225e597b69eaabaeee437fb637943a55602 elated: OS#5927
2023-08-31pcu_sock: use PCU_IF_SAPI_AGCH_2 instead PCU_IF_SAPI_AGCHPhilipp Maier3-7/+26
In PCUIF v.11 we use PCU_IF_SAPI_AGCH_2 exclusively. We use this SAPI to transfer IMMEDIATE ASSIGNMENT messages for uplink and downlink. In both cases we send a confirmation back to the PCU. For details see coresponding patch in osmo-pcu.git (see Depends) CAUTION: This patch breaks compatibility to current master osmo-pcu (See also "Depends") Related: OS#5927 Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292 Depends: osmo-ttcn3-hacks.git Iec00d8144dfb2cd8bcee9093c96a3cc98aea6458 Change-Id: I29858fa20ad8bd0aefe81a5c40ad77a2559a8c10
2023-08-29pcuif_proto: use confirm flag in struct gsm_pcu_if_pchPhilipp Maier1-5/+1
The PCU now sets a confirm flag in struct gsm_pcu_if_pch in case the MAC block (data) requires a confirmation when sent. Use this confirm flag instead of making the decision locally based on the MAC block contents. Related: OS#5927 Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04 Change-Id: I3364d2268bdef9c4d2feeb8e3d51a64e34bca68c
2023-08-26csd_v110: handle empty/incomplete Uplink frames gracefullyVadim Yanitskiy1-3/+9
Change-Id: I7cbf868df3ba5d390cea3d529eef26d18dbe55ab Related: OS#1572
2023-08-26csd_v110: properly set E1/E2/E3 for non-transparent dataVadim Yanitskiy1-3/+11
Change-Id: Ie38c12e462654cd9fe83a0420bc8ea8b476214b8 Related: OS#1572
2023-08-26csd_v110: fix comments in csd_v110_rtp_{en,de}code()Vadim Yanitskiy1-4/+4
Change-Id: I6fee665e587bfa76058187e13f0cdafaea991940 Related: OS#1572
2023-08-22bts: make bts_agch_dequeue staticPhilipp Maier1-1/+1
The function bts_agch_dequeue() is not used outside of bts.c, so it can be a static function. Change-Id: If86293ebbd99d6550022aeb8721d40bca5fc04fc Related: OS#5927
2023-08-10pcuif_proto: get rid of _DT, _dt (Direct TLLI)Philipp Maier1-11/+11
Since we now no longer refer to TLLI when we mean "message ID" (msg_id), we should also remove the "_DT" / "_dt" suffix from structs and define constants and replace it with "_2" if required. Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0 Change-Id: Icf85f60ae86fbe1f3b98e1457c0598bb09cb08c5 Related: OS#5927
2023-08-08pcu_sock: get rid of fn parameter in pcu_tx_pch_data_cnfPhilipp Maier2-3/+2
The function pcu_tx_pch_data_cnf() gets a parameter fn (frame number). This parameter is then used to populate the member fn in gsm_pcu_if_data_cnf_dt of the PCUIF protocol. However, the PCU only uses this parameter for logging and nothing else. Hence it it is not needed and we can remove it. Related: OS#5927 Depends: osmo-pcu.git I35bc99eaec5d0287ae3916bc668f0babaddfd6ce Change-Id: Id1c8fa77725129ec2ea7e92e1df493f35a277659
2023-08-08pcuif_proto: rename tlli to msg_idPhilipp Maier2-7/+7
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an identifier and the related struct member is also called "tlli". Unfortunately this is misleading since the message identifier does not necessarly have to be a TLLI. It is just an implementation detail that osmo-pcu uses the TLLI as a message identifier. To make that clear, lets rename the tlli member (and variable and parameter names where it is passed on) to "msg_id". (Since this change only renames variables and struct members it will not break compatibility with other programs that use the PCUIF) Related: OS#5927 Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6 Change-Id: Ie6b34d5df64f4bed6b14581c7957dcba6af44136
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 Yanitskiy1-2/+19
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 Yanitskiy4-13/+213
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 Eversberg1-52/+4
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 Eversberg2-0/+13
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 Eversberg2-0/+79
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 Eversberg3-19/+112
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 Eversberg3-0/+25
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 Yanitskiy1-1/+3
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 Welte8-20/+304
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 Yanitskiy2-2/+4
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 Yanitskiy8-70/+262
* 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 configurablearehbein4-5/+23
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 Welte1-0/+5
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 Eversberg2-14/+14
Change-Id: I72e30fe852ab69a162b117a534071ebddd4b16ba
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-25 08:31:48 +0000