RFC 2636

Wireless Device Configuration (OTASP/OTAPA) via ACAP

📅 published July 1999, from ietf

RFC 2636 🎀 Wireless Device Configuration (OTASP/OTAPA) via ACAP

Who wrote it: R. Gellens from Qualcomm 💅 When: July 1999 🌸 What kind of doc: Informational, so it's giving "here's some useful info," not "you must do this" 📚 What it replaces: It obsoletes RFC 2604 🔄 (so 2636 is the newer version bestie should look at)

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌈

Okay so wireless carriers are under pressure rn 😩 They need more efficient ways to get devices to customers, happier customers, and better margins and profit. Handsets are also getting sold more and more through retail, and that's a whole mood. Provisioning handsets, activating users, and updating handset parameters can get pricey and slow, but over-the-air activation mechanisms can cut that cost way down ✨ A comprehensive and extensible way to do over-the-air provisioning and handset parameter updating is required 🫶

One option is to buy EIA/TIA/IS-683A (Over-the-air Service Provisioning of Mobile Stations in Spread Spectrum Systems) equipment. Carriers have been side-eyeing that because it costs a lot, so they're looking for other routes 💸 A very viable way to do OTA (over-the-air) provisioning is to ride on the IS-707 data services equipment that most carriers are already rolling out 🔥 This paper lays out an approach that uses that IS-707 deployment to deliver OTA provisioning and parameter upgrading. Main character energy 👑

IS-707 data services already offer several methods for over-the-air provisioning and parameter updating 🧚 A well thought-out approach built on Internet-based open standard mechanisms can give carriers an extensible platform for more service offerings, better interoperability among back-end services, and vendor independence. Literally the dream 😭

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. 💖

Table of Contents 📑

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.5.3.  Dataset . . . . . . . . . . . . . . . . . . . .  15
        5.1.5.4.  Entries and Attributes . . . . . . . . . . . . . 15
        5.1.5.5.  NAM Records . . . . . . . . . . . . . . . . . .  16
        5.1.5.6.  Server Roaming Lists . . . . . . . . . . . . . . 17
        5.1.5.7.  Requested-Data Record . . . . . . . . . . . . .  18
        5.1.5.8.  Sample Server Entry  . . . . . . . . . . . . . . 18
      5.1.6.  Administrative Client . . . . . . . . . . . . . . .  19
      5.1.7.  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

    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. Terms 💅

Application Configuration Access Protocol (ACAP) 🗂️ is an Internet protocol (RFC-2244) that gives you remote storage and access to configuration and preference info.

Activation ⚡ is the process where a mobile station and the network get programmed so the mobile station becomes operable and can be used for cellular service once the service provider authorizes it.

Authentication 🔐 is the procedure used to validate a mobile station's identity.

Authentication Center 🛡️ is an entity that manages the authentication information related to the mobile station.

Authentication Key (A-key) 🗝️ is a secret 64-bit pattern stored in the mobile station. It's used to generate and update the mobile station's shared secret data, and it's used in the authentication process.

Authorization ✅ is an action by a service provider to make cellular service available to a subscriber.

Call 📞 is a temporary communication between telecommunications users for the purpose of exchanging information. A call includes the sequence of events that allocates and assigns the resources and signaling channels needed to set up a communications connection.

Cellular Service Provider 📡 is a licensee of the responsible government agency (in the U.S., a licensee of the Federal Communications Commission) that's authorized to provide Cellular Radiotelephone Service.

Challenge/Response Authentication Mechanism using Message Digest 5 (CRAM-MD5) 🧩 is an authentication mechanism that's easy to implement and gives reasonable security against various attacks, including replay. It's supported in a variety of Internet protocols, it's the baseline mechanism specified in ACAP, and it's published as RFC 2195.

Code Division Multiple Access 🌈 is a technique for spread-spectrum multiple-access digital communications that creates channels through unique code sequences.

Customer Service Center 🎧 is an entity of a service provider that gives user support and assistance to subscribers.

Customer Service Representative 🧑‍💼 is a person who works from a customer service center and gives user support and assistance to subscribers.

Diffie-Hellman Algorithm 🔑 is a public-key cryptography algorithm for exchanging secret keys. It uses the equation , where k is the secret key. Each party of the session runs the equation based on the exchange of independently generated public values.

Digits 🔢 are the decimal integers 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9.

Dual-mode Mobile Station 📱 is a mobile station that can do both analog and digital operation.

Electronic Serial Number (ESN) 🆔 is a 32-bit number assigned by the mobile station manufacturer to identify a mobile station. The ESN is unique for each legitimate mobile station.

Home Location Registry (HLR) 🗄️ is the location register or database that a MIN is assigned to for record purposes like subscriber information.

Message Digest 5 (MD5) 🧮 is a one-way cryptographic hash function. It's widely deployed in Internet protocols and is published as RFC 1321.

Mobile Identification Number (MIN) 🔟 is the 10-digit number that represents a mobile station's directory number.

Mobile Station (MS) 📲 is a station, fixed or mobile, that serves as the end user's wireless communications link with the base station. Mobile stations include portable units (for example, hand-held personal units) and units installed in vehicles.

Mobile Switching Center (MSC) 🏢 is a configuration of equipment that provides cellular radiotelephone service.

Mobile Terminal Authorizing System (MTAS) 🎛️ is a control system that gives the capability to load the CDMA network HLR with mobile station profile information.

Number Assignment Module (NAM) 💾 is the mobile station's electronic memory module, where the MIN and other subscriber-specific parameters are stored. Mobile stations with multi-NAM features let users use their units in several different markets by registering with a local number in each location. Iconic multitasking 🙌

Over-the-air Service Provisioning Function (OTAF) 🛰️ is a configuration of network equipment that controls OTASP functionality and the messaging protocol.

Over-the-air Parameter Administration (OTAPA) 🔧 is the network-initiated OTASP process of provisioning mobile station operational parameters over the air interface.

Over-the-air Service Provisioning (OTASP) 📶 is a process of provisioning mobile station operational parameters over the air interface.

Quick-Net-Connect (QNC) ⚡🌐 is an IS-707 data service capability. It uses the Async Data Service Option number but skips the modem connection for a direct connection to an IP-based internet.

Roamer 🧳 is a mobile station operating in a cellular system or network other than the one it subscribed to.

Simple Authentication and Security Layer (SASL) 🧱 is an Internet protocol (RFC-2222) that provides a framework for negotiating authentication and encryption mechanisms.

Service Provider 🏪 is a company, organization, business, etc. that sells, administers, maintains, and charges for the service. The service provider may or may not be the provider of the network.

Shared Secret Data (SSD) 🤫 is a 128-bit pattern stored in the mobile station (in semi-permanent memory) and known by the network. The A-key is used to generate the SSD at the network and in the mobile station so they can be compared.

Wireless Application Protocol (WAP) 🌍 is a set of network and application protocols. These include a datagram protocol (WDP), Transport Layer Security (WTLS), Transaction Protocol (WTP), Session Protocol (WSP), and Application Environment (WAE), which use carrier-based gateways to let wireless devices access Web resources. See <http://www.wapforum.org> for specifications and details. 🦋

2. Feature Descriptions 🎀

2.1. OTASP Feature Description ✨

okay so OTASP (Over the Air Service Provisioning) is giving "activate it yourself" 💖 A potential wireless subscriber can activate brand new services, and an existing subscriber can make service changes without a third party having to step in 🫶 OTASP 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, and optionally, service provider or manufacturer specific parameters (e.g., lock code, call timer).
  • An Authentication Key (A-key) Generation procedure.
  • A-key storage

2.2. OTAPA Feature Description 🌸

OTAPA (Over-the-Air Parameter Administration) lets wireless service providers update a NAM, IMSI, and Roaming List info in the mobile station remotely, no third party needed 🦋 this is a total game changer for mass updates that hit every single handset, like area-code splits. It adds flexibility and cuts costs for carriers 💅

OTAPA includes the following:

  • Update a user's Number Assignment Module (NAM)
  • Update Data option parameters
  • Update service provider or manufacturer specific parameters (e.g., Server address(es), lock code, call timer).
  • Update roaming lists

3. Operation ✨

3.1. Initial Provisioning Activity

okay so a brand new subscriber has to hand the service provider enough info (name, address, etc.) to prove they're creditworthy and get a record set up in the provider's billing system 💅 The ESN of the mobile station also has to be given to the provider. This can happen in three ways:

Voice scenario -- A customer care rep collects credit info during a voice call. This call is made from a different phone (e.g., wired service) or is started using the IS-683A OTASP dialing scheme (i.e., *228xx) 📞

Once the user has been authorized, the customer care rep creates a record in the CDMA network HLR, which is what lets them use the CDMA network 🫶 A limited-time N-digit password is also created and tied to the ESN. The carrier gets to choose N (how many digits), which is a trade-off between security and user inconvenience 🔐 All the required provisioning info (including the limited-time password) gets loaded into the provisioning server.

The user is then told to hang up and call a special number, of the form *228 XX <N-digit password> SEND (the XX code is the same one used in the initial voice call). This makes the mobile station start a provisioning session 📱

The mobile station and the provisioning server authenticate, and all the required provisioning info is downloaded into the mobile station ✨ The user gets some kind of notification once the activity is done. This can be an audible tone or a text message on the mobile station display. (The form and content of this notification can be part of the provisioning data downloaded by the mobile station.) Once this initial provisioning activity is complete, the user has a fully authorized mobile station ready to go 🎀

Forms scenario -- An interactive user interface is shown in a browser on the mobile station. The subscriber fills in the requested info. (Heads up: entering non-numeric data is kind of a mess on lots of mobile devices 🙈)

A back-end server validates the info. If possible, the customer is authorized, a limited-time password is generated, HLR and provisioning server records are created, and the actual OTASP operation begins 🔥 Otherwise, a voice call is made to a customer care rep.

Desktop scenario -- The subscriber uses a desktop (or in-store kiosk) web browser to contact the carrier, and enters the usual personal info 💻

The carrier's server validates the info. If possible, the customer is authorized, a limited-time password is generated, HLR and provisioning server records are created, and the subscriber is told to dial a special number on the handset 🌈 Once that code is entered, the actual OTASP operation begins. Otherwise, the user is asked to make a voice call to a customer care rep.

3.2. OTASP for Authorized Users

users who are already authorized to use the CDMA network can start provisioning activity too 🦋 This could happen after a Customer Care representative tells them to, either during a phone conversation or through mail notification. This kind of OTASP is needed when the carrier wants to upgrade CDMA parameters in mobile stations, or when mobile station troubleshooting is needed 🧚

This type of OTASP works in a similar way to the initial OTASP activity. The mobile station downloads the new provisioning info in the same way 💜

3.3 OTAPA Activity

okay the big one: OTAPA usually means upgrading a huge number of mobile stations at once 😭 It has to happen in a way that does not get in the way of revenue-bearing CDMA network activity 💅 OTAPA operations are started at the customer care center. This can be done by queuing a notification to the mobile station (via 1-way SMS or special caller-ID) after the provisioning server has the updated configuration data. OTAPA activity will not happen until the mobile station has acquired CDMA service on the carrier's network and the notification has reached the mobile station 🫶

Another option is to put a recheck interval in the set of data used to provision the mobile station. When a low-overhead protocol is used, such as ACAP [ACAP], it makes sense for a mobile station to check in periodically to see if anything has changed ⭐ The time of day and/or day of week that these rechecks should happen could be included in the provisioning data 🌸

OTAPA activity can be terminated at any time due to user call activity 🙈

4. Requirements ✨

4.1. General Requirements

okay so IS-683A OTASP operations happen between a mobile station and an over-the-air service provisioning function (OTAF), using IS-95A traffic channel data burst messages 🔥 OTASP/OTAPA via data services requires that the CDMA carrier has an IS-707 data services capable network. The IS-707 service has to be either Packet Data Service (IS-707.5) or Quick-Net-Connect (QNC) 💖

The mobile station must support:

  • IS-707 Data Service capability
  • Packet/QNC RLP protocol
  • PPP protocol to peer to the IS-707 IWF
  • IP protocol to provide the network layer for routing to the provisioning server
  • A transport layer for end-to-end communication (such as TCP)
  • Authentication and optionally encryption
  • Application software to handle the provisioning protocol and memory access.
  • Domain Name System (DNS) query capabilities sufficient to obtain the (IP) address of the provisioning server (or the provisioning server's address could be provided during PPP negotiation).

Lastly, the mobile has to be able to make a data call (optionally) a voice call without a MIN 🧚

4.2. OTASP Requirements

the OTASP function requires the mobile station to start an IS-707 data call and (optionally) a voice call using a completely unprovisioned mobile station 🫶 The CDMA network must support this capability.

OTASP via data services uses a provisioning server that contains the parameter info for mobile stations 💜 The authorizing agent (or software) at the customer care center must be able to add user and mobile station info into both the CDMA network HLR and the provisioning server during the initial authorizing process. The provisioning server must be able to service a mobile as soon as its record is created ✨

4.3. OTAPA Requirements

IS-683A OTAPA is done by a mobile-terminated call that downloads parameters to the mobile station. OTAPA calls happen without any user interaction 🎀

To do OTAPA via data services, the network needs to direct the mobile station to start a special-purpose data call. Several existing methods can be used for this, for example, a mobile-terminated one-way SMS message. The SMS message content can contain any info the mobile station needs 📩 The mobile station would need a simple parser of SMS messages so it knows when to start an OTAPA call, instead of doing normal SMS message processing. The OTAPA call would be done in a similar way to a registration call. More specifically, the user would not be told about the call activity 🙈

There are other ways to start OTAPA activity; for example, a mobile-terminated voice call with caller-ID using a specialized telephone number. Another option is for mobile stations to check in with the provisioning server periodically to look for updated info. ACAP, for example, is designed for this kind of model 🦋 The recheck interval, as well as the time of day and/or day of week those checks should be used, can be part of the provisioning data sent to the mobile stations 🌈

4.4. Provisioning Server Requirements

IS-683A uses an over-the-air service provisioning function (OTAF) to handle the network-side provisioning activity. OTASP/OTAPA via data services replaces the OTAF with a provisioning server 💅 The provisioning server lives on an IP network inside the controlled confines of the carrier. The provisioning server must do all the service provisioning and parameter administration functions that the OTAF does. It must also have an interface to the carrier's Mobile Terminal Authorizing System (MTAS). This interface keeps the provisioning server in sync with the info in the MTAS. The specifics of this interface depend on the capabilities and interfaces of the carrier's customer care center system(s) 🔥 The provisioning server must be able to receive dynamic updates from the MTAS and have the provisioning info immediately available for downloading into the chosen mobile station. A standard ACAP server is an excellent way to meet these requirements ⭐

The provisioning server must be able to do an authentication procedure with the mobile station. This authentication mechanism must be able to authenticate both the mobile station and the provisioning server 🔐

4.5. Security Requirements

🚨 Security note, bestie: OTASP requires an authentication procedure to validate the mobile station to the provisioning server, while OTAPA requires a mechanism where the mobile validates the server. This is serious stuff 😭

The provisioning server must be capable of either:

  • OTAF A-key generation using a Diffie-Hellman mechanism

Or:

  • Receiving A-keys from the carrier network.

Since data OTASP/OTAPA runs over IP within the carrier's network, end-to-end encryption between the mobile station and the provisioning server should be considered as a future enhancement 🔐 End-to-end encryption protects against attacks from within a carrier's network, and safeguards the provisioning data (for example, roaming lists) 🛡️

5. Architecture ✨

5.1. ACAP over TCP/IP ✨

okay so picture this 💖 Figure 1 shows a provisioning server chilling in the carrier's intranet 🏠. It speaks the Application Configuration Access Protocol (ACAP, RFC 2244). An administrative client in the customer care domain updates that server using ACAP, and handsets get provisioned and configured with a small ACAP client. 🎀

                [Figure 1 -- see PostScript version]

ACAP is an open Internet protocol built to solve the problem of client access to configuration and related data 🦋 Its main goals are protocol simplicity, support for thin clients, and ease of operation over limited bandwidth. It is also super extensible, especially when it comes to authentication mechanisms, specialized attribute handling, and data management. main character energy, fr 👑

5.1.1. Mobile Authentication and A-Key Generation

the mobile client authenticates with the ACAP server before doing anything else 🔐 Authentication uses the mobile's ESN and a shared secret. Provisioned mobiles derive that shared secret from the A-Key, and unprovisioned mobiles use a limited-time password as the secret instead. 🌸

the limited-time password is given to the user by the Customer Care representative during the initial call, as instructions to dial a specific number 📞 This code is N digits long. The carrier picks how many digits, which is a trade-off between security and user convenience. it's giving balance ⚖️

the baseline ACAP authentication mechanism takes the shared secret plus a random challenge from the server and feeds them into a one-way cryptographic hash function (specifically, keyed-MD5) 🧁 This is analogous to the existing IS-683A authentication mechanism, which uses a random challenge and the CAVE algorithm. same energy, different outfit 💅

an A-Key is generated using a Diffie-Hellman exchange, just like it's done in IS-683A 🔑 iykyk

5.1.2. Mobile Identification

provisioning records are identified using the ESN and the current NAM in use 🪪 simple and clean, I love that for us ✨

5.1.3. ACAP Server

as a standard ACAP server, the provisioning server includes configurable datasets and dataset inheritance for managing its data stores 🗂️

the administrative client can use the same simple ACAP protocol to load and modify the ACAP server that the mobile stations use for provisioning 🙌 Any implementation-specific mechanisms from the server vendor could be used for this instead, but being able to use ACAP can really simplify the administrative client and keep it independent of the server. so smart, bestie 🧠

ACAP includes an authentication framework, the Simple Authentication and Security Layer (SASL, RFC 2222)[SASL] 🛡️ SASL lets any standard or custom authentication and encryption mechanism get used. One of its most important features is that it's designed for a world where what counts as "good enough" security today might not be good enough tomorrow 😭 As the threat model changes, SASL makes it easy to add higher-strength mechanisms while still supporting clients and servers that are already deployed. SASL is also getting seriously widespread across a bunch of Internet protocols 🌈

Strongpoints! 💅 ACAP was designed for exactly this kind of provisioning activity, so adopting it can greatly cut the cost, time to market, and support needed for the provisioning server. ACAP also gives mobile stations and other systems an open standard way to reach the provisioning server. Lots of companies are building commercial ACAP servers. The ACAP client code is very small and simple, so it can slip into basically any mobile device at minimal cost. And since it's an open standard, ACAP has benefited from years of review and experience. 🎀

5.1.4. Overview of ACAP Structure

ACAP organizes data into datasets 📚 The structure of a dataset is defined by its dataset class. Generally, ACAP servers don't know about dataset classes, which means a dataset can be expanded without changing the server in any way 🙈 A dataset is an instantiation of the dataset class, which is the logical definition of what's inside a dataset and how it's used.

datasets contain entries, and entries contain attributes and values. Attributes and values are actually metadata, like a name, a length, and a value 🍓 Any entry can also be a dataset, since datasets are hierarchical. Russian doll energy 🪆

for example, think about the ACAP addressbook dataset class, which is built to hold names, email addresses, phone numbers, and related info for a person's contacts 📇 A given user may have one or more addressbook datasets. Each entry holds info about one person or entity, and attributes hold the specific bits, like the given name, surname, various email addresses, phone numbers, and so on. If an entry is a list of people (like a mailing list or a specific group), it's a subdataset with its own entries. Some clients only look at a subset of the attributes. A mobile handset ACAP client might download just the alias (nickname), name, primary phone number, and email address of each entry, while a desktop client might access all of them 📱💻

5.1.5. Data Organization and Capabilities

ACAP provides custom hierarchical datasets, so server data can be organized to fit whatever the applications using the dataset need 🌳

in OTASP/OTAPA over ACAP, the data on the server is organized to both take advantage of ACAP capabilities and use items that are identical to IS-683A. That means IS-683A handset engines can be reused 🔁 genius

ACAP servers also support data inheritance. All data items that are physically in the inherited dataset and not in the inheriting dataset logically also exist in the inheriting dataset. This is recursive, since the inherited dataset can itself inherit from another dataset. This is so powerful, because it lets potentially huge groups of mobile stations inherit items from one common entity 💜 For example, preferred roaming lists can be stored in datasets based on geographic areas and automatically inherited by an individual mobile station in that area 🗺️ The roaming lists could be subdivided further, for example based on tiers of free NVRAM in the mobile. The mobile client doesn't need to be aware of any of this, because it all happens on the server. no thoughts, just vibes 🫶

ACAP uses trees to provide the data hierarchy 🌲 These data trees can be viewed as similar to the directory/file structure used by all common operating systems. The built-in inheritance mechanism plus the hierarchical structure make it extremely easy to update general data without disturbing specific data. ✨

datasets exist within the user, group, and host hierarchies. The user hierarchy holds datasets that belong to individual users. The group hierarchy holds datasets that belong to groups (for example, the "Region." groups in section 5.1.6.3 Server Roaming Lists). The host hierarchy holds datasets that are for specific machines or systems. 🏷️

on top of customizable data trees, ACAP also provides several standard datasets for all clients 🎁 There's a capabilities dataset that holds info about custom functionality and enhanced features available to a specific client or to the site in general. This lets a server advertise any protocol extensions, specialized attribute handling, or other enhanced functionality it supports. A client that wants to use those features can easily check what's available before trying to use them. checks out 🙌

5.1.5.1. Structure

we split the data the client accesses into provisioning items, group items, and client state items 🧩 Provisioning data contains NAM items and requested-data items. Group items (like preferred roaming lists) aren't specific to any mobile device. They physically live in their own datasets, but through inheritance they logically show up in client datasets.

the mobile stations always read data from provisioning entries and write data to client state entries. This structure makes both mobile clients and server configuration easy and simple, while still allowing for extensive custom and diagnostic capabilities 🛠️💖

5.1.5.2. Conventions

"" signifies the empty string (used here for ACAP entries) 🫧

~ is shorthand for user/<userid>. It's part of the ACAP protocol 🤓

5.1.5.3. Dataset

provisioning information lives in the "OTAP" dataset class. (The full specification of this dataset will be published in a subsequent document.) The prefix "Provision." is used for items that get downloaded to the mobile, and the prefix "Client." is used for items the client stores on the server 📦

provisioning data inside the OTAP dataset is organized as a series of items, and each item is stored in its own entry. The entry name is the item name, and the OTAP.VALUE attribute holds the item value. This structure allows change notification on a per-item basis 🔔

we chose the "Provision" and "Client" names to simplify various operations 🧠 For example, the mobile client can easily download all changed provisioning items by running a search that returns the OTAP.VALUE attribute of every entry whose name begins with "Provision" and whose modtime is greater than the last time the client retrieved data. An administrative client can easily generate a report of every client that hasn't received the most recent update by searching for all entries named "Client" whose OTAP.modtime attribute is less than the desired value. 📊 so organized, I'm obsessed 😭

here's a partial list of items 👇

5.1.5.4. Entries and Attributes

dataset.inherit

this is a standard ACAP attribute that identifies the location of inherited data 🔗 It lives in the "" entry (the entry with the empty name) within each dataset. 💅

5.1.5.5. NAM Records 📇✨

okay so the OTAP dataset class has one entry for every provisioned mobile 📱💖 The standard spot for provisioning records is:

/OTAP/USER/<esn>/<nam>/

this tree format lets one ESN have multiple NAMs 🫶 and the specific entries hold data in IS-683A parameter block types 🌸

for example, the CDMA NAM gets stored in an entry called:

/OTAP/USER/<esn>/<nam>/Provision.CDMA-NAM/

here's how the NAM records get organized on the ACAP server, bestie 💅

CDMA/Analog NAM

Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.CDMA-AMPS-NAM/

OTAP.Value: {17} xx xx xx ... xx

the CDMA/Analog NAM entry from IS-683A (section 4.5.2.1) has at least 129 information bits, depending on how many SID NID list entries there are 🔢 it gets stored as 17 (or more) octets of binary data, and padding is used so you end up with a whole number of octets 🎀

Mobile Directory Number

Entry-Path: /OTAP/USER/<esn>/<nam>/Provision.MOBILE-DN/

OTAP.Value: {10} nnnnnnnnnn

the Mobile Directory Number from IS-683A has BCD-encoded digits that represent the phone number 📞 it's stored as a string of 10 or more ASCII digits, like "6195551212" 🦋

CDMA NAM

Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.CDMA-NAM/

OTAP.Value: {13} xx xx xx ... xx

the CDMA-NAM entry from IS-683A (section 4.5.2.3) has at least 100 information bits, depending on how many SID-NID list entries there are 🌈 it's stored as 13 (or more) octets of binary data, and again padding makes sure you get an integral number of octets 💜

IMSI_T

Entry-Path: /OTAP/USER/<esn>/<nam>/ Provision.IMSI_T/

OTAP.Value: {7} xx xx xx xx xx xx xx

the IMSI_T entry from IS-683A (section 4.5.2.4) has 55 bits of information split across five fields 🧚 it's stored left-justified in 7 octets of binary data ⭐

5.1.5.6. Server Roaming Lists 🗺️💅

the ACAP Server gets an entry for each different roaming list configuration a carrier has 🌸 this example assumes the roaming list differs by geography, with subdivisions for tiers of mobile free NVRAM 🧠 so basically, every region has a set of roaming lists for each free NVRAM range 😭

ngl, a carrier can totally do different or extra differentiation (like by phone vendor or product type) just by changing the dataset tree and assigning the right value to the "dataset.inherit" attribute in the provisioning records 🔥 main character energy for carriers, no cap 👑

/OTAP/GROUP/region.NorthEast/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthEast/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthEast/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.NorthWest/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.128-512/
            preferred.roaming.list/OTAP.Value
/OTAP/GROUP/region.SouthWest/free-nv.512-1024/
            preferred.roaming.list/OTAP.Value

5.1.5.7. Requested-Data Record 📝🎀

inside the OTAP dataset there's an entry named "Provision.Requested-Data", and it holds one attribute called "OTAP.Requested-Data" 💖 this attribute is multi-valued. It's either NIL or a list of strings, and each string is the name of one piece of data the server wants the client to supply 🫶

after authenticating, the ACAP client sends a SEARCH command to pull the values of the "OTAP.Requested-Data" attribute from the "Provision.Requested-Data" entry 🔍 then the client processes whatever comes back (if anything) by sending a STORE command to set one or more attributes in the "Client" entry ✨ each value is either the matching mobile value (which can be an empty string if that item has no value), or the special value "[N/A]" if the item doesn't exist or is unknown on the mobile 🙈

this mechanism is super general 🤯 it can be used in the normal OTASP case to change the mobile's dataset based on the mobile's condition. For example, inheritance could be set based on how much NVRAM is available, so one set of preferred roaming list data or another gets used 🌈 it can also be used in other situations, like pulling a full set of mobile configuration parameters for diagnostic reasons 🩺

5.1.5.8. Sample Server Entry 🦋

this entry is an excerpt of a sample ACAP server dataset entry for one mobile station, with an ESN of FB9876E 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"
   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
                                       xx xx

this dataset shows not only the provisioning data that got downloaded into the mobile station 📲 it also shows the client data the server asked for (the Requested-Data attribute) and the values of those items (the "Client" entry) 💅 it also tells us the mobile client successfully stored the values tied to the modtime "199812181703" ✅ and it shows this client inherits data (aka roaming lists) from the "NorthEast" region 🌸

5.1.6. Administrative Client 🧑‍💼💜

the administrative client loads the initial provisioning info into the server, including specifying which roaming list to inherit 📥 it also updates provisioning server records as needed, and pulls data for reports (like a list of clients that haven't been updated yet) 📊

data gets loaded into provisioning records with the ACAP STORE command 💾 the administrative client authenticates to the ACAP server using credentials that allow access to the datasets for mobiles 🔑

when a new mobile is authorized for service, the administrative client creates the dataset by storing values that are specific to that device 🌟 it also sets the "dataset.inherit" attribute so values that aren't tied to the specific mobile get inherited where appropriate 🫶

  • Updates to user records 🔄

existing user records may need updating from time to time 🙈 for example, a user might change service plans or buy an additional or replacement mobile device, or the carrier might need to change some part of the provisioned data 💅

  • Perusal and editing of provisioning records 👀

the administrative client can provide general browse and edit capability for user records 🦋

  • Report generation 📈

the administrative client can extract data from the ACAP server to generate reports 🧚 for example, after OTAPA activity, a carrier may want to identify the mobiles that haven't been updated yet 💖

  • Queuing of OTAPA sessions ⏳

depending on which OTAPA update procedures are chosen (like SMS, CLID, or periodic recheck), the administrative client may be involved in starting the activity 🌈 this may or may not use an interface to the provisioning server 🎀

5.1.7. Mobile Client

okay bestie, the ACAP mobile client is a state machine that does the equivalent of IS-683A provisioning parameter information exchange and non-volatile memory storage 🎀 here's the state diagram (Figure 2) and the steps:

[Figure 2 -- see PostScript version]
  • Establish Transport Layer/Authenticate

authentication and/or encryption can happen at the application layer and/or at the network/transport layer 🔐

basic ACAP authentication happens at the application layer (so inside the ACAP session), and its baseline form uses the CRAM-MD5[CRAM-MD5] mechanism. if you want, other mechanisms can be used that give more protection and encryption. this all happens after the transport layer is set up, as shown in the client state machine diagram above

Figure 3 shows the CRAM-MD5 authentication mechanism for an unprovisioned mobile. for provisioned mobiles, the shared secret is derived from the A-Key instead of the limited-time N-digit code used for unprovisioned devices 🦋

basic ACAP authentication is the preferred pick for early data-OTASP builds because it's simple, easy to implement, and all the procedures and methods are already in place 💅 stronger SASL mechanisms and/or IPSec can be rolled out later without disrupting the deployed base 🫶

[Figure 3 -- see PostScript version]
  • Requested-data SEARCH

the mobile ACAP client sends a search command asking the server to return the attribute "OTAP.Requested-Data" in the entry "Requested-Data" 🔍

  • Receive requested-data values

the server tells the client what to store by returning one or more values of requested-data in response to the Requested-Data SEARCH ✨

for example, the attribute "OTAP.Requested-Data" in the entry "Requested-Data" might contain four values: "phone-make", "phone-model", "SW-Rev", and "Free-NVRAM" 🌸

  • STORE attribute list

if the response to the requested-data SEARCH returns any values, the client issues a STORE command. each attribute in the STORE command matches one item of requested-data. if the client doesn't recognize an item, it stores the string "[n/a]" 🙈

continuing our example, the client uses this STORE command to write four attributes into the "Client" entry. each attribute name is identical to one value of the OTAP.Requested-Data" attribute (with the prefix "OTAP." added). each attribute value is determined by the respective mobile value 💖

in our example, this STORE command sets the following attributes and values:

 - "OTAP.Phone-Make"     =   "Qualcomm
 - "OTAP.Phone-Model"    =   "pdQ1900
 - "OTAP.SW-Rev"         =   "001.030.0908"
 - "OTAP.Free-NVRAM"     =   "65536"
  • Provisioning data SEARCH

the mobile ACAP client sends a search command to grab any provisioning data that changed since it last checked in (so on the first session, it gets everything) 🧚

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 the supplied value (which is zero for an unprovisioned mobile) 📋

  • Receive provisioning data and modtime

the server returns the provisioning items, each as one entry name and one attribute value. the server response to the SEARCH command includes the modtime of the latest entry returned 👑

  • Save values

the mobile writes the returned values into NVRAM 💾

  • STORE modtime

the ACAP client stores the returned modtime on the server as an acknowledgement that the data was received and NVRAM was updated 🎉

  • LOGOUT

the client issues the LOGOUT command 👋

  • Close transport layer

the client closes the TCP connection 🔒

  • End call

the data call is terminated 📴

5.2. WAP with ACAP

ACAP is so good because it can easily coexist with a WAP-based mechanism, which gives carriers more options 🌈

a carrier can roll out handsets into its service area that use WAP-based provisioning, if it wants, right alongside the ones that use ACAP provisioning. all that's needed is for the WAP server to contain a small ACAP client (or an interface to an ACAP server) 🍓

Figure 4 shows how mobile stations can be configured using a WAP browser. by using an ACAP server for provisioning, carriers are free to deploy mobile stations that use either WAP or ACAP at the same time, as they like. either way, the ACAP server is the source for provisioning data 💜

[Figure 4 -- see PostScript version]

5.3. Network-Resident vs. Configuration Data

it helps to know that wireless devices access two different kinds of carrier-provided data: network-resident and configuration 🧠

network-resident data lives mainly inside the carrier's network. examples include account status, billing detail, service plan options, etc. mobiles may show this info to the user, but it lives in the network. configuration data is different: it affects how the handset operates, usually isn't shown to the user, and must persist in the device 🔧

for network-resident data, the obvious choice is the web. the data is highly interactive and changes over time, so web browsers make a reasonable solution. any appropriate web browser can be used. there are lots of good reasons to put a web browser in a wireless device that has a display and can handle user interaction 🌐

for configuration data, the best solution is ACAP. ACAP is optimized for the job, can be implemented quickly, needs a very small amount of memory, and doesn't depend on a display or any user interaction capability 💅

using the same access method for both types of data would unnecessarily complicate things, leading to more design, development, and debug time and expense. it also makes it harder to offer low-cost devices. since the two types of data are fundamentally different, it's good engineering practice to pick the optimal code and protocols for each 🙌

5.4. Intellectual Property Issues

there are no known intellectual property issues with the ACAP solution ✨ the ACAP specification was developed within the IETF, and no ownership, patent, or other IP claims have been asserted. multiple independent vendors are building ACAP clients and servers, on top of the existing usage in deployed products 🥳

6. Handset Protocol Suites

6.1. ACAP over TCP/IP

Figure 5 depicts the mobile station protocol suite for the ACAP over TCP/IP solution. the mobile station can support both IS-683A OTASP and OTASP over ACAP 📱

[Figure 5 -- see PostScript version]

7. IS-683A Compatibility

7.1. OTASP Operations

to maximize compatibility and let handset code from IS-683A get reused, the data formats used in OTASP over ACAP are identical to the ones used in IS-683A. Section 5.1.5 Data Organization and Capabilities goes into this in more detail 📚

OTASP via IS-683A needs custom design and development for the specific CDMA infrastructure a carrier uses. that can really limit data management capabilities and seriously reduces extensibility. OTASP over data, on the other hand, can run on a generic IP network using an Internet standards-based capability that offers extensible provisioning activities for carriers 🌟

OTASP over data uses a traffic channel, whereas IS-683A OTASP runs over the limited-bandwidth signaling channel 📶

IS-683A OTASP operations are inherently simultaneous voice and data 🗣️ this lets the customer care representative pull information from the mobile station while chatting with the user. OTASP over data services is a data-only solution (at least for now), which makes OTASP operations a bit more sequential and potentially problematic 😬 simultaneous voice and data will fix that issue 🫶

7.2 OTASP Call Flow

the call flow diagram (Figure 6) shows the message sequence and operations for a typical IS-683A OTASP (provisioning) call. any data-OTASP solution must perform all the functions of the IS-683A OTASP call. the proposed solution meets these requirements ✅

[Figure 6 -- see PostScript version]

7.3. OTAPA Operations

data-OTAPA needs the ability to instruct mobiles to originate a data call to the provisioning server. several viable approaches are discussed in sections 3.3 OTAPA Activity and 4.3 OTAPA Requirements 🧩

OTAPA over data has the potential to need far less channel resources to download new information to mobile stations. the ACAP server inherently only communicates changes to the clients, so only the changed information needs to be downloaded to the mobile stations using OTAPA over data via ACAP 📉

7.4. OTAPA Call Flow

the call flow diagram (Figure 7) shows the message sequence for a typical IS-683A OTAPA operation. any data-OTAPA solution must perform all the functions of the IS-683A OTAPA call. the proposed solution meets these requirements 💯

[Figure 7 -- see PostScript version]

8. Alternative Methods

8.1. IS-683A over TCP/IP

one alternative is to port IS-683A to TCP, staying as close as possible to the IS-683A protocol exchange 🤓

Figure 8 depicts the architecture and communications backbone to support OTASP/OTAPA via IS-707 data services with a provisioning server based on the IS-683A OTAF function 🏗️

[Figure 8 -- see PostScript version]

8.1.1. OTAF Server

this provisioning server is modeled after the IS-683A OTAF. the OTAF server performs the specific operations and messaging of IS-683A OTAF, including A-key reauthentication procedures 🔑

Strongpoints:

  1. OTAF and mobile station behavior mirrors IS-683A (reduced duplicate software in mobile station). nearly all procedures are fully 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 be built from scratch 😵
  3. the interface application would require a non-standard interface (and therefore proprietary) to the OTAF server 🚫
  4. end-to-end encryption scheme still needed for full security 🔓
⚠️ the drawbacks list is a lot, so pay attention to items 2 and 4 especially 💀

8.1.2. Interface Application

this function loads all required provisioning-related information from the CDMA network information system to the OTAF server. this includes queuing provisioning transactions and data 📥

8.1.3. Protocol Handset Suite

Figure 9 depicts the mobile station protocol suite for the IS-683A over TCP/IP solution. the OTASP client can support either IS-683A OTASP activities or OTASP activities over the data transport 🎀

[Figure 9 -- see PostScript version]

8.2. Browser-Based Forms 🌸

okay so the next idea is forms embedded in web pages 👀

bestie, this one looks SO cute at first 🥹 You could wrap the provisioning data in custom tags inside a web form. And honestly the perks are real: the handset already has a browser, web servers are everywhere, and everyone kinda knows how the web works ✨

but ngl it gets messy fast 😭 You'd need a meta-protocol for this, and somebody would have to write a fully detailed spec for it. The provider side needs custom software to handle that meta-protocol, and handset vendors would also have to add custom software to their browsers so they can speak it 💀

Also, every phone would need a provisioning-capable browser. Having a browser might be nice, but deciding to require one needs real thought 🧐, especially because of the memory it would eat on every single device 🍓

This would also make the handset browser way more complicated, since it'd be doing provisioning AND browsing. Those two things are functionally different, so the code just doesn't fit naturally inside a browser 🙈. Building it would take a ton more development and debugging time, which hurts time-to-market and cost 💸

And because the web is functionally different from provisioning too, carriers would need a LOT of customization. That means less vendor choice and higher deployment costs 📉

This approach layers custom data on top of a standard protocol 🧁. That means a bunch of design work, and it wouldn't get much open review before deployment, which seriously raises the risk ⚠️. ACAP, on the other hand, has had years of open review and refinement 🏆

It also limits extensibility, and ACAP is super extensible 🦋. It's such a simple protocol that it can be added to a wide variety of applications at low cost, so more apps on the mobile device can share info with servers AND desktop apps 📱💻

9. Conclusion 👑

ACAP gives you a high degree of extensibility, especially in authentication mechanisms, custom attribute handling, and data management 🔐. Because it's an Internet standard protocol, interoperability and integration with lots of different equipment is possible, and carriers aren't locked into any one vendor 🔓. Adding new levels of service and capabilities is also easier, especially integrating with future subscriber devices and apps (for example, email) 📧.

Since an ACAP client is so small, it can go into basically any device, even low-end ones without displays, and it can be added without giving up other features 🧚. A simpler client and a simpler protocol mean shorter development cycles and faster time-to-market 🏃‍♀️.

Because ACAP was designed for exactly this kind of provisioning job, using it can greatly cut the cost, time to market, and support needed for the provisioning server AND the handsets 💰. And since it's an open standard, it's had years of review and experience behind it 🫶.

Another win: ACAP can easily coexist with a WAP-based mechanism, which gives carriers more options and reduces the minimal requirement burden on mobile devices 🌈.

A carrier can deploy handsets into its service area that use WAP-based provisioning, if it wants, alongside handsets that use ACAP provisioning. By using an ACAP server for provisioning, carriers are free to deploy mobile stations that use either WAP or ACAP at the same time, as they choose 🎀.

And the lack of intellectual-property issues? Extra appeal 💅✨.

10. References 📚

  • [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
  • [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP 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 Considerations 🔒

Security shows up in lots of sections of this doc, no cap 😤. Most importantly, it covers how to guard against unauthorized updating of handsets, usurpation of newly-created accounts, compromise of handset security values, and disclosure of carrier proprietary data and handset parameters 🚨. Take these seriously, bestie.

12. Acknowledgments 🫶

Jim Willkie and Marc Phillips contributed greatly to this document, and their help is very much appreciated 💖.

13. Author's Address 🖋️

Randall Gellens
QUALCOMM Incorporated
6455 Lusk Boulevard
San Diego, CA  92121-2779

Phone: +1 619 651 5115
EMail: randy@qualcomm.com

Legal stuff, but I kept it word-for-word so it stays exact 🙏

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💌

Funding for the RFC Editor function is currently provided by the Internet Society. 🌷

📦 where this page comes from