We have licensed the code under GNU Afffero Public License,
and state that in the first paragraph as well as in the link
to the license. However, a paragraph in the middle stated
"see the GNU General Public License", which is somewhat misleading.
Let's fix that.
Change-Id: I37e503b195fe43e1da42c080900504ca8e682e76
Fix condition `block_nr == 4`, which was never reached, by effectively
replacing
- `4` by `msg->num_segs`, so we truly check if the current
block is the last of this message
- the index `block_nr` (which starts at zero) by `block_nr + 1`,
so it is comparable to `msg->num_segs`
Related: OS#5354
Change-Id: I3dc116d6c16c80b31712b2a969f0b2a6998b03f0
If a new default message is installed via RSL, and the old default
message is currently being transmitted, we must set cur_msg to NULL.
The old default message must be talloc_free()d unconditionally whenever
a new default message is being set.
We can do that by using the TALLOC_FREE macro.
Change-Id: Id32c2074b61cd1f09957b9d1558ffb3a7691a8e0
Related: OS#5325
If the currently transmitted message is the default message,
bts_ss->cur_msg == bts_ss->derfault_msg. In this case we cannot
simply talloc_free() both of them, as it would result in a boudle-free.
Change-Id: I2d3645e34d31507b012a53ffe12d14223682f808
Closes: OS#5325
Fixes: Ib01d38c59ba9fa083fcc0682009c13d2db3664fe
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
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
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
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
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
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
This should handle OML channel combinations with CBCH and activate the
CBCH SAPI towards the DSP correspondingly. What is still missing is
sending any actual information over the CBCH in respons to the
PH-RTS.ind coming up from L1.
Harald Welte
arehbein
Vadim Yanitskiy
Pau Espin
Martin Hauke