I noticed that the log is awfully silent about disconnecting RUA, even
with DEBUG turned on. It is an important item that should show in the
logs.
Change-Id: I87592cbf197d5d3d2a22b04d9f6b64422af65ded
According to 3GPP TS 25.413 8.26.2.1, "The RNC shall include the Global
RNC-ID IE in the RESET ACKNOWLEDGE message."
Related: SYS#6441
Change-Id: I49d351e90dfe4a7c4dfdd26542565f2d9bd3d605
According to 3GPP TS 25.413 8.26.2.2, "The RNC shall include the Global
RNC-ID IE in the RESET message."
Related: SYS#6441
Change-Id: I2cd5d7ea86a6ed0916befe219dbf21373afbd95b
According to 3GPP TS 25.413 8.26.2.2, "The RNC shall include the Global
RNC-ID IE in the RESET message." To be able to do that, osmo-hnbgw needs
to know the local PLMN.
Introduce explicit knowledge of the local PLMN by config, and use this
configured local PLMN in places where the local PLMN was so far derived
otherwise.
Subsequent patches will separately add the RNC-ID to the RANAP RESET
messages.
Since the PLMN is required to send correct RESET and RESET ACK, include
the new 'plmn' config item in all example configurations.
Related: SYS#6441
Change-Id: If404c3859acdfba274c719c7cb7d16f97d831a2a
Implement Paging record, remembering which CN link paged for which
mobile identity, for a set time period roundabout 15 seconds.
When receiving a Paging Response from a UE, connect it to the CN link
that sent the Paging.
Related: SYS#6412
Change-Id: I907dbcaeb442ca5630146f8cad40601c448fc40e
Implement cnlink FSM. This is a copy of osmo-bsc/bssmap_reset.c, except
for the connection success/failure counting.
The reason to exclude the CONN_CFM_FAILURE/_SUCCESS: it is a rather
experimental feature and should probably rather be covered by PCSTATE
notifications and protocol layer timeout tuning (e.g. SCCP ia timers).
Related: SYS#6412
Change-Id: Id3eefdea889a736fd5957b80280fa45b9547b792
As simple as it may seem, turning the RANAP CS/PS domain indicator to a
string so far is cumbersome. It is usually only CS or PS, but to be
accurate we should also expect invalid values. After the umpteenth
switch statement breaking up otherwise trivial code, I decided that yes,
after all, a value_string[] is a good idea even for just two enum values
that have only two-letter names.
Callers will follow in upcoming patches.
Related: SYS#6412
Change-Id: Ib3c5d772ccea8c854eec007de5c996d1b6640bc0
When proper RANAP RESET handling is in place [1], a specific CN link may
be detected to be disconnected or reconnected at any point.
[1] Id3eefdea889a736fd5957b80280fa45b9547b792
When that happens, all related context maps should disconnect RUA and
SCCP links immediately. Add the context map side of this, so that
context_map_cnlink_lost() is ready to be dispatched in [1].
Related: SYS#6412
Change-Id: Ic0a6fcfb747dc093528ca2bd12a269ad390d465c
Make lots of small tweaks in logging around RUA to SCCP context maps, CN
link selection and HNBAP:
- remove duplicate log context (e.g. LOGHNB() already shows the HNB Id)
- bring more sense into logging categories and levels / reduce noise
- add and clarify the details being logged at what points in time
Related: SYS#6412
Change-Id: I41275d8c3e272177976a9302795884666c35cd06
Upcoming logging tweaks will call this from hnbgw_hnbap.c as well.
See I41275d8c3e272177976a9302795884666c35cd06
Related: SYS#6412
Change-Id: I499d18876685062d066a9a66d2def827efb77640
The Cell ID is an important part to distinguish HNB in logging, add it
to the output string.
Use OTC_SELECT buffer instead of static buffer.
Related: SYS#6412
Change-Id: Id903b8579ded8b908e644808e440d373bcca8da4
This is the bulk of the CN pooling logic but is not working properly
without these future patches:
- detect in/active CN links by RANAP RESET
Id3eefdea889a736fd5957b80280fa45b9547b792
- return Paging Resp to the exact CN link that Paged
I907dbcaeb442ca5630146f8cad40601c448fc40e
Change-Id: I66fba27cfbe6e2b27ee3443718846ecfbbd8a974
Introduce rate counter stats to osmo-hnbgw.
Add the first rate counters -- they will be fed in upcoming commit
"cnpool: select CN link from pool by NRI or round robin"
I66fba27cfbe6e2b27ee3443718846ecfbbd8a974
Related: SYS#6412
Change-Id: I0132d053223a38e5756cede74106019c47ddcd94
For InitialUE messages, decode the RANAP and NAS PDU to obtain the
Mobile Identity. Store it in map->l3.
A following patch will use this mobile identity to decide on which CN
links to pick from the CN pools for this subscriber.
Add the new information to LOG_MAP() as ubiquitous logging context.
Depends: libosmocore Ic5e0406d9e20b0d4e1372fa30ba11a1e69f5cc94
Related: SYS#6412
Change-Id: I373d665c9684b607207f68094188eab63209db51
Even when the config file did not configure any, the 'show
running-config' shows the default 'msc 0' and 'sgsn 0' that were
created. Let's also show that in the vty scripts.
Change-Id: Ia4e43fa9b5d9fda1ae374d3d31965aafe85d493d
Fix: missing allocation of SCCP FSM instance.
When submitting patch [1], i failed to notice that a small but important
fix, already present later on my branch, was needed for this patch to
work.
[1]
'cnpool: split up context_map_find_or_create_by_rua_ctx_id()'
Ifc5242547260154eb5aecd3a9d9c2aac8419e8db
c6393a1f80
Change-Id: I447f989f1d58b666bf9f1ab49ce6ba4fc5cdda80
An upcoming patch will re-use this pattern of decoding RANAP and
attaching a talloc destructor to the result for the third time. The
caller will be in hnbgw_rua.c, so make this a "public" function.
Change-Id: I3695babfb083ed1f5fff700dcb7646fa95496a52
Makes no sense to have groups with one member each.
Soon I will add a new timer that matches neither 'cmap' nor 'ps', and I
would have to open a third group with a single member.
Add a shim that redirects 'ps' to 'hnbgw'.
The group 'cmap' has not yet been released, so just drop that one
without a shim.
Change-Id: Ica6063fae4588b51897e5574d975b3185fa9ae80
Implement only the VTY configuration part, applying NRI to select CN
links follows in I66fba27cfbe6e2b27ee3443718846ecfbbd8a974.
Use the osmo_nri_ranges API to manage each cnlink's NRI ranges by VTY
configuration.
Analogous to osmo-bsc
MSC pooling: make NRI mappings VTY configurable
4099f1db504c401e3d7211d9761b034d62d15f7c
I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
plus
vty: fix doc: default value for 'nri bitlen'
f15d236e3eee8e7cbdc184d401f33b062d1b1aac
I8af840a4589f47eaca6bf10e37e0859f9ae53dfa
Related: SYS#6412
Change-Id: Ifb87e01e5971962e5cfe5e127871af4a67806de1
After recent introduction of multiple 'msc' and 'sgsn' nodes in the
VTY config, switch cfg files to the new syntax:
- in doc/examples
- for 'make config-tests'
- have one test in old config syntax to test backwards compat:
'legacy', an exact copy of 'one_cs7_with_addrs'.
Related: SYS#6412
Change-Id: If999b71a8a8237699f6ccfcaa31d1885e66c0518
Allow configuring multiple MSCs and SGSNs. Show this in new transcript
test cnpool.vty and in sccp.dot chart.
Still use only the first CN link; actual CN link selection from the pool
follows in I66fba27cfbe6e2b27ee3443718846ecfbbd8a974.
Config examples and VTY tests cfg files will be adjusted to the new cfg
syntax in patch If999b71a8a8237699f6ccfcaa31d1885e66c0518. Only the VTY
write() changes are visible here, to pass all transcript tests.
Related: SYS#6412
Change-Id: I5479eded786ec26062d49403a8be12967f113cdb
To ease patch review, I decided to submit this separately from the
caller, which follows in subsequent patch
I5479eded786ec26062d49403a8be12967f113cdb
The new event will be dispatched when there are SCCP config changes
pending, and the human user types 'apply sccp' on the telnet VTY. The
aim is to disconnect all connections so we can create a new SCCP User.
Related: SYS#6412
Change-Id: Idff8e09b5328c904b175e4d4df7d4044a34f4a20
Have separate find, alloc, set_cnlink functions instead of all in one.
For CN pooling, I need these operations to be separate:
- we need to decode the RANAP and L3 PDU only if no existing context_map
was found (see I373d665c9684b607207f68094188eab63209db51 ).
- while decoding RANAP and L3 PDU, and while deciding which cnlink to
use, I already want to use the logging context of LOG_MAP(). So I want
to allocate a map first, and connect it to the selected cnlink later.
Related: SYS#6412
Change-Id: Ifc5242547260154eb5aecd3a9d9c2aac8419e8db
osmo_sccp_instance_next_conn_id() may return negative on error, so use
int instead of uint.
Fixup for recent 548d3d2f66
'use new osmo_sccp_instance_next_conn_id()'
Related: CID#316694
Change-Id: I2623c06c23691acb75f6ee6ff3a42ac7d10a4b1f
Prepare for CN pooling; allow using separate SS7 instances for IuCS and
IuPS.
New struct hnbgw_sccp_user describes a RANAP SCCP user, one per cs7.
Limit struct hnbgw_cnlink to describing a CN peer, using whichever SCCP
instance that is indicated by hnbgw_sccp_user.
Chart sccp.dot shows the changes made.
Related: SYS#6412
Change-Id: Iea1824f1c586723d989c80a909bae16bd2866e08
Show current use of SCCP and SS7 by osmo-hnbgw, which is about to
change (along with this chart).
Related: SYS#6422
Change-Id: I109948758de998326a5e9f0dcdc84d5f11dfba02
Get a handle on how osmo-hnbgw currently auto-configures itself, by
running vty tests with a couple of config files that have various levels
of omitted config items that are to be auto-configured.
These tests serve to ensure continuity and compatibility by upcoming
cnpool patches. They will show how the configuration changes / doesn't
change in all the right ways.
Uncover one bug in osmo-hnbgw: local point-code setting is discarded by
osmo-hnbgw startup when there are no SCCP address book entries in use.
The error is fixed as side effect of an upcoming patch:
Iea1824f1c586723d989c80a909bae16bd2866e08
Related: SYS#6412
Change-Id: Ic8bb30e1dd73753c2ff255566382e241918414f7
Instead of doc/examples/osmo-hnbgw.cfg, use a separate location
tests/osmo-hnbgw-vty-test.cfg for VTY transcript tests, and add a bunch
of SCCP address book entries that upcoming VTY tests will use.
Declaring address book entries within transcript tests is possible, but
cluttered with node 'exit' and VTY prompts -- these addresses are much
easier to read and maintain in form of a cfg file.
First user of these address book entries will be cnpool.vty in
I5479eded786ec26062d49403a8be12967f113cdb
Related: SYS#6412
Change-Id: Idcdf0e8660e8180fbe02282bc94e623ff89e848a
We have not a single example yet showing point code and SCCP address
configuration. Add this example, which will also show how the config
file syntax changes while introducing CN pooling in upcoming patches.
Related: SYS#6412
Change-Id: I42c3b434a7339cc3efb27b43c893cfb734de9ca4
The RUA side may disconnect
a) gracefully (RUA Disconnect with RANAP IU Release Complete) or
b) by detecting that the HNB is gone / has restarted
For a), the SCCP side waits for a RLSD from the CN that follows the IU
Release Complete.
For b), we so far also wait for a RLSD from CN, which will never come,
and only after a timeout send an SCCP RLSD to the CN.
Instead, for b), immediately send an SCCP RLSD.
To distinguish between the graceful release (a) and the disruptive
release (b), add new state MAP_RUA_ST_DISRUPTED on the RUA side,
and add new event MAP_SCCP_EV_RAN_LINK_LOST for the SCCP side.
Any non-graceful disconnect of RUA enters ST_DISRUPTED.
disrupted_onenter() dispatches EV_RAN_LINK_LOST to SCCP,
and SCCP directly sends RLSD to the CN without timeout.
These changes are also shown in doc/charts/hnbgw_context_map.msc.
Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1
We do not need to restore the parent node on vty_go_parent() anymore,
only call the ss7 go-parent callback to trigger actions on vty node
exit.
Change-Id: Id3ecc53885436294d2217c52130910872dde550e
When I implemented it, I thought context_map_check_released() would help
clarify context map deallocation, but instead it just bloats. Simplify
and tweak related comment.
Change-Id: I535780de0d3b09893ba89d66804e5e36b26db049
When in map_rua_fsm_cleanup(), we are always already deallocating the
context map, i.e. neither RUA nor SCCP are active anymore. No need to
call context_map_check_released() again.
Change-Id: I4bf9a9de7861296ec38c3a37de0254ad9a41ef1b
This looks like working RANAP RESET handling, but is in fact dead code.
Instead of testing and completing this implementation, I will copy the
RESET handling FSM from osmo-bsc, which is proven to work well.
See Id3eefdea889a736fd5957b80280fa45b9547b792
"detect in/active CN links by RANAP RESET"
The future patch will start to use transmit_rst(). So instead of
dropping now and resurrecting later, let's keep the code -- but it has
to be '#if 0'-ed to avoid compiler complaints about the unused function.
Related: SYS#6412
Change-Id: I7cacaec631051cf5420202f2f0dd9665a5565b17
Prepend it to the cs7 config .adoc, so that it introduces some concepts
and specifies some limitations of current implementation, etc.
Change-Id: I9faef2dd15b62814e474299c675c2cb05b779c44
Make this deprecated command fatal when in a .cfg file:
hnbgw
sccp cr max-payload-len N
Because we now have:
cs7 instance N
sccp max-optional-data N
from libosmo-sigtran to replace it.
Context: The old command currently has no effect, because we had
implemented the specified fixed 130 byte data limit in libosmo-sigtran.
Recent libosmo-sigtran adds a variable limit configuration.
I considered implementing a shim to redirect the legacy command to the
new implementation, but that would be quite ugly: the old command is
under the 'hnbgw' node and would have to apply to all 'cs7' instances.
But we cannot assume that all 'cs7' are above or below the 'hnbgw' node
in the .cfg file. So I'd have to add global state to remember the legacy
config's value and apply that everywhere else. IMHO this is too much
complexity to support an obsoleted command that has a replacement.
To rule out all confusion that this situation may otherwise create,
abort osmo-hnbgw startup in presence of the legacy VTY command, logging
an error that hints at the new cfg item.
Related: SYS#6423
Change-Id: I71f82efe07af2c32f2aa01084bc8da6ce5c6cd1a
Fix the following compile error, seen on ubuntu 18.04 with GCC 7.5.0,
opensuse 15.4 and our OE builds:
hnbgw.c:549:15: error: initializer element is not constant
.copyright = hnbgw_copyright,
^~~~~~~~~~~~~~~
Fixes: 04844415 ("move main() to separate file")
Change-Id: I13b2569a369724e0298b064a0876b95d6dafd9d0
Neels Hofmeyr
Pau Espin
Oliver Smith
Vadim Yanitskiy