4. SRI-FOR-SM
1.23 Interfaces between SMS network elements
1.23.1 A interface in SMS
Short Messaging uses only the following signalling channels:
. SDCCH
A Stand Alone Dedicated Control Channel is a two-way signalling channel normally used for call establishment and location updates. When there is no voice call active, SDCCH channels are used for short messages. One traffic channel (TCH) can be combined into 8 SDCCHs.
. SACCH
If a voice call is active, a Slow Associated Control Channel is used for short messaging, which means that messages can be sent and received even during a call. Each SDCCH or traffic channel is accompanied by a two- way SACCH.
When there is no active call, USSD and SMS use the same SDCCH signalling channel. During a call, USSD uses FACCH channel, when SMS uses SACCH. With SACCH the sending of the SM takes about three times longer than with SDCCH. The transfer of USSD with FACCH is 5-7 times faster than SMS with SACCH. USSD and SMS are possible simultaneously, even during a call. For more information on the A interface, see 3GPP TS 24.008 and 24.011.
For more information, see A interface operations in VMSC and VLR (MO) , and
A interface operations in VMSC and VLR (MT) .
1.23.2 SMRSE in SMS
The exchange of messages between the MSC and the SMSC is based on Short Message Relay Service Element (SMRSE) interface defined in Technical report 03.47. The SMRSE needs a reliable transport service to exchange messages. There are two alternatives: X.25 and TCP/IP connection. Both interface options can co-exist in the MSC site. Each SMSC can support either the TCP/IP or X.25 connection.
X.25 connection
OSI application with X.25 connection: if the SMSC operator and the PLMN operator are the same, the X.25 connection is considered to be a safer way. In this method the user must create a definition in the SMS-IWMSC to link the SMSC- ISDN address to an OSI application. The following figure describes the OSI protocol stack:
Figure 46. OSI protocol stack
In the technical report of the SMRSE, the number of simultaneous MS transfers (message reference) is limited to 255. This means that a maximum of 256 of messages from one SMSC can be made at the same time in the network. In case of high capacity links, this limitation can result in a bottleneck, and therefore more space is reserved (1000).
ISO IP, ES-IS, IS-IS CONS CLNS Presentation layer ROSE FTAM VT CMISE Session layer
Transport layer Transportlayer 4 Transport
layer 0 PAD
Non OSI applications OSI applications
SMRSE 802.3 subnetwork X.25 network MSW CONS network service user Transport service user X.25 packet level X.25 data link level
physical level CSMA/CD
LLC SNDCF
If feature 619 is in use in your exchange, you can control the maximum value of message references towards SMSC (MO-SMS).
TCP/IP connection
The full seven layered OSI stack of the X.25 connection is quite heavy for transferring relatively simple data, such as SMs, and therefore it unnecessarily loads the physical line transfer capacity and the processing capacity of the computer unit that controls the line. Therefore, if Feature 931: Short Message Service Transfer over TCP/IP is in use in your network, it can increase the performance of the transmission between the MSC and the Nokia SMSC conveying SM traffic.
The purpose of TCP/IP is to provide a fast and efficient way of transferring SMs between MSCs and SMSCs. It implements the functionality defined for SMRSE. There are also some Nokia-specific features, for example, additional parameters, which have to be implemented. Altogether this feature provides all the tasks and features of the previous solution, but in a more efficient way. TCP/IP reduces the amount of protocol layers and therefore the time needed for processing a message.
The interface improves the SM transfer capacity considerably. Because of the high capacity, the number of messages that can be handled simultaneously increases significantly. Consequently, there must be a way to restrict the traffic. The amount of the messages can be tuned up to the optimal for the system configuration used. This prevents the SM transfer system from producing too high a load in the rest of the system.
Figure 47. Protocol stack for SMS with TCP/IP
Both IPv4 and IPv6 are supported.
For a more detailed information refer to the feature descriptions of Feature 931: Short Message Service Transfer over TCP/IP .
For related information, see Comparison of SMS functionalities in case of
SMRSE over X.25 or TCP/IP and SS7 MAP SMSC .
1.23.3 MAP in SMS
MAP is an interface that follows the GSM specification. See the figure below: SS7 Ethernet SMS-IWMSC/GMSC TCP/IP stack Link Layer - 802.3 IP TCP SMRSE SMS Appl. MTP SCCP TCAP MAP SMSC SMRSE TCP/IP Protocol Stack
Figure 48. OSI compared to ITU-T No. 7
MAP covers the following interfaces in the GSM network:
. C interface between MSC and HLR . D interface between VLR and HLR . E interface between MSC and MSC . F interface between MSC and EIR . G interface between VLR and VLR
B interface between MSC and VLR is not described in these descriptions of Short Message Services.
In the GPRS network the following MAP interfaces exist:
. MAP-Gd: between MSC and SGSN . MAP-Gr: between SGSN and HLR
MTP SCCP BSSAP TUP/ ISUP OSI ITU-T Nr. 7 level 1 level 3 level 2 level 4 layer 1 layer 2 layer 3 layer 4 layer 5 layer 6 layer 7 TCAP MAP
MAP provides the following SMS procedures for its users:
. MOForwardSM: between VMSC and SMS-IWMSC or between VMSC and SMSC
. MTForwardSM: between SMS-GMSC and VMSC or between SMSC and VMSC
. SendRoutingInfoForSM: between SMS-GMSC and HLR or between SMSC and HLR
. ReportSM-DeliveryStatus: between SMS-GMSC and HLR or between SMSC and HLR
. InformServiceCentre: between HLR and SMS-GMSC or between HLR and SMSC
. ReadyForSM: between VLR and HLR
. AlertServiceCentre: between HLR and SMS-GMSC or between HLR and SMSC
. SendIMSI: between SMS-IWMSC and HLR or between SMSC and HLR One MAP procedure can be executed during one TCAP dialogue. See SMS
procedures performed by MAP for detailed explanations of the procedures.
The alternative to OSI for implementing SMSC and SMS-GMSC or SMS- IWMSC connection is the MAP interface with CCS7 link. In this case the SMSC is integrated to the CCS7 network, and the functionalities of SMS-GMSC and SMS-IWMSC are combined to the SMSC. Routing definitions are easier than with the X.25 connection. Every MSC and HLR can send SMs directly to the SMSC, as well as receive them directly from there.
MAP version 3 is supported if you have Feature 1043: Short Message Services GSM Phase 2+ in the network. This MAP version includes the parameters necessary for SMS over GPRS . For more information refer to feature descriptions of Feature 1043: Short Message Services GSM Phase 2+ and Feature 857: Support of General Packet Radio Service (GPRS) .
MAP-Gd
MAP-Gd is the interface between the MSC and the Serving GPRS Support Node (SGSN). The SMS-related MAP version 3 makes the usage of Feature 857: Support of General Packet Radio Service (GPRS ) possible. The following figure shows the SMS architecture with SGSN.
Figure 49. MAP-Gd interface in the SMS GSM Phase 2+ network architecture
For related information, see SMS procedures performed by MAP , Short Message
Service on GPRS , and Comparison of the SMS functionalities in case of SMRSE over X.25 or TCP/IP and SS7 MAP SMSC .
1.24
Subscriber interface of SMS
SMS status report
The subscribers receive a notification when there are one or more SMs delivered to them, and when they send a message, a notification that a message has been sent. However, the latter notification only means that the SM was successfully sent to the SMSC, nothing about a future delivery. Whether the SM delivery was successful or not is indicated in a status report . A status report informs the subscriber of the status of the MO-SM that was sent. Its status can be either successful, that is, the SM was delivered successfully to the MS, or unsuccessful. Usually the SMSC address is stored in the MS, but the subscribers can also set it themselves when they are using other than the usual kind of SMs, such as fax, for example.
For background information, see Command SM and MO-SM with Status Report
request . SMSC HLR MSC MAP-C MAP-E A-IF SMRSE Short message service centre SGSN MAP-Gd SMS-GMSC BSS Gb
Prevention of SMS
If the subscribers want to bar incoming or outgoing SMs or both, they, in general, must bar all incoming or outgoing calls, or both. They can bar all incoming/ outgoing SMs if the menu of their MS supports it. Likewise, if they bar all incoming and/or outgoing calls, this automatically means that SMs are also barred.
For background information, see Barring SMS in the MSC . User Data in MT/MO-SMS acknowledgement message
Since the UserData in the acknowledgement messages is available, SIM data download becomes possible. This can be useful in cases when, for example, the user has a prepaid SIM card because the data download is possible by the SMS. Alphanumeric addressing of SMS-related applications
The subscriber has the benefit of easy addressing of SMS-related applications as this feature supports alphanumeric addresses for the destinations of short messages.
The alphabetical address is carried in the MO-SM. The characters are represented by a hexadecimal number in an 7bit octet. For example, the character 'J' is represented as 0x4A (01001010 in binary format). The upper 4 bits (from the most significant bit (MSB)) contains the first digit of the hexadecimal number and the below 4 bits (from the least significant bit (LSB)) contains the second digit thereof.
Our example (the letter 'J') can be, thus, represented as below:
Figure 50. An example for hexadecimal numbers used in alphanumeric addressing
Accordingly, if the subscriber sends a short message to the address 'JOKEBOX', the address in hexadecimal format is 4A 4F 4B 45 42 4F 58 (see below).
MSB LSB
1 0 0 1 0 1 0 "4" "A"
Figure 51. An example for alphanumeric addressing from the MS 4A 4F 4B 45 42 4F 58
- - - - - - - -