rfc2604.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,581 行 · 第 1/5 页

Gellens                      Informational                     [Page 17]

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]

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]

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]

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]

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]

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.