Fix error introduced in 1275a3f91a by
using signed 32 bit integer which is enough for Frame Number in
GSM. Also, mark parameter constraints more explicitly:
- add assert for expected FN values
- don't perform computation for non-relative FN
The error was:
bts.cpp: In member function ‘uint32_t BTS::rfn_to_fn(uint32_t)’:
bts.cpp:554:25: error: call of overloaded ‘abs(uint32_t)’ is ambiguous
if (abs(rfn - m_cur_rfn) > RFN_THRESHOLD) {
^
In file included from /usr/include/c++/6/cstdlib:75:0,
from /usr/include/c++/6/stdlib.h:36,
from /usr/include/osmocom/core/linuxrbtree.h:97,
from /usr/include/osmocom/core/timer.h:35,
from ./bts.h:29,
from bts.cpp:21:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
In file included from /usr/include/c++/6/stdlib.h:36:0,
from /usr/include/osmocom/core/linuxrbtree.h:97,
from /usr/include/osmocom/core/timer.h:35,
from ./bts.h:29,
from bts.cpp:21:
/usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^~~
/usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
abs(long long __x) { return __builtin_llabs (__x); }
^~~
/usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int)
abs(long __i) { return __builtin_labs(__i); }
Change-Id: Ib6d895a97aa35414f245ea4406c6e78f1b4fb5b8
The implementation of the method rcv_rach() in class BTS, restores
the absolute frame number of the incoming RACH-Request by using
the relative frame number (RFn = Fn mod 42432) from the rach
request and the already known internal absolute frame number
m_cur_fn, which is continusly updated by the CCU interface.
In some rare cases, a RACH request might be received by the BTS,
a very short time before the frame number wraps in its 42432.
Depending on the PCU location, RACH request might be received
by the BSC, which forwards it to the PCU. It is then likely
that, while the RACH request is being forwarded to the PCU, the
PCU internal absolute frame number wraps before the RACH
can be processed. The relative frame number from the rach
request would then be interpreted as if it were received after
the wrapping of the internal frame number modulos.
This commit adds logic to detect and resolve this race condition.
Also a unit test is added to check some cornercases.
Change-Id: I74f00c11e5739d49f370ce6c357149e81d9aa759
In libosmocore, my patch was merged to master a bit too soon. To accomodate the
request for naming that matches the general "LOG" prefix instead of "LOGGING",
a fixup was committed to libosmocore. Adjust for that.
Original patch: change-id I5c343630020f4b108099696fd96c2111614c8067
The fixup: change-id I424fe3f12ea620338902b2bb8230544bde3f1a93
Change-Id: I4db4a668f2be07f3d55f848d38d1b490d8a7a685
Solves a sanitizer issue where punct2 is unset when passed to
gprs_rlc_mcs_cps() and thus takes a value not defined in the enum.
Change-Id: I004cbbab15e6ffa2749f4b7f1df651517c2ae693
The rach request contains a relative frame number (Fn % 42432),
while BTS::rcv_rach() accepts the full frame number only.
Since the BTS is always aware of the full frame number this is
not a problem. But for BSC co-located PCU schemes it is a problem
since the rach request only contains the relative frame number
as mentioned above.
The pcu continusly receives frame number updates with the GSM time
indication message. It is simple to re-calculate the full frame
number from that information.
This patch makes BTS::rcv_rach() compatible with relative frame
numbers, while not breaking the compatibility for full frame
numbers
Change-Id: Iaa182d8d29c6a0f5fa06064c2eb48b21b1ba2775
When Packet resource request is received, PCU will generate the
packet access reject if no resources are present. The encoding is done
based on section 7.1.3.2.1 and 8.1.2.5 of 44.060 version 7.27.0 Release 7.
This patch also includes the test case to validate the generated
packet access reject message.
This patch is integration tested on Osmo-trx setup with Ettus B210 board
and LG F70 MS with some simulation code changes in Osmo-pcu.
Change-Id: I05ff25124b58905586caa0c0c37023d69724f121
This test case is for testing generation of
EGPRS PUAN. Corresponding log files .ok and .err
are modified.
Change-Id: I18e6d4a9e90fd6453fe14187beab27dfeae8dbe9
This adds compression of bitmap in PUAN. The compressed bitmap
is used only if the number of bits in the bitmap does not fit in
the message and there is a gain after compression.
The algorithm is part of libosmocore and so there is dependency
on the libosmocore for compilation.
The algorithm is tested on integration setup by forcing compression.
Change-Id: Id2eec4b5eb6da0ebd24054b541b09b700b9b40ba
Array indexing mismatch is corrected for SPB counters.
(bts_ctr_description with the bts counter declaration).
Change-Id: I9b17ca0f838a37d9405cebf2319e722a302f5ed9
Add value_string describing UL and DL TBF states and use it for logging
errors while freeing TBFs.
Change-Id: I292ec81ab602c65ef86e6e3e85740182b63474b6
Issue:Though the rate_ctr framework is used in osmo-pcu for bts statistics,
the interval counters are always 0.
Fix:rate_ctr_init is added in the startup which arms the timer and hence
the rate ctr intervals is displayed with proper values.
Change-Id: Ib0f33d2de9406aa7436aa9aeb6a8dabdff96383b
Adds spb counters at BTS level(show bts statistics).
Adds RLC/MAC downlink control msg at ms level(show ms imsi <imsi_val>).
Adds the number of coding schemes counter for UL at TBF level.
Change-Id: Icbe4ba95e34bea89ee36f532d099db68204b7c38
Adds DL throughput in show ms imsi <imsi_value>.
Adds the number of coding schemes counter and rlc nacked counter at TBf level.
Change-Id: Ia95b0404989b00db0e7ba416bc40d09ef41fde1c
So far, we used to keep a copy of the header file around in
both osmo-pcu and osmo-bts projects. Before we start introducing
a third copy in openbsc, let's have the osmo-pcu install the header
file and make the other programs use that.
Change-Id: I60976c9be5488256d1ff55fdc5aa548e3705400d
In the existing code, GSMTAP messages were only generated in case no
direct PHY access was being used (i.e. in the case all user traffic goes
over the PCU socket). I'm not quite sure what the reason is for that
would be and conclud this is not intentional.
Let's first send the message to GSMTAP and then decide whether to send
it via the direct PHY access or via the PCU socket into the BTS/BSC.
Change-Id: I5d2e018f7009cb947abc874881c0c440feca3ade
When PDAN/EPDAN with channel description is received, PCU will generate the
packet access reject if no resources are present. The encoding is done
based on section 7.1.3.2.1 and 8.1.2.5 of 44.060 version 7.27.0 Release 7.
This patch also includes the test case to validate the generated
packet access reject message.
This patch is integration tested on Osmo-trx setup with Ettus B210 board
and LG F70 MS with some simulation code changes in Osmo-pcu.
Change-Id: I096a3bb44a65533b9e9b091925dd5f70a8696d6
When RACH is received, PCU will generate the Immediate assignment reject
message if no resources are present. The encoding is done based on section
9.1.20 of 44.018 version 11.7.0 Release 11. This patch also includes the
test case to validate the generated Immediate assignment reject message.
This patch is integration tested on Osmo-trx setup with Ettus B210 board
and LG F70 MS with some simulation code changes in Osmo-pcu.
Change-Id: I3d33e2b9746fa4f338fad0e6b63b1c5f07de6f9b
Move writing Timing Advance IE and Timing Advance Index into separate
functions to simplify adding PTCCH support. This also fixes previous
incorrect (and unused) code for writing Packet TA IE which has not set
TS for TA.
Change-Id: I786bf7fc999d401cc3d9e7f1e7a1fba953b5d458
Related: OS#1545
Fix alignment of EPDAN outside the RLC transmit window,
according to section 9.1.8.2.4 in 44.060 version 7.27.0 Release 7.
The specification explains that a bit within the uncompressed bitmap
whose corresponding BSN is not within the transmit window shall be
ignored. Without this fix PCU was dropping the EPDAN message and not
updating the status of BSNs which are inside the RLC window. This patch
updates the status of the BSNs which are inside the window and ignores
the remaining bits.
Related: OS#1789
Change-Id: Id07d178970f168f5389016c1eea31eb6b82057b6
Separate qbit-TA to TA conversion into separate function and use it for
computing and updating Timing Advance.
Note: the code was tested with TA=0 only to make sure it does not
introduce regressions.
Change-Id: I96fdbb20b09fb85fdd9fb6dcf3c25f6bee7f80e4
Fixes: OS#1531
This reverts commit f1a7b8fc66.
Conflicts:
tests/tbf/TbfTest.err
The commit broke GPRS service at least for osmo-bts-sysmo on a SysmoBTS 1002
with current master of osmo-bts (ef30f50d5d6d5f863fc147d05ccdceb89284934e).
The error observed is the following log output (was viewing both osmo-bts-sysmo
and osmo-pcu logs interleaved):
<0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission
<0002> tbf.cpp:893 - Assignment was on CCCH
<0002> tbf.cpp:899 - No uplink data received yet
<0007> l1sap.c:904 RACH for packet access
<0001> pcu_l1_if.cpp:311 RACH request received: sapi=1 qta=0, ra=121, fn=13653
[repeat]
When removing this single commit from current osmo-pcu master, GPRS service
works well on SysmoBTS, with current osmo-bts master.
The TbfTest.err expected output needed adjustment after the revert.
Disclaimer: I am not aware of adverse effects this commit may have. I have no
idea what the WAIT_ASSIGN state is used for -- further review is required.
Change-Id: I1532f8e93194368cdc1e3846f82afa6d68cd5fbd
All callers now check the pointer before calling it.
gcc6 is optimizing `if (!this) {CODE}` as this is assumed to never be a
std::nullptr here.
Change-Id: I918a094e0dc59098a9eb00d152c9ae42d36b3a99
gcc6 is optimizing if (!this) {CODE} as this is assumed to never be a
std::nullptr here. Move the null check to the caller. In preparation of
removing the check within llc_queue->size(), all callers must check the object
before calling it. Make sure of that: make the llc_queue() access function
protected and offer only a public llc_queue_size() function that incorporates
the NULL check. All current callers are only interested in the
llc_queue_size().
Tweaked-by: nhofmeyr
Change-Id: I88cc3180f8f86785e3f07981895dabddf50b60a2
Implemented tree based algorithm to decode compressed bitmap in EPDAN
as described in section 9.1.10 of 3GPP 44.060.
This algorithm intends to improve the performance over existing method.
New Regression test is added under bitcomp directory.
Test case is added to validate decompressed result of the bitmap
Present in EPDAN.
Test is done for multiple bitmaps of varying length.
Invalid inputs are also part of the test vector.
Change-Id: Ieae1992ed4b02bb1e09eec2d3de1a030eabd16ce
Like most other osmo-* programs, bind the telnet VTY to the address specified
by the 'line vty'/'bind' command. This is added by vty_init(), so until now the
PCU offered this config but ignored it.
Change-Id: I4cca05a212ec0d493b906014dc3a83e687ebbb1d
Encode the EGPRS fields of immediate assignment message in uplink
when EGPRS PACKET CHANNEL REQUEST (11 bit RACH) is received.
The series of patches for 11 bit RACH are dependent on libosmocore
and osmo-bts patches for 11 bit RACH.
Change-Id: Ie5e309156e5dbbb6add74a1b4d257c4ee2332e52
Earlier there was no handling for recalculation of DL window
size during tbf update. Which has been fixed in this patch.
Related: OS#1808
Change-Id: I41aa807068520460fd665a55e3529e60f6bbb630
A subsequent patch needs to call this from gprs_rlcmac_tbf::update(),
so to avoid code dup, put the calculation in a separate function.
Related: OS#1808
Change-Id: I7c7777d43f843bbd3421503fc2a8600f148ca035
row 4 of Table 10.4.14a.1 of Spec 44.060 version 7.27.0 Release 7. Says
"The previous RLC data block contains a Upper Layer PDU, or a part of it,
that fills precisely the previous data block and for which there is no
length indicator in that RLC data block.
The current RLC data block contains a Upper Layer PDU that either fills
the current RLC data block precisely or continues in the next RLC data block."
So when we receive block with 1st LI: value=0 and Value of E bit in the
same octet as 1, we expect 2 chunks with 1st chunk as length as 0 and complete
and 2nd chunk as length non zero. But with this bug we see only 1 chunk causing
incorrect assembling
This issue has been fixed in this patch.
Related: OS#1811
Change-Id: I2cd0fca3ed28a553ede3f4b8a7d3267284dd2c9b
Fix attempted read past vector boundaries in case of a starting bit offset !=
0, so that the last amount of bits read should be < 8. In the case of
CSN_LEFT_ALIGNED_VAR_BMP, the mod-8 calculation was flawed, and in the final
step, 8 bits were read instead of the remainder < 8. This lead to -EINVAL being
returned by bitvec_get_bit_pos() and bogus resulting data.
Instead, read 8 bits only as long as at least 8 bits remain, and read any
remaining bits < 8 in a final step. Drop unneeded nB1 variable and an obvious
comment.
Adjust the unit test assertion in testCsnLeftAlignedVarBmpBounds() in
RLCMACTest.cpp.
Based on a fix by Aravind Sirsikar <Arvind.Sirsikar@radisys.com>, but
implemented differently.
Related: OS#1805
Change-Id: I490498c8da6b531f54acb673379379f7b10907c0
* initialize with invalid TA instead of making assumption that phone is
located within 550 meters (TA=0)
* only set valid TA
Change-Id: Idfc40ff0c11bdac13d9e28fbfa4e95dfc6b735b0
Related: OS#1526