Age | Commit message (Collapse) | Author | Files | Lines |
|
For deleting neighbor entries and for triggering manual handovers, it is useful
to identify neighbors by the gsm0808_cell_id, instead of just by ARFCN+BSIC.
This is not a hard requirement, since BTS+ARFCN+BSIC fully identifies a
neighbor. But consider these contrived examples of the situation before this
patch:
# bts 0
# neighbor cgi 001 01 23 42
# no neighbor cgi 001 01 23 42
% No such command
# no neighbor bts 5
(manually looked up that BTS 5 has above CGI)
# neighbor lac 42 arfcn 23 bsic 5
# do handover any to lac 42
% No such command
# do handover any to arfcn 23 bsic 5
(if multiple cells have the same ARFCN+BSIC, the identification is not unique)
So this fills a gap, if only to help debugging / analyzing handover operations.
Change-Id: I198fe7055d1e09b128693eb51276e3d8cde1c0ba
|
|
The commit acd29192deed0e1a243b35278b030bde7b1662b5
Change-Id Ifb9212fede2333ad68db94188b5cda4fcabe02f8
introduced a bad change to neighbor_ident.vty. Revert that bit.
Change-Id: I8b80be6daef73f5864ba9f294bf2134c8a76ddb5
|
|
I believe I have initially misinterpreted the idea behind sending a Cell
Identifier List in BSSMAP Handover Required messages. Instead of associating N
Cell Identifiers with one ARFCN+BSIC, the idea is to add up N separate
ARFCN+BSIC's Cell Identifiers into a list. To keep the door open for future
code simplification, make sure to allow only one Cell Identifier per remote
ARFCN+BSIC on the VTY UI.
Related: OS#3656
Change-Id: Ifb9212fede2333ad68db94188b5cda4fcabe02f8
|
|
Change-Id: I35783f9624eacbdffccdb59a0179ffda54a26990
|
|
Add missing item in the landscape of VTY commands: allow identifying a local
cell by CGI (besides BTS nr, LAC or LAC+CI, which already exist).
Change-Id: I2d03de6b695904c4a86025bf250358d04f6e47de
|
|
Now the scheme nicely matches:
bts 0
neighbor bts 1
no neighbor bts 1
Change-Id: Ib6015b8b48c1f6b98a02cb5a68e568083466e0d5
|
|
When writing the neighbor configuration documentation, I noticed that 'neighbor
add' and 'neighbor del' make sense from an interactive VTY POV, but when
looking at a static config file, it makes more sense to simply name the
neighbors without the 'add' keyword, and to use the 'no' prefix instead of the
'del' keyword. It still makes sense to tweak cosmetics like this before
inter-bsc handover is used anywhere.
First, remove 'add' from all 'neighbor add ...' commands.
Instead, prepend "Add" to the doc string for the cell identification argument
in commands that add a neighbor:
-OsmoBSC(config-net-bts)# neighbor add ?
- bts Neighbor cell by local BTS number
+OsmoBSC(config-net-bts)# neighbor ?
+ bts Add Neighbor cell by local BTS number
(A subsequent patch will rename 'neighbor del' to 'no neighbor'.)
Change-Id: I143f21f6069d1a86096cc8240cf69eb7ea9c8ac8
|
|
Change-Id: I83a2b03c6a081c4ed3225d79d342913a261d9c1c
|
|
In the 'lac-ci' and 'cgi' neighbor identity VTY parameters, fix the CI part to
<0-65535>.
Use 65535 as CI in the neighbor_ident.vty test to verify the range.
Change-Id: Ie93bfe176b9d2d9445966e4ab0b928b9aa62a77f
|
|
9-bit BSIC exist in the 3GPP specs, but we don't use them anywhere. Rather
remove that choice from the API and UI.
Change-Id: I29b92f47da2636d3a19f073755f9382fa98f9010
|
|
Depends: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd (libosmocore)
Change-Id: I0153d7069817fba9146ddc11214de2757d7d37bf
|