2010-06-15 03:52:51 +00:00
|
|
|
/* main MSC management code... */
|
|
|
|
|
|
|
|
/*
|
2013-06-30 13:30:47 +00:00
|
|
|
* (C) 2010,2013 by Holger Hans Peter Freyther <zecke@selfish.org>
|
2010-10-06 12:37:09 +00:00
|
|
|
* (C) 2010 by On-Waves
|
2010-06-15 03:52:51 +00:00
|
|
|
*
|
|
|
|
* All Rights Reserved
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
2011-01-01 14:25:50 +00:00
|
|
|
* it under the terms of the GNU Affero General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
2010-06-15 03:52:51 +00:00
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2011-01-01 14:25:50 +00:00
|
|
|
* GNU Affero General Public License for more details.
|
2010-06-15 03:52:51 +00:00
|
|
|
*
|
2011-01-01 14:25:50 +00:00
|
|
|
* You should have received a copy of the GNU Affero General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
2010-06-15 03:52:51 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2017-09-04 13:04:35 +00:00
|
|
|
#include <osmocom/msc/debug.h>
|
|
|
|
#include <osmocom/msc/transaction.h>
|
|
|
|
#include <osmocom/msc/db.h>
|
|
|
|
#include <osmocom/msc/vlr.h>
|
|
|
|
#include <osmocom/msc/a_iface.h>
|
2017-09-15 09:22:30 +00:00
|
|
|
#include <osmocom/msc/gsm_04_08.h>
|
2017-09-04 13:04:35 +00:00
|
|
|
#include <osmocom/msc/gsm_04_11.h>
|
2018-12-19 16:05:13 +00:00
|
|
|
#include <osmocom/msc/msc_mgcp.h>
|
2010-06-15 04:03:10 +00:00
|
|
|
|
2017-07-05 13:19:52 +00:00
|
|
|
#include "../../bscconfig.h"
|
|
|
|
#ifdef BUILD_IU
|
|
|
|
#include <osmocom/ranap/iu_client.h>
|
|
|
|
#else
|
2017-09-04 13:04:35 +00:00
|
|
|
#include <osmocom/msc/iu_dummy.h>
|
2017-07-05 13:19:52 +00:00
|
|
|
#endif
|
|
|
|
|
2018-03-22 15:43:40 +00:00
|
|
|
struct gsm_network *gsm_network_init(void *ctx, mncc_recv_cb_t mncc_recv)
|
|
|
|
{
|
|
|
|
struct gsm_network *net;
|
|
|
|
|
|
|
|
net = talloc_zero(ctx, struct gsm_network);
|
|
|
|
if (!net)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
net->plmn = (struct osmo_plmn_id){ .mcc=1, .mnc=1 };
|
|
|
|
|
|
|
|
/* Permit a compile-time default of A5/3 and A5/1 */
|
|
|
|
net->a5_encryption_mask = (1 << 3) | (1 << 1);
|
|
|
|
|
|
|
|
/* Use 30 min periodic update interval as sane default */
|
|
|
|
net->t3212 = 5;
|
|
|
|
|
2018-10-10 15:00:49 +00:00
|
|
|
net->mncc_guard_timeout = 180;
|
|
|
|
|
2018-03-22 15:43:40 +00:00
|
|
|
net->paging_response_timer = MSC_PAGING_RESPONSE_TIMER_DEFAULT;
|
|
|
|
|
|
|
|
INIT_LLIST_HEAD(&net->trans_list);
|
|
|
|
INIT_LLIST_HEAD(&net->upqueue);
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
INIT_LLIST_HEAD(&net->ran_conns);
|
2018-03-22 15:43:40 +00:00
|
|
|
|
|
|
|
/* init statistics */
|
|
|
|
net->msc_ctrs = rate_ctr_group_alloc(net, &msc_ctrg_desc, 0);
|
|
|
|
if (!net->msc_ctrs) {
|
|
|
|
talloc_free(net);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
net->active_calls = osmo_counter_alloc("msc.active_calls");
|
2018-06-26 11:27:25 +00:00
|
|
|
net->active_nc_ss = osmo_counter_alloc("msc.active_nc_ss");
|
2018-03-22 15:43:40 +00:00
|
|
|
|
|
|
|
net->mncc_recv = mncc_recv;
|
|
|
|
|
|
|
|
INIT_LLIST_HEAD(&net->a.bscs);
|
|
|
|
|
|
|
|
return net;
|
|
|
|
}
|
|
|
|
|
2018-12-05 00:11:28 +00:00
|
|
|
void gsm_network_set_mncc_sock_path(struct gsm_network *net, const char *mncc_sock_path)
|
|
|
|
{
|
|
|
|
if (net->mncc_sock_path)
|
|
|
|
talloc_free(net->mncc_sock_path);
|
|
|
|
net->mncc_sock_path = mncc_sock_path ? talloc_strdup(net, mncc_sock_path) : NULL;
|
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* Receive a SAPI-N-REJECT from BSC */
|
2018-11-30 00:08:36 +00:00
|
|
|
void ran_conn_sapi_n_reject(struct ran_conn *conn, int dlci)
|
2010-06-15 03:52:51 +00:00
|
|
|
{
|
2010-06-15 04:03:10 +00:00
|
|
|
int sapi = dlci & 0x7;
|
|
|
|
|
|
|
|
if (sapi == UM_SAPI_SMS)
|
|
|
|
gsm411_sapi_n_reject(conn);
|
2010-06-15 03:52:51 +00:00
|
|
|
}
|
|
|
|
|
2018-11-30 00:20:32 +00:00
|
|
|
/* receive a Level 3 Complete message.
|
|
|
|
* Ownership of the conn is completely passed to the conn FSM, i.e. for both acceptance and rejection,
|
|
|
|
* the conn FSM shall decide when to release this conn. It may already be discarded before this exits. */
|
2018-11-30 00:08:36 +00:00
|
|
|
void ran_conn_compl_l3(struct ran_conn *conn,
|
|
|
|
struct msgb *msg, uint16_t chosen_channel)
|
2010-06-17 08:41:25 +00:00
|
|
|
{
|
2018-11-30 00:08:36 +00:00
|
|
|
ran_conn_get(conn, RAN_CONN_USE_COMPL_L3);
|
2010-06-17 08:41:25 +00:00
|
|
|
gsm0408_dispatch(conn, msg);
|
2018-11-30 00:08:36 +00:00
|
|
|
ran_conn_put(conn, RAN_CONN_USE_COMPL_L3);
|
2010-06-17 08:41:25 +00:00
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* Receive a DTAP message from BSC */
|
2018-11-30 00:08:36 +00:00
|
|
|
void ran_conn_dtap(struct ran_conn *conn, struct msgb *msg)
|
2010-06-17 08:41:25 +00:00
|
|
|
{
|
2018-11-30 00:08:36 +00:00
|
|
|
ran_conn_get(conn, RAN_CONN_USE_DTAP);
|
2010-06-17 08:41:25 +00:00
|
|
|
gsm0408_dispatch(conn, msg);
|
2016-06-19 16:06:02 +00:00
|
|
|
|
2018-11-30 00:08:36 +00:00
|
|
|
ran_conn_put(conn, RAN_CONN_USE_DTAP);
|
2010-06-17 08:41:25 +00:00
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* Receive an ASSIGNMENT COMPLETE from BSC */
|
2018-12-11 17:59:27 +00:00
|
|
|
void msc_assign_compl(struct ran_conn *conn,
|
|
|
|
uint8_t rr_cause, uint8_t chosen_channel,
|
|
|
|
uint8_t encr_alg_id, uint8_t speec)
|
2011-12-27 11:31:02 +00:00
|
|
|
{
|
2018-12-11 17:59:27 +00:00
|
|
|
LOGP(DRR, LOGL_DEBUG, "MSC assign complete (do nothing).\n");
|
2011-12-27 11:31:02 +00:00
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* Receive an ASSIGNMENT FAILURE from BSC */
|
2018-11-30 00:08:36 +00:00
|
|
|
void ran_conn_assign_fail(struct ran_conn *conn, uint8_t cause, uint8_t *rr_cause)
|
2011-12-27 11:31:02 +00:00
|
|
|
{
|
2018-12-19 16:05:13 +00:00
|
|
|
LOGPFSMSL(conn->fi, DRR, LOGL_ERROR, "Assignment Failure: cause=%u rr_cause=%u.\n",
|
|
|
|
cause, rr_cause ? *rr_cause : 0);
|
|
|
|
msc_mgcp_ass_fail(conn);
|
2011-12-27 11:31:02 +00:00
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* Receive a CLASSMARK CHANGE from BSC */
|
2018-11-30 00:08:36 +00:00
|
|
|
void ran_conn_classmark_chg(struct ran_conn *conn,
|
|
|
|
const uint8_t *cm2, uint8_t cm2_len,
|
|
|
|
const uint8_t *cm3, uint8_t cm3_len)
|
2012-01-23 09:28:35 +00:00
|
|
|
{
|
2018-09-18 13:52:58 +00:00
|
|
|
struct gsm_classmark *cm;
|
|
|
|
|
|
|
|
if (!conn->vsub)
|
|
|
|
cm = &conn->temporary_classmark;
|
|
|
|
else
|
|
|
|
cm = &conn->vsub->classmark;
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
if (cm2 && cm2_len) {
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
if (cm2_len > sizeof(cm->classmark2)) {
|
2016-06-19 16:06:02 +00:00
|
|
|
LOGP(DRR, LOGL_NOTICE, "%s: classmark2 is %u bytes, truncating at %zu bytes\n",
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
vlr_subscr_name(conn->vsub), cm2_len, sizeof(cm->classmark2));
|
|
|
|
cm2_len = sizeof(cm->classmark2);
|
2012-01-23 09:28:35 +00:00
|
|
|
}
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
cm->classmark2_len = cm2_len;
|
|
|
|
memcpy(cm->classmark2, cm2, cm2_len);
|
2016-06-19 16:06:02 +00:00
|
|
|
}
|
|
|
|
if (cm3 && cm3_len) {
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
if (cm3_len > sizeof(cm->classmark3)) {
|
2016-06-19 16:06:02 +00:00
|
|
|
LOGP(DRR, LOGL_NOTICE, "%s: classmark3 is %u bytes, truncating at %zu bytes\n",
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
vlr_subscr_name(conn->vsub), cm3_len, sizeof(cm->classmark3));
|
|
|
|
cm3_len = sizeof(cm->classmark3);
|
2016-06-19 16:06:02 +00:00
|
|
|
}
|
store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-13 01:05:52 +00:00
|
|
|
cm->classmark3_len = cm3_len;
|
|
|
|
memcpy(cm->classmark3, cm3, cm3_len);
|
2012-01-23 09:28:35 +00:00
|
|
|
}
|
A5/n Ciph: request Classmark Update if missing
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.
To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.
From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.
To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().
Rationale:
In the following commit, essentially we stopped supporting A5/3 ciphering:
commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.
This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.
If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.
Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.
In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.
In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.
Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-13 01:23:07 +00:00
|
|
|
|
|
|
|
/* bump subscr conn FSM in case it is waiting for a Classmark Update */
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
if (conn->fi->state == RAN_CONN_S_WAIT_CLASSMARK_UPDATE)
|
|
|
|
osmo_fsm_inst_dispatch(conn->fi, RAN_CONN_E_CLASSMARK_UPDATE, NULL);
|
2012-01-23 09:28:35 +00:00
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* Receive a CIPHERING MODE COMPLETE from BSC */
|
2018-11-30 00:08:36 +00:00
|
|
|
void ran_conn_cipher_mode_compl(struct ran_conn *conn, struct msgb *msg, uint8_t alg_id)
|
2012-01-23 15:40:24 +00:00
|
|
|
{
|
2016-06-19 16:06:02 +00:00
|
|
|
struct vlr_ciph_result ciph_res = { .cause = VLR_CIPH_REJECT };
|
|
|
|
|
|
|
|
if (!conn) {
|
2018-01-24 21:38:06 +00:00
|
|
|
LOGP(DRR, LOGL_ERROR, "invalid: rx Ciphering Mode Complete on NULL conn\n");
|
2016-06-19 16:06:02 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!conn->vsub) {
|
2018-01-24 21:38:06 +00:00
|
|
|
LOGP(DRR, LOGL_ERROR, "invalid: rx Ciphering Mode Complete for NULL subscr\n");
|
2012-01-23 15:40:24 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-01-24 21:38:06 +00:00
|
|
|
DEBUGP(DRR, "%s: CIPHERING MODE COMPLETE\n", vlr_subscr_name(conn->vsub));
|
2012-01-23 15:40:24 +00:00
|
|
|
|
2018-01-24 21:38:06 +00:00
|
|
|
if (msg) {
|
|
|
|
struct gsm48_hdr *gh = msgb_l3(msg);
|
|
|
|
unsigned int payload_len = msgb_l3len(msg) - sizeof(*gh);
|
|
|
|
struct tlv_parsed tp;
|
|
|
|
uint8_t mi_type;
|
|
|
|
|
|
|
|
if (!gh) {
|
|
|
|
LOGP(DRR, LOGL_ERROR, "invalid: msgb without l3 header\n");
|
|
|
|
return;
|
|
|
|
}
|
2012-01-23 15:40:24 +00:00
|
|
|
|
2018-01-24 21:38:06 +00:00
|
|
|
tlv_parse(&tp, &gsm48_att_tlvdef, gh->data, payload_len, 0, 0);
|
|
|
|
|
|
|
|
/* bearer capability */
|
|
|
|
if (TLVP_PRESENT(&tp, GSM48_IE_MOBILE_ID)) {
|
|
|
|
mi_type = TLVP_VAL(&tp, GSM48_IE_MOBILE_ID)[0] & GSM_MI_TYPE_MASK;
|
|
|
|
if (mi_type == GSM_MI_TYPE_IMEISV
|
|
|
|
&& TLVP_LEN(&tp, GSM48_IE_MOBILE_ID) > 0) {
|
2018-03-13 00:22:01 +00:00
|
|
|
gsm48_mi_to_string(ciph_res.imeisv, sizeof(ciph_res.imeisv),
|
2018-01-24 21:38:06 +00:00
|
|
|
TLVP_VAL(&tp, GSM48_IE_MOBILE_ID),
|
|
|
|
TLVP_LEN(&tp, GSM48_IE_MOBILE_ID));
|
|
|
|
}
|
2016-06-19 16:06:02 +00:00
|
|
|
}
|
2012-01-23 15:40:24 +00:00
|
|
|
}
|
|
|
|
|
2018-11-30 03:35:50 +00:00
|
|
|
conn->geran_encr.alg_id = alg_id;
|
2018-11-29 22:37:19 +00:00
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
ciph_res.cause = VLR_CIPH_COMPL;
|
|
|
|
vlr_subscr_rx_ciph_res(conn->vsub, &ciph_res);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Receive a CLEAR REQUEST from BSC */
|
2018-11-30 00:08:36 +00:00
|
|
|
int ran_conn_clear_request(struct ran_conn *conn, uint32_t cause)
|
2016-06-19 16:06:02 +00:00
|
|
|
{
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
ran_conn_close(conn, cause);
|
2016-06-19 16:06:02 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2012-01-23 09:28:35 +00:00
|
|
|
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
static const char *used_ref_counts_str(struct ran_conn *conn)
|
2018-04-09 18:44:56 +00:00
|
|
|
{
|
|
|
|
static char buf[256];
|
|
|
|
int bit_nr;
|
|
|
|
char *pos = buf;
|
|
|
|
*pos = '\0';
|
|
|
|
|
|
|
|
if (conn->use_tokens < 0)
|
|
|
|
return "invalid";
|
|
|
|
|
|
|
|
#define APPEND_STR(fmt, args...) do { \
|
|
|
|
int remain = sizeof(buf) - (pos - buf) - 1; \
|
|
|
|
int l = -1; \
|
|
|
|
if (remain > 0) \
|
|
|
|
l = snprintf(pos, remain, "%s" fmt, (pos == buf? "" : ","), ##args); \
|
|
|
|
if (l < 0 || l > remain) { \
|
|
|
|
buf[sizeof(buf) - 1] = '\0'; \
|
|
|
|
return buf; \
|
|
|
|
} \
|
|
|
|
pos += l; \
|
|
|
|
} while(0)
|
|
|
|
|
|
|
|
for (bit_nr = 0; (1 << bit_nr) <= conn->use_tokens; bit_nr++) {
|
|
|
|
if (conn->use_tokens & (1 << bit_nr)) {
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
APPEND_STR("%s", get_value_string(ran_conn_use_names, bit_nr));
|
2018-04-09 18:44:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return buf;
|
|
|
|
#undef APPEND_STR
|
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
/* increment the ref-count. Needs to be called by every user */
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
struct ran_conn *_ran_conn_get(struct ran_conn *conn, enum ran_conn_use balance_token,
|
|
|
|
const char *file, int line)
|
2016-06-19 16:06:02 +00:00
|
|
|
{
|
|
|
|
OSMO_ASSERT(conn);
|
2013-06-30 13:30:47 +00:00
|
|
|
|
2018-11-30 00:08:36 +00:00
|
|
|
if (balance_token != RAN_CONN_USE_UNTRACKED) {
|
2017-11-22 13:33:12 +00:00
|
|
|
uint32_t flag = 1 << balance_token;
|
|
|
|
OSMO_ASSERT(balance_token < 32);
|
|
|
|
if (conn->use_tokens & flag)
|
|
|
|
LOGPSRC(DREF, LOGL_ERROR, file, line,
|
|
|
|
"%s: MSC conn use error: using an already used token: %s\n",
|
|
|
|
vlr_subscr_name(conn->vsub),
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
ran_conn_use_name(balance_token));
|
2017-11-22 13:33:12 +00:00
|
|
|
conn->use_tokens |= flag;
|
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
conn->use_count++;
|
|
|
|
LOGPSRC(DREF, LOGL_DEBUG, file, line,
|
2018-04-09 18:44:56 +00:00
|
|
|
"%s: MSC conn use + %s == %u (0x%x: %s)\n",
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
vlr_subscr_name(conn->vsub), ran_conn_use_name(balance_token),
|
2018-04-09 18:44:56 +00:00
|
|
|
conn->use_count, conn->use_tokens, used_ref_counts_str(conn));
|
2016-06-19 16:06:02 +00:00
|
|
|
|
|
|
|
return conn;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* decrement the ref-count. Once it reaches zero, we release */
|
2018-11-30 00:08:36 +00:00
|
|
|
void _ran_conn_put(struct ran_conn *conn, enum ran_conn_use balance_token,
|
|
|
|
const char *file, int line)
|
2016-06-19 16:06:02 +00:00
|
|
|
{
|
|
|
|
OSMO_ASSERT(conn);
|
|
|
|
|
2018-11-30 00:08:36 +00:00
|
|
|
if (balance_token != RAN_CONN_USE_UNTRACKED) {
|
2017-11-22 13:33:12 +00:00
|
|
|
uint32_t flag = 1 << balance_token;
|
|
|
|
OSMO_ASSERT(balance_token < 32);
|
|
|
|
if (!(conn->use_tokens & flag))
|
|
|
|
LOGPSRC(DREF, LOGL_ERROR, file, line,
|
|
|
|
"%s: MSC conn use error: freeing an unused token: %s\n",
|
|
|
|
vlr_subscr_name(conn->vsub),
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
ran_conn_use_name(balance_token));
|
2017-11-22 13:33:12 +00:00
|
|
|
conn->use_tokens &= ~flag;
|
|
|
|
}
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
if (conn->use_count == 0) {
|
|
|
|
LOGPSRC(DREF, LOGL_ERROR, file, line,
|
2017-11-22 13:33:12 +00:00
|
|
|
"%s: MSC conn use - %s failed: is already 0\n",
|
|
|
|
vlr_subscr_name(conn->vsub),
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
ran_conn_use_name(balance_token));
|
2016-06-19 16:06:02 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
conn->use_count--;
|
|
|
|
LOGPSRC(DREF, LOGL_DEBUG, file, line,
|
2018-04-09 18:44:56 +00:00
|
|
|
"%s: MSC conn use - %s == %u (0x%x: %s)\n",
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
vlr_subscr_name(conn->vsub), ran_conn_use_name(balance_token),
|
2018-04-09 18:44:56 +00:00
|
|
|
conn->use_count, conn->use_tokens, used_ref_counts_str(conn));
|
2016-06-19 16:06:02 +00:00
|
|
|
|
2016-05-20 19:59:55 +00:00
|
|
|
if (conn->use_count == 0)
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
osmo_fsm_inst_dispatch(conn->fi, RAN_CONN_E_UNUSED, NULL);
|
2016-05-20 19:59:55 +00:00
|
|
|
}
|
|
|
|
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
bool ran_conn_used_by(struct ran_conn *conn, enum ran_conn_use token)
|
2018-04-01 18:55:54 +00:00
|
|
|
{
|
|
|
|
return conn && (conn->use_tokens & (1 << token));
|
|
|
|
}
|
|
|
|
|
rename gsm_subscriber_connection to ran_conn
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
2018-11-29 21:37:51 +00:00
|
|
|
const struct value_string ran_conn_use_names[] = {
|
2018-11-30 00:08:36 +00:00
|
|
|
{RAN_CONN_USE_UNTRACKED, "UNTRACKED"},
|
|
|
|
{RAN_CONN_USE_COMPL_L3, "compl_l3"},
|
|
|
|
{RAN_CONN_USE_DTAP, "dtap"},
|
|
|
|
{RAN_CONN_USE_AUTH_CIPH, "auth+ciph"},
|
|
|
|
{RAN_CONN_USE_CM_SERVICE, "cm_service"},
|
|
|
|
{RAN_CONN_USE_TRANS_CC, "trans_cc"},
|
|
|
|
{RAN_CONN_USE_TRANS_SMS, "trans_sms"},
|
|
|
|
{RAN_CONN_USE_TRANS_NC_SS, "trans_nc_ss"},
|
|
|
|
{RAN_CONN_USE_SILENT_CALL, "silent_call"},
|
|
|
|
{RAN_CONN_USE_RELEASE, "release"},
|
2017-11-22 13:33:12 +00:00
|
|
|
{0, NULL},
|
|
|
|
};
|
|
|
|
|
2016-05-20 19:59:55 +00:00
|
|
|
void msc_stop_paging(struct vlr_subscr *vsub)
|
|
|
|
{
|
|
|
|
DEBUGP(DPAG, "Paging can stop for %s\n", vlr_subscr_name(vsub));
|
|
|
|
/* tell BSCs and RNCs to stop paging? How? */
|
2010-06-28 09:09:29 +00:00
|
|
|
}
|