As a result of how FR/HR/EFR DTX interacts with block diagonal
interleaving, at the beginning and end of each DTX pause a
correctly functioning TCH receiver will always pick up an
artifact consisting of 4 received bursts (2 for TCH/HS)
and same number of omitted bursts. Standard channel decoding
of this Rx artifact will produce a "half-block" in which half
of the bits prior to convolutional decoding will come from
a SID repetition whose Tx was notionally suppressed, while
the other half will be garbage. As a result of convolutional
decoding, the result will often appear as valid SID per
classification rules - but passing it as such to the Rx DTX
handler is wrong. Classic E1 BTS and GSM MS implementations
include a kind of SID filter at this point, setting BFI on
these received half-blocks, so that the Rx DTX handler will
see an invalid SID condition. Invalid SID means that comfort
noise generation is to be continued, but no updated CN
parameters are available - which is the truth in half-block
Rx situations. Implement the same filter.
Additional background info can be found here:
https://osmocom.org/projects/retro-gsm/wiki/DTXu_half-blocks
Change-Id: I46c62312316b04567bcadf6050597673f071247d
In any environment where GSM MS may exercise DTXu on TCH/FS, TCH/HS or
TCH/EFS, the BTS receiving this TCH UL has to classify each received
traffic frame as valid SID, invalid SID or non-SID speech. For E1 BTS
this SID classification requirement is explicit as there are dedicated
bits in TRAU-UL frames carrying the SID code. For an IP BTS the need
for this classification is less obvious as most RTP payload formats
omit SID indicator bits - however:
* For HR codec, RTP output in RFC 5993 and TW-TS-002 formats does
include explicit SID classification;
* Also for HR output in both TS 101 318 and RFC 5993 formats
(but not TW-TS-002), SID classification must be considered in order
to turn valid SID with some bit errors into perfect SID codeword;
* OsmoBTS already had logic for all 3 of FR/HR/EFR whereby if a frame
is received that is an accepted SID frame in GSM 06.31/06.41/06.81
definition, a flag is set so that the next good speech frame will
be emitted in RTP with marker bit set. This logic implies SID
classification in TCH UL path.
Prior to this patch, OsmoBTS performed limited, non-consolidated
SID classification:
* For FR and EFR, the only SID classification in TCH UL path was done
for RTP marker purposes by way of osmo_{fr,efr}_is_any_sid() Boolean
result fed to lchan_set_marker();
* For the same RTP marker logic with HR codec, only perfect, error-free
SID frames were detected;
* The same limitation applied to SID classification for RFC 5993 output.
Centralize this SID classification by moving it from BTS model to common
l1sap code and unifying it across all 3 codecs. Immediate functional
effects from this change are:
* On TCH/HS we now detect imperfect (partially corrupted) SID frames
and classify them as valid or invalid SID as intended by ETSI,
like we already did for TCH/FS and TCH/EFS;
* When emitting TS 101 318 or RFC 5993, we apply the inherent limitations
of those RTP formats to valid and invalid SID;
* With all 3 codecs, the check for a good speech frame as exit criterion
from DTXu state now happens after the link quality check in l1sap,
rather than before.
AMR speech mode is not affected at all by these changes: AMR DTX model
is completely different from that of FR/HR/EFR.
Related: OS#6036
Change-Id: Id6c8c146962de2f173760889eb232693bb4229d3
In original OsmoBTS architecture prior to Themyscira patches,
BFI (Bad Frame Indication) condition was signaled internally by
zero-length payload passed from BTS model to l1sap, and externally
by absence of RTP output (intentional gap) or a zero-length RTP
payload emitted in 'rtp continuous-streaming' mode. However, this
paradigm is contrary to classic GSM BSS architecture in which BFI
is an out-of-band metadata flag that travels alongside with frame
payload bits, whether the latter are valid or invalid.
Since 2024 OsmoBTS supports the option of TW-TS-001 output for
FR and EFR codecs, which allows the possibility of BFI-with-data
in RTP. OsmoBTS can already emit such BFI-with-data packets when
the BTS model delivered a deemed-good traffic frame, but that frame
was subsequently deemed bad by the link quality check in l1sap -
but there is still no explicit out-of-band BFI flag inside OsmoBTS
TCH UL path.
By introducing an out-of-band BFI flag, we make it possible for BTS
model PHYs to deliver marked-bad traffic frames: when CRC fails
in GSM 05.03 channel decoding step, a PHY that permits modification
(libosmocoding or future FOSS DSP PHY) can be enhanced to preserve
channel-decoded bits while conveying BFI.
The link quality check in l1sap is reworked to use the new OOB BFI
flag. Follow-on patches will introduce further logic that can also
assert BFI at high level, above BTS model PHYs.
While reworking the link quality check in l1sap, restrict it to
speech modes only: per GSM specs, BFI does not exist in CSD.
Change-Id: I8097946429e83eae90f89e49d17ffb8eb0636fcb
According to 3GPP TS 44.021, section 10.3.2, a radio-interface data
block for a TCH/F14.4 channel consists of eight 36-bit data frames
and two M-bits (290 bits total). Let's fix our definition.
Change-Id: I4f11eda98420587efa339484b62f46bf19f78809
Related: OS#6167
A radio-interface block in GSM carries several modified 36-bit or
60-bit V.110 frames. Let's rename the fields to avoid confusion.
Change-Id: If97787a64e30ff9b39c26749ba32aed09d3d7983
There are two levels of alignment inside clearmode RTP packets
carrying CSData per TS 48.103 section 5.6:
1) Alignment of 2 or 4 V.110 (T) or pseudo-V.110 (NT) frames within
one RTP packet of 160 octets of an imaginary ISDN B channel;
2) For NT modes only, alignment of 4 pseudo-V.110 frames to form
a single 240-bit RLP frame.
Per previous patch, alignment 1 is to be treated as mandatory for
RTP transport inside an Osmocom network. Alignment 2 _could_ be
made mandatory for TCH/F9.6 NT, but the same is not possible for
TCH/[FH]4.8 NT: in the best case of half-alignment, alternating
RTP packets will carry alternating halves of RLP frames.
Implemented solution: allow arbitrary state of alignment 2
(aligned or misaligned) in the incoming RTP stream for all CSD NT
modes, and perform the necessary alignment internally.
This approach is consistent with the world of E1 BTS: a TRAU in
data mode is responsible for alignment 1 (with 20 ms TRAU frames
taking the place of our clearmode RTP packets), but only the BTS can
perform alignment 2, as the TRAU is agnostic to T vs NT distinction.
Related: OS#6579
Change-Id: Idaebfce6da13b23ba265a197502712d83991873e
The next patch in the series will add code for alignment of downlink
RLP frames in CSD NT modes; that code will go into new file csd_rlp.c.
RLP GSMTAP code logically belongs in the same place - hence move it
there in preparation.
Change-Id: I824ce6614c8591cccc5f6bcdde767fe49d551378
Modify CSD RTP input path code so incoming bits E2 & E3 from V.110
frames reach the TCH-RTS.ind handler in l1sap. These bits will be
used in the next patch to ensure proper alignment of DL RLP frames
in non-transparent CSD modes.
Related: OS#6579
Change-Id: I43b97caa6030b9401779998ca5dddc4cfe636e2f
In all classic NT modes below 14.5 kbit/s, V.110 frame bits E2 and E3
are repurposed to indicate the alignment whereby a single 240-bit RLP
frame is composed of 4 pseudo-V.110 frames in switching transport.
(TS 48.020 section 15.1.) In the case of TCH/F9.6, setting both E2
and E3 is easy because all 4 pseudo-V.110 frames go out in the same
clearmode RTP packet as a result of a single channel decoding
operation. However, in the case of TCH/F4.8 there are two separate
channel decoding operations producing two separate RTP packets
20 ms apart. Furthermore, GSM 05.03 section 3.4.1 specifies which
TDMA frame positions hold which half of the RLP frame - therefore,
the correct emission of bit E2 needs to be based on the TDMA frame
number at which the block was received.
A similar situation occurs with TCH/H4.8 NT: we receive a single
block from the 05.03 decoder every 40 ms, containing a full RLP frame,
but we emit it as two separate RTP packets, each carrying 20 ms worth
of bits. These RTP packets also require correct setting of E2 bit.
Related: OS#6579
Change-Id: I485af5e01ea87c1721a298a486cd344a17884200
TCH/H4.8 and TCH/H2.4 modes are different from all other TCH in that
the channel coder runs (statistically) every 40 ms instead of the usual
20 ms. However, the standard RTP interface of TS 48.103 still requires
20 ms packets for all CSD modes; furtherfore, this requirement is not
just a matter of 3GPP spec being obstinent, but is highly useful for
interoperability, both between FR and HR and between OsmoBTS and E1 BTS.
The handling of CSD HR was totally broken in this regard: wrong RA2
packing mode, RTP clock model was violated, and even an internal
mismatch with l1sap sending TCH.req prims at twice the rate
at which the PHY expects them.
With this patch CSD HR handling becomes correct for TCH/H2.4 and for
TCH/H4.8 transparent; fully correct handling for TCH/H4.8 NT will
appear in a follow-up patch.
The packet/frame rate mismatch (40 ms Rx/Tx times while each RTP packet
carries 20 ms worth of data) is reconciled by emitting two RTP packets
directly back-to-back for UL, and pulling two RTP packets at a time
from the Rx jitter buffer at the needed times for DL.
Note: due to bug OS#6604, TTCN3 tests for CSD half-rate transparent modes
will start failing once this patch is merged; to make them pass again,
TTCN3 test code will need to be reworked to fix that bug.
Related: OS#6577
Change-Id: Ib35e910df263743cd243f51fb0bd6551ddfcf4c5
Themyscira Wireless Technical Specification TW-TS-001 defines
an enhanced RTP transport format for FR and EFR codecs within
an IP-based GSM RAN, restoring the full functionality and semantics
of GSM 08.60 TRAU-UL format that were lost in the industry transition
to RTP with payload formats standardized by TIPHON and IETF.
Given that this new enhanced RTP transport format runs counter
to commonly accepted standards, it is strictly optional. OsmoBTS
always accepts both basic and extended RTP formats, but it sends
the extended RTP format of TW-TS-001 only when commanded to do so
by the BSC via an RSL extension IE; OsmoBSC will in turn direct
the BTS to use this extension only when the CN asks for it via
the BSSMAP extension defined in TW-TS-003.
Spec references:
https://www.freecalypso.org/specs/tw-ts-001-v010100.txthttps://www.freecalypso.org/specs/tw-ts-003-v010002.txt
Related: OS#6448
Depends: I0eccfe5ddcf44f8f20440acb01e2d4870ec0cd91 (libosmocore)
Change-Id: Id997e8666bc19e60936aaa83b43a968d30320bd7
Let's add some rate counters to add visibility to the BTS on what is
happening in terms of received and/or transmitted RTP packets.
This should help during debugging any RTP related issues.
Change-Id: Ide674bde10b0e4b501d6a48947b983090342dfec
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
If there's nothing to transmit over a CSD NT channel, both ends generate
NULL frames. Let's add an option to suppress GSMTAP output for those,
creating pcap files with less noise.
Change-Id: I85a2159cfaa01bfb4205c1462e3a9dbda68e4bad
Depends: libosmocore.git I2d9bd8eb4f0cd0f72c436996767b199429596917
In CSD (Circuit Switched Data) NT (Non-Transparent) mode, there
are RLP (Radio Link Protocol) frames inside the modified V.110.
wireshark alrady has a dissector for this, and we've introduced
a GSMTAP type for RLP some time ago. So with this patch, we now
generate such GSMTAP RLP frames.
Change-Id: I6a258458822bcb3fe7290a9b9b3d104beecda219
Osmo-bts uses the new polling based LAPDm implementation.
The OML message NM_ATT_T200 is ignored, because T200 timeouts are set to
the minimal response time. Longer timeouts would cause lower throughput
in case of lost frames. Shorter timeouts would cause LAPDm to fail.
Related: OS#4074
Depends: libosmocore.git I6ebe83f829d7751ea9de1d90eb478c7a628db64c
Change-Id: Ic6d7902b13cf491daaa8752db78f9875387aeffd
If the channel is activated for immediate assignment, the initial data
link establishment on main signaling link with SAPI 0 must have L3
infomation included in the SABM message. If this is not the case,
release the data link without notifying BSC.
Related: OS#5971
Change-Id: I6819b51a876b8743c2d4a04165b7900723a1631c
At the moment the PCU has no way of knowing with which BTS model it is
used with. However, some BTS models may require slightly different
behaviour by the PCU, depending on which BTS model is used. So, lets add
an additional bts_model field to struct gsm_pcu_if_info_ind in order to
convey the exact BTS model to the PCU.
Related: OS#6191
Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
Change-Id: Ib51238a0e09d4484a539a7f822864189872698b6
When adding support for Circuit Switched Data calls, we had to enlarge
the burst buffer size to accommodate bits for a maximum of 24 bursts.
Let's take advantage of this by utilizing the currently unused part of
the Uplink burst buffer for storing bits of previously decoded blocks.
This eliminates the need to allocate additional memory for SACCH.
Change-Id: I15047cd1df4476054b36f05616e41f5297d9bfe5
Related: SYS#5114, OS#4794, OS#4795, OS#4796
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. Whenever the uplink on a voice group channel is free, the uplink
access burst detection is turned on. When the uplink access is granted
to a talker or when the calling subscriber has been assigned to the
channel, the uplink access burst detection is turned off until the
uplink becomes free again.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I92d6773a3a463eb747143c85aa149e54c1fda122
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. This is required for voice group/broadcast channels.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I9045437d52984b7abe00fbc815d7f83c62c0fb5a
There are still some remains that are related to the old PCUIF v10
protocol version. Let's clean those up.
Related: OS#5927
Depends: osmo-pcu.git I68a3f59d5c960ae3a4fbd74f9d4a894295cb9ed8
Change-Id: I04f7108c94c99c9920192177087748e8b89b3106
While compiling:
vty.c:169:3: warning: 'is_config_node' is deprecated: Implicit parent
node tracking has replaced the use of this callback. This callback is
no longer called, ever, and can be left NULL. [-Wdeprecated-declarations]
.is_config_node = bts_vty_is_config_node,
^
Change-Id: I54c5aa5911611b181f80e76556b150f25dd5b60c
The PCUIF flag PCU_IF_FLAG_SYSMO was originally used by osmo-bts-sysmo
to signal to the PCU that the direct PHY access for the sysmo-bts DSP
should be enabled. With time, support for other BTS models was added and
the flag became a synonym for "direct PHY access", so it makes sense to
rename it to "PCU_IF_FLAG_DIRECT_PHY"
Related: OS#6191
Depends: osmo-pcu.git I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b
Change-Id: Ib556a93f7d7d7dbe1e96c4a0802bc802241b2b2d
The RSL link is configured/set up by the BBTRANSC NM object, hence move
it to the appropiate substruct.
Related: OS#5253
Change-Id: I62937cbd81c27274b9f5f70d454d5319a6898c7b
This is a preparation commit towards delaying connection of RSL tcp
socket until the BBTRANSC object is OPSTARTed, as it is the case already
in nanoBTS.
Related: OS#5253
Change-Id: Ia571ec19e9e8f8a6d7c2554642aab0afe1b4b917
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 PCU now sets a confirm flag in struct gsm_pcu_if_pch in case the MAC
block (data) requires a confirmation when sent. Use this confirm flag
instead of making the decision locally based on the MAC block contents.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I3364d2268bdef9c4d2feeb8e3d51a64e34bca68c
The function bts_agch_dequeue() is not used outside of bts.c, so it can
be a static function.
Change-Id: If86293ebbd99d6550022aeb8721d40bca5fc04fc
Related: OS#5927
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Change-Id: Icf85f60ae86fbe1f3b98e1457c0598bb09cb08c5
Related: OS#5927
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments
mit Ericsson RBS base stations were made. It is essentially a copy of
gsm_pcu_if_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Related: OS#5927
Change-Id: I779605858648e2a1c202c37e197a6e32e6ea3786
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 E1/E2/E3 bits are set based on out-of-band knowledge of the
current user data rate. The actual bit values are defined in
3GPP TS 44.021, Figure 4 "Coding of data rates".
TODO: this is only valid for transparent services,
for non-transparent services see 3GPP TS 48.020.
TODO: lchan->csd_mode is never set to the actual CSD mode...
Change-Id: I1a14597dff746cf975140b294400a2cc05badccd
Related: OS#1572
Since 95407f3f osmo-bts-trx supports scheduling all CSD specific
channel rates, however the rate adaptation was missing.
On the radio interface we deal with CSD-modified V.110 frames, which
need to be converted to normal 80-bit V.110 frames (RA1'/RA1), which
in turn need to be batched and sent in RFC4040 "clearmode" 160 octet
RTP payloads (RA1/RA2 as per I.460).
Note that this patch comments out TCH/F14.4 in bts_supports_cm_data(),
so that all channel allocations for this mode would be NACKed. The
reason for this is that the rate adaptation functions for TCH/F14.4
are different than the RA1'/RA1 and the RA1/RA2.
For more information, see:
* 3GPP TS 44.021, section 8 (functions RA1'/RA1)
* ITU-T I.460, section 1.1 "Rate adaption of 8, 16 and 32 kbit/s streams"
Change-Id: I5e3701ad52d5d428fd02caff037881045f2d0a02
Related: OS#1572
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
According to TS 44.018 the UPLINK FREE message must be repeated when the
uplink is marked as free. The BSC sends the UPLINK FREE message once and
the BTS repeats it until UPLINK BUSY (uplink blocked by BSC) or
VGCS UPLINK GRANT (talker accesses the uplink) is sent.
It is important to stop sending UPLINK FREE message when a talker
accesses the uplink and before the VGCS UPLINK GRANT message is sent, so
that stopping must be controlled by the BTS.
Related: OS#5781
Change-Id: Ia23c59f5e9a73bbc384fbc317a2cfcf707e3c28f
When a VGCS/VBS call is established in a cell, NCH is used to notify
about ongoing calls to idle subscribers. Additionally Notification/FACCH
is used to notify subscribers in dedicated mode. This is performed by
broadcasting this messages to all active dedicated channels. The mobile
station can then indicate the call, so the user can join the call.
More importaint is the notification of the calling subscriber's MS,
which initiated the call. This is done on the early assigned channel.
The MS must know on which channel the call is placed. After leaving the
uplink, it must know where to access the uplink the next time.
Change-Id: I3ed14fa54a907891e492a7ada8e745a2c56cd46d
Related: OS#4851, OS#5781
The location of the NCH is defined by the rest octet of System
Information 1. If NCH is defined, the given CCCH blocks are used for NCH
instead of AGCH/PCH.
The current list of VGCS/VBS call notifications is transmitted on the
NCH. If there is no notification, an empty notification is transmitted
on the NCH.
The Notification List Number (NLN) is used to indicated new
notificaitons. Only the last notification (or empty notification)
indicates NLN. This way the MS can determine after two equal NLN that
the complete list has been recevied.
Change-Id: I82fdaba3faaced76267a99ae14a5458a1b41fdaa
Related: OS#5781
When BCCH INFO is received via RSL message, the rest octet of the System
Information 1 message is parsed to get the position of the NCH. The
position is stored in the gsm_bts structure. If the position is not
present int the rest octet, the stored value is set to negative.
Change-Id: I799a27179d478d4ff577d8bc47ae524834851e85
Related: OS#5781
Random access is allowed on VGCS / VBS channels to access the uplink or
to detect listeners. Uplink Access from a listener is only reported once
after activating the channel. Uplink Access from a talker is reported
each time the uplink becomes occupied. RSL TALKER/LISTENER DETECT
messages are sent to the bsc.
The VGCS UPLINK GRANT message is sent by the BTS itself. Timer T3115 is
used to repeat the message up to NY2 times until one valid frame is
received from the MS (CM service request). The UPLINK BUSY / UPLINK FREE
message must be sent by the BSC.
The uplink is released by UPLINK RELEASE message from the MS or from the
BSC. Afterwards the UPLINK FREE message causes the MS to leave the
uplink without any acknowlege. An RSL REL-REQ must be used to terminate
the link locally. (Without layer 2 DISC procedure.)
Change-Id: I1bd07ab6802341b09a06e89df356665ffaf6d2bf
Related: OS#4851
* enlarge the maximum burst buffer size to 24 * (2 * 58) bytes;
* enlarge per-l1cs Uplink burst mask to hold up to 32 bits;
* enlarge per-l1cs Uplink meas ring buffer to 24 entries;
* add new meas modes: SCHED_MEAS_AVG_M_{S22N22,S24N22};
Change-Id: I08ffbf8e79ce76a586d61f5463890c6e72a6d9b9
Depends: libosmocore.git Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d
Related: OS#1572
Title refers to the maximum length of the osmo_wqueue used for
the PCU socket connection.
Related: OS#5774
Change-Id: Id6ba6e4eadce9ce82ef2407f4e28346e7fe4abfa
The RSL "Channel rate and type" field from the RSL Channel Mode IE
in RSL_CHAN_ACTIV and RSL_MODE_MODIFY_REQ messages is the only place
where the BSC differentiates between a normal TCH and the special
TCH modes used in VGCS or VBS. Let's copy this field from the RSL
message into the lchan state, so that BTS models can actually (in
subsequent patches) reflect it when activating the L1.
Change-Id: I6d531bf528bcb81f44d91336471a46ef790d7646
Related: OS#4851
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
