Age | Commit message (Collapse) | Author | Files | Lines |
|
Depends: libosmocore.git I9d6ed06731ae15fdcef1a1f397d6ac2b7b1ca980
Change-Id: I1fd513ea03297918d15d4b28ed454f9b6dd6ebfa
Related: OS#3075
|
|
If no PCU is connected, we cannot be providing GPRS services,
and hence should not transmit SI13.
Change-Id: I54320cf8073a33ed9e35b365921df178005e8967
Closes: OS#3075
|
|
Move all struct gsm_bts_trx references from bulky gsm_data to its own
file containing all related definitions and implementations. Also move a
few functions clearly related to that object which were placed in bts.*
Change-Id: Iebaf5b221c48b571f45408af867ce6f9c0cd9f4a
|
|
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
|
|
During the process of bootstrapping, it may happen that System
Information Type 3 is not yet received from the BSC, while the
BTS already needs to transmit a block on AGCH or PCH.
Since the RSL link is established later than the OML link, it's
kind of expected, so we should not log it as error.
Change-Id: I41aa3dbe375cf42c39032bafa80dba94d6219d35
|
|
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
|
|
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
|
|
src/common/sysinfo.c:147:1: warning: control reaches end of non-void function [-Wreturn-type]
}
The compiler warning is actually a false positive since we call
OSMO_ABORT on that path, but let's add a return anyway so the
compiler doesn't throw a warning.
Change-Id: I9b4e06927489a8bc20ce173279a01415a8c4295a
|
|
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
|
|
The existing algorithm (present since 2012!) failed to work
in the sole case that only *one* SACCH filling type was present.
So if you had your BTS configured to only broadcast SI5, but not
broadcast SI5ter, SI6 or any other SACCH filling, it would send
the SI5 message only once on a newly-established channel, and never
again.
The old code was working for more-than-one SACCH filling, as well
as for no SACCH filling at all.
Let's also add a NOTICE message if there is no SACCH filling available
at all. This is highly unusual and definitely a noticeable event.
Change-Id: Ica801f9b9c118f00d9e3dc2780b3123e925f59b4
Closes: OS#3057
Related: OS#2963
|
|
Change-Id: I7e61639349deda28846810c4f52dbea78dccda38
|
|
SI1 is only required if frequency hopping is used or if NCH is used. So it's optional.
If OsmoBTS has no SI1 configured, it will transmit the empty SI1 buffer
at TC=0, and as a result no valid SI will be broadcast at TC=0.
Change-Id: I41ab885c00e943199b2e939e98f30e267ecffbee
Closes: OS#3051
|
|
When no SI 2bis, nor 2ter, nor 2quater is in use, then the code in
bts_sysinfo_get() will return null, causing the transmission of a dummy
frame (0303012B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B) instead of a
system information message. This is - at least - very odd and might not
be backed by the specification. We should simply send any other system
information message instead of sending a frame that does not have a
valid SI header.
While 030301 might be a valid, empty UI frame on a DCCH, it is not a
valid frame for the BCCH, where the header is structured differently.
In fact, bts_sysinfo_get() should never return NULL and always return a
valid BCCH message.
This bug was found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn
Change-Id: Ifeaed27d1d7ba9994fb8ce67d660648bcc8efece
Closes: OS#2365
|
|
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
That's resubmission of 340cff51f49f6e798cb5fb6d1b9febdd09902906 and
186c6bac0758b6f94aa101e151664b0dea5d8975 with memory initialization
order change to fix the issue detected by osmo-gsm-tester - see OS#2338.
Change-Id: Ib595733cde108387bc7ee76b1b11ada6a235f13c
Related: OS#1660, OS#2338
|
|
This reverts commit 340cff51f49f6e798cb5fb6d1b9febdd09902906.
osmo-gsm-tester detected a regression due to this commit, when running
osmo-bts-trx. The modems timed out when waiting for them to register with the
osmo-bts-trx network. osmo-bts-sysmo is apparently not affected. No further
details on the failure cause are known yet. The failure is shown for example by
http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/868/
Change-Id: I15bca30ddc09a7a3044096626016f6130d07636c
|
|
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
Change-Id: I3aeb90804edab1b0325c3eb7347526ae995dbf51
Related: OS#1660
|
|
* use GSM_BTS_HAS_SI() from OpenBSC instead of local copy
* arrange GSM_BTS_HAS_SI() checks to improve readability
* constify SI scheduler parameters
Change-Id: If74bc536fe7d2bfbc976c07d882151873ecda4f2
Related: OS#1660
|
|
SI2quater support as per 3GPP TS 44.018 will require chnages to the way
System Information is stored because it uses 1:n instead of 1:1 mapping
between SI type and generated SI content. This should not affect other
SI types though. To facilitate this transition:
* convert the code to always use GSM_LCHAN_SI helper instead of
accessing buffer directly
* move duplicated code to inline function
* add logging for buffer truncation and corresponding length values
Requires I74e4e3cb86364cec869a1472a41b4a95af0d50dd in OpenBSC.
Change-Id: Ie97be6ead6ce6d2d425fbfac8429bb90afb95acc
Related: RT#8792
|
|
Change-Id: I1fbf7d7f619cc8194c8094cf4a1826b6114f0e11
|
|
Do not assume that 1 == BS_AG_BLKS_RES but take that information from
SI3. Note: due to current implementation quirks we activate channels
before SI3 obtained, than we deactivate channels upon receiving SI3 and
activate them again. This might not be necessary once we migrate to
proper OML state machines.
This affects lc15 and sysmo hw.
Change-Id: I11377b12680ac3b2f77f80e742b6f0af63fc9c1e
Related: OS#1575
|
|
According to 3GPP TS 05.02 ยง 6.3.1.3 SI2ter messages should be scheduled
in FN with TC=4 only if SI2bis messages are also available.
|
|
This issue prevented scheduling of SI 2quater messages.
|
|
Limit the range from 0 to (_MAX_SYSINFO_TYPE - 1) instead of
0 to 31. This way we will never access the lchan->si.buf[] out
of bounds. This is only a theoretical issue though as the code
filling the lchan->si.buf for the SACCH will not have valid
>= _MAX_SYSINFO_TYPE. Add a small regression test to check we
still schedule all SIs.
Fixes: CID 1040765
|
|
|
|
As Holger pointed out, it may well be the case that there are no system
information messages to be sent at TC=4, and we should avoid a modulo by
0. I'm simply sending SI2 instead now, as it isn't forbidden to send it
more often than the minimum at TC=2...
|
|
We now implement the fairly complex rules for schedulign of
SI 2bis/2ter/2quater, 13 and 9 on TC=4 and TC=5 of the BCCH Norm.
The patch is currently untested.
|
|
In case we have neighbor cells in different bands, we should send those
SI...
|
|
|
|
This code re-works osmo-bts to add support for the upcoming sysmocom BTS.
It also tries to add some level of abstraction between the generic
part of a BTS (A-bis, RSL, OML, data structures, paging scheduling,
BCCH/AGCH scheduling, etc.) and the actual hardware-specific bits.
The hardware-specific bits are currently only implemented for the sysmocom
femtobts, but should be (re-)added for osmocom-bb, as well as a virtual
BTS for simulation purpose later.
The sysmocom bts specific parts require hardware-specific header files
which are (at least currently) not publicly distributed.
|