JP5384723B2 - Emergency call processing by authentication procedure in communication network - Google Patents

Description

  This application claims priority to the US provisional patent application filed on April 16, 2009, identified in 61 / 169,929, the disclosure of which is incorporated herein by reference in its entirety.

  The present invention relates generally to communication networks, and more particularly to a communication network in which emergency call processing is performed when an emergency call affects an authentication procedure.

  This section introduces aspects that can help promote a deeper understanding of the present invention. Accordingly, the language in this section should be read from this perspective and should not be understood as an acknowledgment of what is prior art or what is not prior art.

  For example, according to ITU-T (International Telecommunication Union-Telecommunication Standardization Sector), next generation network (NGN) can provide services including telecommunications services, and broadband that can control quality of service (QoS). A packet-based network that can make use of various transfer technologies, and service-related functions are independent of the underlying transfer-related technologies. NGN can allow users to freely access various service providers. In addition, general-purpose mobility can be supported, and the general-purpose mobility can provide a consistent and ubiquitous service to users.

  LTE (Long Term Evolution) is an improvement in the UMTS (Universal Mobile Telecommunications System) mobile phone standard in line with efforts to develop NGN, improved user experience and simplified technology for next generation mobile broadband 3GPP (Third Generation Partnership Project) for the purpose of providing The LTE radio access technology is called E-UTRAN (Evolved UMTS Terrestrial Radio Access Network), and the network is called EPS (Evolved Packet System). The architecture of the EPS network is described in 3GPP technical specifications 23.401 and 23.402, the disclosure of which is incorporated herein by reference in its entirety.

3GPP Technical Specification TS 23.401 3GPP Technical Specification TS 23.402 3GPP Technical Specification TS31.102 3GPP Technical Specification TS31.103 3GPP Technical Specification TS33.102 3GPP Technical Specification TS23.122

  Embodiments of the present invention provide a technique for processing an emergency call when the emergency call affects an authentication procedure in a communication network.

  In a first aspect in which it is assumed in the communication network that the first computing device comprises a user equipment and the second computing device comprises an authentication function, the method includes the following steps.

  At the second computing device, a first type of call indicator message from the first computing device is received. Based on this first type of call indicator message, a decision is made to continue or abort the authentication procedure for the first computing device at the second computing device. The second computing device may be able to place a first type of call for the first computing device. The first type of call can be an emergency call.

  In one or more exemplary embodiments, the authentication procedure includes transmitting an authentication request from the second computing device to the first computing device by a first authentication attempt; and the second computing device. Receiving an authentication failure message sent by the first computing device in response to the authentication request sent by the second computing device from the first computing device; and the second computing device And initiating a second authentication attempt in response to the authentication failure message, wherein the second authentication attempt is canceled in response to the first type call indicator message at the second computing device. To be. The second authentication attempt can include a resynchronization procedure.

  The communication network may include an EPS (Evolved Packet System) architecture, the first computing device comprises a mobile device (ME) and a USIM (UMTS Subscriber Identity Module), and the second user device is an MME (Mobility). Management Entity). The authentication procedure may include an AKA (Authentication and Key Agreement) protocol.

  Advantageously, exemplary embodiments of the present invention provide improved performance of packet-based emergency call setup in LTE environments.

  These and other features and advantages of the present invention will become more apparent from the accompanying drawings and the following detailed description.

1 is a mobile roaming architecture diagram according to an embodiment of the present invention; FIG. FIG. 4 is a diagram of an authentication procedure according to an embodiment of the present invention. FIG. 4 is a diagram of a resynchronization procedure according to an embodiment of the invention. It is a figure of the emergency call processing procedure by one Embodiment of this invention. FIG. 2 is a hardware architecture diagram of a communication network suitable for implementing authentication and emergency call services according to an embodiment of the present invention.

  One embodiment of an LTE (or EPS) roaming architecture 100 is shown in FIG. As illustrated, the architecture 100 includes an HPLMN (Home Public Land Mobile Network) 110 and a VPLMN (Visible Public Land Mobile Network) 120.

  In the HPLMN 110, an HSS (Home Subscriber Server) 112, a PDN (Packet Data Network) gateway server 114, a PCRF (Policy And Charging Rules Function) server 116, and a network operator's Internet Protocol (IP) service 118 are illustrated. ing. These IP services may include, but are not limited to, IMS (IP Multimedia Subsystem), packet switching system (PSS), and the like. As used herein, a “network operator” (or “telecommunications operator”) is defined as an enterprise that owns and operates a telecommunications network and thus provides services (IMS, PSS, etc.) to subscribers. Can do. For example, an NGN operator is a network operator that owns and operates an NGN network. Thus, two features that define a network operator can be (1) owning the network and (2) providing services to and charging the subscriber. The third feature is that the network operator is typically regulated, thereby allowing the network operator to be held legally responsible for ensuring communication secrets and the like. Examples of network operators can illustratively include AT & T or Verizon.

  In VPLMN 120, GSM (R) Edge Radio Access Network, (GERAN, where GSM refers to Global System for Mobile communications) and UTRAN (UMTS Terrestrial Radio), etc. Support Node) 122 (SGSN, where GPRS refers to General Packet Radio Service) is illustratively shown. Also shown is a Mobility Management Entity (MME) 124, a serving gateway 126, an E-UTRAN (Evolved UTRAN network) 128, and a user equipment 130.

  The serving gateway 126 is a local mobility anchor for E-UTRAN mobility, and exchanges packets between mobile interfaces in connected mode. When the mobile is in idle mode, the serving gateway 126 is responsible for terminating the downlink data path and buffering the data by forwarding the MME 124 signal and triggering the paging procedure when downlink data is received. Fulfill.

  The MME 124 is a control plane function for E-UTRAN access. The MME 124 is responsible for mobile device authentication and critical management, as well as idle mode mobile tracking and paging procedures.

  The UE 130 (or mobile station (MS)) includes a mobile device (ME) and a UMTS Subscriber Identity Module (USIM). Examples of mobile stations or user equipment may include, but are not limited to, mobile phones, portable computers, wireless electronic mail devices, personal digital assistants (PDAs), or some other user mobile communication device.

  The E-UTRAN 128 includes an access node including at least one eNB (eNodeB) node, and the eNB (eNodeB) node functions as a base station for the UE to access the VPLMN network.

  In one embodiment, as described in detail below, UE 130 (ME + USIM), eNodeB (E-UTRAN 128), MME 124, and HSS 112 are network elements that are affected by the exemplary principles of the present invention.

  Thus, it should be understood that the UE (User Equipment) is ME (Mobile Equipment) + USIM. USIM is a software and file system on a physical device UICC (Universal Integrated Circuit Card, commonly known as a “SIM card” of a mobile phone). UICC is an unauthorized use prevention smart card. USIM terminates AKA (Authentication and Key Agreement), an authentication and key agreement protocol (cited below) standardized by 3GPP. UMTS and EPS use similar versions of AKA.

The following shows how a successful AKA procedure typically works:
1. During the first attach, the UE sends an attach request with International Mobile Subscriber Identity (IMSI) inside it to the eNodeB (part of the cell site, E-UTRAN).
2. The eNodeB forwards the attach request to the MME, which looks at the IMSI routing label and knows where the UE's home system with the HSS is.
3. The MME forwards the request message with the IMSI internally to its HSS.
4). The HSS performs a calculation: select a random number RAND, use RAND and share it with the USIM root key K to calculate the authentication token AUTN, XRES (expected response), and another root key K _ASME .
5. The HSS then responds to the MME with AKA AV (authentication vector). EPS AV has the following parameters: RAND, AUTN, XRES, and K _ASME .
6). When the MME receives the EPS AV, it holds the XRES and K _ASME and forwards the RAND and AUTN to the USIM via the eNodeB and ME.
7). The first thing the USIM does is to authenticate the AUTN, and only after successful authentication, the USIM calculates the RES and its own K _ASME .
8). The USIM then sends a root key K _ASME to the ME to get another EPS key, and sends a RES to the MME via the ME and eNodeB.

  The MME compares the RES (received from the USIM) with the XRES (received from the HSS). If they are equal to each other, USIM (and USIM + ME = UE) are accepted by the serving network.

  Thus, in one embodiment, it is assumed that the UE supports an application protocol that recognizes the Authentication and Key Agreement (AKA) algorithm. Moreover, in this exemplary embodiment, it is assumed that the UE supports a UMTS Subscriber Identity Module (USIM) application that implements the AKA algorithm. Details regarding USIM applications can be found in 3GPP technical specifications TS 31.102 and TS 31.103, the disclosures of which are incorporated herein by reference in their entirety. Details regarding AKA can be found in 3GPP technical specification TS 33.102, the disclosure of which is incorporated herein by reference in its entirety.

  Although this particular embodiment utilizes aspects of the 3GPP authentication protocol, it should be understood that such a protocol is an example of a security protocol that can be used. Accordingly, other suitable security protocols that provide similar functionality and features as the 3GPP authentication protocol can be considered within the scope of embodiments of the present invention.

  The E-UTRAN initial attach procedure is used for Emergency Attach by UEs that need to perform emergency services but cannot use normal services from the network. These UEs are limited service mode or LSM as defined in 3GPP Technical Specification TS 23.122 ("Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode"). The disclosure of which is incorporated herein by reference in its entirety.

  A UE that can normally attach to a cell, i.e. a UE that is not in a restricted service state, initiates a normal start attach if not already attached.

FIG. 2 shows an exemplary authentication and key establishment procedure 200, such as an AKA (Authentication and Key Agreement) procedure or protocol. The purpose of the AKA procedure is to authenticate the user and establish a new root key K _ASME between the MME and the USIM. During authentication, the USIM verifies the newness of the used authentication vector.

  It is understood that messages transmitted between entities shown in FIG. 2 (and FIGS. 3 and 4 described below) are signals transmitted and received according to one or more communication protocols implemented by the entity. I want to be. A series of message transfers can also be reconfigured or modified (by adding some additional messages and / or deleting some messages) to provide one or more of the benefits resulting from the principles of the present invention. I want you to understand.

  The MME invokes the procedure by selecting an authentication vector (AV). The MME 124 transmits to the USIM (UE 130) a random challenge RAND and an authentication token for the network authentication AUTN from the authentication vector. This is shown in step 1 of FIG.

  In step 2 of FIG. 2, the USIM returns a response to the random challenge to the MME in the form of an authentication response RES. If this response is appropriate, authentication continues as usual (ie, as described above).

  However, in the case of synchronization failure, the UE 130 transmits a synchronization failure message (step 3 user authentication rejection CAUSE message in FIG. 2) to the MME 124 instead of an appropriate response.

Upon receipt of the synchronization failure message from the UE, the MME sends an authentication data request having a “synchronization failure indication” to the HSS 112 with the following parameters:
The RAND sent to the MS in the preceding user authentication request, and the AUTS as described in TS 33.102 received by the MME in response to the preceding user authentication request.

  This is illustrated in FIG. FIG. 3 shows a procedure 300 for achieving resynchronization by combining a user authentication request that is responded with a synchronization failure message and an authentication data request with a synchronization failure indicator that is responded with an authentication data response.

  As shown, after step 1 (MME sends a challenge) and step 2 (UE sends an AUTS response), in step 3, the MME sends RAND and AUTS to the HSS.

  Note that MME 124 does not respond to an unsolicited “synchronization failure indicator” message from UE 130.

  It should also be noted that the MME 124 does not send a new user authentication request to the user before receiving a response to the authentication data request from the HSS 112 (or before timing out).

を計算することによって、Ｃｏｎｃ（ＳＱＮ_ＭＳ）からＳＱＮ_ＭＳを取得する。ＳＱＮはシーケンス番号を表し、「Ｃｏｎｃ」は連結関数を表すことに留意されたい。
２．ＨＳＳは、ＳＱＮ_ＨＥが適正な範囲にあるかどうか、すなわち生成された次のシーケンス番号ＳＱＮ_ＨＥがＵＳＩＭによって受け入れられるかどうかを確認する。
３．ＳＱＮ_ＨＥが適正な範囲にある場合、ＨＳＳは以下のステップ（６）に進み、そうでない場合は以下のステップ（４）に進む。
４．ＨＳＳがＡＵＴＳを検証する。
５．検証が成功した場合、ＨＳＳはカウンタＳＱＮ_ＨＥの値をＳＱＮ_ＭＳにリセットする。
６．ＨＳＳは、ＭＭＥに、新しいバッチの認証ベクトルを有する認証データ応答を送信する（図３のステップ４のＱ_ｉ）。カウンタＳＱＮ_ＨＥがリセットされなかった場合は、これらの認証ベクトルは記憶領域から得ることができ、そうでない場合は、認証ベクトルはＳＱＮ_ＨＥのリセット後に新たに生成される。ＨＳＳにかかるリアルタイム計算の負担を減少させるために、ＨＳＳは、後者の場合に単一の認証ベクトルのみを送信することもできる。 When the HSS 112 receives an authentication data request with a “synchronization failure indicator” (in step 3 of FIG. 3), it operates as follows:
1. HSS

Obtain SQN _MS from Conc (SQN _MS ) by calculating. Note that SQN represents a sequence number and “Conc” represents a concatenation function.
2. The HSS checks whether the SQN _HE is in the proper range, i.e. whether the generated next sequence number SQN _HE is accepted by the USIM.
3. If the SQN _HE is in the proper range, the HSS proceeds to the following step (6), otherwise proceeds to the following step (4).
4). The HSS verifies the AUTS.
5. If the verification is successful, the HSS resets the value of the counter SQN _HE to the SQN _MS .
6). The HSS sends an authentication data response with a new batch of authentication vectors to the MME (Q _i in step 4 of FIG. 3). If the counter SQN _HE is not reset, these authentication vectors can be obtained from the storage area, otherwise the authentication vectors are newly generated after the SQN _HE is reset. To reduce the real-time computational burden on the HSS, the HSS can also send only a single authentication vector in the latter case.

  Each time the MME 124 receives a new authentication vector from the HSS 112 in an authentication data response to an authentication data request with a synchronization failure indicator, the MME 124 deletes the old authentication vector for that UE 130 of the MME.

  UE 130 can now be authenticated based on the new authentication vector from HSS 112.

  However, problems may occur during the above authentication session. Assume that UE130 needs to make an emergency call (EC) even if AUTN verification on USIM fails for one or more reasons during AKA (re) authentication (user authentication rejected CAUSE in FIG. 2) To do.

Under normal conditions (see eg TS33.102 cited above), UE 130 may request a new AKA authentication upon MAC (Media Access Control) authentication failure or an AUTS procedure (according to its HSS) upon SQN mismatch. Enter Resynchronization. In such a case, the MME 124 does not receive the RES, and the UE 130 does not generate a K _ASME .

  In other words, the UE 130 waits for a new AKA (MAC failure) or a subsequent resynchronization by the HSS and a new AKA. A new AKA round trip can be up to about 10-15 seconds, and resynchronization by the HSS may take about the same amount of time. In the worst case, UE 130 must wait about 30 seconds before it can continue the intended call. The MME 124 cannot control the resynchronization time or estimate the resynchronization time for performing communication to the UE 130 that intends to make an emergency call. It will be appreciated that this functional interaction may be unacceptable and / or may be unnecessary for such emergency calls.

  According to one embodiment, the following solution is provided. FIG. 4 shows a procedure 400 for implementing such a solution.

  Since the ME of the UE 130 (as noted above, the ME is part of the UE 130 but functionally separate from the USIM) knows the intention to make an emergency call, the ME Can be communicated to the MME 124 via an emergency call (EC) indicator.

  As shown in FIG. 4, assume that in step 1 the MME sends a user authentication request to the ME (UE) and in step 2 the ME forwards the request to the USIM (also UE). Further assume that upon receiving an authentication failure from the USIM (step 3), the ME forwards it to the MME (step 4) and stops expecting a new AKA, or resynchronization + new AKA. Instead, the ME proceeds to such a mode assuming an unauthenticated attach mode.

  On the network side, the MME 124 knows the UE's intention to do EC via the EC indicator sent in step 5. Upon receiving an authentication failure from the UE, the MME stops following the normal authentication / resynchronization procedure (outlined above in FIGS. 2 and 3). Instead, the MME proceeds to such a mode assuming an unauthenticated attach mode. The MME allows only the EC to pass.

  Note that since the EC indicator message in the above example is sent after the authentication failure message is received by the MME, the authentication procedure can be advantageously aborted or aborted. Alternatively, the EC indicator message can be received earlier in the same authentication session and before authentication actually begins, in which case the authentication procedure may advantageously not be initiated or completely aborted. Is possible. Thus, it will be appreciated that each time an EC indicator message is received in a session, it may advantageously help the MME make a decision regarding the authentication procedure (eg, abort or continue).

  In any case, after the EC call is terminated, both parties (UE and MME) reset to the normal authentication procedure. It is the presence of the EC indicator that basically controls the behavior of the ME and MME when authentication fails while attempting to create an EC.

  In case of emergency attach, the UE ME sets the attach type to “Emergency” and proceeds to an emergency call that is not authenticated.

  If the MME 124 is configured to support emergency attach and the UE indicates the attach type “Emergency”, the MME skips authentication and security setup, or the MME accepts that authentication may fail and attach Continue with the procedure.

  If the MME 124 is not configured to support emergency attach, the MME rejects any attach request that indicates an attach type “Emergency”.

  Finally, FIG. 5 illustrates a general hardware architecture of a communication network 500 suitable for implementing authentication and emergency call processing services according to the above-described principles of the present invention.

  As shown, user equipment 510 (corresponding to UE 130) and MME server 520 (corresponding to MME 124) are operably coupled via communication network medium 550. The network medium can be any network medium over which user equipment and a web server wish to communicate. By way of example, this network medium can carry IP packets end-to-end and may include any of the aforementioned communication networks. However, the present invention is not limited to a particular type of network medium. Typically, user equipment 510 may be a client machine or device and MME 520 may be a server machine or device. Although not explicitly shown herein, other network elements shown in FIG. 1 (which may have the same processor / memory configuration described below) operate on the MME and / or UE. It will be understood that they can be combined.

  As will be readily apparent to those skilled in the art, the server and client may be implemented as a programmed computer operating under the control of computer program code. The computer program code is stored in a computer (or processor) readable storage medium (eg, memory) and the code is executed by the processor of the computer. In view of this disclosure of the present invention, one of ordinary skill in the art can readily generate suitable computer program code to implement the protocols described herein.

  Nevertheless, FIG. 5 generally shows an exemplary architecture of each device communicating over a network medium. As shown, the user equipment 510 includes an I / O device 512, a processor 514, and a memory 516. The MME server 520 includes an I / O device 522, a processor 524, and a memory 526.

  As used herein, the term “processor” includes, but is not limited to, one or more processing devices including a central processing unit (CPU), or one or more signal processors, one or more integrated circuits, and the like. It should be understood that it is intended to include other processing circuits that are not. Similarly, the term “memory” as used herein relates to a processor or CPU, such as RAM, ROM, fixed memory device (eg, hard drive), or removable memory device (eg, diskette or CDROM). Intended to contain memory. Further, as used herein, the term “I / O device” provides one or more input devices (eg, keyboard, mouse) for entering data into the processing unit, as well as results associated with the processing unit. Intended to include one or more output devices (eg, a CRT display).

  Accordingly, software instructions or code for performing the methods of the invention described herein are stored in one or more associated memory devices, such as ROM, fixed memory, or removable memory, When ready to use, it can be loaded into RAM and executed by the CPU. That is, each computing device (510 and 520) shown in FIG. 5 can be individually programmed to implement the respective steps of the protocol shown in FIGS.

  Although exemplary embodiments of the present invention have been described herein with reference to the accompanying drawings, the present invention is not limited to those precise embodiments and without departing from the scope or spirit of the invention. It should be understood that various other changes and modifications can be made by those skilled in the art.

Claims (10)

In a communication network, wherein a first computing device comprises user equipment and a second computing device comprises an authentication function for authenticating the user equipment.
Receiving an authentication denial message from the first computing device at a second computing device;
Receiving, at a second computing device, a first type of call indicator message from the first computing device;
Determining whether to continue or abort the authentication procedure for the first computing device at the second computing device based on receipt of the authentication rejection message and the first type call indicator message. ,Method. The method of claim 1, further comprising enabling a second computing device to place a first type of call for the first computing device if a decision is made to abort the authentication procedure. the method of. The authentication procedure is
Sending an authentication request from the second computing device to the first computing device on a first authentication attempt;
Receiving an authentication failure message sent by the first computing device in response to the authentication request sent by the second computing device from the first computing device at the second computing device;
In a second computing device, after receiving an authentication failure message, initiating a second authentication attempt ;
2. The method of claim 1, comprising: if a first type of call indicator message is received following the initiating step , aborting the second authentication attempt at the second computing device.   The method of claim 3, wherein the second authentication attempt includes a resynchronization procedure.   The method of claim 1, wherein the first type of call is an emergency call. In a communication network, wherein the first computing device comprises user equipment and the second computing device comprises an authentication function for authenticating the user equipment, the second computing device comprises:
Memory,
Coupled to the memory, receiving an authentication reject message from the first computing device , receiving a first type of call indicator message from the first computing device, and receiving the authentication reject message and the first type of call indicator message And a processor configured to make a determination as to whether to proceed or abort the authentication procedure for the first computing device based on the reception of the first computing device.   The apparatus of claim 6, wherein the processor is further configured to allow a first type of call to be placed for the first computing device.   The apparatus of claim 6, wherein the first type of call is an emergency call. In a communication network, wherein a first computing device comprises user equipment and a second computing device comprises an authentication function for authenticating the user equipment.
Sending an authentication reject message from the first computing device to the second computing device;
Sending a first type of call indicator message from a first computing device to a second computing device;
Based on the receipt of the authentication reject message and the first type call indicator message, the second computing device determines whether to continue or abort the authentication procedure for the first computing device. Initiating a call of the first call type with one computing device.   The method of claim 9, wherein the first type of call is an emergency call.

Images