Electronic Switching System for Beginners
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-2024 AOH
