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