path: root/doc/rfc/rfc2604.txt

Network Working Group                                       R. Gellens
Request for Comments: 2604                                    Qualcomm
Category: Informational                                      June 1999


          Wireless Device Configuration (OTASP/OTAPA) via ACAP

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 Notice

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

Abstract

   Wireless carriers today are faced with creating more efficient
   distribution channels, increasing customer satisfaction, while also
   improving margin and profitability.  Industry trends are pushing the
   sale of handsets further into the retail channel.  The cost and
   effort of provisioning handsets, activating users, and updating
   handset parameters can be greatly reduced by using over-the-air
   activation mechanisms.  A comprehensive and extensible means for
   over-the-air provisioning and handset parameter updating is required.

   One approach is to purchase EIA/TIA/IS-683A (Over-the-air Service
   Provisioning of Mobile Stations in Spread Spectrum Systems)
   equipment.  The cost of this has led carriers to seek alternative
   solutions.  A very viable means for providing over-the-air (OTA)
   provisioning is to leverage the rollout of IS-707 data services
   equipment, which most carriers are in the process of deploying.  This
   paper presents an approach to OTA provisioning that utilizes the
   deployment of IS-707 to deliver OTA provisioning and parameter
   upgrading.

   IS-707 data services makes available several methods of providing
   over-the-air provisioning and parameter updating.  A well thought-out
   approach utilizing Internet-based open standard mechanisms can
   provide an extensible platform for further carrier service offerings,
   enhanced interoperability among back-end services, and vendor
   independence.

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




Gellens                      Informational                      [Page 1]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


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.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]
^L
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.  Terms

    Application Configuration Access Protocol (ACAP) -- An Internet
    protocol (RFC-2244) that provides remote storage and access of
    configuration and preference information.

    Activation -- A process in which a mobile station and network become
    programmed so that a mobile station becomes operable and can be used
    for cellular service once authorized by the service provider.

    Authentication -- A procedure used to validate a mobile station's
    identity.

    Authentication Center -- An entity that manages the authentication
    information related to the mobile station.

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

    Authorization -- An action by a service provider to make cellular
    service available to a subscriber.

    Call -- A temporary communication between telecommunications users
    for the purpose of exchanging information.  A call includes the
    sequence of events that allocates and assigns resources and
    signaling channels required to establish a communications
    connection.

    Cellular Service Provider -- A licensee of the responsible
    government agency (in the U.S. a licensee of the Federal
    Communications Commission) authorized to provide Cellular
    Radiotelephone Service.

    Challenge/Response Authentication Mechanism using Message Digest 5
    (CRAM-MD5) -- An authentication mechanism which is easy to
    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 as



Gellens                      Informational                      [Page 3]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    RFC 2195.

    Code Division Multiple Access -- A technique for spread-spectrum
    multiple-access digital communications that creates channels through
    the use of unique code sequences.

    Customer Service Center -- An entity of a service provider that
    provides user support and assistance to subscribers.

    Customer Service Representative -- A person that operates from a
    customer service center and provides user support and assistance to
    subscribers.

    Diffie-Hellman Algorithm -- A public-key cryptography algorithm for
    exchanging secret keys.  Uses the equation , where k is the secret
    key.  The equation is executed by each party of the session based on
    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 analog
    and digital operation.

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

    Home Location Registry (HLR) -- The location register or database to
    which a MIN is assigned for record purposes such as subscriber
    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 that
    represents a mobile station's directory number.

    Mobile Station (MS) -- A station, fixed or mobile, which serves as
    the end user's wireless communications link with the base station.
    Mobile stations include portable units (e.g., hand-held personal
    units) and units installed in vehicles.

    Mobile Switching Center (MSC) -- A configuration of equipment that
    provides cellular radiotelephone service.

    Mobile Terminal Authorizing System (MTAS) -- A control system that
    provides the capability to load the CDMA network HLR with mobile



Gellens                      Informational                      [Page 4]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    station profile information.

    Number Assignment Module (NAM) -- The mobile station's electronic
    memory module where the MIN and other subscriber-specific parameters
    are stored.  Mobile stations that have multi-NAM features offer
    users the option of using their units in several different markets
    by registering with a local number in each location.

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

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

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

    Quick-Net-Connect (QNC) -- An IS-707 data service capability that
    utilizes the Async Data Service Option number but bypasses the modem
    connection for a direct connection to an IP-based internet.

    Roamer -- A mobile station operating in a cellular system or network
    other than the one from which service was subscribed.

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

    Service Provider -- A company, organization, business, etc. which
    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) -- 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 for comparison.

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





Gellens                      Informational                      [Page 5]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


2.  Feature Descriptions

2.1.  OTASP Feature Description

    The Over the Air Service Provisioning (OTASP) feature allows a
    potential wireless service subscriber to activate new wireless
    services, and allows an existing wireless subscriber to make
    services changes without the intervention of a third party.  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

    The Over-the-Air Parameter Administration (OTAPA) feature allows
    wireless service providers to update a NAM, IMSI, and Roaming List
    information in the mobile station remotely without the intervention
    of a third party.  This capability increases flexibility and reduces
    costs for carriers involved with mass changes that affect every
    handset, such as area-code splits.

    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










Gellens                      Informational                      [Page 6]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


3.  Operation

3.1.  Initial Provisioning Activity

    A new subscriber needs to give the intended service provider
    sufficient information (e.g., name, address, etc.) to prove credit-
    worthiness and establish a record within the service provider's
    billing system.  In addition, the ESN of the mobile station needs to
    be given to the provider.  This may occur in three ways:

    Voice scenario -- A customer care representative collects credit
    information during a voice conversation.  This call is made from a
    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 representative
    creates a record in the CDMA network HLR, thus allowing use of the
    CDMA network.  In addition, a limited-time N-digit password is
    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 user
    inconvenience).  All required provisioning information (including
    the limited-time password) is 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 as
    used in the initial voice call).  This causes the mobile station to
    initiate a provisioning session.

    The mobile station and the provisioning server authenticate, and all
    required provisioning information is downloaded into the mobile
    station.  The user receives some form of notification once the
    activity is complete.  This notification 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 for
    use.

    Forms scenario -- An interactive user interface is presented via a
    browser on the mobile station.  The subscriber fills in the
    requested information. (Note that entering non-numeric data presents
    some user interface challenges on many mobile devices.)

    A back-end server validates the information, and 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 representative.



Gellens                      Informational                      [Page 7]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


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

    The carrier's server validates the information, and 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 this code is
    entered, the actual OTASP operation begins.  Otherwise, the user is
    asked to make a voice call to a customer care representative.

3.2.  OTASP for Authorized Users

    Users already authorized for use of the CDMA network can also
    initiate provisioning activity.  This could happen after being
    directed to do so by a Customer Care representative, either from a
    phone conversation or via mail notification.  This type of OTASP
    activity is needed in cases where the carrier desires to upgrade
    CDMA parameters in the mobile stations or in cases where mobile
    station troubleshooting is needed.

    This type of OTASP occurs in similar fashion to the initial OTASP
    activity.  The mobile station downloads the new provisioning
    information in the same way.

3.3  OTAPA Activity

    Typical OTAPA capability involves upgrading a large number of mobile
    stations.  OTAPA activity needs to be performed in a manner that
    does not impose on revenue bearing CDMA network activity.  OTAPA
    operations are initiated at the customer care center.  This can be
    accomplished 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 occur until
    the mobile station has acquired CDMA service on the carrier's
    network and the notification has reached the mobile station.

    Alternatively, OTAPA can be handled by including a recheck interval
    in the set of data used to provision the mobile station.  When using
    a low-overhead protocol, such as ACAP [ACAP], it is reasonable to
    have a mobile station check in periodically to see if anything has
    changed.  The time of day and/or day of week that such rechecks
    should occur could be included in the provisioning data.

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





Gellens                      Informational                      [Page 8]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


4.  Requirements

4.1.  General Requirements

    IS-683A OTASP operations occur 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
    require that the CDMA carrier have an IS-707 data services capable
    network.  The IS-707 service must 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 ability must exist for the mobile to make a data call
    (optionally) a voice call without a MIN.

4.2.  OTASP Requirements

    The OTASP function requires the mobile station to originate 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 information for mobile stations.  The authorizing agent
    (or software) at the customer care center must be able to add user
    and mobile station information into both the CDMA network HLR and




Gellens                      Informational                      [Page 9]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    the provisioning server during the initial authorizing process.  The
    provisioning server must be capable of servicing a mobile as soon as
    its record is created.

4.3.  OTAPA Requirements

    IS-683A OTAPA is performed by a mobile-terminated call that
    downloads parameters to the mobile station.  OTAPA calls occur
    without user interaction.

    In order to perform OTAPA via data services the network needs to
    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 SMS
    message content can contain any information required by the mobile
    station.  The mobile station would need a simple parser of SMS
    messages in order to know when to originate an OTAPA call, as
    opposed to normal SMS message processing.  The OTAPA call would be
    performed in similar fashion to a registration call.  More
    specifically, the user would not be informed of the call activity.

    There are alternative means that can be employed to initiate OTAPA
    activity; for example, a mobile-terminated voice call with caller-ID
    using a specialized telephone number.  Another alternative is for
    mobile stations to periodically check in with the provisioning
    server to check for updated information.  ACAP, for example, is
    designed for such a model.  The recheck interval, as well as the
    time of day and/or day of week that such checks should be used, can
    be part of the provisioning data sent to the mobile stations.

4.4.  Provisioning Server Requirements

    IS-683A utilizes an over-the-air service provisioning function
    (OTAF) to perform the network-side provisioning activity.
    OTASP/OTAPA via data services replaces the OTAF with a provisioning
    server.  The provisioning server resides on an IP network within the
    controlled confines of the carrier.  The provisioning server must
    perform all the service provisioning and parameter administration
    functions that the OTAF provides.  The provisioning server must also
    have an interface to the carrier's Mobile Terminal Authorizing
    System (MTAS).  This interface serves to synchronize the
    provisioning server with the information in the MTAS.  The specific
    requirements of this interface depend on the capabilities and
    interfaces of the carrier's customer care center system(s).  The
    provisioning server must be capable of receiving dynamic updates
    from the MTAS and have the provisioning information immediately





Gellens                      Informational                     [Page 10]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    available for downloading into the chosen mobile station.  A
    standard ACAP server provides an excellent means to meet these
    requirements.

    The provisioning server must be capable of performing an
    authentication procedure with the mobile station.  This
    authentication mechanism must be capable of authenticating both the
    mobile station and the provisioning server.

4.5.  Security Requirements

    OTASP requires that an authentication procedure be performed to
    validate the mobile station to the provisioning server, while OTAPA
    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 mechanism

    Or:

    * Receiving A-keys from the carrier network.

    Since data OTASP/OTAPA operates 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

    Figure 1 shows a provisioning server in the carrier's intranet which
    supports the Application Configuration Access Protocol (ACAP, RFC
    2244).  An administrative client in the customer care domain updates
    this server using ACAP.  Handsets are provisioned and configured
    using a small ACAP client.

                    [Figure 1 -- see PostScript version]

    ACAP is an open Internet protocol designed to solve the problem of
    client access to configuration and related data.  Among its primary
    goals are protocol simplicity, support for thin clients, and ease of
    operation over limited bandwidth.  ACAP provides a high degree of
    extensibility, especially in authentication mechanisms, specialized
    attribute handling, and data management.



Gellens                      Informational                     [Page 11]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


5.1.1.  Mobile Authentication and A-Key Generation

    The mobile client authenticates with the ACAP server prior to
    performing any activities.  Authentication uses the mobile's ESN and
    a shared secret.  Provisioned mobiles derive the shared secret from
    the A-Key; unprovisioned mobiles use a limited-time password as the
    secret.

    The limited-time password is provided 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
    selects the number of digits, as a trade-off between security and
    user convenience.

    The baseline ACAP authentication mechanism uses the shared secret
    plus a random challenge from the server as input to 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.

    An A-Key is generated using a Diffie-Hellman exchange, as is done in
    IS-683A.

5.1.2.  Mobile Identification

    Provisioning records are identified using the ESN and the current
    NAM in use.

5.1.3.  ACAP Server

    As a standard ACAP server, the provisioning server includes
    configurable datasets and dataset inheritance for the management of
    the data stores.

    The administrative client can use the same simple ACAP protocol to
    load and modify the ACAP server as the mobile stations uses for
    provisioning.  While any implementation-specific mechanisms
    available from the server vendor could instead be used for this
    purpose, the ability to use ACAP can greatly simplify the
    administrative client, as well as make it independent of the server.

    ACAP includes an authentication framework (Simple Authentication and
    Security Layer, SASL, RFC 2222)[SASL].  SASL allows any standard or
    custom authentication and encryption mechanism to be used.  One of
    the most important features of SASL is that it is designed for a
    world in which what is "good enough" security today isn't good
    enough tomorrow.  As the threat model changes, SASL allows higher-
    strength mechanisms to be easily added while supporting already



Gellens                      Informational                     [Page 12]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    deployed clients and servers.  SASL is achieving widespread
    deployment in a number of Internet protocols.

    Strongpoints:  Since the ACAP protocol was designed for precisely
    this type of provisioning activity, its adoption can greatly reduce
    the cost, time to market, and support required for the provisioning
    server.  Additionally, the ACAP protocol provides an open standard
    method for mobile stations and other systems to access the
    provisioning server.  Commercial ACAP servers are being developed by
    numerous companies.  The ACAP client code is very small and simple,
    and thus can be incorporated into virtually any mobile device at
    minimal cost.  As an open standard, the ACAP protocol has benefited
    from years of review and experience.

5.1.4.  Overview of ACAP Structure

    ACAP organizes data by datasets.  The structure of a dataset is
    defined by the dataset class.  Generally, ACAP servers do not have
    knowledge of dataset classes.  This allows the dataset to be
    expanded without modifying the server in any way.  A dataset is an
    instantiation of the dataset class, which is a logical definition of
    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 are
    hierarchical).

    For example, consider the ACAP addressbook dataset class, designed
    to hold names, email addresses, phone numbers, and related
    information for a person's contacts.  A given user may have one or
    more addressbook datasets.  Each entry holds information about one
    person or entity.  Attributes in the entry hold specific items of
    information, such as the given name, surname, various email
    addresses, phone numbers, and so forth.  If an entry is a list of
    people (such as a mailing list or specific group of people), it is a
    subdataset, containing its own entries.  Some clients may look at
    only a subset of the attributes.  For example, a mobile handset ACAP
    client may download only the alias (nickname), name, primary phone
    number and email address of each entry, while a desktop client may
    access all attributes.

5.1.5.  Data Organization and Capabilities

    ACAP provides custom hierarchical datasets.  Server data can be
    organized to fit the needs of the applications using the dataset.





Gellens                      Informational                     [Page 13]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    In OTASP/OTAPA over ACAP, data on the server is organized to both
    take advantage of ACAP capabilities and to use items that are
    identical to IS-683A, allowing for reuse of IS-683A handset engines.

    ACAP servers also support data inheritance.  All data items which
    are physically in the inherited dataset and not in the inheriting
    dataset logically also exist in the inheriting dataset.  This is
    recursive, as the inherited dataset can itself inherit from another
    dataset.  This powerful concept allows potentially large groups of
    mobile stations to inherit items from a single 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 further
    subdivided, for example based on tiers of free NVRAM in the mobile.
    The mobile client need not be aware of this; it happens entirely on
    the server.

    ACAP uses trees to provide the data hierarchy.  These data trees can
    be viewed as similar to the directory/file structure used with all
    common operating systems.  The built-in inheritance mechanism,
    together with the hierarchical structure, makes 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 which belong to individual users.  The
    group hierarchy holds datasets which belong to groups (for example,
    the "Region." groups in section 5.1.6.3  Server Roaming Lists).  The
    host hierarchy holds datasets which are for specific machines or
    systems.

    In addition to providing customizable data trees, ACAP also provides
    several standard datasets for all clients.  There is a capabilities
    dataset that contains information on custom functionality and
    enhanced features available to a specific client or at the site
    generally.  This allows a server to advertise any protocol
    extensions, specialized attribute handling, or other enhanced
    functionality it supports.  A client that needs to use these
    features can thus easily determine what is available before trying
    to use them.

5.1.5.1.  Structure

    We divide the data accessed by the client into provisioning items,
    group items, and client state items.  Provisioning data contains NAM
    items and requested-data items.  Group items (such as preferred
    roaming lists), are not specific to any mobile device.  Group items
    physically exist in their own datasets, but through inheritance
    logically appear in client datasets.



Gellens                      Informational                     [Page 14]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    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
    allowing for extensive custom and diagnostic capabilities.

5.1.5.2.  Conventions

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

    ~ This is shorthand for "user/<userid>".  It is part of the ACAP
    protocol.

5.1.6 Dataset

    Provisioning information is located 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
    are to be downloaded to the mobile, and the prefix "Client." is used
    for items which the client stores on the server.

    Provisioning data within the OTAP dataset is organized as a series
    of items, each of which is stored in its own entry.  The entry name
    is the item name, and the "OTAP.VALUE" attribute contains the item
    value.  This structure permits 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 performing a search which returns the
    "OTAP.VALUE" attribute of all entries 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 all clients which have not received the most recent
    update by searching for all entries named "Client" whose
    "OTAP.modtime" attribute is less than the desired value.

    A partial list of items follows.

5.1.6.1.  Entries and Attributes

    dataset.inherit

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






Gellens                      Informational                     [Page 15]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


5.1.6.2.  NAM Records

    The OTAP dataset class contains an entry for each provisioned
    mobile.  The standard location for provisioning records is:

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

    This tree format allows multiple NAMs per ESN.  The specific entries
    contain data in IS-683A parameter block types.

    For example, the CDMA NAM would be stored in an entry called:

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

    The entries below show how NAM records would be organized on the
    ACAP server:

    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)
        consists of at least 129 information bits, depending on the
        number of SID NID list entries.  This is stored as 17 (or more)
        octets of binary data (padding is used to ensure an integral
        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 contains BCD-encoded
        digits representing the phone number.  This is stored as a
        string of 10 or more ASCII digits, e.g., "6195551212".

    CDMA NAM

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

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







Gellens                      Informational                     [Page 16]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


        The CDMA-NAM entry from IS-683A (section 4.5.2.3) consists of at
        least 100 information bits, depending on the number of SID-NID
        list entries.  This is stored as 13 (or more) octets of binary
        data (padding is used to ensure 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) 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 Lists

    The ACAP Server will have an entry for each different roaming list
    configuration for a carrier.  The example below assumes that the
    desired differentiation for the roaming list is geographic, with
    subdivisions for tiers of mobile free NVRAM It shows that for each
    region there exists a set of roaming lists per free NVRAM range.
    Note that a carrier can easily implement different or further
    differentiation (e.g., by phone vendor or product type) by simply
    changing the dataset tree and assigned the appropriate value to the
    "dataset.inherit" attribute in the provisioning records.

        /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








Gellens                      Informational                     [Page 17]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


5.1.6.4.  Requested-Data Record

    Inside the OTAP dataset is an entry with the name
    "Provision.Requested-Data", which contains one attribute called
    "OTAP.Requested-Data".  This attribute is multi-valued.  It is
    either NIL or contains a list of strings.  Each string is the name
    of one element of data that the server requests the client to
    supply.

    After authenticating, the ACAP client issues a SEARCH command to
    retrieve the values of the "OTAP.Requested-Data" attribute of the
    "Provision.Requested-Data" entry.  The client processes the returned
    values (if any) by issuing a STORE command to set one or more
    attributes in the "Client" entry.  The value of each attribute is
    either the corresponding mobile value (which may be an empty string
    if the item has no value), or the special value "[N/A]" if the item
    does not exist or is unknown on the mobile.

    This mechanism is quite general, and can be used in the normal OTASP
    case to modify the mobile's dataset as appropriate for the condition
    of the mobile.  For example, the inheritance could be set based on
    the amount of NVRAM available, to cause one set of preferred roaming
    list data or another to be used.  This mechanism can also be used in
    other situations, such as to retrieve a complete set of mobile
    configuration parameters for diagnostic reasons.

5.1.6.5.  Sample Server Entry

    The entry below is an excerpt of a sample ACAP server dataset entry
    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]
^L
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
                                           xx xx

    This dataset shows not only provisioning data which was downloaded
    into the mobile station, but also the items of client data requested
    by the server (the Requested-Data attribute) and the values of those
    items (the "Client" entry).  It also indicates that the mobile
    client successfully stored the values associated with the modtime
    "199812181703".  In addition, it shows that this client inherits
    data (i.e., roaming lists) from the "NorthEast" region.

5.1.7.  Administrative Client

    The administrative client loads initial provisioning information
    into the server, including specifying the roaming list to inherit.
    The administrative client also updates provisioning server records
    as needed, and retrieves data for reports (such as a list of clients
    which have not yet been updated).

    Data is loaded into provisioning records by using the ACAP STORE
    command.  The administrative client authenticates to the ACAP server
    using credentials that permit access to datasets for mobiles.

    When a new mobile is authorized for service, the administrative
    client creates the dataset by storing into it values that are
    specific for the device.  It also sets the "dataset.inherit"
    attribute so that values which are not tied to the specific mobile
    are inherited as appropriate.

    * Updates to user records

         Existing user records may need updating from time to time.  For
         example, a user may change service plans or purchase an
         additional or replacement mobile device, or the carrier may
         need to modify some aspect of provisioned data.

    * Perusal and editing of provisioning records

         The administrative client can provide general browse and edit
         capability for user records.







Gellens                      Informational                     [Page 19]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    * Report generation

         The administrative client can extract data from the ACAP server
         in order to generate reports.  For example, after OTAPA
         activity, a carrier may wish to identify those mobiles which
         have not yet been updated.

    * Queuing of OTAPA sessions

         Depending on the OTAPA update procedures chosen (e.g., SMS,
         CLID, periodic recheck), the administrative client may be
         involved in initiating the activity.  This may or may not use
         an interface to the provisioning server.

5.1.8.  Mobile Client

    The ACAP mobile client is implemented as a state machine that
    performs the equivalent of IS-683A provisioning parameter
    information exchange and non-volatile memory storage.  The ACAP
    Client state machine diagram (Figure 2) and descriptions are below.

                    [Figure 2 -- see PostScript version]

    * Establish Transport Layer/Authenticate

         Authentication and/or encryption can occur at the application
         layer and/or at the network/transport layer.

         Basic ACAP authentication occurs in the application layer
         (i.e., within the ACAP session), and in its baseline form uses
         the CRAM-MD5[CRAM-MD5] mechanism.  If desired, other mechanisms
         can be used which provide more protection and encryption.  This
         occurs after the transport layer is established, as shown in
         the client state machine diagram above

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

         Use of basic ACAP authentication is preferred for initial
         implementations of data-OTASP because it is simple, easy to
         implement, and all procedures and methods are in place.
         Stronger SASL mechanisms and/or IPSec can be rolled out in the
         future without disrupting the deployed base.

                      [Figure 3 -- see PostScript version]




Gellens                      Informational                     [Page 20]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    * Requested-data SEARCH

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

    * Receive requested-data values

         The server instructs the client to store attributes 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 corresponds to one item of requested-data.
         If the client does not recognize an item, it stores the string
         "[n/a]".

         Continuing with 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 issues a search command to retrieve any
         items of provisioning data that have changed since it last
         checked in (which in the initial session retrieves all
         provisioning data).






Gellens                      Informational                     [Page 21]
^L
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 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 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

    An advantage of the ACAP solution is that is can easily coexist with
    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 ACAP
    provisioning.  All that is required is that the WAP server 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 simultaneously deploy mobile stations that use either WAP or
    ACAP, as desired.  In either case, the ACAP server is the source for
    provisioning data.



Gellens                      Informational                     [Page 22]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


                    [Figure 4 -- see PostScript version]

5.3.  Network-Resident vs.  Configuration Data

    It is useful to recognize that wireless devices access two different
    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 plan
    options, etc.  While mobiles may access this information for user
    display, it resides in the network.  Configuration data, in
    contrast, affects the operation of the handset, is usually not shown
    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 browsers
    a reasonable solution.  Any appropriate web browser can be used.
    There are many good reasons for having a web browser in a wireless
    device which contains a display and is capable of user interaction.

    For configuration data, the best solution is to use ACAP.  ACAP is
    optimized for the job, can be implemented quickly, requires a very
    small amount of memory, and does not depend on a display or any user
    interaction capability.

    Trying to use the same access method for both types of data
    unnecessarily complicates the solution, leading to increased design,
    development, and debug time and expense.  It makes it more difficult
    to offer low-cost devices.  Since the two types of data
    fundamentally differ, it is good engineering practice to select
    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 developing ACAP clients and
    servers, in addition to 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 is capable of supporting both
    IS-683A OTASP and OTASP over ACAP.

                    [Figure 5 -- see PostScript version]



Gellens                      Informational                     [Page 23]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


7.  IS-683A Compatibility

7.1.  OTASP Operations

    To maximize compatibility and allow for reuse of IS-683A handset
    code, the data formats used in OTASP over ACAP are identical to
    those used in IS-683A.  Section 5.1.5  Data Organization and
    Capabilities discusses this in more detail.

    OTASP via IS-683A requires custom design and development for the
    specific CDMA infrastructure used by a carrier.  This can greatly
    limit the data management capabilities and significantly reduces the
    extensibility of the solution.  Conversely, OTASP over data can be
    implemented on a generic IP network using an Internet standards-
    based capability that provides 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 allows the customer care representative to extract information
    from the mobile station while conversing with the user.  OTASP over
    data services is a data-only solution (at least for now).  This
    makes OTASP operations slightly more sequential and potentially
    problematic.  Simultaneous voice and data will alleviate this issue.

7.2   OTASP Call Flow

    The call flow diagram (Figure 6) depicts 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 requires 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 require far less channel
    resources to download new information to mobile stations.  The ACAP
    server inherently only communicates changes to the clients, thus
    only changed information needs to be downloaded to the mobile
    stations using OTAPA over data via ACAP.



Gellens                      Informational                     [Page 24]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


7.4.  OTAPA Call Flow

    The call flow diagram (Figure 7) depicts 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, remaining 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.  This includes A-key reauthentication procedures.

    Strongpoints:

    (1) OTAF and mobile station behavior mirrors IS-683A (reduced
    duplicate software in mobile station).  Nearly all procedures 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) Interface application would require a non-standard interface
    (and therefore proprietary) to OTAF server.

    (4) End-to-end encryption scheme still needed for full security.





Gellens                      Informational                     [Page 25]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


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 the queuing of 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 is capable of supporting
    both IS-683A OTASP activities or OTASP activities over the data
    transport.

                    [Figure 9 -- see PostScript version]

8.2.  Browser-Based Forms

    Another alternative is to use forms embedded in web pages.

    Encapsulating the provisioning data into custom tags embedded in a
    web form is an idea that at first seems attractive.  There are a lot
    of advantages in having a browser in the handset, web servers are
    very widely deployed, and everyone is familiar on some level with
    the web.

    However, a meta-protocol for this would need to be designed, and a
    fully detailed specification produced.  This solution requires
    custom software on the provider side to handle the meta-protocol.
    It additionally requires handset vendors to add custom software in
    the handset browser to handle this protocol.

    This solution would require a provisioning-capable browser in every
    phone.  While it may be desirable to have a browser, the decision to
    require it needs to be considered carefully, especially in light of
    the memory requirements it would impose on all devices.

    This solution would complicate the handset browser, by requiring it
    to handle provisioning as well as browsing.  As provisioning and
    browsing are functionally dissimilar, this code is not a natural fit
    within the browser.  Implementing this solution would require a
    significant increase in development and debug resources, and thus
    negatively impact time-to-market and cost.

    Also because the web is functionally dissimilar, a high level of
    carrier-side customization would be needed, leading to reduced
    vendor choice and increased deployment costs.




Gellens                      Informational                     [Page 26]
^L
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 for
    open review before deployment, greatly increasing the risk.  By
    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 simple
    protocol, it can be added to a wide variety of applications at low
    cost.  This allows increasing numbers of applications on the mobile
    device to share information with servers as well as desktop
    applications.

9.  Conclusion

    ACAP provides a high degree of extensibility, especially in
    authentication mechanisms, custom attribute handling, and data
    management.  By using an Internet standard protocol,
    interoperability and integration with a variety of equipment is
    possible, and carriers are not locked into any vendor.  It is also
    easier to add new levels of service and capabilities, especially
    integration with future subscriber devices and applications (e.g.,
    email).

    Since an ACAP client is so small, it can be incorporated into
    virtually any device, even low-end ones without displays, and can be
    added without sacrificing other features.  The simplicity of the
    client and protocol directly translate to shorter development cycles
    and faster time-to-market.

    Because the ACAP protocol was designed for precisely this type of
    provisioning activity, its adoption can greatly reduce the cost,
    time to market, and support required for the provisioning server as
    well as the handsets.  As an open standard, the ACAP protocol has
    benefited from years of review and experience.

    Another advantage of the ACAP solution is that is can easily coexist
    with a WAP-based mechanism, giving carriers more options and
    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 ACAP
    provisioning.  By using an ACAP server for provisioning, carriers
    are free to simultaneously deploy mobile stations that use either
    WAP or ACAP, as desired.

    The lack of intellectual-property issues further adds to ACAP's
    appeal.




Gellens                      Informational                     [Page 27]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


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 is discussed in many sections of this document.  In
    particular, the need and methods 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 is covered.

12.  Acknowledgments

    Jim Willkie and Marc Phillips contributed greatly to this document.
    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

















Gellens                      Informational                     [Page 28]
^L
RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


14. Full Copyright Statement

   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.



















Gellens                      Informational                     [Page 29]
^L