In the field, we've encountered a so far unsupported scenario: after a
RAB Assignment Request and Response have successfully set up an RTP
stream, the CN sends *another* RAB Assignment Request to modify some SDU
parameters, omitting the transportLayerInformation IE (not modifying the
RTP address).
Directly forward all RAB Assignment Requests that have no RTP
information. This covers above use case, and also generally applies: no
RTP info means nothing to tell the MGW about.
Do not (yet?) support modifying the RTP address/port.
Related: osmo-ttcn3-hacks Iadaba0e5e82ad6d163ad509904ede213e2462d5c
Related: SYS#6624
Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
The actual scope is larger than just a stale release. Every RUA and SCCP
context map FSM state that has a timeout uses X31. (Seems I intended to
add more timers but forgot to follow up when I wrote it.)
Related: SYS#6602
Change-Id: I75a25f9065bc651e7ba8feda6db03c49a3b75c5e
This was being triggered recently by
HNBGW_Tests.TC_ranap_cs_mo_disconnect in osmo-ttcn3-hacks.git.
Change-Id: Idaad11eaa3c2e56de792f80bab1f1d8435ef9b68
It was spotted that in some deploys with satellite links and heavy load,
the roundtrip times for CR and CC can go slightly over 12 seconds, so
better increase the default value to 15 seconds to be on a safer place
and avoid operation problems with default configuration.
Related: SYS#6602, SYS#6616
Change-Id: I24225cfc0addf326c239ec658a27b93b83a3e751
The HNBGW in correctly assumes that no ss7->sccp instance is allocated
until the same function calls osmo_sccp_simple_client_on_ss7_id().
This assumption is wrong, since ss7 may create its own ss7->sccp
instance internally as a result of vty configuration, eg. when "sccp
max-optional-data 124" is placed in osmo-hnbgw.cfg file.
In this scenario, simply removing the assert is enough, since
osmo_sccp_simple_client_on_ss7_id() just calls osmo_ss7_ensure_sccp(),
the same that the libmoso-sccp code called to allocate the pointer.
Related: SYS#6566
Fixes: f3caea850b
Change-Id: I1221c165156e9625324cf0080836a8ed2bad4e9c
Due to ip probing used at MGW and specific/complex routing in place
between RAN and CN, it may happen that, on the RAN-side endpoint connection,
the MGW first selects a local IP address.
Then, after the HNBGW signalling it to the HNB with the patched RabAssReq
and receiving the HNB local IP address through RabAssResp, then applying
it to MGW through MDCX, it can happen that the MDCX ACK contains a changed
local IP address at the MGW, due to IP probing after learning the remote
address.
This change is so far not announced to the HNB in anyway, ending up in the
HNB sending IuUP packets to the wrong IP/port, which is rejected with ICMP
due to osmo-mgw having no socket open there anymore.
We should at least, in osmo-hnbgw, if detecting the local MGW IP address
changed during MDCX, tear down the call setup. This patch does precisely
that.
Related: OS#6127
Change-Id: I32c4a7f838ceb5077bec7945e7976ce455d6b025
When we use the ASN.1 decoder functions, we often reserve some memory on
the stack to store the results. (e.g. RANAP_RAB_xy_t _RANAP_RAB_xy;).
Then we assign the memory location to a pointer variable (e.g.
RANAP_RAB_xy = &_RANAP_RAB_xy). We do this for cosmetic reasons but we
may end up with an uninitialized buffer, which may cause trouble
lateron. Let's be consistent and make sure that those buffers are
initialized with zeros.
Change-Id: I7a8a951ccd8c9ae3923261468c0755192894a84b
When we check for an assignment failure in a RAB AssignmnetResponse, we
use decode_rab_flitms_from_resp_ies to search through the list of RAB
FailedItemsIEs for the RAB id we want to check. In case of failure, we
get a positive index back from this function. We then know that the RAB
that we checked for has failed bcause it was in the FailedItemsList.
In that case, we also must free the RAB FailedItemsIEs that
decode_rab_flitms_from_resp_ies has decoded. At the moment we also free
the RAB FailedItemsIEs also when decode_rab_flitms_from_resp_ies returns
with a negative return code, which may mean that the RAB was not found
or some other error occured. In this case we must not free since then
no valid RAB FailedItemsIEs are allocated.
Related: OS#6062
Change-Id: I755ba6599079810a048bf5b6d8947b5a9ffa622d
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
Neels Hofmeyr
Pau Espin
Philipp Maier