All MS/UE must be notified of ETWS Primary Notifiations.
Depending on their state, the notification goes different paths:
* CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH
* CS/PS idle mode: BTS sends paging messages on PCH
* PS TBF active: PCU send Packet Application Info
This enables the last of the three methods by passing any
ETWS Primary Notifications received over RSL via the PCU socket into
the PCU.
Change-Id: Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6
Related: OS#4047, OS#4048
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
It was noticed with old Sony Ericsson phones (like W595 and K510i)
that the service provided by Osmocom network becomes unreliable
from time to time. The RSSI indicator on those phones shows that
the signal is lost, so neither CS nor PS services are working.
As it then turned out, System Information 3 broadcasted on the
Um interface is different than the one received from the BSC.
In particular, the content of SI3 Rest Octets IE is different.
Among with the 'GPRS Indicator', which is actually expected to
indicate whether the PCU is connected or not, SI3 Rest Octets
on the Um interface contain both 'Optional Power Offset' and
'Scheduling if and where' IEs, which are not present in the
original messages from the BSC.
Moreover, as soon as the PCU is connected, 'GPRS Indicator' IE
contains different 'GPRS RA Colour' value, and informs the MS
that System Information 13 is sent on extended BCCH, which
is not even supported by OsmoBTS!
The culprit is in rsl_rx_bcch_info(), where we pass a pointer
to osmo_gsm48_rest_octets_si3_decode(). Instead of passing a
pointer to the beginning of SI3 buffer, we actually need to
shift it to the beginning of the SI3 Rest Octets IE.
This change makes my Sony Ericsson phones happy ;)
Change-Id: Ia962cf21903ba674057cf52746996dd3254bc1c6
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference
element must be included if channel activation type is 'handover'.
Let's properly reject CHANnel ACTivation messages with missing
RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted
as regular (non-handover) channel requests.
Found using TC_ho_rach() TTCN-3 test case.
Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
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
The existing code ssumed that the RR SUSPEND REQ would be a
LAPDm/RSL unitdata request. I couldn't find any spec reference
that would support this. Rather, the message is sent via the normal
main dedicated channel, which is operated in ABM mode.
As the somewhat similar check for diverting measurement results
is in fact looking for UNITDATA, we have to untangle this slightly.
Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6
Related: OS#2249
Related: OS#4023
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
The spec is quite clear: If the MS Power Parameters IE is present, then
the BTS shall perform autonomous MS power control. If it's absent,
then the MS power shall be fied. Let's adjust our code accordingly.
Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5
Related: OS#1622
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
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
This off-by-one error in length verification caused all SACCH INFO IE
to be deemed invalid and hence any RSL CHAN ACT with that IE to be
rejected.
Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e
Related: OS#3750
The Radio Link Layer (RLL) messages only make sense when a given
logical channel is active. If it isn't active, let's reject the
messages with an RSL ERROR REPORT with cause "Message sequence error",
wich according to spec means:
"A message with an existing message type which is not possible according
to the specification and to the state of the BTS is erroneous."
Related: OS#3750
Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we
still should include it whenever possible to help error analysis.
Related: OS#3750
Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
Send an RSL Error Report in case of unknown/unsupported msg_type,
as describedi in section 7.3 of 3GPP TS 48.058.
Related: OS#3750
Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
Found using clang-8:
rsl.c:1646:7: warning: taking address of packed member 'packets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1646:28: warning: taking address of packed member 'octets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:7: warning: taking address of packed member 'packets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:28: warning: taking address of packed member 'octets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:7: warning: taking address of packed member 'packets_lost'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
Found using clang-8:
rsl.c:1607:93: warning: size argument in 'memcmp' call
is a comparison [-Wmemsize-comparison]
rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead?
It looks more logical to compare the result of memcmp() against
zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size.
Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15,
a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if
it wants to suspend GPRS services. The BSS is now responsible to
somehow forward this to the SGSN. As the Gs interface between BSC and
SGSN is both optional and doesn't have any provision to forward this
message, we have to send it over to the PCU so it can use regular BSSGP
signaling to inform the SGSN of the SUSPEND REQUEST.
This patch requires libosmocore Change-Id
I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of
struct gsm48_gprs_susp_req.
Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f
Closes: OS#2249
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets
use only oml_tx_failure_event_rep() and remove oml_fail_rep()
Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6
Related: OS#3843
This fixes the below compile error:
rsl.c:900:43: error: ‘gsm0808_chosen_enc_alg_names’ undeclared (first use in this function)
Change-Id: I4aed0242737602e61b785862e3c37c963bf48455
Fix recent commit which broke TTCN3 BTS_tests
TC_dyn_ipa_pdch_tchf_act_pdch_act_nack.
Prior to the breaking commit, logic was still not good, because
1- It didn't return after sending the NACK
2- It sent a NACK in all cases, while for PDCH DEACT we want to force
its deactivation. Going through tests it can be seen that indeed it
can deactivate it in that case:
rsl.c:2206 (bts=0,trx=0,ts=3,pchan=TCH/F_PDCH as PDCH) Request to PDCH DEACT, but lchan is still in state ACTIVE
...
rsl.c:2103 (bts=0,trx=0,ts=3,ss=0) Tx PDCH DEACT ACK
Fixes: 133a3d96dc ("rsl: Avoid sending ipa PDCH DEACT NACK followed by ACK")
Change-Id: I6d6d12aec10c801fe55012ca6e58d0bc8755b15d
This commit doesn't change internal logic of any model, only the API to
be able to return result of connect TS asyncrhonously since some models
(like osmo-bts-trx) require some time to process the result. This way
PDCH ACT/DEACT (N)ACK can be sent once the result of this long process
is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK
before getting the result from SETSLOT on the TRX iface.
With this new API, bts_model_ts_connect doesn't return any value
synchronously. Instead, it is expected to always end up calling
cb_ts_connected with the return code from the TS activation process. 0
is considered a successs, while any other value is considered an error.
Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
It was spotted during osmo-gsm-tester test
dynts:trx-sysmocell5000+mod-bts0-dynts67-ipa+cfg-codec-fr-any that
osmo-bts-trx was answering to PDCH DEACT from BSC first with a NACK
followed immediatelly after by an ACK. That happens after the test does
a GPRS pdp ctx act successfuly and then deactivates the ctx and the 2 MS
try to place a call between them (and thus channels need to be moved to
TCH/F).
Most probably the if condition where the lines for this commit are
modified need to be fine-grained. Patch before this one should help to
understand the steates/situation in this scenario, and then a follow-up
patch can be created to improve the logic.
Change-Id: I91c65da6b6b7094f32187d3b083153a87c3219fd
During the investigation of OS#3559, it was discovered that the
log message, which warns that an RSL message was dropped due to
inactive logical channel, has incorrect log level - LOGL_INFO.
This is not informative kind of message, so let's increase the
log level, and additionally let's print the hexdump of message
and it's length.
Change-Id: I26eac5e4466c493ffe08dbb89de20f5e1c2bb85d
Fix the chan mode checking for RSL Chan Mode Modif: do not reject
all modes on dyn TS.
In rsl_rx_mode_modif(), bts_supports_cm() should never
be fed with dynamic pchan kinds (e.g. GSM_PCHAN_TCH_F_TCH_H_PDCH).
Feed instead the return value of ts_pchan() that is to say,
the actual pchan type (e.g. GSM_PCHAN_TCH_F).
Change-Id: I7f0c835b25289931bccf96e982ea5564c8be4192
Normally, the "Common Channel" related RSL messages should actually
contain such a common channel. However, since cell broadcast is
implemented inside what's essentially a downlink SDCCH, we should add
some explicit exceptions.
Before this patch, any RSL SMS BC CMD would have been discarded and
an RSL Error Indiciation returned.
Change-Id: I2f7f1dd43505cc27cd33489d8b0e8c981cd93880
Closes: OS#3533
At the moment only lchan_meas_reset is reset on channel activation.
All other states are not reset. This may lead to irretations in the
first measurement interval if there are still leftover messages from
a previous connection. Lets ensure everything is reset to zero by
zeroing out the whole .meas struct in struct lchan.
- Add a centralized function that does the reset
- Call that function from rsl_tx_chan_act_ack() in rsl.c
Change-Id: I880ae3030df6dcd60c32b7144c3430528429bdea
Related: OS#2975
Related: OS#2987
During SACCH FILL processing, update lchan SI values only
for lchans which follow BTS-global default values, keeping
lchan-specific overrides in place.
Change-Id: I515bbd9983fa894507386b241863a9aa4d279497
Fixes: eee7247ebe
Related: OS#3173
When a SACCH FILL is received, loop over all lchans and update
their copies of system information data.
This change makes BTS_Tests.TC_sacch_multi_chg pass.
Change-Id: I3e63eeb5fcf320fb029de16e4d327e153cc34567
Related: OS#3173
This patch adds extended processing of the high-resolution TOA256
measurement values. It adds reporting of the following values
for each RSL MEAS REP for uplink measurements:
* minimum TOA256 value during reporting period
* maximum TOA256 value during reporting period
* standard deviation of TOA256 value during reporting period
Change-Id: Iea4a4781481f77c6163d82dcd71a844a5be87bf2
This way we give the opportunity to the BSC to release the channel
quicker, otherwise it has to wait until T3101 expires.
Same procedure is already done in rsl.c rsl_rx_imm_ass() when we return
an error (hard limit AGCH queue len reached) from bts_agch_enqueue().
Related: OS#2990
Change-Id: Id9927c0789054ce3ecc7b30380585a1ffe05db5a
The current implementation does not allow the user to specify a port
range in which the BTS is allowed to allocate a local RTP port. Also
the ports the BTS picks do not match the policy described in RFC3550.
An RTP Port must be at an even port number and the matching RTCP
port must be at the following (odd) port number. The BTS currently
picks random port numbers for both.
- Add a VTY command to specify a port range in which the BTS may
assign local ports.
- Pick ports as described in RFC3550.
Change-Id: Id75f1dfaf898ed8750d28b1c4840e188f4cfdc87
Related: OS#2825 OS#2635
The existign code only sent an ERROR REPORT, but it failed to actually
send a proper NACK to the related request. This is confusing, as the
operation should always be ACKed or NACKed, and not simply result in no
response.
Change-Id: Ic374a8e5e239ffe37082a54cdb94cb6ac9723e83
Closes: OS#3254
Whenever we encounter an error condition during processing of RSL CHAN
ACT or RSL MODE MODIFY, it's insufficient to simply send an RSL ERROR
INDICATION, but we also must send a proper NACK back to the BSC.
Change-Id: I4dd7ff2fd2cdbc6e892cd329c826ac1bc3b16bb9
The code actually always *wanted* to make lchan activation fail in
case we don't support the algorithm, but it failed ot do so.
The problem is encr_info2lchan() which uses bts_supports_cipher() to
determine if the cipher is supported. However, if bts_supports_cipher()
returns 0 (not supported), it uses this value as return value of
encr_info2lchan() where '0' means success (standard osmocom convention).
This results in channel activation proceeding, which it shouldn't.
Change-Id: I46275b8fc2a1a74f68b4cc60e0f64ba226b108cd
Related: OS#3254
This logging turned up while I was debugging dynamic timeslots:
- OML Set Channel Attributes logging.
- a specific dyn TS pchan error.
- show pchan and lchan types on CHAN ACT ACK and REL ACK logging.
- on RSL message Rx, log the current pchan kind in detail, using
gsm_ts_and_pchan_name(). This logs the underlying pchan as well as the
current pchan mode a dyn TS is in.
- move 2 dyn TS logging from DL1C to DRSL, where all the other dyn ts logging
is.
Change-Id: Ia89c134060e85f7065afd5642d1c541c65dd25ea
Harald Welte
Vadim Yanitskiy
Eric Wild
Philipp Maier
Pau Espin
Keith Whyte