A communication method, apparatus and device

Abstract

This application discloses a communication method, apparatus, and device. The solution includes: after a system handover, when a connected terminal device, having failed its initial registration process with the target communication system and subsequently releasing its wireless link, re-initiates the registration process upon entering an idle state, it sends a registration request message to the target communication system, employing the security context corresponding to the source communication system for integrity protection. Upon receiving this registration request message, the target communication system can successfully obtain the terminal device's context from the source communication system, thereby enabling the terminal device to successfully register with the target communication system. In summary, this solution avoids situations where the terminal device's re-initiated registration process is rejected, improves the registration success rate of terminal devices in system handover scenarios, reduces registration latency, and ultimately ensures service continuity and user experience for the terminal device.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, apparatus and device. Background Technology

[0002] When a terminal device resides in a communication system, both the non-access stratum (NAS) of the terminal device and the NAS of the core network within the communication system maintain a security context.

[0003] In scenarios where terminal devices need to switch from a first communication system to a second communication system, the terminal device and the core network need to map the first security context in the first communication system to generate a second security context in the second communication system. After the switchover is completed, all NAS messages exchanged between the terminal device and the core network in the second communication system need to be protected for integrity and / or confidentiality using this second security context. The first and second communication systems are different standards, for example, the first communication system is a 5G communication system and the second communication system is a 4G communication system.

[0004] Currently, terminal devices need to initiate a Tracking Area Update (TAU) procedure when switching to the second communication system. However, if a terminal device in the RRC connected state fails to complete the TAU procedure when switching to the second communication system, it enters the RRC idle state. When it attempts to initiate the TAU procedure again, it will be rejected by the core network of the second communication system, causing the terminal device to fail to register with the second communication system.

[0005] Clearly, the current solution results in a low registration success rate for terminal devices, leading to longer network access times and service interruptions, which negatively impacts user experience. Summary of the Invention

[0006] This application provides a communication method, apparatus, and device to improve the registration success rate of terminal devices in cross-system switching scenarios.

[0007] In a first aspect, embodiments of this application provide a communication method, which includes the following steps:

[0008] After switching from the second communication system to the first communication system, the terminal device acquires a first set of security contexts. These first security contexts are used for security authentication between the terminal device and a first network device located in the first communication system. After the terminal device sends a first registration request message to a first core network device, the terminal device releases the wireless link. The first registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device. The terminal device then sends a second registration request message to the first core network device. The second registration request message uses a second set of security contexts for integrity protection, and these second security contexts are used for security authentication between the terminal device and a second network device located in the second communication system.

[0009] In traditional solutions, during inter-system handover scenarios, if the initial registration process fails and the idle terminal device re-initiates the registration process, it continues to use the first security context to protect the integrity of the registration request message. However, the second core network device can only use the second security context for integrity verification, thus the terminal device's second registration process will inevitably fail. In contrast to this traditional solution, this method uses the second security context to protect the integrity of the registration request message when the terminal device re-initiates the registration process. This ensures that when the first core network requests the terminal device's context from the second core network device based on the registration request message, the second core network device can successfully verify the integrity of the registration request message. This guarantees that the first core network device can successfully obtain the terminal device's context from the second core network device, thereby ensuring that the terminal device can successfully register with the first communication system. Clearly, compared to the traditional solution, this method avoids the situation where the terminal device's re-initiated registration process is rejected, improves the registration success rate of terminal devices in inter-system handover scenarios, reduces the latency of successful registration with the first communication system, and ultimately ensures the service continuity of the terminal device and guarantees user experience.

[0010] In one possible design, the terminal device can obtain the first set of security contexts through the following steps:

[0011] The terminal device calculates the second set of security contexts according to the set security context mapping algorithm to generate the first set of security contexts.

[0012] Through this design, the terminal device can obtain the first set of security contexts corresponding to the first communication system during the inter-system handover process.

[0013] In one possible design, when the terminal device receives a registration rejection response message from the first core network device, the terminal device may release the radio link.

[0014] With this design, the terminal device can release the wireless link when it receives a registration rejection response message, thereby initiating the registration process again and continuing to request registration with the first communication system.

[0015] In one possible design, the registration rejection response message includes a rejection reason indication, which instructs the terminal device to maintain the registration state. For example, the rejection reason indication can be other rejection reason values ​​besides the following: #3, #6, #8, #7, #9, #10, #11, #35, #12, #13, #14, #15, #22 (where #22 carries a T3346 value information element, and the value of this T3346 value information element is neither 0 nor deactivated), #25, #40, #42, #31.

[0016] With this design, the terminal device can maintain its registration status after receiving a registration rejection response message, thus enabling it to initiate the registration process again.

[0017] In one possible design, the terminal device can release the wireless link when it malfunctions. The wireless link malfunction may include: reduced signal quality of the signal transmitted by the first AN device in the first communication system, a high bit error rate in data transmission via the wireless link, or the wireless link failing to transmit data, etc., which are not limited in this application.

[0018] With this design, the terminal device can release the wireless link when the wireless link is abnormal, thereby initiating the registration process again and continuing to request registration with the first communication system.

[0019] In one possible design, the terminal device may release the wireless link if it does not receive a registration success response message from the first core network device. Specifically, in this embodiment, the following situations may occur, but are not limited to, causing the terminal device to fail to receive the registration success response message:

[0020] Scenario 1: The first core network device does not send a registration success response message. For example, the first core network device fails to complete the registration step after receiving the first registration request message.

[0021] Scenario 2: Due to message transmission abnormality, although the first core network device sends a registration success response message to the terminal device, the terminal device does not receive it.

[0022] Scenario 3: The terminal device does not receive the registration success response message within a set time period after sending the first registration request message. For example, when sending the first registration request message, the terminal device simultaneously starts timer T3430. For example, the timer duration of T3430 is 15 seconds. If the terminal device does not receive the registration success response message during the timer T3430's countdown, then when timer T3430 expires, the terminal device abandons the current registration process and releases the wireless link.

[0023] If the terminal device does not receive a registration success response message, it indicates that the registration process has failed. This design allows the terminal device to release the wireless link if the initial registration process fails, enabling it to re-initiate the registration process and continue requesting registration with the first communication system.

[0024] In one possible design, the second registration request message includes device information of a second core network device in the second communication system that has the context of the terminal device, and the second network device includes the second core network device. For example, the second registration request message may include a first GUTI of the terminal device, and the first GUTI contains device information of the second core network device (e.g., the identifier or address of the second core network device); wherein the first GUTI is mapped from a second GUTI, and the first GUTI is a unique identifier of the terminal device in the first communication system; while the second GUTI is a unique identifier of the terminal device in the second communication system, assigned to the terminal device by the second core network device in the second communication system.

[0025] With this design, after receiving the second registration request message, the first core network device can request the context of the terminal device from the second core network device based on the device information of the second core network device in the second registration request message.

[0026] In one possible design, after the terminal device sends a second registration request message to the first core network device, the terminal device receives a registration success response message from the first core network device.

[0027] In one possible design, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the first registration request message is a Tracking Area Update (TAU) request message, and the second registration request message is a TAU request message.

[0028] Secondly, embodiments of this application provide a communication method, which includes the following steps:

[0029] After the terminal device switches from the second communication system to the first communication system, the first core network device located in the first communication system receives a registration request message from the idle terminal device; the registration request message uses a second set of security contexts for integrity protection; the second set of security contexts is used for the terminal device to perform security verification with the second network device located in the second communication system; the first core network device sends a context request message to the second core network device located in the second communication system; wherein, the context request message contains the registration request message, the context request message is used to request the context of the terminal device, and the second network device contains the second core network device.

[0030] In this method, when the terminal device initiates the registration process again, a second set of security contexts is used to protect the integrity of the registration request message. Thus, when the first core network requests the terminal device's context from the second core network device based on the registration request message, it can ensure that the second core network device can successfully verify the integrity of the registration request message. This guarantees that the first core network device can successfully obtain the terminal device's context from the second core network device, thereby ensuring that the terminal device can successfully register with the first communication system. Clearly, compared to traditional solutions, this method avoids the situation where the terminal device's re-initiated registration process is rejected, improves the registration success rate of terminal devices in inter-system handover scenarios, reduces the latency of successful registration of terminal devices to the first communication system, and ultimately ensures the service continuity of terminal devices and guarantees user experience.

[0031] In one possible design, the first core network device receives a context response message from the second core network device; the context response message is used to indicate that the context request for the terminal device was successful; the first core network device sends a registration success response message to the terminal device.

[0032] With this design, when the first core network device successfully obtains the context of the terminal device, it can notify the terminal device that the registration is successful.

[0033] In one possible design, the registration request message includes device information of the second core network device in the second communication system that has the context of the terminal device; the first core network device can send the context request message to the second core network device based on the device information of the second core network device.

[0034] In one possible design, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the registration request message is a Tracking Area Update (TAU) request message.

[0035] Thirdly, embodiments of this application provide a communication method, which includes the following steps:

[0036] After the terminal device switches from the second communication system to the first communication system, the second core network device receives a context request message from the first core network device. The second core network device is located in the second communication system, and the first core network device is located in the first communication system. The context request message includes a registration request message, which is protected for integrity using a second set of security contexts. The second set of security contexts is used for security verification between the terminal device and a second network device located in the second communication system, which includes the second core device. The second core network device uses the second set of security contexts to perform integrity protection verification on the registration request message.

[0037] In this method, when the terminal device initiates the registration process again, a second set of security contexts is used to protect the integrity of the registration request message. Thus, when the first core network requests the terminal device's context from the second core network device based on the registration request message, the second core network device can successfully verify the integrity of the registration request message, ensuring that the first core network device can successfully obtain the terminal device's context from the second core network device, thereby ensuring that the terminal device can successfully register with the first communication system. Clearly, compared to traditional solutions, this method avoids the situation where the terminal device's re-initiated registration process is rejected, improves the registration success rate of terminal devices in inter-system handover scenarios, reduces the latency of successful registration of terminal devices to the first communication system, and ultimately ensures the service continuity of terminal devices and guarantees user experience.

[0038] In one possible design, after successful verification, the second core network device sends a context response message to the first core network device; the context response message indicates that the request for the terminal device's context was successful. Optionally, the context response message may contain the context of the terminal device.

[0039] In one possible design, the registration request message includes device information of the second core network device having the context of the terminal device in the second communication system.

[0040] In one possible design, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the registration request message is a Tracking Area Update (TAU) request message.

[0041] Fourthly, embodiments of this application provide a communication method, which includes the following steps:

[0042] After switching from the second communication system to the first communication system, the terminal device obtains a first set of security contexts; wherein, the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system; after the terminal device sends a registration request message to the first core network device, the terminal device releases the wireless link; wherein, the registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device; the terminal device initiates an attach procedure.

[0043] In this method, after a connected terminal device fails to complete its initial registration process upon switching from the second communication system to the first communication system, causing it to release its wireless link, the terminal device, now in an idle state, can initiate an attach process to register with the first communication system. Since the terminal device does not re-initiate the registration process but instead registers with the first communication system through the attach process, this method allows idle terminal devices to quickly register with the first communication system. Compared to the traditional solutions described above, the solution provided in this application avoids situations where the terminal device's re-initiation of the registration process is rejected, improves the registration success rate of terminal devices in inter-system handover scenarios, reduces the latency of successful registration with the first communication system, and ultimately ensures the service continuity of the terminal device and guarantees user experience.

[0044] In one possible design, the terminal device can obtain the first set of security contexts through the following steps:

[0045] The terminal device calculates the second set of security contexts according to the set security context mapping algorithm to generate the first set of security contexts.

[0046] Through this design, the terminal device can obtain the first set of security contexts corresponding to the first communication system during the inter-system handover process.

[0047] In one possible design, when the terminal device receives a registration rejection response message from the first core network device, the terminal device may release the radio link.

[0048] With this design, the terminal device can release the wireless link upon receiving a registration rejection response message, thereby registering to the first communication system through the attach procedure.

[0049] In one possible design, the registration rejection response message includes a rejection reason indication, which is used to instruct the terminal device to maintain the registration state. For example, the rejection reason indication can be other rejection reason values ​​besides the following: #3, #6, #8, #7, #9, #10, #11, #35, #12, #13, #14, #15, #22 (where #22 carries a T3346 value information element, and the value of this T3346 value information element is neither 0 nor invalid (deactivated)), #25, #40, #42, #31.

[0050] With this design, the terminal device can maintain its registration status even after receiving a registration rejection response message.

[0051] In one possible design, the terminal device can release the wireless link when it malfunctions. The wireless link malfunction may include: reduced signal quality of the signal transmitted by the first AN device in the first communication system, a high bit error rate in data transmission via the wireless link, or the wireless link failing to transmit data, etc., which are not limited in this application.

[0052] With this design, the terminal device can release the wireless link when the wireless link is abnormal, thereby registering to the first communication system through the attach process.

[0053] In one possible design, the terminal device may release the wireless link if it does not receive a registration success response message from the first core network device. Specifically, in this embodiment, the following situations may occur, but are not limited to, causing the terminal device to fail to receive the registration success response message:

[0054] Scenario 1: The first core network device does not send a registration success response message. For example, the first core network device fails to complete the registration step after receiving the first registration request message.

[0055] Scenario 2: Due to message transmission abnormality, although the first core network device sends a registration success response message to the terminal device, the terminal device does not receive it.

[0056] Scenario 3: The terminal device does not receive the registration success response message within a set time period after sending the first registration request message. For example, when sending the first registration request message, the terminal device simultaneously starts timer T3430. For example, the timer duration of T3430 is 15 seconds. If the terminal device does not receive the registration success response message during the timer T3430's countdown, then when timer T3430 expires, the terminal device abandons the current registration process and releases the wireless link.

[0057] If the terminal device does not receive a registration success response message, it indicates that the registration process has failed. This design allows the terminal device to release the wireless link if the initial registration process fails, and then register with the first communication system via the attach process.

[0058] In one possible design, the registration request message includes device information of a second core network device in the second communication system that has the context of the terminal device, and the second network device includes the second core network device.

[0059] In one possible design, the terminal device can initiate the attach process through the following steps:

[0060] The terminal device sends an attach request message to the first core network device.

[0061] In one possible design, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the registration request message is a Tracking Area Update (TAU) request message.

[0062] Fifthly, embodiments of this application provide a communication device including a unit for performing the steps in any of the above aspects.

[0063] In a sixth aspect, embodiments of this application provide a communication device including at least one processing element and at least one storage element, wherein the at least one storage element is used to store programs and data, and the at least one processing element is used to read and execute the programs and data stored in the storage element, so that the methods provided in any of the above aspects of this application are implemented.

[0064] In a seventh aspect, embodiments of this application provide a communication system, including: a terminal device for performing the method provided in the first aspect, a first core network device for performing the method provided in the second aspect, and a second core network device for performing the method provided in the third aspect.

[0065] Eighthly, embodiments of this application also provide a computer program that, when run on a computer, causes the computer to perform the methods provided in any of the above aspects.

[0066] Ninthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a computer, causes the computer to perform the method provided in any of the above aspects.

[0067] In a tenth aspect, embodiments of this application also provide a chip for reading a computer program stored in a memory and executing the method provided in any of the above aspects.

[0068] Eleventhly, embodiments of this application also provide a chip system including a processor for supporting a computer device in implementing the methods provided in any of the preceding aspects. In one possible design, the chip system further includes a memory for storing programs and data necessary for the computer device. The chip system may be composed of chips or may include chips and other discrete devices. Attached Figure Description

[0069] Figure 1A A schematic diagram of a confidentiality protection process provided in an embodiment of this application;

[0070] Figure 1B A schematic diagram of an integrity protection process provided in an embodiment of this application;

[0071] Figure 2 A schematic diagram of a communication architecture provided in an embodiment of this application;

[0072] Figure 3 A flowchart illustrating a communication method provided in an embodiment of this application;

[0073] Figure 4 A flowchart illustrating another communication method provided in an embodiment of this application;

[0074] Figure 5 A flowchart illustrating a communication example provided in this application embodiment;

[0075] Figure 6 A flowchart illustrating another communication example provided in this application embodiment;

[0076] Figure 7 A flowchart of a communication device provided in an embodiment of this application;

[0077] Figure 8 A flowchart of a communication device provided in an embodiment of this application. Detailed Implementation

[0078] This application provides a communication method, apparatus, and device to improve the registration success rate of terminal devices in inter-system handover scenarios. The method, apparatus, and device are based on the same technical concept. Since the principles for solving the problems are similar, the implementation of the apparatus, apparatus, and method can be mutually referenced, and repeated details will not be elaborated further.

[0079] The following explanations of some terms used in this application are provided to help those skilled in the art to understand them.

[0080] 1) A terminal device is a device that provides voice and / or data connectivity to a user. A terminal device can also be called user equipment (UE), mobile station (MS), mobile terminal (MT), etc. In the embodiments and examples of this application, a UE will be used as an example for illustration.

[0081] For example, terminal devices can be handheld devices, in-vehicle devices, etc., with wireless connectivity. Currently, some examples of terminal devices include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), point-of-sale (POS) terminals, wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, and various smart meters (smart water meters, smart electricity meters, smart gas meters), etc.

[0082] 2) A communication system, used to connect a terminal device to a data network using the 3rd Generation Partnership Project (3GPP) access technology when the terminal device requests a service, and to transmit user plane data between the terminal device and the data network to realize the corresponding service. It is also known as a mobile communication system or a 3GPP communication system. Unless otherwise stated, all communication systems mentioned in the following embodiments of this application are 3GPP communication systems.

[0083] The communication system is divided into an access network (AN) and a core network (CN). The access network is used to connect terminal devices to the core network via 3GPP access technology. The core network is used to connect terminal devices to different data networks. Furthermore, according to logical functions, the core network can be further divided into a control plane and a user plane.

[0084] It should also be noted that this application does not limit the communication system standard, and can be third-generation (3G) communication system. rd Generation 3G) communication system, fourth generation (4G) th Generation 4G) communication systems (i.e., Long Term Evolution (LTE) communication systems, Evolved Packet System (EPS)), 5G (5G) communication systems, 4G (5G) communication systems, 5 ... th A generation (5G) communication system (i.e., 5G system (5GS)), or a future communication system, or a communication system that evolves from any generation of communication system.

[0085] For example, in 4G communication systems, the access network can also be called the Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN), and the core network can also be called the Evolved Packet Core (EPC).

[0086] For example, in a 5G communication system, the access network can also be called a 5G radio access network (NG-RAN, or new radio (NR) system), and the core network can also be called a 5G core network (5G core, 5GC).

[0087] 3) Network equipment refers to network elements located in a communication system. The network equipment can be access network equipment (i.e., AN equipment) in the access network, or core network equipment in the core network. This application does not limit this.

[0088] 4) AN device is a device in a communication system that connects terminal devices to a wireless network. This access network device, as a node in the radio access network, can also be called a base station or a radio access network (RAN) node (or device).

[0089] Currently, some examples of AN equipment include: generation Node B (gNB), transmission reception point (TRP), evolved Node B (eNB), radio network controller (RNC), Node B (NB), access point (AP), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home evolved Node B, or home Node B, HNB), or base band unit (BBU), Enterprise LTE Discrete Spectrum Aggregation (eLTE-DSA) base station, etc.

[0090] In another network architecture, the AN device may include centralized unit (CU) nodes and distributed unit (DU) nodes. This architecture separates the protocol layers of the eNB in ​​a long term evolution (LTE) system, with some protocol layer functions centrally controlled by the CU, and the remaining part or all of the protocol layer functions distributed in the DU, which is centrally controlled by the CU.

[0091] For example, in a 4G communication system, the AN device is called an eNB; in a 5G communication system, the AN device may be called a gNB.

[0092] 5) Core network equipment, network elements located in the core network, are used to implement the functions of the core network, such as connecting the terminal device to different data networks based on call requests or service requests sent by the terminal device through the access network, and providing services such as billing, mobility management, and session management. Since the method provided in this application embodiment is in a scenario where the terminal device is switching between systems, the core network equipment involved in this application is a network element in the core network responsible for the mobility management function of the terminal device.

[0093] Since mobility management is a control plane function in the core network, in communication systems where the core network is divided into a control plane and a user plane, core network equipment with mobility management function can also be called control plane network element or control plane equipment.

[0094] For example, in a 4G communication system, a core network device with mobility management function can be called a mobility management entity (MME); in a 5G communication system, a core network device with mobility management function can be called an access and mobility management function (AMF) network element, or simply AMF.

[0095] It should also be noted that this application does not limit the name of the core network equipment with mobility management function. It can also perform other functions or be integrated with other functional network elements, and can also be called by other names.

[0096] 6) Security verification, also known as secure docking, security verification, security protection, etc., is used to protect the confidentiality and / or integrity of the receiver and sender.

[0097] 7) Inter-system handover refers to switching a terminal device from one communication system standard to another. In this embodiment, the terminal device in a radio resource control (RRC) connection state can achieve inter-system handover through a handover mechanism.

[0098] 8) A wireless link is a wireless connection between a terminal device and an AN device in a communication system, used to transmit service data or signaling between the terminal device and the AN device. It can also be called a wireless connection. For example, the wireless link may include a data resource bearer (DRB) or a signaling resource bearer (SRB), where the DBR is a wireless bearer used to transmit service data, and the SRB is a wireless bearer used to transmit RRC signaling or NAS signaling.

[0099] Once a terminal device establishes an RRC connection with an AN device, the AN device can establish a wireless link for the terminal device based on this RRC connection. Since the wireless link is established based on the RRC connection, the state of the wireless link is related to the state of the RRC connection. In the field of communications, the states of an RRC connection include: RRC active (simply called active state) and RRC idle (simply called idle state). When the terminal device's wireless link is active (not released), the terminal device is in the RRC active state. When the terminal device's wireless link is released, the terminal device enters the RRC idle state.

[0100] 9) "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the related objects before and after it are in an "or" relationship.

[0101] It should be noted that "multiple" in this application refers to two or more. "At least one" refers to one or more.

[0102] In addition, it should be understood that in the description of this application, the words "first" and "second" are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0103] It should be noted that the attach process and tracking area update (TAU) process involved in the embodiments of this application can be standard processes specified in communication standards, such as those specified in communication standard 24.301. Furthermore, the messages and timers involved in the above processes can also refer to the definitions in that communication standard.

[0104] The role of security context will be explained below.

[0105] When a terminal device accesses and resides within a communication system, the NAS of the terminal device and the NAS of the network equipment (taking core network equipment as an example) in the communication system maintain a security context for security verification to ensure the secure transmission of signaling or service data. This security verification includes confidentiality protection and / or integrity protection. For example, 3GPP protocol TS33.401 specifies that the NAS count value in the security context is one of the parameters for confidentiality and integrity protection. Furthermore, the security context may also include security protection key parameters and security protection algorithms; wherein the security protection key parameters include key parameters used to generate confidentiality keys and / or integrity keys, or confidentiality keys and / or integrity keys, and the security protection algorithms include confidentiality algorithms and / or integrity algorithms.

[0106] Specifically, in the uplink transmission direction, the terminal device can encrypt and / or perform integrity protection processing on the uplink message according to the maintained security context, while the core network device can decrypt and / or verify the integrity of the received encrypted and / or integrity-protected uplink message according to the maintained security context to obtain the uplink message.

[0107] Similarly, in the downlink transmission direction, core network equipment can also encrypt and / or perform integrity protection processing on downlink messages according to the maintained security context, while terminal equipment can decrypt and / or verify the integrity of the received encrypted and / or integrity-protected downlink messages according to the maintained security context to obtain the downlink message.

[0108] Figure 1A This diagram illustrates the process of using the same security context for confidentiality protection between the sender and receiver. Figure 1A As shown, the sender and receiver use a confidentiality algorithm to calculate a series of parameters such as the confidentiality key and NAS count to obtain a key stream block; the sender uses the key stream block to encrypt the plaintext (i.e., the message to be transmitted) to obtain ciphertext; after the ciphertext is transmitted to the receiver, the receiver uses the key stream block to decrypt the ciphertext to obtain the plaintext.

[0109] Figure 1B This diagram illustrates the process of using the same security context for integrity protection between the receiver and the sender. Figure 1BAs shown, the sender uses an integrity algorithm to calculate a checksum based on the message to be transmitted, the integrity key, and a series of parameters such as the NAS count. The sender then sends the message and the checksum to the receiver simultaneously. Upon receiving the message and checksum, the receiver uses the integrity algorithm to calculate a checksum to be verified based on the received message, the integrity key, the NAS count, and other parameters. The receiver then compares the received checksum with the generated checksum: if they match, the message integrity verification passes / successfully, indicating that the message is complete and has not been tampered with; if they differ, the message integrity verification fails / fails, indicating that the message may have been tampered with and is incomplete.

[0110] Based on the above Figure 1A and Figure 1B As illustrated in the confidentiality and integrity protection processes, to ensure secure authentication between the terminal device and the core network device (that the receiver can successfully decrypt or verify the integrity of messages sent by the sender based on the maintained security context), the security contexts maintained by both devices must be identical. Specifically, the NAS count, security protection key parameters, and security protection algorithms in the security contexts maintained by both the terminal device and the core network device must be the same. In other words, secure interoperability can only be achieved if the terminal device and the core network device maintain the same set of security contexts.

[0111] It should be noted that each security context can contain an uplink security context and a downlink security context. The uplink security context contains the uplink NAS count, and the downlink security context contains the downlink NAS count. The uplink security context is used for security verification of uplink messages, while the downlink security context is used for security verification of downlink messages.

[0112] Furthermore, the information contained in the security context differs between different communication systems. For example, the security protection key parameters or security protection algorithms contained in the security context of 5G communication systems are different from those in 4G communication systems.

[0113] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0114] Figure 2 This paper illustrates a communication architecture to which the communication method provided in this application is applicable. This communication architecture is compatible with various communication systems of different standards. Figure 2 This explanation will only take the example of a communication architecture that includes both 5G and 4G communication systems.

[0115] It should be noted that this application does not limit the communication architecture to which the method provided in this application is applicable. The architecture may include at least any two of the following communication systems: 5G communication system, 4G communication system, future next-generation communication system, Global System of Mobile communication (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Advanced Long Term Evolution (LTE-A) system, Universal Mobile Telecommunication System (UMTS), and cellular systems related to the 3rd Generation Partnership Project (3GPP), as well as communication systems evolved from the above communication systems.

[0116] In summary, the communication architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the development of communication technology, the evolution of mobile communication systems, and the evolution of network architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems and scenarios.

[0117] exist Figure 2 In the communication architecture shown, under the condition of inter-system handover, the terminal device (such as the UE in the figure) can switch from one communication system to another through inter-system handover.

[0118] like Figure 2As shown in the diagram, the 4G communication system comprises two parts: an access network and a core network. The access network is the E-UTRAN shown in the diagram, and the core network includes the following network elements: Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PGW), Policy and Charging Rules Function (PCRF) element, and Home Subscriber Server (HSS).

[0119] According to logical functions, the PGW can be further divided into: PGW control plane (PGW-control, PGW-C) network element (referred to as PGW-C) and PGW user plane (PGW-user, PGW-U) network element (referred to as PGW-U).

[0120] A 5G communication system also comprises two parts: the access network and the core network. The access network is the NG-RAN shown in the diagram, and the core network includes the following network elements: AMF (Applied Multifunction Function), User Plane Function (UPF), Session Management Function (SMF), Policy and Charge Function (PCF), and Unified Data Management (UDM).

[0121] It should be noted that, in Figure 2 In the communication architecture shown, which is compatible with both 4G and 5G communication systems, as illustrated in the figure, SMF and PGW-C can be integrated into the same network element or set up separately in different devices. Similarly, the same applies to UPF and PGW-U, HSS and UDM, and PCF and PCRF network elements. In this embodiment, their composition is not specifically limited.

[0122] In 4G or 5G communication systems, two network devices can communicate through corresponding interfaces. For details, please refer to... Figure 2As shown. It should be noted that, in order to enable inter-system handover between 5G and 4G communication systems, the AMF in the 5G communication system and the MME in the 4G communication system can also communicate through interface N26 to transmit signaling, security context, and terminal device context during the handover process.

[0123] It should be understood that the network elements in the 4G or 5G communication system can be network components implemented on dedicated hardware, software instances running on dedicated hardware, or instances of virtualized functions on a virtualization platform (such as a cloud platform). Furthermore, the embodiments of this application do not limit the distribution of the network elements in the communication system. Optionally, the network elements can be deployed in different physical devices, or multiple network elements can be integrated into the same physical device.

[0124] Furthermore, the embodiments of this application do not limit the names of each network element in the communication system. For example, in communication systems of different standards, each network element may have other names; or, for example, when multiple network elements are integrated into the same physical device, the physical device may also have other names.

[0125] In this communication architecture, terminal devices can switch from one communication system to another through inter-system handover. For ease of explanation, in the following embodiments of this application, the target communication system for inter-system handover is referred to as the first communication system, and the source communication system for inter-system handover is referred to as the second communication system. Furthermore, to facilitate the distinction and explanation of network devices in different communication systems, the network device located in the first communication system is referred to as the first network device, and the network device located in the second communication system is referred to as the second network device. The first network device may include a first core network device and a first AN device located in the first communication system, and the second network device may include a second core network device and a second AN device located in the second communication system.

[0126] When a terminal device in a connected state switches to the first communication system, both the NAS of the terminal device and the NAS of the first network device located in the first communication system acquire and maintain a first set of security contexts. These first set of security contexts are used for security authentication between the terminal device and the first network device. Furthermore, after the switchover is complete, all NAS messages exchanged between the terminal device and the first network device must be protected for integrity and / or confidentiality using the first set of security contexts.

[0127] The first set of security contexts is generated by calculating the second set of security contexts based on a set security context mapping algorithm. The second set of security contexts is used for security verification between the terminal device and the second network device located in the second communication system; that is, both the terminal device and the second network device store the second set of security contexts.

[0128] The first set of security contexts maintained by the NAS of the terminal device is generated by the terminal device calculating the second set of security contexts stored locally according to the set security context mapping algorithm.

[0129] The first set of security contexts maintained by the NAS of the first network device can be generated by the second core network device by calculating the second set of security contexts stored locally according to the set security context mapping algorithm, and then forwarded to the first network device.

[0130] This application takes the use of the same security context mapping algorithm on the terminal device side and the core network side as an example, that is, the first set of security contexts maintained by the terminal device and the first network device are the same.

[0131] In this communication architecture, after a terminal device in the connected state switches to the first communication system, it needs to initiate a registration process to register with the first communication system. However, if the terminal device releases the wireless link before successfully registering with the first communication system, it will enter an idle state. The idle terminal device will then initiate the registration process again to continue registering with the first communication system.

[0132] The terminal device initiates the registration process by sending a registration request to the first core network device. Currently, the terminal device uses a first set of security contexts to protect the integrity of this registration request. The registration request includes device information of the second core network device in the second communication system that has the context of the terminal device.

[0133] After receiving a registration request from a terminal device in an idle state, the first core network device obtains the device information of the second core network device from the registration request, and sends a context request carrying the registration request to the second core network device based on the device information, so as to obtain the context of the terminal device from the second core network device.

[0134] Upon receiving the context request, the second core network device uses a second security context to perform an integrity check on the registration request within that context request. Since the registration request is protected for integrity by the terminal device using the first security context, the integrity check performed by the second core network device will fail. Consequently, the first core network device cannot obtain the terminal device's context from the second core network device, and therefore rejects the terminal device's registration request.

[0135] If a terminal device's registration request is rejected, the terminal device can only re-enter the first communication system through an attachment process. This will inevitably prolong the latency of the terminal device registering with the first communication system, thereby affecting service continuity and ultimately impacting user experience.

[0136] Taking the switch from a 5G communication system to a 4G communication system as an example, the registration process can be a TAU process. The communication standard TS24.301 stipulates:

[0137] The UE uses the 5G security context to generate the mapped EPS security context (i.e., the 4G security context);

[0138] After the handover, the UE sends a TAU request message to the MME, and the UE uses the 4G security context to perform integrity protection on the TAU request message.

[0139] The communication standard TS33.501 specifies:

[0140] The terminal device initiates the TAU procedure by sending a TAU request to the MME carrying a mapped EPS globally unique temporary identity (GUTI) (i.e., 4G GUTI). The mapped EPS GUTI is obtained based on the 5G GUTI mapping and contains device information (such as device address or device identifier) ​​of the AMF with UE context in the 5G communication system. After receiving the TAU request, the MME obtains the AMF's device information from the mapped EPS GUTI contained in the TAU request and forwards the complete TAU request message to the AMF. The AMF uses the 5G security context to perform integrity verification on the TAU request message.

[0141] Based on the above description, in inter-system handover scenarios, the current solution results in a low registration success rate for terminal devices, leading to longer network dwell times, service terminal issues, and negatively impacting user experience. The reason for this is that the initial registration process of the terminal device after the handover fails, causing it to release the wireless link. When the terminal device enters an idle state and attempts to re-initiate the registration process, it will be rejected. It can only remain on the new communication system through the attach process.

[0142] It should be noted that the embodiments of this application do not limit the standard of the first communication system and the second communication system. For example, the first communication system can be a 5G communication system, and the second communication system can be a 4G communication system; or the first communication system can be a 4G communication system, and the second communication system can be a 5G communication system; or the first communication system can be a 5G communication system, and the second communication system can be a 6G communication system, etc. The first core network device is a network element with mobility management functions in the first communication system, and the second core device is a network element with mobility management functions in the second communication system. Furthermore, the security context used by the terminal device to perform security verification with the network device in the communication system can also be simply referred to as the security context corresponding to that communication system.

[0143] Example 1:

[0144] To address the aforementioned issues and improve the registration success rate of terminal devices in inter-system handover scenarios, this application provides a communication method. This method can be applied to, for example... Figure 2 In the communication architecture shown, please refer to the following: Figure 3 The flowchart shown below provides a detailed explanation of the method provided in the embodiments of this application.

[0145] S300a: When a terminal device resides in the second communication system, the second communication system establishes a session connection (PDU session) for the terminal device. The terminal device and a second network device located in the second communication system use a second set of security contexts for security authentication. The second network device includes a second AN device and a second core network device.

[0146] Specifically, the NAS in the terminal device and the NAS in the second network device each maintain the second set of security contexts, and use their respective maintained second set of security contexts to protect the confidentiality and integrity of transmitted messages. The specific process can be referred to the above. Figure 1A and Figure 1B The specific details will not be elaborated here.

[0147] S300b: When the current network environment meets the inter-system handover conditions, the inter-system handover of the terminal device in the connected state is triggered; the terminal device, the first network device in the first communication system, and the second network device in the second communication system start to execute the inter-system handover process, and the terminal device switches from the second communication system to the first communication system.

[0148] In one implementation, when the second network device in the second communication system determines that the inter-system handover conditions are met, it triggers the inter-system handover process from the second communication system to the first communication system. The specific process described above can be found in current communication protocols and will not be elaborated upon here.

[0149] S301a: After a successful handover, the terminal device successfully camps on the first communication system. The terminal device obtains a first set of security contexts, wherein the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system. The first network device includes a first AN device and a first core network device.

[0150] Optionally, the terminal device may use the following steps to obtain the first set of security contexts:

[0151] The terminal device calculates the second set of security contexts it maintains based on the locally stored security context mapping algorithm, and generates the first set of security contexts.

[0152] For example, the security context mapping algorithm can be the security context mapping algorithm in 3GPP protocol 33501_CR0611r1, which is used to map the security context corresponding to the 5G communication system to the security context corresponding to the 4G communication system.

[0153] S301b: After a successful handover, the first core network device in the first communication system obtains the first set of security contexts.

[0154] Optionally, the first core network device may obtain the first set of security contexts in the following ways, but not limited to: during or after a handover between different systems, the second core network device in the second communication system calculates the second set of security contexts stored locally according to a set security context mapping algorithm, generates the first set of security contexts, and sends the first set of security contexts to the first core network device.

[0155] The security context mapping algorithm used by the second core network device should be the same as that used by the terminal device. This ensures that the first set of security contexts generated by the two devices is the same, thereby ensuring that the terminal device and the first core device can successfully perform security verification using the first set of security contexts.

[0156] S302: The terminal device initiates a registration process, sending a first registration request message to the first core network device; the first core network device receives the first registration request message from the terminal device. The first registration request message uses the first set of security contexts for integrity protection.

[0157] In this embodiment of the application, after the terminal device switches to another system, the terminal device successfully camps on the first communication system. The terminal device also needs to initiate a registration process to register with the first communication system.

[0158] For example, the registration process in this embodiment can be a TAU process. The first registration request can be a TAU (tracking area update request) message that uses a first set of security contexts for integrity protection.

[0159] The first core network device located in the first communication system can obtain the RRC connection status of the terminal device. Since the terminal device initiates the registration process in the connected state, after receiving the first registration request message from the terminal device in the connected state, the first core network device will execute the corresponding registration steps and, based on the execution result, send a corresponding registration response message back to the terminal device (a registration success response message is sent if the execution is successful; a registration rejection response message is sent if the execution fails). For example, the first core network device initiates a location update process (i.e., sends a location update request message to the data function network element (e.g., HSS / UDM) that stores user-related data in the communication system.

[0160] It should be noted that, since the terminal device does not encrypt the first registration request message, after receiving the first registration request message from the terminal device in the connected state, the first core network device uses the first set of security contexts to perform integrity verification on the first registration request message (without using the first set of security contexts to decrypt the first registration request message). After the integrity verification passes, the device executes the corresponding registration steps according to the first registration request message.

[0161] In addition, the first registration request message may carry device information of the second core network device in the second communication system that has the context (UE context) of the terminal device.

[0162] The device information is used to identify the second core network device in the second communication system, and may be the device identifier or address of the second core network device, etc. This application does not limit this.

[0163] For example, the first registration request message may carry a first GUTI, and similar to the first set of security contexts, the first GUTI is obtained by mapping from a second GUTI. The first GUTI contains device information of the second core network device in the second communication system that has the context of the terminal device. Specifically, the first GUTI is a unique identifier for the terminal device in the first communication system; and the second GUTI is a unique identifier for the terminal device in the second communication system, assigned to the terminal device by the second core network device in the second communication system.

[0164] S303: If the terminal device fails to successfully register with the first communication system after sending the first registration request message to the first core network device, the wireless link of the terminal device is released. The wireless link is the wireless connection between the terminal device and the first AN device in the first communication system.

[0165] In this embodiment of the application, after the wireless link of the terminal device is released, the terminal device enters an idle state, and the first core network device can know that the terminal device is in an idle state.

[0166] In one implementation, the wireless link of the terminal device may be actively released by the first AN device. For example, the first AN device may actively release the wireless link when it determines that the wireless link is abnormal.

[0167] In another implementation, the terminal device may release the wireless link in, but is not limited to, the following ways:

[0168] Method 1: When the terminal device receives a registration rejection response message from the first core network device, the terminal device releases the wireless link. The registration rejection response message is sent by the first core network device after the registration step fails, and it notifies the terminal device that the registration process has failed, or that the first core network device rejects the terminal device's registration request.

[0169] Optionally, the registration rejection response message includes a rejection reason indication, which is used to instruct the terminal device to maintain its registered state, i.e., to prevent the terminal device from migrating to an unregistered state. For example, the rejection reason indication can be other rejection reason values ​​besides the following: #3, #6, #8, #7, #9, #10, #11, #35, #12, #13, #14, #15, #22 (where #22 carries a T3346 value information element, and the value of this T3346 value information element is neither 0 nor invalid (deactivated)), #25, #40, #42, #31.

[0170] Therefore, even after receiving the registration rejection response message, the terminal device will remain in the registration state and will initiate the registration process again later.

[0171] Method 2: If no registration success response message is received from the first core network device, the terminal device releases the wireless link. The registration success response message is sent by the first core network device after successfully executing the registration step. This message notifies the terminal device that the registration process was successful, or that the first core network device has registered the terminal device to the first communication system.

[0172] In this second method, the following situations may occur, causing the terminal device to fail to receive the registration success response message:

[0173] Scenario 1: The first core network device did not send a registration success response message. For example, the first core network device failed to complete the registration process.

[0174] Scenario 2: Due to message transmission abnormality, although the first core network device sends a registration success response message to the terminal device, the terminal device does not receive it.

[0175] Scenario 3: The terminal device does not receive the registration success response message within a set time period after sending the first registration request message. For example, when sending the first registration request message, the terminal device simultaneously starts timer T3430. For example, the timer duration of T3430 is 15 seconds. If the terminal device does not receive the registration success response message during the timer T3430's countdown, then when timer T3430 expires, the terminal device abandons the current registration process and releases the wireless link.

[0176] Method 3: When the wireless link is abnormal, the terminal device releases the wireless link.

[0177] The wireless link anomaly may include: reduced signal quality of the signal transmitted by the first AN device in the first communication system, high bit error rate of data transmitted through the wireless link, failure of the wireless link to successfully transmit data, etc., which are not limited in this application.

[0178] S304: The terminal device in the idle state (maintaining registration status) initiates the registration process again, sending a second registration request message to the first core network device; the first core network device receives the second registration request message from the idle terminal device. The second registration request message uses a second set of security contexts for integrity protection.

[0179] In this step, the terminal device does not encrypt the second registration request message.

[0180] Similar to the first registration request message, the second registration request message can be a TAU request message that uses a second security context for integrity protection. Additionally, the second registration request message also carries device information of a second core network device in the second communication system that has the context of the terminal device.

[0181] For example, the second registration request message carries the first GUTI of the terminal device. The first GUTI contains device information of the second core network device, and a detailed description can be found in the description of the first registration request message in S302, which will not be repeated here.

[0182] S305: The first core network device sends a context request message to the second core network device located in the second communication system; the second core network device receives the context request message from the first core network device. The context request message includes a second registration request message, which is used to request the context of the terminal device.

[0183] The context of the terminal device includes various information that enables the terminal device to create and maintain wireless links, bearers, and PDU sessions in the communication system, thereby realizing communication services. For example, the context of the terminal device may include network capability information, various identifiers of the terminal device, authentication information, created connection information, and created bearer information.

[0184] In one implementation, if the second registration request message contains the device information of the second core network device, after receiving the second registration request message, the first core network device obtains the device information of the second core network device from the second registration request message, and finally sends the context request message to the second core network device based on the device information of the second core network device.

[0185] In this embodiment, since the second registration request message is not encrypted but only undergoes integrity protection processing, the first core network device does not need to decrypt or verify the integrity of the second registration request message and can directly obtain the device information of the second core network device from the second registration request message. Thus, the first core network device can determine that the context request message was sent to the second core network device based on this device information.

[0186] S306: The second core network device obtains the second registration request message from the context request message, and uses the saved second set of security contexts to perform integrity verification on the second registration request message.

[0187] In one implementation, the second core network device may maintain a protection timer for each stored terminal device context. When the protection timer corresponding to the context of any terminal device expires, the second core network device deletes the context of that terminal device.

[0188] In this embodiment of the application, only the case where the second core network device stores the context of the terminal device is taken as an example, that is, the protection timer corresponding to the context of the terminal device has not expired.

[0189] S307: After the second core network device passes the integrity verification of the second registration request message, it sends a context response message to the first core network device; the first core network device receives the context response message from the second core network device. The context response message indicates that the request for context from the terminal device was successful.

[0190] Corresponding to S306, when the second core network device passes the complete verification of the second registration request message and determines that it has stored the context of the terminal device, the second core network device sends the context response message to the first core network device. Optionally, in this embodiment, the second core network device may, but is not limited to, send the context of the terminal device to the first core network device in the following ways:

[0191] The second core network device sends the context of the terminal device to the first core network device through the context response message, that is, the context response message contains the context of the terminal device.

[0192] S308: The first core network device sends a registration success response message to the terminal device; the terminal device receives the registration success response message from the first core network device.

[0193] The registration success response message is used to notify the terminal device that the registration process is successful and that the terminal device has been successfully registered to the first communication system.

[0194] After receiving a registration success response message from the first core network device through the above process, the terminal device successfully registers with the first communication system. Subsequently, the terminal device can create wireless links, bearers, and sessions within the first communication system to enable communication services.

[0195] In summary, this application provides a communication method. In this method, when a connected terminal device, after failing its initial registration process upon switching from a second communication system to a first communication system, causes the terminal device to release its wireless link, and then enters an idle state to initiate a registration process again, it sends a registration request message with integrity protection using a second set of security contexts to the first core network device in the first communication system. Upon receiving the registration request message from the idle terminal device, the first core network device can request the terminal device's context from the second core network device in the second communication system based on this message. The second core network device can then successfully verify the integrity of the registration request message using the stored second set of security contexts, thereby sending the terminal device's context to the first core network device. Therefore, the first core network device can successfully obtain the terminal device's context from the second core network device, enabling the terminal device to successfully register with the first communication system.

[0196] In traditional solutions, during inter-system handover scenarios, if the initial registration process fails and the idle terminal device re-initiates the registration process, it continues to use the first security context to protect the integrity of the registration request message. However, the second core network device can only use the second security context for integrity verification, thus the terminal device's second registration process will inevitably fail. In contrast to this traditional solution, the solution provided in this application uses the second security context to protect the integrity of the registration request message when the terminal device re-initiates the registration process. This ensures that the second core network device can successfully verify the integrity of the registration request message, thereby ensuring that the first core network device can successfully obtain the terminal device's context from the second core network device, and ultimately ensuring that the terminal device can successfully register with the first communication system. Clearly, compared to the traditional solution, the solution provided in this application avoids the situation where the terminal device's re-initiated registration process is rejected, improves the registration success rate of terminal devices in inter-system handover scenarios, reduces the latency of successful registration with the first communication system, and ultimately ensures the service continuity of the terminal device and guarantees user experience.

[0197] Example 2:

[0198] To address the aforementioned issues, reduce registration latency of terminal devices in inter-system handover scenarios, and improve the registration success rate of terminal devices, embodiments of this application provide another communication method. This method can be applied to, for example... Figure 2 In the communication architecture shown, please refer to the following: Figure 4 The flowchart shown below provides a detailed explanation of the method provided in the embodiments of this application.

[0199] Among them, such as Figure 3 , Figure 4 As shown, steps S400a-S403 in this embodiment are the same as steps S300a-S303 in embodiment one. Therefore, the specific description of steps S400a-S403 can be found in the corresponding steps in embodiment one, and will not be repeated here.

[0200] S404: After the initial registration process of the terminal device in the connected state fails and causes the terminal device to release the wireless link, the terminal device in the idle state re-camps to the first communication system and then initiates the attach process.

[0201] Optionally, the terminal device can enter the deregistration state after performing local deregistration; then, through the frequency scanning and network search process, it can re-enter the first communication system.

[0202] In one implementation, the terminal device may use the attach procedure in current communication standards to attach. For example, the terminal device needs to access the first communication system through a random access procedure; then, the terminal device sends an attach request message to the first core network device in the first communication system, etc., which will not be described in detail here.

[0203] Through the above steps, once the terminal device completes the attachment process, it can register with the first communication system.

[0204] In summary, this application provides a communication method. In this method, after a connected terminal device fails to complete its initial registration process upon switching from a second communication system to a first communication system, causing it to release its wireless link, the terminal device, now in an idle state, can initiate an attach process to register with the first communication system. Since the terminal device no longer re-initiates the registration process but instead registers with the first communication system through the attach process, this method enables idle terminal devices to quickly register with the first communication system. Compared to the aforementioned traditional solutions, the solution provided in this application avoids situations where the terminal device's re-initiation of the registration process is rejected, improves the registration success rate of terminal devices in inter-system switching scenarios, reduces the latency of successful registration with the first communication system, and ultimately ensures the service continuity of the terminal device and guarantees user experience.

[0205] Based on the embodiments provided in this application, this application also provides some communication examples. See below. Figure 5 or Figure 6 The following examples will be explained in detail. The example below illustrates a UE switching from a 5G communication system to a 4G communication system via inter-system handover. For ease of explanation, the security context corresponding to the 5G communication system will be referred to as the 5G security context, and the security context corresponding to the 4G communication system will be referred to as the 4G security context. In the 5G communication system, the AN device is denoted as gNB, and the network element with mobility management function in the core network is denoted as AMF; while in the 4G communication system, the AN device is denoted as eNB, and the network element with mobility management function in the core network is denoted as MME. Furthermore, the data function network elements HSS and UDM that store user-directed data in both the 4G and 5G communication systems can be merged into the same network element, denoted as HSS / UDM.

[0206] Example 1: This example is based on Figure 3 Examples of methods provided by the illustrated embodiments. See below. Figure 5 The flowchart shown illustrates the steps in this example in detail.

[0207] S500: The UE camps in the 5G communication system, establishes a radio link with the gNB and a PDU session, and enters the connected state; the UE uses the 5G security context to perform security authentication with network devices in the 5G communication system such as the gNB and AMF.

[0208] The NAS of both the UE and the network devices in the 5G communication system maintains the 5G security context.

[0209] S501: Network-triggered inter-system handover procedure for the UE in connected state (i.e., handover procedure from 5G communication system to 4G communication system). Optionally, this example can use the inter-system handover procedure in the current communication standard to implement S501. For example, the procedure may include the following steps S5011-S5018.

[0210] S5011: When the gNB accessed by the UE in the 5G communication system determines that the current network environment meets the inter-system handover conditions, it sends a handover request message to the AMF in the 5G communication system to trigger the inter-system handover of the UE in the connected state.

[0211] S5012: AMF performs mapping calculations on the 5G security context it maintains based on the saved security context mapping algorithm, and generates a 4G security context.

[0212] Since the 4G security context is calculated by mapping the 5G security context, the 4G security context can also be called the mapped security context, the 5G mapped security context, etc.

[0213] S5013: The AMF sends handover-related information, including the 4G security context, to the MME in the 4G communication system.

[0214] After receiving the handover-related information, the MME saves the handover-related information so that it can communicate with the UE based on the handover-related information after a successful handover.

[0215] S5014: The AMF sends a handover command to the gNB.

[0216] S5015: gNB sends a handover command to the UE.

[0217] S5016: The UE performs mapping calculations on the 5G security context it maintains based on the saved security context mapping algorithm, and generates a 4G security context.

[0218] S5017: The UE sends a handover compete message to the eNB in ​​the 4G communication system.

[0219] S5018: The eNB sends a handover notification to the MME.

[0220] S502: After the UE switches to the 4G communication system, it initiates the first TAU ​​procedure in the 4G communication system, that is, the UE sends a TAU request message to the MME. The UE uses the 4G security context to protect the integrity of this TAU request message.

[0221] S503: Upon receiving the TAU request message, the MME, after successfully performing integrity verification on the TAU request message using the 4G security context, executes the corresponding TAU step. Optionally, this example can implement S503 using the TAU step executed by the MME in current communication standards. For example, the TAU step may include the following steps S5031-S5034.

[0222] S5031: MMR sends a location update request message to HSS / UDM.

[0223] S5032: After receiving the location update request message, the HSS / UDM sends a deregistration notification (Nudm_UECM_DeregistrationNotification) to the AMF in the 5G communication system. The AMF stores the context of the UE, and the deregistration notification is used to instruct the AMF to delete the UE's context.

[0224] S5033: If the protection timer for the UE's context has not expired, the AMF continues to maintain the UE's context.

[0225] It should be noted that if the protection timer for the UE's context has expired, the AMF will delete the UE's context upon receiving the deregistration notification. Conversely, if the AMF continues to maintain the UE's context because the protection timer has not expired, the protection timer will continue to run until it expires, at which point the AMF will delete the UE's context.

[0226] Optionally, the UE's radio link is released when any of the following steps S504a-S504d are performed.

[0227] S504a: If an exception occurs during the execution of the TAU step in S503 above, the MME sends a TAU reject message to the UE. This TAU reject message is used to notify the UE that the TAU process has failed.

[0228] The TAU rejection message contains a rejection reason value that instructs the UE to remain registered and will not cause the UE to migrate to an unregistered state. Therefore, the UE will continue to remain registered after receiving the TAU rejection message.

[0229] For example, the rejection reason value included in the TAU rejection message can be any rejection reason value other than the following:

[0230] #3, #6, #8, #7, #9, #10, #11, #35, #12, #13, #14, #15, #22 (where #22 carries a T3346 value information element, and the value of this T3346 value information element is neither 0 nor invalid (deactivated)), #25, #40, #42, #31.

[0231] S504b: The UE did not receive a TAU success response message from the MME. This TAU success response message is used to notify the UE that the TAU procedure was successful. Since the UE did not receive this message, it determines that the TAU procedure failed.

[0232] Optionally, the UE may fail to receive the TAU success response message in the following situations:

[0233] Scenario 1: An error occurred during the MME's execution of the TAU step, and no TAU success response message was sent to the UE.

[0234] Scenario 2: Message transmission between MME and UE is abnormal; the successful response message sent by MME to TAU fails to be transmitted to UE.

[0235] Scenario 3: After sending the TAU request message, the UE starts timer T3430; and during the timer T3430, the UE does not receive the TAU successful response message until T3430 times out.

[0236] S504c: The UE has determined that the radio link is abnormal.

[0237] Optionally, a wireless link anomaly may include, but is not limited to, the following:

[0238] The signal quality of the signal received by the UE from the eNB is reduced, the bit error rate of the data transmitted by the UE through the radio link is high, and the UE is unable to successfully transmit data through the radio link.

[0239] S504d: eNB has determined that the wireless link is faulty.

[0240] Optionally, a wireless link anomaly may include, but is not limited to, the following:

[0241] The signal quality of the signal received by the eNB from the UE is reduced, the bit error rate of the data transmitted by the eNB through the radio link is high, and the eNB is unable to successfully transmit data through the radio link.

[0242] S505: In any of the above S504a-S504d cases, the UE's radio link is released, and the UE enters the idle state.

[0243] S506: The idle-state UE re-initiates the TAU procedure, that is, the UE sends the TAU request message to the MME again. In this case, the UE uses the 5G security context to protect the integrity of the TAU request message.

[0244] The TAU request messages sent in S502 and S506 carry the UE's 4G GUTI (i.e., the UE's GUTI in the 4G communication system). This 4G GUTI is mapped by the UE based on the 5G GUTI; therefore, this 4G GUTI can also be called the mapped GUTI.

[0245] The 4G GUTI contains device information (such as the AMF identifier or address) of the AMF in the 5G communication system that stores the context of the UE.

[0246] S507: After receiving a TAU request message from an idle UE, the MME sends a context request message to the AMF in the 5G communication system based on the AMF device information in the TAU request message. This context request message contains the TAU request message and is used to request the UE's context.

[0247] S508: After receiving the context request message, the AMF uses the 5G security context to perform integrity verification on the TAU request message, and the verification passes.

[0248] S509: The AMF returns a context response message to the MME. This context response message indicates that the request for the UE's context was successful. The context response message contains the UE's context.

[0249] S510: After receiving the context response message, the MME replies to the UE with a TAU success response message. The TAU success response message is used to notify that the TAU process was successful and that the UE has successfully registered with the 4G communication system.

[0250] In traditional 5G to 4G switching scenarios, if a connected UE fails its initial TAU (Trusted Access Request) procedure after the handover, and then re-initiates the TAU procedure in an idle state, it continues to use the 4G security context to protect the integrity of the TAU request message. The MME (Mechanical Management Interface) forwards this TAU request message to the AMF (Automatic Security Framework) to obtain the UE's context. However, the AMF can only use the 5G security context for integrity verification. Therefore, the AMF will fail to verify the TAU request message, preventing the MME from obtaining the UE's context, ultimately causing the UE's subsequent TAU ​​procedure to fail. In contrast to this traditional approach, in this example, when the UE re-initiates the TAU procedure, it uses the 5G security context to protect the integrity of the TAU request message. This ensures that when the AMF receives the TAU request message forwarded by the MME, it can successfully verify the integrity of the TAU request message, thus ensuring that the MME can successfully obtain the UE's context from the AMF, and consequently, that the UE can successfully register with the 4G communication system through the TAU procedure. Obviously, compared with traditional solutions, the solution provided in this application can avoid the situation where the TAU process initiated by the UE is rejected again, improve the UE registration success rate in the scenario of switching from a 5G communication system to a 4G communication system, reduce the latency of the UE successfully registering to the 4G communication system, and ultimately ensure the UE's service continuity and user experience.

[0251] Example 2: This example is based on Figure 4 Examples of methods provided by the illustrated embodiments. See below. Figure 6 The flowchart shown illustrates the steps in this example in detail. For example, ... Figure 5 and Figure 6 As shown, steps S600-S605 in this example are the same as steps S500-S505 in Example 1. Therefore, the same steps can be referred to each other, and will not be described in detail here.

[0252] S606: After a connected UE switches from a 5G communication system to a 4G communication system, the first TAU ​​procedure is successful, causing the UE to release the radio link. After the UE enters the idle state and re-camps to the 4G communication system, it initiates the attach procedure.

[0253] The UE can enter the idle state, perform local deregistration, and then enter the deregistration state; then it can re-enter the 4G communication system through the frequency scanning and network search process.

[0254] Optionally, the UE can use the attach procedure in the current communication standard to attach. For example, the UE accesses the 4G communication system through a random access procedure; then it sends an attach request message to the MMR to request attaching and registering with the 4G communication system.

[0255] Once the UE successfully completes the attach process, it can register with the 4G communication system.

[0256] In this example, after a connected UE fails its initial TAU (Telematics Admissions) procedure upon switching from a 5G to a 4G communication system, causing it to release its radio link, the idle UE can initiate an attach procedure to register with the 4G communication system. Since the UE no longer re-initiates the TAU procedure but registers with the 4G communication system through the attach procedure, this example allows an idle UE to quickly register with the 4G communication system. Compared to the traditional solutions described above, the solution provided in this application avoids the situation where the UE's re-initiation of the TAU procedure is rejected, improves the UE registration success rate in scenarios switching from a 5G to a 4G communication system, reduces the latency of successful UE registration with the 4G communication system, and ultimately ensures UE service continuity and user experience.

[0257] Based on the same technical concept, this application also provides a communication device, the structure of which is as follows: Figure 7 As shown, it includes a communication unit 701 and a processing unit 702. The communication device 700 can be applied to... Figure 2 The core network device or UE in the illustrated communication architecture can implement the communication methods provided in the above embodiments and examples. Optionally, the physical manifestation of the communication device 700 can be a communication device, such as a core network device or a terminal device (i.e., UE); or the communication device can be other devices capable of implementing the functions of a communication device, such as a processor or chip inside the communication device. Specifically, the communication device 700 can be a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), or a system on a chip (SOC), or some other programmable chip.

[0258] The functions of each unit in the device 700 are described below.

[0259] The communication unit 701 is used to receive and send data.

[0260] When the communication device 700 is applied to core network equipment, the communication unit 701 can be implemented through a physical interface, a communication module, a communication interface, and an input / output interface. The communication device 700 can connect to a network cable or electrical cable through the communication unit 701, thereby establishing a physical connection with other devices.

[0261] When the communication device 700 is applied to a terminal device, the communication unit 701 can be implemented by a transceiver, such as a mobile communication module.

[0262] The mobile communication module can provide solutions for wireless communication applications on terminal devices, including 2G / 3G / 4G / 5G / 6G and future next-generation technologies. The mobile communication module may include at least one antenna, at least one filter, a switch, a power amplifier, a low-noise amplifier (LNA), etc. The terminal device can access and interact with the AN device in the mobile communication system through the mobile communication module, thereby enabling interaction between the terminal device and the mobile communication system.

[0263] In one embodiment, the communication device 700 is applied to Figure 3 Terminal devices in, such as Figure 5 The UE shown is an example. The processing unit 702 is used for:

[0264] After the terminal device switches from the second communication system to the first communication system, it obtains a first set of security contexts; wherein, the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system;

[0265] After sending a first registration request message to the first core network device through the communication unit 701, the wireless link of the terminal device is released; wherein, the first registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device.

[0266] The second registration request message is sent to the first core network device through the communication unit 701. The second registration request message uses a second set of security contexts for integrity protection. The second set of security contexts is used for the terminal device to perform security verification with the second network device located in the second communication system.

[0267] Optionally, when acquiring the first set of security contexts, the processing unit 702 is specifically used for:

[0268] The first set of security contexts is generated by calculating the second set of security contexts according to the established security context mapping algorithm.

[0269] Optionally, when releasing the wireless link of the terminal device, the processing unit 702 is specifically used for:

[0270] When the wireless link is released upon receiving a registration rejection response message from the first core network device via the communication unit 701, the wireless link is released.

[0271] Optionally, the registration rejection response message includes a rejection reason indication, which is used to instruct the terminal device to maintain the registration status.

[0272] Optionally, when releasing the wireless link of the terminal device, the processing unit 702 is specifically used for:

[0273] When the wireless link malfunctions, the wireless link is released.

[0274] Optionally, when releasing the wireless link of the terminal device, the processing unit 702 is specifically used for:

[0275] If a successful registration response message is not received from the first core network device through the communication unit 701, the wireless link is released.

[0276] Optionally, the second registration request message includes device information of a second core network device in the second communication system that has the context of the terminal device, and the second network device includes the second core network device.

[0277] Optionally, the processing unit 702 is further configured to:

[0278] After sending a second registration request message to the first core network device through the communication unit 701, a registration success response message is received from the first core network device through the communication unit 701.

[0279] Optionally, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the first registration request message is a Tracking Area Update (TAU) request message, and the second registration request message is a TAU request message.

[0280] In one embodiment, the communication device 700 is applied to Figure 3 The first core network equipment located in the first communication system, for example Figure 5 The MME shown in the example. The processing unit 702 is used for:

[0281] After the terminal device switches from the second communication system to the first communication system, it receives a registration request message from the idle terminal device through the communication unit 701; the registration request message uses a second set of security contexts for integrity protection; the second set of security contexts is used for the terminal device to perform security verification with the second network device located in the second communication system;

[0282] The communication unit 701 sends a context request message to the second core network device located in the second communication system; wherein the context request message includes the registration request message, the context request message is used to request the context of the terminal device, and the second network device includes the second core network device.

[0283] Optionally, the processing unit 702 is further configured to:

[0284] The communication unit 701 receives a context response message from the second core network device; wherein the context response message is used to indicate that the request for context from the terminal device was successful.

[0285] The communication unit 701 sends a registration success response message to the terminal device.

[0286] Optionally, the registration request message includes device information of the second core network device in the second communication system that has the context of the terminal device; the processing unit 702, when sending a context request message to the second core network device located in the second communication system through the communication unit 701, includes:

[0287] Based on the device information of the second core device, the context request message is sent to the second core network device.

[0288] Optionally, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the registration request message is a Tracking Area Update (TAU) request message.

[0289] In one embodiment, the communication device 700 is applied to Figure 3 The second core network equipment located in the second communication system, for example Figure 5 The AMF shown in the example. The processing unit 702 is used for:

[0290] After the terminal device switches from the second communication system to the first communication system, it receives a context request message from the first core network device through the communication unit 701; wherein the first core network device is located in the first communication system, the context request message contains a registration request message, and the registration request message uses a second set of security contexts for integrity protection; the second set of security contexts is used for the terminal device to perform security verification with a second network device located in the second communication system, and the second network device contains the second core device.

[0291] The second security context is used to perform integrity protection verification on the registration request message.

[0292] Optionally, the processing unit 702 is further configured to:

[0293] After successful verification, a context response message is sent to the first core network device through the communication unit 701; wherein, the context response message is used to indicate that the request for context from the terminal device was successful.

[0294] Optionally, the registration request message may include device information of the second core network device in the second communication system that has the context of the terminal device.

[0295] Optionally, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the registration request message is a Tracking Area Update (TAU) request message.

[0296] In one embodiment, the communication device 700 is applied to Figure 4 Terminal devices in, such as Figure 6 The UE shown in the example. The processing unit 702 is used for:

[0297] After the terminal device switches from the second communication system to the first communication system, it obtains a first set of security contexts; wherein, the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system;

[0298] After sending a registration request message to the first core network device through the communication unit 701, the wireless link of the terminal device is released; wherein, the registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device;

[0299] Initiate the attachment process.

[0300] Optionally, when acquiring the first set of security contexts, the processing unit 702 is specifically used for:

[0301] The first set of security contexts is generated by calculating the second set of security contexts according to the established security context mapping algorithm.

[0302] Optionally, when releasing the wireless link of the terminal device, the processing unit 702 is specifically used for:

[0303] When the wireless link is released upon receiving a registration rejection response message from the first core network device via the communication unit 701, the wireless link is released.

[0304] Optionally, the registration rejection response message includes a rejection reason indication, and the rejection original value indication is used to instruct the terminal device to maintain the registration status.

[0305] Optionally, when releasing the wireless link of the terminal device, the processing unit 702 is specifically used for:

[0306] When the wireless link malfunctions, the wireless link is released.

[0307] Optionally, when releasing the wireless link of the terminal device, the processing unit 702 is specifically used for:

[0308] If a successful registration response message is not received from the first core network device through the communication unit 701, the wireless link is released.

[0309] Optionally, the registration request message includes device information of a second core network device in the second communication system that has the context of the terminal device, and the second network device includes the second core network device.

[0310] Optionally, the processing unit 702, when initiating the attachment process, is specifically used for:

[0311] The attachment request message is sent to the first core network device through the communication unit 701.

[0312] Optionally, the second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; the registration request message is a Tracking Area Update (TAU) request message.

[0313] It should be noted that the module division in the above embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical entities, or have two or more units integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0314] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0315] Based on the same technical concept, this application also provides a communication device, which can be applied to, for example... Figure 2 The core network equipment or UE in the communication architecture shown can implement the communication methods provided in the above embodiments and examples, and has Figure 7 The function of the communication device shown. (See also...) Figure 8 As shown, the communication device 800 includes a communication module 801, a processor 802, and a memory 803. The communication module 801, the processor 802, and the memory 803 are interconnected.

[0316] Optionally, the communication module 801, the processor 802, and the memory 803 are interconnected via a bus 804. The bus 804 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0317] The communication module 801 is used to receive and send data, enabling communication and interaction with other devices. For example, when the communication device 800 is applied to a core network device, the communication module 801 can be implemented through a physical interface, a communication module, a communication interface, or an input / output interface. As another example, when the communication device 800 is applied to a terminal device, the communication module 801 can also be implemented through a transceiver.

[0318] In one embodiment, the communication device 800 can be Figure 3 Terminal devices in, such as Figure 5 The UE shown is an example. Processor 802 is used for:

[0319] After the terminal device switches from the second communication system to the first communication system, it obtains a first set of security contexts; wherein, the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system;

[0320] After sending a first registration request message to the first core network device through the communication module 801, the wireless link of the terminal device is released; wherein, the first registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device;

[0321] The communication module 801 sends a second registration request message to the first core network device. The second registration request message uses a second set of security contexts for integrity protection. The second set of security contexts is used for the terminal device to perform security verification with the second network device located in the second communication system.

[0322] In another embodiment, the communication device 800 can be Figure 3 The first core network equipment located in the first communication system, for example Figure 5 The MME shown in the example. The processor 802 is used for:

[0323] After the terminal device switches from the second communication system to the first communication system, the communication module 801 receives a registration request message from the idle terminal device; the registration request message uses a second set of security contexts for integrity protection; the second set of security contexts is used for the terminal device to perform security verification with the second network device located in the second communication system;

[0324] The communication module 801 sends a context request message to the second core network device located in the second communication system; wherein the context request message includes the registration request message, the context request message is used to request the context of the terminal device, and the second network device includes the second core network device.

[0325] In another embodiment, the communication device 800 can be Figure 3 The second core network equipment located in the second communication system, for example Figure 5 The AMF shown in the example. The processor 802 is used for:

[0326] After the terminal device switches from the second communication system to the first communication system, it receives a context request message from the first core network device through the communication module 801. The first core network device is located in the first communication system. The context request message contains a registration request message, which uses a second set of security contexts for integrity protection. The second set of security contexts is used for the terminal device to perform security verification with a second network device located in the second communication system. The second network device includes the second core device.

[0327] The second security context is used to perform integrity protection verification on the registration request message.

[0328] In another embodiment, the communication device 800 can be Figure 4 Terminal devices in, such as Figure 6 The UE shown in the example. Processor 802, used for:

[0329] After the terminal device switches from the second communication system to the first communication system, it obtains a first set of security contexts; wherein, the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system;

[0330] After sending a registration request message to the first core network device through the communication module 801, the wireless link of the terminal device is released; wherein, the registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device;

[0331] Initiate the attachment process.

[0332] It should be noted that this embodiment does not provide a detailed description of the specific functions of the processor 802. The specific functions of the processor 802 can be found in the descriptions of the communication methods provided in the above embodiments and examples. Figure 7 The specific functional description of the communication device 700 in the illustrated embodiment will not be repeated here.

[0333] The memory 803 is used to store program instructions and data. Specifically, the program instructions may include program code, which includes computer operation instructions. The memory 803 may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The processor 802 executes the program instructions stored in the memory 803 and uses the data stored in the memory 803 to implement the above functions, thereby realizing the communication method provided in the above embodiments.

[0334] It is understood that this application Figure 8 The memory 803 can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0335] Based on the above embodiments, this application also provides a computer program that, when run on a computer, causes the computer to execute the communication method provided in the above embodiments.

[0336] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, causes the computer to perform the communication method provided in the above embodiments.

[0337] The storage medium can be any available medium that a computer can access. For example, but not limited to, a computer-readable medium can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0338] Based on the above embodiments, this application also provides a chip for reading computer programs stored in a memory and implementing the communication method provided in the above embodiments.

[0339] Based on the above embodiments, this application provides a chip system including a processor for supporting a computer device in implementing the functions involved in the service equipment, forwarding equipment, or site equipment in the above embodiments. In one possible design, the chip system further includes a memory for storing necessary programs and data of the computer device. This chip system may be composed of chips or may include chips and other discrete components.

[0340] In summary, this application provides a communication method, apparatus, and device. In this solution, after a system handover, if a connected terminal device fails to complete its initial registration process with the target communication system, causing it to release its wireless link, and then re-initiates the registration process in an idle state, it sends a registration request message to the target communication system, using the security context corresponding to the source communication system for integrity protection. Upon receiving this registration request message, the target communication system can successfully obtain the terminal device's context from the source communication system, thereby enabling the terminal device to successfully register with the target communication system. In conclusion, this solution avoids situations where the terminal device's re-initiated registration process is rejected, improves the registration success rate of terminal devices in system handover scenarios, reduces registration latency, and ultimately ensures service continuity and user experience for the terminal device.

[0341] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0342] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0343] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0344] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0345] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of protection of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A communication method, characterized in that, include: After switching from the second communication system to the first communication system, the terminal device obtains a first set of security contexts; wherein, the first set of security contexts is used by the terminal device to perform security authentication with the first network device located in the first communication system; After the terminal device sends a first registration request message to the first core network device, the terminal device releases the wireless link and enters an idle state because the registration process is incomplete or fails; wherein, the first registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device; While maintaining its registration status, the terminal device sends a second registration request message to the first core network device. The second registration request message uses a second set of security contexts for integrity protection. The second set of security contexts is used by the terminal device to perform security verification with a second network device located in the second communication system.

2. The method as described in claim 1, characterized in that, The terminal device obtains the first set of security contexts, including: The terminal device calculates the second set of security contexts according to the set security context mapping algorithm to generate the first set of security contexts.

3. The method as described in claim 1 or 2, characterized in that, The terminal device releases the wireless link, including: When the terminal device receives a registration rejection response message from the first core network device, the terminal device releases the wireless link.

4. The method as described in claim 3, characterized in that, The registration rejection response message includes a rejection reason indication, which is used to instruct the terminal device to maintain the registration status.

5. The method as described in claim 1 or 2, characterized in that, The terminal device releases the wireless link, including: When the wireless link fails, the terminal device releases the wireless link.

6. The method as described in claim 1 or 2, characterized in that, The terminal device releases the wireless link, including: If no registration success response message is received from the first core network device, the terminal device releases the wireless link.

7. The method according to any one of claims 1-6, characterized in that, The second registration request message contains device information of a second core network device in the second communication system that has the context of the terminal device, and the second network device includes the second core network device.

8. The method according to any one of claims 1-7, characterized in that, After the terminal device sends a second registration request message to the first core network device, the method further includes: The terminal device receives a registration success response message from the first core network device.

9. The method according to any one of claims 1-8, characterized in that, The second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; The first registration request message is a Tracking Area Update (TAU) request message, and the second registration request message is a TAU request message.

10. A communication method, characterized in that, include: After the terminal device switches from the second communication system to the first communication system, the first core network device located in the first communication system receives a registration request message from the terminal device in the idle state; The registration request message is protected for integrity using a second security context. The second set of security contexts is used for the terminal device to perform security authentication with the second network device located in the second communication system; wherein the terminal device releases the wireless link and enters an idle state due to the incomplete or failed initial registration process; The first core network device sends a context request message to the second core network device located in the second communication system; wherein, the context request message includes the registration request message, the context request message is used to request the context of the terminal device, and the second network device includes the second core network device.

11. The method as described in claim 10, characterized in that, The method further includes: The first core network device receives a context response message from the second core network device; the context response message is used to indicate that the request for context from the terminal device was successful. The first core network device sends a registration success response message to the terminal device.

12. The method as described in claim 10 or 11, characterized in that, The registration request message contains device information of the second core network device in the second communication system that has the context of the terminal device; The first core network device sends a context request message to the second core network device located in the second communication system, including: The first core network device sends the context request message to the second core network device based on the device information of the second core network device.

13. The method according to any one of claims 10-12, characterized in that, The second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; The registration request message is a Tracking Area Update (TAU) request message.

14. A communication method, characterized in that, include: After the terminal device switches from the second communication system to the first communication system, the second core network device receives a context request message from the first core network device. The second core network device is located in the second communication system, and the first core network device is located in the first communication system. The context request message includes a registration request message, which uses a second set of security contexts for integrity protection. The registration request message is sent by the terminal device after it releases the radio link and enters an idle state due to an incomplete or failed initial registration process. The second set of security contexts is used for security verification between the terminal device and a second network device located in the second communication system, which includes the second core device. The second core network device uses the second set of security contexts to perform integrity protection verification on the registration request message.

15. The method as described in claim 14, characterized in that, The method further includes: After successful verification, the second core network device sends a context response message to the first core network device; the context response message is used to indicate that the request for context from the terminal device was successful.

16. The method as described in claim 14 or 15, characterized in that, The registration request message contains device information of the second core network device in the second communication system that has the context of the terminal device.

17. The method according to any one of claims 14-16, characterized in that, The second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; The registration request message is a Tracking Area Update (TAU) request message.

18. A communication device, applied to a terminal equipment, characterized in that, include: The communication unit is used to receive and send data; Processing unit, used for: After the terminal device switches from the second communication system to the first communication system, it obtains a first set of security contexts; wherein, the first set of security contexts is used for the terminal device to perform security authentication with a first network device located in the first communication system; After sending a first registration request message to the first core network device through the communication unit, if the registration process is incomplete or fails, the wireless link of the terminal device is released and it enters an idle state; wherein, the first registration request message uses the first set of security contexts for integrity protection, and the first network device includes the first core network device; While maintaining the registration status, a second registration request message is sent to the first core network device through the communication unit. The second registration request message uses a second set of security contexts for integrity protection. The second set of security contexts is used for the terminal device to perform security verification with the second network device located in the second communication system.

19. The apparatus as claimed in claim 18, characterized in that, The processing unit, when acquiring the first set of security contexts, is specifically used for: The first set of security contexts is generated by calculating the second set of security contexts according to the established security context mapping algorithm.

20. The apparatus as claimed in claim 18 or 19, characterized in that, The processing unit, when releasing the wireless link of the terminal device, is specifically used for: Upon receiving a registration rejection response message from the first core network device via the communication unit, the wireless link is released.

21. The apparatus as claimed in claim 20, characterized in that, The registration rejection response message includes a rejection reason indication, which is used to instruct the terminal device to maintain the registration status.

22. The apparatus as claimed in claim 18 or 19, characterized in that, When releasing the wireless link of the terminal device, the processing unit is specifically used for: When the wireless link malfunctions, the wireless link is released.

23. The apparatus as claimed in claim 18 or 19, characterized in that, When releasing the wireless link of the terminal device, the processing unit is specifically used for: If no successful registration response message is received from the first core network device through the communication unit, the wireless link is released.

24. The apparatus according to any one of claims 18-23, characterized in that, The second registration request message contains device information of a second core network device in the second communication system that has the context of the terminal device, and the second network device includes the second core network device.

25. The apparatus according to any one of claims 18-24, characterized in that, The processing unit is further configured to: After sending a second registration request message to the first core network device through the communication unit, a registration success response message is received from the first core network device through the communication unit.

26. The apparatus according to any one of claims 18-25, characterized in that, The second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; The first registration request message is a Tracking Area Update (TAU) request message, and the second registration request message is a TAU request message.

27. A communication device applied to a first core network device, the first core network device being located in a first communication system, characterized in that, include: The communication unit is used to receive and send data; Processing unit, used for: After the terminal device switches from the second communication system to the first communication system, it receives a registration request message from the idle terminal device through the communication unit; the registration request message uses a second set of security contexts for integrity protection. The second set of security contexts is used for the terminal device to perform security authentication with the second network device located in the second communication system; wherein the terminal device releases the wireless link and enters an idle state due to the incomplete or failed initial registration process; The communication unit sends a context request message to a second core network device located in the second communication system; wherein the context request message includes the registration request message, the context request message is used to request the context of the terminal device, and the second network device includes the second core network device.

28. The apparatus as claimed in claim 27, characterized in that, The processing unit is further configured to: The communication unit receives a context response message from the second core network device; wherein the context response message is used to indicate that the request for context from the terminal device was successful. The communication unit sends a registration success response message to the terminal device.

29. The apparatus as claimed in claim 27 or 28, characterized in that, The registration request message contains device information of the second core network device in the second communication system that has the context of the terminal device; The processing unit, when sending a context request message to a second core network device located in the second communication system via the communication unit, includes: Based on the device information of the second core device, the context request message is sent to the second core network device.

30. The apparatus according to any one of claims 27-29, characterized in that, The second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; The registration request message is a Tracking Area Update (TAU) request message.

31. A communication device applied to a second core network device, the second core network device being located in a second communication system, characterized in that, include: The communication unit is used to receive and send data; Processing unit, used for: After the terminal device switches from the second communication system to the first communication system, it receives a context request message from the first core network device through the communication unit. The first core network device is located in the first communication system. The context request message includes a registration request message, which uses a second set of security contexts for integrity protection. The registration request message is sent by the terminal device after it releases the wireless link and enters an idle state due to an incomplete or failed initial registration process. The second set of security contexts is used for security verification between the terminal device and a second network device located in the second communication system, which includes the second core device. The second security context is used to perform integrity protection verification on the registration request message.

32. The apparatus as claimed in claim 31, characterized in that, The processing unit is further configured to: After successful verification, a context response message is sent to the first core network device through the communication unit; wherein, the context response message is used to indicate that the request for context from the terminal device was successful.

33. The apparatus as claimed in claim 31 or 32, characterized in that, The registration request message contains device information of the second core network device in the second communication system that has the context of the terminal device.

34. The apparatus according to any one of claims 31-33, characterized in that, The second communication system is a fifth-generation 5G communication system, and the first communication system is a fourth-generation 4G communication system; The registration request message is a Tracking Area Update (TAU) request message.

35. A communication device, characterized in that, include: The communication module is used to receive and send data; A processor for implementing the method according to any one of claims 1-17 via the communication module.

36. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the method described in any one of claims 1-17.

37. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method according to any one of claims 1-17.

38. A chip, characterized in that, The chip is coupled to a memory, and the chip reads a computer program stored in the memory to execute the method described in any one of claims 1-17.

Images