Device and method of handling security authentication

Abstract

A method for handling a security authentication between a communication device, a source base station (BS), a target BS and a wireless local area network (WLAN) termination (WT) comprises the source BS performing a handover with the target BS and the WT; the source BS transmitting a RRCConnectionReconfiguration to the communication device, after performing the handover; the communication device performing a random access procedure with the target BS, after receiving the RRCConnectionReconfiguration; and the target BS transmitting a confirm message to the WT after performing the random access procedure, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the communication device.

Claims

1. A method for handling a security authentication between a communication device, a source base station (BS), a target BS and a wireless local area network (WLAN) termination (WT), comprising: the source BS performing a handover with the target BS and the WT; the source BS transmitting a RRCConnectionReconfiguration to the communication device, after performing the handover; the communication device performing a random access procedure with the target BS, after receiving the RRCConnectionReconfiguration; and the target BS transmitting a confirm message to the WT after performing the random access procedure, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the communication device.

2. The method of claim 1, wherein the step of the source BS performing the handover with the target BS and the WT comprises: the source BS transmitting a handover request for the communication device to the target BS; the target BS transmitting a WT addition request to the WT, after receiving the handover request; the WT transmitting a WT addition request acknowledgement (ACK) to the target BS in response to the WT addition request; and the target BS transmitting a handover request ACK to the source BS, after receiving the WT addition Request ACK.

3. The method of claim 2, wherein the WT addition request comprises a key S—K.sub.WT.

4. The method of claim 1, wherein the RRCConnectionReconfiguration comprises mobilityControlInfo and a lwa-configuration.

5. The method of claim 4, further comprising: the communication device deriving a key S—K.sub.WT according to a lwa-WT-counter in the lwa-configuration and a key K.sub.eNB.

6. The method of claim 1, further comprising: the communication device transmitting a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure; and the WT performing a 4-way handshake procedure with the communication device, after receiving the confirm message.

7. The method of claim 6, wherein the target BS transmits the confirm message to the WT, after receiving the RRCConnectionReconfigurationComplete.

8. The method of claim 1, further comprising: the communication device transmitting a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure; the WT transmitting a deauthentication or disasociation to the communication device, after receiving the confirm message; and the communication device performing an association procedure with the WT, after receiving the deauthentication or disasociation.

9. The method of claim 8, wherein the target BS transmits the confirm message to the WT, after receiving the RRCConnectionReconfigurationComplete.

10. The method of claim 8, wherein the WT transmits the deauthentication or disasociation with a reason code “Previous authentication no longer valid”.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a schematic diagram of a wireless communication system according to an example of the present invention.

(2) FIG. 2 is a schematic diagram of a communication device according to an example of the present invention.

(3) FIG. 3 is a flowchart of a process according to an example of the present invention.

(4) FIG. 4 is a schematic diagram of a notification procedure of a handover result according to an example of the present invention.

(5) FIG. 5 is a schematic diagram of a notification procedure of a handover result according to an example of the present invention.

(6) FIG. 6 is a schematic diagram of a notification procedure of a handover result according to an example of the present invention.

(7) FIG. 7 is a schematic diagram of a notification procedure of a handover result according to an example of the present invention.

DETAILED DESCRIPTION

(8) FIG. 1 is a schematic diagram of a wireless communication system 10 according to an example of the present invention. The wireless communication system 10 is composed of a communication device 100, base stations (BSs) 102 and 104, and a wireless local area network (WLAN) termination (WT) 106. In FIG. 1, the communication device 100, the BSs 102 and 104 and the WT 106 and are utilized for illustrating the structure of the wireless communication system 10. Practically, each of the BSs 102 and 104 may be an evolved NB (eNB) or a fifth generation (5G) (or called new radio (NR)) BS. The 5G (or NR) BS supports orthogonal frequency-division multiplexing (OFDM) and/or non-OFDM, a transmission time interval (TTI) shorter than 1 ms (e.g., 100 or 200 microseconds) and a wider system bandwidth (e.g., 200 MHz). In FIG. 1, coverage areas of the BS 102 and the BS 104 may be overlapped or non-overlapped. In general, a BS may also be used to refer any of the eNB and the 5G BS. The WT 106 may be an access point (AP) conforming to IEEE 802.1x standards.

(9) When a LTE-WLAN Aggregation (LWA) is operated, an eNB-assisted authentication can be used for helping the WT 106 and the communication device 100 to perform a WLAN 4-way handshake authentication by using a key derived by both a BS (e.g., the BS 102) and the communication device 100 as a Pairwise Master Key (PMK). Since the PMK may need to be updated when a handover happens, the communication device 100 may need to perform an association procedure which is time-consuming with the WT 106. If the WT 106 is able to know a timing of a successful handover as well as a key updating timing at the communication device 100, the WT 106 may directly proceed to perform a 4-way handshake which can maintain the current association with an updating Pairwise Transient Key (PTK) for a following encryption on a WLAN.

(10) The eNB-assisted authentication is defined to avoid an Extensible Authentication Protocol (EAP)/Authentication and Key Agreement (AKA) 802.1X based authentication which is usually time-consuming. A BS (e.g., the BS 102) derives a key S—K.sub.WT from its key K.sub.eNB, and transmits the key S—K.sub.WT to the WT 106 to be used as a PMK for a later 4-way handshake authentication for a WLAN connection of the communication device 100. The communication device 100 is configured by the BS according to a configured WT counter received in a RRCConnectionReconfiguration to derive the same key S—K.sub.WT as PMK.

(11) When a handover such as an intra-eNB handover or an inter-eNB handover happens, the K.sub.eNB is changed. The corresponding S—K.sub.WT needs to be updated as well. Considering a case where the WT 106 is not changed after the handover, the WT 106 gets a new configuration from a target BS (e.g., the BS 104) in a WT Addition Request and applies it if accepting it. Then, the WT 106 transmits a WT Addition Request Acknowledgement (ACK) to the target BS in response to the WT Addition Request. The WT 106 gets an updated S—K.sub.WT in the new configuration. However, the WT 106 does not know whether its peer (i.e., the communication device 100) also possess the same (updated) key S—K.sub.WT now. If the WT 106 triggers a 4-way handshake immediately, it may cause a failed 4-way handshake, and leads to a de-authentication. Accordingly, the UE needs to perform a full procedure of authentication and association. Therefore, this blind triggering of the 4-way handshake is not efficient, and causes a longer suspension time for a data transmission on the WLAN.

(12) The communication device 100 may be a user equipment (UE), a mobile phone, a laptop, a tablet computer, an electronic book, a portable computer system, a vehicle, or an airplane. For uplink (UL), the communication device 100 is the transmitter and the BS 102, the BS 104 and/or the WT 106 is the receiver, and for downlink (DL), the BS 102, the BS 104 and/or the WT 106 is the transmitter and the communication device 100 is the receiver.

(13) FIG. 2 is a schematic diagram of a communication device 20 according to an example of the present invention. The communication device 20 may be the communication device 100, the BS 102, the BS 104 and/or the WT 106 shown in FIG. 1, but is not limited herein. The communication device 20 includes a processing circuit 200 such as a microprocessor or Application Specific Integrated Circuit, a storage device 210 and a communication interfacing unit 220. The storage device 210 may be any data storage device that stores a program code 214, accessed and executed by the processing circuit 200. Examples of the storage device 210 include but are not limited to read-only memory, flash memory, random-access memory, hard disk, optical data storage device, non-volatile storage device, non-transitory computer-readable medium (e.g., tangible media), etc. The communication interfacing unit 220 is preferably a transceiver used to transmit and receive signals (e.g., data, signals, messages and/or packets) according to processing results of the processing circuit 200.

(14) FIG. 3 is a flowchart of a process 30 according to an example of the present invention. The process 30 may be used for handling a security authentication between a UE (e.g., the communication device 100), a source BS (e.g., the BS 102), a target BS (e.g., the BS 104) and a WT (e.g., the WT 106). The process 30 includes the following steps:

(15) Step 300: Start.

(16) Step 302: The source BS performs a handover with the target BS and the WT.

(17) Step 304: The source BS transmits a RRCConnectionReconfiguration to the UE, after performing the handover.

(18) Step 306: The UE performs a random access procedure with the target BS, after receiving the RRCConnectionReconfiguration.

(19) Step 308: The target BS transmits a confirm message to the WT after performing the random access procedure, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the UE.

(20) Step 310: End.

(21) According to the process 30, the source BS performs a handover with the target BS and the WT, and transmits a RRCConnectionReconfiguration to the UE after performing the handover. The UE performs a random access procedure with the target BS, after receiving the RRCConnectionReconfiguration. Accordingly, the target BS transmits a confirm message to the WT after performing the random access procedure, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the UE. That is, the target BS notifies the WT (e.g., via an interface Xw) about a completion of the handover, such that the WT knows that the UE also have the an updated PMK (S—K.sub.WT). Thus, the WT can proceed to use the updated PMK (S—K.sub.WT) to perform a 4-way handshake to generate the PTK for a following encryption on a data transmission between the UE and the WT. This successful 4-way handshake can stop a target eNB transmitting another RRCConnectionReconfiguration message to prevent the UE from triggering a timing-consuming authentication and association procedures with the same WT.

(22) Realization of the process 30 is not limited to the above description. An example of the channel access procedure is described as follows.

(23) In one example, the source BS performs the handover with the target BS and the WT according to the following steps. The source BS transmits a handover request for the UE to the target BS. The target BS transmits a WT addition request (e.g., including a key S—K.sub.WT) to the WT, after receiving the handover request. The WT accepts the key S—K.sub.WT, and transmits a WT addition request ACK to the target BS in response to the WT addition request. The target BS transmits a handover request ACK to the source BS, after receiving the WT addition Request ACK.

(24) In one example, the RRCConnectionReconfiguration includes mobilityControlInfo and a lwa-configuration. Thus, the UE may derive a key S—K.sub.WT according to a lwa-WT-counter in the lwa-configuration and a key K.sub.eNB. The key S—K.sub.WT derived by the UE may be the same as the key S—K.sub.WT received by the WT from the target eNB.

(25) In one example, the UE transmits a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure. Then, the WT performs a 4-way handshake procedure with the UE, after receiving the confirm message. In one example, the target BS transmits the confirm message to the WT, after receiving the RRCConnectionReconfigurationComplete.

(26) In one example, the UE transmits a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure. The WT transmits a deauthentication or disasociation to the UE, after receiving the confirm message. Then, the UE performs an association procedure with the WT, after receiving the deauthentication or disasociation. In one example, the target BS transmits the confirm message to the WT, after receiving the RRCConnectionReconfigurationComplete. In one example, the WT transmits the deauthentication or disasociation with a reason code “Previous authentication no longer valid”.

(27) FIG. 4 is a schematic diagram of a notification procedure of a handover result according to an example of the present invention. Operations of a UE (e.g., the communication device 100), a source BS (e.g., the BS 102), a target BS (e.g., the BS 104) and a WT (e.g., the WT 106) in FIG. 4 are described as follows. It should be noted that the WT may or may not be configured to the UE by the source BS. The source BS performs a handover with the target BS and the WT (Step 400). Detailed operation of the handover can be referred to the previous description, and is not narrated herein. The source BS transmits a RRCConnectionReconfiguration to the UE after performing the handover (Step 402). The UE performs a random access procedure with the target BS after receiving the RRCConnectionReconfiguration (Step 404). Accordingly, the target BS transmits a confirm message to the WT after performing the random access procedure, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the UE (Step 406). Thus, the UE and the WT have the same key S—K.sub.WT now. In addition, the UE transmits a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure (Step 408). More specifically, the transmission of the RRCConnectionReconfigurationComplete occurs after the transmission of the confirm message. The WT performs a 4-way handshake procedure with the UE, after receiving the confirm message (Step 410). Then, the UE and the WT have a same PTK to encrypt following data transmissions on a WLAN, after performing the 4-way handshake procedure.

(28) FIG. 5 is a schematic diagram of a notification procedure 50 of a handover result according to an example of the present invention. Operations of a UE (e.g., the communication device 100), a source BS (e.g., the BS 102), a target BS (e.g., the BS 104) and a WT (e.g., the WT 106) in FIG. 5 are described as follows. It should be noted that the WT may or may not be configured to the UE by the source BS. The source BS performs a handover with the target BS and the WT (Step 500). Detailed operation of the handover can be referred to the previous description, and is not narrated herein. The source BS transmits a RRCConnectionReconfiguration to the UE after performing the handover (Step 502). The UE performs a random access procedure with the target BS after receiving the RRCConnectionReconfiguration (Step 504). Accordingly, the UE transmits a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure (Step 506). In addition, the target BS transmits a confirm message to the WT after receiving the RRCConnectionReconfigurationComplete, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the UE (Step 508). Thus, the UE and the WT have the same key S—K.sub.WT now. More specifically, the transmission of the RRCConnectionReconfigurationComplete occurs before the transmission of the confirm message. The WT performs a 4-way handshake procedure with the UE, after receiving the confirm message (Step 510). Then, the UE and the WT have a same PTK to encrypt following data transmissions on a WLAN, after performing the 4-way handshake procedure.

(29) FIG. 6 is a schematic diagram of a notification procedure 60 of a handover result according to an example of the present invention. Operations of a UE (e.g., the communication device 100), a source BS (e.g., the BS 102), a target BS (e.g., the BS 104) and a WT (e.g., the WT 106) in FIG. 6 are described as follows. It should be noted that the WT may or may not be configured to the UE by the source BS. The source BS performs a handover with the target BS and the WT (Step 600). Detailed operation of the handover can be referred to the previous description, and is not narrated herein. The source BS transmits a RRCConnectionReconfiguration to the UE after performing the handover (Step 602). The UE performs a random access procedure with the target BS after receiving the RRCConnectionReconfiguration (Step 604). Accordingly, the target BS transmits a confirm message to the WT after performing the random access procedure, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the UE (Step 606). Thus, the UE and the WT have the same key S—K.sub.WT now. In addition, the UE transmits a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure (Step 608). More specifically, the transmission of the RRCConnectionReconfigurationComplete occurs after the transmission of the confirm message. The WT transmits a message which can be a deauthentication or disasociation with a reason code such as “Previous authentication no longer valid” to the UE (Step 610). Then, the UE starts an association procedure (e.g., an open-system authentication and association process) with the WT (Step 612). Thus, the WT can perform a 4-way handshake procedure with the UE, and the UE and the WT have a same PTK to encrypt following data transmissions on a WLAN.

(30) FIG. 7 is a schematic diagram of a notification procedure 70 of a handover result according to an example of the present invention. Operations of a UE (e.g., the communication device 100), a source BS (e.g., the BS 102), a target BS (e.g., the BS 104) and a WT (e.g., the WT 106) in FIG. 7 are described as follows. It should be noted that the WT may or may not be configured to the UE by the source BS. The source BS performs a handover with the target BS and the WT (Step 700). Detailed operation of the handover can be referred to the previous description, and is not narrated herein. The source BS transmits a RRCConnectionReconfiguration to the UE after performing the handover (Step 702). The UE performs a random access procedure with the target BS after receiving the RRCConnectionReconfiguration (Step 704). Accordingly, the UE transmits a RRCConnectionReconfigurationComplete to the target BS, after performing the random access procedure (Step 706). In addition, the target BS transmits a confirm message to the WT after receiving the RRCConnectionReconfigurationComplete, wherein the confirm message indicates that the RRCConnectionReconfiguration is received by the UE (Step 708). Thus, the UE and the WT have the same key S—K.sub.WT now. More specifically, the transmission of the RRCConnectionReconfigurationComplete occurs before the transmission of the confirm message. The WT transmits a message which can be a deauthentication or disasociation with a reason code such as “Previous authentication no longer valid” to the UE (Step 710). Then, the UE starts an association procedure (e.g., an open-system authentication and association process) with the WT (Step 712). Thus, the WT can perform a 4-way handshake procedure with the UE, and the UE and the WT have a same PTK to encrypt following data transmissions on a WLAN.

(31) Those skilled in the art should readily make combinations, modifications and/or alterations on the abovementioned description and examples. The abovementioned description, steps and/or processes including suggested steps can be realized by means that could be hardware, software, firmware (known as a combination of a hardware device and computer instructions and data that reside as read-only software on the hardware device), an electronic system, or combination thereof. An example of the means may be the communication device 20. Any of the above processes and examples above may be compiled into the program code 214.

(32) To sum up, the present invention provides a method and a communication device for handling a security authentication. One or more RRCConnectionReconfigurations from a target BS can be avoided to prevent the communication device from triggering a lengthy full authentication and association procedure with a WT. Thus, a longer suspension time for a data transmission caused by the authentication and association procedure is solved.

(33) Those skilled in the art will readily observe that numerous modifications and alterations of the device and method may be made while retaining the teachings of the invention. Accordingly, the above disclosure should be construed as limited only by the metes and bounds of the appended claims.