Patent Description:
In different communications networks, voice services have different bearing mechanisms. Specifically, in a network using a 2nd generation (2nd generation, <NUM>) mobile communications technology or a 3rd generation (3rd generation, <NUM>) mobile communications technology, a voice service is a session service carried in a circuit switched ( CS) domain. With development of network technologies, some networks that provide a packet switched (PS) domain, for example, a long term evolution (LTE) network, also support the voice service.

Single radio voice call continuity (single radio voice call continuity, SRVCC) is a solution for implementing voice service continuity in the long term evolution (long term evolution, LTE) network. To avoid a problem that the voice service is interrupted after a terminal performing the voice service moves out of coverage of the LTE network, the SRVCC solution may be used to hand over the voice service from the packet switched (packet switch, PS) domain to the circuit switched (circuit switch, CS) domain, ensuring that the voice service is not interrupted.

In a next-generation communications network, for example, in a 5th generation (5th Generation, <NUM>) mobile communications technology, a voice over IP multimedia subsystem (voice over IP multimedia subsystem, VoIMS) technology is supported. To avoid voice service interruption after the terminal performing the voice service moves out of coverage of the <NUM> network, in other words, to support continuity of the voice service, the voice service needs to be handed over from the <NUM> network to the CS domain of the <NUM>/<NUM> network.

<NPL>describes handover using the SRVCC solution.

How to hand over the voice service from the <NUM> network to the CS domain of the <NUM>/<NUM> network to ensure continuity of the voice service in the <NUM> network becomes a technical problem that urgently needs to be resolved.

This application provides a communication method and a communications apparatus, so that a voice service of a terminal is handed over from a bearer in a PS domain to a bearer in a CS domain, to ensure continuity of the voice service in a <NUM> network, and improve user experience.

Further optional features are set out in the dependent claims.

The terms such as "component", "module", and "system" used in this application are used to indicate computer-related entities, hardware, firmware, combinations of hardware and software, software, or software being executed. For example, the component may be, but is not limited to, a process that runs on a processor, a processor, an object, an executable file, an execution thread, a program, and/or a computer. As shown in the figures, both a computing device and an application that runs on the computing device may be components. One or more components may reside within a process and/or an execution thread, and a component may be located on one computer and/or distributed between two or more computers. In addition, these components may be executed from various computer-readable media that store various data structures. For example, the components may communicate by performing a local and/or remote process and based on, for example, a signal having one or more data packets (for example, data from two components interacting with another component in a local system, a distributed system, and/or across a network such as an internet interacting with another system by using the signal).

It should be understood that division of manners, cases, types, and embodiments in embodiments of this application are merely for ease of description, but should not constitute any special limitation, and features in various manners, types, cases, and embodiments may be combined when there is no contradiction.

It should be further understood that in the embodiments of this application, "first", "second", "third", and the like are merely intended to indicate different objects, and do not indicate other limitations on the indicated objects.

The technical solutions of the embodiments of this application may be applied to various communications systems, such as a global system for mobile communications (GSM) system, a code division multiple access (code division multiple access, CDMA) system, a wideband code division multiple access (wideband code division multiple access, WCDMA) system, a general packet radio service (general packet radio service, GPRS), a long term evolution (long term evolution, LTE) system, an LTE frequency division duplex (frequency division duplex, FDD) system, an LTE time division duplex (time division duplex, TDD) system, a universal mobile telecommunications system (UMTS), a worldwide interoperability for microwave access (worldwide interoperability for microwave access, WiMAX) communications system, an evolved packet system (evolved packet system, EPS), a future 5th generation (5th generation, <NUM>) system, or a new radio (new radio, NR) system.

A terminal apparatus in the embodiments of this application may be user equipment, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, or a user apparatus. The terminal apparatus may alternatively be a cellular phone, a cordless phone, a session initiation protocol (session initiation protocol, SIP) phone, a wireless local loop (wireless local loop, WLL) station, a personal digital assistant (personal digital assistant, PDA), a handheld device having a wireless communication function, a computing device, another processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, a terminal apparatus in a <NUM> network, or a terminal apparatus in a future evolved public land mobile network (public land mobile network, PLMN). This is not limited in the embodiments of this application.

A base station in the embodiments this application may be a device configured to communicate with a terminal apparatus. The base station may be a base transceiver station (base transceiver station, BTS) in a global system for mobile communications (GSM) or a code division multiple access (code division multiple access, CDMA) system, or may be a NodeB (NodeB, NB) in a wideband code division multiple access (wideband code division multiple access, WCDMA) system, or may be an evolved NodeB (eNB or eNodeB) in an LTE system, or may be a radio controller in a cloud radio access network (cloud radio access network, CRAN) scenario, or the like. This is not limited in the embodiments of this application.

Network elements in the embodiments of this application may include network devices in a <NUM> system architecture and/or in a <NUM> system architecture. For example, the network elements may include an access and mobility management function (access and mobility management function, AMF) entity, a mobility management entity (mobility management entity, MME), a mobile switching center (mobile switching center, MSC) entity, a session management function (session management function, SMF) entity, a unified data management (unified data management, UDM) entity, a policy control function (policy control function, PCF) entity, a policy and charging rules function (policy and charging rule function, PCRF) entity, a packet data network (packet data network, PDN), a packet data unit (packet data unit, PDU), a control plane gateway (PDN gateway-control plane, PGW-C), a user plane gateway (PDN gateway-user plane, PGW-U), a home subscriber server (home Subscriber Server, HSS), an application function (application function, AF) entity, and the like.

The following describes an application environment of the embodiments of this application with reference to <FIG> are respectively schematic diagrams of possible system architectures <NUM> to <NUM> in the embodiments of this application. <FIG> shows a communications system <NUM> applied in an embodiment of this application. <FIG> is a communication architecture diagram of handover of a voice service in a <NUM> system when there is a direct interface between an AMF entity and a mobile switching center (mobile switching center, MSC) entity in a <NUM> network. <FIG> is a communication architecture diagram of handover of a voice service in a <NUM> system when there is no direct interface between an AMF entity and an MSC entity.

<FIG> shows the communications system <NUM> applied in the embodiment of this application. The communications system <NUM> may include at least one terminal <NUM>, an access network device <NUM>, and a core network device <NUM>. In some possible designs, a plurality of terminals <NUM> may be grouped based on a service feature. The access network device <NUM> may be a device that communicates with the terminal <NUM>, for example, a base station or a base station controller. The core network device <NUM> has functions of providing a connection for a terminal, managing a terminal, and bearing a service, and serves as a bearer network to provide an interface for an external network.

<FIG> is a communication architecture diagram of handover of a voice service in a <NUM> system when there is a direct interface between an AMF entity and an MSC entity. The AMF entity is configured to provide access and mobility management of a user, mainly including registration management, reachability management, mobility management, paging management, access authentication and authorization, encryption and integrity protection on non-access stratum signaling, and the like of the user.

As shown in <FIG>, there is a direct interface between the AMF entity and the MSC entity. If a terminal supports SRVCC, when the terminal performs a voice service in the fifth generation communications system, the voice service may be directly handed over from the <NUM> network to a <NUM> network after the terminal moves out of coverage of the <NUM> network, to ensure continuity of the voice service.

<FIG> is a communication architecture diagram of handover of a voice service in a <NUM> system when there is no direct interface between an AMF entity and an MSC entity.

As shown in <FIG>, there is no direct interface between the AMF entity and the MSC entity. If a terminal supports SRVCC, when the terminal performs a voice service in a fifth generation communications system, the voice service needs to be forwarded via an MME entity after the terminal moves out of coverage of the <NUM> network, so that the voice service is handed over to a <NUM> network.

The MME entity is used for mobility management of a user. For example, the mobility management of the user mainly includes attach management, reachability management, mobility management, paging management, access authentication and authorization, encryption and integrity protection on non-access stratum signaling, and the like of the user.

Alternatively, if the terminal in a <NUM> NR network does not support SRVCC to a CS domain of a <NUM> network, when the terminal performs a voice service in a fifth generation communications system, the voice service of the <NUM> network needs to be first handed over to an LTE network and then the voice service is handed over from the LTE network to the <NUM> network after the terminal moves out of coverage of the <NUM> network. In other words, the MME entity forwards the voice service during voice service handover, so that the voice service is handed over from the <NUM> network to the <NUM> network, to ensure continuity of the voice service.

In the embodiments of this application, based on different architectures between the AMF entity in the <NUM> system and the MSC entity in the <NUM> system, a communication method is proposed. According to the communication method, a voice service may be handed over between the <NUM> system and the <NUM> system based on a network requirement, to ensure continuity of the voice service, and improve user experience.

Based on the foregoing scenario descriptions, this application provides an implementation of deriving key information, which is applicable to all the foregoing scenarios of this application. The key information is used to perform encryption, or integrity protection, or encryption and integrity protection on the CS domain of the <NUM> network.

In the embodiments of this application, the AMF entity may first derive key information of a <NUM> network, then derive key information of the <NUM> network based on the key information of the <NUM> network, and send the derived key information of the <NUM> network to the MME entity or the MSC entity.

It may be understood that, in the embodiments of this application, deriving a key or key derivation means obtaining a key based on an input parameter.

An input parameter for deriving the key information of the <NUM> network based on root key of the <NUM> network includes at least one of the following parameters: a first FC, a second FC, a first downlink non-access stratum count, a second downlink non-access stratum count, a second preset value, a first preset value, a first random number, or a second random number. The key information of the <NUM> network may be KASME, or may be key information derived based on CK∥IK.

It should be noted that, in the embodiments of this application, a function code (function code, FC) may be understood as an input parameter used based on a different function when the key information is derived.

The first FC may be function code used when the key information of the <NUM> network is derived based on the root key of the <NUM> network, the second FC may be function code used when the key information of the <NUM> network is derived based on the root key of the <NUM> network, and the third FC may be function code used when the key information of the <NUM> network is derived based on a root key of the <NUM> network. A non-access stratum count includes a sequence number and an overflow counter, and the non-access stratum count may be an uplink non-access stratum count or a downlink non-access stratum count. In the embodiments of this application, a derivation parameter may be a downlink non-access stratum count, or may be an uplink non-access stratum count. The first downlink non-access stratum count may be a downlink non-access stratum count used when the key information of the <NUM> network is derived based on the root key of the <NUM> network, and the second downlink non-access stratum count may be a downlink non-access stratum count used when the key information of the <NUM> network is derived based on the root key of the <NUM> network. KASME is key information generated after the terminal and the network complete authentication.

An input parameter for deriving a a key of the <NUM> network based on the derived key information of the <NUM> network includes at least one of the following parameters: the first FC, the second FC, the third FC, the first downlink non-access stratum count, the second downlink non-access stratum count, a third downlink non-access stratum count, a third preset value, the second preset value, the first preset value, the first random number, the second random number, or a third random number.

For example, the first FC, the first downlink non-access stratum count, the first random number, or the first preset value may be used by the AMF entity to derive the key information of the <NUM> network based on the root key of the <NUM> network.

For example, the second FC, the second downlink non-access stratum count, the second random number, or the second preset value may be used by the AMF entity to derive the key information of the <NUM> network based on the root key of the <NUM> network.

For example, the third FC, the third downlink non-access stratum count, the third random number, or the third preset value may be used by the AMF entity to derive the key information of the <NUM> network based on the root key of the <NUM> network.

It should be noted that, in the implementations of this application, the key derivation parameters used to derive the key information are not limited to the key derivation parameters of the <NUM> network or the <NUM> network in this application. Alternatively, key derivation may be performed based on another parameter in combination with the derivation parameters in this application. Alternatively, key derivation may be performed based on some of the key derivation parameters that are used to derive the <NUM> network or the <NUM> network and that are proposed in this application.

Optionally, the <NUM> network is used to forward the handover request message generated by the AMF entity.

In an optional implementation, the message includes an information field for indicating to hand over the voice service of the terminal from the packet switched PS domain to the circuit switched CS domain, and the information filed is a transparent container for the MME entity. The key information of the <NUM> network is carried in this field. In this case, the message is a request message that is reused by the AMF entity and for handing over the voice service to the <NUM> system, and an information element is added to the message to carry the information. In this implementation, the MME entity is slightly affected, and requires only identification and forwarding.

In an optional implementation, the AMF entity and the MME entity define a message, which is used to send a message generated by the AMF entity. The message is used to request handover of the voice service of the terminal from the packet switched PS domain to the circuit switched CS domain. In this implementation, a new message needs to be defined, and the request message sent by the AMF entity for handover to the <NUM> network is not affected.

After receiving the message or the information, the MME entity forwards the message or the information to a default or pre-configured anchor MSC device, or an anchor MSC device indicated in the message.

A communication method in an embodiment of this application is described below with reference to <FIG>. The method <NUM> in <FIG> may be applied to any architecture in <FIG>. Alternatively, the method in <FIG> may also be applied to another similar architecture. An access and mobility management function AMF entity may be a core network device in a <NUM> network or a core network device in another network. The access network device may be a base station in the <NUM> network, for example, a gNB. This is not limited in the embodiments of this application. The method <NUM> includes the following steps.

Step <NUM>: The access and mobility management function AMF entity receives a first message from an access network device, where the first message includes information for indicating to hand over a voice service of a terminal from a packet switched PS domain to a circuit switched CS domain, the first message further includes identification information of a target device, and the target device is an access network device in a <NUM> network and/or a <NUM> network.

In some examples, the first message may include identification information of the <NUM> network. Alternatively, the first message may include identification information of the <NUM> network. Alternatively, the first message includes identification information of the <NUM> network and identification information of the <NUM> network.

Before step <NUM>, the access network device sends the first message to the AMF entity based on a factor such as a measurement report reported by the terminal or load of the access network device. The first message is used to request the access network device to hand over a voice service of a <NUM> system from the PS domain to a CS domain of a <NUM>/<NUM> system.

Step <NUM>: The AMF entity derives key information of a network in which the target device is located.

In this embodiment of this application, the key information includes key information of the <NUM> network and key information of the <NUM> network. In an example useful for understanding the application a manner in which the AMF entity derives the key information of the network in which the target device is located and sends the key information to an MSC entity in the <NUM> network includes but is not limited to any one of the following manners:.

In this embodiment of this application, a manner in which the AMF entity determines key derivation parameters of the <NUM> network and derives the key information of the <NUM> network based on the key derivation parameters of the <NUM> network and a root key of a network in which the AMF entity is located includes but is not limited to the following derivation manners:
For example, the AMF entity derives the key information of the <NUM> network based on a first FC, a first downlink non-access stratum count, and the root key of the network in which the AMF entity is located.

For example, the AMF entity derives the key information of the <NUM> network based on a first FC, a preset value, and the root key of the network in which the AMF entity is located.

It should be understood that the preset value may be a preset value that is configured in advance and maintained by both the terminal and the AMF entity.

For example, the AMF entity derives the key information of the <NUM> network based on a first FC, a random number, and the root key of the network in which the AMF entity is located.

It should be understood that the random number may be a parameter known to the AMF entity, and the AMF entity sends the parameter to the terminal.

In this embodiment of this application, the root key of the network in which the AMF entity is located may be any one of KAMF, KSEAF, KAUSF, and a cipher key CK+an integrity key IK.

In this embodiment of this application, a manner in which the AMF entity determines key derivation parameters of the <NUM> network and derives the key information of the <NUM> network based on the key derivation parameters of the <NUM> network and a root key of a network in which the AMF entity is located includes but is not limited to the following derivation manners:.

It should be noted that in this embodiment of this application, the preset value for deriving a key of the <NUM> network is the same as or different from the preset value for deriving a key of <NUM>. The random number for deriving the key of the <NUM> network is the same as or different from the random number for deriving the <NUM> parameter. This is not limited in this application.

In this embodiment of this application, a manner in which the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network includes but is not limited to the following derivation manners:.

In this embodiment of this application, that the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network includes:.

It should be noted that the key derivation parameters used to derive the key information of the <NUM> network based on the key information of the <NUM> network may be the same as the key derivation parameters used to derive the key information of the <NUM> network, or may be different from the key derivation parameters used to derive the key information of the <NUM> network. The key derivation parameters include parameters such as the first FC, the second FC, the third FC, the first downlink non-access stratum value, the second downlink non-access stratum value, the preset value, and the random number.

It should be noted that, in the implementations of this application, the key derivation parameters used to derive the key information are not limited to the key derivation parameters of the <NUM> network or the <NUM> network in this application. Alternatively, key derivation may be performed based on another parameter in combination with the derivation parameters in this application. Alternatively, key derivation may be performed based on some of the key derivation parameters that are used to derive the <NUM> network or the <NUM> network and in this application.

Optionally, after step <NUM>, the method <NUM> further includes the following steps:.

Optionally, after the second message is sent, the method <NUM> further includes the following step:
The AMF entity sends configuration information to the terminal, where the configuration information includes information indicating a network to which the terminal preferentially falls back when a call of the voice service ends in the CS domain.

For example, after the terminal completes handover of the voice service from the PS domain to the CS domain, when the call of the voice service ends in the CS domain, the terminal may fall back to the <NUM> network or fall back to the <NUM> network based on the configuration information, to perform the non-voice service.

In this embodiment of this application, the terminal processes the voice service or the non-voice service of the terminal according to a received handover instruction sent by the access network device, and hands over the voice service from a bearer in the PS domain to a bearer in the CS domain, to ensure continuity of the voice service and improve user experience.

Specific examples useful for understanding the communication method in the embodiments of this application are described below with reference to <FIG>. The examples include a communication method for handing over a voice service of a terminal from a bearer in a PS domain of a <NUM> network to a bearer in a CS domain of a <NUM> network in the following scenarios: The terminal supports handover of the voice service from the <NUM> network to the <NUM> network, and there is an interface between an AMF entity and an MSC entity; the terminal supports handover of the voice service from the <NUM> network to the <NUM> network, and there is no interface between an AMF entity and an MSC entity; the terminal does not support handover of the voice service from the <NUM> network to the <NUM> network. It should be understood that this application is described by using the foregoing three scenarios as examples for description, and this application is not limited thereto.

Referring to <FIG> and <FIG>, a method in <FIG> and <FIG> may be applied to the architecture <NUM>. The method in <FIG> and <FIG> includes the following steps.

S501: A terminal reports, to an AMF entity, support for handover of a voice service from a <NUM> network to a <NUM> network. In other words, in the <NUM> network, the terminal supports SRVCC to a bearer in a CS domain of the <NUM> network.

S502: The AMF entity notifies a gNB that the terminal supports SRVCC to the bearer in the CS domain of the <NUM> network.

S503: The terminal sends a measurement report to the gNB.

S504: The gNB determines, based on a factor such as the measurement report or current load, to initiate, to the AMF entity, a handover request for handing over the voice service to a CS domain of a <NUM> network, where the handover request message includes an identifier of a target device to which the voice service is handed over, for example, an identifier of a radio network controller (radio network controller, RNC) entity.

It should be understood that in this example, the handover request message sent by the gNB to the AMF entity may be the first message in the method <NUM>.

S505: The AMF entity determines to hand over the voice service to the bearer in the CS domain of the <NUM> network, and the AMF entity derives key information of the <NUM> network, where the key information is used to perform encryption, or integrity protection, or encryption and integrity protection on the CS domain of the <NUM> network.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on a first FC, a first downlink non-access stratum count, and a root key of a network in which the AMF entity is located.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on a first FC, a preset value, and a root key of a network in which the AMF entity is located.

It should be noted that the preset value may be a preset value that is configured in advance and maintained by both the terminal and the AMF entity.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on a first FC, a random number, and a root key of a network in which the AMF entity is located.

It should be noted that the random number may be a parameter known to the AMF entity, and the AMF entity sends the parameter to the terminal.

In the foregoing examples, the root key of the network in which the AMF entity is located may be any one of KAMF, KSEAF, KAUSF, and a cipher key CK+an integrity key IK.

For example, in an optional derivation manner, the AMF entity derives the key information of the <NUM> network based on the root key and a derivation parameter. The key information of the <NUM> network includes the cipher key CK and the integrity key IK. The derivation parameter may be one of the first downlink non-access stratum count, the random number, or the preset value, that is, KAMF->>KASME->>CS domain CK IK.

For example, in an optional derivation manner, the AMF entity directly uses the root key CK+IK.

It should be understood that the foregoing examples are provided for description, and do not limit the embodiments of this application.

S506: The AMF entity sends, to an MSC entity in the <NUM> network, the handover request message for handing over the voice service from a PS domain to the CS domain. The handover request message includes the key information of the <NUM> network derived by the AMF entity.

S507: The MSC entity in the <NUM> network sends a migration request message of the voice service to a radio network controller (Radio Network Controller, RNC) of the <NUM> network, where the migration request message includes the key information of the <NUM> network derived by the AMF entity.

S508: The RNC sends a migration request acknowledgment message to the MSC entity, where the migration request acknowledgment message includes a radio resource configuration parameter allocated by the RNC to the terminal.

S509: The MSC entity initiates voice session transfer information to an IP multimedia subsystem (IP multimedia subsystem, IMS) entity, and the IMS entity updates a voice session and a user plane bearer based on the message.

S510: The MSC entity sends, to the AMF entity, a handover request response for handing over the voice service from the PS domain to the CS domain, where the handover request response includes the radio resource configuration parameter that is allocated by the RNC to the terminal and that is received by the MSC entity.

S511: The AMF entity sends a handover request acknowledgment message to the gNB, where the handover request acknowledgment message includes the radio resource configuration parameter allocated by the RNC to the terminal and key derivation parameters that are used to derive the key information of the <NUM> network and that are determined by the AMF entity.

S512: The gNB sends, to the terminal, a handover instruction for handing over the voice service from the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network, where the handover instruction includes the key derivation parameters used to derive the key information of the <NUM> network, and the key derivation parameters are determined by the AMF entity.

S513: The terminal receives the handover instruction including the key derivation parameters, derives the key information of the <NUM> network based on the key derivation parameters and a root key of the <NUM> network, and indicates s, according to the received handover instruction, an upper layer of the terminal to suspend or release a PDN session of a non-voice service.

It should be noted that in this example, the terminal receives a third message sent by the base station gNB of the <NUM> network. For example, the terminal receives the handover instruction sent by the base station gNB of the <NUM> network. When the third message is information for indicating the terminal to hand over the voice service from the packet switched PS domain to the circuit switched CS domain, the terminal determines, according to the third message, to suspend or release the PDN session of the non-voice service.

It should be understood that in this example, the third message may be the handover instruction sent by the base station, such as the gNB, in the <NUM> network. Alternatively, the third message may be a handover instruction sent by a base station, such as an eNB, in a <NUM> network. This is not limited in this example of this application.

S514: The terminal accesses the <NUM> network, and sends a handover complete message to the RNC. The message indicates that the terminal has completed handover of the voice service from the bearer in the PS domain to the bearer in the CS domain.

S515: The RNC sends the handover complete message to the MSC entity, to notify the MSC entity that the terminal has completed handover of the voice service from the bearer in the PS domain to the bearer in the CS domain.

S516: The MSC entity sends the handover complete message to the AMF entity.

It should be understood that the handover complete message sent by the MSC entity to the AMF entity may be the second message in the method <NUM>.

S517: After receiving the handover complete message sent by the MSC entity, the AMF entity indicates an SMF entity to suspend or release the PDN session of the non-voice service.

Specifically, the AMF entity indicates the SMF entity to suspend or release the PDN session of the non-voice service, and the SMF entity suspends or releases the PDN session of the non-voice service or of a non-GBR bearer via a user port function (user port function, UPF) entity. The SMF entity indicates the UPF entity to suspend or release all PDN sessions of the terminal.

Optionally, the AMF entity indicates the SMF entity to suspend or release all PDN sessions of the terminal.

S518: The AMF entity sends, to the base station gNB of the <NUM> network, indication information for releasing a resource.

It should be noted that the method <NUM> is the communication method for handing over the voice service of the terminal from the bearer in the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network when the terminal supports handover of the voice service from the <NUM> network to the <NUM> network, and there is an interface between the AMF entity and the MSC entity.

When the terminal supports handover of the voice service from the <NUM> network to the <NUM> network, and there is no interface between the AMF entity and the MSC entity, because there is no direct interface between the AMF entity and the MSC entity, the AMF entity needs to perform a transfer operation via an anchor MME entity, to hand over the voice service of the terminal from the bearer in the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network.

In an embodiment, in step S506, there is no interface between the AMF entity and the MSC entity, the AMF entity sends, to the MME entity, the handover request message for handing over the voice service from the PS domain to the CS domain. The handover request message includes the key information of the <NUM> network derived by the AMF entity and identification information of the target base station of the voice service, for example, an RNC ID. The MME entity sends the handover request message to the MSC entity.

In this embodiment of this application, the AMF entity directly derives the key information of the <NUM> network, and send the derived key information of the <NUM> network to the MME entity or the MSC entity.

For example, the AMF entity derives the key information of the <NUM> network based on the first FC, the first downlink non-access stratum count, and the root key of the network in which the AMF entity is located.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on the first FC, the preset value, and the root key of the network in which the AMF entity is located.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on the first FC, the random number, and the root key of the network in which the AMF entity is located.

In this embodiment of this application, the AMF entity may first derive key information of a <NUM> network, then derive key information of the <NUM> network based on the key information of the <NUM> network, and send the derived key information of the <NUM> network to the MME entity or the MSC entity.

An input parameter for deriving the key information of the <NUM> network based on root key of the <NUM> network includes at least one of the following parameters: the first FC, a second FC, the first downlink non-access stratum count, a second downlink non-access stratum count, a second preset value, a first preset value, a first random number, or a second random number. The key information of the <NUM> network may be KASME, or may be key information derived based on CK∥IK.

An input parameter for deriving a <NUM> key based on the derived key information of the <NUM> network includes at least one of the following parameters: the first FC, the second FC, a third FC, the first downlink non-access stratum count, the second downlink non-access stratum count, a third downlink non-access stratum count, a third preset value, the second preset value, the first preset value, the first random number, the second random number, or a third random number.

Referring to <FIG> and <FIG>, a method in <FIG> and <FIG> may be applied to the architecture <NUM>. The method in <FIG> and <FIG> is a communication method for handing over a voice service of a terminal from a bearer in a PS domain of a <NUM> network to a bearer in CS domain of a <NUM> network when the terminal does not support handover of the voice service from the <NUM> network to the <NUM> network. The method in <FIG> and <FIG> includes the following steps.

S601: The terminal sends a measurement report to a gNB.

S602: The gNB determines, based on a factor such as the measurement report or current load, to initiate, to an AMF entity, a handover request message for handing over the voice service to a <NUM> CS domain.

S603: Because the terminal does not support handover of the voice service from the <NUM> network to the <NUM> network, the AMF entity determines to hand over a non-voice service or a non-GBR bearer to a <NUM> network, and the AMF entity derives key information.

It should be noted that in this example, the AMF entity may directly derive key information of the <NUM> network. Alternatively, the AMF entity may first derive key information of the <NUM> network, and then derive key information of the <NUM> network based on the key information of the <NUM> network.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network.

A manner in which the AMF entity determines key derivation parameters of the <NUM> network and derives the key information of the <NUM> network based on the key derivation parameters of the <NUM> network and a root key of a network in which the AMF entity is located includes but is not limited to the following manners:.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on a first FC, a random number, and the root key of the network in which the AMF entity is located.

For example, in an optional derivation manner, the AMF entity derives the key information of the <NUM> network based on the root key and a derivation parameter. The key information of the <NUM> network includes the cipher key CK and the integrity key IK. The derivation parameter may be one of the first downlink non-access stratum count, the random number, or the preset value, that is, KAMF->>KASME->>CS domain CK+IK.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network and the key information of the <NUM> network.

A manner in which the AMF entity determines key derivation parameters of the <NUM> network and derives the key information of the <NUM> network based on the key derivation parameters of the <NUM> network and the root key of the network in which the AMF entity is located includes but is not limited to the following manners:.

The root key of the network in which the AMF entity is located is any one of KAMF, KSEAF, KAUSF, and a cipher key CK+an integrity key IK. Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on the derived key information of the <NUM> network.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a first FC, and a second downlink non-access stratum count.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a second FC, and a second downlink non-access stratum count.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a second FC, and a preset value.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a second FC, and a random number.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network based on the derived key information of the <NUM> network.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a third FC, and a second downlink non-access stratum count.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a third FC, and a preset value.

For example, the AMF entity derives the key information of the <NUM> network based on the key information of the <NUM> network, a third FC, and a random number.

It should be noted that the key derivation parameters used to derive the key information of the <NUM> network based on the key information of the <NUM> network may be the same as the key derivation parameters used to derive the key information of the <NUM> network, or may be different from the key derivation parameters used to derive the key information of the <NUM> network. The key derivation parameters include parameters such as the first FC, the second FC, the first downlink non-access stratum value, the second downlink non-access stratum value, the preset value, and the random number. It should be noted that, in the implementations of this application, the key derivation parameters used to derive the key information are not limited to the key derivation parameters of the <NUM> network or the <NUM> network in this application. Alternatively, key derivation may be performed based on another parameter in combination with the derivation parameters in this application. Alternatively, key derivation may be performed based on some of the key derivation parameters that are used to derive the <NUM> network or the <NUM> network and that are proposed in this application.

Optionally, in an example, the AMF entity derives the key information of the <NUM> network, for example, KASME.

S604: Because the terminal does not support handover of the voice service from the <NUM> network to the <NUM> network, the AMF entity sends a handover instruction to an MME entity, where the handover instruction instructs handover of the non-voice service of the terminal from the bearer in the PS domain to the <NUM> network.

S605: The MME entity sends the handover instruction to a base station eNB of the <NUM> network, where the instruction is used to indicates the eNB to establish a default RB or a bearer with QCI=<NUM>.

S606: The base station eNB of the <NUM> network sends a handover instruction response to the MME entity, where the handover instruction response indicates that the eNB prepares a target eNB to source eNB container.

S607: The MME entity sends the handover instruction response to the AMF entity.

S608: The AMF entity sends a handover request acknowledgment message to the gNB of the <NUM> network, where the handover request acknowledgment message includes information for indicating to hand over the non-voice service or the non-GBR bearer from the PS domain to the <NUM> network.

S609: The gNB of the <NUM> network sends a handover instruction to the terminal, where the handover instruction instructs handover of the voice service from the PS domain to the <NUM> network.

S610: After receiving the instruction for handing over the non-voice service from the PS domain to the <NUM> network, the terminal determines to suspend a bearer of the voice service, suspend a GBR bearer, or suspend a bearer with QCI=<NUM>.

It should be noted that in this example, the terminal receives a third message sent by the base station gNB of the <NUM> network. For example, the terminal receives the handover instruction sent by the base station gNB of the <NUM> network. When the third message is the information for indicating the terminal to hand over the non-voice service to the <NUM> network, the terminal determines, based on the third message, to suspend the bearer of the voice service or suspend the bearer with QCI=<NUM>.

S611: The terminal sends a handover complete message of the non-voice service to the base station eNB of the <NUM> network.

S612: The MME entity sends, to the MSC entity, the handover complete message for handing over the non-voice service from the PS domain to the <NUM> network.

Optionally, after receiving a request sent by the eNB for handing over the voice service from the PS domain to the CS domain of the <NUM> network, the MME initiates S612.

Optionally, after receiving the handover complete message sent by the eNB, the MME initiates S612.

S613: The MME entity sends, to the MSC entity, a handover request message for handing over the voice service from the bearer in the PS domain to the bearer in the CS domain, where the handover request message may include the key information of the <NUM> network derived by the AMF entity.

Optionally, the handover request message may be generated by the AMF entity.

Optionally, the MME extracts the cipher key and the integrity protection key of the <NUM> network from the key information sent by the AMF entity.

S614: The MSC entity sends a migration request message of the voice service to an RNC, where the migration request message includes the key information of the <NUM> network derived by the AMF entity.

S615: The RNC sends a migration request acknowledgment message to the MSC entity, where the migration request acknowledgment message includes a radio resource configuration parameter allocated by the RNC to the terminal.

S616: The MSC entity initiates voice session transfer information to an IMS entity, and the IMS entity updates a voice session and a user plane bearer based on the message.

S617: The MSC entity sends, to the MME entity, a handover request response for handing over the voice service from the PS domain to the CS domain.

S618: The MME entity sends a handover instruction to the gNB, where the handover instruction includes key derivation parameters determined by the AMF entity.

S619: The gNB sends, to the terminal, the handover instruction for handing over the voice service from the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network, where the handover instruction includes the key derivation parameters used to derive the key information of the <NUM> network, and the key derivation parameters are determined by the AMF entity.

S620: The terminal receives the handover instruction including the key derivation parameters, and derives the key information of the <NUM> network based on the key derivation parameters and a root key of the <NUM> network.

S621: The terminal accesses the <NUM> network, and sends a handover complete message to the RNC. The message indicates that the terminal has completed handover of the voice service from the bearer in the PS domain to the bearer in the CS domain.

S622: The RNC sends a migration complete message to the MSC entity, to notify the MSC entity that the terminal has completed handover of the voice service from the bearer in the PS domain to the bearer in the CS domain.

S623: The MSC entity sends, to the MME entity, the handover complete message for handing over the voice service from the bearer in the PS domain to the bearer in the CS domain.

S624: The MME entity sends the handover complete message to the AMF entity.

S625: The AMF entity receives the handover complete message sent by the MME entity.

S626: The AMF entity sends, to the base station gNB of the <NUM> network, indication information for releasing a resource.

Optionally, the AMF entity indicatess the SMF to release or suspend a PDN session of a non-voice bearer or of a non-GBR.

Optionally, the AMF entity indicates the SMF to release or suspend PDN sessions of all bearers.

It should be noted that the method <NUM> may be the communication method for handing over the voice service of the terminal from the bearer in the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network when the terminal does not support handover of the voice service from the <NUM> network to the <NUM> network.

<FIG> describe the communication methods used in a <NUM> communications system and used for handing over the voice service from the bearer in the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network to maintain continuity of the voice service after the terminal performing the voice service moves out of coverage of the <NUM> network.

An embodiment of this application further provides a communication method for fast fallback. In the communication method, after a voice service is handed from a bearer in a PS domain to a bearer in a CS domain, when a call of the voice service ends in a <NUM> network, a terminal rapidly falls back to a proper network, and restores the service of the bearer that is in the PS domain and suspended during voice handover.

Optionally, in an example, after the call of the voice service of the terminal ends in the <NUM> network, a core network device notifies an RNC, and the RNC indicates UE.

Step <NUM>: An AMF entity or an MME entity sends a handover request message to an MSC entity. The handover request message includes handover information indicating that the handover is from an NR node or the MME entity. It should be understood that in this embodiment of this application, this step is optional.

Step <NUM>: The MSC entity sends the handover information to an RNC. The information is used to indicate the handover from the NR node or the MME entity to the RNC. The MSC entity may determine, based on a type of a source node in the handover request message, whether the source node is an MME entity or an NR node.

Step <NUM>: When Iu is released, the MSC entity indicates to the RNC that the terminal is handed over from the NR node or the MME entity. The RNC determines to release a connection of the terminal on the RNC.

For example, connection release information is sent to the terminal to indicate frequency information of LTE or NR. After receiving the information, the terminal first measures the indicated ARFCN of a radio access system, and performs a cell reselection process. The terminal first measures the indicated ARFCN, and then reselects to a cell having an ARFCN that meets an R criteria.

The R criterion means that Rs of a serving cell and Rt of a target cell respectively meet: Rs=Qmeas,s+QHyst and Rt=Qmeas,t-Qoffset. Qmeas is an RSRP value of a measured cell, and Qoffset defines an offset value of the target cell. For inter-frequency cells having a same priority, two parts are included: a cell-based offset value and a frequency-based offset value. If Rt is always greater than Rs within a time Treselection (where Treselection of an intra-frequency cell may be different from that of the inter-frequency cell), the terminal reselects to a target cell.

Optionally, in an example, the AMF entity or the MME entity sends configuration information to the terminal. The configuration information includes information indicating a network to which the terminal preferentially falls back when the call of the voice service ends in the CS domain.

It should be understood that the configuration information may be information configured before the voice service is handed over, and is used to indicate the terminal to preferentially fall back to NR or LTE after the terminal is handed over from NR or LTE to the <NUM> network and an air interface connection is released.

For example, when preferentially falling back to NR, the terminal first measures an NR-ARFCN, and reselects to an NR cell that meets the R criteria. If no suitable NR cell is available, the terminal reselects to a suitable LTE cell.

For example, when preferentially falling back to LTE, the terminal first measures an LTE-ARFCN, and reselects to an LTE cell that meets the R criteria. If no suitable LTE cell is available, the terminal reselects to a suitable NR cell.

It should be noted that the communication method for fast fallback may be combined with the communication methods that are used for handing over the voice service from the bearer in the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network and that are described in <FIG>. This is not limited in the embodiments of this application.

The execution sequences of the processes should be determined based on functions and internal logic of the processes, and should not constitute any limitation on the implementation processes of the embodiments of this application.

It may be understood that, in the foregoing embodiments, steps or operations implemented by the terminal may alternatively be implemented by a component (for example, a chip or a circuit) that may be used in the terminal, and steps or operations implemented by the access network device may alternatively be implemented by a component (for example, a chip or a circuit) that may be used in the access network device.

The foregoing describes in detail the communication methods for handing over the voice service from the bearer in the PS domain of the <NUM> network to the bearer in the CS domain of the <NUM> network in different scenarios according to the embodiments of this application. The following describes a communications apparatus according to the embodiments of this application. It should be understood that the communications apparatus in the embodiments of this application may perform the various communication methods in the foregoing embodiments of this application. In other words, for specific working processes of the following products, refer to corresponding processes in the foregoing method embodiments.

<FIG> is a schematic structural diagram of a communications apparatus according to an embodiment of this application. The communications apparatus <NUM> in <FIG> may correspondingly implement steps or operations performed by the AMF entity in the foregoing descriptions, and may include:.

In this embodiment of this application, the communications apparatus determines, based on an identifier of the target device in a handover request message of the voice service, the network to which the voice service is to be handed over, to derive the key information of the network in which the target device is located, ensuring that the voice service is handed over from a bearer in the PS domain to the network in which the target device is located, ensuring continuity of the voice service, and improving user experience.

Optionally, the processing module <NUM> is specifically configured to:.

Optionally, the root key is any one of KAMF, KSEAF, KAUSF, and a cipher key CK+an integrity key IK.

Optionally, the communications module <NUM> is further configured to:.

Optionally, the communications module <NUM> is further configured to receive a second message, where the second message includes information indicating that handover of the voice service from the PS domain to the CS domain is complete.

When the communications module <NUM> receives the second message, the processing module <NUM> is further configured to determine, based on the second message, to suspend or release a PDN session of a non-voice service.

Optionally, the communications module <NUM> is further configured to send configuration information, where the configuration information includes information indicating a network to which the terminal preferentially falls back when a call of the voice service ends in the CS domain.

Optionally, the communications apparatus <NUM> may be a core network device in a <NUM> communications system, and the communications apparatus may be configured to hand over the voice service of the terminal from a bearer in the PS domain to a bearer in the CS domain.

It may be understood that, for implementations, interaction, and the like of the modules in the communications apparatus <NUM> in this embodiment of this application, refer to related descriptions in the method embodiments.

<FIG> is a schematic structural diagram of a communications apparatus according to an example useful for understanding of this application. The communications apparatus <NUM> in <FIG> may correspond to the terminal in the foregoing embodiments and examples, and may include:.

In this example useful for understanding of this application, the communications apparatus processes the voice service or the non-voice service based on a received handover request message, to hand over the voice service from a bearer in the PS domain to a bearer in the CS domain, ensuring continuity of the voice service, and improving user experience.

Optionally, the third message further includes key derivation parameters, and the key derivation parameters are determined by an access and mobility management function AMF entity.

Optionally, the processing module <NUM> is further configured to:.

Optionally, the processing module <NUM> is further configured to:
derive the key information of the <NUM> network based on the key information of the <NUM> network.

Optionally, the communications module <NUM> is further configured to receive configuration information, where the configuration information includes information indicating a network to which the terminal preferentially falls back when a call of the voice service ends in the CS domain.

It may be understood that, for implementations, interaction, and the like of the modules in the communications apparatus <NUM> in this example, refer to related descriptions in the method embodiments and examples.

<FIG> is a schematic structural diagram of a communications apparatus according to an embodiment of this application. The communications apparatus <NUM> in <FIG> may correspond to the base station in the foregoing <NUM> communications system, for example, the gNB, and may include:.

In the technical solution of this embodiment of this application, the communications apparatus generates the third message, and sends the third message to the terminal. The terminal indicates, according to the indication information included in the third message, to suspend the voice service or the non-voice service, to ensure that the voice service is handed over from a bearer in the PS domain to a bearer in the CS domain, ensuring continuity of the voice service, and improving user experience.

Optionally, the third message includes key derivation parameters of a network in which the target device is located, and the key derivation parameters are determined by the AMF entity.

It may be understood that all modules in the communications apparatus <NUM>, the communications apparatus <NUM>, and the communications apparatus <NUM> may be separately disposed, or may be integrated together. The foregoing modules may also be referred to as components or circuits.

It may be understood that the communications apparatus <NUM>, the communications apparatus <NUM>, or the communications apparatus <NUM> may be implemented by using at least one processor, or may be implemented by using at least one processor and at least one memory, or may be implemented by using at least one processor and at least one transceiver, or may be implemented by using at least one processor, at least one transceiver, and at least one memory. The processor, the transceiver, and the memory may be disposed separately, or may be integrated together.

<FIG> is a schematic structural diagram of a communications apparatus. The communications apparatus <NUM> may be configured to implement a method that corresponds to the AMF entity and is described in the foregoing method embodiments and examples, or may be configured to implement a method that corresponds to the terminal and is described in the foregoing method embodiments and examples, or may be configured to implement a method that corresponds to the access network device such as the gNB and is described in the foregoing method embodiments and examples. For details, refer to the descriptions in the foregoing method embodiments and examples.

The communications apparatus <NUM> may include one or more processors <NUM>. The processor <NUM> may also be referred to as a processing unit, and may implement a specific control function. The processor <NUM> may be a general-purpose processor, a dedicated processor, or the like.

In an optional design, a memory <NUM> may store an instruction <NUM>. The instruction <NUM> may be run by the processor <NUM>, so that the communications apparatus <NUM> performs the method that corresponds to the AMF entity, the terminal, or the access network device and that is described in the foregoing method embodiments and examples.

In another possible design, the communications apparatus <NUM> may include a circuit. The circuit may implement the sending, receiving, or communication function in the foregoing method embodiments and examples.

Optionally, the communications apparatus <NUM> may include one or more memories <NUM>. The memory stores an instruction <NUM> or intermediate data. The instruction <NUM> may be run on the processor <NUM>, so that the communications apparatus <NUM> performs the method that is performed by the AMF entity, the terminal, or the access network device and described in the foregoing embodiments and examples. Optionally, the memory may further store other related data. Optionally, the processor may also store an instruction and/or data. The processor and the memory may be disposed separately, or may be integrated together.

Optionally, the communications apparatus <NUM> may further include a transceiver <NUM>. The processor <NUM> may be referred to as a processing unit. The transceiver <NUM> may be referred to as a transceiver unit, a transceiver machine, a transceiver circuit, a transceiver, or the like, and is configured to implement a transceiver function of the communications apparatus.

In a design, the communications apparatus (for example, an integrated circuit, a wireless device, a circuit module, a network device, or a terminal device) may include a processor and a transceiver. If the communications apparatus is configured to implement steps or operations performed by the AMF entity in the embodiments corresponding to <FIG>, the transceiver <NUM> may receive a first message, where the first message includes information for indicating to hand over a voice service of a terminal from a packet switched PS domain to a circuit switched CS domain, the first message further includes identification information of a target device, and the target device is an access network device in a <NUM> network and/or a <NUM> network; and
the processor <NUM> is configured to derive key information of a network in which the target device is located.

Optionally, the processor <NUM> is further configured to:
derive the key information of the <NUM> network based on the key information of the <NUM> network.

For example, the processor <NUM> is configured to:.

Optionally, the transceiver <NUM> is further configured to:.

Optionally, the transceiver <NUM> is further configured to:
send configuration information, where the configuration information includes information indicating a network to which the terminal preferentially falls back when a call of the voice service ends in the CS domain.

In a design, the communications apparatus (for example, an integrated circuit, a wireless device, a circuit module, a network device, or a terminal device) may include a processor and a transceiver. If the communications apparatus is configured to implement steps or operations performed by the terminal in the examples corresponding to <FIG> and <FIG> or <FIG> and <FIG>, the transceiver <NUM> may receive a third message; and if the third message includes information for indicating to hand over a voice service from a packet switched PS domain to a circuit switched CS domain, determine, based on the third message, to suspend or release a PDN session of a non-voice service; or if the third message includes information for indicating to hand over a non-voice service to a <NUM> network, determine, based on the third message, to suspend a bearer of a voice service or suspend a bearer with QCI=<NUM>; and
the processor <NUM> is configured to derive key information of a network in which a target device is located, where the target device is an access network device in a <NUM> network and/or the <NUM> network.

Optionally, the transceiver <NUM> is further configured to:
receive configuration information, where the configuration information includes information indicating a network to which the terminal preferentially falls back when a call of the voice service ends in the CS domain.

In a design, the communications apparatus (for example, an integrated circuit, a wireless device, a circuit module, a network device, or a terminal device) may include a processor and a transceiver. If the communications apparatus is configured to implement the access network device in the embodiment corresponding to <FIG> or implement steps or operations performed by the gNB in the example corresponding to <FIG> and <FIG> and in the example corresponding to <FIG> and <FIG>, the processor <NUM> may generate a third message; and if the third message includes information for indicating to hand over the voice service from the PS domain to a CS domain, indicate a terminal to suspend or release a PDN session of a non-voice service; or if the third message includes information for indicating to hand over a non-voice service from the PS domain to a <NUM> network, indicate a terminal to suspend a bearer of a voice service or suspend a bearer with QCI=<NUM>; and
the transceiver <NUM> is configured to send the third message to the terminal.

The processor and the transceiver described in this application may be implemented on an integrated circuit (integrated circuit, IC), an analog IC, a radio frequency integrated circuit RFIC, a hybrid signal IC, an application-specific integrated circuit (ASIC), a printed circuit board (printed circuit board, PCB), an electronic device, or the like. The processor and the transceiver may also be manufactured by using various 1C technologies, for example, a complementary metal oxide semiconductor (complementary metal oxide semiconductor, CMOS), an N-channel metal-oxide-semiconductor (nMetal-oxide-semiconductor, NMOS), a P-channel metal-oxide-semiconductor (positive channel metal oxide semiconductor, PMOS), a bipolar junction transistor (bipolar junction transistor, BJT), a bipolar CMOS (BiCMOS), silicon germanium (SiGe), and gallium arsenide (GaAs).

In the descriptions of the foregoing embodiments, the communications apparatus <NUM> is described by using the AMF entity, the access network device, or the terminal as an example, but a scope of the communications apparatus described in this application is not limited to the AMF entity, the access network device, or the terminal, and a structure of the communications apparatus may not be limited by <FIG>. The communications apparatus may be an independent device or may be a part of a relatively large device. For example, the device may be:.

A person of ordinary skill in the art may be aware that, in combination with the units and algorithm steps in the examples described in the embodiments disclosed in this specification, this application may be implemented by using electronic hardware or a combination of electronic hardware and computer software. Whether the functions are performed by using hardware or software depends on particular applications and design constraint conditions of the technical solutions. A person skilled in the art may use a different method to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of this application.

It may be clearly understood by a person skilled in the art that, for the purpose of convenient and brief description, for detailed working processes of the foregoing system, apparatus, and unit, refer to corresponding processes in the foregoing method embodiments, and details are not described herein again.

For example, the described apparatus embodiments are merely examples. For example, division into the modules or units is merely logical function division and may be other division during actual implementation.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, in other words, may be located in one position, or may be distributed on a plurality of network units.

All or some of the foregoing embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, all or some of the embodiments may be implemented in a form of a computer program product. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and executed on a computer, the procedure or functions according to the embodiments of this application are all or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instruction may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, radio, or microwave) manner. The computer-readable storage medium may be any usable medium accessible by the computer, or a data storage device, such as a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a DVD), a semiconductor medium (for example, a solid-state drive (SSD)), or the like.

Claim 1:
A communication method, comprising:
receiving (S401), by an access and mobility management function, AMF, entity, a first message from a first access network device, wherein the first message comprises information for indicating to hand over a voice service of a terminal from a packet switched, PS, domain to a circuit switched, CS, domain, the first message further comprises identification information of a target device, and the target device is a second access network device in a <NUM> network; and
sending, by the AMF entity, through a mobility management entity, MME, a handover request message to a mobile switching center, MSC, entity, wherein the handover request message includes handover information indicating that the information for indicating to hand over a voice service of a terminal from a PS domain to a CS domain is from a new radio, NR, node.