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?
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
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.
Messages with destination ISDN addresses to not corresponding to known IMSIs in the HLR are set aside for special handling.
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.
We need handling for non-numeric SIP destinations. Another candidate for a short code function.
GSM 03.40 Section 3.8 describes internetworking between SMS and internet
electronic mail at the transport layer.
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:
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（原文出处，翻译整理仅供参考!）