Title of Invention	A METHOD FOR IMPLEMENTING AUTHENTICATION OF HIGH-RATE PACKET DATA SERVICES
Abstract	"A METHOD FOR IMPLEMENTING AUTHENTICATION OF HIGH-RATE PACKET DATA SERVICES" The present invention discloses a method for implementing authentication of high-rate packet data services. The method comprises a user terminal that has set up a physical connection with the access network using the user information stored in its own User Identity Module (UIM) as the user identifier and starting the authentication with a UIM-based authentication entity; the authentication entity, according to said user identifier, acquiring the second random number for authentication of user terminal and the second authentication number that is corresponding to the second random number and calculated according to the shared secret data (SSD) stored at the network side; said user terminal obtaining the first authentication number by calculation based on the second random number and the self-stored SSD, the authentication entity comparing the first authentication number with the second authentication number, if they are identical, the authentication of the user terminal by the authentication entity succeeds, otherwise the authentication fails. This method makes authentication reliable in security while the cost thereof is low and the operation convenient. Figure 5

Title of Invention

A METHOD FOR IMPLEMENTING AUTHENTICATION OF HIGH-RATE PACKET DATA SERVICES

Abstract

"A METHOD FOR IMPLEMENTING AUTHENTICATION OF HIGH-RATE PACKET DATA SERVICES" The present invention discloses a method for implementing authentication of high-rate packet data services. The method comprises a user terminal that has set up a physical connection with the access network using the user information stored in its own User Identity Module (UIM) as the user identifier and starting the authentication with a UIM-based authentication entity; the authentication entity, according to said user identifier, acquiring the second random number for authentication of user terminal and the second authentication number that is corresponding to the second random number and calculated according to the shared secret data (SSD) stored at the network side; said user terminal obtaining the first authentication number by calculation based on the second random number and the self-stored SSD, the authentication entity comparing the first authentication number with the second authentication number, if they are identical, the authentication of the user terminal by the authentication entity succeeds, otherwise the authentication fails. This method makes authentication reliable in security while the cost thereof is low and the operation convenient. Figure 5

Full Text	Field of the invention The present invention relates to network authentication techniques, and particularly to a method for implementing authentication of high-rate packet data services. Background of the invention CDMA is an advanced technology of digital cellular mobile communications and one of the most important radio transmission technologies (RTT) of 3G accepted by the International Telecommunications Union (ITU). Since the first release of CDMA standards by QUALCOMM Incorporated in 1990, there have been two important stages in the evolution of CDMA technology, i.e. IS95 and CDMA2000 lx. As shown in Figure 1, the network architecture of CDMA2000 lx consists of Mobile Station (MS), Base Transceiver Station (BTS), Base Station Controller (BSC), Packet Control Function (PCF), Packet Data Service Node (PDSN), Authentication, Authorization, Accounting server (AAA), and IS-41 core network, where IS-41 core network includes Mobile Switching Center (MSC), Visiting Location Register (VLR), and Home Location Register (HLR). User authentication in CDMA IS95 and CDMA 2000 lx networks is completed jointly by MSC/VLR and HLR/Authentication Center (AuC). Moreover, the Shared Secret Data (SSD) are stored in the terminal and HLR/AuC as one of the input parameters for authentication while identical passwords (A-key) are stored in the terminal and HLR/AC specially for use in updating SSD. When authentication is needed, the authentication result is obtained by calculation through the algorithm of Cellular Authentication and Voice Encryption (CAVE) with such parameters as SSD, random number, Electronic Serial Number (ESN), and Mobile Station Identity Number (MIN), and MSC/VLR or HLR/AuC will compare the authentication result to check whether it is consistent or not; if not consistent, the system will initiate an updating of SSD. After the updating of SSD is successful, i.e. the SSD at the terminal side and SSD at the network side are consistent, next authentication will succeed only when the authentication result calculated by the user with SSD is consistent with the authentication result calculated by HLR/AuC. CDMA 2000 HRPD (CDMA 2000 lxEV-DO), simplified as HRPD, is an upgraded technology of CDMA 2000 lx, providing high-rate packet data service with a single-user downstream rate up to 2.4Mbps. As shown in Figure 2, the networking architecture of HRPD consists of Access Terminal (AT), Access Network (AN), AN AAA, PCF, PDSN, and AAA. User authentication is implemented in an HRPD network mainly by AN AAA. After authentication succeeds, AN AAA will return to AT the International Mobile Subscriber Identity (IMSI) of the terminal for use in later switching and charging processes. In the authentication process of HRPD, the interface A12 between BSC/PCF and AN AAA is used and this interface adopts the Remote Access Dial User Service (RADIUS) protocol with the Password Authentication Protocol (PAP) and Check-Handshake Authentication Protocol (CHAP) as the main authentication mechanisms. Since CHAP has relatively better performance in security, there are more applications of CHAP in authentication. CHAP adopts the private-key-based Message Digest (MD) identity authentication algorithm. As shown in Figure 3, take the CHAP protocol as an example and the authentication process through RADIUS protocol specifically comprises: Step 301: The user terminal consults with the network side via PPP/LCP and decides to use CHAP for authentication; Step 302: AN sends a Challenge message to the user terminal to initiate authentication, and the message contains the random number generated by AN; Step 303: The user terminal calculates the digest with the random number by means of the encryption algorithm prescribed by CHAP, and then sends the user name and digest to AN via a Response message; Step 304: At Interface A12, AN uses an Access Request message of the RADIUS protocol to carry the user name, random number and digest, and sends the message to AN AAA; Step 305: AN AAA calculates a digest with the random number by means of the same algorithm and judges by comparison whether this digest is consistent with the digest sent up from the terminal, if consistent, the authentication succeeds and AN AAA sends an Access Accept message to AN, otherwise the authentication fails; Step 306: AN sends a Success message to the user terminal, notifying the user terminal that the authentication is successful. It can be seen from the above process that authentication of HRPD users in the prior art requires the use of AN AAA and the authentication is a one-way process. At present, along with the development of market economy and technology, more and more operators desire to operate various networks simultaneously. For example, an operator of IS95/CDMA 2000 lx network would like to expand its service to CDMA 2000 lxDO network while authentication in CDMA 2000 lxDO requires setting up of a special AN AAA for authentication. For a user of multi-mode terminal, this approach of authentication requires opening accounts at both HLR and AN AAA, making authentication modes not unified and maintenance inconvenient, which is not conducive to unified operation. Moreover, this approach requires a special nation-wide network of AN AAA for HRPD user authentication, resulting in high cost in network construction. In addition, as authentication of this approach is a one-way process to the user, it is not reliable in security. Besides, Wireless Local Area Network (WLAN) is attracting more and more attentions as a high-rate wireless data access technique. A WLAN is typically used for transmission of IP data packets, i.e. implementing the wireless access of a user terminal via Access Point (AP) and then the transmission of IP packets via network controller and connecting devices. Various techniques have been used in WLAN, among which a technical standard with more applications is IEEE 802.11b. This standard utilizes the frequency band of 2.4GHz with a data transmission rate up to 11 Mbps. Other technical standards utilizing the same frequency band include IEEE 802.1 lg and the Bluetooth, where the data transmission rate of IEEE 802.1 lg is up to 54Mbps. Other new standards, such as IEEE 802.11a and ETSI BRAN Hiperlan2, utilize the frequency band of 5GHz with a transmission rate up to 54 Mbps as well. Along with the rising and developing of WLAN, focus of research is shifting to the inter-working of WLAN with various wireless mobile communications networks, such as GSM, CDMA, WCDMA, TD-SCDMA, and CDMA2000. In the 3GPP2 standardization organization, research is being carried out on the access of WLAN users to 3GPP2 networks. Summary of the invention In view of the above, the object of this invention is to provide a method for implementing authentication of high-rate packet data services such that the authentication could be easy in operation and convenient in maintenance. The method comprises: A. the authentication entity carries out authentication of a user terminal having set up a physical connection with AN by means of the UIM (User Identity Module) -based authentication mechanism, and uses the user information stored in the UIM of the user terminal itself as the user identifier; B. the authentication entity, according to said user identifier, generates the second random number for authentication of the user terminal and the second authentication number that is corresponding to the second random number and is calculated by the SSD of this user terminal stored at the network side; C. said user terminal makes calculation based on the second random number and the self-stored SSD and obtains the first authentication number; the authentication entity compares the first authentication number with the second authentication number, if yes, the authentication of the user terminal by the authentication entity succeeds, otherwise, the authentication fails. Said authentication entity comprises a pre-configured authentication server or the authentication center in a wireless mobile communications system. If the authentication entity is the authentication center in a wireless mobile communications system, said second random number is acquired from the authentication center of the wireless mobile communications system, and said SSD are stored in the HLR/AuC at the network side. If the authentication entity is a pre-configured authentication server, said second random number is acquired from this authentication server, and said SSD is stored in the HLR/AuC at the network side or in this authentication server. After the authentication fails in step C, the method further comprises: The authentication entity notifying the HLR at the network side of the authentication result, and the HLR judging whether this authentication is a first-time authentication, if yes, updating the SSD and then performing step C, otherwise the authentication fails. After the authentication fails in step C, the method further comprises: Updating the SSD, and then performing step C. The process of updating the SSD comprises: Dl. HLR generating an SSD-updating random number, and calculating the authentication number corresponding to the SSD-updating random number; D2. the user terminal recalculating its own SSD based on said SSD-updating random number by means of the original SSD-generating algorithm of the system, and then calculating the authentication number corresponding to the SSD-updating random number based on the re-calculated SSD; D3. judging by comparison whether the authentication number calculated by the user terminal and the authentication number calculated in the HLR is consistent, if consistent, updating the SSD at the user terminal side, otherwise SSD-updating fails. Step Dl further comprises: Dll. HLR sending the SSD-updating random number (RADNSSD) and the corresponding authentication number to the authentication entity; D12. the authentication entity sending to AN an Access-Challenge message, which carries the EAP-Request/UIM/Update message of RADNSSD. D13. AN sending the EAP-Request/UIM/Update message to the user terminal. Step D2 comprises: D21. after receiving the EAP-Request/UIM/Update message sent by AN, the user terminal calculating new SSD using RADNSSD, randomly generating a random number RANDBS, then calculating an authentication number AUTHBS corresponding to RANDBS based on the new SSD, and then sending RANDBS to AN through the EAP-Response/UIM/Challenge message; D22. AN sending the EAP-Response/UIM/Challenge message to the authentication entity; the authentication entity acquiring the base-station inquiry random number RANDBS and the corresponding inquiry authentication number AUTHBS through interaction with HLR, wherein AUTHBS is obtained by calculation based on RANDBS and the self-stored SSD; D23. the authentication entity sending to AN an Access-Challenge message, which carries the EAP-Request/UIM/Challenge message with the authentication number AUTHBS; after receiving this message, AN sending it to the user terminal. Step D3 comprises: D31. after receiving the EAP-Request/UIM/Challenge message, the user terminal judging by comparison whether the AUTHBS therein and the self-calculated AUTHBS are consistent, if consistent, updating the SSD of the user terminal side, the user terminal succeeding in the authentication of the authentication entity and sending an EAP-Response/UIM/success message to AN; D32. after receiving this message, AN sending to the authentication entity the EAP-Response/UIM/success message, which carries the attributes of relevant RADIUS, after receiving this message, the authentication entity updating the SSD of the user. Said own SSD in step D2 is calculated based on said SSD-updating random number, ESN, ;.uul VkeyMSl. ami-password. Step A comprises: Al. AN sending an authentication request to the user terminal; A2. after receiving this authentication request, the user terminal reading out the user information stored in the UIM, taking this user information as its own user identifier, and then sending said user identifier to the authentication entity via AN. Said AN communicates with the user terminal through EAP or CHAP. When the authentication request is sent through EAP, sending the authentication request to the user terminal by AN in step Al is implemented through an EAP-Request/Identity message. Step A2 comprises: A21. said user terminal sending the user identifier to AN through an EAP-Response/Identity message; A22. after receiving this message, AN sending the message to U-AAA through an Access-Request message, initiating an authentication request to U-AAA. Step B further comprises: U-AAA sending the acquired second random number for authentication of the user terminal to the user terminal via AN. The step of sending the second random number to the user terminal via AN comprises: Bl. the authentication entity encapsulating said second random number in the EAP-Request/UIM/Challenge message, and then sending this message to AN through an Access-Challenge message; B2. after receiving the Access-Challenge message sent from the authentication entity, AN separating the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sending the separated message to the user terminal. Step C further comprises: After obtaining the first authentication number by calculation, the user terminal sending the first authentication number to the authentication entity via AN. The step of the user terminal sending the first authentication number to the authentication entity via AN in step C comprises: CI. the user terminal sending the first authentication number to AN through an EAP-Response/UIM/Challenge message; C2. AN encapsulating the received EAP-Response/UIM/Challenge message in the Access-Request message, and sending the Access-Request message that completes the encapsulation to the authentication entity. While performing step C, the method further comprises: the authentication entity notifying the user terminal that the authentication succeeds/fails via AN. Said authentication entity and HLR communicate through ANSI-41D protocol. Said AN comprises WLAN. It can be seen from the foregoing method that this invention has the following merits and features: 1. This invention supports nation-wide roaming by utilizing the existing CDMA IS-41 core network, and there is no need of constructing a new nation-wide special network of AN AAA. Thus, the cost of investment is reduced. 2. Unified authentication in a multi-mode network is conducted, and there is no need for the user to input the user name and password manually, so the operation is convenient. Furthermore, as unified account-opening, unified identification and unified authentication can be conducted in HLR via IMSI for HRPD services and services of other networks, the method brings convenience to the operators. Meanwhile, it is possible for HRPD users to continue to use their previous UIM cards of IS95/CDMA2000 lx, therefore, it is conducive to the transfer of IS95/CDMA2000 lx users to HRPD networks. 3. By means of EAP-UIM protocol, it is also possible for a user terminal to make authentication of the network side such that the mutual authentication between the network and terminal, i.e. authentication of terminal by network and authentication of network by terminal, is implemented. Therefore, the method is more reliable in security. Brief description of the drawings Figure 1 is a schematic diagram illustrating the networking of IS95/CDMA2000 lx system; Figure 2 is a schematic diagram illustrating the networking of an HRPD network; Figure 3 is a schematic diagram illustrating the HRPD authentication process in the prior art; Figure 4 is a schematic diagram illustrating the networking architecture in accordance with this invention; Figure 5 is a schematic diagram illustrating the authentication process at first-time power-on in Embodiment 1 of this invention; Figure 6 is a schematic diagram illustrating the authentication process at second-time power-on in Embodiment 1 of this invention; Figure 7 is a schematic diagram illustrating the authentication process at first-time power-on in Embodiment 2 of this invention; Figure 8 is a schematic diagram illustrating an exemplary communication process between a user terminal and the access network by CHAP in accordance with this invention. Embodiments of the Invention The core idea of this invention is: the authentication entity carries out authentication of a user terminal having set up a physical connection with AN by means of the UIM-based authentication mechanism, and uses the user information stored in the UIM of the user terminal itself as the user identifier; the authentication entity, according to said user identifier, generates the second random number for authentication of the user terminal and the second authentication number that is corresponding to the second random number and is calculated according to the SSD stored at the network side; said user terminal makes calculation based on the second random number and the self-stored SSD and obtains the first authentication number; the authentication entity compares the first authentication number with the second authentication number, if they are identical, the authentication of the user terminal by the authentication entity succeeds, otherwise, the authentication fails. The network by which a user terminal gets accessed may comprise a WLAN. The main distinguishing features of the present invention as compared with the prior art include the following aspects. The authentication entity may comprise a pre- configured authentication server or the original authentication center. The authentication server may communicate with HLR via the ANSI-41D protocol. The second random number may be generated by any entity at the network side, such as HLR/AuC, AAA, and etc. The SSD may be stored in the HLR/AuC at the network side or in the authentication server. When from the HLR/AuC. When the second random number is generated by AAA, the second authentication number can be acquired from the HLR/AuC according to the user identifier and the first random number. The user terminal and AN may communicate with each other by means of CHAP or EAP, or by the original CDMA2000 messages for wireless-channel interface. The technical solution in accordance with the present invention is hereinafter described in detail with reference to the accompanying drawings and specific embodiments. As shown in Figure 4, the networking architecture in accordance with this invention includes AT (user terminal), AN, UIM-based Authentication, Authorization and Accounting server (U-AAA), PCF, PDSN, AAA, HLR, where AN provides the data connection between a terminal and a packet data switching network, being an equivalent of BTS and BSC in CDMA2000 lx and, obviously, an equivalent of WLAN as well; and the U-AAA is pre-configured and special for authentication and accounting. The network elements used herein, such as BTS, PCF, PDSN, HLR, need not to be modified; the user terminal is required to be an HRPD terminal or a hybrid terminal supporting HRPD, such as a HRPD/GSM, HRPD/CDMA2000 lx, or HRPD/WLAN terminal, while the hardware thereof supports the reading of UIM cards or provides interface to external card-reader, and supports EAP-UIM protocol as well as authentication by GSM HLR or CDMA HLR; AN is required to support the authentication protocol at the wireless-channel interface and the interface A12, where the wireless-channel interface is EAP-UIM over PPP and A12 is EAP-UIM over RADIUS. AAA can be removed while the accounting function is implemented by the pre-configured U-AAA. Replacing AN AAA with the network element U-AAA is mainly because of the requirement for supporting the CDMA IS41 protocol as well as the authentication protocol of EAP-UIM over RADIUS. In addition, HLR and AuC are usually located in the same entity, thus referred to hereinafter as HLR. It should be noted that the authentication process after the first-time power-on comprises three parts, i.e. the first-time authentication, SSD updating, and second-time authentication. The authentication conducted at the first-time power-on of AT is the first-time authentication, and since the SSD stored at the system side and the SSD stored at AT side are not consistent when AT switches on for the first time, the first-time authentication of AT always fails. Therefore, SSD updating is needed after the first-time authentication fails, i.e. issue RANDSSD through the EAP-REQUEST/UIM/Update message and calculate the new SSD at AT and HLR by the same SSD-generating algorithm with RANDSSD, ESN, and A-key. As these parameters at AT side and at HLR side are identical and so are the algorithms used, the SSD outputted will be the same. After the SSD updating, the second-time authentication is made. At this time, since it is guranteed that the SSD at AT side and SSD at HLR side are identical, the second-time authentication will succeed in normal conditions. For users switching on again, the SSD at the system side and SSD at AT side are the same, thus there is no need of SSD updating and second-time authentication, and it is sufficient to make authentication only once to achieve success. With reference to Figure 8, the communications between a user terminal and the access network is hereinafter described by taking CHAP as an example. The process is as follows: Step 801: An HRPD session is set up between AT and AN, and AT is prepared to exchange data on the accessing stream. Step 802: AT and AN initiate PPP and LCP consultation for an access authentication. Step 803: AN initiates a Random Challenge and sends it to AT through a CHAP Challenge message. Step 804: AT makes CAVE-based authentication, and sends a CHAP Response message. Step 805: AN sends to U-AAA an Al2-Access Request message. Step 806: U-AAA constructs an AUTHREQ message based on the contents of the A12-Access Request message, and sends the AUTHREQ message to HLR/AuC. Step 807: HLR/AuC performs the CAVE-based authentication process, if the authentication succeeds, HLR/AuC will send to U-AAA an authrep message containing the SSD parameter. Step 808: U-AAA stores the SSD assigned by HLR/AuC. Step 809: U-AAA sends to AN an A12-Access Accept message. Step 810: AN returns to AT an instruction of CHAP Authentication Success. Step 811: AT and AN continue with the subsequent processing steps. The technical solution in accordance with the present invention is hereinafter described in detail with reference to the accompanying drawings and Embodiment 1. As shown in Figure 5, when a user terminal is in a state of non-first-time power-on, the specific process for implementing authentication is as follows: Step 501: A physical connection is set up between WLAN MS and WLAN. Step 502: WLAN MS initiates an authentication request to WLAN, i.e. WLAN MS sends to the network an EAPoL-Start message. Step 503: WLAN sends to WLAN MS an EAP-Request/Identity message, starts the authentication and requests WLAN MS to submit the user identifier. Step 504: After receiving the EAP-Request/Identity message, WLAN MS reads out the information stored in UIM via the appropriate interface, takes the information as its own user identifier, and sends the identifier to WLAN through the EAP-Response/Identity message. Step 505: After receiving the EAP-Response/Identity message, WLAN initiates an authentication request through the Access-Request message in the Radius protocol, and the EAP-Response/Identity message is encapsulated in the Access-Request message. Step 506: After receiving the Access-Request message sent from WLAN, U-AAA extracts the user identifier carried therein, and then decides the type of the user identifier according to the relevant configuration information of its own, if it is the UIM type, encapsulates an EAP-Request/UIM/Start message in the Access-Challenge message and sends it to WLAN, otherwise performs no processing. Step 507: After receiving the Access-Challenge message, WLAN separates the EAP-Request /UIM/Start message therefrom, and then sends the separated message to WLAN MS. Step 508: After receiving the EAP-Request/UIM/Start message sent from WLAN, WLAN MS includes a self-generated random number NonceJVIT in the attribute AT_NONCE MT, and then sends to WLAN the EAP-Response/UIM/Start message containing this random number, indicating that it agrees to use the EAP-UIM authentication protocol. Step 509: After receiving the EAP-Response/UIM/Start message sent from WLAN MS, WLAN encapsulates the EAP-Response/UIM/Start message in the Access-Request message, and then sends the Access-Request message to U-AAA. Step 510: After receiving the Access-Request message sent from WLAN, U-AAA decides to adopt the unique inquiry mode, i.e. U-AAA generates the random number for authentication of WLAN MS (RANDU) - the second random number, and calculates the second authentication number corresponding to this random number according to the self-stored SSD, thereby forming an authentication set. Step 511: U-AAA encapsulates RANDU in the EAP-Request/UIM/Challenge message, and then sends RANDU and MAC to WLAN through the Access-Challenge message, where MAC is generated by U-AAA according to the received random number Nonce_MT and the EAP-Request message to be issued. Step 512: After receiving the Access-Challenge message sent from U-AAA, WLAN separates the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sends the separated message to WLAN MS. Step 513: After receiving the EAP-Request/UIM/Challenge message, WLAN MS will first verify whether the MAC in the EAP message is correct, if incorrect, WLAN MS will send to the network an Incorrect message and terminate this process, otherwise, WLAN MS will extract RANDU therefrom, and calculate the first authentication number (AUTHUl) based on RANDU and the ESN, SSD, MIN acquired from UIM. Step 514: WLAN MS sends AUTHUl, ESN, MIN and the re-calculated MAC to WLAN through the EAP-Response/UIM/Challenge message. Step 515: WLAN encapsulates the received EAP-Response/UIM/Challenge message into the Access-Request message of the Radius protocol, and sends the Access-Request message that completes the encapsulation to U-AAA. Step 516: After receiving the Access-Request message sent from WLAN, U-AAA obtains the AUTHUl therein, and judges whether AUTHUl is consistent with the self-calculated AUTHU2, if consistent, the authentication of WLAN MS by U-AAA succeeds, otherwise the authentication fails. Step 517: U-AAA sends to the network side an Access-Accept message containing the EAP-Success message (authentication succeeds); or U-AAA sends to WLAN an Access-Reject message containing the EAP-Failure message (authentication fails). Step 518: After receiving the Access-Accept message sent from U-AAA, WLAN separates the EAP-Success message therein, and sends the EAP-Success message to WLAN MS, informing WLAN MS that the authentication succeeds; if receiving an Access-Reject message, WLAN separates the EAP-Failure message therein, and sends the EAP-Failure message to each WLAN MS, informing WLAN MS that the authentication fails. As shown in Figure 6, when AT is in a state of first-time power-on, the specific authentication process is as follows: Steps 601 - 615 are the same as steps 501 - 515 in Figure 5. Steps 616 - 617: U-AAA compares the obtained AUTHUl with AUTHUl stored locally, if they are identical, the authentication of the client succeeds and U-AAA sends an EAP-Success message to WLAN MS via WLAN, otherwise U-AAA returns an authentication failure message to HLR. After receiving the returned message, HLR I generates two random numbers, RANDSSD and RANDU, randomly, calculates the corresponding AUTHU based on RANDU, and then sends RANDSSD/RANDU/AUTHU to U-AAA, starting an SSD updating process. Step 618: U-AAA sends to WLAN an Access-Challenge message, which contains the EAP- Request/UIM/Update message carrying the random number RADNSSD. Step 619: WLAN sends the EAP-Request/UIM/Update message to WLAN MS. Step 620: After receiving the EAP-Request/UIM/Update message sent from WLAN, WLAN MS translates the RANDSSD therein, then calculates its own new SSD, randomly generates a random number RANDBS, calculates the corresponding authentication number AUTHBS based on the new SSD, and sends RANDBS to WLAN through the EAP-Response/UIM/Challenge message, starting the authentication of U-AAA. Step 621: WLAN sends the EAP-Response/UIM/Challenge message to the authentication server U-AAA in the format of EAP Over RADIUS message. Step 622: After receiving the EAP-Response/UIM/Challenge message, U-AAA acquires the BS inquiry random number (RANDBS) and the corresponding inquiry authentication result (AUTHBS) through interaction with HLR, where HLR generates RANDBS randomly and obtains AUTHBS through calculation based on this random number and the self-stored SSD. Step 623: U-AAA sends the Access-Challenge message to WLAN, which contains the EAP-Request/UIM/Challenge message carrying AUTHBS. Step 624: After receiving the EAP-Request/UIM/Challenge message, WLAN sends the message to WLAN MS. Step 625: After receiving the EAP-Request/UIM/Challenge message sent from WLAN, WLAN MS translates the AUTHBS therein, and compares the translated AUTHBS with the self-calculated AUTHBS, if they are identical, the authentication of U-AAA by WLAN MS succeeds and WLAN MS sends the EAP-Reauest/UIM/success message to WLAN. Step 626: After receiving this message, WLAN sends the EAP-Request/UIM/success message to the authentication server U-AAA in the format of Access-Request message and carrying the relevant attributes of RADIUS, which indicates the end of the SSD updating process. Step 627: After receiving the Access-Request message sent from WLAN, U-AAA decides to adopt the unique inquiry mode according to the RANDU and AUTHBS received from HLR in step 616. Steps 628 - 635 are the same to steps 511 - 518 in Figure 5. In step 632, U-AAA instructs HLR/AuC at the same time to update the SSD stored in AuC, and AuC updates local SSD according to the received message of instruction. With reference to the accompanying drawing and Embodiment 2, the technical solution in accordance with this invention is hereinafter described again in detail. As shown in Figure 7, this embodiment adopts the global authentication mode, and the process of authentication of WLAN MS is as follows: Step 701: A physical connection is set up between WLAN MS and WLAN. Step 702: WLAN MS makes a request to the network for authentication, i.e. WLAN MS sends to the network an EAPoL-Start message. Step 703: WLAN sends to WLAN MS an EAP-Request/Identity message, starts the authentication and requests WLAN MS to submit the user identifier. Step 704: After receiving the EAP-Request/Identity message, WLAN MS reads out the information stored in UIM via the appropriate interface, takes the information as its own user identifier, and sends the identifier to WLAN through the EAP-Response/Identity message. Step 705: After receiving the EAP-Response/Identity message, WLAN initiates an authentication request through the Access-Request message of the Radius protocol, and the EAP-Response/Identity message is encapsulated in the Access-Request message. Step 706: After receiving the Access-Request message sent from WLAN, U-AAA extracts the user identifier carried therein, and then decides the type of the user identifier according to the relevant configuration information of its own, if it is the UIM type, encapsulates an EAP-Request/TJIM/Start message in the Access-Challenge message and sends it to WLAN, otherwise performs no processing. Step 707: After receiving the Access-Challenge message, WLAN separates the EAP-Request /UIM/Start message therefrom, and then sends the separated message to WLAN MS. Step 708: After receiving the EAP-Request/UIM/Start message sent from WLAN, WLAN MS sends to WLAN the EAP-Response/UIM/Start message, indicating that it agrees to use the EAP-UIM authentication protocol. Step 709: After receiving the EAP-Response/UIM/Start message sent from WLAN MS, WLAN encapsulates the EAP-Response/UIM/Start message in the Access-Request message, and then sends the Access-Request message to U-AAA. Step 710: After receiving the Access-Request message sent from WLAN, U-AAA decides to use the global athentication mode, i.e. U-AAA generates the random number for authentication of WLAN MS (RAND) - the second random number, and calculates according to the self-stored SSD the second authentication number (AUTHR2) corresponding to this random number, thereby forming an authentication set. Moreover, U-AAA calculates the appropriate Message Authentication Code (MAC) by means of a certain algorithm. Step 711: U-AAA encapsulates RAND and MAC in the EAP-Request/UIM/Challenge message, and then sends them to WLAN through the Access-Challenge message. Step 712: After receiving the Access-Challenge message sent from U-AAA, WLAN separates the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sends the separated message to WLAN MS. Step 713: After receiving the EAP-Request/UIM/Challenge message, WLAN MS will extract RAND therefrom, and calculate the first authentication number (AUTHRl) based on RAND and the password read out from UIM. Step 714: WLAN MS sends AUTHRl, ESN, MIN, MAC and RANDC to WLAN through the EAP-Response/UIM/Challenge message, where the RANDC is derived by WLAN MS according to the received RAND. Step 715: WLAN encapsulates the received EAP-Response/UIM/Challenge message into the Access-Request message of the Radius protocol, and sends the Access-Request that completes the encapsulation message to U-AAA. Step 716: After receiving the Access-Request message sent from WLAN, U-AAA determines the corresponding RAND according to the RANDC therein, and then judges whether the SSD of the user has been obtained, if yes, translates the AUTHRl therein and judges whether the received AUTHRl is consistent with the self-calculated AUTHU2 of the user terminal, if consistent, the authentication of WLAN MS by U-AAA succeeds, otherwise the authentication fails. Step 717: U-AAA sends to WLAN an Access-Accept message containing the EAP-Success message and the value of MAC; or U-AAA sends to WLAN an Access-Reject message containing the EAP-Failure message and the value of MAC. Step 718: After receiving the Access-Accept message sent from U-AAA, WLAN separates the EAP-Success message therein, and sends the EAP-Success message to WLAN MS, informing WLAN MS that the authentication succeeds; if receiving an Access-Reject message, WLAN separates the EAP-Failure message therein, and sends the EAP-Failure message to each WLAN MS, informing WLAN MS that the authentication fails. WLAN MS will first verify the MAC, and confirms that this EAP-request message is correct only when the received MAC is identical with the MAC calculated locally. It can be seen from the foregoing embodiments that this authentication process is started when a user desires to access a WLAN-3GPP2 inter-working network or the network desires to re-authenticate a WLAN user having passed authentication. Embodiment 1 is a unique inquiry process and Embodiment 2 is a global authentication process. The two processes are basically the same, except that the types of the random number generated when U-AAA makes authentication of WLAN MS are different and some of the parameters carried in the authentication messages between WLAN MS and U-AAA are different. Major differences between Embodiment 1 and Embodiment 2 are: (1) Types of the random numbers generated are different. In the unique inquiry mode, U-AAA generates RANDU and AUTHU while in the global authentication mode, U-AAA generates RAND and AUTHR. (2) In the unique inquiry mode, when U-AAA sends the generated RANDU to WLAN MS, WLAN MS generates AUTHU through the CAVE algorithm with RANDU, A-key, MIN, and ESN as the input parameters while in the global authentication mode, when U-AAA sends the generated RAND to WLAN MS, WLAN MS generates AUTHR through the CAVE algorithm with RAND, A-key, MIN, and ESN as the input parameters. (3) In the unique inquiry mode, after obtaining AUTHU by calculation, WLAN MS sends this parameter to U-AAA while in the global authentication mode, after obtaining AUTHR by calculation, WLAN MS sends to U-AAA this parameter as well as the parameter RANDC which is derived from RAND. Embodiment 1 and Embodiment 2 are the same in the following: (1) After obtaining AUTHU or AUTHR by calculation, WLAN MS sends to U-AAA a response message, which in either case will contain the ESN and MIN of the WLAN MS. (2) After receiving the UIM authentication starting message, EAP-request/UIM/Start, sent from U-AAA, WLAN MS generates internally a random number, AT_NONCE_MT, and sends to U-AAA this random number through the EAP-response/UIM/Start message to be used as the parameter for authentication of the network by a terminal. (3) After receiving the ATNONCEMT sent from WLAN MS, U-AAA calculates a responding MAC by algorithm, and sends the MAC to WLAN MS through the follow-on EAP-request message. WLAN MS will first verify the MAC, and will only confirm that this EAP-request message is correct when the received MAC is found identical with the MAC calculated locally. To sum up, the foregoing description is only preferred embodiments of this invention and should not be construed as restrictive to the protection scope thereof. WE CLAIM: 1. A method for implementing authentication of high-rate packet data services, comprising the steps of: A) the authentication entity carrying out authentication of a user terminal having set up a physical connection with the Access Network (AN) by means of the User identity Module (UIM)-based authentication mechanism, and using the user information stored in the UIM of the user terminal itself as the user identifier; B) the authentication entity, according to said user identifier, acquiring the second random number for authentication of the user terminal and the second authentication number corresponding to the second random number, wherein the second authentication number is calculated by the Shared Secret Data (SSD) of this user terminal stored at the network side; C) said user terminal obtaining the first authentication number by calculation based on the second random number and the self-stored SSD; the authentication entity comparing the first authentication number with the second authentication number, if yes, the authentication of the user terminal by the authentication entity succeeds, otherwise, the authentication fails. 2. The method according to Claim 1, wherein said authentication entity is a pre-configured authentication server or the authentication center in a wireless mobile communications system. 3. The method according to Claim 2, wherein, if the authentication entity is the authentication center in a wireless mobile communications system, said second random number is generated from the authentication center (AuC) of the wireless mobile communications system, and said SSD are stored in the Home Location Register (HLR)/AuC at the network side. 4. The method according to Claim 2, wherein, if the authentication entity is a pre-configured authentication server, said second random number is generated from this authentication server, and said SSD is stored in the HLR/AuC at the network side or in this authentication server. 5. The method according to Claim 1, comprises after the authentication fails in step C: the authentication entity notifying the HLR at the network side of the authentication result, and the HLR judging whether this authentication is a first-time authentication, if yes, updating the SSD and then performing step C, otherwise the authentication fails. 6. The method according to Claim 1, comprises step D, updating the SSD after the authentication fails, and then performing step C. 7. The method according to Claim 5 or 6, wherein step D comprises the steps: Dl) HLR generating a Shared Secret Data updating random number (RADNSSD), and calculating the authentication number corresponding to the SSD-updating random number; D2) the user terminal recalculating its own SSD based on said SSD-updating random number by means of the original SSD-generating algorithm of the system, and then calculating the authentication number corresponding to the SSD-updating random number based on the re-calculated SSD; . /D D3) judging by comparison whether the authentication number calculated by tne user terminal and the authentication number calculated in the HLR is consistent, if consistent, updating the SSD at the user terminal side, otherwise SSD-updating fails. 8. The method according to Claim 7, wherein step Dl comprises HLR sending the (RADNSSD) and the corresponding authentication number to the authentication entity; the authentication entity sending to AN an Access-Challenge message which carries the Extensible Authentication Protocol (EAP)-Request/U1M/Update message with RADNSSD; AN sending the EAP-Request/UIM/Update message to the user terminal. 9. The method according to Claim 8, wherein step D2 comprising: after receiving the EAP-Request/UIM/Update message sent by AN, the user terminal calculating new SSD using RADNSSD, randomly generating a base-station inquiry random number (RANDBS), calculating a base-station inquiry authentication number (AUTHBS) corresponding to RANDBS based on the new SSD, and then sending RANDBS to AN through the EAP-Response/UIM/Challenge message; AN sending the EAP-Response/UIM/Challenge message to the authentication entity; the authentication entity acquiring the base-station inquiry random number RANDBS and the corresponding base-station inquiry authentication number AUTHBS through interaction with HLR, wherein said AUTHBS is obtained by calculation based on RANDBS and the self-stored SSD; the authentication entity sending to AN an Access-Challenge message, which carries the EAP-Request/UIM/Challenge message with the base-station inquiry authentication number AUTHBS; after receiving this message, AN sending the message to the user terminal. 10. The method according to Claim 8, wherein step D3 comprising: after receiving the EAP-Request/UIM/Challenge message, the user terminal judging by comparison whether the AUTHBS therein and the self-calculated AUTHBS are consistent, if consistent, updating the SSD of the user terminal side, the user terminal succeeding in the authentication of the authentication entity and sending an EAP-Response/UIM/success message to AN; after receiving this message, AN sending to the authentication entity the EAP-Response/UIM/success message, which carries the attributes of relevant RADIUS; after receiving this message, the authentication entity updating the SSD of the user. 11. The method according to Claim 7, wherein said own SSD in step D2 is calculated based on said SSD-updating random number, Electronic Serial Number (ESN), and A-key. 12. The method according to Claim 1, wherein step A comprising the steps: Al) AN sending an authentication request to the user terminal; A2) after receiving this authentication request, the user terminal reading out the user information stored in the UIM, taking this user information as its own user identifier, and then sending said user identifier to the authentication entity via AN. 13. The method according to Claim 12, wherein, when the authentication request is sent through EAP, sending the authentication request to the user terminal by AN is implemented through an EAP-Request/Identity message; and Step A2 comprises: said user terminal sending the user identifier to AN through an EAP-Response/Identity message; after receiving this message, AN sending the message to U-AAA through an Access-Request message, initiating an authentication request to U-AAA. 14. The method according to Claim 1, wherein step B comprises: U-AAA sending the acquired second random number for authentication of the I.' user terminal to the user terminal via AN. 15. The method according to Claim 14, wherein the step of sending the second random number to the user terminal via AN comprises: the authentication entity encapsulating said second random number in the EAP-Request/UIM/Challenge message, and then sending this message to AN through an Access-Challenge message; after receiving the Access-Challenge message sent from the authentication entity, AN separating the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sending the separated message to the user terminal. 16. The method according to Claim 1, wherein step C comprises: after obtaining the first authentication number by calculation, the user terminal sending the first authentication number to the authentication entity via AN. 17. The method according to Claim 16, wherein the step of the user terminal sending the first authentication number to the authentication entity via AN comprises: the user terminal sending the first authentication number to AN through an EAP-Response/UIM/Challenge message; AN encapsulating the received EAP-Response/UIM/Challenge message in the Access-Request message, and sending the Access-Request message that completes the encapsulation to the authentication entity. 18. The method according to Claim 1, comprising while performing step C: the authentication entity notifying the user terminal via AN that the authentication succeeds/fails. 19. The method according to Claim 1, wherein said AN comprises WLAN.

Full Text

Field of the invention
The present invention relates to network authentication techniques, and particularly to a method for implementing authentication of high-rate packet data services.
Background of the invention
CDMA is an advanced technology of digital cellular mobile communications and one of the most important radio transmission technologies (RTT) of 3G accepted by the International Telecommunications Union (ITU). Since the first release of CDMA standards by QUALCOMM Incorporated in 1990, there have been two important stages in the evolution of CDMA technology, i.e. IS95 and CDMA2000 lx.
As shown in Figure 1, the network architecture of CDMA2000 lx consists of Mobile Station (MS), Base Transceiver Station (BTS), Base Station Controller (BSC), Packet Control Function (PCF), Packet Data Service Node (PDSN), Authentication, Authorization, Accounting server (AAA), and IS-41 core network, where IS-41 core network includes Mobile Switching Center (MSC), Visiting Location Register (VLR), and Home Location Register (HLR).
User authentication in CDMA IS95 and CDMA 2000 lx networks is completed jointly by MSC/VLR and HLR/Authentication Center (AuC). Moreover, the Shared Secret Data (SSD) are stored in the terminal and HLR/AuC as one of the input parameters for authentication while identical passwords (A-key) are stored in the terminal and HLR/AC specially for use in updating SSD. When authentication is needed, the authentication result is obtained by calculation through the algorithm of Cellular Authentication and Voice Encryption (CAVE) with such parameters as SSD, random number, Electronic Serial Number (ESN), and Mobile Station Identity Number (MIN), and MSC/VLR or HLR/AuC will compare the authentication result to check whether it is consistent or not; if not consistent, the system will initiate an updating of SSD. After the updating of SSD is successful, i.e. the SSD at the terminal side and SSD at the network

side are consistent, next authentication will succeed only when the authentication result calculated by the user with SSD is consistent with the authentication result calculated by HLR/AuC.
CDMA 2000 HRPD (CDMA 2000 lxEV-DO), simplified as HRPD, is an upgraded technology of CDMA 2000 lx, providing high-rate packet data service with a single-user downstream rate up to 2.4Mbps.
As shown in Figure 2, the networking architecture of HRPD consists of Access Terminal (AT), Access Network (AN), AN AAA, PCF, PDSN, and AAA. User authentication is implemented in an HRPD network mainly by AN AAA. After authentication succeeds, AN AAA will return to AT the International Mobile Subscriber Identity (IMSI) of the terminal for use in later switching and charging processes. In the authentication process of HRPD, the interface A12 between BSC/PCF and AN AAA is used and this interface adopts the Remote Access Dial User Service (RADIUS) protocol with the Password Authentication Protocol (PAP) and Check-Handshake Authentication Protocol (CHAP) as the main authentication mechanisms. Since CHAP has relatively better performance in security, there are more applications of CHAP in authentication.
CHAP adopts the private-key-based Message Digest (MD) identity authentication algorithm. As shown in Figure 3, take the CHAP protocol as an example and the authentication process through RADIUS protocol specifically comprises:
Step 301: The user terminal consults with the network side via PPP/LCP and decides to use CHAP for authentication;
Step 302: AN sends a Challenge message to the user terminal to initiate authentication, and the message contains the random number generated by AN;
Step 303: The user terminal calculates the digest with the random number by means of the encryption algorithm prescribed by CHAP, and then sends the user name and digest to AN via a Response message;
Step 304: At Interface A12, AN uses an Access Request message of the RADIUS protocol to carry the user name, random number and digest, and sends the message to AN AAA;

Step 305: AN AAA calculates a digest with the random number by means of the same algorithm and judges by comparison whether this digest is consistent with the digest sent up from the terminal, if consistent, the authentication succeeds and AN AAA sends an Access Accept message to AN, otherwise the authentication fails;
Step 306: AN sends a Success message to the user terminal, notifying the user terminal that the authentication is successful.
It can be seen from the above process that authentication of HRPD users in the prior art requires the use of AN AAA and the authentication is a one-way process.
At present, along with the development of market economy and technology, more and more operators desire to operate various networks simultaneously. For example, an operator of IS95/CDMA 2000 lx network would like to expand its service to CDMA 2000 lxDO network while authentication in CDMA 2000 lxDO requires setting up of a special AN AAA for authentication. For a user of multi-mode terminal, this approach of authentication requires opening accounts at both HLR and AN AAA, making authentication modes not unified and maintenance inconvenient, which is not conducive to unified operation. Moreover, this approach requires a special nation-wide network of AN AAA for HRPD user authentication, resulting in high cost in network construction. In addition, as authentication of this approach is a one-way process to the user, it is not reliable in security.
Besides, Wireless Local Area Network (WLAN) is attracting more and more attentions as a high-rate wireless data access technique. A WLAN is typically used for transmission of IP data packets, i.e. implementing the wireless access of a user terminal via Access Point (AP) and then the transmission of IP packets via network controller and connecting devices. Various techniques have been used in WLAN, among which a technical standard with more applications is IEEE 802.11b. This standard utilizes the frequency band of 2.4GHz with a data transmission rate up to 11 Mbps. Other technical standards utilizing the same frequency band include IEEE 802.1 lg and the Bluetooth, where the data transmission rate of IEEE 802.1 lg is up to 54Mbps. Other new standards, such as IEEE 802.11a and ETSI BRAN Hiperlan2, utilize the frequency band of 5GHz with a transmission rate up to 54 Mbps as well.

Along with the rising and developing of WLAN, focus of research is shifting to the inter-working of WLAN with various wireless mobile communications networks, such as GSM, CDMA, WCDMA, TD-SCDMA, and CDMA2000. In the 3GPP2 standardization organization, research is being carried out on the access of WLAN users to 3GPP2 networks.
Summary of the invention
In view of the above, the object of this invention is to provide a method for implementing authentication of high-rate packet data services such that the authentication could be easy in operation and convenient in maintenance. The method comprises:
A. the authentication entity carries out authentication of a user terminal having set up
a physical connection with AN by means of the UIM (User Identity Module) -based
authentication mechanism, and uses the user information stored in the UIM of the user
terminal itself as the user identifier;
B. the authentication entity, according to said user identifier, generates the second
random number for authentication of the user terminal and the second authentication
number that is corresponding to the second random number and is calculated by the SSD
of this user terminal stored at the network side;
C. said user terminal makes calculation based on the second random number and the
self-stored SSD and obtains the first authentication number; the authentication entity
compares the first authentication number with the second authentication number, if yes,
the authentication of the user terminal by the authentication entity succeeds, otherwise,
the authentication fails.
Said authentication entity comprises a pre-configured authentication server or the authentication center in a wireless mobile communications system.
If the authentication entity is the authentication center in a wireless mobile communications system, said second random number is acquired from the authentication center of the wireless mobile communications system, and said SSD are stored in the HLR/AuC at the network side.

If the authentication entity is a pre-configured authentication server, said second random number is acquired from this authentication server, and said SSD is stored in the HLR/AuC at the network side or in this authentication server.
After the authentication fails in step C, the method further comprises: The authentication entity notifying the HLR at the network side of the authentication result, and the HLR judging whether this authentication is a first-time authentication, if yes, updating the SSD and then performing step C, otherwise the authentication fails.
After the authentication fails in step C, the method further comprises: Updating the SSD, and then performing step C.
The process of updating the SSD comprises:
Dl. HLR generating an SSD-updating random number, and calculating the authentication number corresponding to the SSD-updating random number;
D2. the user terminal recalculating its own SSD based on said SSD-updating random number by means of the original SSD-generating algorithm of the system, and then calculating the authentication number corresponding to the SSD-updating random number based on the re-calculated SSD;
D3. judging by comparison whether the authentication number calculated by the user terminal and the authentication number calculated in the HLR is consistent, if consistent, updating the SSD at the user terminal side, otherwise SSD-updating fails.
Step Dl further comprises:
Dll. HLR sending the SSD-updating random number (RADNSSD) and the corresponding authentication number to the authentication entity;
D12. the authentication entity sending to AN an Access-Challenge message, which carries the EAP-Request/UIM/Update message of RADNSSD.
D13. AN sending the EAP-Request/UIM/Update message to the user terminal.
Step D2 comprises:
D21. after receiving the EAP-Request/UIM/Update message sent by AN, the user terminal calculating new SSD using RADNSSD, randomly generating a random number RANDBS, then calculating an authentication number AUTHBS corresponding to

RANDBS based on the new SSD, and then sending RANDBS to AN through the EAP-Response/UIM/Challenge message;
D22. AN sending the EAP-Response/UIM/Challenge message to the authentication entity; the authentication entity acquiring the base-station inquiry random number RANDBS and the corresponding inquiry authentication number AUTHBS through interaction with HLR, wherein AUTHBS is obtained by calculation based on RANDBS and the self-stored SSD;
D23. the authentication entity sending to AN an Access-Challenge message, which carries the EAP-Request/UIM/Challenge message with the authentication number AUTHBS; after receiving this message, AN sending it to the user terminal.
Step D3 comprises:
D31. after receiving the EAP-Request/UIM/Challenge message, the user terminal judging by comparison whether the AUTHBS therein and the self-calculated AUTHBS are consistent, if consistent, updating the SSD of the user terminal side, the user terminal succeeding in the authentication of the authentication entity and sending an EAP-Response/UIM/success message to AN;
D32. after receiving this message, AN sending to the authentication entity the EAP-Response/UIM/success message, which carries the attributes of relevant RADIUS, after receiving this message, the authentication entity updating the SSD of the user.
Said own SSD in step D2 is calculated based on said SSD-updating random number,
ESN, ;.uul VkeyMSl. ami-password.
Step A comprises:
Al. AN sending an authentication request to the user terminal;
A2. after receiving this authentication request, the user terminal reading out the user information stored in the UIM, taking this user information as its own user identifier, and then sending said user identifier to the authentication entity via AN.
Said AN communicates with the user terminal through EAP or CHAP.
When the authentication request is sent through EAP, sending the authentication request to the user terminal by AN in step Al is implemented through an EAP-Request/Identity message.

Step A2 comprises:
A21. said user terminal sending the user identifier to AN through an EAP-Response/Identity message;
A22. after receiving this message, AN sending the message to U-AAA through an Access-Request message, initiating an authentication request to U-AAA.
Step B further comprises:
U-AAA sending the acquired second random number for authentication of the user terminal to the user terminal via AN.
The step of sending the second random number to the user terminal via AN comprises:
Bl. the authentication entity encapsulating said second random number in the EAP-Request/UIM/Challenge message, and then sending this message to AN through an Access-Challenge message;
B2. after receiving the Access-Challenge message sent from the authentication entity, AN separating the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sending the separated message to the user terminal.
Step C further comprises:
After obtaining the first authentication number by calculation, the user terminal sending the first authentication number to the authentication entity via AN.
The step of the user terminal sending the first authentication number to the authentication entity via AN in step C comprises:
CI. the user terminal sending the first authentication number to AN through an EAP-Response/UIM/Challenge message;
C2. AN encapsulating the received EAP-Response/UIM/Challenge message in the Access-Request message, and sending the Access-Request message that completes the encapsulation to the authentication entity.
While performing step C, the method further comprises:
the authentication entity notifying the user terminal that the authentication succeeds/fails via AN.

Said authentication entity and HLR communicate through ANSI-41D protocol. Said AN comprises WLAN.
It can be seen from the foregoing method that this invention has the following merits and features:
1. This invention supports nation-wide roaming by utilizing the existing CDMA IS-41 core network, and there is no need of constructing a new nation-wide special network of AN AAA. Thus, the cost of investment is reduced.
2. Unified authentication in a multi-mode network is conducted, and there is no need for the user to input the user name and password manually, so the operation is convenient. Furthermore, as unified account-opening, unified identification and unified authentication can be conducted in HLR via IMSI for HRPD services and services of other networks, the method brings convenience to the operators. Meanwhile, it is possible for HRPD users to continue to use their previous UIM cards of IS95/CDMA2000 lx, therefore, it is conducive to the transfer of IS95/CDMA2000 lx users to HRPD networks.
3. By means of EAP-UIM protocol, it is also possible for a user terminal to make authentication of the network side such that the mutual authentication between the network and terminal, i.e. authentication of terminal by network and authentication of network by terminal, is implemented. Therefore, the method is more reliable in security.
Brief description of the drawings
Figure 1 is a schematic diagram illustrating the networking of IS95/CDMA2000 lx system;
Figure 2 is a schematic diagram illustrating the networking of an HRPD network;
Figure 3 is a schematic diagram illustrating the HRPD authentication process in the prior art;
Figure 4 is a schematic diagram illustrating the networking architecture in accordance with this invention;

Figure 5 is a schematic diagram illustrating the authentication process at first-time power-on in Embodiment 1 of this invention;
Figure 6 is a schematic diagram illustrating the authentication process at second-time power-on in Embodiment 1 of this invention;
Figure 7 is a schematic diagram illustrating the authentication process at first-time power-on in Embodiment 2 of this invention;
Figure 8 is a schematic diagram illustrating an exemplary communication process between a user terminal and the access network by CHAP in accordance with this invention.
Embodiments of the Invention
The core idea of this invention is: the authentication entity carries out authentication of a user terminal having set up a physical connection with AN by means of the UIM-based authentication mechanism, and uses the user information stored in the UIM of the user terminal itself as the user identifier; the authentication entity, according to said user identifier, generates the second random number for authentication of the user terminal and the second authentication number that is corresponding to the second random number and is calculated according to the SSD stored at the network side; said user terminal makes calculation based on the second random number and the self-stored SSD and obtains the first authentication number; the authentication entity compares the first authentication number with the second authentication number, if they are identical, the authentication of the user terminal by the authentication entity succeeds, otherwise, the authentication fails.

The network by which a user terminal gets accessed may comprise a WLAN.
The main distinguishing features of the present invention as compared with the prior
art include the following aspects. The authentication entity may comprise a pre-
configured authentication server or the original authentication center. The
authentication server may communicate with HLR via the ANSI-41D protocol. The
second random number may be generated by any entity at the network side, such as
HLR/AuC, AAA, and etc. The SSD may be stored in the HLR/AuC at the network
side or in the authentication server. When

from the HLR/AuC. When the second random number is generated by AAA, the second authentication number can be acquired from the HLR/AuC according to the user identifier and the first random number. The user terminal and AN may communicate with each other by means of CHAP or EAP, or by the original CDMA2000 messages for wireless-channel interface.
The technical solution in accordance with the present invention is hereinafter described in detail with reference to the accompanying drawings and specific embodiments.
As shown in Figure 4, the networking architecture in accordance with this invention includes AT (user terminal), AN, UIM-based Authentication, Authorization and Accounting server (U-AAA), PCF, PDSN, AAA, HLR, where AN provides the data connection between a terminal and a packet data switching network, being an equivalent of BTS and BSC in CDMA2000 lx and, obviously, an equivalent of WLAN as well; and the U-AAA is pre-configured and special for authentication and accounting.
The network elements used herein, such as BTS, PCF, PDSN, HLR, need not to be modified; the user terminal is required to be an HRPD terminal or a hybrid terminal supporting HRPD, such as a HRPD/GSM, HRPD/CDMA2000 lx, or HRPD/WLAN terminal, while the hardware thereof supports the reading of UIM cards or provides interface to external card-reader, and supports EAP-UIM protocol as well as authentication by GSM HLR or CDMA HLR; AN is required to support the authentication protocol at the wireless-channel interface and the interface A12, where the wireless-channel interface is EAP-UIM over PPP and A12 is EAP-UIM over RADIUS. AAA can be removed while the accounting function is implemented by the pre-configured U-AAA. Replacing AN AAA with the network element U-AAA is mainly because of the requirement for supporting the CDMA IS41 protocol as well as the authentication protocol of EAP-UIM over RADIUS. In addition, HLR and AuC are usually located in the same entity, thus referred to hereinafter as HLR.
It should be noted that the authentication process after the first-time power-on comprises three parts, i.e. the first-time authentication, SSD updating, and second-time authentication. The authentication conducted at the first-time power-on of AT is the

first-time authentication, and since the SSD stored at the system side and the SSD stored at AT side are not consistent when AT switches on for the first time, the first-time authentication of AT always fails. Therefore, SSD updating is needed after the first-time authentication fails, i.e. issue RANDSSD through the EAP-REQUEST/UIM/Update message and calculate the new SSD at AT and HLR by the same SSD-generating algorithm with RANDSSD, ESN, and A-key. As these parameters at AT side and at HLR side are identical and so are the algorithms used, the SSD outputted will be the same. After the SSD updating, the second-time authentication is made. At this time, since it is guranteed that the SSD at AT side and SSD at HLR side are identical, the second-time authentication will succeed in normal conditions. For users switching on again, the SSD at the system side and SSD at AT side are the same, thus there is no need of SSD updating and second-time authentication, and it is sufficient to make authentication only once to achieve success.
With reference to Figure 8, the communications between a user terminal and the access network is hereinafter described by taking CHAP as an example. The process is as follows:
Step 801: An HRPD session is set up between AT and AN, and AT is prepared to exchange data on the accessing stream.
Step 802: AT and AN initiate PPP and LCP consultation for an access authentication.
Step 803: AN initiates a Random Challenge and sends it to AT through a CHAP Challenge message.
Step 804: AT makes CAVE-based authentication, and sends a CHAP Response
message.
Step 805: AN sends to U-AAA an Al2-Access Request message.
Step 806: U-AAA constructs an AUTHREQ message based on the contents of the A12-Access Request message, and sends the AUTHREQ message to HLR/AuC.

Step 807: HLR/AuC performs the CAVE-based authentication process, if the authentication succeeds, HLR/AuC will send to U-AAA an authrep message containing the SSD parameter.
Step 808: U-AAA stores the SSD assigned by HLR/AuC.
Step 809: U-AAA sends to AN an A12-Access Accept message.
Step 810: AN returns to AT an instruction of CHAP Authentication Success.
Step 811: AT and AN continue with the subsequent processing steps.
The technical solution in accordance with the present invention is hereinafter described in detail with reference to the accompanying drawings and Embodiment 1.
As shown in Figure 5, when a user terminal is in a state of non-first-time power-on, the specific process for implementing authentication is as follows:
Step 501: A physical connection is set up between WLAN MS and WLAN.
Step 502: WLAN MS initiates an authentication request to WLAN, i.e. WLAN MS sends to the network an EAPoL-Start message.
Step 503: WLAN sends to WLAN MS an EAP-Request/Identity message, starts the authentication and requests WLAN MS to submit the user identifier.
Step 504: After receiving the EAP-Request/Identity message, WLAN MS reads out the information stored in UIM via the appropriate interface, takes the information as its own user identifier, and sends the identifier to WLAN through the EAP-Response/Identity message.
Step 505: After receiving the EAP-Response/Identity message, WLAN initiates an authentication request through the Access-Request message in the Radius protocol, and the EAP-Response/Identity message is encapsulated in the Access-Request message.
Step 506: After receiving the Access-Request message sent from WLAN, U-AAA extracts the user identifier carried therein, and then decides the type of the user identifier

according to the relevant configuration information of its own, if it is the UIM type, encapsulates an EAP-Request/UIM/Start message in the Access-Challenge message and sends it to WLAN, otherwise performs no processing.
Step 507: After receiving the Access-Challenge message, WLAN separates the EAP-Request /UIM/Start message therefrom, and then sends the separated message to WLAN MS.
Step 508: After receiving the EAP-Request/UIM/Start message sent from WLAN, WLAN MS includes a self-generated random number NonceJVIT in the attribute AT_NONCE MT, and then sends to WLAN the EAP-Response/UIM/Start message containing this random number, indicating that it agrees to use the EAP-UIM authentication protocol.
Step 509: After receiving the EAP-Response/UIM/Start message sent from WLAN MS, WLAN encapsulates the EAP-Response/UIM/Start message in the Access-Request message, and then sends the Access-Request message to U-AAA.
Step 510: After receiving the Access-Request message sent from WLAN, U-AAA decides to adopt the unique inquiry mode, i.e. U-AAA generates the random number for authentication of WLAN MS (RANDU) - the second random number, and calculates the second authentication number corresponding to this random number according to the self-stored SSD, thereby forming an authentication set.
Step 511: U-AAA encapsulates RANDU in the EAP-Request/UIM/Challenge message, and then sends RANDU and MAC to WLAN through the Access-Challenge message, where MAC is generated by U-AAA according to the received random number Nonce_MT and the EAP-Request message to be issued.
Step 512: After receiving the Access-Challenge message sent from U-AAA, WLAN separates the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sends the separated message to WLAN MS.
Step 513: After receiving the EAP-Request/UIM/Challenge message, WLAN MS will first verify whether the MAC in the EAP message is correct, if incorrect, WLAN MS will send to the network an Incorrect message and terminate this process, otherwise,

WLAN MS will extract RANDU therefrom, and calculate the first authentication number (AUTHUl) based on RANDU and the ESN, SSD, MIN acquired from UIM.
Step 514: WLAN MS sends AUTHUl, ESN, MIN and the re-calculated MAC to WLAN through the EAP-Response/UIM/Challenge message.
Step 515: WLAN encapsulates the received EAP-Response/UIM/Challenge message into the Access-Request message of the Radius protocol, and sends the Access-Request message that completes the encapsulation to U-AAA.
Step 516: After receiving the Access-Request message sent from WLAN, U-AAA obtains the AUTHUl therein, and judges whether AUTHUl is consistent with the self-calculated AUTHU2, if consistent, the authentication of WLAN MS by U-AAA succeeds, otherwise the authentication fails.
Step 517: U-AAA sends to the network side an Access-Accept message containing the EAP-Success message (authentication succeeds); or U-AAA sends to WLAN an Access-Reject message containing the EAP-Failure message (authentication fails).
Step 518: After receiving the Access-Accept message sent from U-AAA, WLAN separates the EAP-Success message therein, and sends the EAP-Success message to WLAN MS, informing WLAN MS that the authentication succeeds; if receiving an Access-Reject message, WLAN separates the EAP-Failure message therein, and sends the EAP-Failure message to each WLAN MS, informing WLAN MS that the authentication fails.
As shown in Figure 6, when AT is in a state of first-time power-on, the specific authentication process is as follows:
Steps 601 - 615 are the same as steps 501 - 515 in Figure 5.
Steps 616 - 617: U-AAA compares the obtained AUTHUl with AUTHUl stored locally, if they are identical, the authentication of the client succeeds and U-AAA sends an EAP-Success message to WLAN MS via WLAN, otherwise U-AAA returns an authentication failure message to HLR. After receiving the returned message, HLR

I
generates two random numbers, RANDSSD and RANDU, randomly, calculates the corresponding AUTHU based on RANDU, and then sends RANDSSD/RANDU/AUTHU to U-AAA, starting an SSD updating process.
Step 618: U-AAA sends to WLAN an Access-Challenge message, which contains the EAP- Request/UIM/Update message carrying the random number RADNSSD.
Step 619: WLAN sends the EAP-Request/UIM/Update message to WLAN MS.
Step 620: After receiving the EAP-Request/UIM/Update message sent from WLAN, WLAN MS translates the RANDSSD therein, then calculates its own new SSD, randomly generates a random number RANDBS, calculates the corresponding authentication number AUTHBS based on the new SSD, and sends RANDBS to WLAN through the EAP-Response/UIM/Challenge message, starting the authentication of U-AAA.
Step 621: WLAN sends the EAP-Response/UIM/Challenge message to the authentication server U-AAA in the format of EAP Over RADIUS message.
Step 622: After receiving the EAP-Response/UIM/Challenge message, U-AAA acquires the BS inquiry random number (RANDBS) and the corresponding inquiry authentication result (AUTHBS) through interaction with HLR, where HLR generates RANDBS randomly and obtains AUTHBS through calculation based on this random number and the self-stored SSD.
Step 623: U-AAA sends the Access-Challenge message to WLAN, which contains the EAP-Request/UIM/Challenge message carrying AUTHBS.
Step 624: After receiving the EAP-Request/UIM/Challenge message, WLAN sends the message to WLAN MS.
Step 625: After receiving the EAP-Request/UIM/Challenge message sent from WLAN, WLAN MS translates the AUTHBS therein, and compares the translated AUTHBS with the self-calculated AUTHBS, if they are identical, the authentication of U-AAA by WLAN MS succeeds and WLAN MS sends the EAP-Reauest/UIM/success message to WLAN.

Step 626: After receiving this message, WLAN sends the EAP-Request/UIM/success message to the authentication server U-AAA in the format of Access-Request message and carrying the relevant attributes of RADIUS, which indicates the end of the SSD updating process.
Step 627: After receiving the Access-Request message sent from WLAN, U-AAA decides to adopt the unique inquiry mode according to the RANDU and AUTHBS received from HLR in step 616. Steps 628 - 635 are the same to steps 511 - 518 in Figure
5.
In step 632, U-AAA instructs HLR/AuC at the same time to update the SSD stored in AuC, and AuC updates local SSD according to the received message of instruction.
With reference to the accompanying drawing and Embodiment 2, the technical solution in accordance with this invention is hereinafter described again in detail.
As shown in Figure 7, this embodiment adopts the global authentication mode, and the process of authentication of WLAN MS is as follows:
Step 701: A physical connection is set up between WLAN MS and WLAN.
Step 702: WLAN MS makes a request to the network for authentication, i.e. WLAN MS sends to the network an EAPoL-Start message.
Step 703: WLAN sends to WLAN MS an EAP-Request/Identity message, starts the authentication and requests WLAN MS to submit the user identifier.
Step 704: After receiving the EAP-Request/Identity message, WLAN MS reads out the information stored in UIM via the appropriate interface, takes the information as its own user identifier, and sends the identifier to WLAN through the EAP-Response/Identity message.
Step 705: After receiving the EAP-Response/Identity message, WLAN initiates an authentication request through the Access-Request message of the Radius protocol, and the EAP-Response/Identity message is encapsulated in the Access-Request message.

Step 706: After receiving the Access-Request message sent from WLAN, U-AAA extracts the user identifier carried therein, and then decides the type of the user identifier according to the relevant configuration information of its own, if it is the UIM type, encapsulates an EAP-Request/TJIM/Start message in the Access-Challenge message and sends it to WLAN, otherwise performs no processing.
Step 707: After receiving the Access-Challenge message, WLAN separates the EAP-Request /UIM/Start message therefrom, and then sends the separated message to WLAN MS.
Step 708: After receiving the EAP-Request/UIM/Start message sent from WLAN, WLAN MS sends to WLAN the EAP-Response/UIM/Start message, indicating that it agrees to use the EAP-UIM authentication protocol.
Step 709: After receiving the EAP-Response/UIM/Start message sent from WLAN MS, WLAN encapsulates the EAP-Response/UIM/Start message in the Access-Request message, and then sends the Access-Request message to U-AAA.
Step 710: After receiving the Access-Request message sent from WLAN, U-AAA decides to use the global athentication mode, i.e. U-AAA generates the random number for authentication of WLAN MS (RAND) - the second random number, and calculates according to the self-stored SSD the second authentication number (AUTHR2) corresponding to this random number, thereby forming an authentication set. Moreover, U-AAA calculates the appropriate Message Authentication Code (MAC) by means of a certain algorithm.
Step 711: U-AAA encapsulates RAND and MAC in the EAP-Request/UIM/Challenge message, and then sends them to WLAN through the Access-Challenge message.
Step 712: After receiving the Access-Challenge message sent from U-AAA, WLAN separates the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sends the separated message to WLAN MS.

Step 713: After receiving the EAP-Request/UIM/Challenge message, WLAN MS will extract RAND therefrom, and calculate the first authentication number (AUTHRl) based on RAND and the password read out from UIM.
Step 714: WLAN MS sends AUTHRl, ESN, MIN, MAC and RANDC to WLAN through the EAP-Response/UIM/Challenge message, where the RANDC is derived by WLAN MS according to the received RAND.
Step 715: WLAN encapsulates the received EAP-Response/UIM/Challenge message into the Access-Request message of the Radius protocol, and sends the Access-Request that completes the encapsulation message to U-AAA.
Step 716: After receiving the Access-Request message sent from WLAN, U-AAA determines the corresponding RAND according to the RANDC therein, and then judges whether the SSD of the user has been obtained, if yes, translates the AUTHRl therein and judges whether the received AUTHRl is consistent with the self-calculated AUTHU2 of the user terminal, if consistent, the authentication of WLAN MS by U-AAA succeeds, otherwise the authentication fails.
Step 717: U-AAA sends to WLAN an Access-Accept message containing the EAP-Success message and the value of MAC; or U-AAA sends to WLAN an Access-Reject message containing the EAP-Failure message and the value of MAC.
Step 718: After receiving the Access-Accept message sent from U-AAA, WLAN separates the EAP-Success message therein, and sends the EAP-Success message to WLAN MS, informing WLAN MS that the authentication succeeds; if receiving an Access-Reject message, WLAN separates the EAP-Failure message therein, and sends the EAP-Failure message to each WLAN MS, informing WLAN MS that the authentication fails. WLAN MS will first verify the MAC, and confirms that this EAP-request message is correct only when the received MAC is identical with the MAC calculated locally.
It can be seen from the foregoing embodiments that this authentication process is started when a user desires to access a WLAN-3GPP2 inter-working network or the network desires to re-authenticate a WLAN user having passed authentication.

Embodiment 1 is a unique inquiry process and Embodiment 2 is a global authentication process. The two processes are basically the same, except that the types of the random number generated when U-AAA makes authentication of WLAN MS are different and some of the parameters carried in the authentication messages between WLAN MS and U-AAA are different.
Major differences between Embodiment 1 and Embodiment 2 are:
(1) Types of the random numbers generated are different. In the unique inquiry mode,
U-AAA generates RANDU and AUTHU while in the global authentication mode,
U-AAA generates RAND and AUTHR.
(2) In the unique inquiry mode, when U-AAA sends the generated RANDU to WLAN MS, WLAN MS generates AUTHU through the CAVE algorithm with RANDU, A-key, MIN, and ESN as the input parameters while in the global authentication mode, when U-AAA sends the generated RAND to WLAN MS, WLAN MS generates AUTHR through the CAVE algorithm with RAND, A-key, MIN, and ESN as the input parameters.
(3) In the unique inquiry mode, after obtaining AUTHU by calculation, WLAN MS sends this parameter to U-AAA while in the global authentication mode, after obtaining AUTHR by calculation, WLAN MS sends to U-AAA this parameter as well as the parameter RANDC which is derived from RAND.
Embodiment 1 and Embodiment 2 are the same in the following:
(1) After obtaining AUTHU or AUTHR by calculation, WLAN MS sends to
U-AAA a response message, which in either case will contain the ESN and MIN of the
WLAN MS.
(2) After receiving the UIM authentication starting message, EAP-request/UIM/Start, sent from U-AAA, WLAN MS generates internally a random number, AT_NONCE_MT, and sends to U-AAA this random number through the EAP-response/UIM/Start message to be used as the parameter for authentication of the network by a terminal.
(3) After receiving the ATNONCEMT sent from WLAN MS, U-AAA calculates a responding MAC by algorithm, and sends the MAC to WLAN MS through the follow-on EAP-request message. WLAN MS will first verify the MAC, and will only confirm that this EAP-request message is correct when the received MAC is found identical with the MAC calculated locally.

To sum up, the foregoing description is only preferred embodiments of this invention and should not be construed as restrictive to the protection scope thereof.

WE CLAIM:
1. A method for implementing authentication of high-rate packet data services,
comprising the steps of:
A) the authentication entity carrying out authentication of a user terminal having set up a physical connection with the Access Network (AN) by means of the User identity Module (UIM)-based authentication mechanism, and using the user information stored in the UIM of the user terminal itself as the user identifier;
B) the authentication entity, according to said user identifier, acquiring the second random number for authentication of the user terminal and the second authentication number corresponding to the second random number, wherein the second authentication number is calculated by the Shared Secret Data (SSD) of this user terminal stored at the network side;
C) said user terminal obtaining the first authentication number by calculation based on the second random number and the self-stored SSD; the authentication entity comparing the first authentication number with the second authentication number, if yes, the authentication of the user terminal by the authentication entity succeeds, otherwise, the authentication fails.

2. The method according to Claim 1, wherein said authentication entity is a pre-configured authentication server or the authentication center in a wireless mobile communications system.
3. The method according to Claim 2, wherein, if the authentication entity is the

authentication center in a wireless mobile communications system, said second random number is generated from the authentication center (AuC) of the wireless mobile communications system, and said SSD are stored in the Home Location Register (HLR)/AuC at the network side.
4. The method according to Claim 2, wherein, if the authentication entity is a pre-configured authentication server, said second random number is generated from this authentication server, and said SSD is stored in the HLR/AuC at the network side or in this authentication server.
5. The method according to Claim 1, comprises after the authentication fails in step C: the authentication entity notifying the HLR at the network side of the authentication result, and the HLR judging whether this authentication is a first-time authentication, if yes, updating the SSD and then performing step C, otherwise the authentication fails.
6. The method according to Claim 1, comprises step D, updating the SSD after the authentication fails, and then performing step C.
7. The method according to Claim 5 or 6, wherein step D comprises the steps: Dl) HLR generating a Shared Secret Data updating random number (RADNSSD), and calculating the authentication number corresponding to the SSD-updating random number;
D2) the user terminal recalculating its own SSD based on said SSD-updating random number by means of the original SSD-generating algorithm of the system, and

then calculating the authentication number corresponding to the SSD-updating random number based on the re-calculated SSD;
. /D D3) judging by comparison whether the authentication number calculated by tne user terminal and the authentication number calculated in the HLR is consistent, if consistent, updating the SSD at the user terminal side, otherwise SSD-updating fails.
8. The method according to Claim 7, wherein step Dl comprises HLR sending
the (RADNSSD) and the corresponding authentication number to the authentication
entity;
the authentication entity sending to AN an Access-Challenge message which carries the Extensible Authentication Protocol (EAP)-Request/U1M/Update message with RADNSSD;
AN sending the EAP-Request/UIM/Update message to the user terminal.
9. The method according to Claim 8, wherein step D2 comprising:
after receiving the EAP-Request/UIM/Update message sent by AN, the user terminal calculating new SSD using RADNSSD, randomly generating a base-station inquiry random number (RANDBS), calculating a base-station inquiry authentication number (AUTHBS) corresponding to RANDBS based on the new SSD, and then sending RANDBS to AN through the EAP-Response/UIM/Challenge message;
AN sending the EAP-Response/UIM/Challenge message to the authentication entity; the authentication entity acquiring the base-station inquiry random number RANDBS and the corresponding base-station inquiry authentication number AUTHBS through interaction with HLR, wherein said AUTHBS is obtained by calculation based on RANDBS and the self-stored SSD;

the authentication entity sending to AN an Access-Challenge message, which carries the EAP-Request/UIM/Challenge message with the base-station inquiry authentication number AUTHBS; after receiving this message, AN sending the message to the user terminal.
10. The method according to Claim 8, wherein step D3 comprising:
after receiving the EAP-Request/UIM/Challenge message, the user terminal judging by comparison whether the AUTHBS therein and the self-calculated AUTHBS are consistent, if consistent, updating the SSD of the user terminal side, the user terminal succeeding in the authentication of the authentication entity and sending an EAP-Response/UIM/success message to AN;
after receiving this message, AN sending to the authentication entity the EAP-Response/UIM/success message, which carries the attributes of relevant RADIUS; after receiving this message, the authentication entity updating the SSD of the user.
11. The method according to Claim 7, wherein said own SSD in step D2 is
calculated based on said SSD-updating random number, Electronic Serial Number
(ESN), and A-key.
12. The method according to Claim 1, wherein step A comprising the steps:
Al) AN sending an authentication request to the user terminal;
A2) after receiving this authentication request, the user terminal reading out the user information stored in the UIM, taking this user information as its own user identifier, and then sending said user identifier to the authentication entity via AN.

13. The method according to Claim 12, wherein, when the authentication
request is sent through EAP, sending the authentication request to the user terminal by
AN is implemented through an EAP-Request/Identity message; and
Step A2 comprises:
said user terminal sending the user identifier to AN through an EAP-Response/Identity message;
after receiving this message, AN sending the message to U-AAA through an Access-Request message, initiating an authentication request to U-AAA.
14. The method according to Claim 1, wherein step B comprises:
U-AAA sending the acquired second random number for authentication of the I.' user terminal to the user terminal via AN.
15. The method according to Claim 14, wherein the step of sending the second
random number to the user terminal via AN comprises:
the authentication entity encapsulating said second random number in the EAP-Request/UIM/Challenge message, and then sending this message to AN through an Access-Challenge message;
after receiving the Access-Challenge message sent from the authentication entity, AN separating the EAP-Request/UIM/Challenge message from the Access-Challenge message, and sending the separated message to the user terminal.
16. The method according to Claim 1, wherein step C comprises:
after obtaining the first authentication number by calculation, the user terminal sending the first authentication number to the authentication entity via AN.

17. The method according to Claim 16, wherein the step of the user terminal
sending the first authentication number to the authentication entity via AN comprises:
the user terminal sending the first authentication number to AN through an EAP-Response/UIM/Challenge message;
AN encapsulating the received EAP-Response/UIM/Challenge message in the Access-Request message, and sending the Access-Request message that completes the encapsulation to the authentication entity.
18. The method according to Claim 1, comprising while performing step C:
the authentication entity notifying the user terminal via AN that the
authentication succeeds/fails.
19. The method according to Claim 1, wherein said AN comprises WLAN.

Documents:

3406-chenp-2005 abstract-duplicate.pdf

3406-chenp-2005 abstract.jpg

3406-chenp-2005 abstract.pdf

3406-chenp-2005 claims-duplicate.pdf

3406-chenp-2005 claims.pdf

3406-chenp-2005 correspondence-others.pdf

3406-chenp-2005 correspondence-po.pdf

3406-chenp-2005 description (complete)-duplicate.pdf

3406-chenp-2005 description (complete).pdf

3406-chenp-2005 drawings-duplicate.pdf

3406-chenp-2005 drawings.pdf

3406-chenp-2005 form-1.pdf

3406-chenp-2005 form-18.pdf

3406-chenp-2005 form-26.pdf

3406-chenp-2005 form-3.pdf

3406-chenp-2005 form-5.pdf

3406-chenp-2005 pct search report.pdf

3406-chenp-2005 pct.pdf

3406-chenp-2005 petition.pdf

« Previous Patent

Next Patent »

Patent Number

227199

Indian Patent Application Number

3406/CHENP/2005

PG Journal Number

07/2009

Publication Date

13-Feb-2009

Grant Date

05-Jan-2009

Date of Filing

14-Dec-2005

Name of Patentee

HUAWEI TECHNOLOGIES CO., LTD

Applicant Address

Huawei Administration Building, Bantian, Longgang District, Shenzhen, 518129,

Inventors:

#	Inventor's Name	Inventor's Address
1	ZHUO, LI	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,
2	GUO, Shikui	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,
3	SHAO, Yang	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,
4	GAO, Jianghai	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,
5	CHEN, Dianfu	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,
6	LI, Zhiming	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,
7	WU, Weidong	Huawei Administration Building, Bantian, Longgang District, Shenzhen, Guangdong 518129,

PCT International Classification Number

H04L 9/32

PCT International Application Number

PCT/CN04/00495

PCT International Filing date

2004-05-17

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	03131035.4	2003-05-16	China
2	200410007188.9	2004-03-02	China