As per Relevance of the word provision, we have this rfc below:
Network Working Group R.
Request for Comments: 2604
Category: Informational June 1999
Wireless Device Configuration (OTASP/OTAPA) via
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
Wireless carriers today are faced with creating more
distribution channels, increasing customer satisfaction, while
improving margin and profitability. Industry trends are pushing
sale of handsets further into the retail channel. The cost
effort of provisioning handsets, activating users, and
handset parameters can be greatly reduced by using over-the-
activation mechanisms. A comprehensive and extensible means
over-the-air provisioning and handset parameter updating is required
One approach is to purchase EIA/TIA/IS-683A (Over-the-air
Provisioning of Mobile Stations in Spread Spectrum Systems
equipment. The cost of this has led carriers to seek
solutions. A very viable means for providing over-the-air (OTA
provisioning is to leverage the rollout of IS-707 data
equipment, which most carriers are in the process of deploying.
paper presents an approach to OTA provisioning that utilizes
deployment of IS-707 to deliver OTA provisioning and
upgrading
IS-707 data services makes available several methods of
over-the-air provisioning and parameter updating. A well thought-
approach utilizing Internet-based open standard mechanisms
provide an extensible platform for further carrier service offerings
enhanced interoperability among back-end services, and
independence
This paper describes a viable and attractive means to
OTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol
Gellens Informational [Page 1]
RFC 2604 OTASP/OTAPA via ACAP June 1999
Table of
1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Feature Descriptions . . . . . . . . . . . . . . . . . . . 6
2.1. OTASP Feature Description . . . . . . . . . . . . . . . 6
2.2. OTAPA Feature Description . . . . . . . . . . . . . . . 6
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Initial Provisioning Activity . . . . . . . . . . . . . 7
3.2. OTASP for Authorized Users . . . . . . . . . . . . . . . 8
3.3. OTAPA Activity . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . 9
4.2. OTASP Requirements . . . . . . . . . . . . . . . . . . . 9
4.3. OTAPA Requirements . . . . . . . . . . . . . . . . . . 10
4.4. Provisioning Server Requirements . . . . . . . . . . . . 10
4.5. Security Requirements . . . . . . . . . . . . . . . . . 11
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 11
5.1.1. Mobile Authentication and A-Key Generation . . . . . 12
5.1.2. Mobile Identification . . . . . . . . . . . . . . . 12
5.1.3. ACAP Server . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Overview of ACAP Structure . . . . . . . . . . . . 13
5.1.5. Data Organization and Capabilities . . . . . . . . . 13
5.1.5.1. Structure . . . . . . . . . . . . . . . . . . . 14
5.1.5.2. Conventions . . . . . . . . . . . . . . . . . . 15
5.1.6. Dataset . . . . . . . . . . . . . . . . . . . . . . 15
5.1.6.1. Entries and Attributes . . . . . . . . . . . . . 15
5.1.6.2. NAM Records . . . . . . . . . . . . . . . . . . 16
5.1.6.3. Server Roaming Lists . . . . . . . . . . . . . . 17
5.1.6.4. Requested-Data Record . . . . . . . . . . . . . 18
5.1.6.5. Sample Server Entry . . . . . . . . . . . . . . 18
5.1.7. Administrative Client . . . . . . . . . . . . . . . 19
5.1.8. Mobile Client . . . . . . . . . . . . . . . . . . . 20
5.2. WAP with ACAP . . . . . . . . . . . . . . . . . . . . . 22
5.3. Network-Resident vs. Configuration Data . . . . . . . . 23
5.4. Intellectual Property Issues . . . . . . . . . . . . . 23
6. Handset Protocol Suites . . . . . . . . . . . . . . . . . . 23
6.1. ACAP over TCP/IP . . . . . . . . . . . . . . . . . . . 23
7. IS-683A Compatibility . . . . . . . . . . . . . . . . . . . 24
7.1. OTASP Operations . . . . . . . . . . . . . . . . . . . 24
7.2. OTASP Call Flow . . . . . . . . . . . . . . . . . . . . 24
7.3. OTAPA Operations . . . . . . . . . . . . . . . . . . . 24
7.4. OTAPA Call Flow . . . . . . . . . . . . . . . . . . . . 25
8. Alternative Methods . . . . . . . . . . . . . . . . . . . . 25
8.1. IS-683A over TCP/IP . . . . . . . . . . . . . . . . . . 25
8.1.1. OTAF Server . . . . . . . . . . . . . . . . . . . . 25
8.1.2. Interface Application . . . . . . . . . . . . . . . 26
8.1.3. Protocol Handset Suite . . . . . . . . . . . . . . 26
Gellens Informational [Page 2]
RFC 2604 OTASP/OTAPA via ACAP June 1999
8.2. Browser-Based Forms . . . . . . . . . . . . . . . . . . 26
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 28
13. Author's Address . . . . . . . . . . . . . . . . . . . . 28
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 29
1.
Application Configuration Access Protocol (ACAP) -- An
protocol (RFC-2244) that provides remote storage and access
configuration and preference information
Activation -- A process in which a mobile station and network
programmed so that a mobile station becomes operable and can be
for cellular service once authorized by the service provider
Authentication -- A procedure used to validate a mobile station'
identity
Authentication Center -- An entity that manages the
information related to the mobile station
Authentication Key (A-key) -- A secret 64-bit pattern stored in
mobile station. It is used to generate and update the
station's shared secret data. The A-key is used in
authentication process
Authorization -- An action by a service provider to make
service available to a subscriber
Call -- A temporary communication between telecommunications
for the purpose of exchanging information. A call includes
sequence of events that allocates and assigns resources
signaling channels required to establish a
connection
Cellular Service Provider -- A licensee of the
government agency (in the U.S. a licensee of the
Communications Commission) authorized to provide
Radiotelephone Service
Challenge/Response Authentication Mechanism using Message Digest 5
(CRAM-MD5) -- An authentication mechanism which is easy
implement, and provides reasonable security against various attacks
including replay. Supported in a variety of Internet protocols
Specified as baseline mechanism in ACAP. CRAM-MD5 is published
Gellens Informational [Page 3]
RFC 2604 OTASP/OTAPA via ACAP June 1999
RFC 2195.
Code Division Multiple Access -- A technique for spread-
multiple-access digital communications that creates channels
the use of unique code sequences
Customer Service Center -- An entity of a service provider
provides user support and assistance to subscribers
Customer Service Representative -- A person that operates from
customer service center and provides user support and assistance
subscribers
Diffie-Hellman Algorithm -- A public-key cryptography algorithm
exchanging secret keys. Uses the equation , where k is the
key. The equation is executed by each party of the session based
the exchange of independently generated public values
Digits -- Digits consist of the decimal integers 0,1,2,3,4,5,6,7,8,
and 9.
Dual-mode Mobile Station -- A mobile station capable of both
and digital operation
Electronic Serial Number (ESN) -- A 32-bit number assigned by
mobile station manufacturer used to identify a mobile station.
ESN is unique for each legitimate mobile station
Home Location Registry (HLR) -- The location register or database
which a MIN is assigned for record purposes such as
information
Message Digest 5 (MD5) -- A one-way cryptographic hash function
Widely deployed in Internet protocols. Published as RFC 1321.
Mobile Identification Number (MIN) -- The 10-digit number
represents a mobile station's directory number
Mobile Station (MS) -- A station, fixed or mobile, which serves
the end user's wireless communications link with the base station
Mobile stations include portable units (e.g., hand-held
units) and units installed in vehicles
Mobile Switching Center (MSC) -- A configuration of equipment
provides cellular radiotelephone service
Mobile Terminal Authorizing System (MTAS) -- A control system
provides the capability to load the CDMA network HLR with
Gellens Informational [Page 4]
RFC 2604 OTASP/OTAPA via ACAP June 1999
station profile information
Number Assignment Module (NAM) -- The mobile station's
memory module where the MIN and other subscriber-specific
are stored. Mobile stations that have multi-NAM features
users the option of using their units in several different
by registering with a local number in each location
Over-the-air Service Provisioning Function (OTAF) -- A
of network equipment that controls OTASP functionality and
protocol
Over-the-air Parameter Administration (OTAPA) -- Network
OTASP process of provisioning mobile station operational
over the air interface
Over-the-air Service Provisioning (OTASP) -- A process
provisioning mobile station operational parameters over the
interface
Quick-Net-Connect (QNC) -- An IS-707 data service capability
utilizes the Async Data Service Option number but bypasses the
connection for a direct connection to an IP-based internet
Roamer -- A mobile station operating in a cellular system or
other than the one from which service was subscribed
Simple Authentication and Security Layer (SASL) -- An
protocol (RFC-2222) that provides a framework for
authentication and encryption mechanisms
Service Provider -- A company, organization, business, etc.
sells, administers, maintains, and charges for the service.
service provider may or may not be the provider of the network
Shared Secret Data (SSD) -- A 128-bit pattern stored in the
station (in semi-permanent memory) and known by the network.
A-key is used to generate the SSD at the network and in the
station for comparison
Wireless Application Protocol (WAP) -- A set of network
application protocols including a datagram protocol (WDP),
Layer Security (WTLS), Transaction Protocol (WTP), Session
(WSP), and Application Environment (WAE), which use carrier-
gateways to enable wireless devices to access Web resources.
for specifications and details
Gellens Informational [Page 5]
RFC 2604 OTASP/OTAPA via ACAP June 1999
2. Feature
2.1. OTASP Feature
The Over the Air Service Provisioning (OTASP) feature allows
potential wireless service subscriber to activate new
services, and allows an existing wireless subscriber to
services changes without the intervention of a third party.
includes the following
* A way to establish a user profile
* "Over-The-Air" programming of a Number Assignment Module (NAM),
IMSI and Roaming Lists, including Data option parameters,
optionally, service provider or manufacturer specific
(e.g., lock code, call timer).
* An Authentication Key (A-key) Generation procedure
* A-key
2.2. OTAPA Feature
The Over-the-Air Parameter Administration (OTAPA) feature
wireless service providers to update a NAM, IMSI, and Roaming
information in the mobile station remotely without the
of a third party. This capability increases flexibility and
costs for carriers involved with mass changes that affect
handset, such as area-code splits
OTAPA includes the following
* Update a user's Number Assignment Module (NAM
* Update Data option
* Update service provider or manufacturer specific parameters (e.g.,
Server address(es), lock code, call timer).
* Update roaming
Gellens Informational [Page 6]
RFC 2604 OTASP/OTAPA via ACAP June 1999
3.
3.1. Initial Provisioning
A new subscriber needs to give the intended service
sufficient information (e.g., name, address, etc.) to prove credit
worthiness and establish a record within the service provider'
billing system. In addition, the ESN of the mobile station needs
be given to the provider. This may occur in three ways
Voice scenario -- A customer care representative collects
information during a voice conversation. This call is made from
different phone (e.g., wired service) or is initiated using the IS
683A OTASP dialing scheme (i.e., *228xx).
Once the user has been authorized, the customer care
creates a record in the CDMA network HLR, thus allowing use of
CDMA network. In addition, a limited-time N-digit password
created which is tied to the ESN. The choice of N (how many digits
is up to the carrier (as a trade-off between security and
inconvenience). All required provisioning information (
the limited-time password) is loaded into the provisioning server
The user is then told to hang up and call a special number, of
form *228 XX password> SEND (the XX code is the same
used in the initial voice call). This causes the mobile station
initiate a provisioning session
The mobile station and the provisioning server authenticate, and
required provisioning information is downloaded into the
station. The user receives some form of notification once
activity is complete. This notification can be an audible tone or
text message on the mobile station display. (The form and content
this notification can be part of the provisioning data downloaded
the mobile station.) Once this initial provisioning activity
complete the user has a fully authorized mobile station ready
use
Forms scenario -- An interactive user interface is presented via
browser on the mobile station. The subscriber fills in
requested information. (Note that entering non-numeric data
some user interface challenges on many mobile devices.)
A back-end server validates the information, and if possible,
customer is authorized, a limited-time password is generated,
and provisioning server records are created and the actual
operation begins. Otherwise, a voice call is made to a
care representative
Gellens Informational [Page 7]
RFC 2604 OTASP/OTAPA via ACAP June 1999
Desktop scenario -- The subscriber uses a desktop (or in-
kiosk) web browser to contact the carrier, and enters the
personal information
The carrier's server validates the information, and if possible,
customer is authorized, a limited-time password is generated,
and provisioning server records are created, and the subscriber
told to dial a special number on the handset. Once this code
entered, the actual OTASP operation begins. Otherwise, the user
asked to make a voice call to a customer care representative
3.2. OTASP for Authorized
Users already authorized for use of the CDMA network can
initiate provisioning activity. This could happen after
directed to do so by a Customer Care representative, either from
phone conversation or via mail notification. This type of
activity is needed in cases where the carrier desires to
CDMA parameters in the mobile stations or in cases where
station troubleshooting is needed
This type of OTASP occurs in similar fashion to the initial
activity. The mobile station downloads the new
information in the same way
3.3 OTAPA
Typical OTAPA capability involves upgrading a large number of
stations. OTAPA activity needs to be performed in a manner
does not impose on revenue bearing CDMA network activity.
operations are initiated at the customer care center. This can
accomplished by queuing a notification to the mobile station (
1-way SMS or special caller-ID) after the provisioning server
the updated configuration data. OTAPA activity will not occur
the mobile station has acquired CDMA service on the carrier'
network and the notification has reached the mobile station
Alternatively, OTAPA can be handled by including a recheck
in the set of data used to provision the mobile station. When
a low-overhead protocol, such as ACAP [ACAP], it is reasonable
have a mobile station check in periodically to see if anything
changed. The time of day and/or day of week that such
should occur could be included in the provisioning data
OTAPA activity can be terminated at any time due to user
activity
Gellens Informational [Page 8]
RFC 2604 OTASP/OTAPA via ACAP June 1999
4.
4.1. General
IS-683A OTASP operations occur between a mobile station and
over-the-air service provisioning function (OTAF) using IS-95
traffic channel data burst messages. OTASP/OTAPA via data
require that the CDMA carrier have an IS-707 data services
network. The IS-707 service must be either Packet Data
(IS-707.5) or Quick-Net-Connect (QNC).
The mobile station must support
* IS-707 Data Service
* Packet/QNC RLP
* PPP protocol to peer to the IS-707
* IP protocol to provide the network layer for routing to
provisioning
* A transport layer for end-to-end communication (such as TCP
* Authentication and optionally
* Application software to handle the provisioning protocol
memory access
* Domain Name System (DNS) query capabilities sufficient to
the (IP) address of the provisioning server (or the
server's address could be provided during PPP negotiation).
Lastly, the ability must exist for the mobile to make a data
(optionally) a voice call without a MIN
4.2. OTASP
The OTASP function requires the mobile station to originate an IS
707 data call and (optionally) a voice call using a
unprovisioned mobile station. The CDMA network must support
capability
OTASP via data services uses a provisioning server that contains
parameter information for mobile stations. The authorizing
(or software) at the customer care center must be able to add
and mobile station information into both the CDMA network HLR
Gellens Informational [Page 9]
RFC 2604 OTASP/OTAPA via ACAP June 1999
the provisioning server during the initial authorizing process.
provisioning server must be capable of servicing a mobile as soon
its record is created
4.3. OTAPA
IS-683A OTAPA is performed by a mobile-terminated call
downloads parameters to the mobile station. OTAPA calls
without user interaction
In order to perform OTAPA via data services the network needs
direct the mobile station to initiate a special-purpose data call
Several existing methods can be used to implement this capability
for example, a mobile-terminated one-way SMS message. The
message content can contain any information required by the
station. The mobile station would need a simple parser of
messages in order to know when to originate an OTAPA call,
opposed to normal SMS message processing. The OTAPA call would
performed in similar fashion to a registration call.
specifically, the user would not be informed of the call activity
There are alternative means that can be employed to initiate
activity; for example, a mobile-terminated voice call with caller-
using a specialized telephone number. Another alternative is
mobile stations to periodically check in with the
server to check for updated information. ACAP, for example,
designed for such a model. The recheck interval, as well as
time of day and/or day of week that such checks should be used,
be part of the provisioning data sent to the mobile stations
4.4. Provisioning Server
IS-683A utilizes an over-the-air service provisioning
(OTAF) to perform the network-side provisioning activity
OTASP/OTAPA via data services replaces the OTAF with a
server. The provisioning server resides on an IP network within
controlled confines of the carrier. The provisioning server
perform all the service provisioning and parameter
functions that the OTAF provides. The provisioning server must
have an interface to the carrier's Mobile Terminal
System (MTAS). This interface serves to synchronize
provisioning server with the information in the MTAS. The
requirements of this interface depend on the capabilities
interfaces of the carrier's customer care center system(s).
provisioning server must be capable of receiving dynamic
from the MTAS and have the provisioning information
Gellens Informational [Page 10]
RFC 2604 OTASP/OTAPA via ACAP June 1999
available for downloading into the chosen mobile station.
standard ACAP server provides an excellent means to meet
requirements
The provisioning server must be capable of performing
authentication procedure with the mobile station.
authentication mechanism must be capable of authenticating both
mobile station and the provisioning server
4.5. Security
OTASP requires that an authentication procedure be performed
validate the mobile station to the provisioning server, while
requires a mechanism where the mobile validates the server
The provisioning server must be capable of either
* OTAF A-key generation using a Diffie-Hellman
Or
* Receiving A-keys from the carrier network
Since data OTASP/OTAPA operates over IP within the carrier'
network, end-to-end encryption between the mobile station and
provisioning server should be considered as a future enhancement
End-to-end encryption protects against attacks from within
carrier's network, and safeguards the provisioning data (
example, roaming lists).
5.
5.1. ACAP over TCP/
Figure 1 shows a provisioning server in the carrier's intranet
supports the Application Configuration Access Protocol (ACAP,
2244). An administrative client in the customer care domain
this server using ACAP. Handsets are provisioned and
using a small ACAP client
[Figure 1 -- see PostScript version
ACAP is an open Internet protocol designed to solve the problem
client access to configuration and related data. Among its
goals are protocol simplicity, support for thin clients, and ease
operation over limited bandwidth. ACAP provides a high degree
extensibility, especially in authentication mechanisms,
attribute handling, and data management
Gellens Informational [Page 11]
RFC 2604 OTASP/OTAPA via ACAP June 1999
5.1.1. Mobile Authentication and A-Key
The mobile client authenticates with the ACAP server prior
performing any activities. Authentication uses the mobile's ESN
a shared secret. Provisioned mobiles derive the shared secret
the A-Key; unprovisioned mobiles use a limited-time password as
secret
The limited-time password is provided to the user by the
Care representative during the initial call (as instructions to
a specific number). This code is N digits long. The
selects the number of digits, as a trade-off between security
user convenience
The baseline ACAP authentication mechanism uses the shared
plus a random challenge from the server as input to a one-
cryptographic hash function (specifically, keyed-MD5). This
analogous to the existing IS-683A authentication mechanism
uses a random challenge and the CAVE algorithm
An A-Key is generated using a Diffie-Hellman exchange, as is done
IS-683A
5.1.2. Mobile
Provisioning records are identified using the ESN and the
NAM in use
5.1.3. ACAP
As a standard ACAP server, the provisioning server
configurable datasets and dataset inheritance for the management
the data stores
The administrative client can use the same simple ACAP protocol
load and modify the ACAP server as the mobile stations uses
provisioning. While any implementation-specific
available from the server vendor could instead be used for
purpose, the ability to use ACAP can greatly simplify
administrative client, as well as make it independent of the server
ACAP includes an authentication framework (Simple Authentication
Security Layer, SASL, RFC 2222)[SASL]. SASL allows any standard
custom authentication and encryption mechanism to be used. One
the most important features of SASL is that it is designed for
world in which what is "good enough" security today isn't
enough tomorrow. As the threat model changes, SASL allows higher
strength mechanisms to be easily added while supporting
Gellens Informational [Page 12]
RFC 2604 OTASP/OTAPA via ACAP June 1999
deployed clients and servers. SASL is achieving
deployment in a number of Internet protocols
Strongpoints: Since the ACAP protocol was designed for
this type of provisioning activity, its adoption can greatly
the cost, time to market, and support required for the
server. Additionally, the ACAP protocol provides an open
method for mobile stations and other systems to access
provisioning server. Commercial ACAP servers are being developed
numerous companies. The ACAP client code is very small and simple
and thus can be incorporated into virtually any mobile device
minimal cost. As an open standard, the ACAP protocol has
from years of review and experience
5.1.4. Overview of ACAP
ACAP organizes data by datasets. The structure of a dataset
defined by the dataset class. Generally, ACAP servers do not
knowledge of dataset classes. This allows the dataset to
expanded without modifying the server in any way. A dataset is
instantiation of the dataset class, which is a logical definition
what is in a dataset, and how it is used
Datasets contain entries. Entries contain attributes and values
Attributes and values are actually metadata, such as name, length
and value. Any entry can also be a dataset (datasets
hierarchical).
For example, consider the ACAP addressbook dataset class,
to hold names, email addresses, phone numbers, and
information for a person's contacts. A given user may have one
more addressbook datasets. Each entry holds information about
person or entity. Attributes in the entry hold specific items
information, such as the given name, surname, various
addresses, phone numbers, and so forth. If an entry is a list
people (such as a mailing list or specific group of people), it is
subdataset, containing its own entries. Some clients may look
only a subset of the attributes. For example, a mobile handset
client may download only the alias (nickname), name, primary
number and email address of each entry, while a desktop client
access all attributes
5.1.5. Data Organization and
ACAP provides custom hierarchical datasets. Server data can
organized to fit the needs of the applications using the dataset
Gellens Informational [Page 13]
RFC 2604 OTASP/OTAPA via ACAP June 1999
In OTASP/OTAPA over ACAP, data on the server is organized to
take advantage of ACAP capabilities and to use items that
identical to IS-683A, allowing for reuse of IS-683A handset engines
ACAP servers also support data inheritance. All data items
are physically in the inherited dataset and not in the
dataset logically also exist in the inheriting dataset. This
recursive, as the inherited dataset can itself inherit from
dataset. This powerful concept allows potentially large groups
mobile stations to inherit items from a single common entity.
example, preferred roaming lists can be stored in datasets based
geographic areas, and automatically inherited by an
mobile station in that area. The roaming lists could be
subdivided, for example based on tiers of free NVRAM in the mobile
The mobile client need not be aware of this; it happens entirely
the server
ACAP uses trees to provide the data hierarchy. These data trees
be viewed as similar to the directory/file structure used with
common operating systems. The built-in inheritance mechanism
together with the hierarchical structure, makes it extremely easy
update general data without disturbing specific data
Datasets exist within the user, group, and host hierarchies.
user hierarchy holds datasets which belong to individual users.
group hierarchy holds datasets which belong to groups (for example
the "Region." groups in section 5.1.6.3 Server Roaming Lists).
host hierarchy holds datasets which are for specific machines
systems
In addition to providing customizable data trees, ACAP also
several standard datasets for all clients. There is a
dataset that contains information on custom functionality
enhanced features available to a specific client or at the
generally. This allows a server to advertise any
extensions, specialized attribute handling, or other
functionality it supports. A client that needs to use
features can thus easily determine what is available before
to use them
5.1.5.1.
We divide the data accessed by the client into provisioning items
group items, and client state items. Provisioning data contains
items and requested-data items. Group items (such as
roaming lists), are not specific to any mobile device. Group
physically exist in their own datasets, but through
logically appear in client datasets
Gellens Informational [Page 14]
RFC 2604 OTASP/OTAPA via ACAP June 1999
The mobile stations always read data from provisioning entries
write data to client state entries. This structure makes
mobile clients and server configuration easy and simple,
allowing for extensive custom and diagnostic capabilities
5.1.5.2.
"" This signifies the empty string (used here for ACAP entries).
~ This is shorthand for "user/". It is part of the
protocol
5.1.6
Provisioning information is located in the "OTAP" dataset class
(The full specification of this dataset will be published in
subsequent document.) The prefix "Provision." is used for items
are to be downloaded to the mobile, and the prefix "Client." is
for items which the client stores on the server
Provisioning data within the OTAP dataset is organized as a
of items, each of which is stored in its own entry. The entry
is the item name, and the "OTAP.VALUE" attribute contains the
value. This structure permits change notification on a per-
basis
We chose the "Provision" and "Client" names to simplify
operations. For example, the mobile client can easily download
changed provisioning items by performing a search which returns
"OTAP.VALUE" attribute of all entries whose name begins
"Provision" and whose modtime is greater than the last time
client retrieved data. An administrative client can easily
a report of all clients which have not received the most
update by searching for all entries named "Client"
"OTAP.modtime" attribute is less than the desired value
A partial list of items follows
5.1.6.1. Entries and
dataset.
This is a standard ACAP attribute that identifies the location
inherited data. It exists in the "" entry (the entry with the
name) within each dataset
Gellens Informational [Page 15]
RFC 2604 OTASP/OTAPA via ACAP June 1999
5.1.6.2. NAM
The OTAP dataset class contains an entry for each
mobile. The standard location for provisioning records is
/OTAP/USER///
This tree format allows multiple NAMs per ESN. The specific
contain data in IS-683A parameter block types
For example, the CDMA NAM would be stored in an entry called
/OTAP/USER///Provision.CDMA-NAM
The entries below show how NAM records would be organized on
ACAP server
CDMA/Analog
Entry-Path: /OTAP/USER///Provision.CDMA-AMPS-NAM
OTAP.Value: {17} xx xx xx ...
The CDMA/Analog NAM entry from IS-683A (section 4.5.2.1)
consists of at least 129 information bits, depending on
number of SID NID list entries. This is stored as 17 (or more
octets of binary data (padding is used to ensure an
number of octets).
Mobile Directory
Entry-Path: /OTAP/USER///Provision.MOBILE-DN
OTAP.Value: {10}
The Mobile Directory Number from IS-683A contains BCD-
digits representing the phone number. This is stored as
string of 10 or more ASCII digits, e.g., "6195551212".
CDMA
Entry-Path: /OTAP/USER/// Provision.CDMA-NAM
OTAP.Value: {13} xx xx xx ...
Gellens Informational [Page 16]
RFC 2604 OTASP/OTAPA via ACAP June 1999
The CDMA-NAM entry from IS-683A (section 4.5.2.3) consists of
least 100 information bits, depending on the number of SID-
list entries. This is stored as 13 (or more) octets of
data (padding is used to ensure an integral number of octets).
IMSI_
Entry-Path: /OTAP/USER/// Provision.IMSI_T
OTAP.Value: {7} xx xx xx xx xx xx
The IMSI_T entry from IS-683A (section 4.5.2.4) consists of 55
bits of information in five fields. This is stored left
justified in 7 octets of binary data
5.1.6.3. Server Roaming
The ACAP Server will have an entry for each different roaming
configuration for a carrier. The example below assumes that
desired differentiation for the roaming list is geographic,
subdivisions for tiers of mobile free NVRAM It shows that for
region there exists a set of roaming lists per free NVRAM range
Note that a carrier can easily implement different or
differentiation (e.g., by phone vendor or product type) by
changing the dataset tree and assigned the appropriate value to
"dataset.inherit" attribute in the provisioning records
/OTAP/GROUP/region.NorthEast/free-nv.128-512/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.NorthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.SouthEast/free-nv.128-512/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.SouthEast/free-nv.512-1024/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.NorthWest/free-nv.128-512/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.NorthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.SouthWest/free-nv.128-512/
preferred.roaming.list/OTAP.
/OTAP/GROUP/region.SouthWest/free-nv.512-1024/
preferred.roaming.list/OTAP.
Gellens Informational [Page 17]
RFC 2604 OTASP/OTAPA via ACAP June 1999
5.1.6.4. Requested-Data
Inside the OTAP dataset is an entry with the
"Provision.Requested-Data", which contains one attribute
"OTAP.Requested-Data". This attribute is multi-valued. It
either NIL or contains a list of strings. Each string is the
of one element of data that the server requests the client
supply
After authenticating, the ACAP client issues a SEARCH command
retrieve the values of the "OTAP.Requested-Data" attribute of
"Provision.Requested-Data" entry. The client processes the
values (if any) by issuing a STORE command to set one or
attributes in the "Client" entry. The value of each attribute
either the corresponding mobile value (which may be an empty
if the item has no value), or the special value "[N/A]" if the
does not exist or is unknown on the mobile
This mechanism is quite general, and can be used in the normal
case to modify the mobile's dataset as appropriate for the
of the mobile. For example, the inheritance could be set based
the amount of NVRAM available, to cause one set of preferred
list data or another to be used. This mechanism can also be used
other situations, such as to retrieve a complete set of
configuration parameters for diagnostic reasons
5.1.6.5. Sample Server
The entry below is an excerpt of a sample ACAP server dataset
for a single mobile station, with an ESN of FB9876E and using NAM 1:
/OTAP/USER/FB9876E/1/
entry = ""
dataset.inherit = "/OTAP/GROUP/region.NorthEast
free-nv.128-512/preferred.roaming.list
OTAP.Value/"
entry = "Provision.Requested-Data
OTAP.Requested-Data = ("Phone-Make" "Phone-Model" "SW-Rev
"Free-NVRAM")
entry = "Client
OTAP.Phone-Make = "Qualcomm
OTAP.Phone-Model = "pdQ1900"
OTAP.SW-Rev = "001.030.0908"
OTAP.Free-NVRAM = "65536"
OTAP.Last-Modtime = "199812181703"
Gellens Informational [Page 18]
RFC 2604 OTASP/OTAPA via ACAP June 1999
entry = "Provision.Mobile-DN
OTAP.Value = {10} 619 555 1234
entry = "Provision.CDMA-NAM
OTAP.Value = {13} xx xx xx xx xx xx xx xx xx xx
xx
This dataset shows not only provisioning data which was
into the mobile station, but also the items of client data
by the server (the Requested-Data attribute) and the values of
items (the "Client" entry). It also indicates that the
client successfully stored the values associated with the
"199812181703". In addition, it shows that this client
data (i.e., roaming lists) from the "NorthEast" region
5.1.7. Administrative
The administrative client loads initial provisioning
into the server, including specifying the roaming list to inherit
The administrative client also updates provisioning server
as needed, and retrieves data for reports (such as a list of
which have not yet been updated).
Data is loaded into provisioning records by using the ACAP
command. The administrative client authenticates to the ACAP
using credentials that permit access to datasets for mobiles
When a new mobile is authorized for service, the
client creates the dataset by storing into it values that
specific for the device. It also sets the "dataset.inherit
attribute so that values which are not tied to the specific
are inherited as appropriate
* Updates to user
Existing user records may need updating from time to time.
example, a user may change service plans or purchase
additional or replacement mobile device, or the carrier
need to modify some aspect of provisioned data
* Perusal and editing of provisioning
The administrative client can provide general browse and
capability for user records
Gellens Informational [Page 19]
RFC 2604 OTASP/OTAPA via ACAP June 1999
* Report
The administrative client can extract data from the ACAP
in order to generate reports. For example, after
activity, a carrier may wish to identify those mobiles
have not yet been updated
* Queuing of OTAPA
Depending on the OTAPA update procedures chosen (e.g., SMS
CLID, periodic recheck), the administrative client may
involved in initiating the activity. This may or may not
an interface to the provisioning server
5.1.8. Mobile
The ACAP mobile client is implemented as a state machine
performs the equivalent of IS-683A provisioning
information exchange and non-volatile memory storage. The
Client state machine diagram (Figure 2) and descriptions are below
[Figure 2 -- see PostScript version
* Establish Transport Layer/
Authentication and/or encryption can occur at the
layer and/or at the network/transport layer
Basic ACAP authentication occurs in the application
(i.e., within the ACAP session), and in its baseline form
the CRAM-MD5[CRAM-MD5] mechanism. If desired, other
can be used which provide more protection and encryption.
occurs after the transport layer is established, as shown
the client state machine diagram
Figure 3 shows the CRAM-MD5 authentication mechanism for
unprovisioned mobile. In the case of provisioned mobiles,
shared secret is derived from the A-Key, instead of
limited-time N-digit code used for unprovisioned devices
Use of basic ACAP authentication is preferred for
implementations of data-OTASP because it is simple, easy
implement, and all procedures and methods are in place
Stronger SASL mechanisms and/or IPSec can be rolled out in
future without disrupting the deployed base
[Figure 3 -- see PostScript version
Gellens Informational [Page 20]
RFC 2604 OTASP/OTAPA via ACAP June 1999
* Requested-data
The mobile ACAP client issues a search command asking
server to return the attribute "OTAP.Requested-Data" in
entry "Requested-Data".
* Receive requested-data
The server instructs the client to store attributes
returning one or more values of requested-data in response
the Requested-Data SEARCH
For example, the attribute "OTAP.Requested-Data" in the
"Requested-Data" might contain four values: "phone-make",
"phone-model", "SW-Rev", and "Free-NVRAM".
* STORE attribute
If the response to the requested-data SEARCH returns
values, the client issues a STORE command. Each attribute
the STORE command corresponds to one item of requested-data
If the client does not recognize an item, it stores the
"[n/a]".
Continuing with our example, the client uses this STORE
to write four attributes into the "Client" entry.
attribute name is identical to one value of
OTAP.Requested-Data" attribute (with the prefix "OTAP." added).
Each attribute value is determined by the respective
value
In our example, this STORE command sets the
attributes and values
- "OTAP.Phone-Make" = "
- "OTAP.Phone-Model" = "pdQ1900
- "OTAP.SW-Rev" = "001.030.0908"
- "OTAP.Free-NVRAM" = "65536"
* Provisioning data
The mobile ACAP client issues a search command to retrieve
items of provisioning data that have changed since it
checked in (which in the initial session retrieves
provisioning data).
Gellens Informational [Page 21]
RFC 2604 OTASP/OTAPA via ACAP June 1999
This SEARCH command asks the server to return the "OTAP.Value
attribute of any entries whose name starts with "provision."
(case-insensitive) and whose modtime is greater than
supplied value (which is zero for an unprovisioned mobile).
* Receive provisioning data and
The server returns the provisioning items, each as one
name and one attribute value. The server response to
SEARCH command includes the modtime of the latest
returned
* Save
The mobile writes the returned values into NVRAM
* STORE
The ACAP client stores the returned modtime on the server as
acknowledgement that the data was received and NVRAM updated
*
The client issues the LOGOUT command
* Close transport
The client closes the TCP connection
* End
The data call is terminated
5.2. WAP with
An advantage of the ACAP solution is that is can easily coexist
a WAP-based mechanism, giving carriers more options
A carrier can deploy handsets into its service area which use WAP
based provisioning, if desired, alongside those which use
provisioning. All that is required is that the WAP server contain
small ACAP client (or an interface to an ACAP server).
Figure 4 shows how mobile stations can be configured using a
browser. By using an ACAP server for provisioning, carriers
free to simultaneously deploy mobile stations that use either WAP
ACAP, as desired. In either case, the ACAP server is the source
provisioning data
Gellens Informational [Page 22]
RFC 2604 OTASP/OTAPA via ACAP June 1999
[Figure 4 -- see PostScript version
5.3. Network-Resident vs. Configuration
It is useful to recognize that wireless devices access two
types of carrier-provided data: network-resident and configuration
Network-resident data exists primarily within the carrier's network
Examples include account status, billing detail, service
options, etc. While mobiles may access this information for
display, it resides in the network. Configuration data,
contrast, affects the operation of the handset, is usually not
to the user, and must persist in the device
For network-resident data access, the obvious choice is the web
The data is highly interactive and time-variant, making web
a reasonable solution. Any appropriate web browser can be used
There are many good reasons for having a web browser in a
device which contains a display and is capable of user interaction
For configuration data, the best solution is to use ACAP. ACAP
optimized for the job, can be implemented quickly, requires a
small amount of memory, and does not depend on a display or any
interaction capability
Trying to use the same access method for both types of
unnecessarily complicates the solution, leading to increased design
development, and debug time and expense. It makes it more
to offer low-cost devices. Since the two types of
fundamentally differ, it is good engineering practice to
optimal code and protocols for each
5.4. Intellectual Property
There are no known intellectual property issues with the
solution. The ACAP specification was developed within the IETF,
no ownership, patent, or other IP claims have been asserted
Multiple independent vendors are developing ACAP clients
servers, in addition to the existing usage in deployed products
6. Handset Protocol
6.1. ACAP over TCP/
Figure 5 depicts the mobile station protocol suite for the ACAP
TCP/IP solution. The mobile station is capable of supporting
IS-683A OTASP and OTASP over ACAP
[Figure 5 -- see PostScript version
Gellens Informational [Page 23]
RFC 2604 OTASP/OTAPA via ACAP June 1999
7. IS-683A
7.1. OTASP
To maximize compatibility and allow for reuse of IS-683A
code, the data formats used in OTASP over ACAP are identical
those used in IS-683A. Section 5.1.5 Data Organization
Capabilities discusses this in more detail
OTASP via IS-683A requires custom design and development for
specific CDMA infrastructure used by a carrier. This can
limit the data management capabilities and significantly reduces
extensibility of the solution. Conversely, OTASP over data can
implemented on a generic IP network using an Internet standards
based capability that provides extensible provisioning
for carriers
OTASP over data uses a traffic channel whereas IS-683A OTASP
over the limited-bandwidth signaling channel
IS-683A OTASP operations are inherently simultaneous voice and data
This allows the customer care representative to extract
from the mobile station while conversing with the user. OTASP
data services is a data-only solution (at least for now).
makes OTASP operations slightly more sequential and
problematic. Simultaneous voice and data will alleviate this issue
7.2 OTASP Call
The call flow diagram (Figure 6) depicts the message sequence
operations for a typical IS-683A OTASP (provisioning) call.
data-OTASP solution must perform all the functions of the IS-683
OTASP call. The proposed solution meets these requirements
[Figure 6 -- see PostScript version
7.3. OTAPA
Data-OTAPA requires the ability to instruct mobiles to originate
data call to the provisioning server. Several viable approaches
discussed in sections 3.3 OTAPA Activity and 4.3
Requirements
OTAPA over data has the potential to require far less
resources to download new information to mobile stations. The
server inherently only communicates changes to the clients,
only changed information needs to be downloaded to the
stations using OTAPA over data via ACAP
Gellens Informational [Page 24]
RFC 2604 OTASP/OTAPA via ACAP June 1999
7.4. OTAPA Call
The call flow diagram (Figure 7) depicts the message sequence for
typical IS-683A OTAPA operation. Any data-OTAPA solution
perform all the functions of the IS-683A OTAPA call. The
solution meets these requirements
[Figure 7 -- see PostScript version
8. Alternative
8.1. IS-683A over TCP/
One alternative is to port IS-683A to TCP, remaining as close
possible to the IS-683A protocol exchange
Figure 8 depicts the architecture and communications backbone
support OTASP/OTAPA via IS-707 data services with a
server based on the IS-683A OTAF function
[Figure 8 -- see PostScript version
8.1.1. OTAF
This provisioning server is modeled after the IS-683A OTAF.
OTAF server performs the specific operations and messaging of IS
683A OTAF. This includes A-key reauthentication procedures
Strongpoints
(1) OTAF and mobile station behavior mirrors IS-683A (
duplicate software in mobile station). Nearly all procedures
defined
Drawbacks
(1) The OTAF server would need to be custom-designed and built
(2) No inherent data manipulation capabilities in the OTAF server
All required or desired data management activities would have to
built from scratch
(3) Interface application would require a non-standard
(and therefore proprietary) to OTAF server
(4) End-to-end encryption scheme still needed for full security
Gellens Informational [Page 25]
RFC 2604 OTASP/OTAPA via ACAP June 1999
8.1.2. Interface
This function loads all required provisioning-related
from the CDMA network information system to the OTAF server.
includes the queuing of provisioning transactions and data
8.1.3. Protocol Handset
Figure 9 depicts the mobile station protocol suite for the IS-683
over TCP/IP solution. The OTASP client is capable of
both IS-683A OTASP activities or OTASP activities over the
transport
[Figure 9 -- see PostScript version
8.2. Browser-Based
Another alternative is to use forms embedded in web pages
Encapsulating the provisioning data into custom tags embedded in
web form is an idea that at first seems attractive. There are a
of advantages in having a browser in the handset, web servers
very widely deployed, and everyone is familiar on some level
the web
However, a meta-protocol for this would need to be designed, and
fully detailed specification produced. This solution
custom software on the provider side to handle the meta-protocol
It additionally requires handset vendors to add custom software
the handset browser to handle this protocol
This solution would require a provisioning-capable browser in
phone. While it may be desirable to have a browser, the decision
require it needs to be considered carefully, especially in light
the memory requirements it would impose on all devices
This solution would complicate the handset browser, by requiring
to handle provisioning as well as browsing. As provisioning
browsing are functionally dissimilar, this code is not a natural
within the browser. Implementing this solution would require
significant increase in development and debug resources, and
negatively impact time-to-market and cost
Also because the web is functionally dissimilar, a high level
carrier-side customization would be needed, leading to
vendor choice and increased deployment costs
Gellens Informational [Page 26]
RFC 2604 OTASP/OTAPA via ACAP June 1999
This approach would layer custom data on top of a standard protocol
This would require design work, and would not have much time
open review before deployment, greatly increasing the risk.
contrast, ACAP has had years of open review and refinement
This approach also limits the extensibility of the solution. ACAP
conversely, is very extensible. Because ACAP is such a
protocol, it can be added to a wide variety of applications at
cost. This allows increasing numbers of applications on the
device to share information with servers as well as
applications
9.
ACAP provides a high degree of extensibility, especially
authentication mechanisms, custom attribute handling, and
management. By using an Internet standard protocol
interoperability and integration with a variety of equipment
possible, and carriers are not locked into any vendor. It is
easier to add new levels of service and capabilities,
integration with future subscriber devices and applications (e.g.,
email).
Since an ACAP client is so small, it can be incorporated
virtually any device, even low-end ones without displays, and can
added without sacrificing other features. The simplicity of
client and protocol directly translate to shorter development
and faster time-to-market
Because the ACAP protocol was designed for precisely this type
provisioning activity, its adoption can greatly reduce the cost
time to market, and support required for the provisioning server
well as the handsets. As an open standard, the ACAP protocol
benefited from years of review and experience
Another advantage of the ACAP solution is that is can easily
with a WAP-based mechanism, giving carriers more options
reducing the minimal requirement burden on mobile devices
A carrier can deploy handsets into its service area which use WAP
based provisioning, if desired, alongside those which use
provisioning. By using an ACAP server for provisioning,
are free to simultaneously deploy mobile stations that use
WAP or ACAP, as desired
The lack of intellectual-property issues further adds to ACAP'
appeal
Gellens Informational [Page 27]
RFC 2604 OTASP/OTAPA via ACAP June 1999
10.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Access Protocol", RFC 2244, November 1997.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/
AUTHorize Extension for Simple Challenge/Response", RFC 2195,
September 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
11. Security
Security is discussed in many sections of this document.
particular, the need and methods to guard against
updating of handsets, usurpation of newly-created accounts
compromise of handset security values, and disclosure of
proprietary data and handset parameters is covered
12.
Jim Willkie and Marc Phillips contributed greatly to this document
Their help is very much appreciated
13. Author's
Randall
QUALCOMM
6455 Lusk
San Diego, CA 92121-2779
Phone: +1 619 651 5115
EMail: randy@qualcomm.
Gellens Informational [Page 28]
RFC 2604 OTASP/OTAPA via ACAP June 1999
14. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Gellens Informational [Page 29]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
