SMS

SMS message flow diagram

Mobile-Originated (MO)

Step	What Happens
1	Mobile sends Data Burst Message on traffic channel (or access for short messages)
2	BTS carries the access or traffic frame to BSC over Abis
3	BSC encapsulates the data burst in an A1 ADDS message and forwards to MSC
4	MSC parses the SMS payload and submits it to SMSC
5	SMSC stores in PostgreSQL with delivery state tracking
6	If destination mobile is registered, delivery starts immediately

Mobile-Terminated (MT)

Step	What Happens
1	Operator/API submission or MSC welcome-SMS policy queues a message in SMSC
2	SMSC hands the pending delivery to MSC
3	MSC sends an A1 ADDS message to BSC carrying the SMS payload
4	BSC pages the mobile through BTS over Abis if idle, or sends a Data Burst over the existing traffic channel
5	SMSC updates delivery status on acknowledgment

A message delivered while the handset is idle and one delivered on an active call are acknowledged differently, and the MSC tracks both, so retries and late acknowledgments do not produce duplicates.

MS-to-MS SMS forwards automatically. When the destination number belongs to a provisioned subscriber, the MSC queues a mobile-terminated delivery to it. Offline recipients get the message on their next registration. Messages that were mid-delivery when the MSC restarted are retried after startup.

Teleservices

The same SMS pipeline carries multiple C.S0015-B teleservices:

ID	Name	Used for
`0x1002`	WMT (default)	Plain text point-to-point SMS
`0x1004`	WAP / CATPT	WAP Push — MMS M-Notification.ind, OMA Client Provisioning

MscManagementService.SendSms accepts an optional teleservice_id and opaque raw_user_data bytes; when set, the BSC emits the SMS with MSG_ENCODING=0x00 (octet) and the payload bytes verbatim. The MMS notification pipeline uses this to deliver the WAP Push PDU on F-PCH or F-TCH framed per WAP-259 §6.5. See the MMS guide for the full flow.

SMSC Database

Table	Contents
Messages	SMS content, sender, recipient, timestamps
Delivery state	Pending, delivered, failed, expired
Mobiles seen	ESN/IMSI sightings and last-seen timestamps used for welcome SMS decisions

Schema created automatically on first start. Atomic state transitions via PostgreSQL transactions.

Welcome SMS

The configurable welcome SMS policy sends a message to mobiles that are new to the network or have been inactive longer than the configured threshold. Registration handling records each mobile in the HLR mobiles_seen ledger, resolves subscriber state, and injects the welcome message through the normal SMSC delivery path.

In config/msc.local.json:

{
  "welcome_sms": {
    "enabled": true,
    "text": "Welcome to 1xBTS!",
    "originating_number": "0000",
    "inactive_days_threshold": 30
  }
}

Sending via API

# MSC management endpoint owns SMS submission:
grpcurl -plaintext -d '{
  "destination_mdn": "5551234567",
  "message": "Hello from 1xBTS!"
}' localhost:17017 msc_management.v1.MscManagementService/SendSms

bsc.v1.BscService/SendSms on :17016 remains as a compatibility entry point for existing tooling; it forwards to MSC under the hood.