2008-12-28 00:31:09 +00:00
|
|
|
#ifndef _GSM_04_11_H
|
|
|
|
#define _GSM_04_11_H
|
|
|
|
|
2011-03-22 15:47:59 +00:00
|
|
|
#include <osmocom/gsm/protocol/gsm_04_11.h>
|
2018-11-06 22:08:18 +00:00
|
|
|
#include <osmocom/msc/gsm_04_11_gsup.h>
|
2009-03-30 20:56:32 +00:00
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
struct vlr_subscr;
|
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;
|
2016-06-19 16:06:02 +00:00
|
|
|
struct gsm_trans;
|
|
|
|
|
2010-06-15 04:03:10 +00:00
|
|
|
#define UM_SAPI_SMS 3 /* See GSM 04.05/04.06 */
|
|
|
|
|
2008-12-29 04:20:41 +00:00
|
|
|
/* SMS deliver PDU */
|
|
|
|
struct sms_deliver {
|
2011-04-18 15:04:00 +00:00
|
|
|
uint8_t mti:2; /* message type indicator */
|
|
|
|
uint8_t mms:1; /* more messages to send */
|
|
|
|
uint8_t rp:1; /* reply path */
|
|
|
|
uint8_t udhi:1; /* user data header indicator */
|
|
|
|
uint8_t sri:1; /* status report indication */
|
|
|
|
uint8_t *orig_addr; /* originating address */
|
|
|
|
uint8_t pid; /* protocol identifier */
|
|
|
|
uint8_t dcs; /* data coding scheme */
|
2009-07-05 12:02:46 +00:00
|
|
|
/* service centre time stamp */
|
2011-04-18 15:04:00 +00:00
|
|
|
uint8_t ud_len; /* user data length */
|
|
|
|
uint8_t *user_data; /* user data */
|
2009-07-05 12:02:46 +00:00
|
|
|
|
2011-04-18 15:04:00 +00:00
|
|
|
uint8_t msg_ref; /* message reference */
|
|
|
|
uint8_t *smsc;
|
2008-12-29 04:20:41 +00:00
|
|
|
};
|
|
|
|
|
2018-11-22 08:42:39 +00:00
|
|
|
struct gsm_network;
|
2008-12-28 00:31:09 +00:00
|
|
|
struct msgb;
|
|
|
|
|
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
|
|
|
int gsm0411_rcv_sms(struct ran_conn *conn, struct msgb *msg);
|
2008-12-28 00:31:09 +00:00
|
|
|
|
2009-08-10 05:54:02 +00:00
|
|
|
struct gsm_sms *sms_alloc(void);
|
|
|
|
void sms_free(struct gsm_sms *sms);
|
2016-06-19 16:06:02 +00:00
|
|
|
struct gsm_sms *sms_from_text(struct vlr_subscr *receiver,
|
2018-04-09 17:19:33 +00:00
|
|
|
const char *sender_msisdn,
|
2016-06-19 16:06:02 +00:00
|
|
|
int dcs, const char *text);
|
2008-12-29 04:20:41 +00:00
|
|
|
|
2018-11-22 08:42:39 +00:00
|
|
|
int gsm411_send_sms(struct gsm_network *net,
|
|
|
|
struct vlr_subscr *vsub,
|
2010-12-24 12:48:27 +00:00
|
|
|
struct gsm_sms *sms);
|
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
|
|
|
void gsm411_sapi_n_reject(struct ran_conn *conn);
|
2014-02-08 14:20:48 +00:00
|
|
|
|
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP
Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until
we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we
can route this sms somewhere we can reach indeed.
After this change, the conversation looks like this:
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-SUBMIT | |
|------------------->| |
| | DELIVER-SM |
| |---------------->|
| | |
| | DELIVER-SM-RESP |
| |<----------------|
| GSM 04.11 RP-ACK | |
|<-------------------| |
| | |
Before this patch, the RP-ACK was sent back straight forward to the MS,
no matter if the sms can be route by the ESME or not. Thus, the user
ends up getting a misleading "message delivered" in their phone screen,
when the message may just be unroutable by the ESME hence silently
dropped.
If we get no reply from the ESME, there is a hardcoded timer that will
expire to send back an RP-ERROR to the MS indicating that network is
out-of-order. Currently this timer is arbitrarily set to 5 seconds. I
found no specific good default value on the SMPP 3.4 specs, section 7.2,
where the response_timer is described. There must be a place that
describes a better default value for this. We could also expose this
timer through VTY for configurability reasons, to be done later.
Given all this needs to happen asyncronously, ie. block the SMSC, this
patch extends the gsm_sms structure with two new fields to annotate
useful information to send the RP-ACK/RP-ERROR back to the MS of origin.
These new fields are:
* the GSM 04.07 transaction id, to look up for the gsm_trans object.
* the GSM 04.11 message reference so the MS of origin can correlate this
response to its original request.
Tested here using python-libsmpp script that replies with
DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see
here on my motorola C155 that message cannot be delivered. I have tested
with the success status code in the SMPP DELIVER_SM_RESP too.
Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
|
|
|
int gsm411_send_rp_ack(struct gsm_trans *trans, uint8_t msg_ref);
|
|
|
|
int gsm411_send_rp_error(struct gsm_trans *trans, uint8_t msg_ref,
|
|
|
|
uint8_t cause);
|
|
|
|
|
2008-12-28 00:31:09 +00:00
|
|
|
#endif
|