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
In PCUIF v.11 we use PCU_IF_SAPI_AGCH_2 exclusively. We use this SAPI
to transfer IMMEDIATE ASSIGNMENT messages for uplink and downlink. In
both cases we send a confirmation back to the PCU. For details see
coresponding patch in osmo-pcu.git (see Depends)
CAUTION: This patch breaks compatibility to current master osmo-pcu (See
also "Depends")
Related: OS#5927
Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
Depends: osmo-ttcn3-hacks.git Iec00d8144dfb2cd8bcee9093c96a3cc98aea6458
Change-Id: I29858fa20ad8bd0aefe81a5c40ad77a2559a8c10
The function pcu_tx_pch_data_cnf() gets a parameter fn (frame number).
This parameter is then used to populate the member fn in
gsm_pcu_if_data_cnf_dt of the PCUIF protocol. However, the PCU only uses
this parameter for logging and nothing else. Hence it it is not needed
and we can remove it.
Related: OS#5927
Depends: osmo-pcu.git I35bc99eaec5d0287ae3916bc668f0babaddfd6ce
Change-Id: Id1c8fa77725129ec2ea7e92e1df493f35a277659
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related struct member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: Ie6b34d5df64f4bed6b14581c7957dcba6af44136
The abstract representation of the rest octets are moved to the header
file, so that the test case can include it. append_p*_rest_octets()
function become externally available for test.
Change-Id: Ifa5be8998b671160e38af1be707e040b00d407b8
Related: OS#5781
Do not send notifications here. The notifications are sent on the NCH.
The NLN is used to indicate a change on the NCH, so that the MS will
read the NCH then.
If NLN is not sent towards MS, it will not read NCH to get an updated
list of ongoing calls. Also, it will not allow making VGCS/VBS calls and
might indicate that ASCI is not supported in this call. (Tested with
GPH-610R.)
Change-Id: I22e584b70fd14d8bdabb28cf5de3d4647f37425a
Related: OS#5781
Currently the rest octets contain Notification List Number (NLN) and
NLN status and the "Channel Needed" (CN3 / CN4) fields for mobile
identities.
The existing encoding of CN3 / CN4 in Paging request type 3 has been
replaced.
The missing encoding of CN3 in Paging request type 2 has been added.
Change-Id: I6e33a6d38d4c7b124de35b53d219b64bb881ba66
Related: OS#5781
When an IMMEDIATE ASSIGNMENT MAC block (from PCUIF) is added to the
paging queue, then also an IMSI is required. The paging queue uses the
last three digits of the IMSI to calculate the paging group. In case no
IMSI is given, the MAC block is rejected. This was handeled differently
before. Even an IMSI of length 0 would still be interpreted as "000" and
not rejected. See also:
I9f3799916e8102bf1ce0f21891f2d24f43091f01
Let's restore the behaviour we had before and accept short IMSI
strings again.
Change-Id: Iab1c3f1c39dd59bb53aa74b2c9e9e135e3985e0b
Related: OS#6099
This adds very minimalistic support for notification of VBS/VGCS calls.
Minimalistic in that we
* only notify via PCH (not via NCH or FACCH)
* only include notification in otherwise empty PAGING TYPE 1
This means that notification will cease to work once the PCH becomes too
loaded and we never would send otherwise empty PAGING TYPE 1 anymore.
Change-Id: I6f6f72d9a0123cb519b341d72a124aaa2117370e
Requires: libosmocore.git I9586b5cb8514010d9358fcfc97c3d34741294522
Related: OS#5781
The NLN + NLN-Status are optional parts of P1 rest octets; they can
be used to support the "Reduced NCH monitoring mechanism" as described
in Section 3.3.3.3 of TS 48.018.
The patch just adds encoder capability but doesn't yet make use of it.
Change-Id: I961842c3fec151e149f72a4f36279ce4b979795e
Related: OS#5781
OsmoBTS still uses the deprecated version 10 of the PCUIF protocol.
OsmoPCU is still compatible to version 10, but to maintain a clean
interface it is planned to drop the support for version 10 in the near
future.
Moving to PCUIF v.11 essentially means using the "Direct TLLI" method to
convey IMMEDIATE ASSIGNMENT and also PAGING COMMAND messages through the
PCU socket. This means in particular that we use a TLLI as an identifier
to confirm IMMEDIATE ASSIGNMENT messages towards the PCU (PAGING COMMAND
is not confirmed at all). Also we now use struct gsm_pcu_if_pch_dt to
parse the incoming PCU_IF_SAPI_PCH_DT, which is much cleaner than using
offsets in a buffer.
Change-Id: I25816ac12e63cc6b641eb414e6bc7eaa9c85fc25
Depends: osmo-ttcn3-hacks.git I08de02e951e10bc8b4381cc2ad32e63f2747e3c4
Depends: docker-playground.git Ia28bc0d6d3cbfe63be19443db86631fb67bb80fb
Related: OS#5927
when osmo-bts receives a MAC block from osmo-pcu through the PCUIF it
puts it in the review queue without further interpreting it. This also
means that it will send confirmations to the PCU for IMMEDIATE
ASSIGNMENT and PAGING COMMAND. This is not entirely correct because only
IMMEDIATE ASSIGNMENT messages should be confirmed. osmo-pcu has no
problem with this since it silently drops the confirmations for PAGING
COMMAND messages. This peculiarity of the PCUIF implementation makes the
confirmation logic hard to understand, so let's add some logic to
osmo-bts that makes sure that only IMMEDIATE ASSIGNMENT messages are
confirmed.
Related: OS#5927
Change-Id: I8b8264d28b1b1deb08774cdba58dd4c6dafe115d
The function paging_add_macblock takes a data and length parameter. The
first three byte of that string are the last three digits of the IMSI
from which the paging group is calculated.
As the layout of this data buffer is a property of the PCUIF interface
API, we should do this separation outside of paging.c. Also we should
supply the IMSI as a valid null terminated string since PCUIF v.11 also
uses this format.
Change-Id: I9f3799916e8102bf1ce0f21891f2d24f43091f01
Related: OS#5927
The paging interface towards the PCU has a confusing API. In fact what
the PCU does when it wants to page or do an immediate assignment is
sending a ready formatted MAC block to the BTS. The BTS then puts this
MAC block in the paging queue and then eventually it justs sends it
without looking at the contents. For the code in paging.c it is not
imortant if the MAC block is an immediate assignment, it only cares if
the paging record contains a MAC block or paging parameters.
Related: OS#5927
Change-Id: Ifab37fdedaba98b160718113767e4ef6ee7d16ad
A request to send an Immediate Assignment over the PCH (not AGCH)
is always coming from the PCU. It's used for DL TBF assignment.
Change-Id: If4b0aa01532ab65b96201ff8829e724c67df6993
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
As far as I can see from my perf measurements, bitvec_fill() is called
quite often and takes 0.27% of the CPU. A more detailed look reveals
that it's indirectly called by fill_paging_type_1() in order to fill
the remaining octets with constant '2B'O padding.
Let's optimize this function:
- use memset() for padding *before* writing optional P1 Rest Octets;
- conditionally initialize the bit vector for P1 Rest Octets;
- use designated initializers instead of memset().
It's generally better to avoid using bitvec_fill() when using memset()
is possible, because the former operates on bits rather than bytes.
Change-Id: I90473356b396e5dd9326598aca025afacca4afc8
The ETWS (Earthquake and Tsunami Warning System) uses a so-called
ETWS Primary Notification which is sent
* to phones in dedicated mode (via DCCH from the BSC)
* to phones in idle mode (via P1 Rest Octets on PCH/CCCH)
This patch implements the second part of the functionality, i.e.
transmitting the related ETWS Primary Notification via PCH. As
3GPP doesn't specify how this is communicated over Abis, we use
a new, vendor-specific RSL message type.
Closes: OS#4047
Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680
Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc
Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
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
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 RR PAGING TYPE 3 Rest Octets IE contains (among other things) the
channel type needed for Mobile Identity 3 + 4 in the paging message.
We did not only "forget" to encode those channel type needed field, but
we have a completely wrong definition of those rest octets in
libosmocore/include/gsm/protocol/gsm04_08.h "struct gsm48_paging3"
Change-Id: I3a0bca6707ce95b68459c89f5b2b07f1590a1ab3
Closes: OS#2994
It seems we have been encoding PAGING REQUEST TYPE 1 and
PAGING REQUEST TYPE 2 erroneously all the time. The optional last
Mobile Identity in those messages are TLV, not just LV.
This is a quite serious bug in one of the most fundamental parts of
the Radio Resource layer, and it has likely stayed hidden for a long
time as usually in small networks there's a low paging load, reducing
the amount of pressure to put multiple identities in one PAGING REQUEST
message.
Change-Id: Icc320ed130d0c29e9260a6a2aabe52e7346c3888
Closes: OS#2993
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
This patch extends paging_gen_msg() by adding an output parameter
is_empty that is true, if only a paging message with dummy entries
has been placed into buffer. This feature is then used by
bts_ccch_copy_msg() to insert an AGCH message if is_empty is true.
Ticket: SYS#224
Sponsored-by: On-Waves ehf
Currently, the DSP is always configured with u8NbrOfAgch = 1 before
SYSINFO type 3 is received. Thus using a different value for
BS_AG_BLKS_RES may lead to inconsistencies and MS failing to receive
paging messages properly.
This patch adds a warning and error logging and should be reverted
when initialisation is done in proper order.
Sponsored-by: On-Waves ehf
These attributes are saved in paging_state, we don't need to save them a
second time in struct gsm_bts_role_bts. Add get and set methods for
these attributes and use them consitently in the VTY code.
This was experienced by Daniel on his 64bit machine. The paging
expiration time was too high and not set by the code at all. Using
gdb watchpoints he found the place where the memory is written. The
issue is that the size of the pointer (8) and not the size of the
data structure was copied (3).
Fix the issue by assigning the de-referenced value. gcc generates
the same code as if we had written:
memcpy(&ps->chan_desc, chan_desc, sizeof(*chan_desc));
This may be adding bells and whistles that nobody wants to touch, but at
least for current analysis/optimiziation they are useful to have. Later
on they should probably be removed again and/or obsoleted by OML
messages for configuration of paging behaviour by the BSC.
If someone wants to have paging for a wrong frame, gracefully return
and do not fill the output buffer. Because we are on the wrong frame
I think it is best to not fill the frame, this is why I did not add a
check to l1_if.c to generate an empty frame.
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.
Harald Welte
Philipp Maier
Andreas Eversberg
Vadim Yanitskiy