We're already sending the RANAP CommonID message to the RNC,
let's do the same using BSSMAP CommonId towards the BSC. This
way the BSC knows about the IMSI of the served subscriber, which
is very useful for logging/debugging.
Change-Id: I2552736477663adb250c55728093500e8ae83ebb
Closes: OS#2969
Depends: libosmocore.git I353adc1aa72377f7d4b3336d2ff47791fb73d62c
Adopt the same way to run manual vty transcript tests as in
osmo-bsc/test/Makefile.am.
There are different ways to select a specific test to run in osmo-bsc and here
in osmo-msc. The osmo-bsc way is more convenient when building outside the src
tree, because it does not need the full absolute path of the test file.
Change-Id: If1e2abfa321a5e9fb60358d1f0e4e448b33184af
This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.
This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.
Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
There is an invalid Mobile Identity in the msc_vlr_test_gsm_ciph test data.
This became apparent when applying the new osmo_mobile_identity API (in a
following patch). Current Mobile Identity API ignores the error.
Change-Id: Ib1d54c59acc8b716de471ca275f54f9d22da3574
The example configs suggest to use a random ip-address as MGW address.
Lets use a loopback address here. This will suit the usual case where
MGW and MSC run together on the same machine.
Change-Id: Ie2b2094fdcfed45353d9ba22cb07eed626fd143c
Since the split of OsmoNiTB, OsmoMSC does not deal with the radio
access network directly. Therefore the only purpose of T3212 is to
control subscriber expiration in the local VLR. The timeout value
indicated in System Information Type 3 needs to be configured
separately in the BSC/RNC.
This means that we don't need to store it in deci-hours anymore.
Let's move T3212 to the group of VLR specific timers, so it can
be configured and introspected using the generic 'timer' command,
and deprecate the old '[no] periodic location update' command.
It should be also noted that in the old code subscriber expiration
timeout was actually set to twice the T3212 value plus one minute.
After this change, we apply the configured value 'as-is', but
keep the old behaviour for 'periodic location update' command.
Change-Id: I9b12066599a7c834a53a93acf5902d91273bc74f
These timers so far were implemented as a list of unsigned integers,
which has never been initialized to any reasonable defaults. Since
they are used as state timeouts in several FSMs, we might end up
staying in some state forever.
Let's migrate to generic osmo_tdef API and use default values from
table 11.2 of 3GPP TS 24.008. This way the user can introspect and
change their values from the VTY / configuration file.
Change-Id: Ia8cf98da0aea0e626c5ff088a833d7359c43847f
Related: OS#4368
This change introduces several new VTY commands letting the user
a possibility to introspect and reconfigure some of the existing
timers implemented using libosmocore's osmo_tdef API.
At the moment this covers the following timers:
- MGW specific timers:
- X1 - MGCP response timeout,
- X2 - RTP stream establishing timeout,
- RAN specific timers (same names for GERAN and UTRAN):
- X1 - Authentication and Ciphering timeout,
- X2 - RAN connection release sanity timeout,
- X3 - Handover procedure timeout.
The following commands are introduced:
- 'enable' node:
- show timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN]
- 'config-msc' node:
- timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] [(<0-2147483647>|default)]
Both MNCC and SCCP related timer definitions are empty at the
moment. Achieved by using osmo_tdef_group API of libosmovty.
Change-Id: I6024c104b6101666c8aa1108a043910eb75db9a5
Related: OS#4368
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I53ccde96dd3785098df0f7d693c504c8b8302e90
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS,
set CN-Domain = CS in all SendAuthInfo Requests.
In Milenage auth, it is highly desirable that osmo-hlr guarantees use of
distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same
time use the same IND bucket to generate Milenage SQN, that collision would
rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each
CS/PS Complete-Layer3.
So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo
Request, which was neither required nor evaluated. The CN-Domain is only sent
for the UpdateLocation Request that usually follows later.
Related: OS#4318
Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
Add a char buffer of 1024 characters length as space for SDP to pass to /
receive from MNCC.
Actually support receiving MNCC without such an SDP tail. The main reason for
this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would
stop working for older osmo-msc.
Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged
(save the protocol number bump) without having to implement SDP.
The SDP part in the MNCC protocol will be used in upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f.
This patch must be merged at the same time as osmo-sip-connector patch
Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching
MNCC protocol version number.
Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP
messages. Obviously, libosmo-mgcp-client already contains similar code, but
that is unfortunately heavily glued to the actual MGCP implementation. The
simplest solution is to create this separate implementation, copy-pasting from
the existing libosmo-mgcp-client code as is convenient.
This API is added here to probe whether it works well. When it does, the
intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our
MGCP client and MGCP server APIs using this same API.
Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
Substantial parts of the CC / MNCC call establishment were so far completely
missing from the msc_vlr_test_call.c tests. With my new insights on CC and MNCC
procedures, complete the tests.
Root reason: since I am going to re-order the sequence of events to enable
codec negotiation via SDP in MNCC, I want to have comprehensive tests of the CC
procedures to see the effect as diffs in the test output.
Change-Id: Ie995e264eb1e3dd9558a1753ff6f9b55c1d084e1
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early
return so far skipped logging of that MNCC message. Add this logging.
Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
Fix vty tests that are failing since libosmocore change
Ic225232fbfca49ba868427eaf898e1f6e34e1ca8. If OsmoMSC is built without
IU support, it fails with "cs7-instance-iu" in the config.
Change-Id: Ie56da9167badfd2399b566af91a345103f46c2a1
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP
message, which is in fact a very interesting detail when reading osmo-msc logs.
Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.
Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
We sometimes see errors like
libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!
i.e. changing state to the state msc_a is already in.
Ignore re-entering the same state for most state changes. However, there is one
state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary
to start the timeout.
Hence add msc_a_state_chg_always() and use that for re-entering
MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes.
This should silence all no-op state change error messages for msc_a.
Related: OS#4169
Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
Add a network -> callwaiting VTY command as boolean.
When this is enabled (default) there is no change to
operation previous to this commit.
When this switch is disabled with "no call-waiting" in vty
then when a call arrives, we will check if we have an active
call transaction for this subscriber, no matter if it is
establishing, established, or alerting, in any of these cases we
will return USER BUSY to the calling party.
Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
To not break the msc_vlr tests by new GSUP IEs added to some of the GSUP
messages, make msc_vlr_tests only match the start of the GSUP message and not
care about extra IEs. The extra IEs are anyway seen in the expected logs.
The reason to drop the msgb_eq_data_print() is because it is useless for
mismatching lengths. It will always print only the length mismatch, instead we
need to be able to compare with what was expected.
Change-Id: I38d51eeafab04ece83e4bb87bfaa967506f97b11
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer
BSSMAP Cipher Mode Complete message in the DEBUG log.
Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
Recently, the ability to run UTRAN without encryption was added, but the config
for it was tied to the A5 GERAN encryption configuration. This affected
osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3
test suite sets A5 to 0 (no encryption) but still expects Iu to enable air
encryption. Fix this "regression".
Add a separate vty config option for UEA encryption, even if it does not
provide full granularity to select individual UEA algorithms yet.
As a result, Iu default behavior remains to enable encryption regardless of the
A5 config. UTRAN encryption can be disabled by the new cfg option
"encryption uea 0" alone.
Even though the new vty command already allows passing various combinations of
the UEA algorithm numbers, only '0' and '1 2' are accepted as valid
combinations, to reflect current osmo-msc capabilities.
Revert most changes to the msc_vlr test suite in commit "do not force
encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new
net->iu_encryption instead of net->a5_encryption_mask.
Adjust/add to test_nodes.vty transcript tests.
Related: OS#4144
Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
Following I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7, have tests for UMTS
authentication both for cases with and without encryption.
- Rename test_umts_authen_utran to test_umts_auth_ciph_utran() (uses
encryption).
- Again add test_umts_authen_utran() not using encryption.
- Likewise with test_umts_authen_resync_utran().
Some permutations are still missing, like UMTS AKA on GERAN with encryption
enabled; not bothering at the moment.
Related: OS#2783
Change-Id: I54227f1f08c38c0bf69b9c48924669c4829b04b9
Remove the conditions that always enable encryption on UTRAN.
We so far lack an explicit configuration for UTRAN encryption, and this patch
does not add any either. Instead, whether UTRAN encryption is enabled is simply
triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though
GERAN and UTRAN encryption are not technically related at all, this makes UTRAN
behave like GERAN for now, until we implement a proper separate configuration
for UTRAN encryption.
Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask
such that the expected output remains unchanged. A subsequent patch
(I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly
cases of UTRAN without encryption.
Adjust manual and vty doc.
Related: OS#2783
Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
GSM 04.08 10.5.4.11
The Release indication needs to have the Coding Standard set.
For phones that would display a message on screen, such as
"Number not in use", if the coding standard is not defined,
the display may show "Error in Connection"
Change-Id: Ib28b62a41d433e231cff5910d19455296b284df6
Don't call tx_lu_rej() in the "vlr_lu_compl" FSM. It is always getting
called in the parent "lu" FSM and is therefore redundant:
_vlr_lu_compl_fsm_done(fi, VLR_FSM_RESULT_FAILURE, cause)
-> osmo_fsm_inst_state_chg(fi, LU_COMPL_VLR_S_DONE, 0, 0)
-> vlr_lu_compl_fsm_dispatch_result()
-> lu_fsm_wait_lu_compl()/lu_fsm_wait_lu_compl_standalone()
-> lu_fsm_failure()
-> lfp->vlr->ops.tx_lu_rej()
I have noticed the bug with the TTCN3 tests. This patch fixes
TC_lu_imsi_auth_tmsi_check_imei_{nack,err} after stricter checking
in [1] and also TC_iu_mo_crcx_ran_reject.
[1] I836f76242463789c4c003feec757714827f2a31b (osmo-ttcn3-hacks)
Change-Id: I127b27937613ea0ff29d67991c0414fca6d441d9
osmo_counter will be soon deprecated. Use the newer and more flexible
osmo_stat_item instead.
Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore)
Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
The function name implies OSMO_RAT_GERAN_A, and it has nothing
to do with other OSMO_RAT_* types. Found using clang:
warning: too many arguments in call to 'expect_bssap_clear'
expect_bssap_clear(OSMO_RAT_GERAN_A);
^^^^^^^^^^^^^^^^
Change-Id: Id3a3af33fcc5da4ca4c48a2f589a69f3568d2586
In gsm0911_gsup_rx() we do call vlr_subscr_find_by_imsi(), which
increases subscriber's reference count by one using the function
name as the token. However, we never release this token, so the
reference count grows on every received GSUP PROC-SS message.
Change-Id: I5540556b1c75f6873883e46b78656f31fc1ef186
In case of network-originated SS/USSD session establishment, we
need to verify the received GSUP PROC_SS_REQ message and make
sure that all mandatory IEs are present.
There is no sensible need to allocate a new transaction before
doing all the checks, other than the ability to use LOG_TRANS().
This complicates the code, so let's avoid the early allocation.
Change-Id: I4e027b19e8065a39324a1647957cef4066b82ce7
It is expected that establish_nc_ss_trans() returns an allocated
transaction in successful case, or NULL in case of error. The
function assumes two scenarios:
- the subscriber already has an active RAN connection,
- RAN connection needs to be established (Paging).
In the first case, a pointer to the transaction is returned as
expected, but in case of Paging, NULL has always been returned,
even if there were no errors. Let's fix this.
Change-Id: I9dcee64dd0b435ef29630c223132b81724701f93
The initial idea of the SMS expiry threshold was to avoid storing
SMS messages with too long validity time (e.g. 63 weeks).
Unfortunately, neither this feature was properly documented, nor
the expiry threshold is configurable. Moreover, it has been
implemented in a wrong way, so instead of deleting the oldest
expired message, it would delete the youngest one or nothing:
SELECT ... FROM SMS ORDER BY created LIMIT 1;
while it should be sorted by 'valid_until' in ascending order:
SELECT .. FROM SMS ORDER BY valid_until LIMIT 1;
Thus, if the oldest message is expired, it gets deleted. If the
oldest message is not expired yet, there is nothing to delete.
Change-Id: I0ce6b1ab50986dc69a2be4ea62b6a24c7f3f8f0a
Newer versions of libdbi print to stderr unconditionally when trying to
load drivers from /usr/lib/dbd. This makes test output to change
depending on host/distro set up (installed modules).
Let's get those messages out to make it easier for people having tests
pass.
We swap stderr/stdout instead of mixing to avoud future possible race
conditions if both get content writen into them.
Change-Id: Iec78826d28435f464be22e81b3776a6ae8326d59
man memcp doesn't define exact values for returned integer, it only
specifices a meaning for the sign of it.
So it happens that different versions/implementations actually return
different values when this test is run, making it fail.
Let's simply drop that info from logs since anyways it's not useful.
Change-Id: I771fb8f4fc56f337b16561d005ff1803a386d1c6
Thanks to db_sms_test, it was discovered that storing an SMS with
empty TP-User-Data (TP-UDL=1) causes buffer overruns in libdbi
and it's SQLite3 driver (libdbdsqlite3):
DDB NOTICE test_db_sms_store('Empty TP-UD'): ==7791== Invalid write of size 2
==7791== at 0x857DC60: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
==7791== Address 0x7ed1cf0 is 0 bytes after a block of size 0 alloc'd
==7791== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7791== by 0x857DC4B: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
...
DDB NOTICE test_db_sms_get('Empty TP-UD'): ==8051== Invalid read of size 1
==8051== at 0x5B30510: _dbd_decode_binary (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x857D957: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051== Address 0x8f74641 is 0 bytes after a block of size 1 alloc'd
==8051== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8051== by 0x5DBEB49: strdup (strdup.c:42)
==8051== by 0x857D93C: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051==
success, as expected
DDB NOTICE verify_sms('Empty TP-UD'): user_data_len mismatch: E0 vs A3
Apparently, dbi_conn_quote_binary_copy() doesn't properly handle
zero-length input. Let's guard against this.
Observed with:
- libdbi-dev 0.9.0-1
- libdbd-sqlite3:amd64 0.9.0-2ubuntu2
Change-Id: If0b2bb557118c5f0e520a2e6c2816336f6028661
Since OsmoMSC has built-in SMSC, it needs to store the messages
somewhere. Currently we use libdbi and SQLite3 back-end for that.
For a long time, the db_sms_* API remained uncovered by unit tests.
This change aims to fix that, and does cover the following calls:
- db_sms_store(),
- db_sms_get(),
- db_sms_get_next_unsent(),
- db_sms_mark_delivered(),
- db_sms_delete_sent_message_by_id(),
- db_sms_delete_by_msisdn(),
- db_sms_delete_oldest_expired_message().
Due to performance reasons, the test database is initialized in
RAM using the magic filename ':memory:'. This is a feature of
SQLite3 (and not libdbi), see:
https://www.sqlite.org/inmemorydb.html
Of course, this unit test helped to discover some problems:
1) Storing an SMS with empty TP-User-Data (TP-UDL=0) causes
buffer overruns in both db_sms_store() and db_sms_get().
2) TP-User-Data-Length is always being interpreted in octets,
regardless of DCS (Data Coding Scheme). This results in
storing garbage in the database if the default 7-bit
encoding is used. Fortunately, the 'user_data' buffer
in structure 'gsm_sms' is large emough, so we don't
experience buffer overruns.
3) db_sms_delete_oldest_expired_message() doesn't work
as expected. Instead of removing the *oldest* expired
message, it tries to remove the *newest* one.
The current test expectations do reflect these problems.
All of them will be fixed in the follow-up patches.
Change-Id: Id94ad35b6f78f839137db2e17010fbf9b40111a3
We also need stubs for the upcoming db_sms tests.
Due to a known bug of automake [1], we cannot use 'subdir-objects',
so as a side effect this change introduces some autoreconf warnings.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993
Change-Id: I8846c940f2695fd33e1007fecac83e73f508bb34
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to
the HLR before doing the location update with the HLR.
The OsmoHLR documentation referenced in the code will be added in
osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9.
Related: OS#2542
Change-Id: I88283cad23793b475445d814ff49db534cb41244
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will
get cut off then. This is needed for the subscriber on demand use case,
since we can get the IMEISV early (see [1]), but need to send the IMEI
to the Check IMEI procedure.
While adjusting the tests, I have noticed that there are code paths
where we ask the MS for the IMEISV first, and later ask the MS for the
IMEI, although we already have the IMEISV. This could be improved in a
future patch.
[1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f
Related: OS#2542
Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
Set the length of vlr_subscr->imei to
GSM23003_IMEI_NUM_DIGITS_NO_CHK (14)
instead of
GSM23003_IMEISV_NUM_DIGITS (16).
Note that there is also GSM23003_IMEI_NUM_DIGITS (15), which includes
an additional checksum digit. This digit is not intended for digital
transmission, so we don't need to store it. Also by not storing it, we
can simply copy the IMEI-part from the IMEISV to the IMEI without
worrying about the checksum (will be done in a follow up patch).
A good overview of the IMEI/IMEISV structure is here:
https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_(IMEI_software_version)
Related: OS#2542
Change-Id: Iaf2569c099874b55acbd748b776394726cc5ce54
Prepare for Rhizomatica's subscriber on demand use case, in which the
network access is disabled by default for new subscribers, but the IMEI
is required in the HLR to find out which user has which IMSI. Due to the
network access being disabled, the location update request towards the
HLR fails and the MS gets rejected, so we need to get the IMEI early.
Related: OS#2542, OS#3755
Change-Id: I256224194c3b8caf2b58a88d11dccd32c569201f
The librt is required for old glibc < 2.17 to get clock_gettime().
Since we do check the availability of this function libosmocore
and conditionally link it against librt, there is no need to do
such unconditional and redundant linkage here.
Change-Id: If587d16d2db677b97e3a0641027eb735af9c9c30
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather
store in trans->log_subsys once on trans_alloc() and use that.
Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little
sense and may cause logging to switch subsystems depending on the RAN state.
In trans_log_subsys(), add missing switch cases:
- Log silent call transactions also on CC.
- Log USSD on DMM.
About USSD: we currently have no dedicated USSD logging category. As a result,
after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC,
depending on whether a RAN was associated with the trans or not. Before that
change, USSD always logged on DMM, so, until we have a separate logging
category for USSD, consistenly use DMM again.
[1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7
Related: coverity CID 198453
Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
While developing the inter-MSC handover refactoring, I was annoyed by the fact
that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as
well as a separate msg_type argument, which may deviate from each other. So, as
a first step I wanted to make sure that all callers send identical values for
both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going
to remove the separate msg_type argument.
I then forgot to
- carry on to remove the argument and
- to actually test with internal MNCC (it so happens that all of our ttcn3
tests also use external MNCC).
As a result, the "large refactoring" patch for inter-MSC Handover breaks
internal MNCC operation.
Fix that: remove the separate msg_type argument and make sure that all callers
of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence
also remove the odd duality of arguments.
Various functions in mncc_builtin.c also exhibit this separate msg_type
argument, which are all unused and make absolutely no sense. Remove those as
well.
Related: OS#3989
Change-Id: I966ce764796982709ea3312e76988a95257acb8d
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.
After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.
MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.
Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.
Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
(GSUP),
- no call routing between MSC-A and -I via MNCC necessary.
This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.
The following are some details and rationale for this rather huge refactoring:
* separate MSC subscriber management from ran_conn
struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.
The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.
Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.
* New SCCP implementation for RAN access
To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.
sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.
* RAN Abstraction (BSSAP vs. RANAP)
The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.
ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:
- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
matching RAN peers.
* RAN RESET now also for RANAP
ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)
* RAN de-/encoding abstraction
The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role. However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.
ran_msg.h provides a common API with abstraction for:
- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
that should be encoded to either BSSMAP or RANAP and passed down to the
BSC/RNC and MS/UE.
The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.
In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.
Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.
* MGW and RTP stream management
So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.
The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
call, a combination of two RTP streams to forward between two remote peers.
BSC MGW PBX
CI CI
[MGW-endpoint]
[--rtp_stream--] [--rtp_stream--]
[----------------call_leg----------------]
* Use counts
Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant. Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.
* FSM Timeouts
Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Start using osmo_fsm_term_safely(true), the recently added feature of
libosmocore's fsm.c. Deallocates in slightly changed order and with slightly
modified logging. Adjust test expectations.
Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore)
Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
As we don't initialize all talloc contects of libmsc, let's make
sure that there is nothing left in the NULL context after the
unit test execution is finished.
Change-Id: I99fd82750aff376e4d90eaa2402ec41f4d59ef86
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
Comparing an array to null is not useful, because the expression
will always evaluate as true. Let's just always write SGs server
address and VLR name, no mater whether default values are used
or not, same as we do for the HLR address and port.
Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b
Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
It may happen that either the MS or an EUSE would become
unresponsive during a call independent SS session, e.g.
due to a bug, or a dropped message. In such cases, the
corresponding transaction would remain unfreed forever.
This change introduces a guard timer, that prevents keeping
'stalled' NCSS sessions forever. As soon as it expires, both
sides (i.e. MS and EUSE) are getting notified, and the
transaction is being released.
By default, the timer expires after 30 seconds. As soon as
either the MS, or an EUSE initiates any activity,
the watchdog timer is rescheduled.
The timeout value can be configured from the VTY:
msc
...
! Use 0 to disable this timer
ncss guard-timeout 30
Please note that changing the timeout value at run-time
doesn't affect the existing NCSS sessions, excepting the
case when the timer is disabled at run-time.
This change makes TC_lu_and_ss_session_timeout pass.
Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb
Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f
Related: OS#3655
For some reason the existing code was using msgb_hexdump_l2() while the
L2 header is not used by the BSSAP transmit code. Let's fix this.
Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
We don't want multiple callers to osmo_sccp_tx_data_msg() each having
to hex-dump a log message about the to-be-transmitted message, with
half of the caller sitest missing that printing. Let's centralize
all calls of osmo_sccp_tx_data_msg() in a wrapper function which
takes care of the related OSMO_ASSERT() and the related printing.
Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
This simplifies tests refactoring by showing exact byte where mismatch
happened. It also makes code more readable.
No changes in expected test output are necessary because the additional
logging will be triggered iff the test fails so the result will be
visible only during debugging of unit test issues.
Change-Id: If9771c973f2bc55580f4c146bdbeeb1609d56786
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)
Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
The likely reason why it was disabled is due to
paging_cb_mmsms_est_req() logging pointers which results in unstable log
output. Fixing this allows us to track SMS-related regressions properly.
Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
When check-imei-req is enabled in the VTY config, do not accept IMEIs
sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait
for its ACK or NACK.
OsmoHLR also accepts all IMEIs at this point, but this allows to
optionally store the IMEI in the HLR DB.
Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr)
Related: OS#3733
Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static
buffer in ran_conn_get_conn_id(). So far this function had no callers.
Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber
is associated yet, update the FSM Id by the MI type seen in the L3 Complete
message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update.
Call vlr.ops->subscr_update when the TMSI is updated, so that log context
includes the TMSI from then on.
Enrich context for vlr_subscr_name and ran_conn fi name.
Include all available information in vlr_subscr_name(); instead of either IMSI
or MSISDN or TMSI, print all of them when present. Instead of a short log,
rather have more valuable context.
A context info would now look like:
Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP)
It does get quite long, but ensures easy correlation of any BSSAP / IuCS
messages with log output, especially if multiple subscribers are busy at the
same time.
Print TMSI and TMSInew in uppercase hexadecimal, which is the typical
representation in the telecom world.
When showing the RAN conn id
GERAN_A-00000017
becomes
GERAN-A-23
- We usually write the conn_id in decimal.
- Leading zeros are clutter and might suggest hexadecimal format.
- 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name().
Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore)
Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore)
Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
When a CM Service Req is being rejected, we should do so before changing the
state of the current conn.
Concerning multiple CM Service Requests: in fact we should store multiple
requests, but first fix the status quo of rejecting multiple requests.
Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
For each conn, set a default logging category, to distinguish categories for
BSSMAP and RANAP based conns.
LOG_RAN_CONN(): log with the conn's default category,
LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping
previous DMM logging on the same category).
In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and
remove the manual context info, now provided by the conn->fi->id.
This is loosely related to inter-BSC and inter-MSC handover: to speed up
refactoring, I want to avoid the need for manual logging context and just use
this LOG_RAN_CONN().
Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.
The string representations change, which has cosmetic effects on the test suite
expectations.
Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
during code review, I completely overlooked this:
We've added the 'ipa-name', which identifies the MSC on the GSUP link to the
HLR, under the 'msc' section, while all other GSUP/HLR related config is under
the 'hlr' section.
Before we roll that out in a release, move it over to 'hlr'.
Related: OS#3355
Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
Various places in the code check a flag whether assignment was started and
launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic.
To be able to do that only in one place, remove code dup.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL)
Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS
processing, storage (in SQLite DB), and routing (via SMPP).
In real networks this is done by the external entity called
SMSC (SMS Centre), while the MSC is doing re-encapsulation
of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU)
between SM-RL (Relay Layer) and MAP.
Since OsmoMSC itself is not a 'Network in The Box' anymore, it
makes sense to replicate the 'traditional' behaviour of MSC.
The problem is that this behaviour cannot co-exist with the
current implementation, so the key idea is to rip out the
local SMS storage and routing from OsmoMSC, and (re)implement
it in a separate process (OsmoSMSC?).
As a temporary solution, this change introduces a 'kill-switch'
VTY option that enables routing of SMS messages over GSUP
towards ESME (through VLR and HLR), but breaks the local
storage and routing. This is why it's disabled by default.
As soon as we move the SMS processing and storage away from
OsmoMSC, this behaviour would be enabled by default, and
the VTY option would be hidden and deprecated. At the moment,
this option basically does nothing, and will take an effect
in the follow-up changes.
Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b
Related: OS#3587
Always use LAC which is part of Cell Global ID otherwise we might end up
in a situation where separately stored LAC differs.
Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data
to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part
of LAI which is part of CGI so there should be no case when those values
differ for a given subscriber.
Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
Avoid leaking details on accessing data structure for LAC value into
test output: that's irrelevant clutter which forces unnecessary test
output modifications.
Change-Id: I4a1d7884cf47ad513d7d6fb27c5c6f1b829dff2e
To avoid leaking structure details into test we sometimes have to
separate value description from actual value. Introduce new macro which
makes that possible and convert old one into trivial wrapper around it.
Change-Id: Ic462297edac4c55689f93cc45771c8b5e2aed864
Add a 'ipa-name' VTY command which overrides the default IPA name
used by the MSC. This is a prerequisite for inter-MSC handover.
Related: OS#3355
Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
sub_pres_vlr_fsm_start() starts the FSM, invokes the START event, and then this
FSM invariably always directly terminates when vsub->ms_not_reachable_flag ==
false.
So if it is false, there is not much use in instantiating a whole FSM instance
that just terminates again, we might as well directly issue the
parent-term-event and save some logging space.
The same condition is already in place in the vlr_proc_acc_fsm.c in
_proc_arq_vlr_node2_post_vlr() for CM Service Request and Paging Response. Now
also skip this for LU.
Change-Id: Id2303a795dfd381f76e94ff8ff2f495926ca8ba0
So far the only way to use external MNCC is to pass the -M cmdline arg:
osmo-msc -M /path/to/socket
However, the osmo-msc.service file for systemd is installed by 'make install',
and hence it is quite impractical to depend on such a config item to be
required in the service file:
- It defies any scheme an operator may have in place to compose the
osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs
separate action to add to the installed service file.
- After a make install or package upgrades / re-installations, this option will
be plain overwritten silently, or lead to the need for resolving file
conflicts.
The initial spark for this came from configuring the 35c3 GSM from cfg
templates.
Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
I want to add 'mncc internal' and 'mncc external' commands, and IMHO makes most
sense to have a common 'mncc' keyword to start MNCC config commands with. To
put it in terms of VTY online help:
OsmoMSC(config-msc)# mncc ?
internal Use internal MNCC handler
external Use internal MNCC handler
guard-timeout Set global guard timeout
So far only the 'guard-timeout' exists, I want to add 'internal' and 'external'
in a subsequent commit.
Keep the old command 'mncc-guard-timeout' as deprecated alias. That means it
still works from old config files, but online documentation will omit it.
On 'write', write back the new format instead.
Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee
Change-Id: I52d69af48e1ddc87b3fb54bf66a01b1b8cbf5abe
It needs to work whether SMPP,Iu are enable or disabled, hence a bit more
wildcarding than one might expect.
Change-Id: I3a8c50d8d555b6b948d97d6412e17594ee439de0
Separate 'make python-test' into separate make targets, to sensibly add VTY
transcript tests in an upcoming commit.
Feature: even though ./configure was called without --enable-external-tests,
each of the {ctrl,vty}x{python,transcript} tests can be invoked individually by
e.g. 'make vty-python-test'.
Both 'vty-transcript-test' and 'ctrl-transcript-test' are still empty, a
subsequent patch adds a vty-transcript-test.
All of this in preparation of tweaking the 'mncc' vty configuration, to be able
to track it in a vty transcript test.
Change-Id: I688657e56ae469c07b9f25ba37275d38dbd457e2
I'm going to make the external tests manually launchable. For that I first had
an error message if $(PYTHON) was empty. But Pau says I should just use shebang
instead and ignore the autoconf python stuff, since that often fails anyway.
Change-Id: Ie35dd78c42577109a6a3143221a9769e47d361a5
gsm_subscriber.h contains some legacy cruft, part of which is that the VLR's
max MSISDN length should rather be defined in vlr.h. Same for GSM_NAME_LENGTH
-> VLR_NAME_LENGTH.
Adjust some sms_queue stuff that anyway includes vlr.h already.
Drop gsm_subscriber.h from vlr.h.
Add other (more concise) includes that thus become necessary, since the include
chain vlr.h->gsm_subscriber.h->gsm_data.h is no longer in place.
Change-Id: Iab5c507ec04fc2884187cf946f6ae2240e4a31f8
Along goes GSM_KEYSEQ_INVAL as VLR_*.
It's where it logically belongs, and is almost the only reason why vlr.h
includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved
by upcoming patch.
Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
For hysterical raisins, there are some header files that contain few
declarations, and where the name doesn't reflect the content. Combine them to
new msc_common.h:
- common.h
- common_cs.h
- osmo_msc.h
Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
Following previous rename of gsm_subscriber_connection:
Some functions and #defines are still called like "msc_conn" or just "msc_",
while they are clearly about a RAN conn.
To avoid confusion with the future separate concepts of MSC roles and a RAN
connection, rename all those to match the common "ran_conn" prefix.
Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
Harald Welte
Neels Hofmeyr
Philipp Maier
Oliver Smith
Martin Hauke
Keith Whyte
Pau Espin