Communication method and terminal device

Abstract

The embodiments of the present application relate to the technical field of electronic devices. Provided are a communication method and a terminal device. The method can be applied to an electronic device, such that a terminal can quickly access a high-standard network, and the terminal is prevented from residing in a low-standard network. The method may comprise a terminal device residing in a first network. The method comprises: receiving a first indication message; sending a first mobility update request, i.e., a TAU request; receiving a first TAU reject message, wherein the first TAU reject message indicates that a second network device for a second network rejects the access of a terminal to the second network, the cause value of the first TAU reject message is a first cause value, and the first cause value corresponds to the fact that the terminal initiates access to a third network and the network standard of the third network is lower than that of the second network; and sending a first initial registration request, wherein the first initial registration request is used for requesting attachment to the second network.

Description

A communication method and terminal device This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 30, 2023, with application number 202311641684.9 and invention name “A communication method and terminal device”, the entire contents of which are incorporated by reference in this application. Technical Field The embodiments of the present application relate to the technical field of electronic devices, and in particular, to a communication method and terminal equipment. Background Art The terminal device (referred to as the terminal) can communicate with networks of different standards to achieve communication functions. Among them, the networks of different standards may include 3G networks, 4G networks, or 5G networks. Take the case where the terminal resides in a 5G network. When the communication quality of the 5G network decreases, the network side can instruct the terminal to change to reside in the 4G network for communication. The terminal can try to change to reside in the 4G network according to the instructions of the network side. For example, the terminal can send a mobility update request such as a TAU (Tracking Area Update) request to a 4G network device in order to try to access the 4G network for communication. When the 4G network device confirms that the current terminal cannot access the 4G network, a TAU Reject rejection message can be sent to the terminal. The rejection message can carry a corresponding reason value. For example, the reason value may include #111, which indicates that the network rejects terminal access due to unknown reasons. According to existing standard protocols such as 3GPP protocol 24.301 (specifically: 3GPP TS 24.301 V18.4.0 (2023-09)), the terminal will attempt to access a network with a lower standard than the 4G network (such as a 3G network) based on the rejection message with the reason value #111 received from the 4G network. At the same time, the terminal will also configure the 4G network to be disabled. This will cause the terminal to stay in a lower-standard network (such as a 3G network or a 2G network) for a long time, and it will be unable to quickly return to the 4G network to provide better communication services. Summary of the invention Some embodiments of the present application provide a communication method and a terminal device, which enable the terminal to quickly access a high-standard network (such as a 4G network) after receiving a rejection message with a reason value of #111, thereby avoiding staying in a low-standard network for a long time. In a first aspect, a communication method is provided, which is applied to a terminal device, and the method includes: The terminal device resides in the first network; The terminal device receives a first indication message sent by the first network, where the first indication message includes an identifier of the second network and / or an access frequency of the second network, and the first indication message is used to instruct the terminal device to access the second network; The terminal device sends a first mobility update request to the second network, where the first mobility update request includes an identifier of the second network; The terminal device receives a first mobility update rejection message from the second network, wherein the first mobility update rejection message indicates that the second network device of the second network rejects the terminal from accessing the second network, wherein the rejection reason value carried in the first mobility update rejection message is a first reason value, wherein in the label The quasi-protocol stipulates that: in response to receiving the first mobility update rejection message carrying the first cause value from the second network, the terminal device should initiate access to a third network, where the network standard of the third network is lower than that of the second network; In response to receiving the first mobility update reject message carrying the first cause value from the second network, the terminal device sends a first initial registration request to the second network, where the first initial registration request is used to request attachment to the second network. In this way, the terminal device can attempt to access the second network by initiating an initial registration process when receiving a rejection message with the first cause value, thereby preventing the terminal from residing on the third network according to the existing standard protocol, which in turn causes the terminal to be unable to return to the high-standard network for a long time. Optionally, the method further includes: receiving a first initial registration success message, the first initial registration success message indicating that the terminal is successfully attached to the second network. In this way, by triggering the initial registration process, successful access to the second network is achieved, thereby avoiding the problem of poor communication quality caused by staying in the third network for a long time. Optionally, the first indication message includes: a network redirection message indicating that the terminal device is redirected to the second network. Alternatively, a network switching indication indicating that the terminal device switches to reside in the second network. This example provides two different possibilities of the first indication message. It is understandable that in other embodiments, the network can also indicate that the terminal changes to reside in the second network in other forms. This application is not limited to this. Optionally, the first cause value includes #111. Existing standard protocols such as 3GPP protocol 24.301 (specifically: 3GPP TS 24.301 V18.4.0 (2023-09)) stipulate the following: #111: protocol error, unspecified. …… d)TRACKING AREA UPDATE REJECT,other causes than those treated in clause 5.5.3.2.5,and cases of EMM cause values#22,#25,#31 and#78,if considered as abnormal cases according to clause 5.5.3.2.5 If the tracking area updating request is not for initiating a PDN connection for emergency bearer services,upon reception of the EMM causes #95,#96,#97,#99 and #111 the UE should set the tracking area updating attempt counter to 5. …… If the tracking area updating attempt counter is equal to 5: …… -attempt to select GERAN,UTRAN or NG-RAN radio access technology.Additionally,if the UE selects GERAN or UTRAN radio access technology,the UE may disable the E-UTRA capability as specified in clause 4.5.If No E-UTRA Disabling In 5GS is enabled at the UE(see 3GPP TS 24.368

[0050] or 3GPP TS 31.102

[0017] ) and the UE selects NG-RAN radio access technology, it shall not disable the E-UTRA capability; otherwise, the UE may disable the E-UTRA capability as specified in clause 4.5. Based on the provisions of the above existing protocols, those skilled in the art know that when a terminal receives an original signal from a 4G network, After receiving the rejection message with the value #111, the terminal will try to access a network with a lower standard than the 4G network (such as a 3G network, etc.) to reside. At the same time, the terminal will also configure the 4G network to be disabled. If the existing protocol is followed, the terminal will reside in the 2G or 3G network for a long time, resulting in poor communication quality. In some cases, the terminal receives the rejection message #111 often due to temporary failures within the network, and these temporary failures will be quickly repaired. Therefore, in fact, the terminal can reside in the 4G network, but because the terminal simply executes the process specified by the protocol for #111 according to the existing protocol, the communication quality is reduced. Based on the implementation of each solution provided in the embodiment of the present application, the above problems can be solved. Optionally, before sending the first initial registration request, the method further includes: converting the cause value of the first mobility update rejection message from the first cause value to a second cause value, wherein the standard protocol stipulates that: in response to receiving the first mobility update rejection message carrying the second cause value from the second network, the terminal device should send the first initial registration request to the second network device. This provides a possible implementation, so that the terminal can try to initiate access to the second network through the initial registration process according to the response logic of the second cause value specified in the protocol. Optionally, the second reason value includes #9, or #10, or #40. In an implementation manner, in response to receiving the first mobility update reject message carrying the first cause value from the second network, the terminal device sending a first initial registration request to the second network includes: In response to receiving the first mobility update reject message carrying the first cause value from the second network, when the terminal device is not currently in a call, the terminal device sends a first initial registration request to the second network. Optionally, before converting the cause value of the first TAU ​​rejection message into a second value, the method further includes: determining that the terminal device is not currently in a call. In the existing network environment, the terminal needs to ensure that the IP address remains unchanged for calls on high-standard networks (such as 5G networks and 4G networks). In this application, through the initial registration process, the network may configure a new IP address for the terminal, which will cause the call to be interrupted. Therefore, in this example, if the terminal supports the call function, it can be determined whether it is in a call before initiating the initial registration process, and then the initial registration process can be executed for network access when it is not in a call. This avoids the problem of successful network access but interrupted calls. Optionally, the first initial registration request includes: Attach Request. That is, the first initial registration request is used to attach to the second network (or second network device). The initial registration process may include an attach process. Optionally, the first TAU ​​request includes: TAU Request. The first TAU ​​reject message includes: TAU reject. In one implementation, the method further includes: in response to receiving the first mobility update reject message carrying the first cause value from the second network, when the terminal device is currently in a call, the terminal device sends a third mobility update request to the second network. Optionally, after receiving the first indication message and before sending the first mobility update request, the method further includes: sending a second mobility update request, where the second mobility update request is used to initiate a mobility update process to the second network device to facilitate access to the second network. In this example, the terminal may attempt to initiate a mobility update flow multiple times after receiving the first indication message. Procedure. Optionally, the method further includes: receiving a second mobility update reject message, wherein the second mobility update reject message indicates that the second network device rejects the terminal from accessing the second network, wherein the cause value of the second mobility update reject message is the first cause value. In one implementation, the second network is an LTE network (ie, a 4G network); the first / second / third mobility update request includes: TAU Request; the first / second / third mobility update rejection message includes: TAU reject; or, The second network is an NR network (i.e., a 5G network); the first / second / third mobility update request includes: a registration request with a registration type of MRU; the first / second / third mobility update rejection message includes: a registration rejection message with a registration type of MRU. The UE may send a registration request with a registration type of MRU (mobility registration updating) to implement mobility registration updating. In one implementation, the first / second / third mobility update request is used to initiate a mobility update process to the second network device to facilitate access to the second network. Optionally, after receiving the second mobility update reject message, the method further includes: Starting a first timer, wherein the duration of the first timer is a first duration; The sending the first mobility update request comprises: After the first timer expires, the first mobility update request is sent. Optionally, before sending the first mobility update request, the method further includes: converting the cause value of the second mobility update rejection message into a third cause value. The third cause value corresponds to the terminal sending the first mobility update request to the second network device. The sending of the second mobility update request and the receiving of the second mobility update rejection message may correspond to the terminal performing a mobility update procedure to attempt to access the second network. In this example, the terminal may convert the cause value of the mobility update rejection message into a third cause value when receiving the mobility update rejection message for the first time, thereby allowing the terminal to attempt to perform the mobility update procedure to access the second network multiple times. Optionally, the third reason value includes #17. Existing standard protocols such as 3GPP protocol 24.301 (specifically: 3GPP TS 24.301 V18.4.0 (2023-09)) stipulate the following: #17: Network failure … d)TRACKING AREA UPDATE REJECT, other causes than those treated in clause 5.5.3.2.5, and cases of EMM cause values ​​#22, #25, #31 and #78, if considered as abnormal cases according to clause 5.5.3.2.5 For the cases b,c,d,k,ka,l and la,the UE shall proceed as follows: Timer T3430 shall be stopped if still running. For the cases b,c,d,la k when the"Extended wait time"is ignored,and ka when the"Extended wait time CP data"is ignored,if the tracking area updating request is not for initiating a PDN connection for emergency bearer services,the tracking area updating attempt counter shall be incremented,unless it was already set to 5. Based on the provisions of the above existing protocol, those skilled in the art know that after receiving a rejection message with a reason value of #17 from the 4G network, the terminal will continue to initiate a TAU process to the 4G network. Optionally, the first duration is less than 10 seconds. In this way, by configuring a private timer of the terminal (such as the first timer), the terminal can flexibly configure the waiting time for initiating the mobility update process again. Compared with the 10s specified in the existing protocol, since the timing time of the first timer is shorter, the terminal can initiate the mobility update process faster. Optionally, after converting the cause value of the second mobility update rejection message to a third cause value, the method further includes: starting a first counter, the first counter being configured with a first threshold. After sending the first mobility update request, the method further includes: configuring the value of the first timer to be increased by 1. Optionally, before converting the cause value of the second mobility update reject message into a third cause value, the method further includes: determining that the value of the first counter is less than the first threshold. Optionally, the first threshold is less than 5. In this way, by configuring the private counter of the terminal (such as the first counter), the terminal can flexibly configure the number of times the mobility update process is initiated again. Optionally, the first network is a 5G network, the second network is a 4G network, and the third network is a 3G or 2G network. Alternatively, the first network is a 6G network, the second network is a 4G network or a 5G network, and the third network is a 3G or 2G network. In a second aspect, the present application further provides an electronic device, which may also be referred to as a terminal device. The electronic device includes: a memory and one or more processors. The memory and the processor are coupled. The memory is used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device executes the technical solution provided in the above-mentioned first aspect and any possible implementation thereof. In a third aspect, the present application also provides a chip system, which is applied to electronic devices; the chip system may include one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected by lines, and the interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor, and the signal includes a computer instruction stored in the memory. When the processor executes the above-mentioned computer instructions, the electronic device executes the technical solution provided in the above-mentioned first aspect and any possible implementation thereof. The chip system may include a Modem (baseband processor, or modulation and demodulation processor). In a fourth aspect, the present application also provides a computer-readable storage medium, including computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the technical solution provided in the above-mentioned first aspect and any possible implementation thereof. In a fifth aspect, the present application also provides a computer program product, which, when executed on a computer, enables the computer to execute the technical solution provided in the above-mentioned first aspect and any possible implementation thereof. It can be understood that the solutions provided in the second aspect to the fifth aspect of the present application can respectively correspond to the first aspect and any possible design thereof, so the beneficial effects that can be achieved are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS FIG1 is a schematic diagram of a communication scenario; FIG2 is a schematic diagram showing the composition of a network device; FIG3 is a schematic diagram of an interaction flow of a communication method; FIG4 is a schematic diagram of the percentage of reason values ​​of rejection messages counted in the existing network; FIG5 is a schematic diagram of an interaction flow of a communication method; FIG6 is a schematic diagram of the composition of a terminal device provided in an embodiment of the present application; FIG7 is a schematic diagram of an interaction flow of a communication method provided in an embodiment of the present application; FIG8 is a schematic diagram of an interaction flow of a communication method provided in an embodiment of the present application; FIG9 is a schematic diagram of an interaction flow of a communication method provided in an embodiment of the present application; FIG10 is a schematic diagram of an interaction flow of a communication method provided in an embodiment of the present application; FIG11 is a schematic diagram of the composition of an electronic device provided in an embodiment of the present application; FIG. 12 is a schematic diagram of the composition of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. The technical solution provided in the embodiments of the present application can be applied to various wireless communication networks, such as: global system for mobile communication (GSM) system, code division multiple access (CDMA) system, wideband code division multiple access (WCDMA) system, universal mobile telecommunication system (UMTS) system, general packet radio service (GPRS) system, long term evolution (LTE) system, long term evolution advanced (LTE-A) system, world-wide interoperability for microwave access (WiMAX) system, new radio network of fifth generation mobile communication technology (5G), network of sixth generation mobile communication technology (6G), etc. The terms "network" and "system" can be used interchangeably. In the following description, the network corresponding to the LTE (or LTE-A) system is referred to as a 4G network, and the NR network is referred to as a 5G network. Others are similar and will not be described one by one. User Equipment (UE) or terminal equipment (terminal) can provide users with communication functions of the corresponding network standards by accessing networks of different standards. With the development of network technology, the same location may be covered by networks of multiple standards. For example, refer to Figure 1. In this scenario, the current location of the terminal can be covered by 3G network, 4G network and 5G network at the same time. Then correspondingly, the terminal can provide the user with the communication function of the 3G network by accessing the 3G network. The terminal can also provide the user with the communication function of the 4G network by accessing the 4G network. The terminal can also provide the user with the communication function of the 5G network by accessing the 5G network. In some cases, the terminal can prioritize access to 4G or 5G networks with higher data transmission rates to provide better communication services. For the terminal, the dwell time on each network can be marked by parameters such as the dwell ratio (such as the 4G dwell ratio), and the dwell strategy of the terminal in each standard network can be optimized accordingly. This allows the terminal to stay longer on a higher standard network, thereby providing users with better communication functions. It should be noted that in the embodiment of the present application, a network of a certain standard may be constructed and initiated by corresponding network devices. Exemplarily, a 3G network may correspond to a 3G network device, a 4G network may correspond to a 4G network device, and a 5G network may correspond to a 5G network device. 2, 3G network equipment may include 3G base stations, 3G core network equipment, etc. Thus, when a terminal accesses a 3G network, it may communicate uplink with the 3G core network equipment through the 3G base station, or the 3G core network equipment may communicate downlink with the terminal through the 3G base station. Similarly, 4G network equipment may include 4G base stations, 4G core network equipment, etc. In this way, when the terminal accesses the 4G network, uplink communication can be performed with the 4G core network equipment through the 4G base station, or the 4G core network equipment can perform downlink communication with the terminal through the 4G base station. 5G network equipment may include 5G base stations, 5G core network equipment, etc. In this way, when a terminal accesses a 5G network, it can communicate uplink with the 5G core network equipment through the 5G base station, or the 5G core network equipment can communicate downlink with the terminal through the 5G base station. In the following examples, taking the scenario shown in FIG. 1 as an example, the scenarios involved in the solution provided in the embodiments of the present application and the specific implementation of the solution are explained. Referring to Figure 3, take the case where the terminal resides in a 5G network as an example. In some cases, due to the movement of the terminal or temporary failures on the 5G network side, the 5G network equipment may instruct the terminal to switch to other networks. In the example shown in FIG. 3 , the 5G network device may execute S301 to send an indication message 11 to the terminal. The indication message 11 is used to instruct the terminal to change from the currently accessed 5G network to the 4G network. In some embodiments, the indication message 11 may specifically include a network redirection message (such as RRCConnectionRelease), or a network switching indication (such as HandoverCommand). The indication message 11 may carry information such as the standard identifier corresponding to the 4G network and the access frequency of the 4G network. Correspondingly, the terminal can try to access the 4G network according to the received indication message 11. Exemplarily, the terminal may execute S302 to send a mobility update request 12 to the 4G network device. The mobility update request 12 may be sent by the terminal to the 4G core network device through the 4G base station after the terminal completes the establishment of the RRC connection with the 4G base station in the 4G network device. In some implementations, the mobility update request 12 may include a Tracking Area Update (TAU) Request, i.e., a TAU Request. The TAU Request may include information such as an identifier of the network to be accessed. For example, in this example, the terminal wants to access a 4G network, and correspondingly, the mobility update request 12 may include an identifier of the 4G network, such as an LTE field, etc. In some cases, the 4G network device may determine that the terminal can reside in the current 4G network according to the mobility update request 12. Correspondingly, the 4G network device may send a mobility update accept message (such as TAU Accept) to the terminal. In other cases, when 4G network equipment has compatibility issues, the terminal cannot Access to the current 4G network. Correspondingly, as shown in FIG3 , the 4G network device executes S303 to send a mobility update rejection message 13 to the terminal. Exemplarily, the mobility update reject message 13 may include TAU Reject. In some implementations, the mobility update reject message 13 received by the terminal may carry a reject cause value. For example, the mobility update reject message 13 may include a reject cause value of #111. In the existing protocol specification, #111 is defined as protocol error, unspecified. That is, the reason value #111 corresponds to a protocol error, and the reason is unknown. Correspondingly, the existing protocol also stipulates the execution strategy of the terminal when the cause value is #111: attempt to select GERAN, UTRAN or NG-RAN radio access technology. Additionally, if the UE selects GERAN or UTRAN radio access technology, the UE may disable the E-UTRA capability. That is, the terminal may attempt to select GERAN, UTRAN or NG-RAN radio access technology. In addition, if the UE selects GERAN or UTRAN radio access technology, the UE may disable E-UTRA functions. Among them, GERAN and UTRAN radio technologies are also the aforementioned 2G / 3G network technologies. It can be understood that in the scenario shown in FIG. 3 , since the terminal is disconnected from the 5G network before executing S302 to attempt to access the 4G network, the terminal may no longer select the NG-RAN radio access technology to attempt to access the 5G network when receiving the mobility update rejection message 13 including the cause value #111. Correspondingly, the terminal may attempt to select GERAN, UTRAN to access the 2G or 3G network. Exemplarily, as shown in FIG. 3 , the terminal may execute S304 to initiate a registration request 14 to the 3G network device, and attempt to access the 3G network to reside therein. When the terminal successfully registers to the 3G network, the terminal can complete the network change from 5G to 3G. Based on the description specified in the aforementioned protocol, when the terminal attempts to access a 2G or 3G network, the E-UTRA function will be disabled, that is, the 4G network is configured to be disabled. This will cause the terminal to stay in the 2G or 3G network for a long time, and will not quickly change to a higher standard network (such as a 4G network or a 5G network). This corresponds to a low 4G resident ratio or a low 5G resident ratio of the terminal. This will obviously affect the quality of communication services provided by the terminal to users. Through monitoring and statistics of the existing network, Figure 4 provides examples of 6 rejection reason values ​​with a relatively large proportion. As shown in Figure 4, among the many network access rejection messages received by the terminal, the proportion of access rejection messages carrying the reason value #111 has entered the top 6. Therefore, by optimizing the scenario with the rejection reason value #111, the terminal can try to quickly re-resident in a higher-standard network, which can significantly and effectively improve the communication quality of the terminal. In order to solve the above problem, in some implementations, the cause value may be converted from #111 to #17 so that the terminal can perform subsequent processing according to the processing strategy corresponding to #17 in the existing protocol. In the existing protocol, when the cause value is #17, the terminal can perform multiple (e.g., 5) attempts to register with the 4G network. In this way, compared with the solution implementation shown in FIG3 , the terminal can be configured with more attempts to access the 4G network before staying in the 2G / 3G network for a long time, thereby increasing the probability of accessing the 4G network. As an example, refer to FIG5. In combination with the description of FIG3, the terminal and the network device perform S301- Take the interaction of S303 as an example. As shown in FIG. 5 , after receiving the mobility update rejection message 13 with a cause value of #111, the terminal may trigger the following steps: S401 , the terminal converts the rejection cause value to #17. In this way, the terminal can perform subsequent processing according to the response strategy corresponding to the rejection reason value #17 as specified in the protocol. Exemplarily, the process may include: S402: The terminal starts the T3411 timer and the counter C11. The T3411 timer can provide a 10s timing function. The counter C11 can be used to count subsequent message sending. The terminal may trigger execution of S403 according to the expiration of the T3411 timer. S403: The terminal sends a mobility update request 15 to the 4G network device. Exemplarily, the mobility update request 15 is similar to the mobility update request 12 sent in the aforementioned S302. The mobility update request 15 may include a TAU Request. According to the existing protocol, when a terminal receives an access rejection message with a reason value of #17, it can send a TAU Request to the 4G network device again, thereby trying to access the 4G network again. It is understandable that for the network, if multiple identical messages are received continuously within a short period of time, they may be considered invalid messages, and thus the network will not respond to subsequent messages based on the security policy configured in the network. In the implementation of the solution shown in FIG5 , the terminal can wait for 10 seconds by initiating the T3411 timer before sending the TAU Request again, so that the terminal does not immediately send the TAU Request repeatedly to the 4G network device, thereby avoiding the problem that the mobility update request 15 is not responded to by the 4G network device. In the example shown in FIG. 5 , the terminal may execute S402 - S403 multiple times to implement multiple attempts to access the 4G network device. In the specific execution process, the terminal may record the number of access attempts to the 4G network device through the counter C11 started in S402. For example, after executing S403, the terminal may execute S404 to configure the counter C11 to add 1. Thus, when the value of the counter C11 reaches a certain value (such as 5 times), it indicates that the 4G network cannot be accessed after multiple attempts. Then the terminal can jump to execute S304 shown in FIG3 and send a registration request 14 to the 3G network device, so that the terminal can ensure basic communication by residing on the 3G network. Correspondingly, when the value of the counter C11 does not reach 5 times, the terminal may repeatedly execute S402 - S403 . In the example shown in FIG. 5 , after executing S403 , the terminal may receive a mobility update confirmation message 16 sent from the 4G network device. Exemplarily, the mobility update confirmation message 16 may include TAU Accept. That is, after one retry, the terminal can successfully access the 4G network. In this way, the problem of staying in the 3G network for a long time after failing to access the 4G network as shown in FIG. 3 is avoided. However, there are still some problems in the implementation of the solution shown in FIG5 . As shown in FIG5 , for the terminal, in order to enable the 4G network device to normally respond to the TAU Request (such as the mobility update request 15) sent again, it is necessary to wait for the T3411 timer to expire before sending the TAU Request. Mobility update request 15. Then, even if the terminal accesses the 4G network after retrying the 4G network once as shown in FIG5 , the terminal will still have a communication interruption of at least 10 seconds. Based on this, the technical solution provided by the embodiment of the present application can prevent the terminal from staying in the 2G / 3G network for a long time, compared with the existing solution shown in Figure 3. In addition, the technical solution provided by the embodiment of the present application, compared with the technical implementation shown in Figure 5, can enable the terminal to stay on the 4G network faster, reducing or eliminating the communication interruption problem before staying on the 4G network. The solution provided in the embodiments of the present application is described in detail below with reference to the accompanying drawings. It should be noted that the terminal in the embodiment of the present application may include at least one of a mobile phone, a foldable electronic device, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, a vehicle-mounted device, a smart home device, or a smart city device. The embodiment of the present application does not impose any special restrictions on the specific type of the terminal. As an example, refer to FIG6 , which is a schematic diagram of the composition of a terminal provided in an embodiment of the present application. As shown in FIG6 , the terminal may include a processor 610, an external memory interface 620, an internal memory 621, a universal serial bus (USB) connector 630, a charging management module 640, a power management module 641, a battery 642, an antenna 1, an antenna 2, a mobile communication module 650, a wireless communication module 660, an audio module 670, a sensor module 680, a camera module 693, a display screen 694, etc. In some implementations, the sensor module 680 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc. The processor 610 may include one or more processing units, for example, the processor 610 may include an application processor (AP), a modem processor (Modem), a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor (BP or BBP), and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated into one or more processors. For example, a modem may be integrated into a baseband processor, etc. In the implementation of the solution provided in the embodiment of the present application, the internal processing logic of the terminal can be implemented directly or indirectly by the baseband processor. When the terminal is working, the processor 610 can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions. It should be noted that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the terminal. In other embodiments of the present application, the terminal may include more or fewer components than those shown in FIG6, or combine certain components, or split certain components, or arrange the components differently. The components shown in FIG6 may be implemented in hardware, software, or a combination of software and hardware. Each specific implementation provided in the embodiments of the present application can be applied to the electronic device shown in FIG. 6 . It should be noted that in the following description, the interaction between the terminal and the network device may include the interaction between the terminal and the core network device of the corresponding network. For example, the TAU process between the terminal and the network device (such as including sending a TAU request, etc.) may be the TAU process between the terminal and the core network device of the corresponding network. For another example, the attachment process between the terminal and the network device (such as including sending an Attach request, etc.) may be the Attach process between the terminal and the core network device of the corresponding network. Among them, the interaction between the terminal and the core network device can be achieved through the access network device of the corresponding network. For example, the interaction between the terminal and the 5G core network device can be achieved through message transparent transmission through the 5G base station. For another example, the interaction between the terminal and the 4G core network device can be achieved through message transparent transmission through the 4G base station. For another example, the interaction between the terminal and the 6G core network device can be achieved through message transparent transmission through the 6G base station. Other networks are similar. In some embodiments, referring to FIG7 , a schematic diagram of an interaction process of a communication method provided in an embodiment of the present application is shown. As shown in FIG7 , the scheme may include: S701: A terminal receives a first instruction message. The first instruction message is used to instruct the terminal to re-resident on a network. The first indication message may be sent to the terminal by a network device (such as network device 71) of the network to which the terminal is currently connected. The first indication message is used to instruct the terminal to re-resident in a heterogeneous system network or a homogeneous system network. Exemplarily, re-residence in a different system network may include: switching / redirecting from a currently resided 5G network to a 4G network, or switching / redirecting from a currently resided 4G network to a 2G or 3G network, or switching / redirecting from a currently resided 6G network to a 5G or 4G or 3G network, etc. Re-residence in the same system network may include: switching / redirecting from the currently resided 5G network to other 5G networks, or switching / redirecting from the currently resided 4G network to other 4G networks, or switching / redirecting from the currently resided 6G network to other 6G networks, etc. In this example, it is taken that the first indication message is used to instruct the terminal to re-resident on a heterogeneous system network. In some embodiments, the first indication message may include information indicating the target network where the terminal re-residents. For example, taking the first indication message indicating that the terminal re-residents in the 4G network as an example. The first indication message includes information of the 4G network, such as a network identifier of the 4G network (such as an LTE field) and / or an access frequency of the 4G network. S702: The terminal sends a first mobility update request. Exemplarily, the first mobility update request may include a TAU Request. In some embodiments, the first mobility update request may include an identifier of a network to which the network device 72 belongs. For example, if the network device 72 is a 4G network device, the identifier of the network to which the network device 72 belongs may be an identifier of a 4G network, such as LTE. Optionally, the first mobility update request may be sent by the terminal to the network device (such as network device 72) indicating re-resident according to the first indication message. The first mobility update request may be used to request access to a network corresponding to the network device 72 . S703: The terminal receives a first mobility update reject message. Exemplarily, the first mobility update reject message may include TAU Reject. Optionally, the first mobility update rejection message may be sent by the network device 72 to the terminal. In this example, the first mobility update rejection message may include a reason value for rejecting this network access. For example, the cause value of the first mobility update reject message may be #111. S704: The terminal sends a first initial registration request. Exemplarily, the first initial registration request may include an Attach Request. The first initial registration request may be used to initiate an initial registration with the network corresponding to the network device 72. It is understandable that after the terminal is powered on, it can access the network corresponding to the current location through initial registration. In this example, the terminal can initiate initial registration with the network corresponding to the network device 72 after receiving the first mobility update rejection message with the cause value #111. In some embodiments, the Attach Request may include the International Mobile Equipment Identity (IMSI) of the current terminal, the current location identifier of the terminal (such as the TAI identifier), capability information supported by the terminal (such as frequency band information supported by the terminal, etc.), etc. It should be noted that since the TAU process and the Attach process are two independent interactive processes, even if the TAU process fails, the Attach process may still successfully access the network. Thus, in the present application, when the terminal receives the first mobility update request with the cause value #111 (ie, the TAU process fails), it can initiate the Attach process again and try to access the network corresponding to the network device 72 again. As shown in FIG. 7 , in this example, optionally, the terminal may execute S705 : the terminal receives a first initial registration success message. Exemplarily, the first initial registration success message may include Attach Accept. The first initial registration success message is used to indicate that the terminal is successfully attached to / accessed to the network corresponding to the network device 72. Correspondingly, since the terminal successfully accesses the network corresponding to the network device 72, the network standard will not continue to drop. It should be noted that, during the execution of the solution shown in FIG. 7 , the terminal may be configured to implement various different implementations, so that after receiving the first mobility update reject message with the cause value #111 in S703 , S704 is triggered. Exemplarily, in some embodiments, the terminal may replace the reason value #111 with other reason values ​​(such as #9, #10 or #40, etc.), so that the terminal triggers S704 based on the replaced reason value according to existing protocol provisions. In some other embodiments, after receiving the first mobility update reject message with cause value #111, the terminal may be configured to trigger execution of S704. In the following description, it is taken that the terminal triggers S704 by replacing the reason value as an example. Therefore, when the solution shown in FIG. 7 is applied to the scenario shown in FIG. 1 , compared with the processing mechanism in the existing solution shown in FIG. 3 , the terminal will not fall to 2G or 3G and disable the 4G network after receiving a rejection message with a reason value of #111. Accordingly, the terminal can be implemented based on the solution shown in FIG. 7 , and after receiving a rejection message with a reason value of #111, it can try to access the 4G network again through the Attach process. This increases the probability that the terminal continues to reside in the 4G network. In addition, compared with the implementation of the solution shown in FIG. 5, during the implementation of the solution shown in FIG. 7, after receiving the first mobility update rejection message, the terminal can trigger the execution of S704 to send the first initial registration request to the network device 72. Since the Attach process corresponding to the first initial registration request is different from the TAU process corresponding to the first mobility update request, the terminal does not need to wait and can directly send the first initial registration request. This can also avoid communication interruption within the duration (eg, 10 seconds) of the T3411 timer in the solution shown in FIG. 6 . It should be noted that the process interaction shown in Figure 7 is only one implementation. In other embodiments of the present application, the inventive concept shown in Figure 7 may also have other specific implementations. Exemplarily, referring to Fig. 8, taking the application of the technical solution provided in the embodiment of the present application to the scenario shown in Fig. 1 as an example, the implementation of the solution shown in Fig. 7 is described in detail. In this example, the network device 71 may be a 5G network device, and the network device 72 may be a 4G network device. As shown in FIG8 , the solution may include: S801. The terminal receives an indication message 11. Exemplarily, the execution of this step may refer to S301 shown in FIG3 or S701 shown in FIG7 . The indication message 11 may correspond to the first indication message shown in FIG7 . In this example, the first indication message may be sent by a 5G network device of the currently accessed 5G network (such as a core network device in the 5G network device), and is used to instruct the terminal to switch / redirect from the 5G network to the 4G network. S802. The terminal sends a mobility update request 12 to the 4G network device. Exemplarily, the execution of this step may refer to S302 shown in FIG3 or S702 shown in FIG7 . The mobility update request 12 may correspond to the first mobility update request shown in FIG7 . In this example, the mobility update request 12 may include a TAU Request. The mobility update request 12 may be used to attempt to access a 4G network. S803: The terminal receives the mobility update reject message 13. Exemplarily, the execution of this step may refer to S303 shown in FIG3 or S703 shown in FIG7 . The mobility update reject message 13 may correspond to the first mobility update reject message shown in FIG7 . In this example, the mobility update reject message 13 may include TAU Reject. The reason value of the mobility update reject message 13 may be #111, that is, protocol error, unspecified. S804. The terminal converts the rejection reason value to #9. In this example, after receiving the mobility update rejection message 13, the terminal may trigger the execution of S804 according to the reason value of the rejection message being #111. It can be understood that the cause value #9 is also one of the multiple cause values ​​specified in the existing protocol. Based on existing protocol regulations, after receiving a rejection message with a reason value of #9, the terminal can trigger the execution of the initial registration process, that is, the Attach process. In some other embodiments of the present application, in S804, the terminal may convert the rejection reason value from #111 to other reason values. The reason value replacing #111 may be: a reason value that triggers the execution of the initial registration process according to the existing protocol. For example, the terminal may convert the rejection reason value from #111 to #10 or #40, etc. Then, the terminal can perform subsequent operations according to the received mobility update reject message with reason value #9 and in accordance with the existing protocol. S805. The terminal sends an initial registration request 17 to the 4G network device. Exemplarily, the execution of this step may refer to S704 shown in FIG7 . The initial registration request 17 may correspond to the first initial registration request shown in FIG7 . In this example, the initial registration request 17 may include an Attach Request. Combined with the description in S804, in S804, the terminal triggers the execution of the initial registration process according to the reason value #9. The initial registration process may correspond to the Attach registration process or be called the Attach process. Based on the Attach process, the terminal may execute S805 to send an initial registration request 17 to the 4G network device. The initial registration request 17 may be used to request attachment to the 4G network device for communication. S806. The terminal receives an initial registration success message 18. Exemplarily, the initial registration success message 18 may be sent by a 4G network device. The execution of this step may refer to S705 shown in FIG7 . The initial registration success message 18 may correspond to the first initial registration success message shown in FIG7 . In this example, the initial registration success message 18 may include Attach Accept. Thus, the terminal can complete the Attach process to the 4G network device based on the received initial registration success message 18. Correspondingly, the terminal can also complete the communication with the 4G network device based on the Attach process, and then provide the user with the communication service of the 4G network. It is understandable that, in the example of FIG8 , after receiving the mobility update rejection message 13, the terminal triggers the initial registration process to the 4G network by converting the cause value and registers successfully. In this process, the terminal does not need to wait, so that access to the 4G network can be quickly achieved. Correspondingly, the terminal will not be configured to disable 4G due to network rejection with a cause value of #111, and thus stay on the low-standard 2G / 3G network for a long time. The solution example shown in Figure 8 provides a specific implementation of the solution shown in Figure 7. In other embodiments of the present application, the solution shown in Figure 7 may also include other implementations. Exemplarily, refer to FIG9 , which is a schematic diagram of an interaction flow of another communication method provided in an embodiment of the present application. As shown in FIG. 9 , in this example, the interaction between the network elements can be expanded and obtained in combination with the example of FIG. 8 . In the example shown in FIG. 9 , the execution process of S801 - S806 may refer to the example shown in FIG. 8 , and the details are not repeated here. It should be noted that, as shown in the example of FIG9 , after receiving the mobility update rejection message 13 with the cause value #111, before executing S804, the terminal may execute S901. Specifically: S901. The terminal determines whether it is in a call. The terminal is in a call, that is, the terminal is making a voice call. Exemplarily, the voice call may include a VoNR call based on the currently resident 5G network. In other embodiments, when the terminal is currently resident in a 4G network, the voice call may include a VoLTE call based on the currently resident 4G network. It is understandable that in a 4G network or a 5G network, the voice call of the terminal can be realized based on a fixed IP. The fixed IP of the terminal can be assigned to the terminal by the network device during the registration (such as initial registration) with the current resident network device. Take the case where the terminal currently resides in a 5G network as an example. After the terminal is turned on, it can receive the IP address configured by the 5G network device for the terminal during the initial registration process with the current 5G network. After that, the terminal can make a VoNR call in the 5G network based on the IP address. Correspondingly, if the IP address changes during the terminal call, the VoNR call will be disconnected. It is understandable that, in the execution process of S804-S806 shown in FIG8 , the terminal triggers the execution of the initial registration process according to the converted reason value #9. During the execution of the initial registration process, the 4G network device may configure a new IP address for the terminal. This may cause the current call to be disconnected. In order to avoid abnormal disconnection during the call, in the example of Figure 9, after receiving the mobility update rejection message 13 with the reason value #111, the terminal can execute S804 corresponding to converting the rejection reason value to #9 before executing S901 to determine whether the call is currently in progress. If the terminal is currently in a call, in order to avoid abnormal disconnection of the call, the terminal jumps to execute S902. Correspondingly, if the terminal is no longer in a call, S804-S806 are executed. S902. The terminal converts the rejection reason value to #17. Exemplarily, this step may refer to the description of S401 in FIG. 5 . In this example, the terminal can no longer use the initial registration process to access the 4G network during the call to avoid abnormal call disconnection caused by this. Conversely, the terminal can convert the rejection reason value to #17 to trigger the TAU process again and try to access the 4G network. In this way, the terminal can try to access the 4G network through the TAU process while maintaining the call. It should be noted that the solution implementation provided in this example is different from the solution implementation shown in Figure 5. The following is an explanation in conjunction with specific steps. S903: The terminal starts the timer 91 and the counter C12. Exemplarily, the terminal may be pre-configured with a timer 91 and a counter C12. Among them, the timer 91 can be configured with a timing duration according to specific circumstances. In some embodiments, the timing duration of the timer 91 can be less than the timing duration of the T3411 timer. For example, the timing duration of the timer 91 can be less than 10s. The initial value of the counter C12 is 0. The terminal may configure a corresponding threshold m for the counter C12 according to specific circumstances. In some embodiments, m may be an integer less than 5. For example, m may be configured as 1. It should be noted that, in the example shown in FIG9 , the timer 91 is different from the T3411 timer specified in the existing protocol shown in FIG5 . The counter C12 is also different from the counter C11 specified in the existing protocol shown in FIG5 . In some embodiments, after executing S902, in response to a rejection message with a cause value of #17, the terminal may start timer 91 and counter C12 according to S903. The terminal may also start timer T3411 and counter C11 according to an existing protocol. Therefore, when timer 91 or timer T3411 expires, the terminal triggers execution of S904. For example, if the timing duration of timer 91 is 1 second, after executing S902, the terminal may wait for 1 second until timer 91 expires, triggering execution of S904. It is understandable that, since the timing duration of timer 91 is less than 10s corresponding to timer T3411, timer 91 must end before timer T3411, and the terminal is triggered to execute S904 accordingly. In some other embodiments, after executing S902, in response to a rejection message with a cause value of #17, the terminal may start timer 91 and counter C12 according to S903. In addition, the terminal may be configured not to start timer T3411 and counter C11. S904: The terminal sends a mobility update request 19. Exemplarily, the mobility update request 19 may correspond to the mobility update request 15 as shown in FIG. 5 . In this example, the terminal may try to access the 4G network device again through a mobility update request 19. In some embodiments, the mobility update request 19 may be the same as the mobility update request 12. S905. The terminal configuration counter C12 is incremented by 1. According to the description in S903, the terminal can start the counter C12. Then, after starting the counter C12, each time the terminal sends a mobility update request (TAU Request), the terminal configures the counter C12 to increase by 1. Thus, the value of the counter C12 can be used to indicate the number of times the TAU is repeated. It should be noted that, in some embodiments, after the terminal converts the rejection reason value to #17, the counter C11 is started as an example. In S905, the terminal configures the counter C12 to increase by 1, and can also configure the counter C11 to increase by 1. S906 : The terminal receives the mobility update reject message 20 . In this example, it is taken that after the 4G network device receives the mobility request 19, it sends a mobility update rejection message 20 to the terminal. That is, the terminal fails to make a TAU request. In some embodiments, the mobility update reject message 20 may include TAU Reject. The cause value of the mobility update reject message 20 may include #111. In other embodiments, the terminal may receive a mobility update confirmation message (such as including TAU Accept) from the 4G network device after executing S904. In this way, the terminal successfully accesses the 4G network and correspondingly exits the process shown in FIG. 9 . The following takes the case where the terminal receives a mobility update rejection message 20 after sending a mobility update request 19 as an example. S907: The terminal determines whether the value of the counter C12 reaches m. Exemplarily, in combination with the description in S903, m may be a threshold value corresponding to the counter C12. In some embodiments, the terminal may determine that a mobility update reject message (such as mobility update reject message 20) is received before executing S907. As a possible implementation, the terminal may determine that a mobility update reject message is received by receiving TAU Reject after sending TAU Request. In S907, the terminal may read the value of the counter C12 to determine whether the current value of the counter C12 reaches m. When the current value of the counter C12 reaches m, S908 is executed. Correspondingly, when the current value of the counter C12 does not reach m (ie, is less than m), the process returns to execute S903. In some embodiments, m may be less than 5. Thus, after receiving the mobility update rejection message 13, the terminal may jump to execute S908 after failing the TAU process for a maximum of 4 times (for example, m is configured as 4). Therefore, through S907, the terminal can control the number of times the TAU process is repeated to attempt to access the 4G network according to the configured threshold m, thereby avoiding problems such as excessive power consumption and time consumption caused by excessive attempts to access the 4G network. S908. The terminal sends a registration request 21. Exemplarily, when the terminal performs multiple (e.g., m) TAU procedures on the 4G network and fails, the terminal may send a registration request 21 to the 3G network device. Thus, the terminal may try to access by lowering the standard to ensure that the terminal can provide the most basic communication function. It should be noted that, in the example shown in FIG. 9 , after receiving the mobility update rejection message 13 , the terminal determines whether the call is in progress. That is, the solution shown in FIG. 9 can be applied to a terminal with a call function. middle. For other terminals without a call function, or terminals whose call function is temporarily unavailable, when implementing the solution shown in FIG. 9 , the terminal may execute S803 and no longer execute S901 , but directly jump to execute S804 . In addition, in the example of FIG. 9 , after receiving the mobility update rejection message 13, if the terminal is not in a call, S804 can be directly executed to convert the rejection reason value to #9, thereby triggering the execution of S805 to enter the initial registration process. This processing strategy is referred to as processing strategy A. Correspondingly, if the terminal is in a call, the TAU process is performed again to try to access the 4G network by converting the rejection reason value to #17. This processing strategy is referred to as processing strategy B. That is, in the example of FIG. 9 , after the terminal receives the mobility update rejection message 13 with the cause value #111, the execution of processing strategy A is triggered first. If it is determined in processing strategy A that the terminal is in a call, processing strategy B is triggered. In some other embodiments of the present application, the terminal may also trigger the execution of processing strategy A after processing strategy B. Exemplarily, refer to FIG10 , which is a schematic diagram of an interaction flow of another communication method provided in an embodiment of the present application. As shown in Figure 10, the terminal can implement steps S801-S803 through interaction with network devices (such as 5G network devices, 4G network devices, etc.). In this example, the terminal may trigger the execution of processing strategy B according to receiving the mobility update rejection message 13 with the cause value #111. For example, after executing S803, the terminal may sequentially execute S902, S903, S904, S905, S906, and S907. The specific implementation of each step can refer to the description in FIG9, which will not be repeated here. Thus, after a TAU process fails, the terminal can attempt the TAU process within a preset number of times (such as m times) to increase the probability of re-accessing the 4G network through the TAU process. It can be understood that in the case where the 4G network device sends a rejection message #111 to the terminal due to a temporary failure, the processing strategy B can be used to pass the TAU process as soon as possible after the temporary failure of the 4G network device is repaired, so that the terminal can access the 4G network for communication. In the example of FIG10 , the example of the failure of m TAU processes performed by processing strategy B is used for explanation. In other embodiments, during the execution of the TAU process within the preset number of times (such as m times), if one TAU process succeeds, such as the terminal receives a TAU Accept reply from the 4G network, then the process shown in FIG10 is correspondingly jumped out, that is, the terminal can communicate normally on the connected 4G network. As shown in the example of FIG. 10 , when processing strategy B fails to enable the terminal to access the 4G network, it means that the terminal fails in trying to reconnect to the 4G network through m TAU processes, and processing strategy A is triggered. Exemplarily, the terminal may continue to execute S901 when the value of the counter C12 reaches m. 9, after triggering execution of S901, the terminal can execute steps S804, S805, S806, etc. according to the fact that the terminal is not currently in a call (e.g., the terminal is not currently performing a call service but performing a data service). Correspondingly, the terminal can execute S908 according to the fact that the terminal is currently in a call. It can be understood that the execution of each step in FIG. 10 and the related extensions and deformations can all correspond to the description of the corresponding steps in FIG. 9 , and will not be described one by one here. According to Figure 10, in some other possible implementations, the terminal may attempt to perform multiple TAU processes to the 4G network after receiving a rejection message with a reason value of #111 in reply from the 4G network. If a TAU process is successful, the terminal can communicate normally on the 4G network. If multiple TAU processes all fail (such as initiating multiple TAU requests and receiving rejection messages with a reason value of #111), the terminal may initiate an initial registration with the 4G network (for example, after receiving a rejection message with a reason value of #111 in reply from the 4G network, the terminal may perform an initial registration process with the network in accordance with the processing strategy for receiving a rejection message with a reason value of #9 in reply from a certain network as specified in the existing protocol). Therefore, through the solution as shown in Figure 10, after receiving the rejection message #111, the terminal can trigger the processing strategy B and the processing strategy A in sequence, so that the terminal can trigger the initial registration process, combined with the TAU registration process, to achieve rapid access to the 4G network. It should be noted that in the above-mentioned embodiments, the terminal resides in the 5G network, and after changing to reside in the 4G network under the instruction of the network device, receives a rejection message of TAU Reject carrying the reason value #111 as an example to illustrate the implementation of the solution provided in the embodiments of the present application. In other embodiments, the technical solutions provided in the embodiments of the present application can be applied to other scenarios. For example, the terminal resides in a 6G network and changes to reside in a 5G network or a 4G network under the instruction of the network device. The terminal can initiate a TAU process of the 5G network or the 4G network accordingly. After receiving a rejection message of TAU Reject carrying a reason value of #111, the terminal can quickly access the 5G network or the 4G network according to any of the solutions provided in the embodiments of the present application. For another example, the terminal resides in a 3G network and changes to reside in a 4G network or a 5G network under the instruction of the network device. The terminal can send a TAU process of the 4G network or the 5G network accordingly. After receiving a rejection message of TAU Reject carrying a reason value of #111, the terminal can quickly access the 4G network or the 5G network according to any of the solutions provided in the embodiments of the present application. For another example, the terminal resides in a 5G network and changes to reside in another 5G network under the instruction of the network device. The terminal can initiate a TAU process to the new 5G network accordingly. After receiving the rejection message of TAU Reject carrying the #111 reason value, the terminal can implement any of the solutions provided in the embodiments of the present application, and quickly access the new 5G network again through the initial registration process (such as the above-mentioned processing strategy A), or the initial registration and TAU process (such as the above-mentioned processing strategy A and processing strategy B). It is understandable that the electronic device provided in the embodiment of the present application includes a hardware structure and / or software module corresponding to each function in order to realize the above functions. Those skilled in the art should easily realize that, in conjunction with the units and algorithm steps of each example described in the embodiment disclosed herein, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiment of the present application. The embodiment of the present application can divide the functional modules of the above-mentioned electronic device according to the above-mentioned method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. Exemplarily, Fig. 11 shows a schematic diagram of the composition of an electronic device 1100. The electronic device 1100 may correspond to the terminal in any of the above embodiments. As shown in FIG11 , the electronic device 1100 may include: a processor 1101 and a memory 1102. The memory 1102 is used to store computer-executable instructions. Exemplarily, in some embodiments, when the processor 1101 executes the instructions stored in the memory 1102, the electronic device 1100 may execute any of the methods shown in the above embodiments. It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here. FIG12 shows a schematic diagram of the composition of a chip system 1200. The chip system 1200 may include: a processor 1201 and a communication interface 1202, which are used to support related devices (such as terminals) to implement the functions involved in the above embodiments. In one possible design, the chip system also includes a memory for storing program instructions and data necessary for the terminal. The chip system may be composed of chips, or may include chips and other discrete devices. It should be noted that in some implementations of the present application, the communication interface 1202 may also be referred to as an interface circuit. It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here. The functions or actions or operations or steps in the above embodiments can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using a software program, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or may include one or more servers, data centers and other data storage devices that can be integrated with the medium. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)). Although the present application has been described in conjunction with specific features and embodiments thereof, it is obvious that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely exemplary illustrations of the present application as defined by the appended claims, and are deemed to have covered any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A communication method, characterized in that: Applied to a terminal device, the method comprises: The terminal device resides in the first network; The terminal device receives a first indication message sent by the first network, where the first indication message includes an identifier of the second network and / or an access frequency of the second network, and the first indication message is used to instruct the terminal device to access the second network; The terminal device sends a first mobility update request to the second network, where the first mobility update request includes an identifier of the second network; The terminal device receives a first mobility update rejection message from the second network, wherein the first mobility update rejection message indicates that the second network device of the second network rejects the terminal from accessing the second network, wherein the rejection cause value carried in the first mobility update rejection message is a first cause value, wherein it is specified in the standard protocol that: in response to receiving the first mobility update rejection message carrying the first cause value from the second network, the terminal device should initiate access to a third network, wherein the network standard of the third network is lower than that of the second network; In response to receiving the first mobility update reject message carrying the first cause value from the second network, the terminal device sends a first initial registration request to the second network, where the first initial registration request is used to request attachment to the second network.

2. The method according to claim 1, characterized in that The first indication message includes: a network redirection message instructing the terminal device to redirect to the second network; or, A network switching indication instructing the terminal device to switch to reside on the second network.

3. The method according to any one of claims 1 to 2, characterized in that: The first reason value includes #111.

4. The method according to any one of claims 1 to 3, characterized in that Before sending the first initial registration request, the method further includes: The cause value of the first mobility update reject message is converted from the first cause value to a second cause value, wherein the standard protocol stipulates that in response to receiving the first mobility update reject message carrying the second cause value from the second network, the terminal device should send the first initial registration request to the second network device.

5. The method according to claim 4, characterized in that The second reason value includes #9, or #10, or #40.

6. The method according to any one of claims 1 to 5, characterized in that: In response to receiving the first mobility update rejection message carrying the first cause value from the second network, the terminal device sending a first initial registration request to the second network, comprising: In response to receiving the first mobility update reject message carrying the first cause value from the second network, when the terminal device is not currently in a call, the terminal device sends a first initial registration request to the second network.

7. The method according to claim 6, characterized in that The method further includes: in response to receiving the first mobility update reject message carrying the first cause value from the second network, when the terminal device is currently in a call, the terminal device sending a third mobility update request to the second network.

8. The method according to any one of claims 1 to 7, characterized in that The second network is an LTE network; The first mobility update request includes: TAU Request; the first mobility update rejection message includes: TAU reject; or, The second network is an NR network; the first mobility update request includes: a registration request with a registration type of MRU; the first mobility update reject message includes: a registration reject message with a registration type of MRU.

9. The method according to any one of claims 1 to 8, characterized in that After receiving the first indication message and before sending the first mobility update request, the method further includes: Sending a second mobility update request, where the second mobility update request is used to initiate a mobility update process to the second network device to facilitate access to the second network; receiving a second mobility update reject message, where the second mobility update reject message indicates that the second network device rejects the terminal from accessing the second network; The cause value of the second mobility update reject message is the first cause value.

10. The method according to claim 9, characterized in that After receiving the second mobility update reject message, the method further includes: Starting a first timer, wherein the duration of the first timer is a first duration; The sending the first mobility update request comprises: After the first timer expires, the first mobility update request is sent.

11. The method according to claim 9 or 10, characterized in that: Before sending the first mobility update request, the method further includes: The cause value of the second mobility update reject message is converted into a third cause value; the third cause value corresponds to the terminal sending the first mobility update request to the second network device.

12. The method according to claim 11, characterized in that The third reason value includes #17.

13. The method according to any one of claims 10 to 12, characterized in that: The first duration is less than or equal to 10 seconds.

14. The method according to any one of claims 11 to 13, characterized in that After converting the cause value of the second mobility update reject message into a third cause value, the method further includes: Starting a first counter, wherein the first counter is configured with a first threshold; After sending the first mobility update request, the method further includes: Configure the value of the first timer to increase by 1.

15. The method according to claim 14, characterized in that Before converting the cause value of the second mobility update reject message into a third cause value, the method further includes: It is determined that the value of the first counter is less than the first threshold.

16. The method according to claim 14 or 15, characterized in that The first threshold is less than 5.

17. A terminal device, characterized in that: The terminal device comprises: a memory and one or more processors; the memory and the processor are coupled; The memory is used to store computer program codes, and the computer program codes include computer instructions. When the processor executes the computer instructions, the terminal device executes the method as claimed in any one of claims 1 to 16.

18. A chip system, characterized in that: The chip system is applied to a terminal device; the chip system includes one or more interface circuits and one or more processors; the interface circuit and the processor are interconnected through lines; the interface circuit is used to receive a signal from the memory of the terminal device and send the signal to the processor, the signal including computer instructions stored in the memory; when the processor executes the computer instructions, the terminal device executes the method described in any one of claims 1-16.

Images