This new commands show information about logical channels:
net.btsN.trxM.tsI.show-lchan.full
net.btsN.trxM.show-lchan.full
net.btsN.show-lchan.full
net.show-lchan.full
Change-Id: I23c1a7e6f6679e3964e359fb202ffe6781a07e8a
This new command allows to control MS power level for a specific
logical channel using net.btsN.trxM.tsI.lchanL.ms-power
This patch also adds a lchan node to the ctrl interface.
Depends: libosmocore.git Ibf2786f668ee7e4f5b6a9ef43f2141cd2d79b4e2
Change-Id: I6f556b66011be6126d6bac31a14101ba37f81cc4
Besides from making the ts ctrl interface follow the convention
of being in its own file, it will be used in the next patch to add
a ctrl interface for lchan.
Change-Id: I9840bddd4eae409bc8373912d54b6bbfc9fc1c1a
A switch (bool) is used to enable or disable NSVC 0 or 1. It is enabled
via any "gprs nsvc 0|1" command and disabled via "no gprs nsvc 0|1"
command. If it is disabled, it is treated as unconfigured, similar when
no remote IP or port has been defined.
Related: OS#6006
Change-Id: Ia112e86aa35f6a245d98ef1b3720c18835faeda6
This line shows all BTS an their OML states in a single line.
Additionally the uptime or downtime is displayed, if there was a connect
or disconnect of the OML link.
Related: OS#6018
Change-Id: I003fd32e589ddf53b7dd42089f904cfb598e3625
We already recover broken lchans where an ACTIV ACK or REL ACK arrives
late. Now add a recovery path for lchans that are broken because no
ACTIV ACK or REL ACK arrives at all.
Add a timeout of X28 = 30s to the lchan BORKEN state.
On timeout, attempt both a Channel Activation and a Channel Release. If
any of them is ACKed, we have successfully synced BTS and BSC's state.
After successful recovery, place the lchan back in the UNUSED state,
available for servicing subscribers.
If recovery is unsuccessful, just continue to attempt recovery every
further X28 seconds.
Patch-by: osmith, nhofmeyr
Related: osmo-ttcn3-hacks I9b4ddfc4a337808d9d5ec538c25fd390b1b2530f
Related: OS#5106
Related: SYS#6655
Change-Id: Ic4728b3efe843ea63e2a0b54b1ea8a925347484a
Title refers to the maximum length of the osmo_wqueue used for
the PCU socket connection.
Related: OS#5774
Change-Id: Ic5f19f4613bccaf582997a4d02b689adee083a0b
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: I4b58912ad7be3070829614853901aa19108ba2c0
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: Iebb3a634fee680bdc3636a61f3ccaa1e97e54a64
For each BTS, an SI 10 is generated with the informations about all
neighbor BTS that have the same group/broadcast call.
The SI 10 will only define neighbor cells within the same BSC, because
it does not know about neighbor cells within other BSCs.
When multiple channels are used for a group/broadcast call, the SI 10
is generated after all channels have been activated. Subsequent channel
activations result in an update of SI 10 on all channels.
Change-Id: Icd3101e6dd935a57f003253aaef400c2cf95a0c3
The error logging message within this function is moved to the user
neigh_list_get_arfcn().
In case of an error, which results in measurement report with cell
index that does not exist in the list of neigbor cells, the measurement
report is truncated to 0 neighbor cell measurements.
Change-Id: Ia8a1dca4837536129d17e7784b892bcb75b9ca4b
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: I23df067df99b76048667131905c4448d32d80640
Even though the Abis/OML message flow looks the way it should look
on the wire, it does not actually reflect the sequence/flow of events
and actions in the NM FSMs. For example (extracted from a PCAP):
GPRS Cell(00,00,ff) State Changed Event Report
GPRS Cell(00,00,ff) Software Activate Request
GPRS Cell(00,00,ff) Software Activate Request ACK
GPRS Cell(00,00,ff) Activate Software
GPRS Cell(00,00,ff) Activate Software ACK
[a] GPRS Cell(00,00,ff) State Changed Event Report
[b] GPRS Cell(00,00,ff) Software Activated Report
[c] GPRS Cell(00,00,ff) Get Attributes
GPRS Cell(00,00,ff) Get Attributes Response
[d] GPRS Cell(00,00,ff) IPA Set Attributes
GPRS Cell(00,00,ff) IPA Set Attributes ACK
GPRS Cell(00,00,ff) Change Administrative State
GPRS Cell(00,00,ff) Change Administrative State ACK
GPRS Cell(00,00,ff) State Changed Event Report
GPRS Cell(00,00,ff) Opstart
GPRS Cell(00,00,ff) Opstart ACK
A follow-up patch [1] changes the logic generating message [d],
so that the IPA Object Version of the GPRS Cell MO is taken into
account when adding the attributes.
The problem is that both messages [c] and [d] are generated and
queued for transmission on the receipt of message [a], but *before*
message [b] has been processed. So the IPA Object Version is not
known and assumed to be 0 at that point in time.
This patch delays configure_loop() until message [b] is received.
So far only for nanoBTS and only for those MOs, for which Figure 2
in 3GPP TS 52.021 explicitly mentions that the SW downloading and
activation procedures may be required, plus for the ip.access
specific MOs which all seem to support the SW activation.
osmo-bts does send SW Activated Report only for a subset of MOs,
which does not include Baseband Transceiver, Radio Carrier, and
Radio Channel. 3GPP TS 52.021 is not clear on whether this
message shall be sent by all MOs either, so we consider it
optional and delay configure_loop() only for nanoBTS.
Change-Id: I3953a5e41eb27165f9ff203cac7447ee9d311abf
Related: [1] Ie0fb3eaf76e1f70e5a19bb088e1674b7e553d32a
This is a partial revert of commit [1], which defined a limit on the
number of attributes and SW Description IEs as a constant and added
a spec. reference. The problem is that there is no such limit in the
referenced 3GPP TS 52.021. The attributes and SW Description IEs are
using TL16V encoding, so there can be as many as the Length part can
represent. It's actually the limitation of our side, since we
allocate a buffer of fixed size on the stack for parsing.
* Remove the MAX_BTS_ATTR and confusing spec. reference.
* For the SW Description IEs, define SW_DESCR_MAX locally.
* For the attributes, define the buffer size in place.
Change-Id: Idd8b971d32cf0f7a910a664d921e644b7c32d831
Related: [1] 1ebf23b7fe "Prepare for BTS attribute reporting via OML"
Related: OS#4505
Since change [1], among with the other attributes we started requesting
NM_ATT_IPACC_SUPP_FEATURES from the BTS. This patch adds the logic for
parsing the response (so far only printing supported features).
Change-Id: I64cffa0bdead3617cc169c83b0f6ddf74f0866a7
Related: [1] 43440e1fc5
Depends: libosmocore.git Ia4208e10d61843dd6ae77398f6624c918dc81ea4
Related: OS#4505
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. One
new feature of PCU_IF_SAPI_AGCH_2 is that the PCU may ask to send a
confirmation when the MAC block is sent.
CAUTION: This patch breaks compatibility to current master osmo-pcu (See
also "Depends")
Related: OS#5927
Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
Change-Id: I709c27adaf09a6766cfde4d76d878626d30ebb3c
Since osmo-bsc uses RSL (with a propritary Ericsson RBS specific
extension) to send a confirmed IMMEDIATE ASSIGNMENT messages via
PCH, we can not just forward the MAC blocks into the paging queue
without determining whether the MAC block is a PAGING message or an
IMMEDIATE ASSIGNMENT message. the reason for this is that RSL uses
two different message types (IMMEDIATE ASSIGNMENT COMMAND and PAGING
COMMAND) to process IMMEDIATE ASSIGNMENT and PAGING messages.
This means we have to look into the MAC block to make sure whether
the message is a PAGING message or an IMMEDIATE ASSIGNMENT message.
We also need to make sure that the confirm flag is properly executed.
In the case of the IMMEDIATE ASSIGNMENT this means we have to include
(confirm=true) or not include (confirm=false) the RSL_IE_ERIC_MOBILE_ID
into the IMMEDIATE ASSIGNMENT COMMAND message.
In the case of PAGING we directly echo a confirmation after sending
the PAGING COMMAND via RSL when a confirmation is requested.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I3d2842626b7e8325860ea3160c7d900d39e953a0
The previous amount of 10 messages may be small if the BSC is processing
lots of measurements from lots of BTS connected to it.
Increase it to 100 by default, and allow changing the write_queue length
through the VTY.
Related: SYS#6550
Change-Id: Ib2e3591498c038b8e59f3ad447ac1f65928d6da8
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: I628aaf19999a0004d0760d25ecd323cdbc0076f5
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.)
Change-Id: I37845408edd96017b50559964c82b2cdc5e143a7
Related: OS#5927
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: Ifb3f257099b52c50e525768484f9e93282089d0f
struct lchan_activate_info and struct lchan_modify_info use an enum to
define, if the channel type is for a normal channel, a VAMOS channel or
a VGCS/VBS channel.
Change-Id: I21167eb4192c02cd7b5e1574cddb382a3feaebe0
The assignment is triggered by the MSC by sending an ASSIGNMENT REQUEST
with a group call reference. The reference is used to find the VGCS/VBS
channel that belogs to the referenced call.
The existing VGCS/VBS channel is reactivated. This will put the channel
into a state where the MS can establish the link on it, to complete the
assignment. The old connection is released by the MSC and assignment
completion is handled by the VGCS FSM.
Change-Id: Idaa864cd5ce4df6c3193494ce12d91523c104d89
Related: OS#4852
Channel release is sent to MS that is in dedicated mode on the main
DCCH. Additionally it is sent as unit data on a VGCS/VBS to notify all
listeners that the channel has been released. All listeners return to
IDLE mode.
Change-Id: Ib777fe98c8ce2342082d88d227b796167d92cfe1
Related: OS#4852
A VGCS channel must not release, if all SAPIs (including 0) are
released. lchan FSM will ignore this.
Change-Id: Ief1e1894362c4917f6e0092268690f68c8193750
Related: OS#4852
Rename _gsm0808_ass_compl_extend_osmux() to gsm0808_extend_osmux().
This IE is also used for VGCS/VBS assignment command that is located in
a different file.
Change-Id: I1452cabb142f9e7a169f4ddfeac85908abaf8dfc
Related: OS#4852
"enum lchan_select_reason" gets a new selection reason: "SELECT_FOR_VGCS"
The selection "direction" can also be changed via VTY.
Change-Id: I6b96d0a1df68efa5858b98297ebe0944b1473aaf
Related: OS#4852
"struct lchan_activate_info" is expanded to support flags for VGCS and
VBS. These are used to send the correct Channel Mode to the BTS.
"enum lchan_activate_for" is expanded to indicate and activation of
VGCS/VBS calls.
Change-Id: Ic0c0597d149d0758d6766937d99660fa02e0e139
Related: OS#4852
This message will be sent to each BTS with a VGCS/VBS channel to notify
the served MSs about ongoing group/broadcast calls. It is also used to
remove the notification, if the call is terminated.
Change-Id: I96ec0ee5d1a772a45f1ebfd64210718c8bf5aa58
Related: OS#4852
This adds the vty commands and respective logic to allow the user to
specify the NCH (notification channel) position in the SI1 rests octets.
Change-Id: Iefde0af44a663f22462a54d68a58caa560eceb2f
Related: OS#5781
Requires: libosmocore.git I24a0095ac6eee0197f9d9ef9895c7795df6cdc49
The PCUIF interface implementation in osmo-bsc provides two ways to
access the paging channel (PCH).
1) Under the SAPI PCU_IF_SAPI_PCH PAGING COMMAND messages are accepted
as whole MAC block but the format is in the style that we are going
to deprecate with PCUIF v.11. Also at the moment those PAGING COMMANDs
are not confirmed towards the PCU. This is also not necessary since
osmo-pcu would silently drop such confirmations. (see pcu_rx_data_cnf
in pcu_l1_if.cpp)
2) Under the SAPI PCU_IF_SAPI_PCH_DT messages are also accepded as
MAC blocks but the SAPI will only accept IMMEDIATE ASSIGNMENT messages.
The messages are encapsulated in a struct that holds IMSI (paging group)
and TLLI (used for confirmation) as separate struct members. The
messages are also confirmed towards the PCU as it should be.
Since we want to depreacete the older V.10 version of PCUIF and there is
not much benefit in maintaining two interfaces we should use
SAPI PCU_IF_SAPI_PCH_DT for both message types. This also requires small
adjustments to osmo-pcu (see Depends).
Depends: osmo-pcu.git I99cfe373fa157cfb32b74c113ad9935347653a71
Related: OS#5927
Change-Id: I82443f2b402aa2416469c8c50b1c050323ef3b8f
Matan Perelman
Pau Espin
Vadim Yanitskiy
Oliver Smith
Philipp Maier
Harald Welte