What’s Here?
This page describes the full set of AerFrame™ APIs. A hands-on tutorial is available at Send/Receive SMS with AerFrame API.
Summary
AerFrame Short Message Service (SMS) APIs provide next-generation SMS messaging. AerFrame is designed for high performance and improved flexibility, allowing for fast and efficient data transmission to and from devices across the Aeris network.
Supported Operations
- Send MT-SMS
- Receive MT-SMS Delivery Notifications
- Receive MO-SMS
- Acknowledge MO-SMS Receipt
Features & Benefits
- The SMS API is based on the OMA-DM standard SMS API
- All AerFrame services are simple RESTful interfaces for rapid and simplified development
- All AerFrame services are securely protected by API keys under customer control
- The API for resetting network registration can be a powerful tool for resolving device connectivity issues
- The API for getting a local dial-able number allows customers to deploy devices securely with non-dial-able numbers but still reach them when needed
Sections
This topic is broadly divided in to the following sections:
- 1. API Overview
- 2. API Request, Headers and Parameters
- 3. Application Management Operations
- 4. Notification Channel Management Operations
- 5. Subscription Management Operations
- 6. SMS Request Operations
- 7. Network Service API Operations
- 8. LTE-M Shoulder Tap Operations
- 9. Service Policy Exception Codes
- 10. AerFrame Error Codes
1. API Overview
AerFrame includes the following set of APIs:
- SMS Messaging API – derived from OMA Restful Short Messaging API. The outbound (MT) SMS delivery info and inbound (MO) SMS are delivered to applications over Notification Channels.
- Notification Channel Management API – derived from OMA Notification Channel API. To receive MO SMS and delivery info for the MT SMS, applications must register themselves and setup a notification channel. All messages are delivered over Notification Channel. This version of AerFrame supports only the LongPoll Notification Channel.
- The Network Service API – provides access to operations like Clear Registration and Get Local Dialable Number.
2. API Request, Headers, and Parameters
- AerFrame APIs are available only over HTTPS.
- Each API access must include the appropriate API Key in the request URL as shown in examples. The parameter name is “apiKey”.
- All API must include Content-Type header with value application/json.
2.1 BASE URLS
The URL addresses for the production services are shown in Table 1, “AerFrame Base URLs”.
Base URL | Purpose |
---|---|
https://api.aerframe.aeris.com | AerFrame WebService: Submitting MT SMS Request
|
https://longpoll.aerframe.aeris.com | Longpoll Service:
|
Table 1: AerFrame Base URLs
2.2 API Client Authentication
AerFrame uses API Keys to authenticate clients and applications. Each request must include the API Key as a query parameter in the URL. The API Key uniquely identifies an account and provides the account context to the APIs. The Service Profile Name can then be used to further classify multiple applications belonging to an account.
There are two (2) sets of API keys:
- Account API Key – When an account is registered for the AerFrame API, it is assigned a unique API Key. This API key can be used to perform all operations except subscription management. Subscriptions belong to applications and are managed by applications.
- Application API Key – When an application is registered under an account, it is assigned a unique API Key. This API key can be used to perform all operations except application management.
API Key / Account ID: API Keys are unique and secret. They must be saved securely and should be shared with authorized users or apps only. To obtain your Account ID and API Key, refer to the Send/Receive SMS with AerFrame API section.
2.3 Open Mobile Alliance Specification for SMS APIs
The AerFrame service interface is derived from the Open Mobile Alliance (OMA) Specification for SMS APIs (OMA-TS-REST_NetAPI_ShortMessaging-V1_0-20130219-C.pdf). The OMA RESTful Network API for Short Messaging V1.0 is a re-publication of the ParlayREST ShortMessaging API V 1.1 [ParlayREST_SMS] and is part of the suite of OMA RESTful Network APIs. Additionally, the latest version (v1.2.3) of the GSMA OneAPI SMS API is a subset of the OMA SMS API and uses the same resource structure and datatypes as defined in the OMA API Specification.
3. Application Management Operations
- AerFrame APIs are available only over HTTPS
- Each API access must include the appropriate API Key in the request URL as shown in examples. The parameter name is “apiKey”
- All APIs must include Content-Type header with value application/json
Operation |
Request URI |
Description |
---|---|---|
POST |
registration/v2/{accountId}/applications |
Register a New Application. |
GET |
registration/v2/{accountId}/applications/{appId} |
Get Registered Application. |
GET |
registration/v2/{accountId}/applications/{appId} |
Get All Registered Applications. |
DELETE |
registration/v2/{accountId}/applications/{appId} |
De-Register an Application. |
Table 2: AerFrame API Operations
Name |
Presence |
Description |
---|---|---|
applicationName |
Mandatory |
A name that the client can use to identify the application. |
applicationTag |
Mandatory |
A tag that clients may use to tag this application. AerFrame stores it as it is without modifying and is not used in any way. |
description |
Mandatory |
A description about the application that the client can use to brief the application and what it is used for. |
apiKey |
Mandatory |
Generated by the AerFrame and provided in the response. This key is used for authentication in the queryParam of the request URL of all other AerFrame services. |
apiKeyLifetime |
Optional |
AerFrame ignores this property. An apiKey once created is valid for lifetime unless application is explicitly deleted. |
resourceUrl |
Mandatory |
Generated by the AerFrame service and included in the response. |
applicationShortName |
Mandatory |
The unique identifier of the application with in the given account. |
Table 3: AerFrame Application Attributes
Example Requests and Responses
Register a New Application
URL: https://api.aerframe.aeris.com/registration/v2/99999/applications?apiKey={{accountApiKey}}
Request
{
"applicationName": "My First App",
"description": "A sample AerFrame application",
"applicationShortName" : "afmyfirstapp",
"applicationTag": "aerframe"
}
Response
{
"applicationName": "My First App",
"applicationShortName": "afmyfirstapp",
"applicationTag": "aerframe",
"description": "A sample AerFrame application",
"apiKey": "7fc6f45e-cb3f-11e3-b659-4baeeacae71e",
"resourceURL": "https://api.aerframe.aeris.com/registration/v2/99999/applications/000055a0-124f-23de-6b56-0c8322d14b0c"
}
Get Registered Application
URL: https://api.aerframe.aeris.com/registration/v2/99999/applications/000055a0-124f-23de-6b56-0c8322d14b0c?apiKey={{accountApiKey}}
Note that this operation uses the application 'resourceURL' returned when the application is created. The 'appId' is the GUID at the end of that 'resourceURL'.
{
"applicationName": "My First App",
"applicationShortName": "afmyfirstapp",
"applicationTag": "aerframe",
"description": "A sample AerFrame application",
"apiKey": "7fc6f45e-cb3f-11e3-b659-4baeeacae71e",
"resourceURL": "https://api.aerframe.aeris.com/registration/v2/99999/applications/000055a0-124f-23de-6b56-0c8322d14b0c"
}
Get All Registered Applications
URL: https://api.aerframe.aeris.com/registration/v2/99999/applications?apiKey={{accountApiKey}}
{
"application": [
{
"applicationName": "My First App",
"applicationShortName": "afmyfirstapp",
"applicationTag": "aerframe",
"description": "A sample AerFrame application",
"apiKey": "7fc6f45e-cb3f-11e3-b659-4baeeacae71e",
"resourceURL": "https://api.aerframe.aeris.com/registration/v2/99999/applications/000055a0-124f-23de-6b56-0c8322d14b0c"
}
],
"resourceURL": "https://api.aerframe.aeris.com/registration/v2/99999/applications"
}
De-Register an Application
URL: DELETE https://api.aerframe.aeris.com/registration/v2/99999/applications/000055a0-124f-23de-6b56-0c8322d14b0c?apiKey={{accountApiKey}}
Note that this operation uses the application 'resourceURL' returned when the application is created or when information about the application is read via get operations. The 'appId' is the GUID at the end of that 'resourceURL'.
4. Notification Channel Management Operations
There are up to two (2) Notification Channels available per application, with up to ten (10) total Notification Channels available per account. Each message will live for seven (7) days in the Notification Channel.
Operation |
Request URI |
Description |
---|---|---|
POST |
notificationchannel/v2/{accountId}/channels |
Create New Notification Channel. |
GET |
notificationchannel/v2/{accountId}/channels/{channelId} |
Get a Notification Channel. |
GET |
notificationchannel/v2/{accountId}/channels |
Get All Notification Channels. |
DELETE |
notificationchannel/v2/{accountId}/channels/{channelId} |
Delete a Notification Channel. |
Table 4: Notification Channel Management Operations
Name |
Presence |
Description |
---|---|---|
clientCorrelator |
Optional |
A name that the client can use to identify the application. |
applicationTag |
Optional |
A tag that clients may use to tag this application. AerFrame stores it as it is without modifying and is not used in any way. |
channelType |
Mandatory |
A description about the application that the client can use to brief the application and what it is used for. |
channelData |
Mandatory |
Generated by the AerFrame and provided in the response. This key is used for authentication in the queryParam of the request URL of all other AerFrame services. |
channelLifetime |
Optional |
AerFrame ignores this property. An apiKey once created is valid for lifetime unless application is explicitly deleted. |
callbackUrl |
Mandatory |
Generated by the AerFrame service and included in the response. |
resourceUrl |
Mandatory |
The unique identifier of the application with in the given account. |
Table 5: AerFrame Notification Channel Attributes
Name |
Presence |
Description |
---|---|---|
channelURL |
Mandatory |
Generated by AerFrame and provided in the response for LongPoll channel type. |
maxNotifications |
Optional |
Defines the maximum number of notifications that may be delivered in a notification list. Default is 15. AerFrame will wait for these many notifications or 10 seconds whichever is earlier. Applications that need lower latency should explicitly set this value of a lower number. |
type |
Optional |
AerFrame only supports "nc:LongPollingData". |
Table 6: AerFrame Notification Channel Data
Example Requests and Responses
Create New Notification Channel
URL: POST https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels?apiKey={{accountApiKey}}
{
"applicationTag": "aerframe",
"channelData": {
"maxNotifications": "15",
"type": "nc:LongPollingData"
},
"channelType": "LongPolling"
}
{
"applicationTag": "aerframe",
"channelType": "LongPolling",
"channelData": {
"channelURL": "https://longpoll.aerframe.aeris.com/notificationchannel/v2/99999/longpoll/000058e8-b6d0-8550-328e-8dea70609d3a",
"maxNotifications": 15
},
"callbackURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"resourceURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a"
}
Get a Notification Channel
URL: GET https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a?apiKey={{accountApiKey}}
{
"applicationTag": "aerframe",
"channelType": "LongPolling",
"channelData": {
"channelURL": "https://longpoll.aerframe.aeris.com/notificationchannel/v2/99999/longpoll/000058e8-b6d0-8550-328e-8dea70609d3a",
"maxNotifications": 15
},
"callbackURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"resourceURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a"
}
Get All Notification Channels
URL: GET https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels?apiKey={{accountApiKey}}
{
"notificationChannel": [
{
"applicationTag": "aerframe",
"channelType": "LongPolling",
"channelData": {
"channelURL": "https://longpoll.aerframe.aeris.com/notificationchannel/v2/99999/longpoll/000058e8-b6d0-8550-328e-8dea70609d3a",
"maxNotifications": 15
},
"callbackURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"resourceURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a"
}
],
"resourceURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels"
}
Delete a Notification Channel
URL: DELETE https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a?apiKey={{accountApiKey}}
5. Subscription Management Operations
To get Inbound SMS and Outbound SMS delivery information, applications need to subscribe for notifications. If there is no corresponding subscription for inbound SMS messages they are held for seventy-two (72) hours with one (1) retry every twenty-four (24) hours to check if a valid subscription exist. After seventy-two (72) hours the messages are dropped. If there is no corresponding subscription for outbound SMS delivery info then they are dropped immediately.
Operation |
Request URI |
Description |
---|---|---|
POST |
smsmessaging/v2/{accountId}/outbound/{applicationShortName}/subscriptions |
Create New Outbound (MT) SMS Delivery Info Subscription. |
GET |
smsmessaging/v2/{accountId}/outbound/{applicationShortName}/subscriptions/{subscriptionId} |
Get a Specific Outbound Subscription |
GET |
smsmessaging/v2/{accountId}/outbound/{applicationShortName}/subscriptions |
Get All Outbound Subscriptions for a Given Profile. |
DELETE |
smsmessaging/v2/{accountId}/outbound/{applicationShortName}/subscriptions/{subscriptionId} |
Delete a Specific Outbound Subscription. |
POST |
smsmessaging/v2/{accountId}/inbound/subscriptions |
Create New Inbound (MO) SMS Subscription. |
GET |
smsmessaging/v2/{accountId}/inbound/subscriptions/{subscriptionId} |
Get a Specific Inbound Subscription. |
GET |
smsmessaging/v2/{accountId}/inbound/subscriptions |
Get All Inbound Subscriptions. |
DELETE |
smsmessaging/v2/{accountId}/inbound/subscriptions/{subscriptionId} |
Delete a Specific Inbound Subscription. |
Table 7: Subscription Management API Operations
Name |
Presence |
Description |
---|---|---|
callbackReference |
Mandatory |
Notification Endpoint. AeFrame provides LongPoll service to receive notifications. Hence, the only supported callbackReference is the AerFrame-provided LongPoll Notification Channel. The Client must first create a Notification Channel and pass the callback URL from the Notification Channel here. Push notifications will be supported in the future. |
filterCriteria |
Mandatory |
Must specify ServiceProfile names as "SP:sp1,sp2,sp3" or "SP:*" to subscribe for all service profiles under the account. |
clientCorrelator |
Optional |
A correlator that the client can use to tag subscription. Clients can use this to identify subscription and avoid duplicate subscriptions. AerFrame stores it as it is without modifying and is not used in any way. |
resourceURL |
Mandatory |
Generated by the AerFrame service and included in the response. The URL identifies the newly created resource. |
link |
Optional |
Not used by AerFrame. |
Table 8: AerFrame Outbound DeliveryInfoSubscription
Name |
Presence |
Description |
---|---|---|
callbackReference |
Mandatory |
Notification Endpoint. AeFrame provides LongPoll service to receive notifications. Hence, the only supported callbackReference is AerFrame-provided LongPoll Notification Channel. The Client must first create a notification channel and pass the callback URL from Notification Channel here. Push notifications will be supported in the future. |
destinationAddress |
Mandatory |
This is the applicationShortName that manages the subscription. AerFrame will use this only for Push Notification Service and ignores this for Long Polling. |
criteria |
Mandatory |
Must specify ServiceProfile names as "SP:sp1,sp2,sp3" or "SP:*" to subscribe for all service profiles under the account. |
clientCorrelator |
Optional |
A correlator that the client can use to tag the subscription. Clients can use this to identify subscriptions and avoid duplicate subscriptions. AerFrame stores it as it is without modifying. |
resourceURL |
Optional |
Generated by the AerFrame service and included in the response. The URL identifies the newly created resource. |
link |
Optional |
Not used by AerFrame. |
Table 9: AerFrame Inbound SMS Message Subscription
Name |
Type |
Presence |
Description |
---|---|---|---|
notifyURL |
URI |
Mandatory |
Notify Callback URL. |
callbackData |
String |
Optional |
This is passed back in each notification to the client application. Applications use it for correlation purposes. |
notificationFormat |
ENUM (XML, JSON) |
Optional |
AerFrame supports only JSON. |
Table 10: AerFrame Subscription CallbackReference
Example Requests and Responses
Create New Outbound (MT) SMS Delivery Info Subscription
URL: POST https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions?apiKey={{appApiKey}}
{
"callbackReference": {
"callbackData": "mt-delivery-callback1",
"notifyURL":
"https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback"
},
"filterCriteria": "SP:*"
}
Successful HTTP response = 201 (created)
{
"callbackReference": {
"notifyURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"callbackData": "mt-delivery-callback1",
"notificationFormat": "JSON"
},
"filterCriteria": "SP:*",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions/00004811-6d5b-99fb-2f14-2f5a7b31a85d",
"link": []
}
Get a Specific Outbound Subscription
URL: GET https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions/00004811-6d5b-99fb-2f14-2f5a7b31a85d?apiKey={{appApiKey}}
{
"callbackReference": {
"notifyURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"callbackData": "mt-delivery-callback1",
"notificationFormat": "JSON"
},
"filterCriteria": "SP:*",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions/00004811-6d5b-99fb-2f14-2f5a7b31a85d"
}
Get All Outbound Subscriptions for a Given Profile
URL: GET https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions?apiKey={{appApiKey}}
{
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions",
"deliveryReceiptSubscription": [
{
"callbackReference": {
"notifyURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"callbackData": "mt-delivery-callback1",
"notificationFormat": "JSON"
},
"filterCriteria": "SP:*",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions/00004811-6d5b-99fb-2f14-2f5a7b31a85d"
}
]
}
Delete a Specific Outbound Subscription
URL: DELETE https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions/00004811-6d5b-99fb-2f14-2f5a7b31a85d?apiKey={{appApiKey}}
Create New Inbound (MO) SMS Subscription
URL: POST https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions?apiKey={{appApiKey}}
{
"callbackReference": {
"callbackData": "mo-sms-sub1",
"notifyURL":
"https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback"
},
"criteria": "SP:*",
"destinationAddress": ["afmyfirstapp"]
}
{
"callbackReference": {
"notifyURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"callbackData": "mo-sms-sub1",
"notificationFormat": "JSON"
},
"destinationAddress": [
"afmyfirstapp"
],
"criteria": "SP:*",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions/000176cd-3b3d-ce8b-119d-15999d8ac8bf",
"link": []
}
Get a Specific Inbound Subscription
URL: GET https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions/000176cd-3b3d-ce8b-119d-15999d8ac8bf?apiKey={{appApiKey}}
{
"callbackReference": {
"notifyURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"callbackData": "mo-sms-sub1",
"notificationFormat": "JSON"
},
"destinationAddress": [
"afmyfirstapp"
],
"criteria": "SP:*",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions/000176cd-3b3d-ce8b-119d-15999d8ac8bf"
}
Get All Inbound Subscriptions
URL: GET https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions?apiKey={{appApiKey}}
{
"subscription": [
{
"callbackReference": {
"notifyURL": "https://api.aerframe.aeris.com/notificationchannel/v2/99999/channels/000058e8-b6d0-8550-328e-8dea70609d3a/callback",
"callbackData": "mo-sms-sub1",
"notificationFormat": "JSON"
},
"destinationAddress": [
"afmyfirstapp"
],
"criteria": "SP:*",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions/000176cd-3b3d-ce8b-119d-15999d8ac8bf"
}
],
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions"
}
Delete a Specific Inbound Subscription
URL: DELETE https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions/000176cd-3b3d-ce8b-119d-15999d8ac8bf?apiKey={{appApiKey}}
6. SMS Request Operations
Operation |
Request URI |
Description |
---|---|---|
POST |
/smsmessaging/v2/{accountId}/outbound/{applicationShortName}/requests |
Send Outbound (MT) SMS |
GET |
/notificationchannel/v2/{accountId}/longpoll/{channelId} |
Get Inbound SMS and Outbound SMS Delivery Info Notifications |
POST |
/smsmessaging/v2/{account}/acknowledgement |
Acknowledge Inbound SMS |
Table 11: AerFrame SMS Request API Operations
POST - Outbound Operations
Name |
Presence |
Description |
---|---|---|
address |
Mandatory |
Array of destination addresses to send SMS to. This version of AerFrame accepts IMSI. The array can contain up to 100 addresses. Note: If you are sending an SMS to an eSIM, you must first retrieve the IMSI of the active profile on the eSIM. To retrieve the IMSI, use the AerAdmin API: Single Operation - Get Device Details (Non-Structured Response), and specify the EID as the identifier. The response payload returns the ICCID, IMSI, and MSISDN of the active profile. |
senderAddress |
Mandatory |
Sender address represent the application to which return message or delivery info may be sent. It should match the applicationShortName in the URL. |
senderName |
Optional |
Not used by AerFrame. |
charging |
Optional |
Not used by AerFrame. |
receiptRequest |
Optional |
Not used by AerFrame. AerFrame uses subscription to deliver the delivery info. If a subscription exists for the serviceProfile then all delivery info will be delivered to the notification channel associated with subscription. |
outboundSMSTextMessage |
Choice |
Should be used when sending text messages. AerFrame uses 7-bit encoding when delivering text messages to device. One of outboundSMSTextMessage or outboundSMSBinaryMessage must be present. |
outboundSMSBinaryMessage |
Choice |
Should be used when sending binary messages. AerFrame uses 7-bit/8-bit encoding when delivering binary messages to device. One of outboundSMSTextMessage or outboundSMSBinaryMessage must be present. |
clientCorrelator |
Optional |
Not used by AerFrame. |
ttlInSeconds | Optional | Sets the relative validity period for this message request.
This is the number of seconds this outboundSMS will remain valid and periodic
retries will be done. Valid values are between 0 and 259200 seconds (72 hours). A
value of zero will use the carrier's default validity period for MT-SM for carrier
delivered MT-SM. If this parameter is omitted, then the AerFrame defaults are used
(30 seconds for carrier delivered MT-SM, 72 hours for Global SIM store and forward
service). Note that this parameter is only honored if the destination device is set for carrier-delivered MT-SM or a Global SIM device whose service code is configured for the store and forward service; otherwise, this parameter is ignored. Setting a large value of ttlInSeconds for a device that is offline will result in the final status (Delivered to Terminal or failed) notification not available until the ttlInSeconds period has elapsed. |
resourceURL |
Mandatory |
Generated by AerFrame and included in the response. |
link |
Optional |
Not used by AerFrame. |
deliveryInfoList |
Optional |
Not used by AerFrame. |
Table 12: AerFrame Outbound SMS Request Attributes
Name |
Presence |
Description |
---|---|---|
message |
Mandatory |
Short text message content. AerFrame does not accept empty messages. The message text can have characters in ASCII, some from ISO-8859-1, and Unicode characters. However, the characters supported in the GSM7 basic and extended characters (as defined in the 3GPP TS 23.038 standard) set gets delivered to the device. The characters that are not translatable into GSM7 are replaced by a space character. The maximum length of the message field content is 160 characters. NOTES: The GSM7 character set uses different values for some of the ASCII characters and translates the input ASCII characters to their GSM7 equivalent characters. Some GSM7 Extension characters are represented as two characters. While converting these extension characters, an <ESCAPE> character (value of 0x1b) is inserted before the actual GSM7 Extension character.Therefore, for each extension characters used in the message text, the maximum length of the message gets be reduced by one (since the <ESCAPE> character uses a character position). These Extension characters are:
|
Table 13: AerFrame Outbound SMS Text Message
Name |
Presence |
Description |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
message |
Mandatory |
Short binary message content. Base64 Encoded. AerFrame does not accept empty messages. | ||||||||||||
encodingScheme |
Mandatory |
"7-Bit" or "8-Bit" or "16-Bit". However, the values AerFrame accepts as encoding schemes don't map exactly to the values the mobile terminal receives:
Therefore, if you send the 16-Bit binary data to your devices (not having the Aeris Global SIM), the devices will see or receive the data coding as UCS-2. |
Table 14: Outbound SMS Binary Message
Example: Send Outbound (MT) SMS
URL: POST https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/requests?apiKey={{accountApiKey OR appApiKey}}
{
"address": [
"204111111111111"
],
"senderAddress": "af-app01",
"outboundSMSTextMessage": {
"message":"I am AerFrame 2.1"
},
"clientCorrelator":"123456",
"senderName":"ACME Inc."
}
{
"address": [
"204111111111111"
],
"senderAddress": "af-app01",
"senderName": "ACME Inc.",
"outboundSMSTextMessage": {
"message": "I am AerFrame 2.1"
},
"clientCorrelator": "123456",
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/requests/000178bc-1d1c-3b12-46e9-b9213369827e"
}
GET - Delivery Info Notifications
Name |
Presence |
Description |
---|---|---|
callbackData |
Optional |
Callback Data set in the inbound subscription is returned without modification. |
inboundSMSMessage |
Mandatory |
Inbound SMS Message received from device. |
Table 15: AerFrame Inbound SMS Message Notification
Name |
Presence |
Description |
---|---|---|
destinationAddress |
Mandatory |
Destination Address of the message from the device. |
senderAddress |
Mandatory |
IMSI of device sending SMS. |
serviceProfile |
Mandatory |
Service Profile of the device for which the message was received. |
message |
Mandatory |
SMS message as binary base 64 encoded message. AerFrame does not accept empty messages. The interpretation of the message after decoding from base64 depends on the value of the encodingScheme:
NOTE: The use of the Euro-Currency-sign ("€") should be avoided in 7-Bit MO-SM. There is no ISO-8859-1 character value for the Euro-Currency-sign. (The ISO-8859-1 standard was created before the Euro currency was created).
|
encodingScheme | Mandatory | "7-Bit" or "8-Bit" or "16-Bit". |
dateTime | Mandatory | Time the message was received from device. |
resourceURL | Optional | Placeholder to reference SMS message. Not used by AerFrame. |
link |
Optional |
Placeholder to reference related resources. Not used by AerFrame. |
messageId |
Mandatory |
AerFrame generated and assigned unique message id. |
Table 16: AerFrame Inbound SMS Message
Name |
Presence |
Description |
---|---|---|
callbackData |
Mandatory |
Callback Data set in the outbound SMS delivery info subscription is returned without modification, |
deliveryInfo |
Mandatory |
Outbound SMS delivery info. |
link |
Optional |
Placeholder to reference related resources. Not used by AerFrame. |
Table 17: AerFrame Delivery Info Notification
Name |
Presence |
Description |
|||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
address |
Mandatory |
Device identifier referred in OutboundSMSMessage. AerFrame uses IMSI. |
|||||||||||||||||||||
deliveryStatus |
Mandatory |
Defines the SMS delivery status, which can be one of following:
NOTE: A final status means that this is the final DeliveryInfo status for this particular message. An interim status indicates that additional DeliveryInfo status will be provided for this particular message later. |
|||||||||||||||||||||
description |
Optional |
More details about the status. |
|||||||||||||||||||||
link |
Mandatory |
Reference (Resource URL) to the send SMS request resource to which this deliveryInfo corresponds. |
Table 18: AerFrame Delivery Info
Example: Get Inbound SMS and Outbound SMS Delivery Info Notifications
URL: GET https://longpoll.aerframe.aeris.com/notificationchannel/v2/99999/longpoll/000058e8-b6d0-8550-328e-8dea70609d3a?apiKey={{accountApiKey OR appApiKey}}
If multiple threads or process longpoll same notification channel, then one of them will be aborted with HTTP Status 409 (conflict). This error should be caught and ignored.
{
"deliveryInfoNotification": [
{
"callbackData": "mt-delivery-callback",
"deliveryInfo": [
{
"address": "204111111111111",
"deliveryStatus": "DeliveryImpossible",
"link": [
{
"rel": "MTMessageRequest ResourceUrl",
"href": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/requests/00004811-6d5b-99fb-2f14-2f5a7b31a85d"
},
{
"rel": "MTDeliverySubscription ResourceUrl",
"href": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/outbound/afmyfirstapp/subscriptions/00000152-d8a9-76c7-2a5f-9e83a1173c6e"
}
]
}
]
}
],
"inboundSMSMessageNotification": [
{
"callbackData": "1234511",
"inboundSMSMessage": {
"destinationAddress": "4444444444",
"senderAddress": "204111111111111",
"message": "aGVsbG8gdGVzdA==",
"dateTime": "2014-04-29T18:13:45.391Z",
"link": [
{
"rel": "MOSubscription ResourceUrl",
"href": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/inbound/subscriptions/000176cd-3b3d-ce8b-119d-15999d8ac8bf"
}
],
"messageId": "20c036a2-4000-0000-0021-345029c6014e",
"encodingScheme": "7-Bit",
"serviceCode": "9999"
}
}
]
}
POST - Acknowledge Inbound
Name |
Presence |
Description |
---|---|---|
message |
Mandatory |
Array of AcknowledgeMessage. |
Table 19: AerFrame Acknowledge Message Request
Name |
Presence |
Description |
---|---|---|
message |
Mandatory |
Array of AcknowledgeMessage. |
Table 20: AerFrame Acknowledge Message Response
Name |
Presence |
Description |
---|---|---|
messageId |
Mandatory |
Message Id of the message to be acknowledged. |
messageType |
Mandatory |
Inbound or Outbound. |
serviceProfile |
Mandatory |
Service Profile of the device for which the message was received. |
success |
Mandatory |
true or false. Receipt Status of the message. Specifies whether the message was received/processed successfully by the application. |
acknowledged |
Mandatory |
Populated by AerFrame denoting the status of the acknowledgement of the message. |
Table 21: AerFrame Acknowledge Message
See also Send/Receive SMS with AerFrame API.
Example: Acknowledge Inbound SMS
URL: POST https://api.aerframe.aeris.com/smsmessaging/v2/99999/acknowledgement?apiKey={{accountApiKey OR appApiKey}}
{
"message": [
{
"messageId": "20c036a2-4000-0000-0021-345029c6014e",
"messageType": "Inbound",
"serviceCode": "9999",
"success": true
}
]
}
{
"message": [
{
"messageId": "20c036a2-4000-0000-0021-345029c6014e",
"messageType": "Inbound",
"serviceCode": "9999",
"success": true,
"acknowledged": true,
"retriesAttempted": 0,
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/acknowledgement/20c036a2-4000-0000-0021-345029c6014e"
}
],
"resourceURL": "https://api.aerframe.aeris.com/smsmessaging/v2/99999/acknowledgement"
}
7. Network Service API Operations
AerFrame Network Service API is a set of APIs to access core network features like Clear Registration, Get Local Dialable Number, and Get Network Location. The API for getting a local dialable number allows you to deploy devices securely with non-dialable numbers but still reach them when needed. The API for resetting network registration can be a powerful tool for resolving device connectivity issues.
Operation |
URI |
Description |
---|---|---|
DELETE |
/networkservices/v2/{accountId}/devices/ {deviceIdType}/{deviceId}/registration |
Clear Registration for a Device: Clears registration of device from the serving VLR and SGSN. DeviceIdType could be IMSI or MSISDN. DeviceId is the corresponding IMSI or MSISDN. The Cancel Location is sent on a "best effort" basis. If the device's location is not known, then a cancel location cannot be sent and the request is silently ignored. There is no result for a cancel location request. |
GET |
/networkservices/v2/{accountId}/devices/ {deviceIdType}/{deviceId}/localDialableNumber |
Get Local Dialable Number: Obtain a temporary local dialable number for the device. DeviceIdType could be IMSI or MSISDN. DeviceId is the corresponding IMSI or MSISDN. |
GET | /networkservices/v2/{accountId}/devices/ {deviceIdType}/{deviceId}/ networkLocation?apiKey=<apiKey> | Get Network Location of the Device: This API call fetches the
network-based location of a GSM, Fusion NA, Fusion Global, or Fusion Global HD
device. This API fetches information about the base station or the cell tower ID to
determine the device location where the device was recently connected or registered.
This API accepts the IMSI or MSISDN as DeviceIdType to identify the device. DeviceId
is the corresponding IMSI or MSISDN. This API accepts the unique API key that is
assigned to the customer account for authentication and authorization of the API
call. This API key can be retrieved from the AerPort Portal. This API returns the real-time information about the device network location.
NOTE:
|
Table 22: AerFrame Network Service API Operations
Name |
Presence |
Description |
---|---|---|
dialableNumber |
Mandatory |
Local dialable number that can be used to make MT Voice call. |
numberNOA |
Mandatory |
Nature of address of the returned dialable number. |
numberNP |
Mandatory |
Numbering plan of the returned dialable number. |
requestCompletedTimestamp |
Mandatory |
Timestamp in milliseconds when the request was completed by the network. |
validForSeconds |
Mandatory |
Approximate time in seconds for which the dialable number is valid. |
requestId |
Mandatory |
Reference to the request Id. Used internally by AerFrame. Can be used as reference in support tickets. |
Table 23: AerFrame Network Service API Local Dialable Number Response
Name |
Presence |
Description |
---|---|---|
responseType |
Mandatory |
Always returns as 'Cell ID' because this API is intended to retrieve the cell ID only. |
mcc |
Mandatory |
Defines the Mobile Country Code (MCC) to identify the country of the device location. For example, 404 and 405 represent India, 310, 311, 312, 313, 314 and 316 represent USA, and so on. |
mnc |
Mandatory |
Defines the Mobile Network Code (MNC) to identify the mobile operator in the MCC. See Cell Tower Locations below for additional details. See the Mobile Country Code list on Wikipedia for a quick reference. |
lac |
Mandatory |
Defines the Location Area Code (LAC) which is the unique identifier of the current location area. This LAC is a group of base stations that are used together to optimize signalling. |
cellId |
Mandatory |
Defines the unique identifier of the Base Transceiver Station (BTS) or sector of a BTS within a LAC. The Cell ID can be zero because it does not depend on the data returned from the last known switch. If the device is registered with switch A and then turned off and moved to another location or country and has not yet registered, then switch A is still the last known switch but the API returns no location because the device is no longer registered at that switch. To keep getting updated Cell ID, it is recommend that you execute the API on regular intervals to have updated information of the Cell ID. NOTE: If the Cell ID is zero for any reason, use the value of mcc, mnc, and lac fields to estimate the location (country and state) of the device. |
locationTimestamp |
Optional |
If not NULL or non-zero, then this is the timestamp when the location was received.This is non-NULL and non-zero if there is a location for this device. |
ageOfLocation | Optional |
Defines the age of location information in Minutes corresponding to how long ago the location information was retrieved from the network. Returns NULL or Zero if no location information is available. |
state | Optional |
Returns the CS state, which can be one of the following:
|
requestId | Mandatory |
Reference to the request Id. Used internally by AerFrame. Clients can use it as reference in support tickets. |
destinationType | Mandatory |
Returns the switch type CS (Circuit Switch) or PS (Packet Switch) to represent the location result. Since this API works only on CS (Circuit Switch), this field always return CS as its value. |
destinationTypeCode | Mandatory |
Returns 7 always to represent the destination type value, where 7 represents VLR (circuit switched PSI). |
Table 24: AerFrame Network Service API Location Response
Cell Tower Locations
Cell tower locations are composed of these elements:
- mcc: mobile country code
- mnc: mobile network code
- lac: location area code
- cellId: the unique identifier of the Base Transceiver Station (BTS) or sector of a BTS within a LAC
Running Get Network Location provides you with values for these elements. You can use these four values to look up the latitude and longitude coordinates of the tower using a tool such as Google Gelocation API or Mozilla Location Service data file. This information tells you the current geographic location of the device.
In the table below, note that mcc, mnc, lac, and cellId return integer values. In some cases, the returned value of mnc or cellId might be a one- or two-digit value like 6 or 10 that is missing one or two leading zeros. For example, the location returned could be mcc=310 and mnc=3. In this case, you would need to add leading zeros to the mnc to end up with 3 digits (310 003) when looking up the latitude and longitude coordinates.
Here are the rules for the workaround:
- Add 1 leading zero to a single-digit mnc.
- Add 1 leading zero to a two-digit mnc in the following cases:
310 010 311 030 334 060 404 045 310 011 311 040 334 070 405 034 310 012 311 050 334 080 708 030 310 013 311 070 334 090 708 040 310 016 311 080 338 020 714 020 310 020 311 090 338 050 722 010 310 030 312 010 342 050 722 020 310 032 312 040 344 030 722 070 310 033 312 090 346 050 732 020 310 040 316 010 352 030 310 050 316 011 352 050 310 070 334 010 360 050 310 080 334 020 365 010 310 090 334 030 366 020 311 010 334 040 366 050 311 020 334 050 ** 376 050
** There is one ambiguous case where adding a leading zero might not be correct. 334 050 is not the same as 334 50. Both are valid. If the device is in this region of Mexico, please be aware that this scenario is possible.
- Add 2 leading zeros to a one-digit mnc in the following cases:
310 003 346 006 708 002 750 001 310 004 350 000 732 001 311 000 708 001 732 002
Example Requests and Responses
Clear Registration for a Device
URL: DELETE https://api.aerframe.aeris.com/networkservices/v2/{accountId}/devices/imsi/204111211111259/registration?apiKey={{accountApiKey OR appApiKey}}
Get Local Dialable Number
URL: GET https://api.aerframe.aeris.com/networkservices/v2/{accountId}/devices/imsi/204043396000768/localDialableNumber?apiKey={{accountApiKey OR appApiKey}}
Response
{
"numberNoa": 16
"numberNp": 1
"reqCompletedTimestamp": 1394239535000
"validForSeconds": 30
"requestId": "00009c71-30b8-954d-00b3-ff39179e8d5a"
"dialableNumber": "19254350381"
}
Get Network Location of the Device
URL: GET https://api.aerframe.aeris.com/networkservices/v2/{accountId}/devices/imsi/204043396622367/networkLocation?apiKey={{accountApiKey OR appApiKey}}
Response
{
"responseType": "Cell ID",
"mcc": 404,
"mnc": 11,
"lac": 1013,
"cellId": 0,
"locationTimestamp": 1533581751.01775,
"ageOfLocation": 0,
"state": 0,
"requestId": "000ba911-dabf-b375-0a43-e1c55e5e4da7",
"destinationType": "CS",
"destinationTypeCode": 7
}
8. LTE-M Shoulder Tap Operations
This set of operations applies only to Fusion NA devices.
A challenge in communicating with battery-constrained devices that utilize power saving functions is to contact the device to trigger some action. This process is called a shoulder tap. In 2G/3G devices, a shoulder tap is typically done using SMS, which has a built-in service to store and forward the message. However, SMS is not always available in LTE and NB-IoT devices, which mostly support IP-based data connectivity only. The mobile nature of cellular devices, such as those that roam across serving gateway boundaries and different mobile network operators while the device is in a power-saving state, makes it difficult to deliver shoulder tap packets to the device in a reliable and cost-efficient manner. Additionally, the extended buffering of data at the serving gateway is not always guaranteed and is prone to resource constraints at the serving gateway.
The LTE-M Shoulder Tap APIs send a beacon of shoulder tap packets with a unique identifier to the device at a specified interval. The frequency of the shoulder tap beacon message is dynamically calculated to factor in the device’s listen window size between sleeps and wake-up duration time.
Notes:
- Access will be only via HTTPS.
- The version path segment should appear immediately after the endpoint.
- The base path for the following resources is
- https://{{hostname}}/shouldertap/v2/{{accountId}}
- where {{hostname}} is the AerFrame hostname (e.g., api.aerframe.aeris.com), and {{accountId}} is the account ID of the account of the customer making the request.
- Authentication is the same as for all existing AerFrame services. It is done using the standard customer account AerFrame API Key (placed in the header of the REST request) as is done for all other AerFrame operations.
- Shoulder taps sent using a customer’s API Key can only be sent to devices owned by that customer account.
- Shoulder taps can be sent individually or in a batch of up to 1000 devices.
- Payloads can be up to 140 bytes.
When a shoulder tap is sent to a device:
- To successfully receive a message, the device must be on, in awake mode, with receiver/listening software running.
- If the device is not listening, it will not receive messages.
- When the device comes online, the message arrives.
- The shoulder tap will not wake up the device. Rather, the shoulder tap will be repeated or scheduled for a time when the device will be listening.
Operation |
Request URI |
Description |
---|---|---|
POST |
/s-tap |
This API sends a batch of one or more shoulder tap messages. (This is the same interface to send one or many shoulder taps; the same IMSI device can appear multiple times in the array of messages in a batch.) If the same device is in the batch multiple times, each shoulder tap for that device is processed independently from the others. The parameter names starting with “batch” apply to the entire batch. If an individual shoulder tap does not specify a value for the corresponding parameter, the batch value will be used. The request will be rejected if a batch parameter is not specified and an individual required shoulder tap parameter is not specified. |
DELETE | /s-tap/{{type}}/{{reqId}} |
This API cancels a shoulder tap request. The type is one of:
If there is an error (not HTTP status 200), no response body is returned. For an individual shoulder tap cancellation (by request ID), the returned reqIdList has only a single element in a successful cancellation. There is no response body for HTTP status values >= 400. For cancellation by device ID, if there were no pending shoulder taps for that device, the HTTP status will be 404. |
Table 25: Shoulder Tap API Operations
Individual or Batch Operations
You can choose either a batch payload or an individual payload.
If you choose to send a payload to an individual device:
- Omit batchPayloadType, batchPayload, and batchExpires or set them to null.
- Specify message, idType, id, payloadType, payload, and expires.
- Optionally specify deliveryMechanism, deliveryPort, powerMode, powerSleepInterval, and powerAwakeInterval.
If you choose a send a payload to a batch of devices:
- Specify batchPayloadType, batchPayload, and batchExpires.
- Specify message, idType, and id.
- Omit payloadType, payload, and expires or set them to null.
- Optionally specify deliveryMechanism, deliveryPort, powerMode, powerSleepInterval, and powerAwakeInterval.
Timing a Shoulder Tap Operation
Once the request is submitted, the beacon is continually sent until the expiration. More specifically, the API sends a beacon of shoulder tap packets with a unique identifier to the device(s) at a specified interval until the shoulder tap expires or until the shoulder tap is cancelled.
When the request is submitted, the device(s) can be either asleep or awake. Because we do not know the start of the awake cycle of the device, we begin attempting to deliver the message immediately.
How often we attempt to deliver the payload is calculated from the powerAwakeInterval. powerAwakeInterval specifies the number of seconds that the device stays awake whenever it wakes up. We calculate half of the powerAwakeInterval as X and send the payload every X seconds from the time the request is submitted until the specified expiration time.
Note: powersleepinterval and powermode will be implemented in a future release.
The Contents of a Shoulder Tap Packet
A shoulder tap packet includes several pieces of information.
Field |
Size of Field |
Description |
Sample Value (hex) | Interpretation of Sample Value |
---|---|---|---|---|
STX | One byte | A literal STX character | 0x02 | |
Message Type | Two bytes | Denotes what protocol the remainder of the packet will follow in hex-ascii format. Always 0x3031 for UDP0. | 0x3031 | '01' (in ASCII) denotes UDP0 |
Sequence Number | Four bytes | Denotes the sequence number of the shoulder-tap in hex-ascii format. | 0x42323645 | 'b26e' (in ASCII) denotes sequence number 45,678 (in decimal) |
Payload Length | Two bytes | Denotes, in hex-ascii format, how many bytes the payload will be. | 0x3038 | '08' (in ASCII) denotes a payload of eight bytes |
Payload | Variable length | Binary data. | 0x48692c204d6f6d21 | 'Hi, Mom!' if interpreted as ASCII or UTF-8 |
ETX | One byte | A literal ETX character | 0x03 |
Table 26: Packet Contents
For the UDP0 protocol, the device receiving a shoulder-tap must construct the request ID by appending the device's IMSI, a dash, and the decimal representation of the sequence number of the shoulder-tap.
For example, if the device's IMSI is 123456789012345 and the (hex) value of the shoulder-tap's sequence number is 0x42323645, then the request ID is "123456789012345-45678". To convert the hex value 0x42323645, we first convert it to ASCII characters (B26E), and then convert those ASCII characters to decimal using base 16.
This request ID must be used to cancel the shoulder-tap via the DELETE API; otherwise, the Aeris AerFrame API will continue to deliver the shoulder-tap.
Name |
Presence |
Description |
---|---|---|
batchPayloadType | Optional | The parameter batchPayloadType must be either “ASCII” or “BASE64”. It is validated only if an individual message does not specify a payloadType and thus uses the batchPayloadType. batchPayloadType can be specified with or without batchPayload. |
batchPayload | Optional | This parameter specifies the payload for the batch. batchPayload can be specified with or without batchPayloadType. If batchPayloadType is not specified, each individual message in the batch must specify the payloadType. The contents of batchPayload are validated (for example, a valid base64 value if the payloadType is BASE64) only if an individual message does not specify a payload and thus uses the batchPayload. The maximum batchPayload length is 140 bytes. |
batchExpires | Optional | This parameter specifies the expiration for the batch in
seconds. It will be used as the expires value for a message if the message does not
specify an expires parameter. If the parameter is omitted, then a default of 72 hours is used. 72 hours is 259,200 seconds. |
message | Mandatory | The message parameter is an array of individual shoulder taps. If the message parameter is null or empty, the system rejects the entire batch. |
idType | Mandatory | The only support idType is "IMSI". If the idType parameter is not “IMSI”, the individual shoulder tap is rejected. |
id | Mandatory | The IMSI ID. |
payloadType | Optional |
payloadType is either “ASCII” or “BASE64”. It defines how the payload parameter is to be interpreted. If ASCII, then only printable ASCII characters (including space, CR, and LF) are in the payload. If BASE64, then the payload must be in BASE64 format (RFC4648). In either case, the payload is delivered in binary form in the UDP0 delivery mechanism. (BASE64 payloads are converted to binary, and ASCII payloads are passed through without conversion.) If payloadType is neither “ASCII” nor “BASE64”, the individual shoulder tap is rejected. If the payloadType is not present, then the batchPayloadType will be used. If both the payloadType and the batchPayloadType are not present and a payload is present, then the message will be rejected. If the payload is omitted or is an empty string, then the payloadType and batchPayloadType are not required. |
payload | Optional |
The payload parameter represents the payload for a particular shoulder tap. The maximum payload length is 140 bytes. If the payload is not present, then the batchPayload will be used. If the payload is not present (or is an empty string) and the batchPayload is not present (or is an empty string), then the shoulder tap will contain a zero length payload. |
expires | Optional |
Set the value of expires to 0 to make one attempt at a shoulder tap. If it is greater than zero, it represents the time in seconds from request submission to when it expires. If expires is less than zero, the individual shoulder tap is rejected. If the parameter is omitted, then a default of 72 hours is used. 72 hours is 259,200 seconds. If expires is greater than the maximum value (72 hours or 259,200 seconds), the shoulder tap message is rejected. |
deliveryMechanism | Optional |
The only supported delivery mechanism is “UDP0”. If the parameter is omitted, then “UDP0” is used as the default. If deliveryMechanism is not “UDP0”, the individual shoulder tap is rejected. |
deliveryPort | Optional |
If the optional deliveryPort parameter is omitted, then a value of 23747 is used as the default. If the deliveryPort parameter is present, it must be greater than or equal to 1025 and less than or equal to 65535. If deliveryPort is outside of that range, the individual shoulder tap is rejected. |
powerMode | Unused | This parameter is used to help with scheduling the shoulder tap. Must be either “PSM” or “eDRX”. Any other value causes the system to reject the individual shoulder tap. |
powerSleepInterval | Unused |
This parameter is used to help with scheduling the shoulder tap. The powerSleepInterval is the time in seconds that the device is asleep (not reachable). Its value depends on the powerMode:
If powerSleepInterval is specified, it must be greater than or equal to zero. If it is less than zero, the individual shoulder tap is rejected. |
powerAwakeInterval | Optional | This parameter is used to help with scheduling the shoulder
tap. The time in seconds that the device is awake: 3GPP Timer T3324 (the Active
Timer, in seconds). The mimimum value is 1. If the powerAwakeInterval field is specified for a message, it must be greater than zero. If it is less than or equal to zero, the individual shoulder tap is rejected. |
Table 27: POST /s-tap Request Parameter Descriptions
Batch Parameters
Note that the batch parameters are not validated for the batch as a whole. They are provided as a default only for individual messages in the batch if the message does not provide the parameter. The validations for the parameter values taken from the batch parameters are validated when each message request is processed. An invalid value for a batch parameter will not cause the batch to be rejected, but will cause each individual message that uses that value to be rejected.
A maximum of 1000 devices can be included in a batch.
The maximum message payload length is 140 bytes.
Payload Validations
- If both the payload and the batchPayload are not present, then the shoulder tap is considered to have a zero-length payload, which is allowed.
- If the payloadType (or batchPayloadType if payloadType is not present) is BASE64, then the payload is validated to be in BASE64 format; if that validation fails, this message is rejected.
- The maximum size of a payload is 140 bytes (140 ASCII characters, or 140-byte decoded binary payload if in BASE64); the message will be rejected if the payload is too large.
- If the payloadType is ASCII and the payload contains non-ASCII printable (including: space, tab, CR, LF) characters, the message will be rejected. If you need non-printing ASCII characters, or other character sets such as Unicode, encode them as a BASE64 payload.
Name |
Description |
---|---|
batchAcceptanceStatus | batchAcceptanceStatus is the status of the overall batch. Returns one of: "ALL_ACCEPTED" or "SOME_ACCEPTED" or "ALL_REJECTED". |
batchId | The batchId is an opaque and unique identifier for the batch. |
msgStat | msgStat is an array of individual statuses for each of the messages in the request batch, in the same order as the requests, so that the user can match the status of each message requested. |
idType | The idType is the same as the request parameter. |
id | The id is the same as the request parameter. |
reqId | reqId is an opaque identifier assigned to this message request. This is the identifier that you must use to cancel the request. |
deliveryMechanism | The deliveryMechanism is the same as the request parameter. |
timestamp | timestamp is the epoch time that the request was processed. Epoch time refers to the Unix-standard Epoch Time of the number of seconds since 1970.0101 UTC. |
attemptCount | attemptCount will be zero since there have not yet been any attempts made. |
lastAttemptTimestamp | lastAttemptTimestamp will be zero since there have not yet been any attempts made. |
msgStatus | msgStatus is the acceptance status of the individual request. The value can be either “accepted” or “rejected”. |
error | If the message is rejected, the error field will contain an appropriate error message. If the message is accepted, the error field will be a zero-length string. |
expires | The expires field is the same as the request parameter. |
expirationTime | expirationTime is an epoch time for when the message will expire. |
Table 28: POST /s-tap Response Parameter Descriptions
HTTP Status Code |
Condition |
---|---|
200 | Batch processed. Check the msgStat for the accepted/rejected status of individual messages. |
400 | Error in request; entire batch rejected. |
504 | Internal problem: an internal service did not respond before timeout. |
Table 29: POST /s-tap Response HTTP Status Codes
Name |
Description |
---|---|
reqIdList |
The response has a list of the reqIds that were cancelled. HTTP Status for any cancellation method:
HTTP Status for an individual request cancellation:
HTTP Status for a device ID shoulder tap cancellation:
|
Table 30: DELETE /s-tap/{{type}}/{{reqId}} Response Parameter Descriptions
Example Requests and Responses
Sample Layout of the POST Request
{
"batchPayloadType": "ASCII" or "BASE64",
"batchPayload": "xxxx",
"batchExpires": sss,
"message": [
{
"idType": "IMSI",
"id": "nnnn",
"payloadType": "ASCII" or "BASE64",
"payload": "xxxx",
"expires": sss,
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM" or "eDRX",
"powerSleepInterval": sss,
"powerAwakeInterval": sss
}
]
}
Example of an Individual Request
{
"message": [
{
"idType": "IMSI",
"id": {{s-tap-imsi}},
"payloadType": "ASCII",
"payload": "My Payload",
"expires": 0,
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 60
}
]
}
Example of a Batch Request that Sends the Same Message to All Devices
{
"batchPayloadType": "ASCII",
"batchPayload": "Hello World",
"batchExpires": 0,
"message": [
{
"idType": "IMSI",
"id": {{s-tap-imsi1}},
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 30
},{
"idType": "IMSI",
"id": {{s-tap-imsi2}},
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 60
},{
"idType": "IMSI",
"id": {{s-tap-imsi3}},
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 60
}
]
}
Example of a Batch Request that Sends the Same Message to All Devices Except Those that have Specified an Individual Payload
{
"batchPayloadType": "ASCII",
"batchPayload": "Hello World",
"batchExpires": 0,
"message": [
{
"idType": "IMSI",
"id": {{s-tap-imsi4}},
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 30
},{
"idType": "IMSI",
"id": {{s-tap-imsi5}},
"payloadType": "BASE64",
"payload": "Uy1UQVAgTUVTU0FHRSY/",
"expires": 600,
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 60
},{
"idType": "IMSI",
"id": {{s-tap-imsi6}},
"deliveryMechanism": "UDP0",
"deliveryPort": 23747,
"powerMode": "PSM",
"powerSleepInterval": 120,
"powerAwakeInterval": 60
}
]
}
Sample Layout of the POST Response
{
{
"batchAcceptanceStatus": "ALL_ACCEPTED" or "SOME_ACCEPTED" or "ALL_REJECTED",
"batchId": "xxx",
"msgStat": [
{
"idType": "xxx",
"id": "xxx",
"reqId": "xxx",
"deliveryMechanism": "xxx",
"timestamp": 123,
"attemptCount": 0,
"lastAttemptTimestamp": 0,
"msgStatus": "accepted" or "rejected",
"error": "error text",
"expires": 123,
"expirationTime": 123
}
]
}
Sample Layout of the DELETE Response
{
"reqIdList": [
"xxx"
]
}
For additional help, Aeris is providing a sample reference implementation in github.
https://github.com/aeristhings/aeris-modsdk-py
Additional information on the Udp0 shoulder-tap protocol is available here:
https://github.com/aeristhings/aeris-modsdk-py/wiki/Udp0-Shoulder-Tap
9. Service / Policy Exception Codes and Messages
- AerFrame 2.1 APIs use standard HTTP Status Codes to convey success or failure response
- API response content, if any, is of type application/json
This table describes the Request Errors schema:
Name |
Presence |
Description |
---|---|---|
Link |
Optional |
List of resources that are related to the error. Not used by AerFrame. |
serviceException |
Optional |
Captures AerFrame service and request validation exception (e.g. Device not found). Either serviceException or policyException will be present. |
policyException |
Optional |
Captures AerFrame policy/business rule violations. Either serviceException or policyException will be present. |
Table 31: AerFrame Request Errors
This table describes the Service / Policy Exceptions schema:
Name |
Presence |
Description |
---|---|---|
messageId |
Mandatory |
Error code (See section Service and Policy Exception Code for full list). |
text |
Mandatory |
Error text with variable placeholders. |
variables |
Optional |
List of values matching the number of placeholders in text. |
Table 32: AerFrame Service and Policy Exceptions
Sending a message to an invalid device id returns this response:
Service Exceptions
SVC0001 = A service error occurred. Error code is {0}.
SVC0002 = Invalid input value for message part {0}.
SVC0003 = Invalid input value for message part {0}, valid values are {1}.
SVC0004 = No valid addresses provided in message part {0}.
SVC0005 = Correlator {0} specified in message part {1} is a duplicate.
SVC0006 = Group {0} in message part {1} is not a valid group.
SVC0007 = Invalid charging information.
SVC0008 = Overlapped Criteria {0}.
SVC0280 = Message too long. Maximum length is {0} characters.
SVC0281 = Data format not recognized for message part {0}.
SVC0283 = Delivery Receipt Notification not supported.
SVC0400 = Failed to submit Clear Registration for {0}.
SVC0401 = Service Error: Failure code {0}, Failure Message {1}.
SVC0402 = Service timed out. Please try again.
SVC1000 = No resources.
SVC2000 = The following service error occurred: {0}. Error code is {1}.
Policy Exceptions
POL0001 = A policy error occurred. Error code is {0}.
POL0002 = Privacy verification failed for address {0}, request is refused.
POL0003 = Too many addresses specified in message part {0}.
POL0004 = Unlimited notification request not supported.
POL0005 = Too many notifications requested.
POL0006 = Group specified in message part {0} not allowed.
POL0007 = Nested group specified in message part {0} not allowed.
POL0008 = Charging is not supported.
POL0009 = Invalid frequency requested.
POL0010 = Requested information unavailable as the retention time interval has expired.
POL0011 = Media type not supported.
POL0012 = Too many description entries specified in message part {0}.
POL0013 = Duplicated addresses.
POL1009 = User has not been provisioned for {0}.
POL1010 = User has been suspended from {0}.
POL1016 = File size exceeds the limit {0}.
POL1019 = Binary SMS is not allowed.
POL1020 = MaxBatchSize exceeded. The maximum allowed maxBatchSize is {0}.
POL2000 = The following policy error occurred: {0}. Error code is {1}.
10. AerFrame Error Codes
Negative-value error codes are generated by the SMSC function and described in Table 33 below.
Positive-value error codes are generated by the Network and described in Table 34 below.
SMSC Error Codes
Value |
Error |
---|---|
-1 |
Gsmmap pack failed: Internal error (failure when building GSM MAP message; GSM MAP messages are the ones sent via SS7). |
-2 |
Gsmmap validation failed: Internal error (another failure related to GSM MAP messages). |
-3 |
Gsmmap submit failed: Internal error (when trying to send the GSM MAP message). |
-4 |
Gsmmap timeout: No response received from remote switch. |
-5 |
Gsmmap abort: An error was received. |
-6 |
Gsmmap reject: The request was rejected by the remote switch. |
-7 |
Gsmmap No Appropriate Stack Connection Available: Internal error. |
-8 |
Device is unreachable: The device does not respond at its last known location (serving switch). It may be offline. |
-9 |
Device location is unknown: The location (serving switch) of the device is unknown. It may have never registered or has been offline for a while. |
-10 |
RTTL expired: The Relative-Time-To-Live of the message expired before it could be delivered. |
Table 33: SMSC Error Codes
Network Error Codes
The Network Error Codes provided in this documentation are derived from 3GPP specification TS 24.008 (http://www.3gpp.org/DynaReport/24008.htm), Appendix H.
Please refer to the latest 3GPP specification for additional details and most up-to-date documentation.
Value |
Cause |
Description |
---|---|---|
1 |
unassigned (unallocated) number |
This cause indicates that the destination requested by the mobile station cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated). |
3 |
no route to destination |
This cause indicates that the called user cannot be reached because the network through which the call has been routed does not serve the destination desired. |
5 |
unidentified subscriber |
This cause indicates that the device hasn't registered properly on the network. |
6 |
channel unacceptable |
This cause indicates the channel most recently identified is not acceptable to the sending entity for use in this call. |
8 |
operator determined barring | This cause indicates that the MS has tried to access a service that the MS's network operator or service provider is not prepared to allow. |
16 |
normal call clearing | This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situations, the source of this cause is not the network. |
17 |
user busy |
This cause is used when the called user has indicated the inability to accept another call. It is noted that the user equipment is compatible with the call. |
18 |
no user responding |
This cause is used when a user does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated (defined by the expiry of either timer T303 or T310). |
19 |
user alerting, no answer |
This cause is used when a user has provided an alerting indication but has not provided a connect indication within a prescribed period of time. |
21 |
call rejected |
This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. |
22 | number changed | This cause is returned to a calling mobile station when the called party number indicated by the calling mobile station is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this capability, cause No. 1 "unassigned (unallocated) number" shall be used. |
24 | call rejected due to feature at the destination | This cause is returned when the call is rejected due to a feature at the destination, e.g. Anonymous Call Rejection. This cause is only generated by the network. This cause is not generated by the MS. |
25 | pre-emption | This cause is returned to the network when a mobile station clears an active call which is being pre-empted by another call with higher precedence. |
26 | non-selected user clearing | Not supported. Treated as cause no. 31. |
27 | destination out of order | This cause indicates that the destination indicated by the mobile station cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signalling message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure at the remote user, user equipment off-line, etc. |
28 | invalid number format (incomplete number) | This cause indicates that the called user cannot be reached because the called party number is not a valid format or is not complete. |
29 | facility rejected | This cause is returned when a facility requested by user can not be provided by the network. |
30 | response to STATUS ENQUIRY | This cause is included in STATUS messages if the message is sent in response to a STATUS ENQUIRY message. See also subclause 5.5.3. |
31 | normal, unspecified | This cause is used to report a normal event only when no other cause in the normal class applies. |
34 | no circuit/channel available | This cause indicates that there is no appropriate circuit/channel presently available to handle the call. |
38 | network out of order | This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; e.g., immediately re-attempting the call is not likely to be successful. |
41 | temporary failure | This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the mobile station may wish to try another call attempt almost immediately. |
42 | switching equipment congestion | This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic. |
43 | access information discarded | This cause indicates that the network could not deliver access information to the remote user as requested; i.e., a user-to-user information, low layer compatibility, high layer compatibility, or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic. |
44 | requested circuit/channel not available | This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface. |
47 | resource unavailable, unspecified | This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies. |
49 | quality of service unavailable | This cause indicates to the mobile station that the requested quality of service, as defined in ITU-T Recommendation X.213 144, cannot be provided. |
50 | Requested facility not subscribed | This cause indicates that the requested supplementary service could not be provided by the network because the user has no completed the necessary administrative arrangements with its supporting networks. |
55 | Incoming calls barred within the CUG | This cause indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls are not allowed within this CUG. |
57 | bearer capability not authorized | This cause indicates that the mobile station has requested a bearer capability which is implemented by the equipment which generated this cause but the mobile station is not authorized to use. |
58 | bearer capability not presently available | This cause indicates that the mobile station has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time. |
63 | service or option not available, unspecified | This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies. |
68 | ACM equal to or greater than ACMmax | This cause is used by the mobile to indicate that call clearing is due to ACM being greater than or equal to ACMmax. |
65 | bearer service not implemented | This cause indicates that the equipment sending this cause does not support the bearer capability requested. |
69 | Requested facility not implemented | This cause indicates that the equipment sending this cause does not support the requested supplementary service. |
70 | only restricted digital information bearer capability is available | This cause indicates that one equipment has requested an unrestricted bearer service, but that the equipment sending this cause only supports the restricted version of the requested bearer capability. |
79 | service or option not implemented, unspecified | This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies. |
81 | invalid transaction identifier value | This cause indicates that the equipment sending this cause has received a message with a transaction identifier which is not currently in use on the MS-network interface. |
87 | user not member of CUG | This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG. |
88 | incompatible destination | This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility, or other compatibility attributes (e.g., data rate) which cannot be accommodated. |
91 | invalid transit network selection | For further study. Treated as cause no. 95. |
95 | semantically incorrect message | This cause is used to report receipt of a message with semantically incorrect contents (see subclause 8.8). |
96 | invalid mandatory information | This cause indicates that the equipment sending this cause has received a message with a non-semantical mandatory IE error (see subclause 8.5). |
97 | message type non-existent or not implemented | This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined, or defined but not implemented by the equipment sending this cause. |
98 | message type not compatible with protocol state | This cause indicates that the equipment sending this cause has received a message not compatible with the protocol state (subclause 8.4). |
99 | information element non-existent or not implemented | This cause indicates that the equipment sending this cause has received a message which includes information elements not recognized because the information element identifier is not defined or it is defined but not implemented by the equipment sending the cause. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message. |
100 | conditional IE error | This cause indicates that the equipment sending this cause has received a message with conditional IE errors (see subclause 8.7.2). |
101 | message not compatible with protocol state | This cause indicates that a message has been received which is incompatible with the protocol state or that a STATUS message has been received indicating an incompatible call state. |
102 | recovery on timer expiry | This cause indicates that a procedure has been initiated by the expiry of a timer in association with 3GPP TS 24.008 error handling procedures. |
111 | protocol error, unspecified | This cause is used to report a protocol error event only when no other cause in the protocol error class applies. |
127 | interworking, unspecified | This cause indicates that there has been interworking with a network which does not provide causes for actions it takes; thus, the precise cause for a message which is being sent cannot be ascertained. |
Table 34: Network Error Codes
0 Comments