When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
Add a test that shows that the ARFCN of neighbors from the measurement
report is not parsed correctly for multi-band BSS. A follow-up patch
fixes it.
Related: OS#5717
Change-Id: Ie18e341f236bab5cf60d3a342c15c96cc848a7c2
In SCCPlite, the BSC receives the CN-side MGCP from the MSC through an
IPA conn, and it then forwards those messages to its co-located MGW
through a rawUDP socket created at startup.
This forwarding UDP socket still relied exclusively on the "mgw.conf"
struct which was filled only by the old VTY interface which was been
deprecated lately.
This patch moves the mgw-pool setup before the msc setup so that if the
VTY config file still uses the old VTY, the single MGW is added to the
MGW pool through mgcp_client_pool_register_single(). It then simply
picks the first available MGW from the pool when creating the raw UDP
MGCP-forwarding socket.
This means SCCPLite is still left with supporting only 1 MGW. If more
than one MGW is defined in the pool, then when the call is being set up
a different MGW could be picked from the pool while the CN-side MGCP
would still be sent to the MGW pool selected at osm-bsc startup.
This limitation coul be removed later on by adding a new VTY command
under the "msc" to pin calls for an MSC to an MGW with a given "mgw_nr"
from the pool, and that same MGW be looked for in the pool every time a
new call is being established.
Another possibility would be to avoid creating the "connected" UDP
socket at osmo-bsc startup, and rather use it in non-connected mode and
transmit (sendto) using the mgcp_client remote address during call
establishment.
In any case, this is left as future excercise since so far there hasn't
been any need for multiple MGWs in SCCPLite setups.
Related: SYS#5987
Change-Id: If105dee52b8d36161c759f979eaef4579b47d365
Commit 53b23c252e introduced a weird line
duplication that instead should have been the way this patch does it.
Change-Id: I5a9a983bb6135059ec01edf054ea3f7165bb6a6f
The adoc file has been moved to osmo-gsm-manuals.git so that it can be
included by other apps supporting MGW pooling from libosmo-mgcp-client,
such as osmo-msc and osmo-hnbgw.
Related: SYS#5987
Depends: osmo-gsm-manuals.git Change-Id Ieda0d4bfe6fc90da6e19c791d8ec2da89427ba3b
Change-Id: Icaee61905fbefe4632b562603fce393b70a114b1
This is a preparation commit before moving mgwpool.adoc to a share place
(osmo-gsm-manuals.adoc) so that other apps like osmo-msc and osmo-hnbgw
can also include this section.
Related: SYS#5987
Change-Id: Id0d292506e8b2a888c8d7a682a38db80e9d0933a
New VTY commands have been added recently to the "mgw" node which drop
the redundant "mgw" prefix on each fo them.
Depends: osmo-mgw.git Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
Related: SYS#5987
Change-Id: I71e49cb4d6c2fe54a895aab0b0ba5acc4e57c253
Let's avoid guiding users towards the old deprecated VTY interface.
Line "mgw endpoint-range" is removed since it's nowadays deprected and
implemented as a NOOP.
Related: SYS#5987
Change-Id: Iff74a9efca2a0a2c38d5ac39df704b2b211fd906
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Change-Id: Ib2f04d96ca846d2d61af0b0c0ea1924609004952
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
This feature allows pinning each BTS to a specific MGW from the
configured pool. The pinning can be soft or hard (strict). If strict
pinning is not set, the configured MGW is selected with priority, but
other MGWs can still be selected during each call setup if the
preferred MGW is found not available at that time, hence avoiding denial
of service for the entire BTS if that MGW goes down.
If strict mode is selected, the call will be refused if the configured
preferred MGW is not available at the time the call is set up.
It is useful to use this feature when Osmux is configured between
the BTS and the BSC and an MGW pool is in use. This way the BSC is
capable of grouping all the calls of a BTS towards one MGW, hence taking
advantage of the Osmux trunking optimizations to reduce link data usage
(AMR payload of several concurrent calls ending up sharing the same
underlaying UPD packet).
Furthermore, this allows the operator to intelligently spread load over
the MGW pool in order to avoid ending up with more than 256 concurrent
Osmux circuits on any of the co-located MGWs in the pool (maximum supported
at the moment).
Related: SYS#5987
Depends: osmo-mgw.git 5d8b5b093595e1203e288c3175c163c0994b1102
Change-Id: I9a7a5af72795faed0d12d9d73b59951b6a0e9c7d
The CHAN REQ entry is not deleted after its information was passed on to
the PCU. This causes the same entry to be used over and over again while
blocking other incoming CHAN RQD.
Change-Id: Ia4abc55fc6fcb1c00991cc84d09529131d014910
Related: OS#5198
There's no need to fail, simply make it a noop in that case,
everything's fine and everybody is happy (specially when using CTRL
command "apply-config-file" to load a .cfg file containing
modifications.
Related: SYS#6138
Change-Id: Ia4e70d20d48a28c46a21dd10358577e5c798744c
Current organization is totally mess, there's actually no organization
at all for lots of commands.
Let's organize most commands based on CTRL node where they are applied:
global, bts, trx, etc.
Specific set of commands such as neighbor-related, rf-related, etc.
are left in separate files as subsections inside the same node, so the
hierarchy is still clear.
Change-Id: I51a9b31780a4a8026aafb2d732369cdc10c8bb70
There exists a VTY command for sending default power control params,
but so far there was no CTRL counterpart for it. This patch adds a
SET command 'send-power-control-defaults':
$ osmo_ctrl.py \
--host 127.0.0.1 -p 4249 \
--set "bts.0.send-power-control-defaults" 1
Similar to 'send-new-system-informations', this command takes an
arbitrary dummy value (required for SET), which is simply ignored.
Change-Id: Ib370bd97ee2d9f72f8bec553550b1792d1345387
Related: SYS#6138
in osmo-pcu, the message buffer in pcu_sock_read is allocated with 1000
bytes in addition to the true size of the pcu_prim struct. Presumably
this is to avoid compatibility problems in case the primitives slightly
grow due to appending new struct members. Lets do the same in osmo-bts.
Change-Id: I99f5204b0563f72f9da427bb7aa5451552d8c5b5
Related: OS#5198
The pcu_sock interface in osmo-bts does check the size of the primitives
it receives. Lets do the same in osmo-bsc as well.
Change-Id: I247c6f4b5a7a22d17a060a558c4ceb9221ca7351
Related: OS#5198
We expect osmo-bts to provide us with a remote CID in order to be able
to set up MGW to send Osmux frames to it.
Related: SYS#5987
Change-Id: Ia90e8e0d18193d64c0fa0788dbd0eb242a359b61
the shared code in libbsc checks for sane config being set, but this
doesn't really apply to ipaccess-config, wihich doesn't set such config
fields internally.
Change-Id: I22ff0d22d6dcf9b0f715bfa4e0daeb52c4028308
Until now Osmux was selected unconditionally in bss-side CRCX, without
checking if the codec was AMR or not. If Osmux use policy is "on", we
only want to request Osmux use if AMR codec is selected.
Change-Id: I3f53555dd9608f1337365e4f82b492bdf1da05bb
ipaccess-config sets up the entire line in a fake way.
That requires also setting the fd of each TS used to -1 in order to
avoid library code interacting with it during tear down if an error
occurs.
Change-Id: I19eb23a46f89b96dd8d63742ca2078ecd5c9ab6b
Since this is created by osmo-bsc, it is also expected to be there by
ipaccess_drop_oml() in the shared libbsc code. But ipaccess-config was
not creating it, so let's do so.
Let's explicitly assert this condition in the code path expecting the
pointer to be instantiated in shared code, to easily track related
issues in the future.
Change-Id: I3f63f6827f7c5d7a21ac125b7ca6b35244efbb65
nanoBTS waits until receiving OPSTART in order to establish the RSL
connection socket against BSC, hence we cannot wait until the socket is
established at the BSC in order to send the OPSTART.
Still this way we make sure the RSL CONNECT is acked before attempting
an OPSTART at the BSC.
Change-Id: Ief46bad5075b656c13d1f09a0724e33283148236
The LAC value currently configured is now printed as hexadecimal value
too.
It can still be entered as a decimal value in order to keep backward
compatibility, though the hexadecimal one is now preferred.
Related: OS#5631
Depends: libosmocore.git Ia2b7fbbf5502c28374c21dbff548232680da27d4
Change-Id: I9090d73ae9d39244b79b9dbafa1b164faebabc52
It makes no sense to have duplicate signals. Let's simply clean up
S_NM_IPACC_ACK and pass the required info for higher layers to do
whatever is needed based on the information.
This allows reusing same signal infrastructure for different types of
messages instead of having to implement new signals for each message
(which can be done at a higher point in the stack).
Change-Id: I18ae3d320d00077fc13bb9903903de2a17767302
pcu_sock_read() may not free the message buffer in case the recv
returned errno EAGAIN. This is already fixed in osmo-bts, lets fix it in
osmo-bsc as well.
Related: OS#5198
Change-Id: I49eda447fc1912c1f7f25ba07331cb84decf4548
By default systemd will execute service with root directory (or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I5bf2991d8b6507337b864f4d3c43448e54633f37
There seems to be no way for this function to be called with NULL parameter despite unreproducible crash observed in the
past. Let's add assert to show this explicitly.
Fixes: OS#5551
Change-Id: I235bdd42ea82e7b5a1a40f437ca34c49ad239c48
This way it is a lot easier to find out how and when is an lchan
initialized, simply by looking at the lchan.h header, then seeing the
init function and grepping for it.
Change-Id: I043d1c2ee75d4d2a8b323b7960ee490e567f3865
Oliver Smith
Pau Espin
Neels Hofmeyr
Philipp Maier
Vadim Yanitskiy
Max