SMS Handling in OpenBTS

The OpenBTS application implements SMS delivery over the air interface. It does not, on its own, provide any mechanism for store and forward handling of text messages. This document describes the proper SMS interface for OpenBTS and the "smqueue" application that will provides the store and forward function. Smqueue is not intended to be a complete SMSC, but does serve the purpose of an SMSC in OpenBTS networks.

SMS Interface to OpenBTS

The SMS interface to the OpenBTS application is SIP/SIMPLE page-mode messaging, as described in RFC-3428. This interface forms a functional mapping between SIP/SIMPLE and SMS layer 4, the relay layer (RL), described in GSM 04.11. The layer 5 PDU, the transport PDU (TPDU), should handled opaquely, although in the first iteration of the system the message payload is handled as an ASCII string. (The SMS TPDU, is described in GSM 03.40 Section 9.2.) Where are the layers?
1. In the Transceiver and GSM/GSML1FEC.cpp
1. In GSM/GSML2LAPDm.cpp
1. In Control/SMSControl.cpp
1. This is the SIP layer.
1. This is the TPDU layer.

SMS Delivery to the MS

To deliver a text message to the MS through OpenBTS, smqueue sends to OpenBTS a SIP MESSAGE request addressed to the destination user's IMSI and containing the message string. OpenBTS will attempt to deliver the message as the payload of an RP-DATA message, as described in GSM 04.11 Section 6. If delivery is successful, as determined by the receipt of an RP-ACK message from the MS, OpenBTS will respond with 200 OK. If delivery fails with an RP-ERROR message from the handset, OpenBTSOpenBTS will not produce any response at all. will respond with a corresponding SIP error response. However, the most common delivery failure will be when the handset does not respond to paging, in which case

SMS Submission from the MS

When an MS sends a text message though OpenBTS, it will do so by sending the message string as the payload in an RP-DATA message, as per GSM 04.11. OpenBTS will decode the SIP headers to determine the destination address of the message. OpenBTS will then submit a SIP MESSAGE request to smqueue, addressed to the E.164 address of the destination user and containing the message string. Smqueue responds with 202 Accepted, which OpenBTS then relays to the MS as an RP-ACK message.

Operation Inside smqueue

Needs to be completed.

Implementing Additional Features and Interfaces

Messages with destination ISDN addresses to not corresponding to known IMSIs in the HLR are set aside for special handling.

Delivery Reports

A full SMS implementation would include delivery reports to the original sender of a message reporting the final success or failure of a message. Such reports would be generated whenever a subscribed-originated message is deleted from the messages table.

SIP-Based Messaging Relays

We need handling for non-numeric SIP destinations. Another candidate for a short code function.

E-Mail Relays

GSM 03.40 Section 3.8 describes internetworking between SMS and internet electronic mail at the transport layer.
Smqueue should support this feature.

Short Codes

A short code is a destination ISDN address inside the SMSC that corresponds to a special function that acts on the message content. A well-known example of a short code is the 40404 address through which North American cellular subscribers can submit messages to Twitter.

The smqueue application can implement short code functions by registering those functions in a map (associative array) indexed by short code. Each short code function takes two arguments, the message string and the IMSI of the sender.

As of release 2.5, smqueue implements the following short code applications in smcommands.cpp:

  • shortcode_four_one_one: Return queue status assigned number and the IMSI of the requesting handset.
  • shortcode_zap_queued: Remove a message from the queue, by its tag.
  • shortcode_register: Register the user's phone with the HLR (autoprovisioning).
  • whiplash_quit: Seekrit SMS message to make the server quit for valgrind leak checking.
  • shortcode_debug_dump
  • shortcode_quick_chk

Interfacing to Standard SMSCs

Messages addressed to normal E.164 addresses not in the HLR should be sent to an outside SMSC for delivery through standard GSM mechanisms. Smqueue will also (eventually) need to interface to standard SMSCs to accept incoming SMS from standard GSM sources. Both types of interfacing should be possible with Kannel.

Useful documents:





注：SMS Handling in OpenBTS（原文出处，翻译整理仅供参考!）