EMI UCP Interface Specification v4.6
EMI UCP Interface Specification v4.6
EMI UCP Interface Specification v4.6
6
EMI - UCP Interface
Specification
All rights reserved. This document may not be copied in whole or in part without the prior written consent of CMG Wireless
Data Solutions (“LogicaCMG”).
The information in this document is provided on an “as is” basis and is subject to change without further notice and cannot be
construed as a commitment by LogicaCMG. Although every precaution has been taken in the preparation of this document
LogicaCMG assumes no responsibility or liability for any errors or omissions whatsoever, that may appear in this document.
Neither is any liability assumed for damages resulting from the use of the information contained herein.
The products mentioned in this document are identified by the names, trademarks, service marks and logos of their respective
companies or organisations and may not be used in any advertising or publicity or in any other way whatsoever without the
prior written consent of those companies or organisations.
Table of Contents
1 Introduction......................................................................................................... 1
1.1 Position of interface ............................................................................................................... 1
1.2 Interface history ..................................................................................................................... 3
Abbreviations .......................................................................................................... 87
References............................................................................................................... 89
Index......................................................................................................................... 91
Table 5-20: Parameter Positive Result Data Field Submit Short Message Operation .......................... 29
Table 5-21: Short Message Parameter Field Submit Short Message Operation .................................. 29
Table 5-24: Parameter Positive Result Data Field Delivery Short Message Operation ........................ 32
Table 5-25: Parameter Negative Result Data Field Delivery Short Message Operation....................... 32
Table 5-27: Parameter Positive Result Data Field Delivery Notification Operation............................... 34
Table 5-28: Parameter Negative Result Data Field Delivery Notification Operation ............................. 35
Table 5-30: Parameter Positive Result Data Field Modify Short Message Operation........................... 38
Table 5-31: Short Message Parameter Field Modify Short Message Operation ................................... 39
Table 5-32: Parameter Negative Result Data Field Modify Short Message Operation ......................... 39
Table 5-34: Parameter Positive Result Data Field Inquiry Message Operation .................................... 41
Table 5-35: Parameter Negative Result Data Field Inquiry Message Operation................................... 41
Table 5-37: Parameter Positive Result Data Field Response Inquiry Message Operation ................... 43
Table 5-38: Parameter Negative Result Data Field Response Inquiry Operation ................................. 44
Table 5-40: Parameter Positive Result Data Field Delete Message Operation..................................... 45
Table 5-41: Parameter Negative Result Data Field Delete Message Operation ................................... 46
Table 5-46: Parameter Positive Result Data Field Response Delete Message Operation ................... 48
Table 5-47: Parameter Negative Result Data Field Response Inquiry Operation ................................. 48
Table 6-6: Parameter Positive Result Data Field Session Management Operation.............................. 52
Table 6-7: Parameter Negative Result Data Field Session Management Operation ............................ 52
Table 6-9: Parameter Positive Result Data Field Provisioning Actions Operation ................................ 53
Table 6-10: Parameter Negative Result Data Field Provisioning Actions Operation............................. 54
Table 7-2: Parameter Positive Result Data Field SMT Alert Operation................................................. 56
Table 7-3: Parameter Negative Result Data Field SMT Alert Operation ............................................... 57
Table 8-2: Parameter Positive Result Data Field Call Input Operation ................................................. 59
Table 8-4: Parameter Negative Result Data Field Call Input Operation ................................................ 59
Table 8-5: Parameters Operation Data Field Multiple Address Call Input Operation ............................ 60
Table 8-6: Parameter Positive Result Data Field Multiple Address Call Input Operation...................... 61
Table 8-7: Short Message Parameter Field Multiple Address Call Input Operation .............................. 61
Table 8-8: Parameter Negative Result Data Field Multiple Address Call Input Operation .................... 62
Table 8-9: Parameter Operation Data Field Call Input with Services Operation ................................... 62
Table 8-10: Parameter Positive Result Data Field Call Input with Services Operation ......................... 64
Table 8-11: Short Message Parameter Field Call Input with Services Operation ................................. 64
Table 8-12: Parameter Negative Result Data Field Call Input with Services Operation ....................... 64
Table 8-13: Parameter Operation Data Field MS Message Transfer Operation ................................... 65
Table 8-14: Parameter Positive Result Data Field MS Message Transfer Operation ........................... 67
Table 8-16: Parameter Negative Result Data Field MS Message Transfer Operation.......................... 67
Purpose
This manual specifies the interface used between the SMSC System and other computer
systems and applications. The interface is based on the ERMES UCP (Universal Computer
Protocol) with SMSC-specific extensions.
Throughout this document the interface is called 'EMI': External Machine Interface.
The interface that is described in this document has been implemented in an SMSC API
built by CMG. Hereby, application programmers are able to build applications for
communication with a Short Message Service Centre (SMSC) of CMG in order to send and
receive short messages to/from mobile stations.
Audience
All persons involved in the design and implementation of applications on external computer
systems that have to interact with the SMSC.
Organisation
This document is structured as follows:
• Chapter 1 contains the introduction to the EMI. It describes the position of the EMI
between the SMSC components and the external machines.
• Chapter 2 shows the structure of EMI messages and provides examples of valid
exchanges of operations between the SMSC and the applications.
• Chapter 3 defines the EMI operations, and describes briefly the actions that are expected
from the SMSC and the Application upon reception of the operations
• Chapter 4 shows the syntax of EMI operations.
• Chapter 5 shows the syntax of the 50-series of EMI operations.
• Chapter 6 shows the syntax of the 60-series of EMI operations.
• Chapter 7 shows the syntax of legacy EMI operations.
• Chapter 8 summarises the error codes for the EMI operations.
• Chapter 9 lists the error messages and reason codes for Notifications
• Chapter 10 lists the 2 GSM 7-bit alphabet tables
• Chapter 11 lists the GSM 7-bit alphabet and Unicode character mappings
• Chapter 12 provides a typical protocol sequence example
The External Machine Interface specification specifies the features that can be used in the
EMI operations. However, many features are subject to provisioning by the SMSC operator,
i.e. did the operator grant you the rights to use these features in the EMI operations.
<courier> Serves as a placeholder for variable Use the file name <entity>.cfg for...
text that the user will replace as
appropriate to its context.
- Bridges two keystrokes that should be If Ctrl-C does not work, use Ctrl-
pressed simultaneously. Alt-Del.
This document contains the general specification of the external machine interface of CMG's
SMSC. Since the available functions depend on the specific SMSC implementation of the
Mobile Telecommunication Operator, please contact your local operator for the available
implemented SMSC functions and features.
xiv EMI - UCP Interface Specification — © 2003 CMG Wireless Data Solutions
1 Introduction
For submission and reception of Short Messages the Short Message Service Centre can
interface with (among others):
• GSM/GPRS/UMTS/TDMA/CDMA Mobile Telephones (PLMN),
• Value Added Services applications,
• Voice Messaging systems,
• Unified Communications systems.
Throughout this document the External Machine will be referred to as 'SMT'. This can of
course be any application system.
In order to allow any service provider to develop dedicated applications an interface was
developed to access SMSC functions. This manual specifies that interface.
When viewed from the SMT side, the EMI provides access to the SMSC functions:
• Submission of Short Messages
• Reception of Short Messages
• Reception of Notifications related to submitted Short Messages
• Operate on submitted Short Messages: query, delete and modify.
The SMSC can be viewed as a black box: Short Messages are directed to the GSM mobile
telephone of the recipient. The SMSC and the PLMN only function as relay mechanisms for
those Messages. The only visible action of the SMSC apart from this is the provision of
Notifications: upon request the SMSC will notify the originator of the SM regarding the status
of the SM.
The set-up of the connection between the SMSC platform and the SMT depends on the
carrier used. Once the connection is established, the EMI operations can be used. An SMT
may establish multiple connections for failover purposes or increased throughput. The
SMSC operator may apply restrictions to the number of connections. The SMSC operator
may require the SMT to authorize itself by starting with a session management operation
with identification and password. An SMT may submit multiple messages without waiting for
response on each message (windowing). The SMSC operator applies restrictions to the
allowed window size.
Each side can send operations asynchronous, e.g. independent of each other. For example,
the SMSC can deliver a mobile originated message between receiving an operation from the
SMT and sending the result operation to that response.
An SMSC operator may apply an inactivity timeout on the message transfer. The SMSC
releases the connection after the timeout.
SMT SMSC
Network Connection
OT_60_open_session
OT_60_result
OT_51_submit_short_message
OT_51_submit_short_message_result
OT51_submit_short_message
OT_51_sumbit_short_message_result
OT_56_delete_message
OT_56_delete_message_result
OT_58_delete_message_response
OT_58_delete_message_response_result
OT_53_notification
OT_53_notification_result
In the example, the SMT logs into the SMSC using the operation type 60, subtype Open
Session for authentication.
In the SMSC the UCP protocol was chosen as the basis for the EMI because:
1. The first operators that used the SMSC required using the UCP protocol to interact with
external machines.
2. It allows service providers to use a single mechanism to interface to both ERMES based
paging systems and the SMSC.
3. No re-invention of 'yet another' protocol had to take place.
All new applications should only use the SMT alert operation, UCP5x and UCP6x
operations. All other UCP operations are only referenced for existing applications and
compatibility with previous SMSC releases.
o stx = 02(hex)
o etx = 03(hex)
Note that in the examples “stx”, “etx” and “/” each represent only one character.
As separator between header and data, between data and checksum, as well as between
parameters, a “/” (2F(hex)) is used.
In parameters that contain a list, the items are separated by a “,” (2C(hex)). Numeric
characters (0..F) are encoded as in IRA. Alphanumeric characters are encoded as two
numeric IRA characters, the higher 3 bits (0..7) first, the lower 4 bits (0..F) thereafter.
The <header> consists of the following 4 mandatory fields:
Values 00-99
O/R Char “O” or “R” “O” indicates operation, “R” indicates result
The <data> fields depend on the Operation Type. For each Operation Type they are listed
in the next chapters.
The <checksum> is derived by the addition of all bytes of the header, data field separators
and data fields (i.e. all characters after the stx-character, up to and including the last “/”
before the checksum field). The 8 Least Significant Bits (LSB) of the result is then
represented as two printable characters. The character containing 4 Most Significant Bits
(MSB) (of those 8 LSB) shall be transmitted first. For example, if the checksum is 3A(hex)
the representation shall be the characters “3” (33(hex)) and “A” (41(hex)).
The Unicode character set allows for text in languages like Chinese, Thai and Hebrew, but
occupies 2 bytes 16-bits) per character.
The GSM 7-bit alphabet tables are listed in 11 GSM 7-bit alphabet tables.
A character mapping of GSM 7-bit and Unicode 16-bit is listed in 12 GSM 7-bit – Unicode
mapping.
Besides text character sets, EMI support the transfer of 8-bit binary data.
2.2 Examples
Below you will find examples of the operations and responses.
Other examples are given in the description of the specific EMI operations. Note that the stx
and etx in these examples are skipped.
EMI operations can be initiated either from the SMT, or from the SMSC. Each command will
lead to an action on the other side. The other side will respond with a positive or negative
acknowledgement with the same TRN value. Each side maintains its own TRN values.
31 SMT alert operation Alert the SMSC to start delivering buffered messages
immediately. This allows you to retrieve messages submitted
to you without waiting for the scheduled next delivery
attempt.
32 (reserved)
33 (reserved)
38 (reserved)
40 (reserved)
41 (reserved)
61 List management Manage your own mobile originated and mobile terminated
blacklists or whitelists.
The 'SMT alert operation' can be used by the application to alert the SMSC to send
messages and notifications to the application. It can only be used when the application uses
a connection that supports Calling Line Identification, such as X.25.
34 (reserved)
36 (reserved)
42 (reserved)
43 (reserved)
All new applications should only use the SMT alert operation, UCP5x and UCP6x
operations. All other UCP operations are only referenced for existing applications and
compatibility with previous SMSC releases.
The definitions of operations '01', '02' and '03' are identical to the corresponding operations
defined in [ETSI 03.00]
The 'Call input operation' is the normal means of submitting a Short Message. The SMSC
must, when it receives this command, send the message to the recipient address that is
specified in the command.
The 'Multiple address call input operation' is used to address a number of recipients in one
operation. The command contains a list of recipient addresses. The SMSC will send the
same message to all addresses in this list.
The 'Call input with supplementary services operation' is used when a message is to be
scheduled for deferred delivery.
The 'SMS message transfer operation' is used to submit a message when SMSC specific
services are required, such as notification request, deferred delivery, or validity period.
The SMSC uses the 'Call input operation' to transfer Notifications and Mobile Originated
Short Messages to the Short Message Terminal (SMT). The initiative to do so lies either with
the SMSC (Notifications on messages submitted in the current session) or with the SMT (the
SMT has to issue an SMT alert command).
The second type of flow control that can be supported by the SMSC is ‘windowing’ for
increased thoughput. In this case a maximum of n operations can be sent before a response
is received. The transaction number of the command (field TRN) will be used to determine if
a command is in the current ‘window’.
The SMSC will discard a command if its transaction number is outside the current window
(message n+1 in a window of n).The SMSC will give transaction numbers to the operations
it sends as much as possible in a cyclic manner.
If the SMSC receives an invalid response on a command, then the transaction number of
that command can only be used again after the delivery operation has been cancelled due
to a delivery time-out.
Windowing is only supported in combination with UCP5x series operations and the
windowing functionality has to be provisioned by the SMSC operator.
This chapter shows the syntax of the data fields of the EMI operations. For the syntax of the
complete messages, please refer to Chapter 2, Structure of EMI messages. For each
command also the format of the positive and negative responses is given, including the
possible error codes. For convenience, all error codes are summarised in Chapter 9, 9.1,
Error Codes Overview. The order in which the operations are listed is:
1. General operations, used for normal SM transfer.
2. SMSC specific extensions, used to address SMS functions not foreseen in the UCP
definition.
In the column marked 'Presence', “M” indicates that the field is Mandatory, “O” indicates that
it is Optional, “C” indicates Conditional and “-” indicates Not Applicable.
<international-prefix><country-code><trunk-code><telephone-nr>
• In case the national prefix is not used in the network, the following syntax is seen as valid
addresses (in these situations, a valid telephone number will be recognised by its
length):
<international-prefix><country-code><telephone-nr>
<telephone-nr>
For TCP/IP addresses every byte expressed in decimal form should be left zero padded so
that they all have a length of 3 characters. The TCP/IP port number shall be concatenated to
the IP address. All dots (“.”) in the address shall be omitted.
Example:
This chapter introduces the 50-series of operations. The following table defines these
operations:
51 Submit_short_message SMT
52 Deliver_short_message SMSC
53 Deliver_notification SMSC
54 Modify_message SMT
55 Inquiry_message SMT
56 Delete_message SMT
57 Response_inquiry_message SMSC
58 Response_delete_message SMSC
These messages have been introduced in order to provide more facilities to the SMSC
users. If a user has used one of these operations during a session, it is assumed that the
other (output) operations are supported as well. The SMSC initiated operations will always
be those of the 50-series. Only in the cases that are mentioned in section 4.2, the SMSC will
use the UCP01 operation.
The following is a description of this generic ADT (where 'Num. string' indicates 'string of
numeric char.'):
AdC 16 Num. String Address code recipient for the SM OadC 16 Num.
String Address code originator
1 = NAdC used
0131 X.400
1 = LRAd used
1
) Compared to the GSM 03.39 specification the following differences can be noted:
EMI implementation : As mentioned above;
GSM Specification: 1=BN, 2=DN, 3=ND, 4=BN+DN, 5=BN+DN, 6=DN+ND, 7=all.
0131 X.400
1 = DDT used
0 = delivered
Rsn 3 3 num. char. Reason code, value '000'...'255'. Code can be found in
an SMSC configuration file witch can be changed by
the operator. (See appendix A)
2
The SMSC operator may apply limitations.
MT=3:
AMsg 640 Char. string Alphanumeric message encoded into IRA characters.
MT=4:
MMS 1 1 num. char. More Messages to Send (to the same SME)
0 = default alphabet
0 = message class 0
1 = message class 1
2 = message class 2
3 = message class 3
1 = request
2 = response
4
The length is 140 octets when the SMSC is used in a GSM environment and 160 octets when used in a TDMA/CDMA
environment.
TT1LL1DD1…DD1TT2LL2DD2..DD2
Member Type
SM System Message
Member Type
EC Error code
SM System Message
In [3GPP 23.038] chapter “Default alphabet” the 7-bit codes can be derived from the table.
L = 100 1100
P = 101 0000
H = 100 1000
A = 100 0001
@ = 000 0000
N = 100 1110
U = 101 0101
M = 100 1101
The application packs the 7-bit characters in octets as defined in [3GPP 23.038] chapter
”SMS Point-to-Point Packing”. The result is:
b7 B6 b5 b4 b3 b2 b1 b0 Result
0 1 0 0 0 0 0 1 41
0 0 1 0 0 1 1 0 26
0 0 0 1 0 1 0 0 14
0 0 0 1 1 0 0 1 19
0 0 0 0 0 1 0 0 04
0 0 1 1 1 0 0 0 38
1 0 1 0 1 0 1 1 AB
0 1 0 0 1 1 0 1 4D
The application should add the number of useful semi-octets within the alphanumeric
address in front of these values, according to [3GPP 23.040]. The length should be added in
a byte (octet). In case of ALPHA@NUM, the number of useful semi-octets in the 7 bit
encoded representation is 16 decimal (0x10 hexadecimal). This results in the following
hexadecimal values:
Finally this string should be converted to an ASCII string that can be used in the UCP
message. Each nibble (4 bits) should be stored as ASCII character. The resulting ASCII
string is:
10412614190438AB4D
This is the OAdC as it should be stored in a UCP message. The OTOA should be set to
'5039' in the UCP message
There are no restrictions. All characters from the IRA alphabet can be used.
The XSer field allows the specification of one or more additional services, all in the format
TTLLDD…DD, where TT field specifies the type of service, LL indicates the length of data
and DD indicates zero or more data elements. The following subsections specify the
supported service types.
It is possible to combine various Services in the XSer field. The order of the various
Services in the XSer field is not important. However, each Type of Service should not occur
more than once since each repeated occurrence would overwrite the previously set values.
The length of the GSM UDH information, related to the length of the Msg field content, is
restricted to the maximum length of the GSM TP-UD field: 140 octets c.q. 160 septets.
Depending on the MT field this is checked as follows:
• If MT = 2 or 3 then: The length of the UDH field (in octets), multiplied by 8/7, rounded up
to the nearest integer value, plus the length of the NMsg/AMsg field (in octets) must not
exceed 160 (septets).
• If MT = 4 then: The length of the UDH field (in octets) plus the length of the TMsg field (in
octets) must not exceed 140 (octets).
There must be only one occurrence of Type of service 01, GSM UDH information in XSer.
The GSM UDH information field consisting of the following two UDH information elements is
to be encoded:
1. Concatenated short messages, Concatenated short message reference number = 64,
Maximum number of short messages in the concatenated short message = 4, Sequence
number of the current short message = 2
2. Application Port Addressing 8 bit address, destination port = 240, originator port = 250
TT = 02
LL=01
DD=00..FF.
Use the GSM DCS information field value 08 to send text in the Unicode character set
[UCS2]. The MT field must be set to the value 4.
Use the GSM DCS information field to send 8-bit data coded short messages. The MT field
must be set to the value 4. If the GSM DCS information field is not specified, MT=4 indicates
an 8-bit coded short message and the MCLs (Message Class) must be specified.
Use the GSM DCS information field to send “Message Waiting Indication” updates to the
mobile station.
Use the GSM DCS information field to send “Message Class Meaning”. If the MCLs field is
specified too, the GSM DCS information field overrules the MCLs field.
The use of the GSM DCS information field in the XSER field is limited to the UCP51,
UCP52, UCP53 and UCP54 messages.
020108, meaning that the DCS value 08 (0000 1000 binary) is used.
The XSER Types of Services are only applicable for UCP51 and UCP52 operations. Other
operations do not support this extension.
The next table shows which information elements can be accessed or retrieved using the
UCP protocol operations. The first column is the Type of Service in the TTLLDD sequence
(some examples will follow). The second column describes the information element.
This section continues with a detailed description of these Types of Services. This section
ends with an example showing the XSer field when some services are used simultaneously.
This Service indicates the type of a message. It is only present in a delivery when the
message involves an acknowledgement. It has exactly one data element (octet), which can
have the following values:
An example of the Service 03 in the XSer field is the sequence 030102 (TTLLDD), which
means a Manual Acknowledgement message type.
The Message Reference is an identifier for a Short Message. The end user can use it as a
handle to refer to an earlier submitted message. The data element is two octets long and
represents a 16-bit integer number (for TDMA only the lower 13 bits may be used). The first
data element in the sequence contains the most significant bits. If this Service is absent, the
default value 0 is assumed.
For example, the sequence 0402020A (TTLLDD) contains 522 as a Short Message
identifier.
This Type of Service indicates the privacy level of the Short Message. The size of the data
element is one octet, which can have the following values:
01 Restricted
02 Confidential
03 Secret
If the Privacy Indicator is not specified in the submitted message, the default value Not
Restricted is assumed. The next example shows the XSer sequence (TTLLDD) indicating a
Privacy Level of Secret: 050103.
This Type of Service indicates the priority of the Short Message to the end user. The size of
this data element is one octet, which can have the following values:
00 Bulk
01 Normal (Default)
02 Urgent
03 Very Urgent
When the Urgency Indicator has a value of 02 or 03, the SMSC shall attempt to deliver the
message with priority. This can also be realized by setting the UCP field Priority Requested.
However, both ways are independent and do not affect each other.
An example of the Service 06 is the sequence 060102 (TTLLDD), which means: Urgency
Indicator set to Urgent.
This service indicates whether or not the sender of the Short Message requests an
Acknowledgement. This Type of Service is absent in a delivery when no acknowledgement
is requested. The size of the data element is one octet, which can have the following values:
An example of a valid XSer entry is 070101 (TTLLDD), which means that the field
Acknowledgement Request is set to request a Delivery Acknowledgement.
This Type of Service requests to replace a previously submitted message. It is only present
when an update is requested. By default a message is assumed to be a new message. The
size of the data element is one octet, which can have the following values:
00 New (Default)
For example, 080101 (TTLLDD) is a valid XSer entry with the meaning: Message Updating
set, replace the corresponding message in both the SMSC and the SME, if applicable.
This Service associates a Call Back Number information element with the Short Message. A
Call Back Number information element consist of the call back number itself, Type of
Number, Numbering Plan Identification, Presentation Indicator and Alpha Tag. See next
table.
The Call Back Number Type of Service data part, contains a (TTLLDD..DD) on itself (the
TTLLD’s are nested). The next table presents the nested tag codes, which should be used
within the Call Back Number Type of Service.
CBN 01 1 to 16 octets.
Each of the elements CBN, CBN_TON, CBN_NPI, CBNPI and CBNAT will now be
described in more detail. The CBN consist of 1 to 16 digits IRA encoded. The CBN_TON
and CBN_NPI elements are according the TDMA specifications TIA/EIA-136-123-A.
The Call Back Number Presentation Indicator (CBNPI) controls the presentation and
screening of the Call Back Number at the mobile station. The CBNPI is a bit field with the
size of one octet. The bit field is arranged b7..b0, where b7 means most significant bit. Bits
b7..b4 are reserved and should always be set to zero. Bit 3 and 2 are the Provision bits. Bit
1 and 0 are the Presentation bits. The next tables show the different settings for the
Provision and Presentation bits.
11 Network provided
00 Presentation Allowed
01 Presentation Restricted
When submitting a Short Message, the value of the screening part should be set to 00 in
order to prevent rejection of the message. The default value for the Presentation Indicator is
00, i.e., the presentation is set to Presentation Allowed and the screening is set to User
provided, not screened.
6
The CBNAT is a string with a maximum length of 64 characters.
5
At this moment the SMSC accepts multiple definitions of Call Back Number information elements. However, only the
first definition is really processed, others are ignored.
6
At this moment the CBNAT string is accepted by the SMSC but not associated with the message. Instead an empty string
is associated.
0910010433343536040100050B48656C6C6F
Example of multiple Call Back Number definitions. Two definitions are made, first call back
number 3456, default CBN_TON and CBN_NPI, CBNPI set to zero and CBNAT set to “Hello
World”. Second call back number 7777, default CBN_TON and CBN_NPI, CBNPI set to 01
and CBNAT not defined.
0910010433343536040100050B48656C6C6F0909010437373737040101
The user may optionally set the Response Code in the Manual Acknowledgement Message.
The meaning of the Response Code is specific for the Message Center. The length of the
data element is one octet.
00 – 0F Response Code
An example of a valid XSer entry is 0A010F (TTLLDD), which means: Response Code,
code set to 0F (hex).
This Type of Service enables the user to select a specific teleservice for the message. The
size of the Teleservice Identifier field is one octet and the value of this field should be
according to the table below:
At present the only valid occurrence of the Teleservice Identifier is the sequence 0B0100.
An example of combining various Services in the XSer field is the following sequence:
0301020601020402020A. This sequence can be decomposed in three parts, namely
030102, 060102 and 0402020A. These three parts are the individual examples shown
before for the Services Message Type (03), Urgency Indicator (06) and Message Reference
(04). The explanations of the three parts can be found in the descriptions of the
corresponding services.
The Billing Identifier data element is an alphanumeric field with a variable length of at least 0
and at most 20 characters. These characters need to be part of the Visible String character
set as defined in ITU-T. Each character takes two hexadecimal positions.
o stx = 02(hex)
o etx = 03(hex)
The data field shall always contain ALL fields listed in the 5x series generic ADT. These
fields are separated by “/”. If a member of the ADT is not used in a specific message type,
its place in the data string is empty, but the field separators will be present (“//”).
For example the data block for INQM (OAdC and AdC fields only) will look like:
../55/O/012345/0324///////////......
This format provides a high degree of flexibility as well as upwards compatibility to future
EMI specifications.
This does also apply for the responses. For example, the positive response message
contains the MVP field. This field is only used for the SUBS message positive response; in
all other cases this field is left empty.
NT O Notification Type
MT M Message Type.
MT=2:
MT=3:
MT=4:
PR O Priority Requested
DCs - Deprecated
RES4 -
RES5 -
• If the AC field is used, it should contain at least 4 numeric characters in every message,
which are not all equal to zero, otherwise it shall be rejected.
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
• If NRq is used, and NAdC and NPID are both used, then this address will be used as
notification address.
• If NRq is used, and NAdC or NPID or both are left empty, then the notification is sent to
the originator in the current session. If in this case :
⋅ the session is ended,
⋅ the originator is not known to the SMSC to have more than one address,
⋅ the originator is not a mobile user submitting messages via a UCP application (option
‘Mobile Subscriber Access via Fixed Network’)
⋅ and the notification has not yet been delivered,
Examples:
• Alphanumeric message ‘Message 51' with validity period set and with notification request
to a PC application over TCP/IP.
18/00113/O/51/012345/09876//1/1920870340125000/4/0539//////3012961212//////3//4D6573
73616765203531/////////////CD
• TD message with deferred delivery set and notification request within the session for all
types of notification
39/00099/O/51/0657467/078769//1//7//1/0545765/0122/1/0808971800///////4/32/F5AA34DE//
//1/////////65
The following table shows the parameters in the positive result data field:
Table 5-20: Parameter Positive Result Data Field Submit Short Message Operation
Table 5-21: Short Message Parameter Field Submit Short Message Operation
The following table shows the parameters in the negative result data field:
Table 5-22: Parameter Negative Result Data Field Submit Short Message Operation
Example:
• 00/00022/R/51/N/31//07
NT - Notification Type
MT M Message Type.
MT=2:
MT=3:
MT=4:
RES4 -
RES5 -
• If the recipient of the UCP52 operation is registered in the SMSC as being a large
account, the MSC ISDN address of the mobile originator is stored in the HPLMN field
when the option HOMEPLMN_IN_UCP52 is active.
• If the recipient of the UCP52 operation is registered in the SMSC as being a large
account and the originator of the Short Message has anonymised the message (Hide
CLI), then the OAdC field contains the used SMSC address.
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
• Recipients of UCP52 operations with a UDH specified in the XSer field must be
registered in the SMSC as large accounts.
Example:
• Alphanumeric message ‘Call you back later.’ received from originator 07686745
00/00120/O/52/076523578/07686745/////////////120396111055////3//43616C6C20796F752062
61636B206C617465722E///0//////////A3
The following table shows the parameters in the positive result data field:
Table 5-24: Parameter Positive Result Data Field Delivery Short Message Operation
Example:
• 00/00039/R/52/A//076567:010196010101/6C
The following table shows the parameters in the negative result data field:
Table 5-25: Parameter Negative Result Data Field Delivery Short Message Operation
Example:
• 00/00022/R/52/N/01//05
NT - Notification Type
RPID O Replace PID value. Present when the original SM’s delivery
acknowledgement contains a PID value.
MT M Message Type.
MT=2:
MT=3:
MT=4:
DCs - Deprecated
RES4 -
RES5 -
• If the recipient of the UCP53 operation is registered in the SMSC as being a large
account and the originator of the Short Message has anonymised the message (Hide
CLI), then the OAdC field contains the used SMSC address.
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
Example:
• Notification ‘Message for 3155555, with identification 960109161057 has been buffered’
received
00/00234/O/53/1299998/3155555/////////////090196161057/1/108/090196161105/3//4D65737
361676520666F7220333135353535352C2077697468206964656E74696669636174696F6
E2039363031303931363130353720686173206265656E206275666665726564/////////////1F
The following table shows the parameters in the positive result data field:
Table 5-27: Parameter Positive Result Data Field Delivery Notification Operation
Example:
• 00/00032/R/53/A//020296020202/F2
The following table shows the parameters in the negative result data field:
Example:
• 00/00022/R/53/N/02//07
This operation is used to modify a previously submitted Short Message which is still buffered
in the SMSC. The originally submitted has to be a UCP51 operation. The AdC field in
combination with the SCTS field identifies the message to be modified. Extra security is
provided by an optional check on the OAdC and the AC field.
The message that is buffered in the SMSC will be identified by the modify operation as the
message to be modified, in the following cases.
1. Calling Line Identification (CLI) available: AdC, OAdC and SCTS should all match. If the
AC field was used in the original submitted message, this must match as well. If the CLI
address differs from the OAdC field, then the CLI address must match as well.
2. No Calling Line Identification available: AdC, OAdC, AC and SCTS of the original
message and the modify operation should all match and all be filled in.
Furthermore, if the original message was submitted via a port on the SMSC that is
associated with a Virtual SMSC (VSMSC), then the modify operation has to be sent via the
same VSMSC. If the message is not found in the SMSC, a negative acknowledge is
returned.
The above implies that the recipient address, originator address, authentication code and
timestamp of a previously submitted message cannot be changed.
All other fields can be changed. If a field is left empty in the modify operation, it will leave the
related field in the original submitted short message unchanged. Below the effect is
described in more detail.
1. Notifications.
⋅ If Nrq is empty, no changes are made. The contents of NAdC, NPID and NT are
ignored.
⋅ If Nrq is “0”, the notification request is cancelled. The contents of NAdC, NPID and NT
are ignored.
⋅ If Nrq is “1”, then NAdC and NPID must be both left empty or both used, otherwise a
negative acknowledge is returned.
⋅ If Nrq is “1” and NAdC and NPID are left empty, then the notification is sent to the
originator in the current session, if in this case:
⋅ the session is ended,
⋅ the originator is not known to the SMSC to have more than one address,
NT O Notification Type
SCTS M Service Centre Time Stamp that identifies the message in the
SMSC that is to be modified, in DDMMYYHHmmss.
MT O Message Type.
MT=2:
MT=3:
MT=4:
DCs - Deprecated
RES4 -
RES5 -
• When the AC field is used, it should contain at least 4 numeric characters in every
message, which are not all equal to zero, otherwise it shall be rejected.
• If a message is to be modified that was conditionally or unconditionally forwarded, a
negative acknowledge is returned.
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
• A UCP 54 operation that requires modification of the message contents of a buffered
message that contains a UDH is rejected by the SMSC.
• UCS2 as well as GSM Message Waiting Indications can be supplied in the GSM DCS
information field in the UCP XSer field. Hereby, UCS2 messages can also be modified.
• If the GSM DCS information field is specified in the UCP XSer field, the UCP MCls field
is over-ruled and does not have to be supplied.
• If the stored message contains a message content, the UCP54 message must have the
same alphabet and compression or a new message content must be supplied else the
operation is rejected.
• GSM Message Waiting Indications can be modified only if no MT and NMsg, Amsg or
TMsg is supplied and the alphabet and compression is the same as of the stored
message.
• If the originator of the UCP51 message is not registered in the SMSC as being a large
account and the Billing Identifier in the XSER field is used, then the UCP54 operation will
be rejected with error code 04 "Operation not allowed".
Examples:
• Previously submitted message to recipient 012345 with timestamp 010197120501 is
modified with a new (mobile) last resort address 0654321.
00/00087/O/54/012345/0111111//////1/0654321/0100/////010197120501////3///////////////4C
The following table shows the parameters in the positive result data field:
Table 5-30: Parameter Positive Result Data Field Modify Short Message Operation
Table 5-31: Short Message Parameter Field Modify Short Message Operation
Example:
• 00/00039/R/54/A//012345:020197120005/65
The following table shows the parameters in the negative result data field:
Table 5-32: Parameter Negative Result Data Field Modify Short Message Operation
Example:
• 00/00022/R/54/N/04//0A
NT - Notification Type
MT - Message Type.
MT=2:
MT=3:
MT=4:
DCs - Deprecated
XSer -
RES4 -
RES5 -
• When the AC field is used, it should contain at least 4 numeric characters in every
message which are not all equal to zero, otherwise it shall be rejected.
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
Example:
• Inquiry message on recipient 0786483 from originator 0786875676
65/00066/O/55/0786483/0786875676////////////////////////////////7B
The following table shows the parameters in the positive result data field:
Table 5-34: Parameter Positive Result Data Field Inquiry Message Operation
Example:
• 00/00032/R/55/A//030395030303/F8
The following table shows the parameters in the negative result data field:
Table 5-35: Parameter Negative Result Data Field Inquiry Message Operation
Example:
• 09/00022/R/55/N/02//12
NT - Notification Type
MT M Message Type.
MT=2:
MT=3:
MT=4:
DCs - Deprecated
XSer -
RES4 -
RES5 -
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
Example:
• There are no messages for 0666666 waiting to be send
17/00098/O/57/55555//////////////////3//44657374696E6174696F6E3A203036363636363620/1/
///////////37
The following table shows the parameters in the positive result data field:
Table 5-37: Parameter Positive Result Data Field Response Inquiry Message
Operation
Example:
• 00/00020/R/57/A///9A
The following table shows the parameters in the negative result data field:
Example:
• 47/00022/R/57/N/02//16
NT - Notification Type
MT M Message Type.
MT=2:
MT=3:
MT=4:
DCs - Deprecated
XSer -
RES4 -
RES5 -
• When the AC field is used, it should contain at least 4 numeric characters in every
message which are not all equal to zero, otherwise it shall be rejected.
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
Example:
• Delete messages with timestamps ‘960901113944 960808122222' for recipient 0546546
from originator 08456556
12/00115/O/56/0546546/08456556/////////////////3//39363039303131313339343420393630383
038313232323232/////////////2A
The following table shows the parameters in the positive result data field:
Table 5-40: Parameter Positive Result Data Field Delete Message Operation
Example:
• 10/00032/R/56/A//040497161604/07
The following table shows the parameters in the negative result data field:
Table 5-41: Parameter Negative Result Data Field Delete Message Operation
Example:
• 00/00022/R/56/N/01//09
NT - Notification Type
MT M Message Type.
MT=2:
MT=3:
MT=4:
DCs - Deprecated
XSer -
RES4 -
RES5 -
• If the option ‘Long Message’ is not supported on the SMSC, the maximum length of
AMsg represents 160 characters and NMsg is 160 digits.
Example:
22/00188/O/58/55555//////////////////3//44657374696E6174696F6E2030363636363636206964
656E74696669636174696F6E3A2039363031313030393130343320686173206265656E20
64656C657465642E/1////////////FF
The following table shows the parameters in the positive result data field:
Table 5-46: Parameter Positive Result Data Field Response Delete Message Operation
Example:
• 00/00029/R/58/A//064564565/7D
The following table shows the parameters in the negative result data field:
Table 5-47: Parameter Negative Result Data Field Response Inquiry Operation
Example:
• 00/00027/R/58/N/02/07567/1A
This chapter introduces the 60-series of operations. The 60-series are used in combination
with registered SMTs. The following table defines these operations:
The following table is a description of this generic ADT (where 'Num. string' indicates 'string
of numeric char.'):
Member Type
SM System Message
Member Type
EC Error code
SM System Message
o stx = 02(hex)
o etx = 03(hex)
The data field shall always contain ALL fields listed in the 6x series generic ADT. These
fields are separated by “/”. If a member of the ADT is not used in a specific message type,
its place in the data string is empty, but the field separators will be present (“//”).
This format provides a high degree of flexibility as well as upwards compatibility to future
EMI specifications.
In the columns marked 'Presence' of the sections to follow, “M” indicates that the field is
Mandatory, “O” indicates that the parameter is Optional and “-” indicates that the parameter
shall be empty.
OAdC M Any valid X.121, E.164, TCP/IP or abbreviated address, excluding prefixes
3 = X121 address
1 = open session
2 = reserved
3 = change password
5 = reserved
00 = Mobile station
39 = PC application
RES1 -
• If ISDN is used as access method to the SMSC, then the ONPI field should remain
empty.
• In case STYP=4 or STYP=6 (provisioning) then the physical address from which the
connection is set up (CLI-address) is not checked. That is, the connection may be set
up from any address.
• The session setup is refused by the SMSC when:
⋅ the physical address is to be screened and STYP=1 or STYP=3 and the CLI-address
(connect address) is not registered in the SMSC.
⋅ the OAdC contains an address or abbreviated short number that is not a registered
large account.
⋅ the supplied password does not match.
Example:
• 02/00059/O/60/07656765/2/1/1/50617373776F7264//0100//////61
The following table shows the parameters in the positive result data field:
Table 6-6: Parameter Positive Result Data Field Session Management Operation
Example:
• 00/00019/R/60/A//6D
The following table shows the parameters in the negative result data field:
Table 6-7: Parameter Negative Result Data Field Session Management Operation
Example:
• 00/00022/R/60/N/01//04
OAdC M Any valid X.121, E164, TCP/IP or abbreviated address, excluding prefixes
3 = X121 address
LAdC M Address to be ‘filled in’, ‘removed from’ or ‘checked in’ a VSMSC list,
containing a valid X.121, E.164 or TCP/IP address excluding prefixes
3 = X121 address
5 = TCP/IP address
RES1 -
RES2 -
Example:
• 00/00058/O/61/04568768///2///0100/1920870340094000//5///06
The following table shows the parameters in the positive result data field:
Table 6-9: Parameter Positive Result Data Field Provisioning Actions Operation
Example:
• 00/00019/R/61/A//6E
The following table shows the parameters in the negative result data field:
Table 6-10: Parameter Negative Result Data Field Provisioning Actions Operation
Example:
• 00/00022/R/61/N/02//06
AdC String of num. char. M Address code for the SMT, maximum
length is 16 digits.
0131 X.400
PID value 0639 can only be used to alert for the own (originator) address and if the
abbreviated number is the OAdC of the corresponding 60 operation ‘open session’.
Example:
• Alert requested on PSTN number 0234765439845
02/00035/O/31/0234765439845/0139/A0
The following table shows the parameters in the positive result data field:
Table 7-2: Parameter Positive Result Data Field SMT Alert Operation
If used, the positive SMT alert operation result text SM parameter will contain the number of
messages waiting in the SC destined for the subscriber the alert was generated for. The
number consists of four digits and contains leading zeros. When the number of messages
waiting in the SC is more than 9,999, then 9999 will be returned as the number of messages
waiting. In case the alert address is a Multiple Address large account, the number of
messages waiting is always returned as ‘0000’, independent of the actual number of waiting
messages.
Example:
• 04/00024/R/31/A/0003/5D
The following table shows the parameters in the negative result data field:
Table 7-3: Parameter Negative Result Data Field SMT Alert Operation
The following error codes can be returned in the operation negative result:
01 Checksum error
02 Syntax error
04 Operation not allowed (at this point in time)
05 Call barring active
06 AdC invalid
07 Authentication failure
08 Legitimisation code for all calls, failure
24 Message too long
26 Message type not valid for the pager type
Example:
7 00/00022/R/31/N/06//07
The following table shows the parameters in the operation data field:
MT=2:
NMsg
String of num. char. O Numeric message, maximum length is
160 digits.
MT=3:
AMsg
String of char. O Alphanumeric message encoded into IRA
characters, maximum length is
representing 640 characters.
Examples:
• Alphanumeric message ‘Short Message’
00/00041/O/01/0888444///2/716436383334/C5
The following table shows the parameters in the positive result data field:
Table 8-2: Parameter Positive Result Data Field Call Input Operation
When the SMSC initiates this operation, the contents of the SM parameter will be discarded.
Example:
• 06/00043/R/01/A/01234567890:090196103258/4E
The following table shows the parameters in the negative result data field:
Table 8-4: Parameter Negative Result Data Field Call Input Operation
The following error codes can be returned in the operation negative result:
01 Checksum error
02 Syntax error
03 Operation not supported by system
04 Operation not allowed (at this point in time)
The following table shows the parameters in the operation data field:
Table 8-5: Parameters Operation Data Field Multiple Address Call Input Operation
MT=2:
MT=3:
• The SMSC does currently not support the Multiple call input operation for large accounts
in combination with throughput regulation.
• The SMSC does not support the Multiple call input operation for Multiple Address large
accounts.
• The NPL parameter must range from 1 to 20 thus limiting the length of the RAd:s list to
20. An IW also contains the DEST_MAX parameter. The NPL must also have a value
less than or equal to this parameter.
Examples:
• Alphanumeric message ‘SMSC’ to 3 subscribers
05/00059/O/02/3/01111/02222/03333/0123456789//3/534D5343/52
• Numeric message ‘563444' to 5 subscribers
17/00069/O/02/5/01111/02222/03333/04444/05555/0123456789//2/563444/44
The following table shows the parameters in the positive result data field:
Table 8-6: Parameter Positive Result Data Field Multiple Address Call Input Operation
Table 8-7: Short Message Parameter Field Multiple Address Call Input Operation
Since the operation allows for a maximum of 20 addresses to be provided the positive result
may also contain a maximum of 20 address:time-stamp combinations.
If some of the addresses are invalid, and some are valid, the invalid addresses can be
recognised by the absence of the timestamp field. If all addresses are invalid, a negative
result is returned.
Example
• 82/00059/R/02/A/0654321:090196113940,065432:090196113940/86
The following table shows the parameters in the negative result data field:
Table 8-8: Parameter Negative Result Data Field Multiple Address Call Input Operation
The following error codes can be returned in the operation negative result:
01 Checksum error
02 Syntax error
04 Operation not allowed (at this point in time)
05 Call barring active
06 AdC invalid
07 Authentication failure
08 Legitimisation code for all calls, failure
23 Message type not supported by system
24 Message too long
26 Message type not valid for the pager type
Example:
• 47/00022/R/02/N/01//0B
Table 8-9: Parameter Operation Data Field Call Input with Services Operation
MT=2:
MT=3:
• The RAd field contains an address and optionally a legitimisation code. If the
legitimisation code is present it is separated from the address by a comma ",". If the
legitimisation code is not present the comma may be omitted. If present the legitimisation
code is discarded by the IW.
• The NPL must be equal to zero. If the NPL contains anything else than zero a negative
response with "GA not valid" (09) must be sent to the message sender. Since NPL must
be equal to zero the GA:s list may not be used.
• The RP parameter may not be set. If the RP parameter is set a negative response with
"Repetition not allowed" (10) must be sent to the message sender.
• The PR parameter may not be set. If the PR parameter is set a negative response with
"Priority call not allowed" (12) must be sent to the message sender.
• The LPR parameter may not be set. If the LPR parameter is set a negative response with
"Priority call not allowed" (12) must be sent to the message sender.
• The UR parameter may not be set. If the UR parameter is set a negative response with
"Urgent message not allowed" (14) must be sent to the message sender.
• The LUR parameter may not be set. If the LUR parameter is set a negative response
with "Urgent message not allowed" (14) must be sent to the message sender.
• The RC parameter may not be set. If the RC parameter is set a negative response with
"Reverse charging not allowed" (16) must be sent to the message sender.
• The LRC parameter may not be set. If the LRC parameter is set a negative response
with "Reverse charging not allowed" (16) must be sent to the message sender.
Examples:
• Alphanumeric message ‘CMG’
15/00058/O/03/01234568/0756663/2435/0//////////3/434D47/1B
• Numeric message ‘89123334' with deferred delivery
22/00067/O/03/01234568/0756663//0////////1/0602961500/2/89123334/CF
The following table shows the parameters in the positive result data field:
Table 8-10: Parameter Positive Result Data Field Call Input with Services Operation
Table 8-11: Short Message Parameter Field Call Input with Services Operation
Example:
• 01/00038/R/03/A/066666:090296103355/4F
The following table shows the parameters in the negative result data field:
Table 8-12: Parameter Negative Result Data Field Call Input with Services Operation
01 Checksum error
02 Syntax error
03 Operation not supported by system
04 Operation not allowed (at this point in time)
05 Call barring active
06 AdC invalid
07 Authentication failure
08 Legitimisation code for all calls, failure
09 GA not valid
10 Repetition not allowed
11 Legitimisation code for repetition, failure
12 Priority call not allowed
13 Legitimisation code for priority call, failure
14 Urgent message not allowed
15 Legitimisation code for urgent message, failure
16 Reverse charging not allowed
17 Legitimisation code for reverse charging, failure
18 Deferred delivery not allowed
21 Standard text not valid
22 Time period not valid
23 Message type not supported by system
24 Message too long
26 Message type not valid for the pager type
Example:
01/00022/R/03/N/22//05
0131 X.400
Examples:
• Alphanumeric message ‘EMI specification’ with notification requested to a PC application
over PSTN
56/00089/O/30/0123456/0568243//1/0296877842/0139////454D49207370656369666963617
4696F6E/D4
• Alphanumeric message ‘Message OK’ with deferred delivery and validity period set
44/00077/O/30/0673845336//////1/1003961344/1203961200/4D657373616765204F4B/27
The following table shows the parameters in the positive result data field:
Table 8-14: Parameter Positive Result Data Field MS Message Transfer Operation
Example:
• 10/00039/R/30/A//067345:070295121212/6F
The following table shows the parameters in the negative result data field:
Table 8-16: Parameter Negative Result Data Field MS Message Transfer Operation
The following error codes can be returned in the operation negative result:
01 Checksum error
02 Syntax error
04 Operation not allowed (at this point in time)
05 Call barring active
06 AdC invalid
07 Authentication failure
Error codes, which can be returned in the operations negative result, are listed in [ETSI
03.00] paragraph 9.2.6. For all operations defined in the ERMES recommendation, which
are not implemented in the SMSC, EMI returns with error code 03 ("Operation not supported
by system").
01 Checksum error
02 Syntax error
06 AdC invalid
07 Authentication failure
09 GA not valid
30 Subscriber hang-up
37 Delivery in progress
38 Message forwarded
04 Any internal error (e.g. no resources), often of temporary nature. If the RAd:s
(number of addresses) parameter contained more addresses than the
specified maximum, the System Message parameter will contain "too many
addresses".
105 SC congestion
109 Sc congestion
112 Unknown SC
113 SC congestion
114 Illegal MS
116 Error in MS
The GSM 7-bit alphabet consists of 2 tables listed below: a default table and an extended
table.
b7 0 0 0 0 1 1 1 1
b6 0 0 1 1 0 0 1 1
b5 0 1 0 1 0 1 0 1
B4 b3 b2 B1 0 1 2 3 4 5 6 7
0 0 0 0 0 @ SP 0 ¡ P ¿ p
0 0 0 1 1 £ DC1 ! 1 A Q a q
0 0 1 0 2 $ “ 2 B R b r
0 0 1 1 3 ¥ # 3 C S c s
0 1 0 0 4 è ¤ 4 D T d t
0 1 0 1 5 é % 5 E U e u
0 1 1 0 6 ù & 6 F V f v
0 1 1 1 7 ì ‘ 7 G W g w
1 0 0 0 8 ò ( 8 H X h x
1 0 0 1 9 Ç θ ) 9 I Y i y
1 0 1 0 10 LF * : J Z j z
1 0 1 1 11 Ø 1) + ; K Ä k ä
1 1 0 0 12 ø Æ , < L Ö l ö
1 1 0 1 13 CR Æ - = M Ñ m ñ
1 1 1 0 14 Å ß . > N Ü n ü
1 1 1 1 15 å É / ? O § o à
1) This code is an escape to an extension of the 7 bit default alphabet table. A receiving
entity, which does not understand the meaning of this escape mechanism, shall display
it as a space character.
b7 0 0 0 0 1 1 1 1
b6 0 0 1 1 0 0 1 1
b5 0 1 0 1 0 1 0 1
B4 b3 b2 B1 0 1 2 3 4 5 6 7
0 0 0 0 0 |
0 0 0 1 1
0 0 1 0 2
0 0 1 1 3
0 1 0 0 4 ^
0 1 0 1 5 2)
0 1 1 0 6
0 1 1 1 7
1 0 0 0 8 {
1 0 0 1 9 }
1 0 1 0 10 3)
1 0 1 1 11 1)
1 1 0 0 12 [
1 1 0 1 13 ~
1 1 1 0 14 ]
1 1 1 1 15 \
In the event that an MS receives a code where a symbol is not represented in the above
table then the MS shall display the character shown in the main default 7 bit alphabet table.
1) This code value is reserved for the extension to another extension table. On receipt of
this code, a receiving entity shall display a space until another extension table is
defined.
2) This code represents the EURO currency symbol. The code value is that used for the
character “e”. Therefore a receiving entity which is incapable of displaying the EURO
currency symbol will display the character “e” instead.
3) This code is defined as a Page Break character. Any mobile which does not understand
the 7 bit default alphabet table extension mechanism will treat this character as Line
Feed.
In the example, the SMT uses “55555” as the originator address and the international
number “0031612345678” for the mobile station address.
[ETSI 03.00] ETSI ETS 300 133-3 Paging Systems (PS); European Radio
Messaging System (ERMES) Part 3: Network aspects; Section 9: I5
interface.
[3GPP 23.038] 3GPP TS 23.038 Alphabets and language-specific information;
Release 5.
[3GPP 23.040] 3GPP TS 23.040 Technical realisation of the Short Message Service
(SMS); Release 5
[ITU-T] ITU-T Recommendation X.208, Open Systems Interconnection Model
and Notation, Specification of Abstract Syntax Notation One (ASN.1).
[TIA/EIA-136-710a] TIA/EIA-136-710a, Short Message Service - Cellular Messaging
Teleservice, 20 November 1998.
[TIA/EIA-637-A] TIA/EIA-637-A, Short Message Service for Spread Spectrum Systems
—5— —I—
50-Series of EMI Messages 15 Inquiry message operation -55 42
Interface history 3
—6—
—M—
60-Series of EMI Messages 53
Modify Short Message operation - 54 38
13, 69
—A— 13, 60
Abbreviations 91 9, 11, 13, 64, 65, 66
Abstract Data Types 15, 53
Address syntax 13, 75, 89 —P—
alphanumeric OadC 20
Provisioning actions operation -61 56
—C—
—R—
9, 10, 11, 13, 62, 63
Reason Codes 77
References xiv, 93
—D— Response delete message operation -58 49
Delete message operation -56 47 Response Inquiry message operation -57 45, 49
Delivery notification operation -53 36
Delivery Short Message operation -52 33 —S—
document
audience xiii Session management operation -60 54
organisation xiii SMSC xiii
purpose xiii SMSC initiated commands 9, 11
SMT initiated commands 9, 11
—E— Standard string 29, 54
Structure of EMI Messages 5
EMI Commands 9, 13 Submit Short Message operation -51 30
EMI External View 1 9, 11, 13, 66, 68
Error Codes 13, 73, 74
Error Codes Overview 13
—T—
—F— typographic conventions xiv
Flow control 12
—X—
XSer Extra Services 21