Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Phreaking Cellular - Misc. :: acc-fe~1.txt

Authentication Control Channel





From: 

                                   .     .
                                  ...   ...   MOTOROLA
                                 .. .. .. ..
                                .     .     .

                                AUTHENTICATION
                                CONTROL CHANNEL FEATURE

                                EMX 2500 Switching Systems
                                Release Date: September 1997


1. BACKGROUND

Until recently, a cellular system identified a mobile phone solely by the
phone's MIN and ESN.  A shortcoming of the identification process is that
the MIN/ESN is transmitted over the air on unsecured cellular radio control
channels.  These channels are easily monitored to obtain MIN/ESN information
of active subscriber units.  Once the MIN/ESN is known, it can be used to
reprogram a phone into a fraudulent clone of the original (legal) unit.

As cellular telephony becomes more widespread, operators/service providers
bear the increasing costs associated with cloning fraud.  One method
identified to combat fraud is authentication.  The EIA/TIA Authentication
Control Channel capability, as implemented by Motorola on cellular
control/paging channels, provides the cellular operator a means to detect
and block cloned mobiles.  The ability to perform pre-call authentication
on local and roaming subscribers is critical towards providing a complete
cellular service while minimizing lost revenues.  Along with post-call fraud
detection schemes, pre-call authentication affords secure, reliable
operation expected with analog cellular networks.

The initial roll-out of the Motorola authentication product provides
validation of the subscriber unit via the forward and reverse channels
during registration and origination attempts.  System accesses by
authentication capable mobiles will be authenticated for:

  *     local subscribers in the home EMX switch (including roamers within
        the DMX network)

  *     local subscribers roaming outside the home system (IS-41 network),
        provided the serving system is capable

  *     non-local subscribers (i.e., non-Motorola home systems) roaming
        in the Motorola system (IS-4 1), provided the home system is capable

by:

  *     exchanging calculated authentication data via the control channel
        and having the mobile and the cellular infrastructure compare the
        data (per IS-91)

  *     Unique Challenges via the RF control channel

  *     SSD Updates via the RF control channel

2. OVERVIEW                                                     PAGE 2

Throughout most of this document, the assumption is made that a mobile
system access attempt begins while the MS is operating locally in the
subscriber's home EMX switch.  Hence, the originating EMX switch and its
"home" or serving EMX switch are the same.  The basic authentication
processes are similar regardless of the mobile's location.  Other scenarios
may include the MS:

  *     roaming in the domain of another EMX2500 switch while the "home" EMX sw
itch
        acts merely as a "tandem switch" to the HLR (DMX)

  *     roaming in a Motorola EMX switch network, but "homed" (i.e.,served)
        on a foreign MSC (IS-41)

  *     roaming in a foreign cellular network, but "homed" by an EMX2500
        switch (IS-41)

NOTE:   Authentication control procedures applied to a subscriber unit
        originate from the authentication system that the subscriber is
        "homed" on. i.e., Subscribers homed on a Motorola system and roaming
        in a non-Motorola system are authenticated by the Motorola
        authentication infrastructure via the IS-41 inter-network.
        Likewise, subscribers homed on a non-Motorola system and roaming in
        the Motorola system are authenticated by its home system.

---[ Basic Definitions ]---

Authentication - A process whereby the identity of the mobile subscriber
        unit is verified.  Information (derived from encrypted source data)
        is exchanged during verification to maintain security.  The system
        operator then has the ability to detect and disable cloned mobile
        subscriber units.  Authentication services provided by cellular
        infrastructures and subscriber units are defined by IS-91A, IS-54B,
        IS-95A, and IS-41C industry standards.

CAVE - Cellular Authentication and Voice Encryption is a cryptographic
        algorithm present in the authentication network and the mobile
        subscriber unit. it is used to generate data for exchange between a
        cellular subscriber unit and its network.

A-key - Authentication Key is a unique and secret bit pattern used by the
        CAVE algorithm to generate and update "shared secret data" in the
        authentication process.  It is stored in the mobile station and in
        the authentication subsystem(s).

SSD - Shared Secret Data is a secret number generated and stored in the
        mobile station and in the authentication subsystem.  It is derived
        from the A-key when the CAVE algorithm executes using that A-key.

Registration - The process whereby a mobile subscriber unit makes its
        location known to the controlling cellular system, and subsequently
        to its home (HLR), thereby enabling it to originate and/or terminate
        calls.

Origination - The process whereby a mobile subscriber unit initiates a call
        by accessing its controlling cellular infrastructure and delivering
        dialed digits.

Fraudulent Subscriber Service - A feature enabled on the HLR, whereby the
        status of a subscriber unit may be marked as fraudulent in the HLR
        database.  Service for a subscriber marked fraudulent may be denied
        or limited in some way.  Either the system sets this status as the
        result of an authentication operation or it is set manually by the
        operator.


2.1 DESCRIPTION                                                 PAGE 3

Fraud detection using IS-91 authentication procedures requires the existence
in a cellular network of some centralized entity, which in Motorola systems
is provided by an Authentication Center (AC) subsystem.  The Authentication
Control Channel feature is a purchased special product (SP) for the HLR and
EMX 2500 switch that enables system-wide support of the Authentication
Center (AC).

NOTE:   The feature is referred to as: "Authentication - Control Channer" on
        the EMX 2500 switch feature list.

Additional functionality is required of the EMX 2500, SAS, HDII (SCSC), HLR
and IS-41 Converter subsystems to support authentication.  Of course, mobile
subscriber units must support the IS-91 authentication functionality in
order to be authenticated.  Non-authentication capable mobiles (as well as
suspected clones) may be granted access as defined and permitted by the
operator.  A simplified diagram of the cellular network architecture for the
Authentication feature is shown in Figure 1.

Using a unique authentication key stored in the AC and in all subscriber
units manufactured since January 1996, data is generated by both the AC and
the subscriber unit which is unique to each subscriber unit.  To ensure that
the unit has the correct A-key as determined by the AC, "unique challenges"
and "shared secret data update" orders can be issued to the phone when
necessary.

Currently, the MS is authenticated on both registrations and originations
while operating in Motorola systems.  Other access types are authenticated
in non-Motorola systems capable of supporting authentication.

The process begins when a system access is attempted.  The subscriber unit
executes an authentication algorithm called CAVE and sends the result to the
base station.  The algorithm executes using information such as the
subscriber unit MIN (or Dialed Digits if originating), ESN and shared secret
data (SSD).  The result is passed on to the AC via the base station, MSC
(and IS-41 if necessary), and HLR.  Then the AC executes CAVE using its
version of the same information and compares the result to that received
from the MS.  If they match, then the MS has passed authentication and
normal call processing activities continue.

If they do not match, then authentication has "failed." Either further
attempts at authentication can be initiated, or the access may be processed
normally, or the MS can be marked as "fraudulent" and denied service.  If it
is determined the MS is fraudulent and is marked as such in the HLR
subscriber record, the unit can be effectively disabled for all cellular
activities except special emergency originations such as a "911". (Or it
can receive other treatment as defined by the cellular operator.)

The desired outcome of the authentication process is that the operators
provide the legitimate subscriber access to the cellular system resources
without additional delay, with total transparency, and with assurance that
associated billing will be accurate.  This can occur only when the system
demonstrates that the MS and the AC each possess identical copies of SSD.


2.2 SYSTEM ARCHITECTURE                                         PAGE 4

A call attempt should be validated by the subscriber's home system
(regardless of its location within cellular networks).  Therefore,
accessibility to authentication service infrastructure must be consistent
end-to-end throughout the cellular network (including EMX switches and other
MSCs accessed via DMX and IS-41 interfaces).  That is, all subsystems and
interfaces involved in the authentication process must either support or be
transparent to the process.

An authentication capable system consists of EMX 2500 switches, HLRS, IS-41
Converters, MSCS, Base Stations and associated networking elements that pass
authentication information between the AC and authentication-capable
subscriber units.  After a call has been validated and successfully passed
authentication, and if the subscriber profile indicates the mobile is
legitimate, call processing continues with the subscriber's serving EMX
switch maintaining the record of call activity (handoffs, feature
activations, disconnects, etc.).

The AC, along with the HLR, stores and maintains authentication information
in separate databases on a per-subscriber basis.  The AC and HLR execute
procedures needed for authenticating mobile stations within the HLR's
database domain, regardless of the physical location of the MS.  The
Motorola AC functionality resides on the HLR platform and most
authentication operations are performed by the MS and the HLR/AC.  With some
exceptions, the other system components and interfaces act essentially as
transport mechanisms to exchange data between the MS and AC.  The primary
function of the EMX 2500 switch in analog systems is to generate, distribute
periodically, and resolve a random number (RAND) used by the algorithms
executed in the MS and AC.  Non-Motorola MSCs may have additional
authentication functionality.

NOTE:   The HLR is the primary repository of all subscriber data and
        performs the same functions as the home EMX switch regarding
        subscriber validation, feature activation and service logic, and
        information updates, etc.

If a system access (i.e., registration or origination) is attempted by the
mobile and its subscriber file does not exist in the local EMX switch, HLR
or VLR, then a remote authentication request is performed by the visiting
switch to the home HLR or MSC (via DMX or IS-41).  Primary functions are
described in the following section.




2.2.1  Major Subsystem Components                               PAGE 5

Major network components required for Authentication functionality are
shown below.
                                ,----------.                 ,----------.
                                |SCP ,---. |                 |SCP ,---. |
                                |    |HLR|.|..               | ...|HLR| |
                                |    `---' | :               | :  `---' |
                                |    ,---. | :..."mated"HLRs.|.:   ,--. |
                                |    |AC |.|.:               | :...|AC| |
                                |    `---' |                 |     `--' |
,----.    ,---------.           `--:-------'                 `----------'
|PSTN|----|MSC      |....D.M.X.....:
`----'    |EMX 2500 |                 ,---------.               ,--------.
          |  Switch |....D.M.X........|IS-41    |               |IS-41   |
          `-:-----:-'                 |Converter|.....IS-41C....|Cellular|
,--.        :     :                   `---------'               |Networks|
|MS|        :     :                                             `--------'
`--'        :     :
(cell     ,-:-. ,-:--.
phone)    |SAS| |SCSC|           ----- Voice Trunks
IS-91     `---' `----'           ..... Data and/or Signalling Channels
         Base Stations


Figure 1. Authentication-Capable Cellular Network



Authentication Center - The AC functionality is an application program
        running co-resident with the HLR on the same Tandem - K2000
        platform.  It provides a centralized location for subscriber
        authentication services.  Utilizing mobile subscriber authentication
        data and authentication algorithms, it performs the decision-making
        process of authenticating an MS as well as other authentication
        related services.  The AC application is queried by the HLR
        application whenever a system access by a subscriber defined as an
        authentication-capable MS is required.  Primary functions of the AC
        include cryptographic algorithm storage, execution of CAVE, "shared
        secret data" generation and storage, and A-key database entry,
        generation, and storage.

Base Station - Cells must be capable of supporting authentication data
        transfer on forward and reverse control channels.  Motorola SAS and
        SCSC cells with appropriate software, support the analog
        authentication control channel feature.  Authentication is equipped
        on a per-cell basis.

Electronic Mobile Exchange - The EMX 2500 switch is a Motorola mobile switch
        that provides basic call processing and routing for subscriber units
        operating under control of Motorola base stations.  Its role in the
        authentication process is to generate and distribute a random 32-bit
        number called RAND to the base stations, resolve an 8-bit RANDC to
        RAND during a mobile access attempt, and pass the mobile's
        registration or validation requests (with RAND) on to the HLR or
        Mobile Switching Center.

Home Location Register - The HLR functionality is an application program
        running on the Tandem K2000 platform.  It is the location of a
        permanent centralized subscriber database with service-effecting
        information including service profiles and last known location
        (paging area, MSC, etc.) for a subscriber unit.  The HLR provides
        subscriber and feature validation, feature control logic and call
        routing on a per-subscriber basis and it provides some
        authentication functionality (in conjunction with the AC).  It is
        usually co-located with an EMX switch and may support multiple EMX
        switches within DMX networks.  Multiple HLRs may be networked in
        mated configurations for redundancy and/or load sharing.

IS-41 Converter - A network interface gateway subsystem that translates
        Motorola DMX protocol to IS-41 and vice versa.  It also serves as a
        limited Visitor Location Register (VLR) for roaming mobiles.

Mobile Subscriber or Subscriber Unit - The MS unit is a portable handset
        that by virtue of IS-91 A compatibility is capable of exchanging
        authentication parameters and data via cellular paging and access chann
els.

Besides the ESN, the MS may be manufactured with an additional
identification number (the A-key) already installed.


3.      FUNCTIONAL DESCRIPTION                                  PAGE 6

3.1     Basic Operation

Authentication of a mobile subscriber is the process by which information
derived using a secret authentication key is exchanged between a mobile
station and the Authentication Center for the purpose of confirming the
identity of the mobile station.  The authentication key is referred to as
the A-key and is used to produce the Shared Secret Data (or SSD-see Note 1)
in the MS and AC.  It is known only by the authenticating system and the
mobile station.  The A-key and SSD are not sent over any cellular system
interfaces, including over the air.  Although the functionality of sharing
SSD across visitin(y systems is defined, Motorola does not implement that
capability.  The A-key is not displayable by the cellular operator or
subscriber (see Note 2).

The following is a brief description of the authentication process for local
subscribers "homed" on the Motorola system and operating in the home area.
Motorola "homed" subscribers roaming to foreign systems (i.e., non-Motorola)
are handled identically except the MS then communicates directly with the
foreign system and indirectly interacts with the Motorola HLR/AC "home"
subsystems via the Motorola IS-41 Converter.  Additionally, the HLR/AC will
support voice channel authentication functionality if requested by a foreign
system via IS-41.  Subscribers "homed" in foreign systems and roaming in the
Motorola network are also handled the same, except that the MS is directly
communicating with the Motorola system and indirectly interacting with its
authenticating "home" system.  In the latter case, although the home
(authenticating system) can request that certain authentication procedures
occur by sending appropriate commands/requests via the IS-41 links, the
serving system has ultimate control over call processing actions regardless
of the outcome of the authentication process.

Most authentication-related operations are performed by the MS and the AC.
Results of failed authentication operations are highly configurable in the
HLR/AC by the operator, and to a lesser extent in the IS-41 Converter and
EMX switch.

The process begins when a mobile station initiates a system access via an
authentication capable Base Station.  Assuming the control channel Overhead
Message Train (OMT) has the AUTH bit turned on, the MS generates an 18-bit
authentication response parameter (AUTHR) utilizing CAVE with specific input
data (see Note 3).  AUTHR and RANDC are included in the mobile's
authentication response portion of the RECC access request message.  The EMX
switch resolves RANDC to RAND, then the registration or validation message
is routed to the HLR via the cellular network (MSC, IS-41, EMX switch).
First, the HLR performs routine checks such as digits check, ESN check, type
of service allowed, etc.  Then it checks if the MS has been marked
"fraudulent".  If not, then the authentication request is sent on to the AC
as an authentication request (Invoke).  The AC does another ESN check (see
Note 4), then begins the authentication process.  The AC generates its
version of AUTHR using CAVE and the same data values, except it uses its
current copy of SSD for the mobile.  The AC compares the two ALTI'HR values.
If the two values of AUTHR are identical, the subscriber unit is considered
"authentic".  The rest of the access sequence is processed normally and the
subscriber is allowed service.

If the AUTHR values are not identical and the access is for a Registration,
then any of a number of results may follow.  Either the registration is
allowed anyway, or registration fails and the system invokes a Unique
Challenge process (see next section), or registration fails and the MS is
immediately marked "fraudulent" due to an authentication mis-match. i.e.,
"Fraudulent Service" is activated.  If the Unique Challenge fails, the
registration may still complete and MS may still be allowed access or the
SSD Update process may be invoked.  Other scenarios may be configured by the
operator.

If the ALTTHR values are not identical and the access is for an Origination,
then the call can (at the operator's discretion) either be blocked or
connected (connected possibly with certain limitations).  The call can be
blocked or terminated by routing the call to a special call treatment.
"Fraudulent Service" may also be activated for that subscriber MIN in the
HLR ( i.e., marked fraudulent).

                                                                PAGE 7
A unique case occurs when the MS has not completed the initial SSD Update
process (see next subsection).  In this instance, the the MS can still be
allowed origination service if a "SSD Update Failure" indicator is below an
operator-defined threshold.  How this situation is handled is configurable
by the operator.

The HLR can control whether an authentication failure or event can block a
call or let it go through.  The HLR's decision to block the call is
indicated to the EMX switch via the following CFCs.

B9 - Authentication was performed on an originating mobile, the mobile
failed authentication with an AUTHR mismatch, and the HLR did not override
the failure.

D9 - An originating mobile previously has been marked fraudulent, either
automatically or manually. DA - A terminating mobile previously has been
marked fraudulent, either automatically or manually.

DB - An originating mobile and serving system are capable of authentication,
but authentication could not be performed for one of the following reasons:

* an originating mobile did not send authentication parameters, even though
  the system requested them, and the HLR did not override this condition.

* the mobile's RANDC could not be resolved to a RAND, and the HLR did not
  override this condition.

* the mobile has not performed an SSD update, and it has exceeded the number
  of allowed originations (if limiting originations is activated in the AC).

Note that the EMX switch can override CFCs B9, D9, and DB and allow the call
to continue, based on the values of the OCOS, EOCOS, TCOS, and ETCOS in the
CP DEFPKG AUTHEN entry (for CFC B9 and D9) or NOAUTH entry (for CFC DB).
CFC DA can not be overridden.

The EMX switch may indicate the status of the authentication attempt with
status codes contained in the MCON 917 IPR.

Note 1. SSD - Shared Secret Data, is a calculated 128-bit number stored in
the MS and in the AC, and is derived using a random number (RANDSSD), the
subscriber unit's ESN, and the A-key as input variables to the CAVE
algorithm.  A 64-bit subset of the number for authentication is the most
critical input to CAVE for determining AUTHR values.

Note 2. Displayable A-key - An exception to this is that a newly created
A-key is displayed once to the operator immediately after the AC has
generated it.  At that time, it is noted and then manually entered into the
subscriber unit.

Note 3. CAVE - Cellular Authentication and Voice Encryption, is an algorithm
that has the ability to calculate a unique number from a particular set of
input variables.  It always produces the same number if given the same set
of inputs. (Some inputs are generated using CAVE and the A-key with openly
attainable inputs such as RAND and MIN or ESN .) For example, to calculate
AUTHR data inputs to CAVE include: K4[Nl, ESN, SSD - A, RAND, DGTSDIAL.

Note 4. MIN/ESN - Subscriber information such as MIN and ESN is maintained
on both the HLR and the AC.  The MIN to ESN check is made in the HLR (as
done prior to the advent of authentication capability).  A benefit of this
is that subsystem resources are not wasted (particularly, the AC) if a
MIN/ESN check fails at the HLR. (There is no need to continue the process in
the AC.) The AC also maintains this information for several reasons.  One,
because the A-key and SSD is maintained only in the AC on a per MIN basis,
the AC must be able to associate each MIN to its A-key/SSD.  The AC
application was designed to be independent of HLR database considerations
and hence, the MIN/ESN functionality is integral to the AC.  A caveat is
that the AC's MIN to ESN check may fail due to subscriber database error.



3.1.1   Unique Challenge                                        PAGE 8

In addition to the basic authentication process described previously, two
other processes are required.  They are Unique Challenge and SSD Update.  A
number of scenarios exist for which the authentication system will utflize
these special functions.  The scenarios are operator-configurable in the HLR
and AC.

If the result of any comparisons indicate a mismatch, the AC may attempt a
Unique Challenge.  If the mobile station continues to fail Unique Challenge,
the subscriber's profile may be marked fraudulent in the HLR.  Subsequent
system access attempts will be treated as defined by the cellular operator.

Unique Challenge

The Unique Challenge (UC) is a method by which the system may challenge a
particular MS to prove its authenticity.  UC may be initiated for the
following situations:

1. By the AC as a result of an AUTHR mismatch on registration.
2. By the AC, required as part of the SSD Update procedure.
3. By the AC if a UC failed previously.
4. By the operator at the AC Subscriber function screen. (i.e., manual UC).
5. By the HLR as a result of a RANDC mismatch.
6. By the HLR as a result of missing authentication parameters in the request.
7. No response from a previous attempt (if Retry is enabled at the AC).

A mismatched Authentication Response for AUTHU indicates the mobile may be
fraudulent (see Note 5).  On registrations, the first instance of a
mismatched AUTHR may result in the AC executing the Unique Challenge
procedure if desired by the operator. (Unique Challenge is not performed on
originations because the subscriber unit will have retuned to a voice
channel.  Voice Channel Authentication is not supported at this time except
when the MS is roaming in a foreign system with that capability.)

Unique Challenge is initiated by the AC by generating an authentication
response (AUTHU) using specific data (including the AC's SSD and RANDU).  A
Unique Challenge request and the authentication response (with AUTHU and
RANDU) are sent by the AC to the HLR (and serving MSC), which saves the A
response and sends the request (w/ RANDU) on to the MS.  The MS generates
an authentication response based on the data and its SSD, and returns an
authentication re- sponse (including its AUTHU) which is routed to the
serving MSC and HLR (see Note 6).. The MSC or HLR reports the result (match
or mis-match) back to the AC. If the AUTHU responses generated by the AC and
MS match, then the MS is successfully authenticated. In the case of a Unique
Chal- lenge AUTHU mismatch, the procedure may be followed by an SSD Update
procedure to force the mobile to have correct valid Shared Secret Data. (The
mobile could have an invalid SSD (see Note 7).  The operator must configure
what the system does next in response to an AUTHU mis-match.

Note 5. Unique Challenge responses include AUTHU and RANDU instead of AUTHR
        and RANDC.

Note 6. The serving non-Motorola MSC performs the AUTHU comparison instead
        of the HLR. The comparison result is sent to the HLR via an IS-41
        ASReport message.

Note 7. For the UC operation to succeed, the MS and AC must have first
        performed an SSD Update procedure to establish a mutual Shared
        Secret Data number.

                                                                PAGE 9
                      Unique Challenge
        Mobile                              Infrastructure
             MS                                    HLR                   AC
             |                                      |   AUTHREQ Response  |
             |                                      |<-----save-AUTHU-----| 1.
             |<--unique-challenge-order(RANDU)------|2.    send RANDU     |
AUTHU      3.|---unique-challenge-repsonse(AUTHU)-->|                     |
calculated 4.|                                      |                     |
             |                                      |--ASREPORT-Invoke--->|
             |                                      |                     |


1.      The AC generates a RANDU, then calculates AUTHU using RANDU, the
        mobile's ESN (from the AC database), MIN1, MIN2, and the
        precalculated SSD-A.

2.      The HLR initiates a Unique Challenge message (with RANDU) to the
        mobile.

3.      The mobile calculates AUTHU using RANDU, its MIN1, MIN2, ESN, and
        the precalculated SSD-A with CAVE.

4.      The mobile transmits a Unique Challenge response message with its
        AUTHU back to the HLR (or MSC if IS-41).

5.      The H LR (or MSC if IS-41) compares the MS AUTHU with calculated
        AUTHU.  If they match, the Unique Challenge succeeds; therefore, the
        mobile is NOT a clone.

3.1.2   SSD Update

Along with the A-key, the "Shared Secret Data" is the most critical secure
data common to the AC and MS.  It is required for input to the CAVE
algorithm during accesses and Unique Challenges.  The AC must execute the
SSD Update procedure at least once with the MS in order to support
successful authentication procedures.  The status of the SSD
(current/pending) and its validity are maintained by the AC. The SSD Update
request is initiated by the AC by setting the "SSD Update Needed" indicator
flag in the AC.  The flag is maintained on a per-subscriber basis, and can
be set under any of the following conditions:

1.      When requested manually by the system operator in the AC
        Application User Interface.

        - The operator manually initiates the process for immediate
          execution.
        - The operator manually initiates the process for delayed execution
          by requesting SSD Update on

        Next Access. (This forces the AC's "SSD Needed" read-only flag to
        "Y".  Then, the SSD Update will be performed on the next allowed
        system access.

2.      Periodic SSD Updates.

        i.e., After the initial SSD Update, all subscriber units may update
        their SSD periodically as required by the system.  The frequency of
        the updates is selectable on a per-AC basis.

3.      When the A-key is changed for the MIN / ESN pair, OR added to the
        system database.

4.      When either of two Registration Failure cases occur:

        - Authentication on registration fails and the initial SSD Update is
          Needed for the MS, then the AC will immediately initiate the SSD
          Update.
        
        - Unique Challenge on registration fails and the SSD Update is not
          Needed, then the AC may attempt to update SSD. (Occurrence of UC
          and SSD Update is operator selectable option.)

5.      When the MS has moved into another switch as indicated by the MSCID
        changing. e.g., when the MS which previously registered on its home
        system, now registers on a visited MSC (or vice versa).

6.      If the previous SSD Update failed, or the attempt timed out with no
        response, or has never been attempted.

For a routine authentication operation to succeed, the MS and AC must
havefirst performed an SSD Update procedure to establish a mutual Shared
Secret Data number.  The MS and AC exchange data (including RANDBS) and
execute the CAVE algorithm.  If all inputs to CAVE are valid, the AC
determines that the MS has identical Shared Secret Data.  Once a valid SSD
has been established, as indicated by a successful SSD Update with Unique
Challenge, the authentication process can proceed.



                  SSD Update

        1. The infrastructure determines that a mobile's SSD should be
           updated. (A UC may have failed or the AC's SSD Update Needed
           indicator may be set.) It generates a random number RANDSSD and
           using CAVE, calculates a new value of SSD (referred to as
           "pending").  It then sends the RANDSSD to the mobile in a SSD
           Update order.
        
        2. The MS generates a new SSD using RANDSSD, its ESN and its A-key.

        3. The MS generates a random number, RANDBS, using its new SSD-A and
           sends it to the infrastructure in a Base Station Challenge
           message.

        4. The infrastructure uses its pending SSD-A,the mobile's ESN
           (from database), the mobile's MIN1, and the RANDBS received from
           the mobile as inputs into the CAVE algorithm to produce an AUTHBS va
lue.  Then, sends this AUTHBS to the mobile in a Base Station Challenge respons
e message.

        5. The MS uses its new SSD-A, its ESN, its MlNl, and the RANDBS it
           generated as inputs in to the CAVE algorithm to produce an
           AUTHBS.  The MS compares its AUTHBS to the ACs AUTHBS,

        6. If AUTHBS matches, then the mobile has confirmed that it is
           talking to a legitimate system.  The mobile saves the new value
           of the SSD to use thereafterfor calculating AUTHR or AUTHU and
           returns an SSD Update 'success'.  If the two values of AUTHBS
           mis-match, then the mobile sends an SSD Update "failed".  If
           "failed", then the MS continues to use the current SSD.

        7. If the MS indicated a successful SSD Update, the infrastructure
           initiates a Unique Challenge and sends a Unique Challenge message
           to the mobile.

        --Unique Challenge--
        8. The infrastructure generates a RANDU, then calculates an AUTHU
           using RANDU, the mobile's MIN1, MIN2, the mobile ESN, and its
           pending (new) SSD-A as inputs to the CAVE algorithm.

        9. The MS uses RANDU received from the infrastructure, its MIN1,
           MIN2, its ESN, and its (new) SSD-A as inputs to the CAVE
           algorithm to generate an AUTHU value.  lt sends this value to the
           infrastructure in the Unique Challenge Response.

        10. The Infrastructure compares the AUTHU it generated to what it
           received from the mobile.  If they match, the infrastructure has
           verified that it performed an SSD Update on the correct mobile.
           If the AUTHUs do not match, the AC sets SSD Status to "unknown"
           and SSD Needed to 'Y".  U.C. status is also set to 'failed" and
           Not Needed.


3.1.3   More Definitions

A-key - A secret 64-bit pattern used to generate and update the Shared
Secret Data in the authentication process.  It is stored in the mobile
station and at the HLR/AC and never sent over the air or shared with other
network subsystems.  A default version of A-key is equipped in the MS at
time of manufacture.  A new unique A-key can be generated by the AC
application and manually programmed into the MS.

AUTH - A 1 -bit field in the System Parameter Overhead Message Train of the
FOCC.  It is used as an indicator that the system supports authentication
procedures.  When ON, it prompts an authentication capable MS to send its
authentication parameters as part of a system access attempt.

AUTHBS - Similar to AUTHR (see below) except, it is used by the Base Station
Challenge process.  The same CAVE inputs are used, except RANDBS is used
instead of RAND.  Dialed Digits (DGTSDIAL) are not used.

AUTHR - Authentication Response (or result) is an 18-bit pattern generated
by the authentication algorithm running in the AC and the MS.  It is an
output of the CAVE algorithm with the following inputs: RAND, SSD-A, ESN,
and MIN1 (or Dialed Digits).  It is used to validate mobile station
registrations and originations.

AUTHU - Similar to AUTHR except it is used by the Unique Challenge
procedure.  Same CAVE inputs, except MIN2 is used along with MIN1 and RANDU
instead of RAND.  Dialed Digits (DGTSDIAL) are not used.

CAVE - Cellular Authentication and Voice Encryption algorithm as defined by
IS-54B (TR45.3). A cryptographic algorithm that's used to generate data for
exchange between the network and the cellular phone.  CAVE must be present
in both the network and the phone.  The CAVE algorithm information is
governed under the U. S. International Traffic and Arms Regulations and the
Export Administration Regulations.

DGTSDIAL - The last 6 digits of the number dialed by the subscriber and sent
as part of the access attempt on originations.  It is one of the parameters
used in the authentication process for originations.  The six digits are
used by CAVE to supplant MIN1 digits.

RAND - A 32-bit random number generated and distributed periodically by the
EMX switch (analog systems) or foreign MSC either for all paging areas or
per area.  It is distributed at pre-defined intervals to all authentication
capable cells under the control of the switch.  RAND is transmitted to the
mobile continuously by the base station (over the air interface OMT).  The
mobile station stores and uses the most recent version of RAND in the
authentication process.

RANDBS - Random Variable for Base Station Challenge used for SSD Update.  It
is generated by the MS.

RANDC - Random Variable Confirmation.  The high 8 bits of the RAND number
used by the switch to confirm the last RAND received by the mobile station.
RANDC is sent by the MS along with AUTHR on a system access attempt.  A
RANDC with a value of zero indicates the mobile does not have the current
value of RAND for the serving system.  The switch tracks the last three
RANDs used.  If no match is found, RAND is considered "unresolved" and is
reported as such to the AC.

RANDSSD - Shared Secret Data random variable.  A 56-bit random number
generated by the mobile station's home system (HLR/AC).  It is used in
conjunction with the mobile station's A-key and ESN to generate a Shared
Secret Data number during the S@D Update process.

RANDU - Unique Random Variable.  A 24-bit random number generated by the AC
and used by it and the MS during execution of the Unique Challenge Response
procedure.

Registration - The process whereby a Mobile Subscriber unit makes its
location known to the controlling system on which it has scanned and locked,
and subsequently, known to the HLR.

SSD - Shared Secret Data is a 128-bit number stored in the mobile station
and in the AC.  Only 64 bits are used for authentication.  Hence, it is a
concatenation of two 64-bit subsets: SSD-A for authentication and SSD-B,
used for Signal Message Encryption and DataNoice Privacy Mask generation.
It is derived using the CAVE algorithm, the A-key, ESN, and a random number
(RANDSSD). It is the most critical input to CAVE for determining AUTHR
values.

SSD Update - A process initiated by the AC at least once that is executed by
both the AC and MS to arrive at a mutually agreed upon SSD parameter for use
during MS authentications.  It is generated and stored in both, and never
sent across an RF air interface.

Unique Challenge - A special authentication attempt usually initiated by the
AC as the result of a previous attempt that failed or indication that the MS
is possibly fraudulent (or some other abnormality).  Also, it may be
manually initiated by the operator (or periodically by the AC) as determined
by the operator. If the serving system is foreign (IS-41), then a system
access with the access type set to "unspecified" may result in an UC.



3.2     Typical Call Processing Scenario - Event Flow Diagrams

This section has call scenario event flow representations to illustrate the
typical flow of authentication message events across system interfaces.
Authentication capability is enabled throughout the cellular network.

NOTE: The Authentication bit in the Overhead Message Train (OMT) of the FOCC
must be turned on.  Therefore, authentication is enabled at the EMX 2500
switch, Base Stations and foreign cellular infrastructure.  When the Auth
bit = 1 (on), the cell is requesting the MS to send authentication
parameters over the RECC during system access attempts, if it is capable.

* Registration - Local MS on Home EMX switch - AUTHR Match - MS information
  Updated

* Registration - Local MS on Home EMX switch - AUTHR Mis-Match, Unique
  Challenge Failure, SSD Update Failure - MS information not Updated

* Origination - Local MS on Home EMX switch - AUTHR Match - Call allowed

* Origination - Local MS on Home EMX switch - AUTHR Mis-Match - Access
  Denied

* Registration - Local MS on Home EMX switch - AUTHR Mis-Match - MS
  information not Updated



3.2.1   Registration Success - MS Local on Home EMX2500 switch

FIGURE


1. Base Station transmits the Authentication ON flag (AUTH= 1) and the RAND
   variable via the OMI

2. MS locks to a control channel, stores RAND and calculates an AUTHR using
   RAND, its ESN, its MINI, and its precalculated SSD-A. Registration

3. MS sends a Registration Request with authentication parameters including
   AUTHR and RANDC (high-order 8 bits of RAND) to EMX switch.

4. BTS immediately returns a registration acknowledgement to the MS.

5. EMX resolves RANDC to RAND, then forwards the Registration request (with
   AUTHR and RAND) to the HLR and AC.

6. HLR performs normal mobile validation checking (e.g., MIN to ESN).  If
   the validation succeeds, then an Authentication Request Invoke is passed on
   to the AC (along with the controlling MSCID).

7. AC calculates an AUTHR usinq RAND, ESN (as stored in the database), MINI,
   and the precalculated SSD-A.  It compares the computed AUTHR to the received
   AUTHR.  They match, so the MS is authentic.  The AC informs the HLR. (AC
   AUTHP = MS AUTHP)

8. HLR updates the MS location information.  Normal call processing follows.



3.2.2   Registration Failure - MS Local on Home EMX2500 switch

FIGURE --------

AUTHR Mis-Match, Unique b-hallenge Failure,
SSD Update Failure
- No MS Information Update -

                Mobile                           BTS    EMX     HLR     AC
                        EMX generates
        alculate        OMT 1.@h@l RAND)        RAND
        AUTHR   Registration Request
                (RANDC, AUTHR)
                Re  'Station

                        calculate,
                ACK     Registration notification               compare AUTHR
                        (RAND, AUTHR)   AUTHREQ Invoke  AUTHR Mis-Match
                                (RAND, AUTHR, ESN, MIN, MSCI'6) 0






                                THREO Return Result     generate RANDU
                Unique   allenge OrdeF,                 calculate AUTHU
                C'              (Deny access, AUTHU, RANDU)
                (IA DU)
        Calculate
        AUTHU   Unique Challenge response

                (AUTHU) 10
        ASREPORT Invoke compare AUTHU
                                        AUTHU Mis-Match


                SSD LJpdate order               SREPORT Return Resul
                                @(D"eny acress, RANDSSD,RANDL
                (RANDSSD)               AUTHU)  generate RANDSSD,
                                        SSD, RANDU, and
        Generate        Base Station Challenge Ord@                     calcula
te new
        RANDBS  (RANDBS)                BSCHALL Invoke  AUTHU


                                (RANDBB)        mm
                Base Station Challenge          BSCHALL Return  Resull
                                (AUTHBS)                calculate AUTHBS
                on ,,n (AUIHBS) 10

        Calculate,
        compare, AUTHBL SSD Update

        AUTHBS  FAILED          ASREPORT Invoke

        Mis-Match

@SREPORT Return Resul

---(No update)---

1. Base Station transmits the Authentication ON flag (AUTH=l) and RAND via
   the OMt.

2. MS locks to a control channel, stores RAND and calculates AUTHR using
   RAND, its ESN, its MIN1, and its precalculated SSD-A.

---Registration---

3. MS sends a Registration Request with authentication parameters including
   AUTHR and RANDC (high-order 8 bits of RAND) to EMX switch.

4. BTS immediately returns a registration acknowledgement to the MS.

S. EMX switch resolves RANDC to RAND and forwards the request (with AUTHR
   and RAND) to the HLR and AC.

6. AC calculates an AUTHR using RAND, ESN (as stored in the database), MIN1,
   and the precalculated SSD-A.  Compares computed AUTHR to received AUTHR.
   They do not match, so MS may be a clone. Since the MS failed
   authentication, the infrastructure can take any one of several actions
   depending on how HLR and AC parameters have been set: e.g., allow the
   registration to continue, fail registration, perform a Unique Challenge,
   or perform a Unique Challenge with SSD update.  In this case, a Unique
   Challenge with SSD Update are initiated by the AC.

---Unique Challenge---

7. AC generates RANDU and AUTHU. (See UC message flow described previously.)
   AC informs the HLR of the AUTHR mis-match and provides RANDU and AUTHU.
   HLR does not update MS information and sends a Unique Challenge to the
   MS.

8. HLR compares the AUTHU received from the mobile with the AC-calculated
   AUTHU.  They do not match (AC AUTHU # MS AUTHO.  The Unique Challenge
   failed, so an SSD Update is attempted to ensure the AC and MS have
   identical "shared secret data".  The HLR reports a UC failure in ASReport
   Invoke message.

---SSD Update---

9. AC generates RANDSSD, new RANDU, SSD, and calculates new AUTHU, see SSD
   Update message flow described previously.

10. MS generates RANDBS using its new SSD-A, see SSD Update message flow
    described previously.

11. AC calculates AUTHBS using RANDBS.  It sends AUTHBS to the MS in BSCHALL
    response message.

12. MS calculates and compares AUTHBS and sends result (failure because of
    AUTHBS Mis-match) back to HLR/AC.

13. HLR/AC may attempt one more SSD Update, or maintain the flags: SSD
    Status="F" and SSD Needed="Y", and wait until MS



3.2.3   Origination - MS Local on Home EMX2500 switch

FIGURE ------

Authentication on Origination
AUTHR Match

Mobile                          BTS                           EMX
             HLR                          AC

IIT 'aulh=l RAND)


Origination access

(RANDC, AUTHR)

Initial Voice Channel

Origination reques

(RANDC, AUTHR)



        Validation Requ
        (RAND, AUTHR)   AUTHREO Inv a



                (RAND. AUTHR, ESN, MIN, MS l@)



                AUTHREO Return Result

                Allow access.
        AC


        I - Validation response         authenticatio

        7,N.--.1 call progression)              performed -
                        AUTHR Matc

1. Base Station transmits the Authentication ON flag (AUTH = 1) and RAND via
   the OMT

2. The mobile calculates an AUTHR using RAND, its ESN, dialed DIGITS, and
   its precalculated SSD-A. (Up to six of the dialed digits supplant the MS
   MIN1 when used as input to CAVE.)

---Origination---

3. The mobile sends an origination message with authentication parameters
   including AUTHR, RANDC (the high-order 8 bits of RAND).

4. The Base Station transmits an Initial Voice Channel (IVC) order message
   to the mobile.

5. The AC calculates AUTHR using RAND, the mobile's ESN (from the AC
   database), the mobile's dialed DIGITS, and the precalculated SSD-A.  The
   AC compares the AUTHR received from the mobile with its own calculated
   value.  They match, so the mobile is authentic.  The infrastructure will
   allow the call (barring any other failures).



3.2.4   Origination - MS Local on Home EMX2500 switch

Authentication on Origination
AUTHR Mis-Match
Access Denied,, Call Not Allowed

Mobile                          BTS                             EMX
                HLR                             AC

OMT (auth=l, RAND)


Origination access

(RANDC,AUTHR)

Initial Voice Channel

Origination

(RANDC,AUTHR)

        Validation Requ
        (RAND, AUTHR)   AUTHREQ invoke
                (RAND, AUTHR, ESN, MIN, MSCID)
                AUTHREO response
                Deny access)    AC
                        authentication
        Validation response             performed -
        (cfc)           AUTHR
                        Mis-Match

1. Base Station transmits the Authentication ON flag (AUTH=l) and RAND via
   the OMT

2. The mobile calculates an AUTHR using RAND, its ESN, dialed DIGITS, and
   its precalculated SSD-A. (Up to six of the dialed digits supplant the MS
   MIN1 when used as input to CAVE.)

---Origination---

3. The mobile sends an origination message with authentication parameters
   including AUTHR, RANDC (the high-order 8 bits of RAND).

4. The Base Station transmits an Initial Voice Channel (IVC) order message
   to the mobile.

5. The AC calculates an AUTHR using RAND, ESN (from the AC database), dialed
   DIGITS, and the precalculated SSD-A.  Compares the computed AUTHR to the
   received AUTHR.  They do not match, so the MS may be a clone.

Since the MS failed authentication, the infrastructure can take any one of
several actions depending on how the HLR and EMX switch are configured to
handle AUTHR mismatch, e.g., all6w the origination to continue, fail the
origination by blocking the call, etc.

Unique Challenge - none
SSD Update - none

6. AC informs HLR of AUTHR mis-match.  At this point the HLR and/or EMX
   switch blocks the call and terminates it to call treatment.


3.2.5   Registration Success - MS Local on Home EMX2500 switch

Authentication on Registration

AUTHR Mis-Match, Unique Challenge Failure, SSD Update Success

                        MS Location, etc.       Updated -

        Mobile  BTS     EMX     HLR     AC

        .-OMT (auth= I, RAND)           EMX generates

                        RAND

Registration Request

(RANDC AUTHR)


        egistration ACK Registration notification               calculate,
                (RAND, AUTHR)   AUTHREO Invoke  compare AUTH
                        (@ND. AUTHR, ESN, MIN, MS i@D)  AUTHR Mis-Mat

        UC order, incl RANDU \ 0,               AUTHREQ Return Result   generat
e RAND
                        (Deny access, AUTHU, RANDU)     calculate AUTH

.@.,,IatesAL)THL)) 7\

UC response
(AUTHU)

                                        ASREPO  compare AUTH

                                                AUTHU Mis-Ma
                                        SREPORT Return Resull



        U       date    0       rder    @eny Access, RANDSSD, RANDU
        (RA     , Dss D)                        AUTHLJ) generate RANDS
                                                SSD,RANDU,A

        Base Station Challenge          calculate new
        (MS calculates RANDBS, AL;THBS) BSCHALL Invoke  AUTHU
                (RANDBS)
        MS compares AUTHBS      BSCHALL Return Resul,
        AUTHBS is-Matc,,        (RANDBS,AUTHBS)
        SSD Updat),             calculate AU
        @Success]
        UC order, incl RANDU    execute another UC
        MS calcu ates A@JTHU    with new SSD

        UC      resdonse
                (AUTHU) ASREPORT Invoke
        MS calculates,
        compares AUTHU
                ASREPORT Return Result  AUTHU Match
                        (Update and Access allowed)

1. Infrastructure transmits the authentication flag (AUTH=l) and the RAND
   variable via the OMT

2. MS locks onto a control channel, stores RAND and generates an AUTHR using
   RAND, its ESN, its MIN1, and its precalculated SSD-A.

---Origination---

3. MS sends a Registration Request with authentication parameters including
   AUTHR and high-order 8 bits of RAND (RANDC) to EMX switc

4. BTS immediately returns a registration acknowledgement to the MS.

S. EMX switch resolves RANDC to RAND and forwards the request (with AUTHR
   and RAND) to the AC.

6. AC generates an AUTHR using RAND, ESN (as stored in the database), M[Nl,
   and the precalculated SSD-A.  It compares the computed AUTHR to the
   received AUTHR.  They do not match, so the MS may be a clone.  The AC
   generates RANDU, then informs the HLR (AC AUTHR #MS AUTHR) Since the MS
   failed authentication, the infrastructure may take any one of several
   actions depending on how the HLR and EMX switch are configured to handle
   AUTHR mismatch. e.g., allow the registration to continue, fail the
   registration, perform a UC, or perform a UC with S update.  In this case,
   UC with SSD Update is initiated by the AC.


---Unique Challenge---

7. AC generates RANDU and AUTHU, See UC message flow described previously.

8. HLR compares the AUTHU received from the mobile with the AC-calculated
   AUTHU.  They do not match (AC AUTHU Unique Challenge failed, so an SSD
   Update is attempted to ensure the AC and MS have identical "shared secret
   data

---SSD Update---

9. AC generates RANDSSD new RANDU, SSD, and calculates new AUTHU, see SSD
   Update message flow described previously.

10. MS generates RANDBS using its new SSD-A, see SSD Update message flow
    described previously.

11. AC calculates AUTHBS using RANDBS, etc.  It sends AUTHBS to the MS in a
    BSCHALL response message.

12. MS calculates and compares AUTHBS and sends the result (success because
    of matching AUTHBS) back to HLR/AC.

---Unique Challenge---
13. HLR requests Unique Challenge to verity correct SSD.

14. UC is successful so MS location is updated.  Registration is successful.


3.3     OTHER CONSIDERATIONS

The following list of limitations, interactions, etc. is not intended to be
comprehensive.  It is highly dependent on the software releases residing in
the various subsystems.


3.3.1   LIMITATIONS

* Local subscribers must be located in the HLR and AC databases in order to
  be authenticated.

* The AC and HLR must be co-resident on the Tandem K2000 Himalaya platform.

Traffic Channel Authentication on Motorola MSCs is not supported.

* Signaling Message Encryption and Voice Privacy features are not supported.

* Terminations in Motorola systems are not authenticated.

* Sharing of SSD with visited systems is not supported.

* Call History COUNT updates are not supported.

* There is no means to regulate the frequency of appearance of the RAND
  field in the control channel Overhead Message Train.  RAND is sent once
  every 5 iterations of the OMT.

* Older HDII and LD base stations (i.e., non-SCSC) do not support
  authentication.

* HD base stations do not support authentication.

* Older non-authentication capable EMX switches ignore authentication
  directives from the HLR.

* Authentication in Motorola systems is supported only by the EMX 2500
  switch series of switches.

---RANDC Resolution---

* +100% correct resolution of RAND is not guaranteed because of air interface
  and network considerations.  The air interface allows a mobile to rescan
  and access a different cell from which it may have obtained its overhead
  information from.  The system attempts to resolve RAND by only attempting
  to resolve on the EMX switch that the access occurred.  If the RANDC is
  not on this EMX switch, the EMX switch does not query adjacent EMX
  switches. (Since each EMX switch may generate its RAND independently, it
  is possible that more than one EMX switch may be able to provide RAND, but
  it may not be the correct R4ND.) In this "border cell" situation, the call
  or registration will fail authentication with "unresolved RAND".  Also, it
  is possible for an AUTHR mismatch to occur in border cell situations when
  the associated MSCs have the same RANDCS, but different RANDS.  In this
  case the serving MSC will "resolve RAND" and send it on to the AC along
  with the mobile's AUTHR (calculated using the original MSC's RAND).  The
  AC will calculate an incorrect AUTHR.

RAND resolution requests from non-Motorola MSCs (IS-41) are not supported.

---SSD---

A prerequisite of authentication execution is establishing a Shared Secret
Data between the MS and the authentication infrastructure.  This requires
some time (perhaps several minutes) while the MS is idle on a control
channel following a registration.  The system must first exchange some data
with the mobile station so that it can generate an SSD before authentication
can be performed on system access.

Page Ack and Flash:

Authentication for Page Ack and Flash messages in the DMX network is not
supported.  Authentication is supported for those messages arriving via
IS-41 (assuming the serving system is fully capable).


3.3.2   INTERACTIONS WITH OTHER FEATURES/CAPABILITIES

The following is a list of known interactions or limitations of the
Authentication feature with other cellular system capabilities.

There are three new CFC codes (D9, DA, DB)

The new CFC codes are not displayed in the CDRs of EMX 2500 switch software
preceding CSR7.5.0 (the CFC field will indicate "unknown")

The existing B9 cfc code is now used to indicate authentication failure, too

There are several new statistics records in the HLR and the IS-41 Converter

No changes to the DAS billing record format

Three-way call originations (i.e., calls initiated by "flash") are not
authenticated (unless for an IS-41 roamer)

Authentication for FAX / Data accesses is not currently supported

3.3.3   EFFECTS ON SYSTEM PERFORMANCE

FOA experience indicated the possibility of potential problems with some
non-authentication capable subscriber units (non-Motorola).

Also, some early authentication-capable models may have problems properly
accessing the system when authentication is enabled in the Overhead Message
Train, e.g., Improper ORDER codes or corrupted data fields sent up in the
access message.

Results of this problem may include increased Unique Challenge message
traffic on Registrations, or blocked call attempts on Originations (CFC DB).



3.3.2   INTERACTIONS WITH OTHER FEATURES/CAPABILITIES

The following is a list of known interactions or limitations of the
Authentication feature with other cellular system capabilities.

There are three new CFC codes (D9, DA, DB)

The new CFC codes are not displayed in the CDRs of EMX 2500 switch software
preceding CSR7.5.0 (the CFC field will indicate "unknown")

The existing B9 cfc code is now used to indicate authentication failure, too

There are several new statistics records in the HLR and the IS-41 Converter

No changes to the DAS billing record format

Three-way call originations (i.e., calls initiated by "flash") are not
authenticated (unless for an IS-41 roamer)

Authentication for FAX / Data accesses is not currently supported

3.3.3   EFFECTS ON SYSTEM PERFORMANCE

FOA experience indicated the possibility of potential problems with some
non-authentication capable subscriber units (non-Motorola).

Also, some early authentication-capable models may have problems properly
accessing the system when authentication is enabled in the Overhead Message
Train, e.g., Improper ORDER codes or corrupted data fields sent up in the
access message.

Results of this problem may include increased Unique Challenge message
traffic on Registrations, or blocked call attempts on Originations (CFC DB).


4.2     EMX 2500 SWITCH

Below is information on EMX switch database entries necessary for
implementation of the Authentication feature.  Boldface parameter entries
are recommendations.  Italicized or dashed parameter entries require either
operator-dependent data, or are set by the subsystem itself as the result of
an authentication operation.

        *  Configuring DMX link for EMX 2500 switch (to HLR)
        *  Configuring authentication-related parameters
        *  Configuring Base Station (analog)
        *  Configuring Authentication-Capable Subscribers

4.2.1   NETWORK Requirements

Normal DMX configuration parameters are set for EMX 2500 switch, HLR, and
IS-41 Converter DMX links (i.e., there are no authentication-related
dependencies).

4.2.2   PROVISIONING

Authentication is provisioned on the EMX 2500 switch and base stations by
loading an SSDB withauthentication-Control Channel SP bit enabled.  See
document: "INSTALLATION PROCEDURE SP72117, Authentication - Control
Channel"EMX 2500 switch for Software Release 7.5. O.X, 68PO9295A96.

DISP FEATURE                         [Authentication - Control Channel]
SUBSYSTEM AND/OR SYSTEM LEVEL
After the SSDB is loaded, the EMX switch authentication parameters are
configured using the CHANGE CP AUTH MMI command.  Three parameters must be
set.

RAND Generation PA/E                       PA
RAND Interval   1-1440min                 60
(Initially, start at 60, then reduce until the number of RAND mismatches are
acceptable.)

Authentication IPR

N/C/E/B

[ N ]



4.2.3 ENABLE

The Authentication feature is enabled automatically when SSDB files with the
Authentication-Control Cliannel SP are loaded.

Define call processing DEFPKG via C@GE CP DEFPKG MMI command.

        AUTHENTICATION FAILURE OR FRAUDULENT MOBILE: OCOS, TCOS (AUTHEN package
)
        CANNOT AUTHENTICATE AUTH-CAPABLE MOBILE: OCOS, TCOS     (NOAUTH package
)

        Enable Registration via CHANGE CP REGDAT
        REGISTRATIONS ENABLED   (must be enabled)



Setup define authentication-capable subscriber - See next section on
transferring subscribers.
        C/D CP AUTH
        C/D CP FOREIGN
        C/D CP ROAMID
        C/D CP VALNODE
        C/D CP SUBSCR   (na)
        C/D CP ROAMER   (na)
        C/D CP MOBID    (na)
        C/D TRANSFER CP SUBSCR



Enable Authentication for a Base Station via CHANGE CELL FEATURE
AUTH ENABLE          Y/N

(NOTE: Enabling authentication on every cell is not required.)

PROVISIONING - EMX

Authentication is provisioned on the EMX 2500 switch and the cell sites by
the loading of an SSDB with the Authentication - Control Channel SP bit
enabled.  This SSDB must be purchased from Motorola CIG through the usual
means.

After the SSDB is loaded, the EMX switch authentication parameters must be
configured using the CHANGE CP AUTH MMI.  This MMI provides three parameters
which must be set:

RAND GENERATION: This parameter can take one of two values: PAGINGAREA (or
PA) or EMX switch (or E).  If this field is set to PAGINGAREA, the EMX
switch will generate a RAND value for each paging area.  If the field is set
to EMX, the EAff switch will use the same RAND in all paging areas.
Motorola recommends using PAGINGAREA.

RAND INTERVAL: This parameter can take a numeric value between 1 and 1440,
which represent the number of minutes between generations of new values of
RAND.  The default value is 60 (a new RAND is generated each hour).  For
initial deployment, Motorola recommends a value of 60.  Decreasing this
value increases the frequency at which new values of RAND are generated.
This has the effect of making the system more secure, since a bandit can use
information gleaned from monitoring the control channel for a shorter period
of time.  However, increasing the frequency of RAND generation may result in
a higher incidence of unresolved RAND conditions.


AUTHENTICATION IPR: This parameter determines the conditions upon which CALL
917 IPRs are to be generated.  It can take one of four values: NONE (N),
CALLTYPE (C), ERROR (E), or BOTH (B).  If NONE is entered, CALL 917 IPRs
will not be generated.  If CALLTYPE is entered, the EMX switch will generate
a CALL 917 IPR when an indication is received from the HLR that the AC
performed authentication (whether successful or otherwise).  If ERROR is
entered, the EMX switch will generate a CALL 917 IPR when an indication is
received from the HLR that an error occurred during authentication (i.e.,
RAND unresolved, ALJTHR mismatch, time-out, etc.). If BOTH is entered, the
EMX switch will generate a CALL 917 IPR when either authentication is
performed or an error occurs.  Because a large number of IPRs can be
generated, Motorola recommends that this field be set to NONE initially.  It
can be set to CALLTYPE, ERROR, or BOTH during problem debugging as required.
Once authentication is rolled out to the majority of subscribers in the
network, this IPR can be set to ERROR to provide an indication of
authentication problems.

NOTE: The CALL 917 IPR will be eliminated in a future cellular system
release, and the information contained therein moved to the Call Detail
Record (CDR).

PROVISIONING - EMX SWITCH VALIDATION DATABASE

In order for a mobile subscriber to be provisioned with authentication, its
subscriber database must be located on the HLR.  If the subscriber already
exists on the EMX switch, its database must be moved from the EMX switch to
the HLR (either manually or with TRANSFER CP SUBSCR).  Subscribers can be
provisioned on the HLR singly or in groups.

SINGLE SUBSCRIBER ON TFIE HLR

After the subscriber is provisioned on the HLR (either manually or through
TRANSFER CP SUBSCR), the EMX switch validation database must be modified so
that the EMX switch can validate the subscriber remotely on the HLR.  This
procedure must be performed on the subscriber's "home" EMX switch (i.e...
the EMX switch to which the subscriber's MIN range has been assigned).  AB
other EMX switches already should have validation database entries which
point to the home EMX switch, so that these other EMX switches can validate
the subscriber.

To remote a subscriber singly, the following steps are performed on the home
EMX switch:


Step 1. Execute the CHANGE CP ROAMER MMI and remote the subscriber to the
        HLR using the following parameters:

        MOBILE ID(S)              10-digit MIN of subscriber.
        EMX ID:                  EMX switch node number of HLR.


Step 2. If the subscriber already exists and is validated on the home EMX
        switch, its subscriber record must be eliminated from the validation
        database of the home EMX switch using the DELETE CP SUBSCR MMI
        followed by the DELETE CP MOBID MMI.  Note that TRANSFER CP SUBSCR
        may delete the subscriber record, but not the mobid.


GROUP OF SUBSCRIBERS ON THE HLR

Groups of subscribers, in blocks of 10, 100, 1000, or 10000 may be validated
on the HLR.  These groups can be set up from the start, transferred as a
block (either manually or with CHANGE CP SUBSCR)I. or they can be set up
after ten or more individual subscribers are provisioned on or moved to the
HLR (see the procedure above).  As is done when provisioning a single
subscriber, the following procedure must be done on the home EMX switch for
the subscribers.  All other EAff switches already should contain validation
databases that point to the home EMX switch.  Also, the following procedure
should be done only after the subscribers have been provisioned on the HLR.

Note that only subscribers with consecutive MINs can be moved in this
procedure.  Also, the subscribers must share the first 9 MIN digits for a
block of 10, first 8 MIN digits for a block of 100, first 7 MIN digits for a
block of 1000, and first 6 MIN digits for a block of 10000.

To remote a block of 10 subscribers, the following procedure should be used:


Step 1. Execute the CHANGE CP ROAMID MMI and remote the subscribers to the
        HLR using the following parameters:

        BLOCK SIZE:     10
        TENS-BLOCK NUMBER(S):   First, common 9 digits of the MIN of the
                                subscribers to be moved.
        FOREIGN OR ROAMERS:     R
        EMX ID: EMX switch node number of HLR.


Step 2. If the subscribers already exist and are validated on the home EMX
        switch, their subscriber records must be eliminated from the
        validation database of the home EMX switch using the DELETE CP
        SUBSCR MMI followed by the DELETE CP MOBID MMI.  Note that TRANSFER
        CP SUBSCR may delete the subscriber record, but not the mobid.


To remote a block of 100 subscribers, the following procedure should be used:

Step 1. Execute the CHANGE CP ROAMID MMI and remote the subscribers to the
        HLR using the following parameters:

        BLOCK SIZE:     100
        HUNDREDS-BLOCK NUMBER(S):       First, common 8 digits of the NUN
                                        of the subscribers to be moved.
        FOREIGN OR ROAMERS:     R
        EMX ID: EMX switch node number of HLR.

Step 2. If the subscribers already exist and are validated on the home EMX
        switch, their subscriber records must be eliminated from the
        validation database of the home EMX switch using the DELETE CP
        SUBSCR MMI followed by the DELETE CP MOBID MMI.  Note that TRANSFER
        CP SUBSCR may delete the subscriber record, but not the mobid.


To remote a block of 1000 subscribers, the following procedure should be used:


Step 1. If the subscribers already exist on the home EMX switch, execute the
        CHANGE CP ROAMID MMI and remote the subscribers to the HLR using the
        following parameters:

        BLOCK SIZE:     1000
        THOUSANDS-BLOCK NUMBER(S):      First, common 7 digits of the MIN
                                        of the subscribers to be moved.
        FOREIGN OR ROAMERS:     R
        EMX ID: EMX switch node number of HLR.


Step 2. If the subscribers already exist and are validated on the home EMX
        switch, their subscriber records must be eliminated from the
        validation database of the home EMX switch using the DELETE CP
        SUBSCR MMI, the DELETE CP MOBID MMI, and the DELETE CP

OFFCOD MMI.  Note that TRANSFER CP SUBSCR may delete the subscriber record,
but not the mobid or offcod.


Step 3. Use the CHANGE CP OFFCOD MMI to provision the office code for the
        subscribers so that it indicates that the subscribers are validated rem
otely
        on the HLR using the following parameters:

        NPA: First, common 3 digits of MIN of the subscribers being moved.
        NXX: Second, common 3 digits of MIN of the subscribers being moved.
        1ST X OF XXY-X(S): Seventh common digit of MIN of the subscribers
                           being moved.
        EMX ID: EMX switch node number of HLR.


Step 4. Delete the entry in CP ROAMID set up in step 1. using the DELETE CP
        ROAMID MMI.



To remote a block of 10000 subscribers, the following procedure should be
used:

Step 1. If the subscribers already exist on the home EMX switch, execute the
        CHANGE CP FORIGN MMI and remote the subscribers to the HLR using the
        following parameters:

        1ST 6 DIGITS OF MOBILE:         First, common 6 digits of the MIN of
                                        the subscribers to be moved.
        LOCAL OR REMOTE:                R
        REMOTE VALIDATING EMX ID:       EMX switch node number of HLR.


Step 2. If the subscribers already exist and are validated on the home EMX
        switch, their subscriber records must be eliminated from the
        validation database of the home EMX switch using the

DELETE CP SUBSCR MMI, the DELETE CP MOBID MMI, and the DELETE CP OFFCOD MMI.
Note that TRANSFER CP SUBSCR may delete the subscriber record, but not the
mobid or offcod.


Step 3. Use the CHANGE CP OFFCOD MMI to provision the office codes for the
        subscribers so that it indicates that the subscribers are validated rem
otely
        on the HLR using the following parameters:

        NPA: First, common 3 digits of NUN of the subscribers being moved.
        NXX: Second, common 3 digits of MIN of the subscribers being moved.
        1ST X OF XXXX(S): 0-9
        EMX ID: EMX switch node number of HLR.


Step 4. Delete the entry in CP FORIGN set up in step 1. using the DELETE CP
        FORIGN MMI.

ENABLING - EMX SWITCH

The Authentication feature is enabled automatically when the SSDB with the
Authentication - Control Channel SP enabled is loaded.

ENABLING - ANALOG CELL

Once an analog cell is loaded with firmware capable of supporting
authentication, the authentication feature can be enabled on a per-cell
basis with the CHANGE CELL FEATUR MMI.  The AUTHE-@CATION ENABLE parameter
in this MMI is set to "N" to disable the feature on the cell.  It is set to
"Y" to enable the feature on the cell.  Note that it may take several
minutes before the cell begins to broadcast the appropriate authentication
information on the forward control channel.  During this time. if
authentication is being enabled, there may be system accesses which may fail
due to not sending authentication information, since different devices on
the cell may have different values in their databases.

4.2.4   STATUS and DATA COLLECTION

START IPR CALL 916-917
START IPR MCON 419


4.3 HLR

Below is a list of HLR database entries necessary for implementation of the
Authentication feature. Boldface parameter entries are recommendations.
Italicized or dashed parameter entries require either operator-dependent
data, or are set by the subsystem itself as the result of an authentication
operation.  See the HLR Operations manual for more information.

4.3.1   NETWORK REQUIREMENTS

Normal DMX link configuration parameters are set for EMX 2500 switch, HLR,
and IS-41 Converter links (i.e.. there are no authentication-related
dependencies).

4.3.2   HLR PROVISIONING
INSTALATION - software (see customer release documents for HLR 1.3.0)
0 Configuring DMX
    Configuring Authentication-Capable Subscribers (also see AC section)
    Configuring AC (also see AC and GIN section)
    Configuring IS-41 (also see IS-41 section)

HLR     EMX Networks
[via hmimenu: / HLR Main-Fl / Dbase Access-Fl / EMX NETWORK ID-F7]

Authentication Capable                                                y I


HLR Subscriber Service Definitions
[via utils/hmimenu: / HLR Main-Fl / Dbase Access-Fl / Service Defs-F3]

    Authentication  Provisioned     I y I
    Authentication  Enabled I y I
    Fraudulent Subscriber   Provisioned     I y I
    Fraudulent Subscriber   Enabled (activated)     I y I

    General Authentication Parameters

[via hmimenu: / HLR Main-Fl / Dbase Access-Fl / Service Defs-F3 /
Authentication Prov->Feature Parameters-SF5]
    (Note: on actual HMI screen, X entry = enabled (Yes) - Blank entry      dis
abled (No))
    Authentication of Registrations in DMX network  I y I
    Authentication of C)riginations in DMX network  [ y I
    SSD Updating in DMX network     I y I   (UC is always performed after
                        SSD Update.)
    Unique Challenge in DMX network [ y I   (Applies only to standalone UC.
                        Not those associated with SSD
                        Update.)
    Auth in IS-41 Network   [ y I   (Must be via Motorola IS-41
                        Converter.)

    SSD Updating in IS-41 network   I y I   (UC is always performed after
                        SSD Update.)

Unique Challenge in IS-41 network                 11   11    11


(Applies only to standalone UC.)



DMX Authentication Parameters

[via hmimenu: / HLR Main-Fl / Dbase Access-F] / Service Defs-F3 /
Authentication Prov->Feature Parameters-SF5
        / DNIX Parameters-SF5]          (Note: on actual HMI screen, X entry
 enabled (Yes)
        Activate Fraudulent Serv,iceforfailure of.
        Authentication  N I

        Autonomous Unique Challenge     N I
        Unique Challenge after a failed registration    N I
        Unique Challenge associated with SSD Update     N I
        Allovi Registrationsfor:
        missing Authentication parameters       N I
        unresolved RAND N
        mismatched AUTHR        [N]
        failed Unique Challenge [N]
        Alloii, O?iginations for:
        missing Authentication parameters       [NJ
        unresolved RAND [N]
        mismatched ALTTHR       [N]
        Request L,nique Challengefor.-
        missing Authentication parameters upon Registration     [Y]
        unresolved RAND upon Registration       [Y]

Blank entry = disabled (No))

(X may cause a valid subscriber to lose service.)








IS-41 Authentication Parameters

[via hmimenu: I;' HLR Main-Fl / Dbase Access-Fl / Service Defs-F3
Authentication Prov->Feature Parameters-SF5 IS-41 Parameters-SF6] (Note: on
actual HMI Screen, X entry = enabled (Yes) - Blank entry = disabled (No))

        Activ-are Fraudulent Service in thefollowing cases:
        Authentication failure  [N]     (X may cause a valid subscriber to
                        lose service.)
        Autonomous Unique Challenge failure     [N]
        Unique Challenge failure after failed registration      [N]
        Unique Challenge failure associated with SSD Update     [NJ


        Application Timer Parameters

[via hmimenu: / HLR Main-Fl / Dbase Access-Fl / Service Defs-F3 /
Authentication Prov-> Feature Parameters-SF5 / TimersSF4]

Note:   These wait timers apply to DMX network authentication as well as
IS-41 network authentication.

        ADT     Authentication Directive Response       3-15sec 61
        AFRT    Authentication Failure Report   3-15    61
        ART     Authentication Request Response 3-15    6 ]
        ASRT    Authentication Status Report    5-60    61
        BSCHALL Base Station Challenge  5-60    [28]
        BSCT    Base Station Challenge Response 3-15    [51
        RESCAN  MS to rescan    1-255   [5]
        SSDUPDT SSD Update Response     5-15    [11)
        UNCHALL Unique Challenge Response       5-60    [28]


NOTE

ADT     (AuthDir response from EMXIMSC)

AFRT    (AFReport response from AC)

ART     (AuthReq response from AC)

ASRT    (ASReport response from AC)

BSCHALL (BS Challenge invoke from MS)

BSCT    (BS Challenge response from AC; MS waits up to 5 sec)

RESCAN  (Timer to allow MS to rescan control channel)

SSDUPDT (SSD Update Status from EMX)

UNCHALL (Wait for UC Response from EMX or an ASReport invoke from MSC)

The sum of the five HLR timers: BSCHALL, BSCT, RESCAN, SSDUPT, and UN-
CHALL must be less than or equal to the AC timer- ASRRT

HLR Subscriber Profile
[via hmimenu: / HLR Main-Fl / Dbase Access-Fl / Subscriber Profile-Fl
          Services-SF5]

        MIN, ESN, etc.
        Feat. Pkg.
        Authentication  Provisioned     [Y]     (unit must be auth-capable)
        Authentication  Enabled         (unit-level enable is n/a)
        Feat. Pkg.
        Fraudulent Subscriber   Provisioned     [Y]
        Fraudulent Subscriber   Enabled (activated)             (flag indicator
 set by operator*
                                or system to Y for "fraudulent')

dependent on the operator's requirements.


4.4     AUTHENTICATION CENTER

Below is a list of Authentication Center database entries necessary for
implementation of the Authentication feature.  Boldface parameter entries
are recommendations.  Italicized or dashed parameter entries require either
operator-dependent data, or are set by the subsystem itself as the result of
an authentication operation.  See the HLR Operations manual for more
information.

NOTE:   Those settings with a shaded background are only accessible tbrou a
        spe- cial HMI screen.Ib access this screen, enter- ACACSPSD m the
        Request field and L in the Type field, at the top right of the
        Safevath H SI thenpressF4. Theonlyvaluesthatshouldbecbangedarethose
        ing to Next Action Required, which determines when SSD dates, nique

Challenges,and access restrictio
 areverformed.  Other are for informational purposes.

4.4.1   PROVISIONING

INSTALLATION (software)   (see customer release documents for HLR 1.3.0)

Authentication Center System Parameters File (page 1/3)
[viaSAFEPATH: /SCP@Applications-I/SCPAC-2/ACSYSParameters-1]

        General Fields:
        Authentication Center   I y I
        Automatic A-Key Update  I y I
        Generate Statistics     I Y I
        Limit Origination Attempts      [ N ]

Set Limits to Y if all service markets support SSD Update and is so enabled per
 MSCID in the AC.
        Limit Registration Attempts     N ]
        Perform NPA Split Logic N I
        Periodic SSD Update     y I
        Periodic Unique Challenge       f@N I
        SSD Update for Reg. in new Sys  N
        T@al Type Validation
        Unique Challenge on failed Reg. I Y

Limits: (before successful SSD Update)
                Origination     Attempts        0-99    99
                Registration    Attempts        0-99

        Timers:
        ADT     Authentication Directive Invoke [ 00:06.00 ]see 0-4m:0-59S.
                                        0-99hundths

        CRT     Count Request Invoke    [ 00:06.00 ]see
        NOTE - Important!
        The ASRRT timer must be set to a value
        greater than or equal to the sum of the five
        HLR timers: BSCHALL, BSCT, RESCAN,
        SSDUPDT, and UNCHALL.

        ASRRT   Authentication Staru, Rpnnrt Tnvnk-P    r ni .,)ii nn i..,

AUTHENTICATION - CONTROL CHANNEL FEATURE

Event Logs:    (Y=All, N=None, F=Failures Only)
        ASREPORT        Authentication Status Report    [F]
        AFREPORT        Authentication Failure Report   [F]
        AUTHDIR Authentication Directive response       [F]
        AUTHREQ Authentication Request result   [F]
        BSCHALL Base Station Challenge result   [F]
        COUNTREQ        Count Request result    [F]
        SSREPORT        Security Status Report  [F]

Authentication Center System Parameters File (page 2/3) "Next Action Required"
selections
[viaSAFEPATH:   /SCPINApplications-l/SCPAC-2/ACSYSParameters-l->F2]

        Next Action Required.         (page 2 of 3)
        AFREPORT:
        RANDC Mismatch  A/D/GA/GD       [GD]
        AUTHR Mismatch  A/D     [DI
        TERMTYPE Mismatch       A/D     [Al
        Missing Auth Params     A/D/GA/GD       [GD]
        Other   A/D     [DI

        SSD Update Failure:
        Failed  A/RA    [RA]    Retry SSD update, otherwise
                                allow access.
                                or
                                (@erwise, if

                                access).
        No Attempt/No Response  A/RA    [Al     or

                                rme d.
        que Challenge Failed
        UC No Attempt/Rsp       A/D/RA/RD       [A]     or

        Num Retries     0-1     [01]    Must set to I for initial SSD
                                Update to occurr.

        Unique Challenge AFREPORT:
        Failed  A/D/SA/SD       [DI
        No Response     A/RA    [Al     or
                        D       voice

                                        an              ed.
        Unique Challenge ASREPORT:
        Failed  A/D/SA/SD       [SDI
        No Response     A/RA    [Al     or

                be      ed.
        Not Attempted
        Ignore Failure if Manual        N/Y     [NJ
        Num Retries     0-1     [ 001

        APPLICATION NOTE

        AuthReq:
        AUTHR Mismatch                  fD]
        Missiniz Auth Pararne

        Periodic Updates:
        SSD Update Frequency    1-999 days      301
        SSD Update Interval     1-999 days      7 ]
        Unique Challenge Frequency
        Unique Challenge Internal       minutes F301

Authentication Center System Parameters File (page 3/3)
[viaSAF'EPATH:  /SCPINApplications-l/SCPAC-2/ACSYSParameters-l->F2->F2]

        ERAD Indicators:        (Set all to No except for testing and/or troubl
eshooting.)      f N
        Timeouts
        Reject Sent.    Reject Received
        Errors Sent,    Errors Received

MIN/ESN Mismatch
TenTiinal Type Mismatch
Initialization Information
Authentication Unsuccessful
MIN Not Registered
Record Not Found
Database 1/0 Error
Authentication Disabled
SSD Update Disabled
Unique Challenge Disabled


        Default Home MSCID      O@5636  0-255           (Set MSCID of EMX adjac
ent to HLR.)
        HLR Point Code  all     0-255   0 0 0 0 240
        AC Point Code   all     0-255   0 0 0 0 010
        Encryption Key Index                    00001 ]
        Low Range NPA-NXX       all     0-999   000 000 I

        MS UNIT -

Authentication Center Subscriber Profile File
[via SAFEPATH: / SCP IN Applications-l/ SCP AC-2 / AC Subscriber Prorile-2]

        Mobile ID Number (MIN)
        Equipment Serial Number (ESN)
        Authentication Enabled  N[Y     I y I
        Home MSCID of MS        0-65536 1 -1
        Terminal Type   N/A, etc.       [n/al
        SSD uses default A-key          [n/a]

AUTHENTICATION - CONTROL CHANNEL FEATURE

4.5     GENERIC INTELLIGENT NETWORK

Below is a typical list of HLR-AC entries in the Generic Intelligent Network
(GIN) necessary for associating the Authentication Center application with
other remote authentication network entities such as: HLRS, VLRs (IS-41
Converters), MSCs (Motorola and non-Motorola).  These parameters are
required for the AC to function.  All MSC IDs must be entered representing
the EMX switches and MSCs from which the AC will receive authentication type
messages.  Each remote device requires point code definitions.  The EMX
Network ID screen contains the mapping. Boldface parameter entries are
recommendations.  Italicized or dashed parameter entries require either
operator-dependent data, or may be set by the subsystem itself as the result
of an authentication operation.

        NOTE

        Those settings with a shaded b                      nd  are     le
         a spe-
        cial HMI screen. To access this screen, en              GIMPCMSD
 'the    est
        field and L in the Type field, at the op        t       Safenat
        thenpTessF4. Theonlyvaluesthat ou               e th
        to System Access Type, which dewrmi             p
        Challenges, and access attemt)ts are verf
        informational purposes.


        SCP MSC/Point Code Map File

[via SAFEPATH: / SCP IN Applications-1 / SCP GIN-1
 SCP MSC Point Code Map-1]

MSCID                                               0-65535,         0-255

The MSCID for each authentication capable EMX / Paging area mapping should be e
ntered. (see mapping in EMX Network ID Screen)
        Point Code & SSN        0-255   [00001
        Description     (text]  I - I
        Node Type       MSCFVLR [ M or V
                        (Must be valid for subsystem type)
        Switch Vendor   Att/Eric/Moto/NT        M, E, A or N
        IS-41 Revision Level    A/B     B
        HLR SSN

Allowed Message Indicators:
Call Data Rost
Location Rqsi
Qualification Rqst
@rv

ice Ptofile     St

Transfer to Number

(defined per MSC)


N I


        Authentication Request  I y I
        Authentication Failure Report   I y I
        Base Station Challenge  I Y I
        Cellul ar mes


SystemAccess

@Page


s s




Registration    [Y]     Y for an EMX system. Also, for an MSC ID that
                supports SSD Update Registrations. This requires control
                channel authentication capabili N if the serving MSC ID does
                not support SSD Updates during Regis or the operator does
                not want to perform SSD Updates for this MSC

Origination     [N]     N for an EMX system. Also, for an MSC ID that does
                not support Uni Challenges during an Origination. Or, the
                operator does not want to UniqueChallengesforthisMSCID.
                SettoYiftheservingMSCIDs Unique Challenges. This requires
                voice channel authentication cap

Flash   [ N     [N] for an EMX system. Also, for an MSC ID that does not
                support SS Updates during a Flash request. Or, operator does
                not want to perfo Updates for this MSC ID.  Set to Y if the
                serving MSC ID supports SS Updates during Flash requests.
                This requires voice channel authenti capability.

Unspecified     [Y]     Y always. A system access of unspecified indicates
                that the serving is requesting a Unique Challenge (and SSD
                Update, if needed).

        Other   N I



System Access Type = Unique Challenge

Page    N for an EMX system. Also, for an MSC ID that does not support Uni
        Challenges during a page acknowledgement (Termination). Or, ope
        doesnotwanttoperformUniqueChallengesforthisMSCID. Sett
        serving MSC ID supports Unique Challenges on page acknowledge
        This requires voice channel authentication capability.

Registration    Y for an EMX system. Also, for an MSC ID that supports
        Unique Challenge during Registrations. This requires control channel
        authentication c Set to N if the serving MSC ID does not support
        Unique Challenges Registrations, or the operator does not want to
        perform Unique Chall for this MSC ID.

Origination     N for an EMX system. Also, for an MSC ID that does not
        support Uni Challenges during an Origination. Or, the operator does
        not want to Unique Challenges for this MSC ID. Set to Y if the serving
        MSC IDs Unique Challenges. This requires voice channel authentication
        capability.

Flash   N for an EMX system. Also, for an MSC ID that does not support Uni
        Challenges during a Flash request. Or, operator does not want to p
        Unique Challenges for this MSC ID. Set to Y if the serving MSC IDs
        Unique Challenges during Flash requests. This requires voice channel
        authentication capability.



AUTHENTICATION                  CONTROL CHANNEL FEATURE

                        Option Indicator Fields

        01      [4      Method for encoding ft CallingFeaturel          0 -
                                        1 =PN,
                                        2 =Ph,,,
                                        3 -Col
                                        4-9 --ri
        02      lo]     Message Waiting
        =r      treated

        03      101     When to send Routing Request Mossaaes           to is I
                                        ROUTREO even    serving M SC
                                        --reserved, treated sa
        04      101     Include AuthenticationCapability I
 messages
                        0 =Do not !rK           abili   3

I --Include CallinaFeatureindicator 3 parz 2 = Include Authentication 3 =Includ
e both paramete 4-9 -@ed, treated sa

101        Number of CIC digits to send to Msc ID


        ,06     101     VLR sharing of SSD      0 @ VLR does not share SSD
                                I -VLR does share SSD
                                9 -reserved, tre

        07              VLR is able to perforrn authentication
                101
                I VLR i

2-9 -             treated se

08                    V R is able to execute GAVE                  0 -V ' at ab
le to e
lo]                                                              is n

I =VLR is able to ex@ute

                                2-9     rved, treated sai

        09      101     VLR is able to perfoffn COUNT   0 -
                                -VLF
                                I =VLF
                                2-9 =rf

        10      11 I    VLR is able to perforrn Global Challenge

                3 9 reserved,

                f 01    NACN or CTC Feature code rules


        12      11 I    VLR is Fraud Capable or not


        13 -100 11      inotused)


        Oual Rqst Unassigned MIN Resp   [E]     or
        Detult DND Directory Num.       I
        Default NRI Directory Num.      101



SCP Point Code Definition File
No effect on authentication.

Queue Management Facility Configuration

[via SAFEPATH: / SCP IN Applications-1 / SCP GIN-1 / Queue Management
Configuration-3]

A single record exists and is required for the AC to function.

        Application Name                [ ISACSC        Waming
        Queue Type      0-255   [ 027 1
        Queue Name              [AUTHDRI        DO NOT CHANGE
        Maximum RetTies 0-99    f 00 ]  QUEUEMANAGEMENTFACILITY
        Task ID 1-63    [ 401   CONFIGURATION SETTINGS!
        Server Class    1-31    [ 301
        Queue Delay     mm:ss   [ 00:03
        Retr), Delay    mm:ss   [ 01:00
        Average TPS Per Interval        10-9999 [ 0020
        Overload Adjustment     0-99    [ 01 ]
        Overload Threshold      0-14    [ 04 ]
        Pacing Interval mm:ss   [ 02:00

AUTHENTICATION - CONTROL CHANNEL FEATURE

4.5.1   A-key Provisioning

The authentication key installed in the mobile subscriber unit must be
entered into the AC database record for that subscriber.  If the A-key is
known, then the operator can use the HLR RSMI feature to manually update its
subscriber database record.  In this case, no manual entries need be made at
the MS unit.  Otherwise, the operator can have the AC generate an A-key for
that subscriber, which subsequently must be entered into the subscriber unit
by the user or service provider/re-seller.  NOTT-: The only time the A-key
is displayed is at the time of entry via CHANGE CP SUBSCR, or immediately
after being generated by the AC.  Afterwards, the A-key is not accessible in
any manner.

RSMI DATABASE ENTRY

The RSMI feature (similar to the EMX CAMP command) is used to enter
information specific to an individual subscriber unit into the database.
The A-key as well as the AUTH capability, and Fraud can be provisioned.


~Use:    CHANGE CP SUBSCR  AKEY <20 or 26 digit A-key>
~        CHANGE CP SUBSCR  AUTH Y FRAUD Y N

The RSMI can except either a 20 or 26 digit A-key entry. (The last 6 digits
of the 26 digit entry are the checksum and are not actually stored.)

If the HLR is part of a mate network, the RSMI A-key entry is updated in the
mate HLIus database.

The DISPLAY CP SUBSCR command may be used to display information (except the
A-key and certain other AC database info).

AC GENERATION

A new A-key is generated by the AC using the SUBA function.  The 26 digit
A-key value is displayed and should be recorded by operator until it is
manually loaded into the MS unit*.

If the HLR is part of a mate network, the SUBA (SafePath) A-key entry is not
updated in the mate HLR's database. (This may change in later HLR releases.)

* For more information on entry and revision of the A-key in the MS unit -
  see the EIA/TIA document TSB-50 or manufacturer's user documentation.

4.6     IS-41 CONVERTER

Below is a list of IS-41 Converter database entries necessary for
associating the Motorola Authentication feature network entities such as:
HLRS, Authentication Center, MSCs (Motorola and non-Motorola).  Boldface
parameter entries are recommendations.  Italicized or dashed parameter
entries require either operator-dependent data, or may be set by the
subsystem itself as the result of an authentication operation.  See the HLR
Operations manual for more information.

4.6.1   NETWORK REQUIREMENTS

Normal DMX configuration parameters are set for EMX 2500 switch, HLR, and
IS-41 Converter links. i.e., there are no authentication-related
dependencies.


        Remote Network Entity Settings
        Network Entity ID       [IDEFAULTI]


        AUTH Operation
        SSD Updates     I y I
        Unique Challenge        I y I
        Auth on Reg     p I
        Auth on Reg Period      120
        Auth on Orig    y I


        Allow for Last Auth Result
        Auth Failure    N I


AUTH REQUEST TIMER

* Note: An AuthReq Timer timeout is similar to a RegNot timeout used in a
* non-authentication capable network.  If default service is provided to
* mobiles when a registration attempt times out (see VLR Default Profiles
* Screen), it is possible to allow ART timeouts for Last Auth Result.  In
* this case, however, since timeouts are rare, a fraudulent MS may be
* allowed service. It is recommended to not allow ART Timeout for the Last
* Auth Result,

Auth Incomplete

ART Timeout*                             [N]*

4.6.2   IS-41 PROVISIONING

>From IS-41 Operations Manual, Automatic Roaming

        Application Timers
        Extemal Timers: (outbound from IS-41 Converter)
        Auth Request    [ 61
        Auth Directive  [ 6 ]
        BS Chal [ 51
        AFReport        [ 61
        ASReport        [ 6

        Intemal Timers: (inbound from IS-41 Converter)
        Auth Request    [ 121
        BS Chal [ 51
        AFReport        [ 6
        ASReport        [ 6
        ASReport        Response        [ 481

        Application Parameters
        Auth Unique Challenge Rescan Time       [ 2



5.      VERIFICATION

This section describes and suggests typical test cases and information used
to verify that the Authentication feature is working,

Basic Functionality Testing

initial setup conditions and/or Parameters FEATURE status BY subsystem
Subscriber Unit Status Authentication Event messages

ERADs
IPRs
Statistics - HLR            AC          IS-41         EMX

5.1     BASIC FUNCTIONALITY TESTING

These tests are extracted from FOA Field Test Plans from NSD@ST

        1  Test: 1.1.1.1     page 10
        Successful Authentication on Registration - Initial Power On of MS -
        SSD Updated

        2  Test: 1.1.1.2     page 13
        Successful Authentication on Registration - Re-Registration

        3  Test: 1.1.5.2   page 41
        Authentication  on Registration - Authentication Request AUTHR Mis matc
h - Fraudulent Service
        Disabled on the HLR. - Registration Denied

        4  Test: 1.1.5.6   page 49
        Authentication  on Registration - Authentication Request AUTHR Mismatch
 - Fraudulent Service
        provisioned and enabled onthe HLR-Fraudulent Service NotActivatedforAUT
H Fail -AC is Provisioned
        to Perform an Unique Challenge on Failed Registration System Access- Un
ique
        Challenge Fails - Fraud Activated on UC Fail after Registration

        5  Test: 1.2.1.1     page 66
        Authentication on Origination -Authentication Capable Mobileto Land Cal
l-
        Dialled Digits greaterthan 6 - Success

        6  Test: 1.2.5.1     page 82
        Authentication on Origination - Missing Authentication Parameters -
        Originations Marked Not Allowed

        7  Test: 1.5.1.1     page 120
        AC Operator Initiated Immediate SSD Update - Successful

        8  Test: 1.5.2.1     page 122
        AC Operator Initiated Unique Challenge - Successful

        9  Test: 2.1.1.1     page 127
        Receive authentication requestforan HLR subscriber (singleton
        remoted) on an initial access in a foreign system

        10  Test: 2.2.1.1     page 132
        MSC MS Authentication on Registration in EMX, no previous VLR record

        11  Test: 2.3. 1.1     page 138
        MSC MS Authentication on Origination in EMX, no previous VLR record

        12  Test: 2.4. 1.1  page 144
        SSD Update of MSC MS in EMX system, MS is valid and not off hook

        13  Test: 2.5.1.1       page 151
        Unique Challenge of MSC MS in EMX system, MS is valid and not off
        hook

        14 Test: 3.1.1.4       page 162
        RSMI tests for valid A-Key entries for existing HLR subscribers with
        the AUTH feature.

5.2     BASIC FUNCTIONALITY TESTING

These tests are extracted from FOA Field Test Plans frrom SITG-ST

BASELINE
        1  FTC-1 5 - Origination w/o Auth. and w/o Fraud Service
        Verifies mobile originations when the subscriber does not have
        authentication or fraudulent service enabled.  In this case, a
        non-authenticating mobile will be verified on a cell with
        authentication disabled.

        2  FTC-1 5 - Origination w/o Auth. and w/o Fraud Service
        Verifies mobile originations when the subscriber does not have
        authentication or fraudulent service enabled.  In this case, a
        non-authenticating mobile will be verified on a cell with
        authentication enabled.

ORIGINATIONS

        3  FTC-1 8 - Origination w/Auth. and w/o Fraud Service
        Verifies mobile originations when the subscriber has authentication
        but does not have fraudulent service enabled.  In this case, an
        authenticating mobile will be verified on a cell with authentication
        disabled.

        4  FTC-24 - Origination w/Auth. and w/o Fraud Service
        Verifies mobile originations when the subscriber has authentication
        but does not have fraudulent service enabled.  In this case, an
        authenticating mobile will be verified on a cell with authentication
        enabled.

REGISTRATIONS

        5  FTC-36 - Registration w/o Auth. and w/o Fraud Service
        Verifies mobile registrations when the subscriber does not have
        authentication and does not have fraudulentserviceenabled.  In this
        case, a non-authenticating mobile will be verified on a cell with
        authentication disabled.

        6  FTC-36 - Registration w/o Auth. and w/o Fraud Service
        Verifies mobile registrations when the subscriberdoes not have
        authentication and does not have fraudulent service enabled.  In
        this case, a non-authenticating mobile will be verified on a cell
        with authentication enabled.

        7  FTC-38 - Registration w/Auth. and w/o Fraud Service
        Verifies mobile registrations when the subscriberhas authentication
        and does not havefraudulentservice enabled.  In this case, an
        authenticating mobile will be verified on a cell with authentication
        disabled.

        8  FTC-45 - Registration w/Auth. and w/o Fraud Service
        Verifies mobile registrations whenthe subscriberhas authentication
        and does not havefraudulent service enabled.  In this case, an
        authenticating mobile will be verified on a cell with authentication
        enabled.

TERMINATIONS

        9  FTC-66 - Termination w/o Auth. and w/o Fraud Service
        Verifies mobile termination when the subscriber does not have
        authentication and does not have fraudulent service enabled.  In
        this case, a non-authenticating mobile will be verified on a cell
        with authentication disabled.

        10  FTC-66 - Termination w/o Auth. and w/o Fraud Service
        Verifies mobile termination when the subscriber does not have
        authentication and does not have fraudulentserviceenabled.
        ln this case, a non-authenticating mobile will be verified on a cell
        with authentication enabled.

        11  FTC-68 - Termination w/Auth. and w/o Fraud Service
        Verifies mobile termination when the subscriber has authentication
        and does not have fraudulent service enabled.  In this case, a
        non-authenticating mobile will be verified on a cell with
        authentication disabled.

        12  FTC-68 - Termination w/Auth. and w/o Fraud Service
        Verifies mobile termination when the subscriber has authentication
        and does not have fraudulent service enabled.  In this case, a
        non-authenticating mobile will be verified on a cell with
        authentication enabled.

UNIQUE CHALLENGE & SSD UPDATE

        13  FTC-1 39 - Unique Challenge to Legitimate Mobile
        Verifies that a unique challenge to a legitimate mobile will succeed
        when and authentication-capable mobile is in a cell with
        authentication enabled.

        14  FTC-148 - SSD Update to Legitimate Mobile
        Verifies that an SSD update to a legitimate mobile will succeed when
        and authentication-capable mobile is in a cell with authentication
        enabled.

5.3     SUBSCRIBER UNIT STATUS

Authentication Center System Parameters File:

[via hmimenu: !HLR MAI',-Fl,"DBASE ACCESS-FI/SUBSCRIBER PROFMF-Fl/SUBSCRIBER
STATUS-SF6] Basic functionality is verified by checking Status of successful
and failed authentication attempts and are found under HLR and AC statistics
and AC subscriber status screen. (Bold = read-only fields.)

AC Subscriber Profile            (some of these may be READ-Only fields)

Mobile ID Number (.MIN)
Equipment Serial Number
Authentication Enabled
Terminal Type IS-
Home MSCID

Authenticating MSCH)
Authentication Point Code
Previous MSCED
Previous Point Code

A-Key Status
Default A-Key Present
SSD Uses Default A-Key
Last A-Kev Generated

Unique Challenge (Attempts subfield)
Unique Challenge (Status subfield)
Unique Challenge (Needed subrield)
Unique ChaDenge (Reason subrield)
Unique Challenge (Last Aftempted subfield)

SSD Update (Attempts subfleld)
SSD Update (Status subrield)
SSD Update (Needed Subfield)
SSD Update (Reason subfield)
SSD Update (Last Attempted subfleld)
Changed on (mm/dd/yy)

Origination Attempts
Registration Attempts
Authentication Status
Call lestory Count (AC subfield)
Cafl History Count (MS subrield)

AUTHENTICATION - CONTROL CHANNEL FEATURE

5.4     AUTHENTICATION-RELATED EVENT MESSAGES

(see HLR and IS-41 Release documentation)

5.4.1 HLR - AC ERADS
7134, 7135
7500 -7525
7530
7540 -7542
7545 -7548
7550 -7553

5.4.2 IS-41 ERADS
6312 - Now includes Authentication-related timer information.

5.4.3   EMX 2500 SWITCH IPRS

CALL 917 - Produced by cellular call processing for every Mobile Origination
        and reports authentication information useable for billing purposes
        and troubleshooting. (see IPR DICT MMI)

CALL 916 - Produced by cellular call processing for problems with attempted
        message transmission by the EMXswitch to the HLR or IS-41 Converter.
        (see IPR DICT MMI)

MCON 419 - Produced by cellular call processing when errors occur in the
        handling of Unique Challenge, SSD Update, and Base Station Challenge
        messages. (see IPR DICT MMI)


The CALL 917 IPR provides information on whether authentication has been
performed for mobile origination.  It also provides information on errors
detected during authentication for mobile Origination.

DATA FIELD

6)      Authentication performed indicator
0 - authentication was not performed
1 - authentication was performed

7)      Authentication event code
00 - no error detected
01 - serving system not authentication capable
02 - unresolved RAND
03 - Authentication Request Timer expired
04 - Authentication Center sends RETURN ERROR
05 - mobile is authentication capable but not provisioned for authentication

8)      Deny access code
00 - no error detected
01 - unspecified
02 - SSD Update failure
03 - COUNT Update failure
04 - Unique Challenge failure
05 - AUTHR mismatch
06 - COUNT mismatch
07 - process collision
08 - missing authentication parameters
09 - terminal type mismatch
10 - MIN or ESN authorization

1-5) (see IPR Dictionary)


ACTION: UsetheCal]IDEMXaddressandsequencenumbergeneratedbythisIPRtocorrelate th
e billing information in the corresponding CDR and the Multiple Record Correlat
ion Subrecord OA.

The CALL 916 IPR reports that an attempt was made to send a message to a HLR or
 IS-41 Converter for a particular mobile that is undergoing some authentication
 operation, but the EMX switch was not able to successfully determine the HLR o
r IS-41 Converter's EMX switch address within the network.
DATA FIELD #:

1)      Message Type
-       OxA8 SSD Status
-       Ox36 Base Station Challenge
-       OXAC Unique Challenge Response
-       Ox5C IS-41 Query

6)      CFC from validation (if applicable)

7)      Last Known Area (if applicable):
-       Last Known LATA (3rd nibble)
-       Last Known Paging Area (4th nibble)

8)      Cell Identification (if applicable)
- Cell Number (high 12 bits)
- Sector Number (low 4 bits)

2-5)    (see IPR Dictionary)


ACTION: AnalyzetheEMXswitchvalidationtablestodetermineifthemobileinquestionwas

remotely        validated onto the HLR or IS-41 Converter properly (e.g. DISPLA
 CP FORIGN, 61SPLA

CP ROAMID, DISPLA CP ROAMER, DISPLA CP SUBSCR, DISPLA CP OFFCOD).  Analyze the
call final class (CFC) or other IPRs from the translator to determine any other
 forms of validation failure.  Analyze the mobile identification number to dete
rmine its validity.

The MCOIV 419 IPR indicates a software error has occurred in the cellular subsy
stem where general messages were processed.
DATA FIELDS:

1)      Error type

                0001- 3002      (see IPR Dictionary)
                3003    Invalid Last Known Paging area received from the Authen
tication message
                        from HLR.
                3004    Invalid Authentication parameters received from the Aut
hentication message
                        from HLR.

        2)      Error data      Field 1
                based on the
                first data field.

                0001 -3002      (see IPR Dictionary)
                3003 -  Last Known Area received
                        Last Known Lata in high nibble of the lower byte.
                        Last Known Paging Area in low nibble of the lower byte.
                        The upper byte is un-used and is 0.
                3004 -  Authentication Parameters received
                        1 is for Unique Challenge operation.
                        2 is for BS Challenge Response.
                        4 is for SSD Update operation.
                        Invalid otherwise.

        3)      Error data      Field 1
                based on the
                first data field.



                0001 - 1001     (see IPR Dictionary)
                1002 -  Return code from searching Authentication capable cells
.
                A05B -  can't access the cell parameters table,
                A05C -  invalid paging area was input.
                1003 -  Cell Number
                1004 -  Returned Link number
                1005 -3002      (see IPR Dictionary)
                3003 -  Cell Number received
                3004 -  Last Known Area received
                        Last Known Lata in high nibble of the lower byte.
                        Last Known Paging Area in low nibble of the lower byte.
                        The upper byte is unused and is 0.

        4)      Error data      Field 1
                based on the
                first data field.

                0001 -0006      (see IPR Dictionary)
                0007 -  Authentication Parameter
                        1 is for Unique Challenge operation.
                        2 is for BS Challenge Response.
                        4 is for SSD Update operation.
                        Invalid otherwise.
                1002 -  Last known Paging area to search for Authentication cap
able cells.
                1003 -  Message Type
                1004 -  Returned Drop number
                1005 -  NPA of the TBCD Mobile ID
                1006 -  Cell Number
                2002 -  NPA of the BCD Mobile ID
                2003 -  Mandatory Elements Bit Map
                        Bit 2 = RANDBS element
                        Bit 1 = Auth Response element
                        Bit 0 = Mobile Id element
                2004 -  Cell Number
                3001 -  Cell Number
                3002 -  Page Area to send message to
                3003 -  Authentication Parameter received
                        1 is for Unique Challenge operation,
                        2 is for BS Challenge Response.
                        4 is for SSD Update operation.
                        Invalid otherwise.
                3004 - Cell     Number received

        5)      Error data      Field 1
                based on the
                first data field.

                0001 -0006      (see IPR Dictionary)
                0007 -  Destination Cell Number if this is a BS Challenge opera
tion,
                        Last Known Paging area otherwise.
                1003 -3004      (see IPR Dictionary)

ACIION: Contact Motorola service.

- APPLICATION NOTE

5.5     STATISTICS

See HLR and IS-41 Converter Release documents: HLR System Functionality and
HLR Statistics and Reports concerning:

HLR General Authentication Statistics

RAND Authentication EMX Switch Traffic Reports
Authentication Center Reports (TANDEM)

5.5.1 HLR

A.             HLR Authentication Statistics

1)      Unresolved RANDC Queries for Home local subscribers and Roamers:
-       queries to neighbor EMXs to correlate unresolved RANDC
-       queries to neighbor EMXs to correlate unresolved RANDC that result in s
uccessful correlation.

2)      UnresolvedRANDonRegistrationsandOriginationsforHomelocalsubscribers,Roa
minglocalsubscribers, and Roamers:


3)      Missing AUTH parameters on Registrations and Originations for Home loca
l subscribers, Roaming local subscribers. and Roamers:

4)      SuccessfulAuthenticationsonRegistrationsandOriginationsforHomelocaIsubs
cribers,Roaming local subscribers, and Roamers:

5)      FailedAuthenticationduetoAUTHRMismatchonRegistrationsandOriginationsfor
Homelocaisubscribers, Roaming local subscribers, and Roamers:

6)      Fraudulent Status Set on Originations and Registrations for Home local
subscribers and Roaming local subscribers:

7) SSDUpdateSuccesses,Failures,NoResponses,NoAttemptsforHomelocalsubscribers,Ro
aming
local subscribers, and Roamers:
i.e.,
-       SSD Update success, Unique Challenge success
-       SSD Update success, Unique Challenge failure
-       SSD Update success, Unique Challenge no attempt

-       SSD Update failure, Unique Challenge no attempt
-       SSD Update no response, Unique Challenge no attempt
-       SSD Update success, Unique Challenge no response
-       SSD Update no attempt, Unique Challenge no attempt


8)      StandaloneUniqueChallengeSuccesses,Failures,NoResponses,NoAftemptsforHo
melocalsubscribers, Roaming local subscribers, and Roamers:
-       Standalone Unique Challenge success
-       Standalone Unique Challenge failure
-       Standalone Unique Challenge no response
-       Standalone Unique Challenge no attempt

        B.              HLR Statistical Reports
                        HLR Statistics Reports Subsystem

                        EMX Traffic Report
                        + list of reports, particularly:
                        Registration
                        Subscriber Registration
                        Origination validation
                        Authentication Directive
                        AUTH SSD & Challenge

                OR      HLR General Authentication Reports (8 report types)
                OR      RANDAuthenticationEMXTrafficReports (2reporttypes)
                OR      TANDEMAuthenticationCenterReports (10reporttypes)


5.5.2 AC

A.           AC Reporting facilities
["SAFEPATH"I
SCP     Intelligent Network Application
SCP AC - Authentication Center Menu
AUC Sys Params
or                                       AUC Subscriber profile

5.5.3   IS-41 Converter

A.           Converter Authentication Statistics

Information can be collected on many aspects of the IS-41 application for
Authentication.  See below for partial listing.

Also see IS-41 Converter Release documents:
IS-41 Convener System Functionality
IS-41 Convener Statistics and Reports - ALJTHENTICATION STATS
Authentication:
1 )     Directive:
Attempt
Complete
Failure
Force Disconnect
SSD Update and Unique Challenge
Unique Challenge
SSD Update Only
2)      Directive Denied:

SSD Update FailLira

Process Collision

Missing AUTH parameters
Unique Challenge Failure
AUTHR mismatch

Term Type mismatch
MIN or ESN mismatch
totals

3) Failure:
Attempt
Complete
Failure
Timeout
SSD Update Requested
Unique Challenge Requested
Attempt - RANDC mismatch
Attempt - Missing AUTH parameters
4)      Failure Denied:

SSD Update Failure

Unique Challenge Failure

AUTHR mismatch

Process Collision
Missing AUTH parameters
Term Type mismatch
MIN or ESN mismatch
totals
5) Request:
Attempt
Complete
Failure

Timeout
SSD Update Requested
Unique Challenge Requested

APPLICATION NOTE

6)      Request Denied.:
SSD Update Failure
Unique Challenge Failure
AUTHR mismatch
Process Collision
Missing AUTH parameters
Term Type mismatch
MIN or ESN mismatch
totals

Authentication Status:

7)      Attempt Complete Failure Timeout
etc.

Base Station Challenge:

8)      Attempt Complete Failure Timeout

Request DenN, Access Override
etc.


General Authentication Report


ERADs   7504-9, 7511, 7501, 16, 20, 42, 47. @ical information provided by
some ERADS include:

SSD Updates
Unique Challenges
Forced Disconnects
AUTHR Mismatches
RANDC Mismatches
MIN or ESN authorization
Missing authentication parameters
SSD Update not attempted
Unique Challenge not attempted

Statistics for Authentication include:

Directive totals for:
Attempts, Completions, Failures

Directives for:
Attempts, Completions, Failures
of:     SSD Updates & Unique Challenges
or:     Unique Challenges
and:    Forced Disconnects totals Unique Challenge totals

Directives Denied for:
AUTHR Mismatches
Missing authentication parameters

Failures for:
SSD Updates
Unique Challenges
MIN or ESN authorization
Total Directive Denied

AUTHENTICATION               CONTROL CHANNEL FEATURE

Failures for:   Attempts, Completions, Failures Denied
Timeouts
SSD Update Requested
Unique Challenge Requested

Failure Denied  for:
AUTHR Mismatches
MIN or ESN authorization failures Missing authentication parameters
   SSD Update failures
Unique Challenge failures

Requests for:   Attempts, Completions, Failures Denied
Timeouts
SSD Update requested
Unique Challenge requested
Requests Denied for:
AUTHR Mismatch
MIN or ESN authorization failures

Missing authentication parameters
SSD Update failure
Unique Challenge failure

Authentication Status

Status Attempts for:
SSD Updates
No SSD Updates
Unique Challenges

Status of SSD Updates for
requests
successes
failures
no response
not attempted
Status of Unique Challenge for:

requests
successes
failures
no response
not attempted
Status Denied for:

AUTHR Mismatch

MIN or ESN authorization failures
Missing authentication parameters
SSD Update failure
Unique Challenge failure

Base Station Challenge:

for:    Attempts Completions Failures Timeouts

Request Deny Access Override
etc.


6.      RELATED DOCUMENTS

(See your Motorola Program or Product Manager to obtain the latest versions
of the documentation.)

EMX2500 SWITCH

                0 Software Release 7.3. I.x     68PO9227A55
        0       Intelligent Network (IN) Triggers       68PO9228AO7
        0       DAS Progra=er's Guide   68P8115OE64

0  EMX 2500 Switch Cellular Subsystem Command Reference Pages
   68PO92OIA55
HLR
        0       Software Installation   68PO9244AO6
        0       System Functionality    68PO9243A93
        0       Operation       68PO9243A90
        0       System Operating Procedures     68PO9243A92
        0       Alarm and Messages      68PO9243A94
        0       Statistics and Reports  68PO9243A95
        0       Maintenance and Troubleshooting 68PO9243A96

IS-41 CONVERTER

        0       SoftA,are Installation  68PO9223AlO
        *       Configuration   68PO9223A35
        f       Operation       68PO9223AO5
        0       System Operating Procedures     68PO9223A25
        *       Alarm and Messages      68PO9223A30
        *       Statistics and Reports  68PO9223A20
        0       Maintenance and Troubleshooting 68PO9223AI5

INDUSTRY RELATED DOCUMENTATION

        0       TIA, 800-MHz AMPS, Authentication and optional NAMPS Air
 IS-91-A
                Interface standard (TR45. 1, PN-3476)
        0       TIA, Cellular Radio Telecommunications Intersystem Operations
 IS-41-C
                (TR45.2)
        0       TIA. Mobile Station Authentication A-Key Entry  TSB-50


7.      TERMINOLOGY

Bg      Call Final Class - Authentication performed and failed

D9      Call Final Class - Fraudulent Originating mobile

DA      Call Final Class - Fraudulent Terminating mobile

DB      Call Final Class - Mobile is capable of authentication, but
        authentication was not performed.

AC      Authentication Center - The AC stores and maintains MS
        authentication data, performs authentication algorithms, and
        initiates authentication activities depending on results.

ADT     AC CP Query waits for response to Authentication Directive Invoke

A-key   Authentication key

ASRRT   CP timer waits to Authentication Status Report Result

AUTH    A 1 bit field used in the Overhead message Train

AUTHBS  Base Station Challenge Authentication Response.  An 1 8 bit pattern
        generated by the authentication algorithm (CAVE).  It is used to
        confirm the validity of the Base Station as part of the Base Station
        Challenge procedure.

AUTHR   Authentication Response

AUTHREG Authentication Request

Authorization   A process whereby the mobile subscriber unit is permitted to
                use cellular system resources.

AUTHU   Unique Challenge Authentication Response

ACK     Acknowledgement

AMPS    Advanced Mobile Phone System

Base Station    Cell Site

BSC     Base Site Controller (usually HDII cell)

BSCHALL Base Station Challenge

CALL 916        EMX IPR that reports an HLR or IS-41 message addressing
                problem during an authentication operation.

CALL917         EMX IPR that reports Authentication results.

CAVE    CAVE algorithm is the Cellular Authentication and Voice Encryption
        algorithm as defined by IS-54.  Availability of CAVE algorithm
        information is governed under the U. S. International Traffic and
        Arm Regulation and the Ex@ort Administration Regulations.

CDR     Call Detail Record

CFC     Call Final Class, also Call Failure Class

CRT     AC CP Timer waits for response to Count Request Invoke message

DGTSDIAL        Digits Dialed

DIGITS  Telephone "BCD" fields used to identify called directory number,
        routing numbers and the preferred inter-exchange carrier

DMX     Distributed Mobile Exchange'.  The signalling protocol used between
        Motorola Electronic Mobile Exchanges.

DMXIO   The DMX Input/Output process on the HLR.

EMX     Electronic Mobile Exchange-

ERAD    Exception Reporting and Alarm Distribution - stored report messages
        of exception Reports and alarms on the HLR and IS-41 Converter.

ESN     Electronic Serial Number - a 32 bit constant as defined in IS-54B
        section 2.3.2. Bits 0-17 (18 bits inclusively) are the serial
        number.  Bits 18-23 (6 bits inclusively) are reserved.  Bits 24-31
        (8 bits inclusively) are the Manufacturer Code.

FOCC    Forward Control Channel

FVC     Forward Voice Channel

HDII    High-Density 11 Cell Site

HLR     Home Location Register

MMI     Human-Machine Interface

HOME System or MSC      Location of subscriber records

IN      Intelligent Network

IN Trigger      An event trigger request from the HLR to other network
                entities.

IPR     Information and Problem Report.

IS-41C  Interim Standard4l C-Cellular Radio-Telecommunications intersystem
        Operations

IS-91A  Interim Standard 91A - Air interface Specification for Dual Mode
        Analog Mobile Stations

MCON 419        EMX IPR that reports general subsystem messaging errors.

MIN     Mobile Identification Number-the mobile's 10 digitstation code
        (NPA-NXX-XXXX) in BCD form.

MS      Mobile Station

MSC     Mobile Switching Center

MSCID   ID number of a Mobile Switching Center

NAMPS   Narrow-Band Advanced Mobile Phone System

NB      Narrow-Band

OMT     Overhead Message Train

PSTN    Public Switched Telephone Network

RECC    Reverse Control Channel

RVC     Reverse Voice Channel

RAND    Random Variable

RANDBS  Base Station Random Variable.  A 32 bit random number generated by
        the mobile station.  This number is used in authenticating base
        stations that are initiating requests to update the Shared Secret
        Data.

RANDC   Random Variable Confirmation.  An 8 bit number used to confirm the
        last RAND received by the mobile station.  RANDC is the 8 high order
        bits of RAND.  A RANDC with avalue of zero indicatesthe mobile does
        not havethe currentvalue of RAND for the serving system.

RANDSSD Shared Secret Data Random variable.  A 56 bit random number
        generated by the mobile station's home system (HLR/AC).  Used in
        conjunction with the mobile station's A-Key and ESN to generate the
        Shared Secret bata.

RANDU   Unique Random Variable.  A 24 bit random number generated to request
        execution of the Unique Challenge Response procedure.

REGNOT  Registration Notification.  A message sent to the HLR to update the
        mobile's current location.

SAS     A Standalone Analog Supercell base station that controls operations
        of analog mobile subscriber units within Its RF coverage area and
        provides the interface between the the MS and the EMX.

SIG     Signalling Channel Transceiver

SP      Special Product

SCSC    A modified HDII or LD base station that provides the cell the same
        authentication capability as a SAS cell.
        
SCP     Service Control Point.  The SCP has the cellular subscriber
        database and consists of the Home Location Register and Authentication
        Center.  The HLR and AC functionalities are co-located on the
        same platform, communicate internally via a common signalling and
        messaging protocol and comprise the Motorola SCR

SERVING System or MSC   The system or MSC that is currently controlling the
                        MS.

SME     Signalling Message Encryption

SSD     Shared Secret Data.  A 128 bit pattern stored in the mobile station
        and in the HLR/AC.  It is a concatenation of two 64 bit subsets: SSD
        A, used in the authentication procedures, and SSD_B, used in the
        Signal Messiige Encryption and DataNoice Privacy Mask generation.

SSD-A   64 bits of the 128 bit Shared Secret Data word.  It is used for
        authentication calculations in a mobile and the authenticating
        infrastructure (AC).

SSD-B   64 bits of the 128bit Shared Secret Data word.  It is used for
        Signal Message Encryption and Data/Voice Privacy Mask generation.

TIA     Telecommunications Industries Association

VLR     Visitor Location Register - A database of subscriber ID numbers
        assigned to subscribers temporarily registered in a cellular network
        outside of their home network's service area.





TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH