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
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's of no use for the test. Furthemore, it was being created outside
the build direcory, being left there.
Change-Id: Iaeee14a01badb8439bc8893ba8be06b13e4318f3
A follow-up patch implements a special channel allocation mode, which is
only working for assignment (basically TCH selection for a voice call).
This mode cannot be employed for initial CHANNEL REQUEST or handover due
to the absence of an already established lchan.
Adding this mode to the existing VTY command syntax would be confusing:
channel allocator (ascending|desscending|dynamic)
^^^^^^^
so this patch extends the VTY syntax in a way that it becomes possible
to configure different channel allocator modes for different cases:
OsmoBSC(config-net-bts)# channel allocator mode ?
set-all Set a single mode for all variants
chan-req Channel allocation for CHANNEL REQUEST (RACH)
assignment Channel allocation for assignment
handover Channel allocation for handover
The old command syntax, which is basically 'set-all', is kept for
backwards compatibility, but marked as deprecated.
Change-Id: I3ae73b36ee9433cc768376b56f0765e5f416162f
Related: SYS#5460
The neighbor configuration storage is fundamentally broken: it requires
all local cells to be configured before being able to list them as
neighbors of each other. Upon config write-back, the neighbor config
however is placed back inline with the other config, and hence a
written-out neighbor config no longer works on program restart.
The cause of this problem is that the config is stored as explicit
pointers between local cells (struct gsm_bts), which of course requires
the pointer to exist before being able to reference it.
Instead, store the actual configuration that the user entered as-is,
without pointers or references to objects that need to be ready. Resolve
the neighbors every time a neighbor is needed.
Hence the user may enter any config at any place in the config file,
even non-working config (like a BTS number that doesn't exist), and the
relation to actual local or remote neighbor cells is made at runtime.
Abort program startup if the initial neighbor configuration contains
errors.
Related: OS#5018
Change-Id: I9ed992f8bfff888b3933733c0576f92d50f2625b
This new CTRL interface allows users of this BSC (such as attached PCU)
to gather neighbor information.
This interface is needed for PCU to translate ARFCN+BSIC keys provided
by MS in the Um side into CGI + RAC keys used to identify target cells
in RIM procedures against SGSNs on the Gb interface.
This patch extends the already existing neighbor information storage in
the VTY by allowing storage of CGI + RAC (RAC couldn't be stored
beforehand).
Related: SYS#4909
Depends: libosmocore.git Change-Id If48f412c32e8e5a3e604a78d12b74787a4786374
Change-Id: Ib07c9d23026332a207d4b7a0f7b4e76c0094e379
arehbein
Pau Espin
Vadim Yanitskiy