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
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
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 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
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 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.
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.
Philipp Maier
Andreas Eversberg
Vadim Yanitskiy
Harald Welte