[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


SMS Interface Requirements

This section describes the interface requirements for the interaction between the Access Controller and Steel-Belted Radius Carrier's SMS module.

Overview

The Access Controller uses the RADIUS interface requirements described in this section to provision the temporary subscriber account and one-time password. The MSISDN of the subscriber's mobile device is the username for the temporary account. The one-time password is generated by the SMS module and is communicated to the user with an SMS message sent to the subscriber's mobile device.

After the temporary account and password have been provisioned, the Access Controller uses conventional RADIUS authentication and accounting procedures, as with any subscriber account, to manage the subscriber's connection to the Internet. For the typical Access-Request, the username is the MSISDN and the password is the one-time password assigned to the temporary account.

Access-Request

The provisioning Access-Request must have a username and a password in a specific format. The provisioning reply is always an Access-Reject. The Reply-Message attribute attached to the Access-Reject contains the actual provisioning status.

Username Format

The username must be in the form:

MSISDN@realm

The MSISDN is composed of an optional + character followed by 8 to 18 digits in ASCII format.

For example, the following lines are both valid usernames:

+8567872785@provider.com

8567872785@provider.com

Typically, the subscriber enters only the MSISDN into the Web page and the Access Controller itself adds the @realm section of the username.

Password Format

Only Password Authentication Protocol (PAP) passwords are accepted.

The password must be in the form:

SmsProvision_T:duration_L:language.

where:

SmsProvision is case-sensitive

duration specifies the maximum duration (in seconds) of the temporary account and its associated one-time password. The duration field must consist of ASCII digits. (Optional field.)

If duration is not specified, the default value is used. The default value is the value of DefaultAccntProvisionRequestSecs in the smsprov.aut field.

language is one of the two-character lowercase ASCII alphabetic language codes specified in ISO-639. (Optional field.)

If the language is not specified, the default value is used. The default value is the value of DefaultAccountProvisionRequestSeconds in the smsprov.aut field.

The following are examples of valid passwords:

SmsProvision_T:3600_L:en

SmsProvision_L:en_T:3600

SmsProvision

SmsProvision_L:mn

SmsProvision_T:7200

Access-Request

The Access-Reject is used for both successful and failed provisioning. (The Access-Accept message is not used during provisioning.)

The provisioning status is carried in the Reply-Message attribute of Access-Reject message. The Reply-Message carries an ASCII string as shown in Figure 21.


Figure 21: Example C Code Showing ASCII String in Reply-Message

Success String

Table 156 describes the success string text.



Table 156: smsmsg.gen [Language] Fields 
Text in Reply-Message
Description

0 - Successful

Indicates a successful provisioning (although sent in Access-Reject).


Failure Strings

Table 157 describes the failure string text.

Table 157: smsmsg.gen [Language] Fields 
Text in Reply-Message
Description

1024 - No route to home network

User's home operator could not be reached due to missing IMSI analysis or SS7 network configuration.

1025 - Non-existent Subscriber

MSISDN could not be solved to an existing subscriber.

1026 - Call barring on

User's outgoing calls are barred in HLR profile.

1031 - No service subscribed

The user does not subscribe WLAN service.

1050 - Authentication network error

Internal error in SMS module or MAP gateway.

2001 - SMS memory full

There's no free memory in user's mobile phone for short message.

2002 - Mobile terminal unreachable

User's mobile phone could not be reached for delivering a short message. Phone is out of coverage area or switched off.

2003 - Subscriber already provisioned

Maximum provisioning attempt limit reached for the subscriber; no short message is sent.


Interaction Examples

The following examples show the interaction between devices involved in the provisioning.

Example 1: Successful Provisioning When No Temporary Account Exists

In Example 1 (Figure 22), a user, who is not previously known in the system, is provisioned. The user has a postpaid subscription and has a service activated. A password is sent to the mobile device in an SMS message. The Web server displays the password dialog page.


Figure 22: Successful Provisioning When No Temporary Account Exists

Example 2: Failed Provisioning Due to Unknown MSISDN

In Example 2 (Figure 23), the user is trying to provision with a random phone number. The MSISDN entered by the user does not belong to a known subscriber. The customer is informed with the Internet that the phone number is not valid.


Figure 23: Failed Provisioning Due to Unknown MSISDN


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]