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

MT delivery acknowledgments are keyed by the path used for delivery: idle-page delivery tracks the F-PCH correlation ID, while traffic-channel delivery tracks the Layer 2 MSG_SEQ. This lets retries and late acknowledgments resolve consistently across paging and traffic paths.

MS-to-MS SMS forwards automatically. After an MO submission is recorded, the MSC re-resolves the destination phone number through HLR; if a subscriber matches, an MT delivery is queued through the same pipeline. Offline recipients are handled by the retry sweep so the MT delivery completes on the next registration. The MSC also recovers submissions left in Paging across a restart by resetting them to Accepted at 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

msc.json owns the configurable welcome SMS policy for 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.

{
  "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.