aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2019-06-13l1sap: Compute statistics on FN advance in PH-RTS.indHarald Welte3-0/+36
Let's keep some statistics about the min/max/average frame number advance that we're observing above L1SAP when comparing the time in the PH-RTS.ind and the frame number we observe in PH-DATA.ind of data that was received on the uplink. The statistics are currently only shown in the VTY, but this is a precursor to using them to correctly advance the LAPDm timers in a follow-up patch. Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2 Related: OS#2294 Related: OS#3906
2019-06-08common/scheduler.c: refactor description of TRXC_* lchansVadim Yanitskiy1-98/+452
Let's avoid fancy alignment in the description of logical channels for the benefits of having better readability, the ability to add more comments and fields without making it look ugly. Get rid of value-string array 'trx_chan_type_names', since each logical channel has its name defined in 'trx_chan_desc'. Get rid of field 'chan' of 'trx_lchan_desc' structure since it's not used anywhere, and not actually needed because the position of each lchan description is defined by its TRXC_* type. Replace both 'pdch' and 'auto_active' fields with more generic bitmask field called 'flags', and define the following flags: - TRX_CHAN_FLAG_AUTO_ACTIVE, - TRX_CHAN_FLAG_PDCH. Use RSL channel mode #defines from libosmogsm instead of having hard-coded numbers. This increases readability. As a bonus, let's add a human readable description to each lchan definition, so it can be printed in the VTY some day. Change-Id: I9d5d49ec569f133d37b8164b22607d4700474315 Backported from: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843 I7ab4958801b3422973b67ff0452b90afa8a3f501
2019-06-05Use #define RSL_CHAN_RACH for RSL Channel Number of RACHVadim Yanitskiy5-5/+5
Change-Id: I7f54fccdae6799e5f4d956a101e11c2d6f998546
2019-06-04bts-trx: trx_if.c: Introduce logging macro LOGPPHIPau Espin Pedrol2-44/+36
This way we unify format. We take the chance to add related information to some log messages which were not printing that information (and was confusing when using more than one phy instance). Change-Id: I5b17a01638ade9a6c41da73e550d5947fa92f568
2019-06-03common/bts.c: bts_supports_cm(): take care about GSM48_CMODE_SIGNVadim Yanitskiy1-0/+5
At the moment, bts_supports_cm() is only called on reception of RSL Channel MODE MODIFY from the BSC. The idea is to check whether the indicated RSL channel mode is supported by a BTS model. RSL Channel MODE MODIFY message may indicate a channel in signalling mode, i.e. GSM48_CMODE_SIGN, which has always been rejected so far. Let's assume that signalling is always supported, as there is no special BTS_FEAT_* definition to check that. This change should make BTS_Tests.TC_rsl_modify_encr pass. Change-Id: I8ea98a3eb9dc15a04f665596ee276883eb824b9a
2019-06-01common/rsl.c: RSL_IE_HANDO_REF is mandatory for handover CHAN ACTVadim Yanitskiy1-3/+7
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference element must be included if channel activation type is 'handover'. Let's properly reject CHANnel ACTivation messages with missing RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted as regular (non-handover) channel requests. Found using TC_ho_rach() TTCN-3 test case. Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
2019-06-01osmo-bts-trx/l1_if.h: drop unused ho_rach_detect from trx_l1hVadim Yanitskiy1-1/+0
Change-Id: I90b6d7fb1bb7ba2f8b1f500043635b0ae5cb4495
2019-06-01osmo-bts-trx/trx_if.c: dropping Tx bursts is a noticeable eventVadim Yanitskiy1-2/+1
Change-Id: Ia954b797a9bb90660b6548ec0ffb218a1dcff37a
2019-05-29osmo-bts-lc15: Change LED behaviour to be the same as oc2gDaniel Willmann1-10/+30
It looks like the status LED on the sysmobts2100 never worked correctly since lc15bts-mgr expects osmo-bts-lc15 to create and manage /var/run/osmo-bts/state, but there is nothing to do so in osmo-bts. This patch copies the functions from oc2g to manage the state file in lc15. Change-Id: Iad32a22fc72e2aba45e4f1b9ae585f6e0b8757ed Related: SYS#4493
2019-05-29osmo-bts-oc2g: Fix status LED responsibilitiesDaniel Willmann1-10/+2
osmo-bts-oc2g no longer modifies the status LED and instead leaves that to the bts manager. The service file now also creates a directory in /var/run needed for osmo-bts to communicate with oc2gbts-mgr. This status file is used by oc2gbts-mgr to figure out when the bts is operational. Related: SYS#4493 Change-Id: Ifae634c6c2ecec7d32298c0f266f91f3e81308f5
2019-05-28clear GPRS indicator in SI3 while PCU is disconnectedHarald Welte3-9/+57
osmo-bts cannot provide GPRS service while osmo-pcu is not connected. The BSC has no knowledge of the PCU connection state. Prevent MSs from trying to register for GPRS while the PCU is disconnected by erasing the GPRS Indicator in SI3. Change-Id: I1a6f5c636c0fe098ee31c280d4572a3f8122b44b Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git) Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git) Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git) Related: OS#3075
2019-05-28lc15,sysmo,oc2g: fix dsp-trace-flag commandNeels Hofmeyr3-3/+3
Remove the '~' from '|= flag', it is plain wrong. This affects the correct parsing of DSP trace flags from the config file only. The bug is not present in the interactive VTY command at runtime. Change-Id: I915971f49642967c969f5dd475e8faa960ef3960
2019-05-27Fix passing of RR SUSPEND REQ from DCCH to PCU socketHarald Welte1-9/+33
The existing code ssumed that the RR SUSPEND REQ would be a LAPDm/RSL unitdata request. I couldn't find any spec reference that would support this. Rather, the message is sent via the normal main dedicated channel, which is operated in ABM mode. As the somewhat similar check for diverting measurement results is in fact looking for UNITDATA, we have to untangle this slightly. Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6 Related: OS#2249 Related: OS#4023
2019-05-26common/rsl.c: fix NULL-pointer dereference in rsl_rx_rll()Vadim Yanitskiy1-2/+2
Change-Id: I07e39e69a42dd09841f5d03608ec0d0b2345139a Fixes: CID#198663 Null pointer dereferences
2019-05-25Add severity to OML FAILURE EVENT REPORTHarald Welte8-47/+48
Example: The fact that the PCU has connected with a given version is not a *failure* in the first place, particularly not a MAJOR one. Let's allow callers of oml_tx_failure_event_rep() specify the serverity of the event that they're reporting to the BSC. Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
2019-05-24oml: Have one generic log message for all transmitted messagesHarald Welte1-6/+2
Rather than open-coding "Tx foobar..." in various functions (and forgetting it in half of them), let's add a generic message into oml_mo_send_msg(). Change-Id: I5dd4b1749e68fb7fc74cb2e3a778d2418f46b770
2019-05-24oml: Print more context from FOM Header or using MOHarald Welte1-28/+31
Some of our OML log lines were missing any context. Try making more sense by printing any context information about the given managed object, TRX, ... as we have it. Change-Id: I60d1660c6d574f206d7b8cc10082b413142365dd
2019-05-24l1sap: Fix calculation of expired RACH slots in case of missing frame numbersHarald Welte1-2/+5
In case of a Combined CCCH (with SDCCH/4), the number of RACH slots depends on the frame number. So in case of lost/skipped frame numbers, we cannot simply compute the value for the current fn and then multiply it by the number of frame numbers expired. Rather, we have to 'replay' all missed frame numbers and individually determine how many RACH slots happened in that frame. Related: OS#3750 Change-Id: If4f8d2ea55fc722c64c330cde09e833b67ee98fe
2019-05-24l1sap: Correctly count RACH slots in calc_exprd_rach_frames()Harald Welte1-4/+1
We used a bogus multiplication factor of four when computing the number of expired RACH slots. While there are four RACH slots per block (i.e. 4 times more RACH received than normal MAC blocks), that multiplier doesn't apply here: We are calling this function per *frame* and not per *block*. So the maximum number of RACH slots per *frame* is (in most suual cases with a single CCCH) at maximum 1. Only some obscure configurations with multiple CCCHs in a single cell would render higher values. In any case, *blocks* never even enter this equation. This wrong multiplier resulted in rather weird RACH load reports to the BSC. Related: OS#3750 Change-Id: I6b14fd6e7819f9164fb4a09b432a9f419e3b6e5c
2019-05-24load_indication: Fix missing re-set of RACH parametersHarald Welte1-0/+1
While we re-set the PCH load counters after every report, we never actually re-set the RACH load counters. This meant that the period/window for RACH load averaging would always grow, rather than being reset every load indication period. Related: OS#3750 Change-Id: Icd9150ba56d77d031c3cf496c5936c2de52b364c
2019-05-24rsl: MS POWER COCNTROL isn't (only) about "forcing" power levelsHarald Welte1-1/+1
...so let's have a more neutral error message Change-Id: I1ffa336b18347c2fcedfeb398b255dc517245d7a
2019-05-24rsl: Implement parsing of BS Power Control messageHarald Welte1-0/+44
Change-Id: Id144a7e468f730e3cdaefa4cf2ad51c6106310a2
2019-05-24RSL: Fix logic about fixed/dynamic MS power control in MS POWER COMMANDHarald Welte1-6/+21
The spec is quite clear: If the MS Power Parameters IE is present, then the BTS shall perform autonomous MS power control. If it's absent, then the MS power shall be fied. Let's adjust our code accordingly. Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5 Related: OS#1622
2019-05-24Use LOGPLCHAN whenever possibleHarald Welte6-210/+150
There's no point in open-coding what LOGPLCHAN was created to do: Log some event while stating the name of the logical channel. Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
2019-05-23cbch: Improve verbosity and extend logging; Always indicate BASIC/EXTD CBCHHarald Welte1-19/+35
Change-Id: I6c8f9fc6215b616371e46c1f4ca4e44b8c7ac096
2019-05-23cbch: Add counters; queue length limits and CBCH LOAD reportingHarald Welte4-2/+123
This adds the final missing part to full CBCH support: * keep a tab on the current queue length for basic + extended CBCH * keep rate counters about the number of sent / transmitted SMSCB * send CBCH LOAD information via RSL to the BSC Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
2019-05-22sysmo: Fix "nominal power" / BS power display in VTYHarald Welte1-1/+1
The function get_p_max_out_mdBm() returns a value in 1/1000th of dBm, "milli-dBm", while trx->nominal_power is only whole dBm. We were missing the required divider of 1000 ever since Change-Id Ieff75d5becaa80a2097b6e744c75c2d16259c9a4 was merged in February 2017. The good news is that this really only affected the VTY output and not any actual operational aspect of the system. Change-Id: If92d0b15c48dafc63776b82c7ff5f3c2b3505f68 Closes: SYS#4570
2019-05-21cbch: Keep SMSCB queue length counterHarald Welte2-14/+5
This avoids having to iterate the list to count the number of elements. Change-Id: I72c47affeb87c9b898bc2290dc7ed113945f1805
2019-05-21cbch: Support Extended CBCHHarald Welte4-29/+58
The logic for Extended CBCH are the same as for the Basic CBCH, we just need to * duplicate our related state * parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE * start to send data on the Extended CBCH (TB=4..7) Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429 Closes: OS#3535
2019-05-21cbch: Fix memory leak and send error message on invalid SMSCB commandHarald Welte2-3/+10
Change-Id: I411d1fb3693a2f7cf7bba3d38b1aaf276a4137ba Related: OS#4011
2019-05-21cbch: Implement support for DEFAULT messageHarald Welte1-13/+37
The BSC can not only send us each to-be-sent message separately, but it can also configure a DEFAULT message, which is then to be sent instead of the NULL message. Let's add support for this Change-Id: I65a79215b54155d128c26d2ca11ff9ff3ed2cdba Closes: OS#4013
2019-05-21cbch: Log every RSL SMSCB COMMAND with type and number of blocksHarald Welte1-3/+15
Change-Id: I20efe0aa5a67f011d6b6bead57236366c2f45ecf
2019-05-21cbch: Refactor get_smscb_block() / remove smscb_msg.next_segHarald Welte1-19/+25
There's no need to keep around a pointer to the next segment in a SMSCB message. The way how the multiframe structure is laid out (and how the tb number works), we can use the result of a modulo-division on the frame number to determine which of the segments/blocks inside a SMSCB message (page) we have to transmit. This also acts as a simplification in preparation of support for the SMSCB DEFAULT type. Change-Id: I48faa19fec4a0852e6112ca2faa98960c678d4c5 Related: OS#4013
2019-05-21cbch: Implement handling of "Schedule" messageHarald Welte1-2/+10
The first block of "schedule" messages must be advertised with a special sequence number coding, see Table 1 of 3GPP TS 44.012. Change-Id: I473edf698eba7ff5008f2fd1ec1776f0aa013858 Closes: OS#4012
2019-05-21RSL: Fix off-by-one error when parsing SACCH INFO IE in RSL CHAN ACTHarald Welte1-1/+1
This off-by-one error in length verification caused all SACCH INFO IE to be deemed invalid and hence any RSL CHAN ACT with that IE to be rejected. Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e Related: OS#3750
2019-05-21RSL: Reject RLL messages for lchans that are not active yetHarald Welte1-0/+8
The Radio Link Layer (RLL) messages only make sense when a given logical channel is active. If it isn't active, let's reject the messages with an RSL ERROR REPORT with cause "Message sequence error", wich according to spec means: "A message with an existing message type which is not possible according to the specification and to the state of the BTS is erroneous." Related: OS#3750 Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
2019-05-20rsl: Include Channel Nr and Link ID in Error reports whenever possibleHarald Welte1-13/+27
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we still should include it whenever possible to help error analysis. Related: OS#3750 Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
2019-05-20rsl: Send RSL Error Report in case of unknown/unsupported msg_typeHarald Welte1-1/+14
Send an RSL Error Report in case of unknown/unsupported msg_type, as describedi in section 7.3 of 3GPP TS 48.058. Related: OS#3750 Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
2019-05-10osmo-bts-sysmo: fix: indicate BTS_FEAT_CBCH support on OMLVadim Yanitskiy1-0/+1
It seems osmo-bts-sysmo does support CBCH (Cell Broadcast), but for some reason it doesn't report BTS_FEAT_CBCH to the BSC. Change-Id: I42dd3f84c44c210d9255e17153372bf252f897a1
2019-05-09osmo-bts-trx: distinguish 11-bit Access Bursts by synch. sequenceVadim Yanitskiy1-43/+124
Thanks to both TC_rach_content and TC_rach_count TTCN-3 test cases, it was discovered that there are possible collisions when trying to decode a regular 8-bit Access Burst as an 11-bit one. This is exactly what we are doing in rx_rach_fn(): - calling gsm0503_rach_ext_decode_ber() first, - if it failed, falling-back to gsm0503_rach_decode_ber(). With default BSIC=63, the following 8-bit RA values are being misinterpreted as 11-bit Access Bursts: Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f According to 3GPP TS 05.02, section 5.2.7, there are two alternative synch. (training) sequences for Access Bursts: TS1 & TS2. By default, TS0 synch. sequence is used, unless explicitly stated otherwise (see 3GPP TS 04.60). According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability can be indicated by the MS using one of the alternative training sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme. In other words, knowing the synch. sequence of a received Access Burst would allow to decide whether it's extended (11-bit) or a regular (8-bit) one. As a result, we would avoid possible collisions and save some CPU power. Unfortunately, due to the limitations of the current TRXD protocol, there is no easy way to expose such information from the transceiver. A proper solution would be to extend the TRX protocol, but for now, let's do the synch. sequence detection in rx_rach_fn(). As soon as the TRX protocol is extended with info about the synch. sequence, this code would serve for the backwards-compatibility. This change makes the both TC_rach_content and TC_rach_count happy, as well as the new TC_pcu_ext_rach_content() test case aimed to verify extended (11-bit) Access Burst decoding. Related (TTCN-3) I8fe156aeac9de3dc1e71a4950821d4942ba9a253 Change-Id: Ibb6d27c6589965c8b59a6d2598a7c43fd860f284 Related: OS#1854
2019-05-08handle NULL return from rate_ctr_group_alloc()Harald Welte1-0/+4
Change-Id: I2170e400e47369e9171af4c7361aa2177fea1174 Related: OS#3701
2019-05-07common/oml.c: fix: properly encode NM_ATT_SW_CONFIGVadim Yanitskiy1-6/+33
According to 3GPP TS 52.021, sections 9.4.61-62, 'SW Configuration' shall contain a list of 'SW Descriptions' related to the MO. In other words, all 'NM_ATT_SW_DESCR' blobs shall be encapsulated into a single NM_ATT_SW_CONFIG attribute. For some reason, they were not encapsulated properly, so OsmoBSC were unable to parse the 'SW Descriptions'. However, unlike OsmoBSC the old OpenBSC does not expect this encapsulation, thus after this change it will be unable to parse the 'SW Descriptions'. Change-Id: Id26104719891944f3e2151df362bd45bb057a9c5 Related: OS#3938
2019-05-07common/oml.c: refactor Get Attribute Response message generationVadim Yanitskiy1-67/+53
Instead of allocating two transitional buffers (one static, another dynamic), we can use the existing message buffer. Both handle_attrs_bts() and handle_attrs_trx() can put (append) the reported attributes, and push (prepend) non-reported ones as per 3GPP TS 52.021, 9.4.64 "Get Attribute Response Info". Change-Id: I349447a43bce360f59e0c6b435906c65167d158b
2019-05-05common/oml.c: fix broken debug print in down_mom()Vadim Yanitskiy1-2/+2
Change-Id: Ideac59946d50c6e06052a9590e02cfcfbf23d003
2019-05-05common/oml.c: use proper format specifier for uint16_tVadim Yanitskiy1-2/+1
Change-Id: I8f372a689b3c1cc2cf925654b2db44a0f4ee7603
2019-05-05common/oml.c: introduce and use both LOGPFOH and DEBUGPFOHVadim Yanitskiy1-51/+44
Change-Id: I9e9d6ccb88c9c9d35b2ce5778fa2580382704089
2019-04-24common/paging.c: fix unaligned pointer accessVadim Yanitskiy1-6/+22
Passing a pointer to a packed structure to tmsi_mi_to_uint() may result in unaligned pointer value. Found with clang-8. Change-Id: Ief69854973a098e6da7c05f4417dc11988edd777
2019-04-24common/rsl.c: fix unaligned pointers in rsl_add_rtp_stats()Vadim Yanitskiy1-24/+24
Found using clang-8: rsl.c:1646:7: warning: taking address of packed member 'packets_sent' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1646:28: warning: taking address of packed member 'octets_sent' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1647:7: warning: taking address of packed member 'packets_recv' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1647:28: warning: taking address of packed member 'octets_recv' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1648:7: warning: taking address of packed member 'packets_lost' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter' of class or structure 'ipa_stats' may result in an unaligned pointer value Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
2019-04-23common/rsl.c: fix size argument in memcmp() callVadim Yanitskiy1-1/+1
Found using clang-8: rsl.c:1607:93: warning: size argument in 'memcmp' call is a comparison [-Wmemsize-comparison] rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead? It looks more logical to compare the result of memcmp() against zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size. Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
2019-04-21common/l1sap.c: fix: add missing new line to a debug messageVadim Yanitskiy1-1/+1
Change-Id: I7c0dab255289a5847d1a0af009e8962e4410e5ca
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 15:08:27 +0000