aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2021-09-20nm_*_fsm: Move to state Disabled NotInstalled Locked when shtudown proc endsPau Espin Pedrol1-0/+1
Change-Id: I5c070adbba6b4abb19467a02d6449a443657ae2b
2021-09-20nm_*_fsm: Set adminsitrative state 'shutting down' when shutdown procedure ↵Pau Espin Pedrol1-0/+1
starts Change-Id: I0d14840a55642812b865687a6cb208e7ffd22829
2021-09-20Allow setting administrative state through oml_mo_state_chg()Pau Espin Pedrol1-1/+1
This way it can be changed together with operative/availability state, and changes announced to the BSC if present. This commit presents no real change in osmo-bts behavior, since the only place where adm_state is passed different than -1 is in st_op_disabled_notinstalled_on_enter(), which is actually never called (yet) since it's the initial state and no other states transition later to it. However, this will change in the future once we support re-connecting to a (possibly different) BSC, which means objects will need to be moved to that state to restart the whole OML install procedure on the new BSC. Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
2021-09-20abis.c: Fix mess with priv->bsc_oml_hostPau Espin Pedrol1-1/+1
The pointer was used as "struct bsc_oml_host" sometimes, and other times as "struct llist_head". It just worked because bsc_oml_host->list is the first item in the script. The code was really confusing, also because the bts list of items has a name really similar to the one currently assigned. Let's rename the currently assigned address to "current_bsc", store it always as "struct bsc_oml_host*" and finally use llist_entry helpers when needed. The related code is also moved to a helper function to enclose there the logic to get next BSC in list. This change actually changes the logic where a remote address is removed from VTY, since now the next address in list is picked at the time, and later when reconnecting the list is forwarded another time, meaning one address will be skipped. This could be considered a bug, but this situation is really special and anyway the entire logic will be changed in new commits where we'll keep reconnecting in loop without exiting when reaching the end of the list, so we are fine with it. Think of this commit as a preparation commit for next ones. Change-Id: I3cc8a4148b3d63bc185b72dab8108105a6644910
2021-09-20abis.c: Transition to CONNECTED state only when OML link is upPau Espin Pedrol1-0/+1
This clarifies the different states and transitions between them: OML LINK UP: CONNECTING->CONNECTED ANY LINK DOWN: CONNECTING->CONNECTING, CONNECTED->FAILED In follow up commits, support to reconnect instead of exit after the BTS has already connected will be added, so only the last transition needs to be changed. Related: SYS#4971 Change-Id: I43e83b1b04fbaa1f87818c096e6ad3920801b1f6
2021-09-15abis.h: Drop unused statePau Espin Pedrol1-10/+0
Change-Id: I11173af3a543f6679ca9d43064bf071c214b1898
2021-09-14Support configuring TA loop SACCH block ratePau Espin Pedrol2-0/+3
Similar to what is already provided for power control loops. However, there's no existing way to communicate TA control parameters from the BSC to the BTS, so implement them locally in BTS vty. Related: SYS#5371 Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
2021-09-13MS Power Control Loop: Feed UL C/I from correct measurement periodPau Espin Pedrol1-2/+4
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is the value used over previous measurement period. Hence, we need to feed the algo with the measurements taken over that same period. Related: SYS#4917 Change-Id: I13c0014fdd73f823ae5b1256c35bfa7d97cfa334
2021-09-13lchan: Move TA CTRL param to its own substructPau Espin Pedrol1-2/+8
Field is renamed to look similar to similar fields in power control loop. This is a preparation commit, next one will add functionality to skip SACCH blocksi (P_CON_INTERVAL). Related: SYS#5371 Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
2021-09-13TA loop: Take into account UL SACCH 'Actual Timing advance' fieldPau Espin Pedrol1-1/+1
First step improving and reworking TA loop: Move trigger of the loop to similar place done by BS/MS Power Control Loop, that is, upon receivial of UL SACCH block, which contains information about the TA used to transmit the block encode in L1SACCH Header. Hence, from computed received TOA and TA used when transmitting from the MS, we can infer the desired TA to be used by the MS, which will send back to it later during DL SACCH block. The values taken are actually the ones calculated for the previous SACCH block and stored in lchan->meas.ms_toa256. That's because L1SACCH contains the TA used for the previous reporting period, similarly to what's specified for MS Power Control loop (TS 45.008 sec 4.2): """ The MS shall confirm the power control level that it is currently employing in the SACCH L1 header on each uplink channel. The indicated value shall be the power control level actually used by the mobile for the last burst of the previous SACCH period. """ (The reader may observe that currently this is not properly done for MS Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.) This new method also permits changing TA quicker, since we have more confidence that the TA we request is aligned with the one used to transmit, and we don't simply increment/decrement based on the value we request to transmit. Related: SYS#5371 Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
2021-09-11early IMM ASS: add configurable delay for RR IMM ASSNeels Hofmeyr1-0/+2
During live testing, it has become apparent that some IMM ASS still fail when sending the RR IMM ASS directly upon the target channel becoming active. Add a bit of delay after activation, to give some time for the channel to light up for the MS. Default is 50ms. Related: OS#5559 Change-Id: Ia1e63b98944dc840cde212fc732e20277cdc5585
2021-09-03BS Power Control Loop: Support EWMA average algo for RxQual measPau Espin Pedrol1-0/+1
params->rxqual_meas.upper_thresh is left unchecked in lchan_bs_pwr_ctrl() on this commit on purpose, to keep this commit with old behavior wrt to algo logic. Change-Id: If7e3987df89d680cfa443195ab2f225681d0e6cf
2021-09-03MS Power Control Loop: Support EWMA algorithm for C/I measurementsPau Espin Pedrol1-0/+1
Change-Id: I52eb0558fd7a215a6ee0b2aced189ae4a37d8a22 Related: SYS#4917
2021-09-03MS Power Control Loop: Take C/I into accountPau Espin Pedrol2-1/+10
This commit extends existing MS Power Control Loop algorithm to take into account computed C/I values on the UL, received from MS. The related C/I parameters used by the algorithm are configured at and provided by the BSC, which transmits them to the BTS similar to already existing parameters. Using C/I instead of existing RxQual is preferred due to extended granularity of C/I (bigger range than RxQual's 0-7). Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance" Table 10.3) provides detailed information about expected target values, even different values for different channel types. Hence, it was decided to support setting different MS Power Parameters for different channel types. These MS Power Parameters are Osmocom specific, ie. supported only by newish versions of osmo-bts. Older versions of osmo-bts should ignore the new IEs added just fine. The new IEs containing the MS POwer Parameters are not send for non osmo-bts BTSs, hence this commit is secure with regards to running osmo-bsc against an ip.access BTS such as nanoBTS. Related: SYS#4917 Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca Change-Id: I5dfd8ff9ab6b499646498b507624758dcc160fb6
2021-08-18add osmo_tdef groups, exposing T timers on VTY configNeels Hofmeyr1-0/+3
We have two osmocom specific timers used in the BTS, X1 and X2. Expose those on the VTY configuration, as timer group 'bts'. This prepares for a subsequent patch, where I would like to add another configurable timer. This provides the basic infrastructure for that. Related: SYS#5559 Change-Id: I0f56f9425134679219884b0c3c2f29e77aff5e64
2021-08-18enable Early Immediate AssignmentNeels Hofmeyr1-0/+5
When an Immediate Assignment comes in targeting an lchan that is not yet active, then hold back the RR Immediate Assignment until the channel becomes active. This allows the BSC to send the Immediate Assignment before first waiting for the Channel Activation ACK, saving one Abis roundtrip, and helping avoid double allocation on high latency Abis links. Related: SYS#5559 Related: I56c25cde152040fb66bdba44399bd37671ae3df2 (osmo-bsc) Related: Ifb2c62431a91dafa6116b5d6b9410930f00a6e18 (osmo-ttcn3-hacks) Change-Id: Ie52765b238b01f22fb327fe12327fbf10abcad4c
2021-08-16remove unused LCHAN_S_INACTIVENeels Hofmeyr1-1/+0
Change-Id: Ia738eaa796264fe0a97a2c86d6bbd37eaffe0a59
2021-07-19allow to configure multiple oml remote-ip addressesPhilipp Maier2-3/+15
At the moment we can only configure a single BSC in the BTS configuration. This also means that if this single BSC fails for some reason the BTS has no alternate BSC to connect to. Lets extend the remote-ip parameter so that it can be used multiple times so that an operater can configure any number of BSCs that are tried one after another during BTS startup. Change-Id: I205f68a3a7f35fee4c38a7cfba2b014237df2727 Related: SYS#4971
2021-07-06paging: prioritize CS related paging over PS related pagings.Philipp Maier2-1/+3
When the paging queue is filled up to a critical level, pagings from the PCU should be dropped as each immediate assignment paging from the PCU is worth 4 normal CS pagings. Also the PCU may still issue pagings if the paginging queue is already full and CS pagings are dropped. In a congestion situation it is more important to get the CS rather than PS pagings through. Change-Id: I30f97672d7a0c369c4a656e878ab8cbbd83e31ea Related: SYS#5306
2021-07-01osmo-bts-trx: implement BCCH carrier power reduction modeVadim Yanitskiy2-0/+8
The BCCH carrier (sometimes called C0) of a BTS shall maintain discontinuous Downlink transmission at full power in order to stay 'visible' to the mobile stations. Because of that, early versions of 3GPP TS 45.008 prohibited BS power reduction on C0. However, in the recent 3GPP TS 45.008 there is a feature called 'BCCH carrier power reduction operation'. This is a special mode of operation, where the variation of RF level for some timeslots is relaxed for the purpose of energy saving. In BCCH carrier power reduction operation, for timeslots on the C0 carrier, except timeslots carrying BCCH/CCCH, the output power may be lower than the output power used for timeslots carrying BCCH/CCCH. In this case the maximum allowed difference in output power actually transmitted by the BTS is 6 dB. The power reduction operation can be controlled by the BSC by sending BS POWER CONTROL on the A-bis/RSL with the Channel Number IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the transmission power on inactive timeslots of the BCCH carrier. This is a non-standard, Osmocom specific extension, so indicate support of this feature to the BSC in the feature vector. Also add a VTY command to allow enabling/disabling the power reduction locally. Add some signalling notes to the A-bis/RSL manual. For more details, see 3GPP TS 45.008, section 7.1. Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98 Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716 Related: SYS#4919
2021-06-30Support forwarding proto IPAC_PROTO_EXT_PCU BSC<->PCUPau Espin Pedrol4-0/+18
This new extension protocol is used to forward Osmocom PCUIF messages BSC<->BTS<->PCU. It will be sent re-using the IPA multiplex of the OML link between BSC and BTS. BTS is responsible for forwarding the message over the unix socket to the PCU. PCUIF existing RX path needs to be reworked in order to accept variable-size messages, in order to be able to transparently forward messages without knowing about them (the new container message is variable-length). Related: SYS#5303 Change-Id: I73fdb17107494ade9263a62d1f729e67303fce87
2021-06-30pcuif_proto.h: Add new container messagesPau Espin Pedrol1-0/+10
Related: SYS#5303 Change-Id: I8deef11f9ec191475c99133629cd5cd9048c4bcb
2021-06-29gsm_data: Drop unused function gsm_pchan_parse()Pau Espin Pedrol1-1/+0
Change-Id: I8f49811c1b694c5ef1fb9178d5ff4558172089b0
2021-06-18osmo-bts-trx: report PDCH interference levels to the PCUVadim Yanitskiy2-0/+12
The PDCH multiframe contains 48 data slots, 2 PTCCH slots, and 2 IDLE slots. The later two can be used for the interference measurements, since the UEs shall not transmit on them. bts_report_interf_meas() is called every 104 TDMA frames, what corresponds to 2 PDCH multiframe periods. Report interference levels on PDCH timeslots from this function. Change-Id: I56f83db5264c246ec1b4b8a973105a4fc09931fb Related: SYS#5313, OS#1569
2021-06-18osmo-bts-{trx,virtual}: get rid of dummy tx_idle_fn()Vadim Yanitskiy1-1/+0
This logical channel handler does nothing more than just logging. Change-Id: I438705f8dd902193e6c7b499d8ee55c56b6a1c2e
2021-06-18osmo-bts-trx: report interference levels to the upper layersVadim Yanitskiy1-2/+6
In trx_sched_ul_burst(), treat all BURST.ind and NOPE.ind mapped to inactive logical channels as interference. Average the RSSI values on the fly using a sliding average with constant a=0.5. Report averaged values for each logical channel every 104 TDMA frames (SACCH period) by calling gsm_lchan_interf_meas_push(). Change-Id: I4686448e42a40df56c1d27a14fd0a4d43fd144a5 Related: I78b6d8beffa5228a28231b75728e7aebdd3cb23c Related: SYS#5313, OS#1569
2021-06-18scheduler: reorder enum trx_chan_type, add TRX_CHAN_IS_DEDIC()Vadim Yanitskiy1-3/+7
With the new ordering, all TRXC_* values starting from TRXC_TCHF belong to dedicated channels. This is useful for the interference reporting logic, where we're not interested in broadcast channels. Change-Id: I7148f4d0bd1abbfe309bc5477e32a56d884533ea Related: SYS#5313, OS#1569
2021-06-18Report interference levels in RSL RF RESource INDicationVadim Yanitskiy1-0/+18
This change implements general interference averaging logic for the higher layers. In l1sap_info_time_ind(), where we receive TDMA time updates from BTS model, call rsl_tx_rf_res() for each transceiver according to the interval defined by the Intave parameter received from the BSC. In rsl_tx_rf_res() perform the actual averaging for each inactive logical channel, and then send everything to the BSC over the A-bis/RSL. The BTS model specific code needs to report the measurements for each logical channel every 104 TDMA frames (SACCH period) by calling gsm_lchan_interf_meas_push(). Change-Id: Id80fdbef087de625149755165c025c0a9563dc85 Related: SYS#5313, OS#1569
2021-06-05[VAMOS] osmo-bts-trx: schedule bursts on 'shadow' timeslotsVadim Yanitskiy1-0/+2
Change-Id: I3e0bdf8c03273f66991aa1764029ab1dd3528d7e Related: SYS#4895, OS#4941
2021-06-05[VAMOS] Implement the concept of 'shadow' timeslotsVadim Yanitskiy3-2/+21
Change-Id: I48b44b4df9ffb1cca105aebbd868c29b21f3b1d6 Depends: Ia0bd8695a3f12331b696fe69117189cdd48b584d Related: SYS#4895, OS#4941
2021-06-04[VAMOS] gsm_data: rework and rename gsm_lchan_name_compute()Vadim Yanitskiy1-1/+1
Change-Id: Id5cc40db04a654d94f5f75d4aad45439d66528cc Related: SYS#4895, OS#4941
2021-06-04[VAMOS] scheduler: add new GMSK training sequences from 3GPP 45.002Vadim Yanitskiy2-2/+2
Change-Id: I03fe712da5a3cc1a59f40a98a57f43306c3586c6 Related: SYS#4895, OS#4941
2021-06-04[VAMOS] osmo-bts-trx: rework handling of Training SequenceVadim Yanitskiy2-3/+12
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts' is always initialized in oml_rx_set_chan_attr() during the OML bootstrapping, so there is no need for gsm_ts_tsc() - remove it. Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can apply a different TSC value during the RSL CHANnel ACTIVation. Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'. These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS' field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros. Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b Related: SYS#4895, OS#4941
2021-06-01[VAMOS] common/scheduler: unify symbol names for training sequencesVadim Yanitskiy1-3/+3
Change-Id: Ice464e5b02b11b0f13df247fe6a01420a29bf1c5 Related: SYS#4895, OS#4941
2021-06-01[VAMOS] rsl: call bts_supports_cm() from rsl_handle_chan_mod_ie()Vadim Yanitskiy1-2/+2
Ensure that we check the PHY capabilities in both cases: * RSL CHANnel ACTIVation, and * RSL CHANnel MODE MODIFY, by calling bts_supports_cm() from rsl_handle_chan_mod_ie(). Modify bts_supports_cm() to accept a 'struct rsl_ie_chan_mode', so we can handle VAMOS enabled channel modes and CSD later on. Change-Id: I31a444592436705ec9d6ddade3cbfa7f8cb4bb91 Related: SYS#5315, OS#4940
2021-06-01[VAMOS] osmo-bts-trx: indicate MTS in Downlink TRXDv2 PDUsVadim Yanitskiy1-1/+4
Change-Id: I1a17a25883214c068f9b1a6d651128b8f760d1fb Related: SYS#4895, OS#4941
2021-06-01[VAMOS] osmo-bts-trx: implement and enable PDU batching for TRXDv2Vadim Yanitskiy1-2/+0
This change implements TRXD PDU batching approach b), which is described in section 25.3.4 of the user manual [1]. This approach is quite easy to implement on the transceiver side, so we can enable it by default. .Example: datagram structure for combination b) ---- +--------+----------------+---------+------------------------+ | TRXN=N | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits | +--------+----------------+---------+------------------------+ | TRXN=N | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits | +--------+----------------+---------+------------------------+ | TRXN=N | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits | +--------+----------------+---------+------------------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +--------+----------------+---------+------------------------+ | TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits | +--------+----------------+---------+------------------------+ ---- Other PDU batching approaches can be introduced later. [1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf Change-Id: I9b4cc8e10cd683b28d22e32890569484cd20372d Related: SYS#4895, OS#4941
2021-05-23[VAMOS] osmo-bts-trx: rework and split up bts_sched_fn()Vadim Yanitskiy1-0/+1
Currently, in bts_sched_fn() we send a Downlink burst to the PHY immediately after calling the associated logical channel handler. Together with the obvious performance advantages, this approach imposes some serious limitations. The code has already become quite complex with the introduction of the baseband frequency hopping, and now it's not possible anymore to extend it further. TRXD PDU batching, which is essential for VAMOS implementation, requires us to make the scheduler more flexible at the expense of increased memory consumption and additional CPU cycles. This patch splits up Downlink burst scheduling into 3 main steps: 1. bts_sched_init_buffers(): initialization of per-TRX Downlink burst buffers allocated by phy_instance_create(). For C0/TRX0 all timeslots are pre-initialized with dummy burst. 2. bts_sched_fn(): generating burst bits for all active lchans. 3. bts_sched_flush_buffers(): sending everything to the PHY. This approach allows us to a) get rid of the ugly tail in bts_sched_fn() that was responsible for sending dummy bursts on C0/TRX0; b) implement the PDU batching and have several variants of bts_sched_flush_buffers() providing the alternative batching approaches later on; c) implement PDU merging for the upcoming shadow transceivers. Change-Id: Iec78989517865b3275a9784d1042a5ebd1d2815f Related: SYS#4895, OS#4941
2021-05-23[VAMOS] gsm_data.h: introduce and use BTS_TSC macroVadim Yanitskiy1-0/+1
Change-Id: I0cf915d2d3a640aa1442cf6abe9a314261b4a64e Related: SYS#5315, OS#4940
2021-05-23[VAMOS] gsm_data.h: fix wrong bit-mask in BSIC2BCC macroVadim Yanitskiy1-1/+1
BCC takes 3 LSB bits of the BSIC, so we should apply 0b111 or 0x07. The BSIC is specified in 3GPP TS 03.03 section 4.3.2. Change-Id: Id24ad64e6c6de080ab43faa272daf844fbba6954 Related: SYS#5315, OS#4940
2021-05-23[VAMOS] common: make 'struct gsm_bts_trx_ts' pointers constVadim Yanitskiy1-3/+3
Change-Id: I0369ef4ae603a4afed0661a5894df6a7135b1919
2021-05-19common: make the arguments of phy_{link,instance}_name() constVadim Yanitskiy1-2/+2
Change-Id: Ic01d131148065c9143d3a90f8020e2e133941292 Related: CID#236092 "Dereference before null check"
2021-05-19osmo-bts-{trx,virtual}: fix: pinst->trx may be NULLVadim Yanitskiy1-1/+1
We assume that it's legal to have dangling PHY instances that are not associated with any TRX instances in the configuration file. Obviously, such PHY instances have pinst->trx set to NULL. The DSP based models seem to handle dangling PHY instances without any problems, so let's ensure that we always check pinst->trx against NULL in the osmo-bts-{trx,virtual} specific code. Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb Fixes: CID#236092 "Dereference before null check"
2021-05-18[VAMOS] Re-organize osmo-bts-trx specific structuresVadim Yanitskiy4-51/+40
Together with the 'generic' structures which used to be shared between osmo-bsc and osmo-bts some time ago, we also have the following osmo-bts-trx specific structures (in hierarchical order): - struct l1sched_trx (struct gsm_bts_trx), - struct l1sched_ts (struct gsm_bts_trx_ts), - struct l1sched_chan_state (struct gsm_lchan). These structures are not integrated into the tree of the generic structures, but maintained in a _separate tree_ instead. Until recently, only the 'l1sched_trx' had a pointer to generic 'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for 'l1sched_chan_state' one would need to traverse all the way up to 'l1sched_trx' and then tracerse another three backwards. + gsm_network | --+ gsm_bts (0..255) | --+ l1sched_trx --------------------> gsm_bts_trx (0..255) | | --+ l1sched_trx_ts --+ gsm_bts_trx_ts (8) | | --+ l1sched_chan_state --+ gsm_lchan (up to 8) I find this architecture a bit over-complicated, especially given that 'l1sched_trx' is kind of a dummy node containing nothing else than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'. In this path I slightly change the architecture as follows: + gsm_network | --+ gsm_bts (0..255) | --+ gsm_bts_trx (0..255) | --+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8) | | --+ l1sched_chan_state --+ gsm_lchan (up to 8) Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to 'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts') because there is no direct mapping. The former is a higl-level representation of a logical channel, while the later represents one specific logical channel type like FCCH, SDCCH/0 or SACCH/0. osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also affected by this change. Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-18scheduler.h: cosmetic: use #pragma onceVadim Yanitskiy1-4/+1
Change-Id: I551ce74f8cec8ec8d80768ec6c0559a203a8143c
2021-05-17sysmo,oc2g,lc15: Make RadioChannel MO depend on RadioCarrier MOPau Espin Pedrol2-1/+5
lower layer specific APIs require first to enable the TRX object (GsmL1_PrimId_MphInitReq, which requires ARFCN received during Set Radio Carrier Attributes) before enabling the per-TS structure. Hence, OPSTART must happen in RCARRIER MO before OPSTART can be sent to the Radio Channel MOs, otherwise the initialization of the TS objet will fail and OPSTART for the RadioChannel MO will send back a NACK. In order to avoid this, we need to keep the RadioChannel MO announced as "Disabled Dependency" until RCARRIER is OPSTARTed. Related: OS#5157 Change-Id: I8c6e5ff98c32a3cd5006f5e5ed6875bcabb1d85f
2021-05-11osmo-bts-trx: implement TRXDv2 protocol supportVadim Yanitskiy1-0/+14
Change-Id: I3532a6693bb335043ec390049138308991083e66 Related: SYS#4895, OS#4941, OS#4006
2021-05-11[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}Vadim Yanitskiy2-30/+28
Historically the logical channel handlers like rx_data_fn() used to accept quite a lot of arguments. With the introduction of additional measurement parameters it has become clear that we need to group the arguments into structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures were introduced. However, both channel type and burst ID were kept untouched, so until now we had them being passed between the scheduler functions here and there. This change is a logical conclusion of the original change mentioned above. As a part of this change, the new LOGL1SB() macro is introduced. It does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the context information for the old LOGL1S() macro. Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
2021-05-11[VAMOS] Merge bts_trx_init() into gsm_bts_trx_alloc()Vadim Yanitskiy1-1/+0
gsm_bts_trx_alloc() already does initialize some fields of the allocated 'struct gsm_bts_trx' instance, and having an additional function for initializing the other fields makes no sense. Note that I intentionally didn't merge a call to bts_model_trx_init() into gsm_bts_trx_alloc(), because this would break some assumptions regarding the order of initialization and cause regressions. This also allows us to not call bts_model_trx_init() from tests. Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
2021-05-09[VAMOS] struct gsm_bts_trx: fix the PHY instance pointerVadim Yanitskiy2-4/+3
First of all, there is no reason to use a void pointer because it's always 'struct phy_instance'. Also, no need to encapsulate this pointer into 'role_bts' because there are no other roles in osmo-bts (we used to have shared headers years ago). This commit also fixes a bug in test_sysmobts_auto_band(), where a pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst. Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 16:32:33 +0000