You are on page 1of 67

Acision Diameter Messaging Interface TM 1.

0
Protocol Specification

CONFIDENTIAL

Document Version:
Document Status:
Document ID:
Document Issue Date:

1.0
ISSUED
Acision Diameter Messaging Interface
March 2010

Copyright Acision BV 2010


All rights reserved. This document is protected by international copyright law and may not be reprinted, reproduced, copied or utilised in whole
or in part by any means including electronic, mechanical, or other means without the prior written consent of Acision BV.
Whilst reasonable care has been taken by Acision BV to ensure the information contained herein is reasonably accurate, Acision BV shall not,
under any circumstances be liable for any loss or damage (direct or consequential) suffered by any party as a result of the contents of this
publication or the reliance of any party thereon or any inaccuracy or omission therein. The information in this document is therefore provided on
an as is basis without warranty and is subject to change without further notice and cannot be construed as a commitment by Acision BV.
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 and Acision BV.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 2 of 67

Table of Contents
Preface........................................................................................................................9
1

Interface Overview ............................................................................................ 10


1.1

1.2
1.3

ADMI Diameter Applications ............................................................................ 14


2.1

2.2

Context ................................................................................................................................ 10
1.1.1
Extended Message Handling Control .................................................................. 10
1.1.2
Apply Services ..................................................................................................... 10
1.1.3
Additional Information Query ............................................................................... 10
Diameter Applications ......................................................................................................... 10
Use of Diameter Base Protocol ........................................................................................... 11
1.3.1
Securing Diameter Messages .............................................................................. 11
1.3.2
Accounting ........................................................................................................... 11
1.3.3
Use of Sessions ................................................................................................... 11
1.3.4
Transport Layer .................................................................................................... 12
1.3.5
Advertising Application Support ........................................................................... 12

ADMI Notification Application .............................................................................................. 14


2.1.1
Notif-Request (NFR) Command .......................................................................... 14
2.1.2
Notif-Answer (NFA) Command ............................................................................ 15
2.1.3
Guidelines for NFR/NFA Usage ........................................................................... 15
2.1.4
Mobile-Application-Request (MAR) Command .................................................... 16
2.1.5
Mobile-Application-Answer (MAA) Command ..................................................... 16
ADMI Messaging Interface Application ............................................................................... 17
2.2.1
Msg-Iface-Request (MIR) Command ................................................................... 17
2.2.2
Msg-Iface-Answer (MIA) Command .................................................................... 18
2.2.3
Guidelines for MIR/MIA Usage ............................................................................ 18
2.2.4
Mobile-Application-Request (MAR) Command .................................................... 18
2.2.5
Mobile-Application-Answer (MAA) Command ..................................................... 19

ADMI AVPs......................................................................................................... 20
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15

Summary ............................................................................................................................. 20
Address Formats ................................................................................................................. 24
Arm-Future-Notification AVP ............................................................................................... 24
Destination-Identity AVP ..................................................................................................... 25
GSM-TPDU AVP ................................................................................................................. 25
ISDN-Address AVP ............................................................................................................. 25
Location-Info AVP ............................................................................................................... 26
MA-OpCode AVP ................................................................................................................ 26
MA-Originator AVP .............................................................................................................. 26
MA-Recipient AVP ............................................................................................................... 26
MAP-ALERT-SC AVP ......................................................................................................... 27
MAP-Cause-Of-Failure AVP ............................................................................................... 27
MAP-Data-Load AVP .......................................................................................................... 27
MAP-Error-Code AVP ......................................................................................................... 27
Message-Reference AVP .................................................................................................... 27

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 3 of 67

3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
3.45
3.46
3.47
3.48
3.49
3.50
3.51
3.52
3.53
3.54
3.55
3.56
3.57
3.58
3.59
3.60
3.61

MO-FWSM AVP .................................................................................................................. 27


MO-SC-Address AVP .......................................................................................................... 27
MSC-Address AVP .............................................................................................................. 27
Msg-Content AVP ................................................................................................................ 28
MT-FWSM AVP ................................................................................................................... 28
MT-SC-Address AVP .......................................................................................................... 28
Network-Node-Address AVP ............................................................................................... 28
Notification-Point AVP ......................................................................................................... 28
Opaque-Data AVP ............................................................................................................... 29
Operation AVP .................................................................................................................... 29
Originating-Identity AVP ...................................................................................................... 29
Parent-Message-Reference AVP ........................................................................................ 30
Recommended-Decision AVP ............................................................................................. 30
Request-Data AVP .............................................................................................................. 30
Request-Counter AVP ......................................................................................................... 30
Response-Data AVP ........................................................................................................... 31
SC-Address AVP ................................................................................................................. 31
SCCP-Destination-Address AVP ........................................................................................ 31
SCCP-Global-Title AVP....................................................................................................... 31
SCCP-GT-Address AVP...................................................................................................... 31
SCCP-Nature-Of-Address-Indicator AVP............................................................................ 31
SCCP-Numbering-Plan AVP ............................................................................................... 32
SCCP-Originator-Address AVP ........................................................................................... 32
SCCP-Responding-Address AVP ....................................................................................... 32
SCCP-Routing-Indicator AVP ............................................................................................. 33
SCCP-Signalling-Point-Code AVP ...................................................................................... 33
SCCP-Subsystem-Number AVP ......................................................................................... 33
SCCP-Translation-Type AVP .............................................................................................. 33
Service-Type AVP ............................................................................................................... 33
SGSN-Node-Address AVP .................................................................................................. 33
SMS-Command-Data AVP .................................................................................................. 33
SMS-Command-Type AVP ................................................................................................. 33
SMS-Content-Info AVP ....................................................................................................... 33
SMS-Destination-Address AVP ........................................................................................... 34
SMS-Discharge-Time AVP .................................................................................................. 34
SMS-Error-Code AVP ......................................................................................................... 34
SMS-Failure-Cause AVP..................................................................................................... 34
SMS-Info AVP ..................................................................................................................... 34
SMS-Language AVP ........................................................................................................... 35
SMS-Last-Delivery-Time AVP ............................................................................................. 35
SMS-Loop-Prevention AVP ................................................................................................. 35
SMS-Message-Mode AVP .................................................................................................. 35
SMS-Message-Number AVP .............................................................................................. 35
SMS-Message-Reference AVP ........................................................................................... 35
SMS-Message-Text AVP .................................................................................................... 36
SMS-Message-Type AVP ................................................................................................... 36

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 4 of 67

3.62
3.63
3.64
3.65
3.66
3.67
3.68
3.69
3.70
3.71
3.72
3.73
3.74
3.75
3.76
3.77
3.78
3.79
3.80
3.81
3.82
3.83
3.84
3.85

Mobile Messaging Principles in ADMI Triggering Context ............................ 40


4.1

SMS-Message-Type-Indicator AVP .................................................................................... 36


SMS-More-Msg-To-Send AVP ............................................................................................ 36
SMS-Originating-Address AVP ........................................................................................... 36
SMS-Parameter-Indicator AVP ........................................................................................... 36
SMS-Payload AVP .............................................................................................................. 36
SMS-Priority AVP ................................................................................................................ 37
SMS-Recipient-Address AVP .............................................................................................. 37
SMS-Reject-Duplicates AVP ............................................................................................... 37
SMS-Replace-If-Present AVP ............................................................................................. 37
SMS-Reply-Path AVP ......................................................................................................... 37
SMS-Sched-Delivery-Time AVP ......................................................................................... 37
SMS-Service-Centre-Time-Stamp AVP .............................................................................. 37
SMS-Status AVP ................................................................................................................. 37
SMS-Status-Report AVP ..................................................................................................... 38
SMS-Status-Report-Indication AVP .................................................................................... 38
SMS-Status-Report-Qualifier AVP ...................................................................................... 38
SMS-User-Data AVP ........................................................................................................... 38
SMS-User-Data-Header-Indicator AVP ............................................................................... 38
SMS-Validity-Period AVP .................................................................................................... 38
SMS-Validity-Period-Format AVP ....................................................................................... 38
Service-Info AVP ................................................................................................................. 39
SRI-SM AVP ........................................................................................................................ 39
TCAP-Segmented AVP ....................................................................................................... 39
Untranslated-Address AVP ................................................................................................. 39

SMS ..................................................................................................................................... 40
4.1.1
Mobile Originated Messages (MO) ...................................................................... 40
4.1.2
Mobile Terminated Messages (MT) ..................................................................... 41
4.1.3
Home-routed Mobile Terminated Messages (MT) ............................................... 42
4.1.4
SMS Application Originated Messages (AO) ....................................................... 43
4.1.5
SMS Application Terminated Messages (AT) ...................................................... 44
4.1.6
SM Notification Points .......................................................................................... 45

Generic Comments ........................................................................................... 46


5.1

5.2

Protocol Version Negotiation ............................................................................................... 46


5.1.1
New Applications ................................................................................................. 46
5.1.2
Negotiation Using CER/CEA ............................................................................... 46
5.1.3
Version Negotiation Commands .......................................................................... 46
Security................................................................................................................................ 46

Appendix A.
A.1
A.2
A.3
A.4
A.5

Commands ................................................................................... 47

Notif-Request (NFR) Command content versus Notification-Point ..................................... 47


Notif-Answer (NFA) Command content versus Notification-Point....................................... 49
Msg-Iface-Request (MIR) Command content versus Operation ......................................... 51
Msg-Iface-Answer (MIA) Command content versus Operation .......................................... 53
Mobile-Application-Request (MAR) Command content ...................................................... 54

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 5 of 67

A.6

Mobile-Application-Answer (MAA) Command content ........................................................ 58

Appendix B.
B.1
B.2

Acision / SM Excerpt ................................................................... 60

Acision Diameter Credit Control AVPs Rules...................................................................... 60


Semantics of Acision AVPs ................................................................................................. 60
B.2.1
SMS-Address-TON AVP ...................................................................................... 60
B.2.2
SMS-Address-NPI AVP ....................................................................................... 61
B.2.3
SMS-Content-CM-Reference AVP ...................................................................... 61
B.2.4
SMS-Content-CM-Segment AVP ......................................................................... 61
B.2.5
SMS-Content-CM-Total AVP ............................................................................... 61
B.2.6
SMS-Content-Info AVP ........................................................................................ 61
B.2.7
SMS-Network-Technology AVP ........................................................................... 61
B.2.8
SMS-Time-Offset AVP ......................................................................................... 62
B.2.9
SMS-Time-Validity AVP ....................................................................................... 62

Abbreviations ........................................................................................................... 63
Glossary ................................................................................................................... 65
References ............................................................................................................... 66

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 6 of 67

List of Figures
Figure 1-1: ADMI Context ...................................................................................................................... 10
Figure 1-2: Basic Message Flow Over Diameter Connection ............................................................... 11
Figure 1-3: ADMI Connection Setup ..................................................................................................... 13
Figure 4-1: MO Message Triggering ..................................................................................................... 41
Figure 4-2: MT Message Triggering ...................................................................................................... 42
Figure 4-3: Home Routed MT Message Triggering ............................................................................... 43
Figure 4-4: AO Message Triggering ...................................................................................................... 44
Figure 4-5: AT Message Triggering ....................................................................................................... 45

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 7 of 67

List of Tables
Table 3-1: AVP Summary ...................................................................................................................... 20
Table A-1: Notif-Request (NFR) Command Content Versus Notification-Point .................................... 47
Table A-2: Notif-Answer (NFA) Command content versus Notification-Point ....................................... 49
Table A-3: Msg-Iface-Request (MIR) Command Content Versus Operation ........................................ 51
Table A-4: Msg-Iface-Answer (MIA) Command Content Versus Operation ......................................... 53
Table A-5: Mobile-Application-Request (MAR) Command content ....................................................... 54
Table A-6: Mobile-Application-Answer (MAA) Command content ........................................................ 58
Table B-1: Rules for relevant AVPs of Acision Credit Control for SMS................................................. 60

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 8 of 67

Preface
Purpose
This document describers the Acision Messaging Interface, being the interface between the
Messaging Servers (core components in Acision messaging platform providing e.g SMS
service) and the Application Servers (providing advance business logic). The Application
servers can be components manufactured by Acision or by external parties.

Audience
The target readership for this document is technical personnel responsible for the design and
implementation of solutions requiring integration between business applications and the
services offered by the Acision Messaging Interface.

Scope
The scope of this document is the definition of the protocol interface between Acision
Messaging components and as an interface to external applications. The external
applications are developed and maintained by either Customers or partners of Acision. It
excludes design considerations for the Acision components and the internals of any higher
layer applications.
The scope is currently limited to SMS and related features. It is expected that in the future
support for other services like email, IM, MMS - will be added.

Organisation
This document is divided into four main chapters. In the first chapter a brief introduction of
the interface is provided together with the main characteristics of the used protocol.
The second chapter provides a brief introduction of the ADMI and its Diameter aspects. The
third chapter provides full details of the AVPs used in the ADMI commands.
In the fourth chapter the potential future evolution of the protocol is discussed.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 9 of 67

Interface Overview

1.1 Context
The Acision Messaging Interface allows for the transfer of both message related and
generic (e.g. signalling) information between Messaging and Application servers.

Messaging
Server

ADMI

Application
Server

Figure 1-1: ADMI Context


The ADMI interface enables messaging platforms to:
Extended message handling control
Advanced services,
Perform information query related to the message from an external source.
1.1.1 Extended Message Handling Control
During a standard message flow there may be cases where the operator would like to apply
network based services on the messages. Examples for this style of services are spam and
virus control which require all message information to determine what how messages should
be processed.
1.1.2 Apply Services
In addition to network based services there are opportunities to allow subscriber based
advanced messaging where the subscribers opt in for a service. This is interesting from an
operator view to increase the ARPU and create high value services for the subscriber base.
Examples here are copy forward, message archiving or out of office notifications.
1.1.3 Additional Information Query
As operators reduce the operational costs relating to provisioning there is a need to be able
to perform a query and return additional information for message/routing related choices. An
example could be which billing system to use for charging.

1.2 Diameter Applications


The Acision Messaging Interface consists of 2 Diameter applications that implement the
interface between a Messaging Server and an Application Server.
The Notification Application is used by Messaging Server to notify (trigger) the Application
server upon certain conditions or on the occurrence of a specific event (either in a message
processing flow or in general in a subscribers device state) and to provide it with specific
message data and/or other data (e.g. device state change). The Application Server accepts
these events, applies its business logic and provides a recommendation to the Messaging
Server how to proceed with the message, which may include the modification of parameters
of the message. Alternatively it could use this information for other/ later processing.
The Messaging Interface Application is used by Application Server to provide the
Messaging server with new message for processing and delivery or for querying some
network information related to a given subscriber.
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 10 of 67

1.3 Use of Diameter Base Protocol


ADMI is based on the Diameter Base Protocol as specified in [BASEDIA], with the following
exceptions:
SCTP support is optional for both client and server,
TLS and IPSEC support is not required in ADMI v 1.0,
support of the Diameter Base Protocol Accounting application (ACR/ACA) is not required.
These deviations are discussed in more detail later in this section.
ADMI specification defines new AVPs, commands and Diameter applications following the
guidelines for design of new application provided in [BASEDIA], [3GPP-REC] and [3GPP-ID].
The basic message flow over a Diameter connection as depicted on Figure 1-2: Basic
Message Flow Over Diameter Connection applies also for ADMI connection. The term ADMI
connection used hereinafter is defined as a Diameter connection with a negotiated ADMI
application(s).
Transportation Connection Establishment
CER
CEA

(Messages)

DWR
DWA

DPR
DPA
Transportation Connection Establishment

Figure 1-2: Basic Message Flow Over Diameter Connection


note that Diameter specification does not distinguish the peers on the transport
Please
layers. Therefore both parties have to try establishing connections to its peers. For more
detailed information on the connection setup please refer to the Diameter Base Protocol
[BASEDIA].
1.3.1 Securing Diameter Messages
The Diameter messages over the ADMI interface are not secured.
1.3.2 Accounting
Accounting functionality (Accounting Session State Machine, related command codes and
AVPs) has no use in the ADMI interface.
1.3.3 Use of Sessions
The ADMI Diameter session span is limited to one ADMI request / answer pair.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 11 of 67

note that Diameter session identifies the request/ answer pair. While the connection
Please
between two ADMI peers is kept until released by one of the parties.
1.3.4 Transport Layer
ADMI interface shall make use of TCP [TCP] as the transport layer.
According to [BASEDIA], there can be only a single transport connection between Diameter
peers. The infrastructure at Message Server side and at Application Server side as well can
consist of multiple nodes and/or multiple processes. Therefore any ADMI enabled process
MUST be able to keep multiple ADMI connections to connect to multiple Diameter peers.
Note that this specification does not mandate that an ADMI enabled component must
implement both ADMI applications. This is a question of requirements whether a particular
component (MS or AS) implements one of the two applications of both. In case a component
implements both interfaces, it is a design decision whether they are implemented in two
separate processes or in a single process. In the first case, each of the two processes
advertises one ADMI application on a separate ADMI connection. In the latter case, the
single process should advertise both ADMI applications over the same Diameter connection
to comply with [BASEDIA]. However ADMI specification explicitly allows to use two separate
connections also in case of a single ADMI process.
If the ADMI process is connected to multiple ADMI peers, it always sends the answer
command back to the originating host. The distribution of requests among the multiple nodes
is outside the scope of this document.
1.3.5 Advertising Application Support
Support of ADMI applications is advertised by means of the standard Capabilities-ExchangeRequest (CER) and Capabilities-Exchange-Answer (CEA) messages defined in [BASEDIA].
The Messaging and Application Servers shall advertise support of ADMI notification interface
by including value 16777275 in the Auth-Application-Id AVP within the Vendor-SpecificApplication-Id grouped AVP of the Capabilities-Exchange-Request and CapabilitiesExchange-Answer commands.
The Messaging and Application Servers shall advertise support of ADMI messaging interface
by including value 16777276 in the Auth-Application-Id AVP within the Vendor-SpecificApplication-Id grouped AVP of the Capabilities-Exchange-Request and CapabilitiesExchange-Answer commands.
The Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the CER and
CEA commands shall be set to vendor identifier value of Acision (3830).
Diameter nodes manufactured by Acision shall set the top level Vendor-Id AVP of the CER
and CEA commands to vendor identifier of Acision (3830).

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 12 of 67

Peer 1

Peer 2
Establish TCP Session

CER
Auth-Application-Id AVP:
ADMI notification (16777275),
Vendor-Id: <Vendor ID>/Acision (3830);
Vendor-Id: 3GPP (10415)
CEA
Auth-Application-Id AVP:
ADMI notification (16777275),
Vendor-Id: <Vendor ID>/Acision (3830);
Vendor-Id: 3GPP (10415)

ADMI Communication Established

Figure 1-3: ADMI Connection Setup


Diameter nodes manufactured by third party shall set the top level Vendor-Id AVP of the
CER and CEA commands to vendor identifier of the third party and in addition set the
Supported-Vendor-Id AVP to vendor identifier of Acision (3830).
All Diameter nodes advertising support of ADMI shall include the Supported-Vendor-Id AVP
set to the vendor identifier value of 3GPP (10415) in the CER and CEA commands.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 13 of 67

ADMI Diameter Applications


In the following chapters, modified Augmented BNF is used to describe the syntax of
Diameter commands. In the rest of the document this will be referred to as ABNF and its
definition is in [BASEDIA] in section 4.4.
An oversimplified summary would be that a Diameter command is described using form like:
Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY >
{ User-Name }
* { Origin-Host }
* [ AVP ]

Where curly bracket means present AVP, square bracket optional AVP. It can be prefixed by
repetition indication where * means any number (including zero), 1* means one ore more
repetitions. All AVPs in bold are Acision defined, all others are from the Diameter Base
Protocol [BASEDIA] or 3GPP standards [3GPP-ID].
When we reuse an already defined command or grouped AVPs where we do not use some
of the optional AVPs then these are simply left out in the ABNF definition (unlike striking out
as used in some other Diameter based protocol specifications).
that the two command codes for NFR/NFA and MIR/MIA has not been registered yet.
Note
In this specification next two free codes available at the time of writing were chosen.

2.1 ADMI Notification Application


The ADMI Notification Application consists of Notif-Request, Notif-Answer and MobileApplication-Request, Mobile-Application-Answer commands.
2.1.1 Notif-Request (NFR) Command
The MS sends Notif-Request to AS in order to notify the AS that
Subscriber's state changed (e.g., Mobile Originated message is received by the
Messaging Server),
Processing of a message reached a particular trigger point (e.g. the Messaging Server is
about to perform message delivery attempt).
The notification request has the following format:
< Notif-Request > ::= <
<
{
{
{
{
[
{
{
* [
* {
[
[
[
[
[
[
* [

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Diameter Header: 326, REQ, 16777275 >


Session-Id >
Origin-Host }
Origin-Realm }
Destination-Realm }
Auth-Application-Id }
Destination-Host ]
Service-Type }
Notification-Point }
Originating-Identity ]
Destination-Identity }
Message-Reference ]
Parent-Message-Reference ]
Msg-Content ]
Service-Info ]
Opaque-Data ]
Request-Counter ]
AVP ]

Version: 1.0
Status: ISSUED
Page 14 of 67

The MS setup determines when a notification is generated for a specific application:


State change notification: Message Server decides on its own (e.g. based on its
configuration) whether a notification will be generated for a particular subscriber state
change.
Message notification: Message Server decides on its own (e.g. based on its
configuration) whether a notification will be generated for a particular message and if so,
at which trigger point.
Consecutive message notifications: In response to the notification, the Application Server
can arm next trigger point at which it wishes to receive a notification for this particular
message.
The key Attribute-Value Pairs (AVP)s of the NFR in the ADMI triggers are the following:
In the Notification-Point AVP, the Messaging Server specifies the point at which the
notification was generated (either a point in message processing or a subscriber's state
change).
Message-reference AVP is mandatory for all notification except for the state change
notification, as this is not related to any specific message.
Originating-Identity AVP the subscriber identity the notification relates to (i.e. the
subscriber who originated the message or the subscriber whose state changed).
All Acision specific AVPs of the ANR are further described in chapter 0.
Opaque-Data AVP sent back in the NFR only if it was filled in previous NFA for the same
message (see next section).
2.1.2 Notif-Answer (NFA) Command
On reception of a Notif-Request (NFR), the Application Server performs all actions
appropriate for the notification and will reply to the Messaging Server with Notif-Answer
(NFA).
The notification answer has the following message format:
< Notif-Answer > ::=

<
<
{
{
{
{
* [
[
[
{
[
[
* [

Diameter Header: 326, 16777275 >


Session-Id >
Origin-Host }
Origin-Realm }
Auth-Application-Id }
Result-Code }
Destination-Identity ]
Msg-Content ]
Service-Info ]
Recommended-Decision }
Arm-Future-Notification ]
Opaque-Data ]
AVP ]

All Acision defined AVPs of the NFA are described in detail in chapter 0.
2.1.3 Guidelines for NFR/NFA Usage
The following principles apply for the Applications supporting ADMI Notifications:
1. For message related notification, Application Server may change any data in ServiceInfo, Destination-Identity or Opaque-Data AVPs received in the NFR. In this case,
Application Server will include in the answer only the changed AVPs. Data that should
not be changed must not appear in the answer. If there are no changes, none of these
AVPs may appear in the NFA. It depends on the given processing context / agreement

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 15 of 67

what AVPs are allowed to be changed by AS. When AS requests a change to an AVP
which is not allowed, an error should be logged on the Messaging Server.
AS can also add AVP in the answer the case of Opaque-Data. SMS-Error-Code in
Service-Info is used to signal SMS message status in NFR and proposed status in NFA
in the context of Recommended-Decision (e.g. drop).
2. Application Server always sets Recommended-Decision AVP in the answer.
3. Application Server may include the Arm-Future-Notification AVP to the answer in case of
message related notification if it requires to be notified at a latter point in the processing
of this particular message.
4. Application server may include Opaque-Data AVP in the NFA containing any binary data
it may need in the future processing. The Messaging Server will return these in the next
NFR for that message. If this AVP is not sent in the NFA no Opaque-Data will be sent in
the next NFR (i.e. if the AS needs the same Opaque-Data for all armed notification
points, it has to send this AVP in every NFA).
5. Messaging Server on receipt of the NFA may reflect changes that have been done by
AS Service-info, Destination-Identity or Opaque-Data AVPs. The MS has the final
authority to decide whether the changes provided by AS will be followed.
6. Messaging Server will look at the Recommended-Decision and apply or override this
decision. The Messaging Server has final authority over the message processing.
The same processing guidelines apply to the following MAR and MAA commands.
2.1.4 Mobile-Application-Request (MAR) Command
Mobile-Application-Request command is used by the Messaging Server to notify or deliver
messages to the Application Server on a lower level than NFR. Specifically it exposes lower
layer SMS message encoding details.
The Mobile-Application request has the following format:
< Mobile-Application-Request > ::= < Diameter Header: 328, REQ, 16777275 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
[ Destination-Host ]
{ MA-OpCode }
[ SMS-Network-Technology ]
[ SRI-SM ]
[ MO-FWSM ]
[ MT-FWSM ]
[ Request-Data ]
[ Response-Data ]
[ SCCP-Destination-Address ]
[ SCCP-Originator-Address ]
[ SCCP-Responding-Address ]
[ MAP-Error-Code ]
[ MAP-Cause-Of-Failure ]
[ TCAP-Segmented ]
* [ AVP ]

Please refer to Appendix for the availability of individual AVPs in given context.
2.1.5 Mobile-Application-Answer (MAA) Command
In the Mobile-Application-Answer (MAA) the AS signals back to the MS whether it has
received the message or just used it as a trigger. Fro the triggering the AS can modify subset
of the parameters. The same rules as with NFR/NFA apply here (only changed AVPs are
returned back).
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 16 of 67

The Mobile-Application Answer has the following format:


< Mobile-Application-Answer > ::= < Diameter Header: 328, 16777275 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ Result-Code }
[ Recommended-Decision ]
[ Arm-Future-Notification ]
[ SRI-SM ]
[ MT-FWSM ]
[ Response-Data ]
[ MAP-ALERT-SC ]
[ SCCP-Responding-Address ]
[ MAP-Error-Code ]
[ MAP-Cause-Of-Failure ]
* [ AVP ]

Similarly as with NFR/NFA the AS can in the MAA indicate what next notification it is
interested in. In this context SMS-SUBMIT-REPORT is considered as post-submission
notification (i.e. supported values of Arm-Future-Notification) point and SMS-DELIVERREPORT as post-delivery. Please refer to Appendix for the availability of individual AVPs in
given context.

2.2 ADMI Messaging Interface Application


ADMI Messaging Interface Diameter Application consists of Msg-Iface-Request, Msg-IfaceAnswer and Mobile-Application-Request, Mobile-Application-Answer commands. This
primitives allow an Application Server to initiate new messages that are further processed by
the Messaging Server and delivered according to the MS routing rules.
2.2.1 Msg-Iface-Request (MIR) Command
The application server uses the MIR command:
1. To pass a new message to the messaging server. Messaging server becomes
responsible for delivery of the message.
2. To query subscriber location information from Messaging server
3. For other use-cases which will be supported in future versions of ADMI, see more in
section 0.
The MIR command has the following message format:
< Msg-Iface-Request > ::= <
<
{
{
[
{
{
{
* {
* [
[
[
[
[
* [

Diameter Header: 327, REQ, 16777276 >


Session-Id >
Origin-Host }
Origin-Realm }
Destination-Host ]
Destination-Realm }
Auth-Application-Id }
Operation }
Originating-Identity }
Destination-Identity ]
Message-Reference ]
Parent-Message-Reference ]
Msg-Content ]
Service-Info ]
AVP ]

The Operation AVP is used to distinguish message submission and location information
query. In case of location information query, Message-Reference, Parent-MessageReference, Msg-Content and Msg-Properties AVPs are not present in MIR command.
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 17 of 67

2.2.2 Msg-Iface-Answer (MIA) Command


On reception of a Msg-Iface-Request command, the Messaging Server replies to Application
Server with a Msg-Iface-Answer. The MIA command has the following format:
< Msg-Iface-Answer > ::= <
<
{
{
{
[
[
{
* [

Diameter Header: 327, 16777276 >


Session-Id >
Origin-Host }
Origin-Realm }
Auth-Application-Id }
Location-Info ]
SMS-Error-Code ]
Result-Code }
AVP ]

Location-Info AVP is present only in successful answer to a location query.


2.2.3 Guidelines for MIR/MIA Usage
In MIR the Operation AVP discriminates the type of operation. Currently there are two
categories:
Sending a message (SM-Submit, SM-Deliver)
Auxiliary services like SM location info1.
The main use for these commands is sending of a new message. This means that for MIR
the most important data are Originating-Identity, Destination-Identity and Msg-Content (and
Message-Reference so that we can identify the message later on). The MIA the carries the
result of the requested operation.
2.2.4 Mobile-Application-Request (MAR) Command
By using the MAR command within the Message Interface Application the AS can also
initiate new messages on the lower level. This is somewhat symmetrical to the MAR/MAA in
the Notification Application (but in the opposite direction).
The Mobile-Application request has the following format:
< Mobile-Application-Request > ::= < Diameter Header: 328, REQ, 16777276 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
[ Destination-Host ]
{ MA-OpCode }
[ SMS-Network-Technology ]
[ SRI-SM ]
[ MO-FWSM ]
[ MT-FWSM ]
[ Request-Data ]
[ Response-Data ]
[ SCCP-Destination-Address ]
[ SCCP-Originator-Address ]
[ SCCP-Responding-Address ]
[ MAP-Error-Code ]
[ MAP-Cause-Of-Failure ]
[ TCAP-Segmented ]
* [ AVP ]

Please refer to Appendix for the availability of individual AVPs in given context.

Subject for specific Messaging Server deployment configuration in the operator network.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 18 of 67

2.2.5 Mobile-Application-Answer (MAA) Command


The Mobile-Application answer has the following format:
< Mobile-Application-Answer > ::= < Diameter Header: 328, 16777276 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ Result-Code }
[ Recommended-Decision ]
[ SRI-SM ]
[ MT-FWSM ]
[ Response-Data ]
[ MAP-ALERT-SC ]
[ SCCP-Responding-Address ]
[ MAP-Error-Code ]
[ MAP-Cause-Of-Failure ]
* [ AVP ]

Please refer to Appendix for the availability of individual AVPs in given context.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 19 of 67

ADMI AVPs

3.1 Summary
In the following table a summary of all used AVPs (except for the base Diameter ones) is
provided.
Table 3-1: AVP Summary
AVP Flags

3GPP-IMSI-MCCMNC

3GPP TS 29.061

UTF8String

M, V

3GPP-IMSI

3GPP TS 29.061

UTF8String

M, V

3GPP-User-LocationInfo

22

3GPP TS 29.061

OctetString

M, V

Address-Data

897

3GPP TS 32.299

UTF8String

M, V

Address-Domain

898

3GPP TS 32.299

Grouped

M, V

Address-Type

899

3GPP TS 32.299

Enumerated

M, V

Addressee-Type

1208

3GPP TS 32.299

Enumerated

M, V

Arm-FutureNotification

1000

Acision / ADMI

Enumerated

M, V

Data-Coding-Scheme

2001

3GPP TS 32.299

Integer32

M, V

Destination-Identity

1001

Acision / ADMI

Grouped

M, V

Domain-Name

1200

3GPP TS 32.299

UTF8String

M, V

GSM-TPDU

1032

Acision / ADMI

Grouped

M, V

ISDN-Address

1033

Acision / ADMI

Grouped

M, V

Location-Info

1002

Acision / ADMI

Grouped

M, V

MA-OpCode

1034

Acision / ADMI

Enumerated

M, V

MA-Originator

1035

Acision / ADMI

Grouped

M, V

MA-Recipient

1036

Acision / ADMI

Grouped

M, V

MAP-ALERT-SC

1037

Acision / ADMI

Grouped

M, V

MAP-Cause-OfFailure

1038

Acision / ADMI

Unsigned32

M, V

MAP-Data-Load

1080

Acision / ADMI

OctetString

M, V

MAP-Error-Code

1039

Acision / ADMI

Unsigned32

M, V

MO-FWSM

1040

Acision / ADMI

Grouped

M, V

MO-SC-Address

1083

Acision / ADMI

Grouped

M, V

MT-FWSM

1041

Acision / ADMI

Groped

M, V

MT-SC-Address

1084

Acision / ADMI

Grouped

M, V

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

May
Encr.
Must
Not

Value Type

Shoul
d Not

Source/ Owner

May

AVP
Code

Must

AVP Name

Version: 1.0
Status: ISSUED
Page 20 of 67

AVP Flags

MSC-Address

1003

Acision / ADMI

Address

M, V

Message-Reference

1004

Acision / ADMI

OctetString

M, V

Msg-Content

1005

Acision / ADMI

Grouped

M, V

Network-NodeAddress

1042

Acision / ADMI

Grouped

M, V

Notification-Point

1006

Acision/ADMI

Enumerated

M, V

Opaque-Data

1007

Acision/ADMI

OctetString

M, V

Operation

1008

Acision / ADMI

Enumerated

M, V

Originating-Identity

1009

Acision / ADMI

Grouped

M, V

Originator-Address

886

3GPP TS 32.299

Grouped

M, V

Originator-SCCPAddress

2008

3GPP TS 32.299

Address

M, V

Parent-MessageReference

1010

Acision / ADMI

OctetString

M, V

Recipient-Address

1201

3GPP TS 32.299

Grouped

M, V

Recipient-SCCPAddress

2010

3GPP TS 32.299

Address

M, V

RecommendedDecision

1011

Acision / ADMI

Enumerated

M, V

Reply-PathRequested

2011

3GPP TS 32.299

Enumerated

M, V

Request-Counter

1031

Acision / ADMI

Unsigned32

M, V

Request-Data

1044

Acision / ADMI

Grouped

M, V

Response-Data

1045

Acision / ADMI

Grouped

M, V

SC-Address

1046

Acision / ADMI

Grouped

M, V

SCCP-DestinationAddress

1047

Acision / ADMI

Grouped

M, V

SCCP-GT-Address

1048

Acision / ADMI

UTF8String

M, V

SCCP-Global-Title

1049

Acision / ADMI

Grouped

M, V

SCCP-Nature-OfAddress-Indicator

1050

Acision / ADMI

Enumerated

M, V

SCCP-NumberingPlan

1051

Acision / ADMI

Enumerated

M, V

SCCP-OriginatorAddress

1052

Acision / ADMI

Grouped

M, V

SCCP-RespondingAddress

1053

Acision / ADMI

Grouped

M, V

SCCP-RoutingIndicator

1054

Acision / ADMI

Enumerated

M, V

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

May
Encr.
Must
Not

Value Type

Shoul
d Not

Source/ Owner

May

AVP
Code

Must

AVP Name

Version: 1.0
Status: ISSUED
Page 21 of 67

AVP Flags

SCCP-SignallingPoint-Code

1055

Acision / ADMI

Unsigned32

M, V

SCCP-SubsystemNumber

1056

Acision / ADMI

Unsigned32

M, V

SCCP-TranslationType

1057

Acision / ADMI

Unsigned32

M, V

SGSN-Address

1228

3GPP TS 32.299

Address

M, V

SGSN-Node-Address

1058

Acision / ADMI

Grouped

M, V

SM-Protocol-ID

2013

3GPP TS 32.299

OctetString

M, V

SM-User-DataHeader

2015

3GPP TS 32.299

OctetString

M, V

SMS-Address-NPI

68

Acision / SMS

UTF8String

M, V

SMS-Address-TON

67

Acision / SMS

UTF8String

M, V

SMS-Command-Data

1061

Acision / ADMI

OctetString

M, V

SMS-Command-Type

1062

Acision / ADMI

Unsigned32

M, V

SMS-Content-CMReference

19

Acision / SMS

Unsigned32

M, V

SMS-Content-CMSegment

20

Acision / SMS

Unsigned32

M, V

SMS-Content-CMTotal

22

Acision / SMS

Unsigned32

M, V

SMS-Content-Info

25

Acision / SMS

Grouped

M, V

SMS-DestinationAddress

1063

Acision / ADMI

OctetString

M, V

SMS-Discharge-Time

1064

Acision / ADMI

OctetString

M, V

SMS-Error-Code

1012

Acision / ADMI

Integer32

M, V

SMS-Failure-Cause

1065

Acision / ADMI

Unsigned32

M, V

SMS-Info

1013

Acision / ADMI

Grouped

M, V

SMS-Language

1014

Acision / ADMI

UTF8String

M, V

SMS-Last-DeliveryTime

1015

Acision / ADMI

Time

M, V

SMS-Loop-Prevention

1016

Acision / ADMI

Enumerated

M, V

SMS-Message-Mode

1017

Acision / ADMI

Enumerated

M, V

SMS-MessageNumber

1066

Acision / ADMI

Unsigned32

M, V

SMS-MessageReference

1067

Acision / ADMI

Unsigned32

M, V

SMS-Message-Text

1018

Acision / ADMI

UTF8String

M, V

SMS-Message-Type

1019

Acision / ADMI

Enumerated

M, V

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

May
Encr.
Must
Not

Value Type

Shoul
d Not

Source/ Owner

May

AVP
Code

Must

AVP Name

Version: 1.0
Status: ISSUED
Page 22 of 67

AVP Flags

SMS-Message-TypeIndicator

1082

Acision / ADMI

Unsigned32

M, V

SMS-More-Msg-ToSend

1020

Acision / ADMI

Enumerated

M, V

SMS-NetworkTechnology

35

Acision / SMS

Enumerated

M, V

SMS-OriginatingAddress

1081

Acision / ADMI

OctetString

M, V

SMS-ParameterIndicator

1068

Acision / ADMI

Unsigned32

M, V

SMS-Payload

1021

Acision / ADMI

Grouped

M, V

SMS-Priority

1022

Acision / ADMI

Integer32

M, V

SMS-RecipientAddress

1069

Acision / ADMI

OctetString

M, V

SMS-RejectDuplicates

1023

Acision / ADMI

Enumerated

M, V

SMS-Replace-IfPresent

1024

Acision / ADMI

Enumerated

M, V

SMS-Reply-Path

1070

Acision / ADMI

Enumerated

M, V

SMS-Sched-DeliveryTime

1025

Acision / ADMI

Time

M, V

SMS-Service-CentreTime-Stamp

1071

Acision / ADMI

OctetString

M, V

SMS-Status

1072

Acision / ADMI

Unsigned32

M, V

SMS-Status-Report

1026

Acision / ADMI

Enumerated

M, V

SMS-Status-ReportIndication

1073

Acision / ADMI

Enumerated

M, V

SMS-Status-ReportQualifier

1074

Acision / ADMI

Enumerated

M, V

SMS-Time-Offset

63

Acision / SMS

Integer32

M, V

SMS-Time-Validity

51

Acision / SMS

Time

M, V

SMS-User-Data

1027

Acision / ADMI

OctetString

M, V

SMS-User-DataHeader-Indicator

1075

Acision / ADMI

Enumerated

M, V

SMS-Validity-Period

1076

Acision / ADMI

OctetString

M, V

SMS-Validity-PeriodFormat

1077

Acision / ADMI

Unsigned32

M, V

SMSC-Address

2017

3GPP TS 32.299

Address

M, V

Service-Type

1028

Acision / ADMI

Enumerated

M, V

Service-Info

1029

Acision / ADMI

Grouped

M, V

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

May
Encr.
Must
Not

Value Type

Shoul
d Not

Source/ Owner

May

AVP
Code

Must

AVP Name

Version: 1.0
Status: ISSUED
Page 23 of 67

AVP Flags

May
Encr.

SRI-SM

1078

Acision / ADMI

Grouped

M, V

Submission-Time

1202

3GPP TS 32.299

Time

M, V

TCAP-Segmented

1079

Acision / ADMI

Enumerated

M, V

Untranslated-Address

1030

Acision / ADMI

Grouped

M, V

Must
Not

Value Type

Shoul
d Not

Source/ Owner

May

AVP
Code

Must

AVP Name

The Source/ owner column refers to:


3GPP TS 29.061 refer to [3GPP-29.061],
3GPP TS 32.299 refer to [3GPP-32.299],
Acision / SMS refer to [Acision / SMS],
Acision / ADMI newly introduced AVP by this specification.

3.2 Address Formats


Address handling in SMS has some rules when the optional AVPs SMS-Address-TON
and/or SMS-Address-NPI have specific values within the Originating-Identity or DestinationIdentity AVPs. Address-Type values:
MSISDN used International number as the default TON (Address-Data expected in
the corresponding format).
Numeric Short Code used Abbreviated number as the default TON (Address-Data
expected in the corresponding format).
Alphanumeric Short Code used Alphanumeric as the default TON (Address-Data
expected in the corresponding format).
Any other value in Msg-Iface-Request and Mobile-Application-Request is unsupported.
When SMS-Address-TON, SMS-Address-NPI are provided, they should be compliant with
the Address-Type value. In case there are multiple AVPs Recipient-Address or OriginatorAddress then the SMS-Address-TON, SMS-Address-NPI belongs to the address with
Address-Type set to MSISDN.

3.3 Arm-Future-Notification AVP


The Arm-Future-Notification AVP (AVP code 1000) is of type Enumerated and the supported
values are:
0

All / any

Pre-submission

Post-submission

Pre-delivery

Post-delivery

Using this AVP the application can indicate in which next Notification-Point a request should
be sent to it. When no further notification is required, then this AVP should be left out to
indicate this (i.e. there is no special value for none).
Note that the values for NFR/NFA are identical to the Notification-Point except for addition of
all/any for arming any subsequent notification point and omission of Subscriber status

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 24 of 67

change. Also note the given sequence of notification points in respect to the current
scenario (e.g. refer to SMS-Message-Mode for SMS).

3.4 Destination-Identity AVP


The Destination-Identity AVP (AVP code 1001) has the following ABNF grammar:
<Destination-Identity> ::= < AVP Header: 1001 >
* [ Recipient-Address ]
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Untranslated-Address ]
[ 3GPP-IMSI ]
[ Recipient-SCCP-Address ]
[ SMS-Network-Technology ]
[ SMS-Time-Offset ]
[ Location-Info ]
* [ AVP ]

It contains the destination/recipient identity/identities details in the corresponding form for the
given service/processing context.

3.5 GSM-TPDU AVP


The GSM-TPDU AVP (AVP code 1032) has the following ABNF grammar:
<GSM-TPDU> ::= <
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
* [

AVP Header: 1032 >


SMS-More-Msg-To-Send ]
SMS-Command-Data ]
SMS-Command-Type ]
Data-Coding-Scheme ]
SMS-Destination-Address ]
SMS-Discharge-Time ]
SMS-Failure-Cause ]
SMS-Loop-Prevention ]
SMS-Message-Number ]
SMS-Message-Reference ]
SMS-Message-Type-Indicator ]
SMS-Originating-Address ]
SMS-Parameter-Indicator ]
SM-Protocol-ID ]
SMS-Recipient-Address ]
SMS-Reject-Duplicates ]
SMS-Reply-Path ]
SMS-Service-Centre-Time-Stamp ]
SMS-Status ]
SMS-Status-Report-Indication ]
SMS-Status-Report-Qualifier ]
SMS-Status-Report ]
SMS-User-Data ]
SMS-User-Data-Header-Indicator ]
SMS-Validity-Period ]
SMS-Validity-Period-Format ]
AVP ]

This AVP caries the GSM 03.40 (see [03.40]) content of the abstracted MAP message.

3.6 ISDN-Address AVP


The ISDN-Address AVP (AVP code 1033) has the following ABNF grammar:
<ISDN-Address> ::= <
[
[
[

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

AVP Header: 1033 >


SMS-Address-TON ]
SMS-Address-NPI ]
Address-Data ]

Version: 1.0
Status: ISSUED
Page 25 of 67

* [ AVP ]

It is a generic AVP for address representation for various entities and is based on the
[03.40].

3.7 Location-Info AVP


The Location-Info AVP (AVP code 1002) has the following ABNF grammar:
<Location-Info> ::= <
[
[
[
* [

AVP Header: 1002 >


3GPP-User-Location-Info ]
SGSN-Address ]
MSC-Address ]
AVP ]

3.8 MA-OpCode AVP


The MA-OpCode AVP (AVP code 1034) is of type Enumerated with following values:
0

SMS-DELIVER

SMS-DELIVER-REPORT

SMS-STATUS-REPORT

SMS-COMMAND

SMS-SUBMIT

SMS-SUBMIT-REPORT

Note that it is intentional separate from the SMS-Message-Type AVP as it is expected to be


extended in the future in a different way than the other one.

3.9 MA-Originator AVP


The MA-Originator AVP (AVP code 1035) has the following ABNF grammar:
<MA-Originator> ::= <
[
[
[
[
* [

AVP Header: 1035 >


ISDN-Address ]
3GPP-IMSI ]
Network-Node-Address]
SGSN-Node-Address ]
AVP ]

This AVP contains the address of the originating entity.

3.10 MA-Recipient AVP


The MA-Recipient AVP (AVP code 1036) has the following ABNF grammar:
<MA-Recipient> ::= <
[
[
[
[
* [

AVP Header: 1036 >


ISDN-Address ]
3GPP-IMSI ]
Network-Node-Address]
SGSN-Node-Address ]
AVP ]

Similarly as MA-Originator contains the address of the receiving entity.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 26 of 67

3.11 MAP-ALERT-SC AVP


The MAP-ALERT-SC AVP (AVP code 1037) has the following ABNF grammar:
<MAP-ALERT-SC> ::= < AVP Header: 1037 >
[ ISDN-Address ]
* [ AVP ]

3.12 MAP-Cause-Of-Failure AVP


The MAP-Cause-Of-Failure AVP (AVP code 1038) is of type Unsigned32 and contains
additional failure information.

3.13 MAP-Data-Load AVP


The MAP-Data-Load AVP (AVP code 1080) is of type OctetString and contains the SM RP
UI.

3.14 MAP-Error-Code AVP


The MAP-Error-Code AVP (AVP code 1039) is of type Unsigned32 and contains the error
code of MAP operation.

3.15 Message-Reference AVP


The Message-Reference AVP (AVP code 1004) is of type OctetString.
Message-Reference is a unique identifier for the message within the context of the specific
operator. It is generated on receipt of the message from the network (first entry point of the
solution) and must be passed with the message for the lifetime of the message.

3.16 MO-FWSM AVP


The MO-FWSM AVP (AVP code 1040) has the following ABNF grammar:
<MO-FWSM> ::= <
[
[
[
* [

AVP Header: 1040 >


ISDN-Address ]
3GPP-IMSI ]
SC-Address ]
AVP ]

MO-FWSM carries information specific for the MAP MAP-MO-FORWARD-SHORTMESSAGE service.

3.17 MO-SC-Address AVP


The MO-SC-Address AVP (AVP code 1083) has the following ABNF grammar:
<MO-SC-Address> ::= < AVP Header: 1083 >
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Address-Data ]
* [ AVP ]

Address of the service centre for SM in the MO leg.

3.18 MSC-Address AVP


The MSC-Address AVP (AVP code 1003) is of type Address and should contain MSC
address. The encoding is the same as for Originator-SCCP-Address in [3GPP-32.299].

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 27 of 67

3.19 Msg-Content AVP


The Msg-Content AVP (AVP code 1005) has the following ABNF grammar:
<Msg-Content> ::= <
[
[
* [

AVP Header: 1005 >


SMS-Language ]
SMS-Message-Text ]
AVP ]

Msg-Content is used in the MIR command for submission of a new message. SMSLanguage is used as auxiliary information for the delivery component for more efficient
encoding.

3.20 MT-FWSM AVP


The MT-FWSM AVP (AVP code 1041) has the following ABNF grammar:
<MT-FWSM> ::= <
[
[
[
* [

AVP Header: 1041 >


SC-Address ]
3GPP-IMSI ]
SMS-More-Msg-To-Send ]
AVP ]

MT-FWSM carries information specific for the MAP MAP-MT-FORWARD-SHORTMESSAGE service.

3.21 MT-SC-Address AVP


The MT-SC-Address AVP (AVP code 1084) has the following ABNF grammar:
<MT-SC-Address> ::= < AVP Header: 1084 >
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Address-Data ]
* [ AVP ]

Address of the service centre for SM in the MT leg.

3.22 Network-Node-Address AVP


The Network-Node-Address AVP (AVP code 1042) has the following ABNF grammar:
<Network-Node-Address> ::= <
[
[
[
* [

AVP Header: 1042 >


SMS-Address-TON ]
SMS-Address-NPI ]
Address-Data ]
AVP ]

3.23 Notification-Point AVP


The Notification-Point AVP (AVP code 1006) is of type Enumerated and the values are:
1

Pre-submission

Post-submission

Pre-delivery

Post-delivery

100

Subscriber status change

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 28 of 67

This AVP defines the point in processing where the notification took place. Note the
significance of SMS-Message-Mode for the SMS related notifications points (intercepted /
store & forward mode). For service specific context please refer to section 0.

3.24 Opaque-Data AVP


The Opaque-Data AVP (AVP code 1007) is of type OctetString with maximal size of 32
octets. The message payload may contain an opaque field that is used to transfer
information with the message during its lifetime. This field is provided so that the endpoint
can populate additional information that is required when the message is received again.
The opaque data field has no meaning for the Message Server and will only be passed with
the message.

3.25 Operation AVP


The Operation AVP (AVP code 1008) is of type Enumerated and the values are:
0

SM Submit

SM Deliver

100

SM location info single shot

101

SM location info with follow-up

SM Submit is used for submission of a new short message. Both originating and destination
identities have to be filled in together with at least basic message parameters (e.g. message
text). SM Deliver is similar to the SM Submit operation however it is guaranteed to be
executed in a transactional mode. I.e. the answer will be sent back with the outcome after
the delivery attempt.
SM location info single shot is used for querying subscribers approximate location.
Currently in successful answer a serving MSC address is returned. SM location info2 with
follow-up is similar to the single shot variant with the only distinction that when the subscriber
is not reachable we are requesting a follow-up information once the information is available.
The typical scenario would unsuccessful SM-SRI and later ALERT-SC (NRA with
Notification-Point = Subscriber status change in ADMI).

3.26 Originating-Identity AVP


The Originating-Identity AVP (AVP code 1009) has the following ABNF grammar:
<Originating-Identity> ::= < AVP Header: 1009 >
* [ Originator-Address ]
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Untranslated-Address ]
[ 3GPP-IMSI ]
[ Originator-SCCP-Address ]
[ SMS-Network-Technology ]
[ SMS-Time-Offset ]
[ Location-Info ]
* [ AVP ]

It contains the originating/sender identity/identities details in the corresponding form for the
given service/processing context.

Subject for specific Messaging Server deployment configuration in the operator network.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 29 of 67

3.27 Parent-Message-Reference AVP


The Parent-Message-Reference AVP (AVP code 1010) is of type OctetString. During
message processing there may be a case where a new message is created (this can be for
reasons such as auto-copy forward). The new message is assigned a new message
reference, but keeps also the message reference of the parent (original) message for
traceability. The message can have only a single parent message.

3.28 Recommended-Decision AVP


The Recommended-Decision AVP (AVP code 1011) is of type Enumerated and the values
are:
0

Proceed

Reject

Complete

Drop

The recommended decision type is used to communicate back to the originating endpoint
the decision of the Application Server on which course of action to take. This field is a
recommendation as the originating endpoint has ultimate control over the message
processing. The recommendation can be one of:
Proceed message is to be accepted for further processing / the default processing
should proceed according to the default scenario.
Reject message is to be rejected with the appropriate response sent back to the
originating party. The message will not be delivered. This could subsequently trigger
some retry / alternative processing.
Complete message has reached a successful final state and no further processing is
required. MCO should send positive notification to the originator. I.e. when a delivery
report was requested it will be generated and sent by the MCO. However the original
message is not delivered in this scenario.
Drop message is to be dropped from the system without notifying the originating party
of the message status. This is for the anti-spam and spoofing controls so that the
originator does not get any feedback or to prevent loops in the network when the
originator is spoofed and/or has invalid address. The MCO signalling should ensure that
no retry should take place afterwards (i.e. the message should be effectively silently
dropped).

3.29 Request-Data AVP


The Request-Data AVP (AVP code 1044) has the following ABNF grammar:
<Request-Data> ::= <
[
[
* [

AVP Header: 1044 >


MAP-Data-Load ]
GSM-TPDU ]
AVP ]

It represents the original message data in raw MAP and/or GSM decoded form.

3.30 Request-Counter AVP


The Request-Counter AVP (AVP code 1031) is of type Unsigned32 and its presence
indicates that a duplicate request check has been performed. Its values means how many
such (duplicate) requests has been detected so far including this one. I.e. the first one
(original) will have value 1.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 30 of 67

that the definition of a duplicate message depends on the configuration of the sending
Note
entity.

3.31 Response-Data AVP


The Response-Data AVP (AVP code 1045) has the following ABNF grammar:
<Response-Data> ::= <
[
[
* [

AVP Header: 1045 >


MAP-Data-Load ]
GSM-TPDU ]
AVP ]

It represents the modified message data in raw MAP and/or GSM decoded form.

3.32 SC-Address AVP


The SC-Address AVP (AVP code 1046) has the following ABNF grammar:
<SC-Address> ::= <
[
[
[
* [

AVP Header: 1046 >


SMS-Address-TON ]
SMS-Address-NPI ]
Address-Data ]
AVP ]

Address of the service centre.

3.33 SCCP-Destination-Address AVP


The SCCP-Destination-Address AVP (AVP code 1047) has the following ABNF grammar:
<SCCP-Destination-Address> ::= <
[
[
[
[
* [

AVP Header: 1047 >


SCCP-Routing-Indicator ]
SCCP-Signalling-Point-Code ]
SCCP-Subsystem-Number ]
SCCP-Global-Title ]
AVP ]

It represents SCCP address of the destination entity.

3.34 SCCP-Global-Title AVP


The SCCP-Global-Title AVP (AVP code 1049) has the following ABNF grammar:
<SCCP-Global-Title> ::= <
[
[
[
[
* [

AVP Header: 1049 >


SCCP-Nature-Of-Address-Indicator ]
SCCP-Numbering-Plan ]
SCCP-Translation-Type ]
SCCP-GT-Address ]
AVP ]

This AVP is based on [Q.713] and carries GT address within the SCCP address.

3.35 SCCP-GT-Address AVP


The SCCP-GT-Address AVP (AVP code 1048) is of type UTF8String and for its definition
refer to Global title address information in [Q.713].

3.36 SCCP-Nature-Of-Address-Indicator AVP


The SCCP-Nature-Of-Address-Indicator AVP (AVP code 1050) is of type Enumerated with
the following values:
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 31 of 67

Unknown

Subs number

National use

National

International

For its definition refer to Routing indicator as defined in [Q.713].

3.37 SCCP-Numbering-Plan AVP


The SCCP-Numbering-Plan AVP (AVP code 1051) is of type Enumerated with following
values:
0

Unknown

ISDN / telephony numbering plan

Generic numbering plan

Data numbering plan

Telex numbering plan

Maritime mobile numbering plan

Land mobile numbering plan

ISDN / mobile numbering plan

8..13

Spare

14

Private network or network-specific numbering plan

For its definition refer to Routing indicator as defined in [Q.713].

3.38 SCCP-Originator-Address AVP


The SCCP-Originator-Address AVP (AVP code 1052) has the following ABNF grammar:
<SCCP-Originator-Address> ::= <
[
[
[
[
* [

AVP Header: 1052 >


SCCP-Routing-Indicator ]
SCCP-Signalling-Point-Code ]
SCCP-Subsystem-Number ]
SCCP-Global-Title ]
AVP ]

It represents SCCP address of the originating entity.

3.39 SCCP-Responding-Address AVP


The SCCP-Responding-Address AVP (AVP code 1053) has the following ABNF grammar:
<SCCP-Responding-Address> ::= <
[
[
[
[
* [

AVP Header: 1053 >


SCCP-Routing-Indicator ]
SCCP-Signalling-Point-Code ]
SCCP-Subsystem-Number ]
SCCP-Global-Title ]
AVP ]

SCCP address used in the MAP response.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 32 of 67

3.40 SCCP-Routing-Indicator AVP


The SCCP-Routing-Indicator AVP (AVP code 1054) is of type Enumerated with following
values:
0

Route on GT

Route on SSN

For its definition refer to Routing indicator as defined in [Q.713].

3.41 SCCP-Signalling-Point-Code AVP


The SCCP-Signalling-Point-Code AVP (AVP code 1055) is of type Unsigned32 and for its
definition refer to [Q.713].

3.42 SCCP-Subsystem-Number AVP


The SCCP-Subsystem-Number AVP (AVP code 1056) is of type Unsigned32 and for its
definition refer to [Q.713].

3.43 SCCP-Translation-Type AVP


The SCCP-Translation-Type AVP (AVP code 1057) is of type Unsigned32 and for its
definition refer to TT in [Q.713].

3.44 Service-Type AVP


The Service-Type AVP (AVP code 1028) is of type Enumerated and the values are:
0

SMS

MMS

Email

This AVP specifies service type the request is associated with. Currently only SMS is
supported. When not applicable / in case of service agnostic requests the AVP is omitted
completely.

3.45 SGSN-Node-Address AVP


The SGSN-Node-Address AVP (AVP code 1058) has the following ABNF grammar:
<SGSN-Node-Address> ::= <
[
[
[
* [

AVP Header: 1058 >


SMS-Address-TON ]
SMS-Address-NPI ]
Address-Data ]
AVP ]

3.46 SMS-Command-Data AVP


The SMS-Command-Data AVP (AVP code 1061) is of type OctetString and for its definition
within the GSM context refer to TP-Command-Data as defined in [03.40].

3.47 SMS-Command-Type AVP


The SMS-Command-Type AVP (AVP code 1062) is of type Unsigned32 and for its definition
within the GSM context refer to TP-Command-Type as defined in [03.40].

3.48 SMS-Content-Info AVP


For definition of SMS-Content-Info refer to [Acision SMS] or Appendix B. Note that only the
three concatenated message related AVPs are used in ADMI.
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 33 of 67

SMS-Content-Info :: = <
[
[
[

AVP Header: 25 >


SMS-Content-CM-Segment ]
SMS-Content-CM-Total ]
SMS-Content-CM-Reference ]

This AVP contains sequencing details about the SM segment of a concatenated message.
Used only when the message reassembly is not performed.

3.49 SMS-Destination-Address AVP


The SMS-Destination-Address AVP (AVP code 1063) is of type OctetString and for its
definition within the GSM context refer to TP-Destination-Address as defined in [03.40].

3.50 SMS-Discharge-Time AVP


The SMS-Discharge-Time AVP (AVP code 1064) is of type OctetString and for its definition
within the GSM context refer to TP-Discharge-Time as defined in [03.40] (same format as
TP-SCTS).

3.51 SMS-Error-Code AVP


The SMS-Error-Code AVP (AVP code 1012) is of type Integer32. The AVP contains
outcome/status of the SM processing reusing the underlying IFX message status values:
0x0000

SUBMITTED

Submission process of a SM started

0x0001

REJECTED

SM was rejected

0x0002

ACCEPTED

SM was accepted for delivery

0x0003

BUFFERED

SM was buffered (S&F mode)

0x0004

DELIVERED

SM was successfully delivered

0x0005

NOT_DEL_TEMP

Unsuccessful delivery attempt, temporary error

0x0006

NOT_DEL_PERM

Unsuccessful delivery attempt, permanent error

0x0007

DELETED

SM was deleted (e.g. by SMPP cancel_sm)

0x0008

EXPIRED

SM validity period expired

3.52 SMS-Failure-Cause AVP


The SMS-Failure-Cause AVP (AVP code 1065) is of type Unsigned32 and for its definition
within the GSM context refer to TP-Failure-Cause as defined in [03.40].

3.53 SMS-Info AVP


The SMS-Info AVP (AVP code 1013) has the following ABNF grammar:
<SMS-Info> ::= <
[
[
[
[
[
[
[
[
[
[
[
[
[
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

AVP Header: 1013 >


SMS-Message-Mode ]
SMS-Message-Type ]
SMS-Priority ]
MO-SC-Address ]
MT-SC-Address ]
SM-Protocol-ID ]
Submission-Time ]
SMS-Time-Validity ]
SMS-Sched-Delivery-Time ]
SMS-Last-Delivery-Time ]
SMS-Content-Info ]
SMS-Replace-If-Present ]
SMS-Status-Report ]
Version: 1.0
Status: ISSUED
Page 34 of 67

[
[
[
[
[
[
* [

SMS-More-Msg-To-Send ]
SMS-Loop-Prevention ]
SMS-Reject-Duplicates]
Reply-Path-Requested ]
SMS-Error-Code ]
SMS-Payload ]
AVP ]

Contains additional SM details. Currently it is based on GSM standards. In the future when
support of other networks is added it may be extended with additional AVPs. When network
technology is important for further processing the SMS-Network-Technology AVP of
Originating-identity should be used to distinguish this.

3.54 SMS-Language AVP


The SMS-Language AVP (AVP code 1014) is of type UTF8String and language codes
according to ISO 639-2 are used. It contains the message language and helps mainly the
delivery component with selecting the most appropriate encoding. The list of supported
languages is subject to cooperating components specification.

3.55 SMS-Last-Delivery-Time AVP


The SMS-Last-Delivery-Time AVP (AVP code 1015) is of type Time. Contains the time of the
last delivery attempt.

3.56 SMS-Loop-Prevention AVP


The SMS-Loop-Prevention AVP (AVP code 1016) is of type Enumerated and the values are:
0

False/ disabled

True/ enabled

Please refer to definition of TP-Loop-Prevention in [03.40].

3.57 SMS-Message-Mode AVP


The SMS-Message-Mode AVP (AVP code 1017) is of type Enumerated and the values are:
1

Store and forward

MO routing / transaction

FSG/ homerouted

The modes mean:


Store and forward the Messaging Server does delivering (and store, retries).
Corresponds to the MO-MT scenario.
In the other modes the Messaging Server is not delivering the SM.
Note that the message mode may be also requested in the new SM submission scenario in
MIR. In that case only store and forward and transaction values are applicable.

3.58 SMS-Message-Number AVP


The SMS-Message-Number AVP (AVP code 1066) is of type Unsigned32 and for its
definition within the GSM context refer to TP-Message-Number as defined in [03.40].

3.59 SMS-Message-Reference AVP


The SMS-Message-Reference AVP (AVP code 1067) is of type Unsigned32 and for its
definition within the GSM context refer to TP-Message-Reference as defined in [03.40].
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 35 of 67

3.60 SMS-Message-Text AVP


The SMS-Message-Text AVP (AVP code 1018) is of type UTF8String. This AVP contains
decoded plain text of the message. Also used for message submission and other uses. This
is a message content abstraction.

3.61 SMS-Message-Type AVP


The SMS-Message-Type AVP (AVP code 1019) is of type Enumerated and the values are:
0

DELIVER

DELIVER REPORT

STATUS-REPORT

COMMAND

SUBMIT

SUBMIT-REPORT

Please refer to [03.40] for individual message types descriptions.

3.62 SMS-Message-Type-Indicator AVP


The SMS-Message-Type-Indicator AVP (AVP code 1082) is of type Unsigned32 and
specifies message type as defined in [03.40]. The GSM TP-MTI is stored in the least
significant byte.

3.63 SMS-More-Msg-To-Send AVP


The SMS-More-Msg-To-Send AVP (AVP code 1020) is of type Enumerated and the values
are:
0

More messages are waiting for the receiving entity in this Service Centre.

No more messages are waiting for the receiving entity in this Service Centre.

For the definition see TP-More-Messages-to-Send in [03.40].

3.64 SMS-Originating-Address AVP


The SMS-Originating-Address AVP (AVP code 1081) is of type OctetString and for its
definition within the GSM context refer to TP-Originating-Address as defined in [03.40].

3.65 SMS-Parameter-Indicator AVP


The SMS-Parameter-Indicator AVP (AVP code 1068) is of type Unsigned32 and for its
definition within the GSM context refer to TP-Parameter-Indicator as defined in [03.40].

3.66 SMS-Payload AVP


The SMS-Payload AVP (AVP code 1021) has the following ABNF grammar:
<SMS-Payload> ::= <
[
[
[
* [

AVP Header: 1021 >


Data-Coding-Scheme ]
SM-User-Data-Header ]
SMS-User-Data ]
AVP ]

It contains the message data as used by the underlying technology. For GSM (currently the
only one supported) it corresponds/is based on the TP-Data-Coding-Scheme, TP-User-DataHeader-Indicator and TP-User-Data as defined in [03.40].
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 36 of 67

3.67 SMS-Priority AVP


The SMS-Priority AVP (AVP code 1022) is of type Integer32 and defines the priority the
Message Server should use when processing. The supported range is:
1 highest priority,
1000 lowest priority.
Other values or when not used mean default priority.

3.68 SMS-Recipient-Address AVP


The SMS-Recipient-Address AVP (AVP code 1069) is of type OctetString and for its
definition within the GSM context refer to TP-Recipient-Address as defined in [03.40].

3.69 SMS-Reject-Duplicates AVP


The SMS-Reject-Duplicates AVP (AVP code 1023) is of type Enumerated and the values
are:
0

False/ disabled

True/ enabled

For the definition see TP-Reject-Duplicates in [03.40].

3.70 SMS-Replace-If-Present AVP


The SMS-Replace-if-present AVP (AVP code 1024) is of type Enumerated and the values
are:
0

False/ disabled

True/ enabled

For the definition please refer to replace_if_present_flag in [SMPP].

3.71 SMS-Reply-Path AVP


The SMS-Reply-Path AVP (AVP code 1070) is of type Enumerated with following values:
0

Reply path parameter is not set in this SMS-SUBMIT/DELIVER.

Reply path parameter is set in this SMS-SUBMIT/DELIVER.

For its definition within the GSM context refer to TP-Reply-Path as defined in [03.40].

3.72 SMS-Sched-Delivery-Time AVP


The SMS-Sched-Delivery-Time AVP (AVP code 1025) is of type Time and contains the
requested time of message delivery.

3.73 SMS-Service-Centre-Time-Stamp AVP


The SMS-Service-Centre-Time-Stamp AVP (AVP code 1071) is of type OctetString and for
its definition within the GSM context refer to TP-Service-Centre-Time-Stamp as defined in
[03.40].

3.74 SMS-Status AVP


The SMS-Status AVP (AVP code 1072) is of type Unsigned32 and for its definition within the
GSM context refer to TP-Status as defined in [03.40].

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 37 of 67

3.75 SMS-Status-Report AVP


The SMS-Status-Report AVP (AVP code 1026) is of type Enumerated and the values are:
0

False/ disabled

True/ enabled

Indication whether a status report was requested. For GSM corresponds to TP-StatusReport-Request from [03.40].

3.76 SMS-Status-Report-Indication AVP


The SMS-Status-Report-Indication AVP (AVP code 1073) is of type Enumerated with
following values:
0

A status report shall not be returned to the SME.

A status report shall be returned to the SME.

For its definition within the GSM context refer to TP-Status-Report-Indication as defined in
[03.40].

3.77 SMS-Status-Report-Qualifier AVP


The SMS-Status-Report-Qualifier AVP (AVP code 1074) is of type Enumerated with
following values:
0

SMS-STATUS-REPORT is the result of a SMS-SUBMIT.

SMS-STATUS-REPORT is the result of an SMS-COMMAND e.g. an Enquiry.

For its definition within the GSM context refer to TP-Status-Report-Qualifier as defined in
[03.40].

3.78 SMS-User-Data AVP


The SMS-User-Data AVP (AVP code 1027) is of type OctetString. It contains data from the
TP-User-Data from [03.40] which are expanded to 8bit and any leading UDH is removed
(this information is contained in SM-User-Data-Header AVP).

3.79 SMS-User-Data-Header-Indicator AVP


The SMS-User-Data-Header-Indicator AVP (AVP code 1075) is of type Enumerated with
following values:
0

User data field contains only the Short Message.

Beginning of the user data field contains a header in addition to the Short Message.

For its definition within the GSM context refer to TP-User-Data-Header-Indicator as defined
in [03.40].

3.80 SMS-Validity-Period AVP


The SMS-Validity-Period AVP (AVP code 1076) is of type OctetString and for its definition
within the GSM context refer to TP-Validity-Period as defined in [03.40].

3.81 SMS-Validity-Period-Format AVP


The SMS-Validity-Period-Format AVP (AVP code 1077) is of type Unsigned32 and for its
definition within the GSM context refer to TP-Validity-Period-Format as defined in [03.40].

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 38 of 67

3.82 Service-Info AVP


The Service-Info AVP (AVP code 1029) has the following ABNF grammar:
<Service-Info> ::= < AVP Header: 1029 >
[ SMS-Info ]
* [ AVP ]

This is a top level AVP containing/grouping the service information. Other services could
be added in the future.

3.83 SRI-SM AVP


The SRI-SM AVP (AVP code 1078) has the following ABNF grammar:
<SRI-SM> ::= <
[
[
[
* [

AVP Header: 1078 >


MA-Recipient ]
SC-Address ]
MA-Originator ]
AVP ]

SRI-SM carries information specific for the MAP MAP-SEND-ROUTING-INFO-FOR-SM


service.

3.84 TCAP-Segmented AVP


The TCAP-Segmented AVP (AVP code 1079) is of type Enumerated and the values are:
0

False

True

Indication whether the message is segmented on TCAP.

3.85 Untranslated-Address AVP


The Untranslated-Address AVP (AVP code 1030) has the following ABNF grammar:
<Untranslated-Address> ::= <
[
[
[
* [

AVP Header: 1030 >


SMS-Address-TON ]
SMS-Address-NPI ]
Address-Data ]
AVP ]

This AVP contains original / untranslated address as it was received, before any
normalization done by the MS.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 39 of 67

Mobile Messaging Principles in ADMI


Triggering Context
This chapter outlines general principles of mobile messaging and explains how the ADMI fits
into them.

4.1 SMS
The Messaging Server is integrated into the mobile operator mobile network and enables
SMS messaging service. The SMS processing within the mobile network is well defined by
the corresponding standard bodies (3GPP, TIA/EIA, etc.) that should be referred for the
details. However it is important to understand the context where Messaging Sever is
involved in the overall SMS service to relate that to the ADMI messaging.
The Messaging Server can be deployed in the mobile network as an SMSC or as an SMS
router. The exact deployment architecture should be irrelevant for the ADMI Application
Server. On the contrary it is important to realise different types of the SMS that are
processed by the Messaging Server in order to develop successful applications. The
following groups of messages can be distinguished based on its origin and destination:
Mobile Originated Messages (MO)
Messages originated by the mobile station (MS) and received by the messaging server
for routing, delivery, or storage
Mobile Terminated Messages (MT)
Messages destined for a mobile station originated by the messaging server.
Home routed Mobile Terminated Messages
Messages destined for a mobile station originated from the other operator network.
SMS Application Originated Messages (AO)
Messages originated by the SMS services application or SMS interconnect application
using traditional SMS application protocols such as SMPP.
SMS Application Terminated Messages (AT)
Messages destined to an SMS services application or SMS interconnect application using
traditional SMS application protocols such as SMPP.
The Messaging Server can be configured to handle any trajectory above that makes sense
and required my mobile operator, e.g. MO-MT, MO-MO, AO-MT, etc. The paragraphs below
will outline the message characteristics that can be exposed in the ADMI notifications
depending on the message type.
4.1.1 Mobile Originated Messages (MO)
The MO message is originated by the mobile station and delivered to the Messaging Server
via a Mobile Switching Centre, which is an addressable element within the mobile network.
Depending on the core network configuration or Messaging Server configuration, the MO
message can also contain the originator identity number (IMSI) in addition to the mobile
station address (MSISDN). Therefore originating identity of an MO message can have the
following parameters in the ADMI notification:
Originator-Address,
Originator-SCCP-Address,
3GPP-IMSI (optionally).
The following figure outlines the relation between the MO processing events and ADMI
notification points.
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 40 of 67

Messaging
Server

MSCO

Messaging
Application

MO-FWSM

Pre-submission
ADMI NFR
ADMI NFA

PROCEED, DROP, REJECT


MO-FWSM-CNF

Post-submission
ADMI NFR
ADMI NFA

Figure 4-1: MO Message Triggering


It is important to realise that Pre-submission notification point is after the MO message
reception and before the acknowledgement is sent to the network. The Post-submission
point is right after the MO acknowledgement is sent to the network. The actions that
Messaging Server has taken between these events are implementation/deployment specific.
4.1.2 Mobile Terminated Messages (MT)
The MT message is originated by the Messaging Server and destined towards the mobile
station. It represents a delivery attempt to the mobile network of an earlier accepted
message. The delivery procedure of the MT message includes interrogation with the HLR
that provides recipient identity information (IMSI) and MSC address where the message
should be delivered to in order to reach the recipient. Depending on the configuration of the
Messaging Server the following destination identity parameters can be present in the ADMI
notification:
Recipient-Address,
Recipient-SCCP-Address (optional),
3GPP-IMSI (optional).
The following figure illustrates the relation between the MT processing by the messaging
server and ADMI notification points.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 41 of 67

MSCO

Messaging
Server

Messaging
Application

Deliver MT

Pre-delivery
ADMI NFR
ADMI NFA
MT-FWSM

MT-FWSM-CNF

Post-delivery
ADMI NFR
ADMI NFA

Figure 4-2: MT Message Triggering


Please note that the triggers on the pre-delivery and post-delivery stages can be initiated
only when the application server has requested them in the Answer messages on the
previous stages during message acceptance.
4.1.3 Home-routed Mobile Terminated Messages (MT)
When the MT message is originated from the other operator network the Messaging Server
can be configured to perform the home routing3 procedure with the subsequent delivery of
the message toward the own subscriber. The figure below illustrates the relation between the
home routed MT delivery procedure in transparent mode and ADMI notifications.

Please refer for the details of the MT home routing procedures to 3GPP 23.040 and 3GPP 23.002 specifications.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 42 of 67

Other Operator
Foreign
SMSC

MSCO

Messaging
Server

Messaging
Application

MT-FWSM

Pre-submission
ADMI NFR
SMS-Message-Mode = homerouted
ADMI NFA

MT-FWSM

MT-FWSM-CNF

Post-delivery
ADMI NFR
ADMI NFA
MT-FWSM-CNF

Figure 4-3: Home Routed MT Message Triggering


As it is indicated on the figure for the home routed MT message the pre-submission trigger
point is applied. In order to distinguish between the MO message and home routed MT
message the Application Server should use the SMS-Message-Mode AVP. Please note that
the trigger post-delivery stages can be initiated only when the application server has
requested them in the Answer messages on the previous stage.
4.1.4 SMS Application Originated Messages (AO)
The AO message is initiated by the SMS application using standard peer to peer SMS
transfer protocol (e.g. SMPP) in scope of an existing session or a newly created session with
the Messaging Server. The session setup is protocol specific and should be considered
irrelevant for message triggering. The AO message originator identity can be have the
following parameters:
Originator-Address
An MSISDN identifying originator address specified in the message.
Originator-Address
An numeric short code or alphanumeric string identifying originating application.
The following figure outlines the relation between the AO processing events and ADMI
notification points.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 43 of 67

Messaging
Server

Messaging
Application

Submit-sm

Pre-submission
ADMI NFR
ADMI NFA

PROCEED, DROP, REJECT


Submit-sm-ack

Post-submission
ADMI NFR
ADMI NFA

Figure 4-4: AO Message Triggering


4.1.5 SMS Application Terminated Messages (AT)
The AT message is originated by the Messaging Server and destined towards the SMS
Application. It represents a delivery attempt to the SMS Application in scope of existing or a
newly created session with this application of an earlier accepted message. The session
setup is protocol specific and should be considered irrelevant for message triggering. The AT
message Destination identity can be have the following parameters:
Destination-Address
An MSISDN identifying recipient address specified in the message.
Destination-Address
An numeric short code or alphanumeric string identifying destination application.
The following figure outlines the relation between the AT processing events and ADMI
notification points.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 44 of 67

Messaging
Server

Messaging
Application

Deliver AT

Pre-delivery
ADMI NFR
ADMI NFA
Deliver-sm

Deliver-sm-ack

Post-delivery
ADMI NFR
ADMI NFA

Figure 4-5: AT Message Triggering


4.1.6 SM Notification Points
Note the significance of SMS-Message-Mode for the SMS related notifications points
(intercepted / store & forward mode). The individual points mean:
Pre-submission4 the message has been sent by the originator but not yet received by
the delivering entity (e.g. SMSC), no ACK has been sent yet to the originator. In this point
the application can change for example the destination identity address or message
content.
Post-submission the message has been sent and received by the delivering entity.
Pre-delivery the delivery entity is about to execute a delivery attempt of the message.
The application can still interrupt the delivery.
Post-delivery after the delivery attempt. The result of the delivery attempt is in the
notification request (SMS-Error-Code).
Subscriber status change notification that a status of the originating identity has
changed (see MIR Operation = SM location info with follow-up).
While SMS-Message-Mode AVP distinguish message processing trajectory that might be
significant for an Application Server.

Please note utilization of the pre-submission triggering point for the home-routed MT messages.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 45 of 67

Generic Comments
Following are some thoughts on further evolution of the protocol and various implementation
aspects.

5.1 Protocol Version Negotiation


The initial protocol specification does not address major extension of the interface beyond
addition of new (ideally optional) AVPs into existing commands. During initial investigation
we have identified 3 approaches:
5.1.1 New Applications
We could introduce major interface versions / revisions as new Diameter applications under
different application ids. The advantage is that this a standard approach with support for
negotiation in CER/CEA. The downside is that application id has to be globally unique and
officially requested/registered. For this reason we considered this option as not preferred.
5.1.2 Negotiation Using CER/CEA
Another approach is one of the recommendations in [3GPP TR 29.909] (section 5.4.5
Proposal 5). Specifically introduce following AVPs:
* [ Supported-Application-Variant ]
* [ Vendor-Specific-Application-Variant ]
The advantages are that we do not have to apply for a new application ID with every
interface change and the negotiation takes place during standard CER/CEA phase. However
there are 2 potential problems. It seems that this mechanism does not allow negotiating
versions of more than one application on one connection (in our case two Diameter
applications). Finally we are not sure how easily the currently used Diameter implementation
could be extended in this respect (add new AVPs to CER/CEA). Alternatively we could
introduce different AVPs to overcome the first issue. Note that this does not provide end to
end negotiation but only hop by hop.
5.1.3 Version Negotiation Commands
The last option is to introduce special (proprietary) commands for version negotiation. This is
similar to the first ADMI version definition Admi-Register-Request, Admi-Register-Answer.

5.2 Security
Future versions of ADMI will probably mandate that all ADMI implementations support
IPSEC and TLS in the extent described in [BASEDIA].

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 46 of 67

Appendix A. Commands
In this appendix we summarise content of the individual commands in respect to the
currently supported functionality. Following indication is used:
M mandatory/ used in this context. Note that the word mandatory within this appendix
is a loose term (in contrast to formally defined term within Diameter standards),
O optional / conditional,
(empty) not supported/ used.
Note that this summary is only generic and in specific solution will be exactly specified what
is provided / supported at what time (individual solutions will use additional filtering / limiting
of functionality).

A.1 Notif-Request (NFR) Command content versus Notification-Point


Note that MO-SC-Address and MT-SC-Address AVPs are not expanded for better
readability.
Table A-1: Notif-Request (NFR) Command Content Versus Notification-Point
AVP

Presubm.

Postsubm.

Predeliv.

Post.deliv.

Sub.
Change

{ Service-Type }

{ Notification-Point }

*[ Originating-Identity ]

*[ Originator-Address ]

[ Address-Type ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Untranslated-Address ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ 3GPP-IMSI ]

[ Originator-SCCP-Address ]

[ SMS-Network-Technology ]

[ SMS-Time-Offset ]

[ Location-Info ]

[ Address-Domain ]
[ Domain-Name ]
[ 3GPP-IMSI-MCC-MNC ]

[ 3GPP-User-Location-Info ]
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 47 of 67

AVP

Presubm.

Postsubm.

Predeliv.

Post.deliv.

[ SGSN-Address ]

[ MSC-Address ]

[ Address-Type ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Untranslated-Address ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ 3GPP-IMSI ]

[ Recipient-SCCP-Address ]

[ SMS-Network-Technology ]

[ SMS-Time-Offset ]

[ Location-Info ]

[ SGSN-Address ]

[ MSC-Address ]

[ Message-Reference ]

[ Parent-Message-Reference ]

[ Msg-Content ]

[ SMS-Language ]

[ SMS-Message-Text ]

[ Service-Info ]

[ SMS-Info ]

[ SMS-Message-Mode ]

[ SMS-Message-Type ]

[ SMS-Priority ]

[ MO-SC-Address ]

*{ Destination-Identity }
*[ Recipient-Address ]

Sub.
Change

[ Address-Domain ]
[ Domain-Name ]
[ 3GPP-IMSI-MCC-MNC ]
[ Addressee-Type ]

[ 3GPP-User-Location-Info ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 48 of 67

AVP

Presubm.
[ MT-SC-Address ]

Postsubm.

Predeliv.

Post.deliv.

[ SM-Protocol-ID ]

[ Submission-Time ]

[ SMS-Time-Validity ]

[ SMS-Sched-Delivery-Time ]

[ SMS-Last-Delivery-Time ]
[ SMS-Content-Info ]

[ SMS-Content-CM-Segment ]

[ SMS-Content-CM-Total ]

[ SMS-Content-CM-Reference ]

[ SMS-Status-Report ]

[ SMS-More-Msg-To-Send ]

[ SMS-Loop-Prevention ]

[ SMS-Reject-Duplicates]

[ Reply-Path-Requested ]

Sub.
Change

[ SMS-Replace-if-present ]

[ SMS-Error-Code ]
[ SMS-Payload ]

[ Data-Coding-Scheme ]

[ SM-User-Data-Header ]

[ SMS-User-Data ]

[ Opaque-Data ]

[ Request-Counter ]

A.2 Notif-Answer (NFA) Command content versus Notification-Point


Note that MO-SC-Address and MT-SC-Address AVPs are not expanded for better
readability.
Table A-2: Notif-Answer (NFA) Command content versus Notification-Point
AVP

Presubm.

Postsubm.

Predeliv.

Post.deliv.

Sub.
change

{ Result-Code }

{ Recommended-Decision }

[ Arm-Future-Notification ]

*[ Destination-Identity ]

*[ Recipient-Address ]

[ Address-Type ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 49 of 67

AVP

Presubm.

Postsubm.

Predeliv.

Post.deliv.

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ SMS-Language ]

[ SMS-Message-Text ]

[ Address-Data ]

Sub.
change

[ Address-Domain ]
[ Domain-Name ]
[ 3GPP-IMSI-MCC-MNC ]
[ Addressee-Type ]

[ Untranslated-Address ]
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Address-Data ]
[ 3GPP-IMSI ]
[ Recipient-SCCP-Address ]
[ SMS-Network-Technology ]
[ SMS-Time-Offset ]
[ Location-Info ]
[ 3GPP-User-Location-Info ]
[ SGSN-Address ]
[ MSC-Address ]
[ Msg-Content ]

[ Service-Info ]
[ SMS-Info ]
[ SMS-Message-Mode ]

[ SMS-Message-Type ]
[ SMS-Priority ]

M
O

[ SMS-Time-Validity ]

[ SMS-Sched-Delivery-Time ]

[ MO-SC-Address ]
[ MT-SC-Address ]
[ SM-Protocol-ID ]
[ Submission-Time ]

[ SMS-Last-Delivery-Time ]
[ SMS-Content-Info ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 50 of 67

AVP

Presubm.
[ SMS-Content-CM-Segment ]

Postsubm.

Predeliv.

Post.deliv.

Sub.
change

[ SMS-Content-CM-Total ]
[ SMS-Content-CM-Reference ]
[ SMS-Replace-if-present ]
[ SMS-Status-Report ]

[ SMS-More-Msg-To-Send ]
[ SMS-Loop-Prevention ]
[ SMS-Reject-Duplicates]

[ Reply-Path-Requested ]

[ SMS-Error-Code ]

[ SMS-Payload ]

[ Data-Coding-Scheme ]

[ SM-User-Data-Header ]

[ SMS-User-Data ]

[ Opaque-Data ]

A.3 Msg-Iface-Request (MIR) Command content versus Operation


Table A-3: Msg-Iface-Request (MIR) Command Content Versus Operation
AVP

SM
submit

SM
deliver

SM
location
info
single shot

SM
location
info with
follow-up

{ Operation }

*[ Originating-Identity }

[ Address-Type ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

*[ Originator-Address ]

[ Address-Domain ]
[ Domain-Name ]
[ 3GPP-IMSI-MCC-MNC ]

[ Untranslated-Address ]
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Address-Data ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 51 of 67

AVP

SM
submit

SM
deliver

SM
location
info
single shot

*{ Destination-Identity }

*[Recipient-Address]

[ Address-Type ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Message-Reference ]

[ Parent-Message-Reference ]

[ Msg-Content ]

SM
location
info with
follow-up

[ 3GPP-IMSI ]
[ Originator-SCCP-Address ]
[ SMS-Network-Technology ]
[ SMS-Time-Offset ]
[ Location-Info ]
[ 3GPP-User-Location-Info ]
[ SGSN-Address ]
[ MSC-Address ]

[ Address-Domain ]
[ Domain-Name ]
[ 3GPP-IMSI-MCC-MNC ]
[ Addressee-Type ]

[ Untranslated-Address ]
[ SMS-Address-TON ]
[ SMS-Address-NPI ]
[ Address-Data ]
[ 3GPP-IMSI ]
[ Recipient-SCCP-Address ]
[ SMS-Network-Technology ]
[ SMS-Time-Offset ]
[ Location-Info ]
[ 3GPP-User-Location-Info ]
[ SGSN-Address ]
[ MSC-Address ]

[ SMS-Language ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 52 of 67

AVP

SM
submit

SM
deliver

[ Service-Info ]

[ SMS-Info ]

[ SMS-Message-Text ]

[ SMS-Message-Mode ]

[ SMS-Message-Type ]

[ SMS-Priority ]

[ SM-Protocol-ID ]

[ Submission-Time ]

[ SMS-Time-Validity ]

[ SMS-Sched-Delivery-Time ]

SM
location
info
single shot

SM
location
info with
follow-up

[ MO-SC-Address ]
[ MT-SC-Address ]

[ SMS-Last-Delivery-Time ]
[ SMS-Content-Info ]
[ SMS-Content-CM-Segment ]
[ SMS-Content-CM-Total ]
[ SMS-Content-CM-Reference ]
[ SMS-Replace-if-present ]

[ SMS-Status-Report ]

[ SMS-More-Msg-To-Send ]
[ SMS-Loop-Prevention ]

[ SMS-Reject-Duplicates]

[ Reply-Path-Requested ]

[ SMS-Error-Code ]
[ SMS-Payload ]
[ Data-Coding-Scheme ]
[ SM-User-Data-Header ]
[ SMS-User-Data ]

Note that SM location info with follow-up is not supported yet.

A.4 Msg-Iface-Answer (MIA) Command content versus Operation


Table A-4: Msg-Iface-Answer (MIA) Command Content Versus Operation

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 53 of 67

AVP

SM
submit

SM
deliver

[ Location-Info ]

SM
location
info
single shot

SM
location
info with
follow-up

[ 3GPP-User-Location-Info ]
[ SGSN-Address ]

[ MSC-Address ]

[ SMS-Error-Code ]

{ Result-Code}

A.5 Mobile-Application-Request (MAR) Command content


Note that GSM-TPDU AVP is not expanded for better readability.
Table A-5: Mobile-Application-Request (MAR) Command content

[ SMS-Network-Technology ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ 3GPP-IMSI ]

[ Network-Node-Address]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ SRI-SM ]
[MA-Recipient ]
[ ISDN-Address ]

[ SGSN-Node-Address ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

SMS-SUBMIT-REPORT

[ MA-OpCode ]

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER
SMS-STATUS-REPORT

Messaging
Interface
Application

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER-REPORT

Notification Application

SMS-DELIVER
SMS-STATUS-REPORT

AVP

Version: 1.0
Status: ISSUED
Page 54 of 67

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ 3GPP-IMSI ]

[ Network-Node-Address]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ SC-Address ]

[MA-Originator ]
[ ISDN-Address ]

[ SGSN-Node-Address ]

[ MO-FWSM ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ 3GPP-IMSI ]

[ SC-Address ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ ISDN-Address ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

SMS-DELIVER
SMS-STATUS-REPORT

Messaging
Interface
Application

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER-REPORT

SMS-DELIVER
SMS-STATUS-REPORT

SMS-SUBMIT-REPORT

Notification Application

SMS-SUBMIT
SMS-COMMAND

AVP

Version: 1.0
Status: ISSUED
Page 55 of 67

[ MT-FWSM ]

SMS-DELIVER
SMS-STATUS-REPORT

Messaging
Interface
Application

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER-REPORT

SMS-DELIVER
SMS-STATUS-REPORT

SMS-SUBMIT-REPORT

Notification Application

SMS-SUBMIT
SMS-COMMAND

AVP

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ 3GPP-IMSI ]

[ SMS-More-Msg-To-Send ]

[ SC-Address ]

[ Request-Data ]

[ MAP-Data-Load ]

[ GSM-TPDU ]

[ MAP-Data-Load ]

[ GSM-TPDU ]

[ SCCP-Routing-Indicator ]

[ SCCP-Signalling-Point-Code ]

[ SCCP-Subsystem-Number ]

[ SCCP-Global-Title ]

[ SCCP-Nature-Of-Address-Indicator ]

[ SCCP-Numbering-Plan ]

[ SCCP-Translation-Type ]

[ SCCP-GT-Address ]

[ SCCP-Originator-Address ]

[ SCCP-Routing-Indicator ]

[ SCCP-Signalling-Point-Code ]

[ SCCP-Subsystem-Number ]

[ SCCP-Global-Title ]

[ SCCP-Nature-Of-Address-Indicator ]

[ SCCP-Numbering-Plan ]

[ Response-Data ]

[ SCCP-Destination-Address ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 56 of 67

[ SCCP-Translation-Type ]

[ SCCP-GT-Address ]

[ SCCP-Responding-Address ]

[ SCCP-Routing-Indicator ]

[ SCCP-Signalling-Point-Code ]

[ SCCP-Subsystem-Number ]

[ SCCP-Global-Title ]

[ SCCP-Nature-Of-Address-Indicator ]

[ SCCP-Numbering-Plan ]

[ SCCP-Translation-Type ]

[ SCCP-GT-Address ]

[ MAP-Error-Code ]

[ MAP-Cause-Of-Failure ]

[ TCAP-Segmented ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

SMS-DELIVER
SMS-STATUS-REPORT

Messaging
Interface
Application

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER-REPORT

SMS-DELIVER
SMS-STATUS-REPORT

SMS-SUBMIT-REPORT

Notification Application

SMS-SUBMIT
SMS-COMMAND

AVP

Version: 1.0
Status: ISSUED
Page 57 of 67

A.6 Mobile-Application-Answer (MAA) Command content


Note that GSM-TPDU AVP is not expanded for better readability.
Table A-6: Mobile-Application-Answer (MAA) Command content

[ Recommended-Decision ]

[ Arm-Future-Notification ]

SMS-DELIVER
SMS-STATUS-REPORT

Messaging
Interface
Application

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER-REPORT

SMS-DELIVER
SMS-STATUS-REPORT

SMS-SUBMIT
SMS-COMMAND

AVP

SMS-SUBMIT-REPORT

Notification Application

[ SRI-SM ]

[ MA-Recipient ]

[ 3GPP-IMSI ]

[ Network-Node-Address]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ SGSN-Node-Address ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ MT-FWSM ]

[ SC-Address ]

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

[ Response-Data ]

[ MAP-Data-Load ]

[ GSM-TPDU ]

[ MAP-ALERT-SC ]
[ ISDN-Address ]

O
O
O

[ SMS-Address-TON ]

[ SMS-Address-NPI ]

[ Address-Data ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 58 of 67

SMS-DELIVER
SMS-STATUS-REPORT

[ SCCP-Routing-Indicator ]

[ SCCP-Signalling-Point-Code ]

[ SCCP-Subsystem-Number ]

[ SCCP-Global-Title ]

[ SCCP-Nature-Of-Address-Indicator ]

[ SCCP-Numbering-Plan ]

[ SCCP-Translation-Type ]

[ SCCP-GT-Address ]

[ MAP-Error-Code ]

[ MAP-Cause-Of-Failure ]

SMS-SUBMIT
SMS-COMMAND
[ SCCP-Responding-Address ]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

SMS-SUBMIT-REPORT

SMS-SUBMIT
SMS-COMMAND

SMS-DELIVER-REPORT

Messaging
Interface
Application

AVP

SMS-DELIVER
SMS-STATUS-REPORT

Notification Application

Version: 1.0
Status: ISSUED
Page 59 of 67

Appendix B. Acision / SM Excerpt


In this appendix we provide an excerpt of all the relevant information from the [Acision /
SMS] specification.

B.1 Acision Diameter Credit Control AVPs Rules


This section defines the Credit Control AVPs that are specific to Acision Credit Control
applications and that MAY be included in the Diameter Credit Control messages.
The Diameter AVP rules are defined in [BASEDIA], section 4. These AVP rules are observed
in AVPs defined in this section. Table 1 describes the Diameter AVPs defined in the Acision
Credit Control application, their AVP Code values, types, possible flag values, and whether
the AVP MAY be encrypted. The Diameter base [BASEDIA] specifies the AVP Flag rules for
AVPs in section 4.5.
Table B-1: Rules for relevant AVPs of Acision Credit Control for SMS
MAY
Encrypt

SMS-Content-CM-Reference

19

Unsigned32

M, P

SMS-Content-CM-Segment

20

Unsigned32

M, P

SMS-Content-CM-Total

22

Unsigned32

M, P

SMS-Content-Info

25

Grouped

M, P

SMS-Network-Technology

35

Enumerated

M, P

SMS-Network-Type

36

Enumerated

M, P

SMS-Time-Offset

63

Integer32

M, P

SMS-Time-Validity

51

Time

M, P

SMS Address-TON

67

UTF8String

M, P

SMS-Address-NPI

68

UTF8String

M, P

MUST
NOT

AVP Flag Rules


SHLD
NOT

Data Type

MAY

AVP
Code

MUST

Attribute Name

B.2 Semantics of Acision AVPs


Obviously, the Acision AVPs are vendor specific. Acision strictly adheres to the
recommended format, as defined in section 11 of [BASEDIA]. The vendor-ID that has to be
used in the AVP header of the Acision AVPs is Acisions assigned SMI Network
Management Private Enterprise Code as registered with IANA, which has the value 3830.
B.2.1
SMS-Address-TON AVP
The SMS-Address-TON AVP (Acision AVP code 67) is of type UTF8String and holds Type
Of Number (TON) associated with the address structure. It SHOULD contain the value as
contained in the protocol PDU related to the particular address. Its semantics are vendor and
protocol specific. It facilitates the possibility to tag addresses or further specify the detailed
interpretation of the address by the charging element. A single address MUST only be
associated with a single SMS-Address-TON.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 60 of 67

B.2.2
SMS-Address-NPI AVP
The SMS-Address-NPI AVP (Acision AVP code 68) is of type UTF8String and holds
Numbering Plan Identifier (NPI) associated with the address structure. It SHOULD contain
the value as contained in the protocol PDU related to the particular address. Its semantics
are vendor and protocol specific. It facilitates the possibility to tag addresses or further
specify the detailed interpretation of the address by the charging element. A single address
MUST only be associated with a single SMS-Address-NPI.
B.2.3
SMS-Content-CM-Reference AVP
The SMS-Content-CM-Reference AVP (Acision AVP code 19) is of type Unsigned32 and
contains the 8 bit or 16 bit reference number of this concatenated message (see
[3GPP23.040] 9.2.3.24).
B.2.4
SMS-Content-CM-Segment AVP
The SMS-Content-CM-Segment AVP (Acision AVP code 20) is of type Unsigned32 and
contains the sequence number of the segment for concatenated messages. Its value MUST
NOT exceed that of SMS-Content-CM-Total. For messages that are segmented by the
originator, the values for SMS-Content-CM-Segment MUST be in the range 1SMSContent-CM-Total. In case the Charging Node does the segmentation itself or reassembles
the concatenated message and chooses to transmit only a single Diameter transaction, then
SMS-Content-CM-Segment MUST be set to 0.
B.2.5
SMS-Content-CM-Total AVP
The SMS-Content-CM-Total AVP (Acision AVP code 22) is of type Unsigned32 and contains
total number of segments for this concatenated message.
B.2.6
SMS-Content-Info AVP
The SMS-Content-Info AVP (Acision AVP code 25) is of type Grouped. It contains
information about the content of the SM. It has the following ABNF grammar:
SMS-Content-Info ::= <
[
[
[
[
[
[
[
[
[
* [

AVP Header: 25 >


SMS-Content-Size ]
SMS-Content-DCS ]
SMS-Content-Billing-Info ]
SMS-Content-Data ]
SMS-Content-CM-Segment ]
SMS-Content-CM-Total ]
SMS-Content-CM-Reference ]
SMS-Content-CM-Size ]
SMS-Content-TeleService ]
SMS-Content-Class ]

B.2.7
SMS-Network-Technology AVP
The SMS-Network-Technology AVP (Acision AVP code 35) is of type Enumerated and
indicates the type of network associated with this address.
The values for this AVP are:
0

OTHER Used when the network technology is known but not listed here.

NMT Used when the network technology is NMT.

GSM Used when the network technology is GSM.

GPRS Used when the network technology is GPRS.

UMTS Used when the network technology is UMTS.

CDMA Used when the network technology is CDMA.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 61 of 67

TDMA Used when the network technology is TDMA.

IDEN Used when the network technology is iDEN.

PDC Used when the network technology is PDC.

GAIT Used when the network technology is GAIT.

B.2.8
SMS-Time-Offset AVP
The SMS-Time-Offset AVP (Acision AVP code 63) is of type Integer32 and holds time
difference between the local time of the originator or recipient and UTC in units of 15 min.
B.2.9
SMS-Time-Validity AVP
The SMS-Time-Validity AVP (Acision AVP code 51) is of type Time and holds the message
absolute validity time in UTC format.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 62 of 67

Abbreviations
3GPP
ABNF
ADMI
AO
ARPU
AS
AT
AVP
BNF
CEA
CER
FSG
GSM
IM
IMSI
IPSEC
ISDN
MAA
MAP
MAR
MIA
MIR
MMS
MO
MO-FWSM
MS
MSISDN
MT
MT-FWSM
MT-SRI
NFA
NFR
NPI
S&F
SC
SCCP
SCTP
SGSN
SM
SMS
SMSC
TCAP
TCP
ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

3rd Generation Partnership Project


Augmented BackusNaur Form
Acision Diameter Messaging Interface
Application originated
Average Revenue per user
Application Server
Application Terminated
Attribute-Value Pair
Backus-Naur Form
Capabilities-Exchange-Answer
Capabilities-Exchange-Request
Foreign Subscriber Gateway
Global System for Mobile Communications
Instant Messaging
International Mobile Subscriber Identity
Internet Protocol Security
Integrated Services Digital Network
Mobile-Application-Answer
Mobile Application Part
Mobile-Application-Request
Msg-Iface-Answer
Msg-Iface-Request
Multimedia Messaging Service
Mobile Originated
MO Forward Short Message
Messaging Server or Mobile Station
Mobile Station International ISDN Number
Mobile Terminated
MT Forward Short Message
MT Send Routing Info (for SM)
Notif-Answer
Notif-Request
Numbering Plan Identifier
Store and Forward
Service Centre
Signalling Connection Control Part
Stream Control Transmission Protocol
Serving GPRS Support Node
Short Message
Short Message Service
Short Message Service Centre
Transaction Capabilities Application Part
Transmission Control Protocol
Version: 1.0
Status: ISSUED
Page 63 of 67

TIA/EIA
TLS
TON
TPDU

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Telecommunications Industry Association / Electronic Industries


Alliance
Transport Layer Security
Type of Number
Transport Protocol Data Unit

Version: 1.0
Status: ISSUED
Page 64 of 67

Glossary
Application Server (AS)
Component of the Acision messaging platform or provided by an
external party that provides advanced business logic into processing
and delivery of messages by the Acision messaging platform.
Message
Unit of communication exchange between 2 subscribers, between
subscriber and application (in either direction) or between 2
application in the operator network processed and delivered by
Acision messaging platform. The possible types of message include,
but are not limited to the SMS, MMS, IMS, e-mail message.
Messaging Server (MS)
Component in the Acision messaging platform that plays role in the
processing and delivery of message between the originator and
recipient.
Non-transparent data Data that is understood both syntactically and semantically by the
Messaging Server.
Opaque data
Data that is understood syntactically but not semantically by the
Messaging Server. It is data that an AS may store in the Message
Server to support its service logic when the message is returned.

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

Version: 1.0
Status: ISSUED
Page 65 of 67

References
[03.40]
[3GPP-REC]
[3GPP-ID]
[3GPP23.040]

[3GPP-29.061]

[3GPP-32.299]
[Acision / SMS]

[BASEDIA]
[Q.713]

[TCP]

ADMI_Specification_1.0
Security: CONFIDENTIAL
Copyright Acision BV 2010

3GPP TS 23.040, Technical realization of the Short Message Service


(SMS) (Release 9)
"Diameter-based protocols usage and recommendations in 3GPP",
3GPP TR 29.909 V8.1.2, January 2009
"3GPP specific codes and identifiers", 3GPP TS 29.230 V8.6.0, June
2009
Technical realization of the Short Message Service (SMS), 3GPP
TS 23.040 v7.0.1, March 2007, http://www.3gpp.org/ftp/Specs/htmlinfo/23040.htm.
3GPP TS 29.061 V6.3.1 (2005-01), Interworking between the Public
Land Mobile Network (PLMN) supporting packet based services and
Packet Data Networks (PDN) (Release 6)
3GPP TS 32.299 V9.0.0 (2009-06), Telecommunication management;
Charging management; Diameter charging applications (Release 9)
SMS Product Suite, Acision Diameter Charging version 1.1, Interface
Specification
As this specification is not freely available an excerpt of relevant
information is provided in the appendix.
Calhoun, P. et al. Diameter Base Protocol, RFC 3588, September
2003
ITU-T Q.713 , SERIES Q: SWITCHING AND SIGNALLING
Specifications of Signalling System No. 7 Signalling Connection
Control Part (SCCP)
Postel, J. "Transmission Control Protocol", STD 7, RFC 793, January
1981.

Version: 1.0
Status: ISSUED
Page 66 of 67