WO2023051060A1 - 降低掉话率的方法及终端 - Google Patents

降低掉话率的方法及终端 Download PDF

Info

Publication number
WO2023051060A1
WO2023051060A1 PCT/CN2022/112510 CN2022112510W WO2023051060A1 WO 2023051060 A1 WO2023051060 A1 WO 2023051060A1 CN 2022112510 W CN2022112510 W CN 2022112510W WO 2023051060 A1 WO2023051060 A1 WO 2023051060A1
Authority
WO
WIPO (PCT)
Prior art keywords
identity verification
verification request
response
request
base station
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/112510
Other languages
English (en)
French (fr)
Inventor
李海波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to US18/571,646 priority Critical patent/US20240284266A1/en
Priority to EP22874455.3A priority patent/EP4340422B1/en
Publication of WO2023051060A1 publication Critical patent/WO2023051060A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/14Reselecting a network or an air interface
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/30Connection release
    • H04W76/38Connection release triggered by timers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/02Arrangements for optimising operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]

Definitions

  • the present application relates to the communication field, in particular to a method and a terminal for reducing the call drop rate.
  • Call drop rate is an important indicator in mobile communication, also known as call interruption rate, which refers to the probability of accidental interruption of communication during the process of mobile communication.
  • the call drop rate is a very important index in the mobile communication network, and the level of the call drop rate reflects the quality of the mobile network communication to a certain extent. Therefore, reducing the call drop rate of users has become the focus of network optimization projects.
  • the solutions for reducing the call drop rate given by terminal manufacturers are usually aimed at the call drop caused by wireless network call drop, Abis interface call drop, A interface call drop, TC interface call drop, etc.
  • the stage of identity verification and authentication between the network side and the terminal side will also cause call drop phenomenon, for example, the calling party and the called party adopt the Circuit Switched Fallback (CSFB) technology, or the dual-mode single-standby wireless voice call continuity (Single When the Radio Voice Call Continuity (SRVCC) technology calls to the core network (Core Network, CN), the CN will initiate an identity verification request to the terminal and start the T3360 timer.
  • CSFB Circuit Switched Fallback
  • SRVCC Radio Voice Call Continuity
  • the terminal When the T3360 timer expires, if the terminal fails to authenticate in time A successful response message is sent to CN, and CN will retransmit the identity verification request. From the actual situation, for the retransmitted identity verification request, the Universal Subscriber Identity Card (Universal Subscriber Identity Card) used in the terminal for identity verification and authentication Module, USIM) will return authentication failure because the two authentication requests are completely consistent, and the reason value is Synch failure. In this case, the terminal will start the T3320 timer after receiving the identity verification response of the verification failure from the USIM. After verifying the request, the T3320 timer will trigger the call drop and other processes after the timer expires.
  • the Universal Subscriber Identity Card Universal Subscriber Identity Card
  • this application provides a method and terminal for reducing the call drop rate, which can effectively avoid misjudgment in the identity verification and authentication stage, thereby solving the problem of call drop in the identity verification and authentication stage caused by misjudgment in the above user scenario to reduce the call drop rate and improve user experience.
  • the present application provides a method for reducing the call drop rate.
  • the method is applied to a terminal, and includes: receiving a first identity verification request sent by a base station, the first identity verification request is initiated by the core network, and after the core network sends the first identity verification request to the base station, starting a T3360 timer; responding to the first For the identity verification request, the base station sends to the core network the first identity verification response for the successful verification of the first identity verification request; the second identity verification request sent by the base station is received, and the second identity verification request is corresponded by the core network at T3360 timer Initiate after the end of the timing period; determine whether the first identity verification request and the second identity verification request are the same; Send the second identity verification response for the verification failure of the second identity verification request, and start the T3320 timer; within the timing duration corresponding to the T3320 timer, obtain the direction information of the currently executing call service, the call service and the first identity
  • the verification request is associated with the second identity verification request; judging whether
  • the core network performs identity authentication with the terminal according to the normal process, and the terminal receives the second identity authentication after the first identity authentication.
  • the method further includes: determining that the first identity verification request is received obtain the first moment; obtain the session identification number of the call service corresponding to the first identity verification request; generate an authentication tuple according to the first identity verification request, the first identity verification response, the session identification number, and the first moment ; Establish and save the corresponding relationship between the first identity verification request and the authentication tuple.
  • the first identity verification response recorded in the authentication tuple can be directly reused, preventing the USIM from mistaking the core network synchronization abnormality, that is, SQN out of range, and returning the second identity verification that the authentication failed Response, causing the terminal to trigger the call drop process.
  • the first identity verification request recorded in the authentication tuple includes a random number and an authentication value; wherein, the authentication value is calculated based on the random number. Because the USIM in the terminal needs to use the authentication value in the first identity verification request when performing identity verification and authentication on the first identity verification request, and the authentication value is obtained based on random number calculation, so that different identities can be distinguished Verification request. Therefore, in the method for reducing the call drop rate provided by the present application, the first identity verification request required when generating the authentication tuple includes at least a random number and an authentication value.
  • the first identity verification response recorded in the authentication tuple includes an A&C reference number, an actual response value and an expected response value. Since in an actual application scenario, multiple authentication tuples corresponding to different identity verification requests may be saved in the terminal, so in order to facilitate finding the first identity verification response that can be multiplexed to the second identity verification request, this application provides In the method for reducing the call drop rate, the first identity verification response required when generating the authentication tuple includes a reference number that can identify the response, and the actual response value calculated according to the message in the first identity verification request and the expected response value expected by the core network, so as to facilitate the determination of whether the authentication is successful.
  • the method also includes: judging whether there is an authentication tuple corresponding to the first identity verification request; when there is an authentication tuple corresponding to the first identity verification request, extracting the first identity from the authentication tuple The verification response is used as the second identity verification response for the successful verification of the second identity verification request, and the second identity verification response is sent to the core network through the base station; when there is no authentication tuple corresponding to the first identity verification request, In response to the second identity verification request, the base station sends to the core network a second identity verification response that fails verification for the second identity verification request, and starts a T3320 timer.
  • the terminal when receiving the same second identity verification request as the first identity verification request, the terminal first checks whether the stored authentication tuple can be reused for the second identity verification request, and then decides whether to directly multiplex the existing authentication tuple based on the result.
  • the authentication result, or the USIM re-responses to the second identity verification request for identity verification and authentication operations, so as to prevent the USIM from returning the authentication failure, thereby preventing the execution of the call drop process from the source, and effectively reducing the call drop rate.
  • the first identity verification request sent by the base station is received, and in response to the first identity verification request, the base station sends to the core network a first identity verification response for successful verification of the first identity verification request, including: through the antenna Receiving the first identity verification request sent by the base station; determining the first USIM to process the first identity verification request; sending the first identity verification request to the first USIM through a modem associated with the first USIM; responding to the first USIM by the first USIM An identity verification request, sending a successful first identity verification response to the first identity verification request to the modem; the modem sends the first identity verification response of successful verification to the base station through the antenna, and the base station sends a successful verification response to the core network.
  • the first authentication response for is directly implemented on the Model layer of the terminal, without interaction with the upper layer, and without user intervention, so that the call drop problem in the identity verification and authentication stage can be solved without the user's perception .
  • two USIMs are set in the terminal; receiving the second identity verification request sent by the base station, judging whether the first identity verification request and the second identity verification request are the same, Including: receiving the second identity verification request sent by the base station through the antenna; determining the second USIM to process the second identity verification request; sending the second identity verification request to the second USIM through a modem associated with the second USIM; When a USIM and the second USIM are the same USIM, the first USIM judges whether the first identity verification request and the second identity verification request are the same; when the first USIM and the second USIM are different USIMs, the second USIM responds For the second identity verification request, send a successful second identity verification response to the second identity verification request to the modem associated with the second USIM; the modem associated with the second USIM sends the successful second identity verification response through the antenna sent to the base station, and the base station sends a second identity verification response of successful verification to the core network.
  • judging whether the first identity verification request and the second identity verification request are the same includes: respectively determining the system time and the time when the first identity verification request is received The system time at the time of the second identity verification request, get the first moment and the second moment; judge whether the time interval between the first moment and the second moment is less than the time threshold; when the time interval is less than the time threshold, judge the first identity verification Whether the content of the request is consistent with the content of the second identity verification request; when the content of the first identity verification request is consistent with the content of the second identity verification request, obtain the session identification number and the second The session identification number of the call service corresponding to the second identity verification request; judge whether the session identification number of the call service corresponding to the first identity verification request is the same as the session identification number of the call service corresponding to the second identity verification request; When the session identification number of the corresponding call service is the same as the session identification number of the call service corresponding to the second identity verification request, it is determined that the first identity verification request is
  • the second identity verification request Whether the request is the first authentication request for retransmission, so as to avoid the call drop problem caused by the authentication failure caused by the misjudgment of the retransmitted authentication request in the existing authentication and authentication stage, and to avoid the problem of using different identities
  • the verification request is mistaken for a retransmission request, resulting in the inability to execute new call services smoothly.
  • judging whether the content of the first identity verification request is consistent with the content of the second identity verification request includes: obtaining the first serial number corresponding to the first identity verification request The second serial number corresponding to the second identity verification request; wherein, for different identity verification requests, the serial numbers are different; judging whether the first serial number and the second serial number are the same; between the first serial number and the second serial number If they are the same, it is determined that the contents of the first identity verification request and the second identity verification request are consistent. In this way, it is fast and convenient to determine whether the two identity verification requests are the same by comparing the serial numbers that can identify their uniqueness in the two identity verification requests without comparing the specific content in the two identity verification requests.
  • the base station in response to the second identity verification request, sends a second identity verification response that fails to verify the second identity verification request to the core network, and starts T3320 timer, including: responding to the second identity verification request by the first USIM, generating a second identity verification response whose cause of verification failure is Synch failure; sending the second identity verification response to the modem by the first USIM; by the modem Send the second identity verification response of verification failure to the base station through the antenna, and the base station sends the second identity verification response of verification failure to the core network.
  • the USIM that processes the second identity verification request in this application returns the second identity verification of Synch failure as the cause of verification failure. response, so that the terminal can start the T3320 timer after sending the second identity verification response to the base station.
  • judging whether the call service is redirected to a successful direction according to the direction information including: judging whether the direction information is Routing Area Update Accept, or Service Accept, or connect, or connect act; when the direction information is Routing Area Update Accept, or Service Accept, or connect, or connect act, it is determined that the call service is to jump in the direction of success.
  • the method further includes: after the first identity verification request and the second identity verification request If different, in response to the second identity verification request, the base station sends to the core network a second identity verification response that is successfully verified for the second identity verification request.
  • the terminal processes it according to the normal authentication process, thus taking into account the normal The execution of the authentication process can avoid misjudgment of the retransmitted identity verification request.
  • the present application provides a terminal.
  • the terminal includes: at least one USIM, a modem associated with the at least one USIM, one or more processors, memory, and one or more computer programs; wherein the one or more computer programs are stored on the memory, when the computer When the program is executed by one or more processors, the terminal can execute the method in the first aspect or any possible implementation manner of the first aspect.
  • the present application provides a computer-readable medium for storing a computer program, where the computer program includes instructions for executing the method in the first aspect or any possible implementation manner of the first aspect.
  • the present application provides a computer program, where the computer program includes instructions for executing the method in the first aspect or any possible implementation manner of the first aspect.
  • the present application provides a chip.
  • the chip includes: one or more processing circuits and one or more sending and receiving pins; wherein, the sending and receiving pins and the processing circuits communicate with each other through an internal connection path, and the processing circuits perform any one of the first aspect or the first aspect.
  • the method in the implementation manner is used to control the receiving pin to receive a signal, and to control the sending pin to send a signal.
  • the present application provides a system for reducing the call drop rate.
  • the system includes a base station, a core network and the terminal involved in the second aspect above.
  • FIG. 1 is a sequence diagram of an exemplary identity verification and authentication phase
  • FIG. 2 is a schematic diagram of a call drop scenario in an exemplary identity verification and authentication stage
  • FIG. 3 is a schematic diagram of a hardware structure of a terminal exemplarily shown
  • Fig. 4 is one of the schematic flow charts of the method for reducing the call drop rate provided by the embodiment of the present application.
  • Fig. 5 is a sequence diagram of the interaction process between entities involved in the method for reducing the call drop rate provided in Fig. 4 exemplarily shown;
  • Fig. 6 is the second schematic flow diagram of the method for reducing the call drop rate provided by the embodiment of the present application.
  • FIG. 7 is a sequence diagram of the interaction process between entities involved in the implementation of the method for reducing the call drop rate provided in FIG. 6;
  • Fig. 8 is a third schematic flowchart of the method for reducing the call drop rate provided by the embodiment of the present application.
  • first and second in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order of objects.
  • first target object, the second target object, etc. are used to distinguish different target objects, rather than describing a specific order of the target objects.
  • words such as “exemplary” or “for example” are used as examples, illustrations or illustrations. Any embodiment or design scheme described as “exemplary” or “for example” in the embodiments of the present application shall not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Rather, the use of words such as “exemplary” or “such as” is intended to present related concepts in a concrete manner.
  • multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.
  • the method for reducing the call drop rate provided by the embodiment of the present application is specifically aimed at the identity verification and authentication stage.
  • the data exchanged between the terminal and the core network is usually forwarded by the base station. Therefore, in the actual application scenario, the network authorization size for the terminal to access through the base station directly affects the time it takes for the terminal capability information to be reported to the base station.
  • the verification request is sent to the terminal, so the terminal's response message in response to the base station's request to inquire about its capabilities is queued before the response message in response to the identity verification request. Therefore, the successful authentication response sent by the terminal for the identity verification request may not reach the base station within the time period corresponding to the T3360 timer. In this case, the base station will retransmit the last identity verification request, thereby As a result, the USIM in the terminal misjudges and triggers the call drop process.
  • a terminal such as a calling terminal or a called terminal
  • the base station will send a terminal capability query request to the terminal, that is, step 101 is executed.
  • the terminal when the terminal receives the terminal capability query request sent by the base station, it will respond to the request and continuously report the obtained terminal capability information segments (subsequently denoted by SEG), such as SEG-1 to SEG-N, to the base station , that is, the operations of step 102 and step 102' are performed.
  • SEG terminal capability information segments
  • the terminal capability information fragments queued to be reported to the base station in the queue may not be fully uploaded.
  • the first identity verification request sent to the terminal arrives at the terminal, that is, the operation in step 103 .
  • the terminal After the terminal receives the first identity verification request from the core network sent by the base station, it will hand over the first identity verification request to the built-in USIM or SIM card, that is, step 104 is executed.
  • the USIM or SIM card will perform identity verification and authentication processing in response to the first identity verification request, and then obtain a first identity verification response to the first identity verification request, and feed back the first identity verification response to the terminal, That is, step 105 is executed.
  • the first identity verification response for the first identity verification request is a successful verification, but since there are still unreported terminal capability information fragments in the queue currently sending messages to the base station, such as SEG-N, therefore
  • the obtained first identity verification response needs to be ranked after the terminal capability information SEG-N, that is, after the terminal capability information SEG-N is reported to the base station, the first identity verification response will be sent to the base station, and then the base station will forward it to The core network, that is, step 106.
  • the core network after the core network initiates the first identity verification request, it will start the T3360 timer, and the core network will retransmit the last identity verification after the T3360 timer expires (the timing duration is generally set to 6s).
  • request that is, step 107 is executed, and the base station sends a second identity verification request to the terminal.
  • the second identity verification request in step 107 is essentially the first identity verification request, that is, the content and the corresponding call service session identification number and other information are all the same .
  • the terminal after receiving the second identity verification request, the terminal will also hand it over to the USIM or SIM for identity verification and authentication processing, that is, step 108 is executed.
  • the USIM or SIM will perform identity verification and authentication processing in response to the second identity verification request, and then obtain the first identity verification response to the second identity verification request, and feed back the second identity verification response to the terminal, that is, Go to step 109.
  • the second identity verification request is a retransmitted first identity verification request, and the USIM or SIM has already made a successful first identity verification response to the first identity verification request, the second identity verification request is received again at this time.
  • the identity verification request will mistakenly think that the identity verification with the core network fails, so it will return a verification failure, and the specific reason value of the verification failure carried can be Synch failure.
  • the terminal after receiving the failed second identity verification response, the terminal sends the failed second identity verification response to the base station, and then the base station forwards it to the core network, that is, executes step 110 .
  • the terminal after sending the second identity verification response whose cause of verification failure is Synch failure, the terminal will start the T3320 timer and wait for the core network to re-initiate the identity verification request. If the core network does not re-initiate an identity verification request within the time period corresponding to the timer, the call drop process will be automatically triggered after the T3320 timer expires, that is, step 111 .
  • the first identity verification response that has been successfully verified has not been discarded, and the core network has only delayed receipt, that is, after the core network retransmits the last identity verification request, although the T3360 timer has expired, the first
  • the successful first authentication response of the second authentication request will arrive at the core network before the second authentication failure response, so the core network will mistakenly think that the received first authentication response is for the second authentication request Yes, since the response received is a successful authentication, the call service will continue, that is, the core network will not re-initiate the identity authentication request within the time period corresponding to the T3320 timer, so for the terminal, the T3320 timer
  • the call drop process will inevitably be executed. Specifically, the local release is performed first, and then the current call is dropped by the Bar, and the link is actively disconnected, resulting in call drop.
  • FIG. 2 is a schematic diagram of a scenario where a call drop occurs during the identity verification and authentication phase shown in FIG. 1 .
  • the core network when a user uses USIM_1 in terminal A to call USIM_2 in terminal B, the core network will send a first-person authentication request to terminal A through the base station, and USIM_1 in terminal A will perform identity verification.
  • Terminal A, the base station, and the core network are executed in accordance with the above steps 101 to 110.
  • the core network Before the second identity verification response of verification failure reaches the core network, the core network has received the first identity verification response of successful verification. In this case
  • the core network will send the call request from USIM_1 in terminal A to USIM_2 in terminal B to terminal B through the base station. If the called user answers the current call, terminal A cannot receive it within the time period corresponding to the T3320 timer.
  • the call drop process will be executed, so that the established call will be interrupted, as shown in Figure 2.
  • the communication link between terminal A and the base station, And the communication link between the base station and terminal B will be disconnected.
  • the method for reducing the call drop rate provided by the embodiment of the present application. This method does not require any modifications to the core network, base stations, and USIM.
  • the core network performs identity verification with the terminal according to the normal process, and the terminal receives the second identity verification request after the first identity verification. Compare the first identity verification request with the second identity verification request. After determining that the second identity verification fails, monitor the direction of the call service within the time period corresponding to the T3320 timer, and determine that the call service is in the direction of success.
  • FIG. 3 it is a schematic diagram of a hardware structure of a terminal 100 exemplarily shown to implement the method for reducing the call drop rate provided by the embodiment of the present application.
  • the terminal 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charging management module 140, a power management module 141, and a battery 142 , antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (subscriber identification module , SIM) card interface 195 etc.
  • antenna 1 and antenna 2 are used for transmitting and receiving electromagnetic wave signals.
  • Each antenna in terminal 100 may be used to cover single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas.
  • Antenna 1 can be multiplexed as a diversity antenna of a wireless local area network.
  • the antenna may be used in conjunction with a tuning switch.
  • the terminal receives the identity verification request sent by the base station and sends the identity verification response to the base station through antenna 1 or antenna 2.
  • the mobile communication module 150 can provide wireless communication solutions including 2G/3G/4G/5G applied on the terminal 100 .
  • the mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA) and the like.
  • the wireless communication module 160 can provide wireless local area networks (wireless local area networks, WLAN) (such as wireless fidelity (Wi-Fi) network), bluetooth (bluetooth, BT), global navigation satellite system, etc. (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field communication technology (near field communication, NFC), infrared technology (infrared, IR) and other wireless communication solutions.
  • WLAN wireless local area networks
  • WiFi wireless fidelity
  • BT Bluetooth
  • global navigation satellite system etc.
  • GNSS global navigation satellite system
  • FM frequency modulation
  • NFC near field communication technology
  • infrared technology infrared, IR
  • the antenna 1 of the terminal 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the terminal 100 can communicate with the network and other devices through wireless communication technology.
  • the audio module 170 of the terminal 100 includes a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, and the like.
  • the terminal 100 can implement audio functions such as music playback, recording, and voice calls through the speaker 170A, receiver 170B, microphone 170C, earphone interface 170D, and application processor in the audio module 170 .
  • audio functions such as music playback, recording, and voice calls through the speaker 170A, receiver 170B, microphone 170C, earphone interface 170D, and application processor in the audio module 170 .
  • the sensor module 180 in the terminal 100 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, Ambient light sensors, bone conduction sensors, etc. are not listed here, and this application does not limit them.
  • the processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processing unit device (graphics processing unit, GPU), image signal processor (image signal processor, ISP), controller, memory, video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or Neural-network processing unit (NPU), etc.
  • application processor application processor, AP
  • modem processor graphics processing unit device
  • graphics processing unit device graphics processing unit, GPU
  • image signal processor image signal processor
  • ISP image signal processor
  • controller memory
  • video codec digital signal processor
  • DSP digital signal processor
  • baseband processor baseband processor
  • NPU Neural-network processing unit
  • processing units may be independent devices, or may be integrated in one or more processors.
  • the controller may be the nerve center and command center of the terminal 100 .
  • the controller can generate an operation control signal according to the instruction opcode and timing signal, and complete the control of fetching and executing the instruction.
  • the memory in the processor 110 is mainly used to store instructions and data.
  • the memory in processor 110 is a cache memory.
  • USB interface 130 shown in FIG. 3 is an interface conforming to the USB standard specification, specifically, it may be a Mini USB interface, a Micro USB interface, a USB Type C interface, and the like.
  • the charging management module 140 is configured to receive a charging input from a charger.
  • the power management module 141 shown in FIG. 3 is used to connect the battery 142 , the charging management module 140 and the processor 110 .
  • the power management module 141 receives the input from the battery 142 and/or the charging management module 140 to provide power for the processor 110 , the internal memory 121 , the external memory, the display screen 194 , the camera 193 , and the wireless communication module 160 .
  • the wireless communication function of the terminal 100 can be realized by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.
  • the terminal 100 shown in FIG. 3 implements a display function through a GPU, a display screen 194, an application processor, and the like.
  • the GPU is a microprocessor for image processing, and is connected to the display screen 194 and the application processor. GPUs are used to perform mathematical and geometric calculations for graphics rendering.
  • Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.
  • the display screen 194 is specifically used for displaying images, videos and the like.
  • the display screen 194 includes a display panel.
  • the terminal 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.
  • the display screen is also used to cooperate with sensors, such as pressure sensors, so that the terminal can determine where the application triggered by the user is located, and then determine the specific location of the application triggered by the user. What application was triggered.
  • the terminal 100 can implement a shooting function through an ISP, a camera 193 , a video codec, a GPU, a display screen 194 , and an application processor.
  • the camera 193 is used to capture still images or videos.
  • the terminal 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.
  • the external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal 100.
  • the external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. Such as saving music, video and other files in the external memory card.
  • the internal memory 121 may be used to store computer-executable program code, which includes instructions.
  • the processor 110 executes various functional applications and data processing of the terminal 100 by executing instructions stored in the internal memory 121 .
  • relevant instructions for implementing the method for reducing the call drop rate provided by the embodiment of the present application are pre-stored in the internal memory 121, and the processor 110 can execute the instructions stored in the internal memory 121, so that the terminal 100 can execute the embodiment of the present application.
  • the method provided to reduce the dropped call rate is pre-stored in the internal memory 121, and the processor 110 can execute the instructions stored in the internal memory 121, so that the terminal 100 can execute the embodiment of the present application.
  • the method provided to reduce the dropped call rate.
  • the motor 191 may be, for example, a vibration motor; the indicator 192 may be an indicator light.
  • the SIM card interface 195 is used for connecting a SIM card or a USIM card.
  • the SIM card can be connected and separated from the terminal 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195 .
  • the terminal 100 may support 1 or N (N is an integer greater than 1) SIM card interfaces 195 . That is, multiple SIM cards or USIM cards can be inserted into the terminal.
  • each terminal in addition to a SIM card or a USIM card (hereinafter collectively referred to as USIM), each terminal will also be provided with a modem (Modem) corresponding to or associated with the USIM, and the Modem
  • Modem modem
  • the number can be the same as the number of USIMs, and they correspond one by one.
  • each USIM in the terminal corresponds to a Modem, so that the call service of each USIM can be directly processed by the Modem associated with it, for example, when the antenna receives the identity verification request for USIM1 initiated by the core network sent by the base station , the identity verification request will be handed over to Modem1 associated with USIM1, and then Modem1 will hand over the identity verification request to USIM1 for processing.
  • the number of Modems may be different from the number of USIMs.
  • the number of Modems may be different from the number of USIMs.
  • the relationship between the Modem and each USIM can be maintained by the Modem itself, which is not limited in this application.
  • terminal 100 may be combined, or may have different component configurations.
  • the various components shown in Figure 3 may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application specific integrated circuits.
  • a specific implementation of a method for reducing the call drop rate provided by the embodiment of the present application specifically includes:
  • Step 201 receiving a first identity verification request sent by a base station.
  • the terminal used to receive the first identity verification request sent by the base station may be, for example, a UE (User Equipment) often referred to in the field of mobile communications.
  • UE User Equipment
  • the user terminal is called UE, which is equivalent to MS (Mobile Station) in 2G network, that is, a mobile station/mobile station with the characteristics of both a workstation and a notebook computer. Therefore, in some other embodiments, the terminal for receiving the first identity verification request sent by the base station may also be the MS.
  • MS Mobile Station
  • UEs include but are not limited to mobile phones, smart terminals, multimedia devices, streaming media devices, etc., which are not listed here and are not limited in this application.
  • this embodiment takes a mobile phone as an example.
  • the identity verification and authentication operation between the core network and the terminal is essentially completed by the USIM set in the terminal. That is, after receiving the first identity verification request sent by the base station, the terminal will hand it over to the corresponding USIM for identity verification and authentication.
  • the antenna in the terminal is used to receive and transmit electromagnetic wave signals. Therefore, the terminal receives the first identity verification request sent by the base station through the internal antenna, and then sends the first identity verification request to the USIM through the Modem associated with the USIM for identity verification and authentication processing.
  • the terminal receives the first USIM sent by the base station through the antenna. After verifying the request, it is necessary to first determine the USIM that processes the first identity verification request.
  • the USIM that processes the first identity verification request can be called the first USIM, and then use the modem associated with the first USIM to send the first USIM to the USIM.
  • An identity verification request is sent to the first USIM.
  • the first USIM used to process the first identity verification request is the originator of the call service corresponding to the first identity verification request.
  • the core network after the core network sends the first identity verification request to the base station, it will start a T3360 timer according to the stipulations of the 3GPP protocol, and set a corresponding timing duration, such as 6s.
  • the timing duration set for the T3360 timer can be determined according to the current network situation, the authorized amount occupied by the terminal, and the real-time requirements of the business scenario.
  • the specific setting method is not limited or explained in this application .
  • Step 202 In response to the first identity verification request, the base station sends to the core network a first identity verification response indicating successful verification of the first identity verification request.
  • the operation in response to the first identity verification request in step 202 is performed by the USIM set in the terminal, that is, the USIM will perform identity verification and authentication processing according to the received first identity verification request.
  • the authorization process is not modified in this embodiment and will not be described here.
  • the USIM After the USIM completes the identity verification and authentication process for the first identity verification request, it will send the first identity verification response to the first identity verification request to the associated Modem, and then the Modem will send the first identity
  • the verification response is delivered to the antenna, and the first identity verification response is sent to the base station through the antenna, so that the base station can forward the first identity verification response to the core network.
  • the authentication result of the USIM to the first identity verification request is nothing more than authentication success (authentication success) or authentication failure (authentication failure), and after the authentication fails, the core network No matter whether the T3360 timer is started or not, after receiving the first identity verification response of verification failure, the call service will not continue to jump, but will initiate the operation of retransmitting the identity verification request, so the terminal will start after the verification fails.
  • the retransmitted identity verification request can be received within the time period corresponding to the T3320 timer, so the call drop process will not be triggered. Therefore, this embodiment mainly addresses the problem of call drop caused by retransmission of the identity verification request before the core network delays receiving the first identity verification response of successful verification when the authentication result is successful.
  • the USIM makes a first identity verification response of successful verification.
  • Step 203 receiving a second identity verification request sent by the base station.
  • step 201 For details of the receiving process, refer to the description in step 201, which will not be repeated here.
  • Step 204 judging whether the first identity verification request is the same as the second identity verification request.
  • the USIM can perform judgment processing, and then give a processing As a result, it can also be determined directly by the terminal without going through the USIM.
  • this embodiment takes the scenario that needs to be judged by the USIM as an example, that is, the antenna needs to hand over the received second identity verification request to the Modem, and then the Modem hands it to the associated USIM for processing .
  • all identity verification requests received by the terminal are processed by the USIM for identity verification and authentication.
  • the request in one example, can be compared to a sequence number that uniquely identifies each authentication request.
  • the USIM can identify the first identity verification request and the second identity verification request.
  • the first authentication request and the second authentication request are different.
  • the second identity verification request when the core network retransmits the identity verification request for the first identity verification request after the time period corresponding to the T3360 timer expires, the second identity verification request is actually the first identity verification request.
  • the contents, corresponding serial numbers, and call services carried by the two identity verification requests are completely the same, so in this case, the USIM will consider the first identity verification request and the second identity verification request to be the same.
  • the time interval between two identity verification requests and the call service corresponding to each identity verification request will also affect the judgment result. Even if the serial numbers of the two are the same, if the time interval is greater than a certain threshold, Or the corresponding call services are different, and the two authentication requests cannot be directly regarded as the same. Therefore, when judging whether the first identity verification request and the second identity verification request are the same, two factors, time interval and call service, may also be introduced.
  • the USIM after receiving the second identity verification request, the USIM will respectively determine the system time when receiving the first identity verification request and the system time when receiving the second identity verification request, and obtain the first moment and the second moment ; Then, judge whether the time interval between the first moment and the second moment is smaller than the time threshold.
  • the USIM will continue to judge whether the content of the first identity verification request is consistent with the content of the second identity verification request, for example, it can be determined by comparing the serial numbers that can identify each identity verification request.
  • the USIM will also obtain the session identification number of the call service corresponding to the first identity verification request and the call service corresponding to the second identity verification request Then, continue to judge whether the session identification number of the call service corresponding to the first identity verification request is the same as the session identification number of the call service corresponding to the second identity verification request.
  • the session identification number of the call service corresponding to the first identity verification request is the same as the session identification number of the call service corresponding to the second identity verification request, it is determined that the first identity verification request is the same as the second identity verification request.
  • step 204 if it is judged that the first identity verification request and the second identity verification request are the same, go to step 205; otherwise, go to step 210.
  • the terminal judges the first identity verification request and the second identity verification request after receiving the second identity verification request sent by the base station.
  • the terminal judges the first identity verification request and the second identity verification request after receiving the second identity verification request sent by the base station.
  • the operations of the above steps 203 and 204 are as follows: first receive the second identity verification request sent by the base station through the antenna; then, determine the second identity verification request to be processed.
  • the USIM judges whether the first identity verification request and the second identity verification request are the same; when the first USIM and the second USIM are different USIMs, the second USIM will respond to the second identity verification request and make a decision on the second identity verification request.
  • the second identity verification response of successful verification is sent to the modem; the modem sends the second identity verification response of successful verification to the base station through the antenna, and the base station sends the second identity verification response of successful verification to the core network.
  • Step 205 In response to the second identity verification request, the base station sends to the core network a second identity verification response that fails verification for the second identity verification request, and starts a T3320 timer.
  • step 205 the operation in response to the second identity verification request is still performed by the USIM, but when the USIM determines that the first identity verification request and the second identity verification request are the same, the USIM will mistakenly believe that it is the same as the core identity verification request.
  • the identity verification of the network fails, so it will return a verification failure, and the specific reason value of the verification failure can be Synch failure. That is, a second identity verification response of verification failure is made for the second identity verification request.
  • the USIM will send the authentication result to the Modem associated with it, and then the Modem will send it to the base station through the antenna, so that the base station will regard the authentication result as verification failure.
  • the second identity verification response is sent to the core network.
  • the terminal will start the T3320 timer after sending the second identity verification response whose cause of verification failure is Synch failure, and wait for the core network to re-initiate the identity verification request. If the core network does not re-initiate an identity verification request within the time period corresponding to the T3320 timer, the call drop process will be automatically triggered after the T3320 timer expires, that is, step 209 will be entered.
  • the terminal after the terminal sends the second identity verification response whose cause of verification failure is Synch failure to the base station through the antenna, it will start the T3320 timer and set the corresponding timing duration.
  • the timing duration set for the T3320 timer can also be determined according to the current network conditions, the amount of authorization occupied by the terminal, and the real-time requirements of the business scenario. Without limitation and description.
  • Step 206 within the timing duration corresponding to the T3320 timer, obtain the direction information of the currently executing call service.
  • the terminal After the terminal sends the second identity verification response with the cause of verification failure as Synch failure to the base station through the antenna, it will monitor whether there is a retransmitted identity verification request within the time period corresponding to the started T3320 timer. At the same time, it will also monitor whether there is a call service being executed, and obtain the direction information of the currently executed call service.
  • Step 207 judging whether the call service is redirected to a successful direction according to the direction information.
  • step 207 if it is determined through judgment that the call service is redirected to a successful direction, then go to step 208; otherwise, go to step 209.
  • the direction information is Routing Area Update Accept, or Service Accept, or connect, or connect act
  • the current call service usually jumps in the direction of success Therefore, in this embodiment, when judging whether the call service is redirected to a successful direction according to the direction information, it is specifically determined whether the direction information is Routing Area Update Accept, or Service Accept, or connect, or connect act.
  • the direction information is Routing Area Update Accept, or Service Accept, or connect, or connect act, it is determined that the call service is to jump in the direction of success.
  • Step 208 close the T3320 timer.
  • the core network when it is determined according to the direction information that the current call service is redirected to the successful direction, it means that the core network will not retransmit the identity verification request to the terminal. The process will cause the call to be dropped and affect the user experience. The terminal will actively close the T3320 timer, thus preventing the execution of the call drop process.
  • Step 209 after the T3320 timer expires, execute the call drop process.
  • call drop process performed when the T3320 timer expires is specifically to perform local release first, then Bar drops the current call, actively disconnects the link, and then causes call drop.
  • the method for reducing the call drop rate provided by this embodiment still has the situation that the call drop process is triggered after the T3320 timer expires, it is found through actual tests that the core network receives the delayed After verifying the successful first identity verification message, the direction information sent to the terminal when the call service is triggered to jump in the successful direction is usually obtained by the terminal within the time period corresponding to the T3320 timer. Therefore, the reduction provided by this embodiment is adopted.
  • the call drop rate method can largely avoid call drop during the identity verification and authentication phase, thereby reducing the call drop rate and improving user experience.
  • Step 210 In response to the second identity verification request, the base station sends to the core network a second identity verification response that is successfully verified for the second identity verification request.
  • the processing of the second identity verification request by the terminal is similar to the processing of the first identity verification request.
  • the processing of the second identity verification request by the terminal is similar to the processing of the first identity verification request.
  • the specific processing process see step 202 The description in , will not be repeated here.
  • the core network performs identity authentication with the terminal according to the normal process, and the terminal receives the second identity authentication after the first identity authentication.
  • Step 301 when the terminal calls to the core network CN using CSFB technology or SRVCC technology, the base station first sends a terminal capability query request to the terminal to obtain terminal capability information.
  • the terminal needs to establish a communication link with the base station, and receive and transmit electromagnetic wave signals transmitted in the communication link through an antenna.
  • the terminal obtains its own terminal capability information in response to the received terminal capability query request from the base station, for example, multiple terminal capability information SEGs, and continuously reports the obtained terminal capability information SEG to the base station, for example Terminal capability information SEG-1 to terminal capability information SEG-N in FIG. 5 .
  • terminal capability information SEGs obtained by the terminal namely SEG-1, SEG-2, SEG-3, SEG-4 and SEG-5
  • the terminal capability information will be added to the message sending queue in sequence, and sent to the base station in sequence according to the order in which they entered the queue. For example, send SEG-1 to the base station at time T1, send SEG-2 to the base station at time T2, send SEG-3 to the base station at time T3, send SEG-4 to the base station at time T4, and send SEG-2 to the base station at time T5. 5.
  • Step 303 during the process of the terminal sending the terminal capability information SEG to the base station, the core network sends a first identity verification request to the terminal through the base station.
  • the terminal receives the first identity verification request through an antenna.
  • the core network after the core network sends the first identity verification request to the terminal through the base station, it will start the T3360 timer and set the corresponding timing duration.
  • Step 304 the terminal sends the first identity verification request to the internally set USIM.
  • the Modem associated with the USIM sends the first identity verification request received by the antenna to the associated USIM, so that the USIM can perform identity verification according to the received first identity verification request. Right to handle.
  • Step 305 In response to the first identity verification request, the USIM makes a first identity verification response of successful verification for the first identity verification request, and sends the response to the terminal.
  • the first identity verification response is specifically sent to the terminal through the Modem associated with the USIM.
  • Step 306 the terminal sends the first identity verification response of successful verification to the base station, so that the base station sends the first identity verification response to the core network.
  • the terminal sends the first identity verification response to the base station, there are still three terminal capability information SEGs SEG-3, SEG-4 and SEG-5 in the message sending queue that have not been sent to the base station, and the verification is successful at this time
  • the first identity verification response needs to be added to the message queue, and the three terminal capability information SEGs are all sent to the base station before they can be sent.
  • the first identity verification response that is successfully verified needs to be sent at T6. .
  • the end time of the timing duration corresponding to the T3360 timer started by the core network is T5
  • the T3360 timer has timed out before the first identity verification response of successful verification reaches the core network, and the core network will trigger a retransmission of the identity verification at this time
  • the flow of the request is to execute step 307.
  • Step 307 the core network sends a second identity verification request to the terminal through the base station.
  • the second identity verification request sent by the core network after the T3360 timer expires is the retransmitted first identity verification request, that is, the first identity verification request received by the terminal and
  • the second authentication request is exactly the same.
  • Step 308 the terminal sends the second identity verification request to the internally set USIM.
  • the Modem associated with the USIM sends the second identity verification request received by the antenna to the associated USIM, so that the USIM can perform identity verification according to the received second identity verification request.
  • the Modem associated with the USIM sends the second identity verification request received by the antenna to the associated USIM, so that the USIM can perform identity verification according to the received second identity verification request.
  • the identity verification request retransmitted by the core network must be for the call service of the same USIM. Therefore, the second identity verification request received by the antenna is transmitted to the same USIM by the Modem that forwards the first identity verification request.
  • step 309 in response to the second identity verification request, the USIM makes a second identity verification response of verification failure for the second identity verification request, and sends the response to the terminal.
  • the second identity verification response is specifically sent to the terminal through the Modem associated with the USIM.
  • the USIM will compare the received second identity verification request with the first identity verification request, and then determine whether the two identity verification requests are the same, so as to make an appropriate authentication result.
  • first identity verification request and the second identity verification request are the same, and the USIM has already made a successful first identity verification response to the first identity verification request, here the first identity verification request is received again. If the same second identity verification request is requested, it will be misunderstood that the identity verification and authentication with the core network fails, so a second identity verification response of verification failure is made for the second identity verification request.
  • the cause value of the verification failure carried in the verification failure second identity verification response is specifically Synch failure .
  • Step 310 the terminal sends a second identity verification response that fails to be verified to the base station, so that the base station sends the second identity verification response to the core network.
  • the terminal sends the second identity verification response to the base station, there is still a message in the message sending queue that has not been sent to the base station, such as SEG-5, the first identity verification response, and the verification fails at this time
  • the second identity verification response needs to be added to the message queue, and can be sent only after SEG-5 and the first identity verification response are sent to the base station.
  • the second identity verification response that fails to be verified needs to be sent at T7. You can send.
  • the core network first receives the first identity verification response of successful verification before receiving the second identity verification response of verification failure.
  • the core network Since the first identity verification request and the second identity verification request are identical, the core network It will be misunderstood that the currently received first identity verification response is made by the terminal in response to the second identity verification request. And, because the authentication result of the first identity verification response is verification success, the core network will consider that the identity verification and authentication with the terminal is successful, so it will continue to execute the call service, and receive the first identity verification response after the first identity verification response. The received second identity verification response will be ignored by the core network, that is, the core network will not re-initiate the identity verification request according to the second identity verification response.
  • the terminal after the terminal sends the second identity verification response with the cause of verification failure as Synch failure to the core network through the base station, it will start the T3320 timer, set the corresponding timing duration, and set the timing duration Wait for the core network to re-initiate the identity verification request. If the core network does not re-initiate the identity verification request within the time period corresponding to the T3320 timer, the call drop process will be automatically triggered after the T3320 timer expires.
  • the terminal After the terminal sends the second identity verification response to the base station and starts the T3320 timer, it will monitor whether it has received the retransmitted identity verification request sent by the core network through the base station within the timing period, or directly monitor the currently executing call service Then, according to the direction information, it is determined whether the call service is redirected to a successful direction, that is, step 311 is executed.
  • Step 311 when the terminal detects that the currently executing call service is redirected to a successful direction within the timing duration corresponding to the T3320 timer, the terminal actively closes the T3320 timer.
  • step 207 For details on how to determine whether the call service is redirected to a successful direction according to the direction information, refer to the description of step 207 in the above embodiment, and details will not be repeated here.
  • the specific implementation of another method for reducing the call drop rate specifically includes:
  • Step 401 receiving a first identity verification request sent by a base station.
  • Step 402 In response to the first identity verification request, the base station sends to the core network a first identity verification response indicating successful verification of the first identity verification request.
  • step 401 and step 402 in this embodiment are roughly the same as step 201 and step 202 in the embodiment shown in FIG. I won't repeat them here.
  • step 403 an authentication tuple is generated, a corresponding relationship between the first identity verification request and the authentication tuple is established, and saved.
  • the authentication tuple generated in this embodiment is to directly reuse the identity verification response that the USIM has made for subsequent retransmission of the identity verification request, without the need for the USIM to process it again, thereby preventing the USIM from receiving
  • the second identity verification response with the cause of verification failure as Synch failure is made, and the T3320 timer is started at the same time, resulting in subsequent T3320
  • the call drop process is triggered when no identity verification request retransmitted by the core network is received within the time period corresponding to the timer.
  • the generated authentication tuple needs to include the first identity verification request and the first identity verification response that is successfully verified for the first identity verification request.
  • the session identification number of the call service corresponding to the first identity verification request.
  • the authentication tuple also needs to include The system time when the first authentication request was received.
  • the session identification number mentioned in this embodiment is a read-only value that uniquely identifies the current access session.
  • Session IDs are assigned sequentially, that is, Session ID "706616433” is followed by Session ID "706616434", so that it is possible to distinguish whether two authentication requests are the same.
  • the first identity verification request recorded in the authentication tuple includes a random number and an authentication value; wherein, the authentication value is calculated based on the random number.
  • the first identity verification request required when generating the authentication tuple includes a random number and an authentication value.
  • the first identity verification response recorded in the authentication tuple includes an A&C reference number, an actual response value and an expected response value.
  • the first identity verification response required when generating the authentication tuple includes a reference number that can identify the response, as well as the actual response value calculated according to the message in the first identity verification request and the expected value of the core network. The expected response value, so that it is convenient to determine whether the authentication is successful.
  • Step 404 receiving a second identity verification request sent by the base station.
  • step 404 in this embodiment is substantially the same as step 203 in the embodiment shown in FIG. 4 , and the specific implementation process of step 404 can be found in step 203 , and will not be repeated here.
  • Step 405 judging whether the first identity verification request is the same as the second identity verification request.
  • the retransmitted authentication request can directly reuse the authentication response stored in the authentication tuple.
  • the operation of whether the first identity verification request is the same as the second identity verification request is specifically completed by the terminal, that is, in this embodiment, the USIM does not process retransmitted identity verification requests. Therefore, after receiving the second identity verification request, the terminal will respectively determine the system time when receiving the first identity verification request and the system time when receiving the second identity verification request, and obtain the first moment and the second moment; then , judging whether the time interval between the first moment and the second moment is less than a time threshold.
  • the terminal when the time interval is less than the time threshold, the terminal will continue to judge whether the content of the first identity verification request is consistent with the content of the second identity verification request, for example, it can be determined by comparing the serial numbers that can identify each identity verification request.
  • the terminal when the content of the first identity verification request is consistent with the content of the second identity verification request, the terminal will respectively obtain the session identification number of the call service corresponding to the first identity verification request and the call service corresponding to the second identity verification request Then, continue to judge whether the session identification number of the call service corresponding to the first identity verification request is the same as the session identification number of the call service corresponding to the second identity verification request.
  • the session identification number of the call service corresponding to the first identity verification request is the same as the session identification number of the call service corresponding to the second identity verification request, it is determined that the first identity verification request is the same as the second identity verification request.
  • step 405 if it is determined that the first identity verification request is the same as the second identity verification request, go to step 406; otherwise, go to step 407.
  • Step 406 extracting the first identity verification response from the authentication tuple as the second identity verification response for the second identity verification request, and sending the second identity verification response to the core network through the base station.
  • the identity verification response recorded in the authentication tuple is directly multiplexed, and the USIM is not required to process the second identity verification request, so that the second identity verification response that fails verification will not be invoked, and the terminal is not allowed to start the T3320 timer.
  • Step 407 In response to the second identity verification request, the base station sends to the core network a second identity verification response that is successfully verified for the second identity verification request.
  • step 407 in this embodiment is substantially the same as step 210 in the embodiment shown in FIG. 4 , and the specific implementation process of step 407 is detailed in step 210 , which will not be repeated here.
  • the first identity verification response recorded in the authentication tuple can be directly reused, preventing the USIM from mistaking the core network synchronization abnormality, that is, SQN out of range, and returning the second identity verification that the authentication failed Response, causing the terminal to trigger the call drop process.
  • the terminal when receiving the same second identity verification request as the first identity verification request, the terminal first checks whether the stored authentication tuple can be multiplexed for the second identity verification request, and then decides to directly multiplex according to the result.
  • the existing authentication results are still handed over to the USIM to re-response to the second authentication request for authentication and authentication operations, so as to prevent the USIM from returning authentication failures, thereby preventing the execution of the call drop process from the source, and effectively reducing the call drop Rate.
  • Step 501 when the terminal calls to the core network CN using CSFB technology or SRVCC technology, the base station first sends a terminal capability query request to the terminal to acquire terminal capability information.
  • the terminal obtains its own terminal capability information in response to the received terminal capability query request from the base station, for example, it may be a plurality of terminal capability information SEGs, and continuously reports the obtained terminal capability information SEGs to the base station, for example Terminal capability information SEG-1 to terminal capability information SEG-N in FIG. 7 .
  • Step 503 during the process of the terminal sending the terminal capability information SEG to the base station, the core network sends a first identity verification request to the terminal through the base station.
  • Step 504 the terminal sends the first identity verification request to the internally set USIM.
  • Step 505 In response to the first identity verification request, the USIM makes a first identity verification response of successful verification for the first identity verification request, and sends the response to the terminal.
  • Step 506 the terminal sends the first identity verification response of successful verification to the base station, so that the base station sends the first identity verification response to the core network.
  • step 403 For the manner of generating and saving the authentication tuple, refer to the description of step 403 in the embodiment shown in FIG. 6 above, and details will not be repeated here.
  • Step 507 the core network sends a second identity verification request to the terminal through the base station.
  • steps 501 to 507 in the specific scenario description shown in FIG. 7 are substantially the same as steps 301 to 307 in the specific scenario description shown in FIG. 5 , and will not be repeated here.
  • Step 508 the terminal judges whether to reuse the saved authentication tuple.
  • the terminal needs to first judge whether the first identity verification request and the second identity verification request are the same, and determine whether the first identity verification request When the identity verification request is the same as the second identity verification request, it is judged whether there is an authentication multigroup corresponding to the first identity verification request.
  • the terminal needs to first judge whether the first identity verification request and the second identity verification request are the same, and determine whether the first identity verification request When the identity verification request is the same as the second identity verification request, it is judged whether there is an authentication multigroup corresponding to the first identity verification request.
  • the specific judgment process refer to the description of step 405 and step 406 in the above-mentioned embodiment, and will not be repeated here. repeat.
  • step 509 if it is determined that the saved authentication tuple can be reused, then enter step 509; otherwise, it means that the first identity verification request and the second identity verification request are different, and enter step 510, that is, trigger a new identity verification Authentication operation.
  • Step 509 the terminal extracts the first identity verification response from the authentication tuple as the second identity verification response for the second identity verification request, and sends the second identity verification response to the core network through the base station.
  • the terminal since the first identity verification response of successful verification is sent, the terminal will not start the T3320 timer, so that the call drop process will not be triggered.
  • Step 510 the terminal sends a second identity verification request to the internally set USIM.
  • Step 511 in response to the second identity verification request, the USIM makes a second identity verification response of successful verification for the second identity verification request, and sends the response to the terminal.
  • Step 512 the terminal sends a second identity verification response that is successfully verified to the base station, so that the base station sends the second identity verification response to the core network.
  • the second identity verification request is a second identity verification response of successful verification, so the terminal sends the second identity response of successful verification to the core network through the base station, so that the identity verification and authentication between the core network and the terminal can be successful , the call service can be carried out normally, thereby avoiding the problem of call drop in the identity verification and authentication stage.
  • steps 510 to 512 is the interaction between the USIM, the terminal, the base station, and the core network when the first identity verification request and the second identity verification request are different.
  • the subsequent established The session substance is responsive to the second identity.
  • this embodiment specifically combines the above two implementations, so that the identity verification and authentication stage can use the method shown in Figure 4.
  • the method for reducing the call drop rate in the embodiment is shown, and the method for reducing the call drop rate in the embodiment shown in FIG. 6 can also be used.
  • Step 601 receiving a first identity verification request sent by a base station.
  • Step 602 In response to the first identity verification request, the base station sends to the core network a first identity verification response that is successfully verified for the first identity verification request.
  • step 601 and step 602 in this embodiment are roughly the same as step 201 and step 202 in the embodiment shown in FIG. I won't repeat them here.
  • Step 603 Generate an authentication tuple, establish a correspondence between the first identity verification request and the authentication tuple, and save it.
  • step 603 in this embodiment is substantially the same as step 403 in the embodiment shown in FIG. 6 , and the specific implementation process of step 603 is detailed in step 403 , which will not be repeated here.
  • Step 604 receiving a second identity verification request sent by the base station.
  • Step 605 judging whether the first identity verification request is the same as the second identity verification request.
  • step 603 and step 604 in this embodiment are substantially the same as step 403 and step 404 in the embodiment shown in FIG. I won't repeat them here.
  • Step 606 judging whether there is an authentication tuple corresponding to the first identity verification request.
  • step 607 if it is determined through judgment that there is an authentication tuple corresponding to the first identity verification request, go to step 607 ; otherwise, go to step 608 .
  • the operation in step 606 may be to find out whether there is a corresponding authentication tuple according to the second identity verification request.
  • Step 607 extracting the first identity verification response from the authentication tuple as the second identity verification response for the successful verification of the second identity verification request, and sending the second identity verification response to the core network through the base station.
  • step 607 in this embodiment is substantially the same as step 406 in the embodiment shown in FIG. 6 , and the specific implementation process of step 607 is detailed in step 406 , which will not be repeated here.
  • Step 608 In response to the second identity verification request, the base station sends to the core network a second identity verification response that fails verification for the second identity verification request, and starts a T3320 timer.
  • Step 609 within the timing duration corresponding to the T3320 timer, acquire the direction information of the currently executing call service.
  • Step 610 judge whether the call service is redirected to a successful direction according to the direction information.
  • Step 611 close the T3320 timer.
  • Step 612 after the T3320 timer expires, execute the call drop process.
  • Step 613 In response to the second identity verification request, the base station sends to the core network a second identity verification response that is successfully verified for the second identity verification request.
  • steps 608 to 613 in this embodiment are roughly the same as steps 205 to 210 in the embodiment shown in FIG. I won't repeat them here.
  • the methods for reducing the call drop rate performed by the terminal may also be performed by a chip system included in the terminal, such as a USIM (or SIM) with a processing unit.
  • the chip system may include a processor.
  • the system-on-a-chip can be coupled with a memory, so that the system-on-a-chip invokes a computer program stored in the memory when running, so as to realize the above-mentioned steps executed by the terminal.
  • processor in the chip system may be an application processor or a non-application processor.
  • the embodiment of the present application also provides a computer-readable storage medium, the computer storage medium stores computer instructions, and when the computer instructions are run on the terminal, the terminal executes the above-mentioned related method steps to realize the application in the above-mentioned embodiments.
  • an embodiment of the present application also provides a computer program product, which, when running on a computer, causes the computer to execute the above related steps, so as to implement the method for reducing the call drop rate applied to the terminal in the above embodiment.
  • the embodiment of the present application also provides a system for reducing the call drop rate.
  • the system includes a base station, a core network, and a terminal for implementing the method for reducing the call drop rate in the foregoing embodiments.
  • embodiments of the present application also provide a chip (which may also be a component or module), which may include one or more processing circuits and one or more transceiver pins; wherein, the transceiver pins and the The processing circuits communicate with each other through internal connection paths, and the processing circuits execute the above-mentioned related method steps to realize the method for reducing the call drop rate in the above-mentioned embodiments, to control the receiving pin to receive signals, and to control the sending pin to send signals.
  • a chip which may also be a component or module
  • the processing circuits communicate with each other through internal connection paths, and the processing circuits execute the above-mentioned related method steps to realize the method for reducing the call drop rate in the above-mentioned embodiments, to control the receiving pin to receive signals, and to control the sending pin to send signals.
  • the terminal includes but is not limited to: at least one USIM, a modem associated with the at least one USIM, one or more processors, memories, and one or more computer programs.
  • one or more computer programs are stored in the memory, and when the computer programs are executed by one or more processors, the terminal or the chip system can execute the steps in any of the above method embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请提供了一种降低掉话率的方法及终端。该方法无需对核心网、基站和USIM做任何修改,核心网按照正常流程与终端进行身份验证,终端则在首次身份验证鉴权后接收到第二身份验证请求时,将首次身份验证时接收到的第一身份验证请求与第二身份验证请求进行比较,在确定第二身份验证鉴权失败后,通过在T3320定时器对应的定时时长内监测呼叫业务的走向,并在确定呼叫业务往成功方向跳转时,主动关闭T3320定时器,以避免T3320定时器超时后终端自动执行掉话流程,从而有效避免了身份验证鉴权阶段的误判,解决了现有用户场景中由于误判导致身份验证鉴权阶段出现掉话的问题,进而降低了掉话率,提升了用户体验。

Description

降低掉话率的方法及终端
本申请要求于2021年9月29日提交中国专利局、申请号为202111153780.X、发明名称为“降低掉话率的方法及终端”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域,尤其涉及一种降低掉话率的方法及终端。
背景技术
掉话率,是移动通信中的重要指标,也称通话中断率,是指在移动通信的过程中,通信意外中断的几率。掉话率在移动通信网中是一项非常重要的指标,掉话率的高低在一定程度上体现了移动网通信质量的优劣。因而,降低用户掉话率已经成为网络优化项目中的重点。
目前,终端厂家给出的降低掉话率的方案通常是针对无线网络掉话、Abis接口掉话、A接口掉话、TC接口掉话等原因造成的掉话,然而在实际的用户使用场景中,网络侧与终端侧进行身份验证鉴权的阶段也会出现掉话现象,例如主、被叫采用电路域回落(Circuit Switched Fallback,CSFB)技术,或者双模单待无线语音呼叫连续性(Single Radio Voice Call Continuity,SRVCC)技术呼叫到核心网(Core Network,CN)的时候,CN会向终端发起身份验证请求,并启动T3360定时器,当T3360定时器超时以后如果终端未能及时的把鉴权成功的响应消息发送到CN,CN会重传身份验证请求,而从实际情况来看,对重传的身份验证请求,终端中用于进行身份验证鉴权的全球用户识别卡(Universal Subscriber Identity Module,USIM)会因为两次身份验证鉴权请求完全一致而返回鉴权失败,原因值为同步失败(Synch failure)。对于这种情况,终端在接收到USIM作出的验证失败的身份验证响应后,会启动T3320定时器,而在T3320定时器对应的定时时长内如果没有再次接收到核心网针对验证失败重传的身份验证请求,T3320定时器超时后会触发掉话等流程。
这就使得这种用户使用场景必然会出现掉话的问题,因此亟需提供一种能够降低身份验证鉴权阶段出现掉话的技术方案。
发明内容
为了解决上述技术问题,本申请提供一种降低掉话率的方法及终端,能够有效避免身份验证鉴权阶段的误判,从而解决上述用户场景中由于误判导致身份验证鉴权阶段出现掉话的问题,以降低掉话率,提升用户体验。
第一方面,本申请提供一种降低掉话率的方法。该方法应用于终端,包括:接收基站发送的第一身份验证请求,第一身份验证请求由核心网发起,且核心网向基站发送第一身份验证请求后,启动T3360定时器;响应于第一身份验证请求,通过基站向核心网发送针对第一身份验证请求作出的验证成功的第一身份验证响应;接收基站发送的第二身份验证请求,第二身份验证请求由核心网在T3360定时器对应的定时时长结束后发起;判断第一身份验证请求和第二身份验证请求是否相同;在第一身份验证 请求和第二身份验证请求相同时,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器;在T3320定时器对应的定时时长内,获取当前执行的呼叫业务的走向信息,呼叫业务与第一身份验证请求和第二身份验证请求相关联;根据走向信息判断呼叫业务是否往成功方向跳转;在呼叫业务往成功方向跳转时,关闭T3320定时器。这样,无需对核心网、基站和终端内用户进行身份验证鉴权操作的USIM做任何修改,核心网按照正常流程与终端进行身份验证,终端则在首次身份验证鉴权后接收到第二身份验证请求时,将首次身份验证时接收到的第一身份验证请求与第二身份验证请求进行比较,在确定第二身份验证鉴权失败后,通过在T3320定时器对应的定时时长内监测呼叫业务的走向,并在确定呼叫业务往成功方向跳转时,主动关闭T3320定时器,以避免T3320定时器超时后终端自动执行掉话流程,从而有效避免了身份验证鉴权阶段的误判,解决了现有用户场景中由于误判导致身份验证鉴权阶段出现掉话的问题,进而降低了掉话率,提升了用户体验。
根据第一方面,在响应于第一身份验证请求,通过基站向核心网发送针对第一身份验证请求作出的验证成功的第一身份验证响应之后,方法还包括:确定接收到第一身份验证请求时的系统时间,得到第一时刻;获取第一身份验证请求对应的呼叫业务的会话标识号;根据第一身份验证请求、第一身份验证响应、会话标识号和第一时刻生成鉴权多元组;建立第一身份验证请求和鉴权多元组之间的对应关系,并保存。这样,在得到针对第一身份验证请求作出的验证成功的第一身份验证响应后,通过获取与第一身份验证请求相关的数据,如第一身份验证响应、接收到第一身份验证请求的第一时刻、第一身份验证请求对应的呼叫业务的会话标识号,进而根据这些数据生成鉴权多元组进行保存,从而可以便于后续接收到核心网通过基站重传的与第一身份验证请求相同的第二身份验证请求时,能够直接复用鉴权多元组中记录的第一身份验证响应,避免USIM误认为核心网同步异常,即认为SQN out of range,从而返回鉴权失败的第二身份验证响应,导致终端触发掉话流程。
根据第一方面,或者以上第一方面的任意一种实现方式,鉴权多元组中记录的第一身份验证请求包括随机数和鉴权值;其中,鉴权值基于随机数计算获得。由于终端中的USIM在针对第一身份验证请求进行身份验证鉴权时需要用到第一身份验证请求中的鉴权值,而鉴权值是基于随机数计算获得的,这样就可以区分不同的身份验证请求,因此本申请提供的降低掉话率的方法中,生成鉴权多元组时所需的第一身份验证请求中至少包括了随机数和鉴权值。
根据第一方面,或者以上第一方面的任意一种实现方式,鉴权多元组中记录的第一身份验证响应包括A&C参考编号、实际响应值和预期响应值。由于在实际的应用场景中,终端中可能保存了多个不同身份验证请求对应的鉴权多元组,因此为了便于查找到能够复用给第二身份验证请求的第一身份验证响应,本申请提供的降低掉话率的方法中,生成鉴权多元组时所需的第一身份验证响应中包括了能够标识该响应的参考编号,以及根据第一身份验证请求中的消息计算出的实际响应值和核心网预期的预期响应值,从而便于确定本次鉴权是否成功。
根据第一方面,接收基站发送的第一身份验证请求,在响应于第二身份验证请求, 通过基站向核心网发送针对第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器之前,方法还包括:判断是否存在与第一身份验证请求对应的鉴权多元组;在存在与第一身份验证请求对应的鉴权多元组时,从鉴权多元组中提取第一身份验证响应作为针对第二身份验证请求作出的验证成功的第二身份验证响应,并通过基站向核心网发送第二身份验证响应;在不存在与第一身份验证请求对应的鉴权多元组时,执行响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器的步骤。这样,在接收到与第一身份验证请求相同的第二身份验证请求时,终端先查找保存的鉴权多元组是否可以给第二身份验证请求复用,然后根据结果决定是直接复用已经存在的鉴权结果,还是交由USIM重新响应于第二身份验证请求进行身份验证鉴权操作,从而可以避免USIM返回鉴权失败,进而从源头阻止掉话流程的执行,有效降低了掉话率。
根据第一方面,接收基站发送的第一身份验证请求,响应于第一身份验证请求,通过基站向核心网发送针对第一身份验证请求作出的验证成功的第一身份验证响应,包括:通过天线接收基站发送的第一身份验证请求;确定处理第一身份验证请求的第一USIM;通过与第一USIM关联的调制解调器,将第一身份验证请求发送给第一USIM;由第一USIM响应于第一身份验证请求,将针对第一身份验证请求作出的验证成功的第一身份验证响应发送给调制解调器;调制解调器通过天线将验证成功的第一身份验证响应发送给基站,由基站向核心网发送验证成功的第一身份验证响应。这样,针对核心网发起的身份验证鉴权直接在终端的Model层实现,无需与上层交互,不需要用户介入,从而可以在用户没有感知的情况下解决掉身份验证鉴权阶段存在的掉话问题。
根据第一方面,或者以上第一方面的任意一种实现方式,终端内设置了两张USIM;接收基站发送的第二身份验证请求,判断第一身份验证请求和第二身份验证请求是否相同,包括:通过天线接收基站发送的第二身份验证请求;确定处理的第二身份验证请求的第二USIM;通过与第二USIM关联的调制解调器,将第二身份验证请求发送给第二USIM;在第一USIM与第二USIM为同一张USIM时,由第一USIM判断第一身份验证请求和第二身份验证请求是否相同;在第一USIM与第二USIM为不同的USIM时,由第二USIM响应于第二身份验证请求,将针对第二身份验证请求作出的验证成功的第二身份验证响应发送给第二USIM关联的调制解调器;第二USIM关联的调制解调器通过天线将验证成功的第二身份验证响应发送给基站,由基站向核心网发送验证成功的第二身份验证响应。这样,对于多卡多待的终端,先确定两次接收到的身份验证请求是否对应的是同一张USIM,在是针对同一张USIM时,才判断两条身份验证请求是否相同,决定是否执行本申请提供的降低掉话率的方法,在针对的是不同USIM时,则无需判断两条身份验证请求是否相同,对于每一条首次到达USIM的身份验证请求,USIM直接进行身份验证鉴权即可。
根据第一方面,或者以上第一方面的任意一种实现方式,判断第一身份验证请求和第二身份验证请求是否相同,包括:分别确定接收到第一身份验证请求时的系统时间和接收到第二身份验证请求时的系统时间,得到第一时刻和第二时刻;判断第一时刻和第二时刻之间的时间间隔是否小于时间阈值;在时间间隔小于时间阈值时,判断 第一身份验证请求的内容和第二身份验证请求的内容是否一致;在第一身份验证请求的内容和第二身份验证请求的内容一致时,分别获取第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号;判断第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号是否相同;在第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号相同时,确定第一身份验证请求和第二身份验证请求相同。这样,通过判断时间间隔、身份验证请求具体的内容,以及对于的呼叫业务的会话标识号,从多维度的角度来判断第一身份验证请求和第二身份验证请求是否相同,即第二身份验证请求是否为重传的第一身份验证请求,从而既可以避免现有身份验证鉴权阶段由于误判重传的身份验证请求导致的鉴权失败造成的掉话问题,又可以避免将不同的身份验证请求误认为重传请求,导致新的呼叫业务无法顺利执行。
根据第一方面,或者以上第一方面的任意一种实现方式,判断第一身份验证请求的内容和第二身份验证请求的内容是否一致,包括:获取第一身份验证请求对应的第一序列号和第二身份验证请求对应的第二序列号;其中,对于不同的身份验证请求,序列号不相同;判断第一序列号和第二序列号是否相同;在第一序列号和第二序列号相同时,确定第一身份验证请求和第二身份验证请求的内容一致。这样,通过对比两条身份验证请求中能够标识其唯一性的序列号来确定二者是否相同,无需比对两条身份验证请求中的具体内容,快速方便。
根据第一方面,或者以上第一方面的任意一种实现方式,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器,包括:由第一USIM响应于第二身份验证请求,生成验证失败的原因值为Synch failure的第二身份验证响应;由第一USIM将第二身份验证响应发送给调制解调器;由调制解调器通过天线将验证失败的第二身份验证响应发送给基站,由基站向核心网发送验失败的第二身份验证响应。由于终端在USIM返回的身份验证响应中携带了Synch failure时,才会启动T3320定时器,因此本申请中处理第二身份验证请求的USIM通过返回验证失败的原因值为Synch failure的第二身份验证响应,使得终端在将该第二身份验证响应发送给基站后,能够启动T3320定时器。
根据第一方面,或者以上第一方面的任意一种实现方式,根据走向信息判断呼叫业务是否往成功方向跳转,包括:判断走向信息是否为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act;在走向信息为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act时,确定呼叫业务是往成功方向跳转。示例性的,在实际的应用场景中,当终端接收到Routing Area Update Accept,或者Service Accept,或者connect,或者connect act时,往往表征当前的呼叫业务正在往成功的方向跳转,因此本申请提供的降低掉话率的方法中通过判断走向信息是否为上述任意一种,从而能够快速确定呼叫业务是否往成功方向跳转,进而在T3320定时器超时前提前关闭掉T3320定时器,从而阻止了掉话流程的执行,使得当前的呼叫业务能够正常进行,提升了用户体验。
根据第一方面,或者以上第一方面的任意一种实现方式,在判断第一身份验证请求和第二身份验证请求是否相同之后,方法还包括:在第一身份验证请求和第二身份 验证请求不相同时,响应于第二身份验证请求,并通过基站向核心网发送针对第二身份验证请求作出的验证成功的第二身份验证响应。这样,在确定第一身份验证请求和第二身份验证请求不相同,即第二身份验证请求不是重传的第一身份验证请求时,终端按照正常的鉴权流程进行处理,从而即兼顾了正常鉴权流程的执行,又能够避免重传身份验证请求被误判。
第二方面,本申请提供了一种终端。该终端包括:至少一张USIM、与至少一张USIM关联的调制解调器、一个或多个处理器、存储器,以及一个或多个计算机程序;其中,一个或多个计算机程序存储在存储器上,当计算机程序被一个或多个处理器执行时,使得终端能够执行第一方面或第一方面的任意可能的实现方式中的方法。
第三方面,本申请提供了一种计算机可读介质,用于存储计算机程序,该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
第四方面,本申请提供了一种计算机程序,该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
第五方面,本申请提供了一种芯片。该芯片包括:一个或多个处理电路和一个或多个收发管脚;其中,收发管脚和处理电路通过内部连接通路互相通信,处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法,以控制接收管脚接收信号,以控制发送管脚发送信号。
第六方面,本申请提供一种降低掉话率的系统。该系统包括基站、核心网和上述第而方面涉及的终端。
附图说明
图1是示例性示出的身份验证鉴权阶段的时序图;
图2是示例性示出的身份验证鉴权阶段存在的掉话场景示意图;
图3是示例性示出的一种终端的硬件结构示意图;
图4是示例性示出的本申请实施例提供的降低掉话率的方法的流程示意图之一;
图5是示例性示出的实现图4提供的降低掉话率的方法时涉及的各实体之间的交互过程的时序图;
图6是示例性示出的本申请实施例提供的降低掉话率的方法的流程示意图之二;
图7是示例性示出的实现图6提供的降低掉话率的方法时涉及的各实体之间的交互过程的时序图;
图8是示例性示出的本申请实施例提供的降低掉话率的方法的流程示意图之三。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完 整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象,而不是用于描述对象的特定顺序。例如,第一目标对象和第二目标对象等是用于区别不同的目标对象,而不是用于描述目标对象的特定顺序。
在本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中,除非另有说明,“多个”的含义是指两个或两个以上。例如,多个处理单元是指两个或两个以上的处理单元;多个系统是指两个或两个以上的系统。
在对本申请实施例的技术方案说明之前,首先结合附图对本申请实施例提供的降低掉话率的方法所针对的场景进行说明。
具体的说,本申请实施例提供的降低掉话率的方法具体是针对身份验证鉴权阶段。
可理解的,终端与核心网之间交互的数据,通常是由基站进行转发的。因此,在实际的应用场景中,终端通过基站接入的网络授权大小,直接影响了终端能力信息上报给基站时所占用的时长,而基站查询终端能力的请求是会先于核心网发起的身份验证请求到终端的,故而终端响应于基站查询其能力的请求的响应信息是排在响应于身份验证请求的响应消息之前的。因此,终端发送的针对身份验证请求做出的验证成功的身份验证响应可能会在T3360定时器对应的定时时长内无法到达基站,这种情况下基站就会重传上一次的身份验证请求,从而导致终端内的USIM误判,触发掉话流程。
基于上述实现逻辑,结合图1进行具体说明。
参见图1,当终端,例如可以是主叫终端,也可以是被叫终端采用CSFB技术或SRVCC技术呼叫核心网CN时,基站会向终端发送终端能力查询请求,即执行步骤101。
相应地,当终端接收到基站发送的终端能力查询请求后,会响应于该请求,并将得到的终端能力信息片段(后续用SEG表示片段),例如SEG-1~SEG-N持续上报给基站,即执行步骤102、步骤102’的操作。
继续参见图1,在实际的应用场景中,队列中排队上报至基站的终端能力信息片段可能还没有全部上传完,例如步骤102’终端能力信息SEG-N还在排队上传中,核心网通过基站发送给终端的第一身份验证请求就到达终端,即步骤103的操作。而终端接收到来自基站发送的核心网发起的第一身份验证请求后,会将第一身份验证请求交由内置的USIM,也可以是SIM卡,即执行步骤104。
相应地,USIM或SIM卡会响应于第一身份验证请求,进行身份验证鉴权处理,进而得到针对第一身份验证请求作出的第一身份验证响应,并将第一身份验证响应反馈给终端,即执行步骤105。
示例性的,假设针对第一身份验证请求作出的是验证成功的第一身份验证响应,但是由于当前向基站发送消息的队列中还有没有上报完的终端能力信息片段,如SEG-N,因此得到的第一身份验证响应需要排在终端能力信息SEG-N后,即在终端能力信息SEG-N上报到基站后,第一身份验证响应才会发送给基站,进而基站才会将其转发到核心网,即步骤106。但是在实际的应用场景中,核心网在发起第一身份验证请求后,会启动T3360定时器,并且核心网在T3360定时器超时(定时时长一般设置为6s)后会重传上一次的身份验证请求,即执行步骤107,通过基站向终端发送第二身份验证请求。
可理解的,在实际的应用场景中,对于重传身份验证请求,步骤107中的第二身份验证请求实质就是第一身份验证请求,即内容和对应的呼叫业务的会话标识号等信息全部相同。
相应地,终端在接收到第二身份验证请求后,同样会将其交由USIM或SIM进行身份验证鉴权处理,即执行步骤108。
相应地,USIM或SIM会响应于第二身份验证请求,进行身份验证鉴权处理,进而得到针对第二身份验证请求作出的第一身份验证响应,并将第二身份验证响应反馈给终端,即执行步骤109。
需要说明的是,由于第二身份验证请求是重传的第一身份验证请求,而USIM或SIM已经针对第一身份验证请求作出了验证成功的第一身份验证响应,此时重新接收到第二身份验证请求会误认为与核心网的身份验证鉴权失败,因此会返回验证失败,具体携带的验证失败的原因值可以为Synch failure。
相应地,终端在收到验证失败的第二身份验证响应后,会将验证失败的第二身份验证响应发送给基站,进而由基站转发至核心网,即执行步骤110。
此外,需要说明的是,在实际的应用场景中,终端在发送验证失败的原因值为Synch failure的第二身份验证响应后会启动T3320定时器,等待核心网重新发起身份验证请求,如果在T3320定时器对应的定时时长内核心网没有重新发起身份验证请求,T3320定时器超时后便会自动触发掉话流程,即步骤111。
而参见图1可知验证成功的第一身份验证响应并没有被丢弃,核心网只是延迟收到,即在核心网重传上一次的身份验证请求后,虽然T3360定时器已超时,但是针对第一次身份验证请求作出的验证成功的第一身份验证响应会先于验证失败的第二身份验证响应到达核心网,因此核心网会误以为接收到的第一身份验证响应是针对第二身份验证请求的,由于收到的是验证成功的响应,因此呼叫业务会继续进行,即核心网在T3320定时器对应的定时时长内是不会重新发起身份验证请求的,这样对于终端而言,T3320定时器超时后,必然会执行掉话流程,具体为先进行本地释放,然后Bar掉当前的呼叫,主动拆链,进而导致掉话。
示例性的,参见图2为图1所示身份验证鉴权阶段出现掉话的场景示意图。
具体的说,按照上述描述,当用户使用终端A中的USIM_1呼叫终端B中的 USIM_2时,核心网会通过基站向终端A发送第一身验证请求,由终端A中的USIM_1进行身份验证,如果终端A、基站、核心网按照上述步骤101至步骤110的操作执行,在验证失败的第二身份验证响应到达核心网前,核心网已经接收到了验证成功的第一身份验证响应,这种情况下核心网便会通过基站将终端A中的USIM_1呼叫终端B中的USIM_2的呼叫请求发送给终端B,如果被叫用户接听了当前通话,那么终端A在T3320定时器对应的定时时长内是无法接收到核心网通过基站重传的身份验证请求,在T3320定时器超时后,就会执行掉话流程,从而使得已经建立的通话中断,如图2所示终端A与基站之间的通信链路,以及基站与终端B之间的通信链路会断开。
为了解决上述身份验证鉴权阶段存在的掉话问题,提出了本申请实施例提供的降低掉话率的方法。该方法无需对核心网、基站和USIM做任何修改,核心网按照正常流程与终端进行身份验证,终端则在首次身份验证鉴权后接收到第二身份验证请求时,将首次身份验证时接收到的第一身份验证请求与第二身份验证请求进行比较,在确定第二身份验证鉴权失败后,通过在T3320定时器对应的定时时长内监测呼叫业务的走向,并在确定呼叫业务往成功方向跳转时,主动关闭T3320定时器,以避免T3320定时器超时后终端自动执行掉话流程,从而有效避免了身份验证鉴权阶段的误判,解决了现有用户场景中由于误判导致身份验证鉴权阶段出现掉话的问题,进而降低了掉话率,提升了用户体验。
为了更好的理解本申请实施例提供的降低掉话率的方法,以下先结合图3对该方法所适用于的终端的硬件结构进行说明,再结合图4至图7对基于该硬件结构的终端实现本申请实施例提供的降低掉话率的方法的过程进行说明。
参见图3,为示例性示出的实现本申请实施例提供的降低掉话率的方法的终端100的硬件结构示意图。
如图3所示,终端100可以包括:处理器110,外部存储器接口120,内部存储器121,通用串行总线(universal serial bus,USB)接口130,充电管理模块140,电源管理模块141,电池142,天线1,天线2,移动通信模块150,无线通信模块160,音频模块170,传感器模块180,按键190,马达191,指示器192,摄像头193,显示屏194,以及用户标识模块(subscriber identification module,SIM)卡接口195等。
其中,天线1和天线2用于发射和接收电磁波信号。终端100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用,以提高天线的利用率。例如:可以将天线1复用为无线局域网的分集天线。在另外一些实施例中,天线可以和调谐开关结合使用。
需要说明的,在本申请实施例中,终端接收基站发送的身份验证请求,以及向基站发送身份验证响应均是通过天线1或天线2实现的。
移动通信模块150可以提供应用在终端100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器,开关,功率放大器,低噪声放大器(low noise amplifier,LNA)等。无线通信模块160可以提供应用在终端100上的包括无线局域网(wireless local area networks,WLAN)(如无线保真(wireless fidelity,Wi-Fi)网络),蓝牙(bluetooth,BT),全球导航卫星系统(global navigation  satellite system,GNSS),调频(frequency modulation,FM),近距离无线通信技术(near field communication,NFC),红外技术(infrared,IR)等无线通信的解决方案。
在一些实施例中,终端100的天线1和移动通信模块150耦合,天线2和无线通信模块160耦合,使得终端100可以通过无线通信技术与网络以及其他设备通信。
继续参见图3,示例性的,对于终端100的音频模块170包括扬声器170A、受话器170B、麦克风170C、耳机接口170D等。
示例性的,终端100可以通过音频模块170中的扬声器170A、受话器170B、麦克风170C、耳机接口170D,以及应用处理器等实现音频功能,例如音乐播放,录音、语音通话等。
此外,关于终端100中的传感器模块180,在一些实施例中可以包括压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、指纹传感器、温度传感器、触摸传感器、环境光传感器、骨传导传感器等,此处不再一一列举,本申请对此不做限制。
此外,需要说明的是,在一些实施例中,处理器110可以包括一个或多个处理单元,例如:处理器110可以包括应用处理器(application processor,AP),调制解调处理器,图形处理器(graphics processing unit,GPU),图像信号处理器(image signal processor,ISP),控制器,存储器,视频编解码器,数字信号处理器(digital signal processor,DSP),基带处理器,和/或神经网络处理器(neural-network processing unit,NPU)等。
可理解的,在具体实现中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
此外,在一些实施例中,控制器可以是终端100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号,产生操作控制信号,完成取指令和执行指令的控制。
此外,处理器110中的存储器主要用于存储指令和数据。在一些实施例中,处理器110中的存储器为高速缓冲存储器。
此外,关于图3中示出的USB接口130是符合USB标准规范的接口,具体可以是Mini USB接口,Micro USB接口,USB Type C接口等。
充电管理模块140用于从充电器接收充电输入。此外,图3中示出的电源管理模块141用于连接电池142,充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入,为处理器110,内部存储器121,外部存储器,显示屏194,摄像头193,和无线通信模块160等供电。终端100的无线通信功能可以通过天线1,天线2,移动通信模块150,无线通信模块160,调制解调处理器以及基带处理器等实现。
此外,图3中示出的终端100通过GPU,显示屏194,以及应用处理器等实现显示功能。GPU为图像处理的微处理器,连接显示屏194和应用处理器。GPU用于执行数学和几何计算,用于图形渲染。处理器110可包括一个或多个GPU,其执行程序指令以生成或改变显示信息。
关于,显示屏194具体用于显示图像,视频等。显示屏194包括显示面板,在一 些实施例中,终端100可以包括1个或N个显示屏194,N为大于1的正整数。
示例性的,在本申请实施例中,显示屏除了用于显示图像、视频等内容,还用于与传感器配合,如压力传感器使得终端能够确定用户触发的应用具体位于什么位置,进而确定用户具体触发的是什么应用。
此外,终端100可以通过ISP,摄像头193,视频编解码器,GPU,显示屏194以及应用处理器等实现拍摄功能。
摄像头193用于捕获静态图像或视频,在一些实施例中,终端100可以包括1个或N个摄像头193,N为大于1的正整数。
此外,图3中示出外部存储器接口120可以用于连接外部存储卡,例如Micro SD卡,实现扩展终端100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信,实现数据存储功能。例如将音乐,视频等文件保存在外部存储卡中。
此外,图3中示出内部存储器121可以用于存储计算机可执行程序代码,所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令,从而执行终端100的各种功能应用以及数据处理。
具体的,实现本申请实施例提供的降低掉话率的方法的相关指令预先存储到内部存储器121中,处理器110通过执行内部存储器121中存储的指令,从而能够使得终端100执行本申请实施例提供的降低掉话率的方法。
此外,图3中示出马达191例如可以是振动马达;指示器192可以是指示灯。
SIM卡接口195用于连接SIM卡,或者USIM卡。SIM卡可以通过插入SIM卡接口195,或从SIM卡接口195拔出,实现与终端100的接触和分离。终端100可以支持1个或N(N为大于1的整数)个SIM卡接口195。即,终端中可以插入多个SIM卡或USIM卡。
此外,需要说明的是,在实际的应用场景中,每一终端内除了设置有SIM卡或USIM卡(后续统称为USIM),还会设置与USIM对应或关联的调制解调器(Modem),并且Modem的个数可以与USIM的个数相同,并一一对应。即,终端中的每一张USIM对应一个Modem,这样每一USIM的呼叫业务直接由与其关联的Modem进行处理即可,例如在天线接收到基站发送的由核心网发起的针对USIM1的身份验证请求时,会将该身份验证请求交由与USIM1关联的Modem1,进而由Modem1将该身份验证请求交由USIM1处理。
此外,在另一个例子中,Modem的个数可以与USIM的个数不相同,比如对于采用高通芯片的终端,内部可以只有一个Modem,但是可以设置两张或多张USIM。对于这种情况,Modem与每一张USIM之间的关联关系,由Modem内部自行维护即可,本申请对此不做限制。
关于终端100的硬件结构就介绍到此,应当理解的是,图3所示终端100仅是一个范例,在具体实现中,终端100可以具有比图中所示的更多的或者更少的部件,可以组合两个或多个的部件,或者可以具有不同的部件配置。图3中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
以图3示出的硬件结构的终端为例,对该终端实现本申请实施例提供的降低掉话率的方法的流程进行具体说明。
参见图4,本申请实施例提供的一种降低掉话率的方法的具体实现方式,具体包括:
步骤201,接收基站发送的第一身份验证请求。
示例性的,在一些实施例中,用于接收基站发送的第一身份验证请求的终端,例如可以是移动通讯领域中常说的UE(User Equipment)。
可理解的,在3G和4G网络中,用户终端就叫做UE,相当于2G网络中的MS(Mobile Station),即兼具工作站和笔记本电脑的特性的移动站/移动台。故而,在另一些实施例中,用于接收基站发送的第一身份验证请求的终端,也可以是MS。
此外,可理解的,在实际的应用场景中UE包括但不限于手机、智能终端、多媒体设备、流媒体设备等,此处不再一一列举,本申请对此也不做限制。为了便于说明,本实施例以手机为例。
此外,需要说明的是,由于呼叫业务是针对终端中设置的USIM而言的,因此核心网与终端之间的身份验证鉴权操作,实质是由终端中设置的USIM完成的。即,终端接收到基站发送的第一身份验证请求后,会将其交由对应的USIM进行身份验证鉴权。
具体的,通过上述对终端硬件结构的描述可知,终端中的天线是用来接收和发射电磁波信号的。故而,终端是通过内部的天线接收基站发送的第一身份验证请求,然后通过与USIM关联的Modem将第一身份验证请求交由USIM进行身份验证鉴权处理。
可理解的,由于在实际的应用场景中,终端中可能设置了多张USIM,即终端为多卡多待终端,为了身份验证请求能被正确的USIM处理,终端通过天线接收到基站发送的第一身验证请求后,需要先确定处理第一身份验证请求的USIM,示例性的可以将处理第一身份验证请求的USIM称为第一USIM,然后通过与第一USIM关联的调制解调器,将第一身份验证请求发送给第一USIM。
示例性的,在一个例子中,确定用来处理第一身份验证请求的第一USIM即为第一身份验证请求对应的呼叫业务的发起者。
此外,需要说明的是,在实际的应用场景中,核心网在向基站发送第一身份验证请求后,根据3GPP协议的规定会启动一个T3360定时器,并设置对应的定时时长,例如6s。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。在实际的应用场景中,为T3360定时器设置的定时时长可以根据当前的网络情况、终端占用的授权量,以及业务场景对实时性的要求确定,具体的设置方式,本申请不做限制和说明。
步骤202,响应于第一身份验证请求,通过基站向核心网发送针对第一身份验证请求作出的验证成功的第一身份验证响应。
具体的说,步骤202中响应于第一身份验证请求的操作具体是由终端中设置的USIM进行的,即USIM会根据接收到的第一身份验证请求进行身份验证鉴权处理, 关于具体的鉴权过程,本实施例并未修改,此处不做描述。
相应地,USIM在完成对第一身份验证请求的身份验证鉴权处理后,会将针对第一身份验证请求作出的第一身份验证响应发送给与之关联的Modem,然后由Modem将第一身份验证响应交由天线,通过天线将第一身份验证响应发送给基站,以便基站能够将第一身份验证响应转发至核心网。
可理解的,在实际的应用场景中,USIM对第一身份验证请求的鉴权结果不外乎鉴权成功(验证成功)或鉴权失败(验证失败),而在鉴权失败后,核心网不管是否启动的T3360定时器是否超时,在接收到验证失败的第一身份验证响应后通常呼叫业务不会继续跳转,而是会发起重传身份验证请求的操作,故而终端在验证失败后启动的T3320定时器对应的定时时长内是能够接收到重传的身份验证请求的,故而不会触发掉话流程。因此,本实施例主要针对鉴权结果是鉴权成功,而核心网延时收到验证成功的第一身份验证响应前发起重传身份验证请求导致的掉话问题。
也就是说,在本实施例中,对于核心网发起的首次身份验证请求,USIM作出的是验证成功的第一身份验证响应。
步骤203,接收基站发送的第二身份验证请求。
示例性的,对于基站而言,需要发送给终端的所有身份验证请求均是来自核心网的,同样对于终端而言,从基站接收身份验证请求的操作,均是通过内部的天线实现,具体的接收过程详见步骤201中的描述,此处不再赘述。
步骤204,判断第一身份验证请求和第二身份验证请求是否相同。
具体的说,在通过天线接收到第二身份验证请求后,在一个例子中,为了确定第二身份验证请求是否为重传的第一身份验证请求,可以由USIM进行判断处理,进而给出处理结果,也可以不经过USIM,直接由终端确定。
示例性的,本实施例以需要由USIM进行判断出来这一场景为例进行说明,即天线需要将接收到的第二身份验证请求交由Modem,然后由Modem交由与之关联的USIM进行处理。
具体的说,对于这种场景,即终端接收到的所有身份验证请求均由USIM进行身份验证鉴权处理,USIM在进行身份验证鉴权处理时,通过对比第一身份验证请求和第二身份验证请求,在一个例子中可以是对比能够标识每一条身份验证请求唯一性的序列号。
可理解的,对于不同的身份验证请求,即第一身份验证请求和第二身份验证请求不相同,不是同一条身份验证请求的情况,两个序列号是不相同的,故而USIM可以识别出第一身份验证请求和第二身份验证请求不相同。而对于第二身份验证请求时在T3360定时器对应的定时时长结束后核心网针对第一身份验证请求重传的身份验证请求时,实质上第二身份验证请求就是第一身份验证请求,这两条身份验证请求携带的内容,对应的序列号,呼叫业务是完全相同的,故而对于这种情况,USIM就会认为第一身份验证请求和第二身份验证请求是相同的。
进一步地,在实际应用中,两条身份验证请求的时间间隔,以及每一条身份验证请求对应的呼叫业务同样会影响判断结果,即便二者的序列号相同,但是如果时间间隔大于某一阈值,或者对应的呼叫业务不同,也不能直接将这两条身份验证请求看做 是相同的。故而,在判断第一身份验证请求和第二身份验证请求是否相同时,还可以引入时间间隔和呼叫业务这两个因素。
具体的说,在接收到第二身份验证请求后,USIM会分别确定接收到第一身份验证请求时的系统时间和接收到第二身份验证请求时的系统时间,得到第一时刻和第二时刻;然后,判断第一时刻和第二时刻之间的时间间隔是否小于时间阈值。
相应地,在时间间隔小于时间阈值时,USIM会继续判断第一身份验证请求的内容和第二身份验证请求的内容是否一致,例如可以通过比较能够标识每条身份验证请求的序列号确定。
相应地,在第一身份验证请求的内容和第二身份验证请求的内容一致时,USIM还会分别获取第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号;然后,继续判断第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号是否相同。
相应地,在第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号相同时,确定第一身份验证请求和第二身份验证请求相同。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。在实际的应用场景中,可以根据实际的业务需求设置不同的判断条件,此处不做限制。
故而,在步骤204中,若经过判断确定第一身份验证请求和第二身份验证请求相同,则进入步骤205,反之则进入步骤210。
此外,需要说明的是,在实际的应用场景中,对于终端中设置了多张USIM,例如两张时,终端在接收到基站发送的第二身份验证请求,判断第一身份验证请求和第二身份验证请求是否相同时,可以先确定第二身份验证请求是否需要由处理第一身份验证请求的USIM进行处理。
示例性的,假设处理第一身份验证请求的USIM为第一USIM,则上述步骤203和步骤204的操作具体为:先通过天线接收基站发送的第二身份验证请求;然后,确定处理的第二身份验证请求的第二USIM;接着,通过与第二USIM关联的调制解调器,将第二身份验证请求发送给第二USIM;接着,在第一USIM与第二USIM为同一张USIM时,由第一USIM判断第一身份验证请求和第二身份验证请求是否相同;在第一USIM与第二USIM为不同的USIM时,由第二USIM响应于第二身份验证请求,将针对第二身份验证请求作出的验证成功的第二身份验证响应发送给调制解调器;调制解调器通过天线将验证成功的第二身份验证响应发送给基站,由基站向核心网发送验证成功的第二身份验证响应。
步骤205,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器。
具体的说,在步骤205中,响应于第二身份验证请求的操作,依旧是由USIM执行的,只是在USIM确定第一身份验证请求和第二身份验证请求相同时,USIM会误认为与核心网的身份验证鉴权失败,因此会返回验证失败,具体携带的验证失败的原因值可以为Synch failure。即针对第二身份验证请求作出的是验证失败的第二身份验证响应。
相应地,在作出验证失败的第二身份验证响应后,USIM会将该鉴权结果发生至与之关联的Modem,然后由Modem通过天线发送给基站,以使基站将鉴权结果为验证失败的第二身份验证响应发送给核心网。
此外,基于3GPP协议的规定可知,在实际的应用场景中,终端在发送验证失败的原因值为Synch failure的第二身份验证响应后会启动T3320定时器,等待核心网重新发起身份验证请求,如果在T3320定时器对应的定时时长内核心网没有重新发起身份验证请求,T3320定时器超时后便会自动触发掉话流程,即进入步骤209。
故而,在本实施例中,终端通过天线将验证失败的原因值为Synch failure的第二身份验证响应发送给基站后,会启动T3320定时器,并设置对应的定时时长。
可理解的,在实际的应用场景中,为T3320定时器设置的定时时长同样可以根据当前的网络情况、终端占用的授权量,以及业务场景对实时性的要求确定,具体的设置方式,本申请不做限制和说明。
步骤206,在T3320定时器对应的定时时长内,获取当前执行的呼叫业务的走向信息。
具体的说,终端在通过天线将验证失败的原因值为Synch failure的第二身份验证响应发送给基站后,在启动的T3320定时器对应的定时时长内会监听是否有重传的身份验证请求,同时也会监听是否有呼叫业务在执行,并获取当前执行的呼叫业务的走向信息。
示例性的,如果在T3320定时器对应的定时时长内没有接收到重传的身份验证请求,而是监听到当前有呼叫业务正在执行,则获取当前执行的呼叫业务的走向信息。
步骤207,根据走向信息判断呼叫业务是否往成功方向跳转。
具体的说,在步骤207中,若通过判断确定呼叫业务是往成功方向跳转的,则进入步骤208,反之则进入步骤209。
示例性的,通过对呼叫业务执行过程中流程的跳转发现,在走向信息为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act时,通常当前的呼叫业务是往成功方向跳转的,故而本实施例中在根据走向信息判断呼叫业务是否往成功方向跳转时,具体是判断走向信息是否为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act。
相应地,在走向信息为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act时,确定呼叫业务是往成功方向跳转。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
步骤208,关闭T3320定时器。
具体的说,在根据走向信息确定当前执行的呼叫业务是往成功方向跳转时,说明核心网不会在向终端重传身份验证请求,此时为了避免T3320定时器超时后,终端进入掉话流程,导致呼叫出现掉话现象,影响用户体验,终端会主动关闭T3320定时器,从而阻止了掉话流程的执行。
步骤209,在T3320定时器超时后,执行掉话流程。
可理解的,关于T3320定时器超时执行的掉话流程,具体为先进行本地释放,然 后Bar掉当前的呼叫,主动拆链,进而导致掉话。
此外,需要说明的是,虽然本实施例提供的实现降低掉话率的方法中依旧存在T3320定时器超时后,触发掉话流程的情况,但是通过实际测试发现,核心网在接收到延时的验证成功的第一身份验证消息后,触发呼叫业务往成功方向跳转时向终端发送的走向信息,通常都会在T3320定时器对应的定时时长内被终端获取到,因此采用本实施例提供的降低掉话率的方法,能够很大程度的避免在身份验证鉴权阶段出现掉话,从而降低掉话率,提升用户体验。
步骤210,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证成功的第二身份验证响应。
可理解的,对于这第二身份验证请求并非重传第一身份验证请求的场景,终端对第二身份验证请求的处理,与对第一身份验证请求的处理类似,具体处理过程详见步骤202中的描述,此处不再赘述。
这样,无需对核心网、基站和终端内用户进行身份验证鉴权操作的USIM做任何修改,核心网按照正常流程与终端进行身份验证,终端则在首次身份验证鉴权后接收到第二身份验证请求时,将首次身份验证时接收到的第一身份验证请求与第二身份验证请求进行比较,在确定第二身份验证鉴权失败后,通过在T3320定时器对应的定时时长内监测呼叫业务的走向,并在确定呼叫业务往成功方向跳转时,主动关闭T3320定时器,以避免T3320定时器超时后终端自动执行掉话流程,从而有效避免了身份验证鉴权阶段的误判,解决了现有用户场景中由于误判导致身份验证鉴权阶段出现掉话的问题,进而降低了掉话率,提升了用户体验。
为了更好的理解本实施例提供的降低掉话率的方法,以下结合图5对终端实现本实施例提供的降低掉话率的方法时,核心网、基站、终端本身,以及终端内部的USIM具体的交互进行说明。
步骤301,在终端采用CSFB技术或SRVCC技术呼叫到核心网CN的过程中,基站先向终端发送获取终端能力信息的终端能力查询请求。
可理解的,在实际的应用场景中,终端需要与基站建立通信链接,并通过天线接收和发射该通信链路中传输的电磁波信号。
步骤302,终端响应于接收到的来自基站的终端能力查询请求,获取本机的终端能力信息,例如可以是多个终端能力信息SEG,并将获取到的终端能力信息SEG持续上报给基站,例如图5中的终端能力信息SEG-1~终端能力信息SEG-N。
示例性的,在一个例子中,如果终端获取到的本机的终端能力信息SEG有5个,分别为SEG-1、SEG-2、SEG-3、SEG-4和SEG-5,这5个终端能力信息会按序添加到消息发送队列中,并按照进入队列的先后顺序依次发送给基站。例如,在T1时刻向基站发送SEG-1,在T2时刻向基站发送SEG-2,在T3时刻向基站发送SEG-3,在T4时刻向基站发送SEG-4,在T5时刻向基站发送SEG-5。
步骤303,在终端向基站发送终端能力信息SEG的过程中,核心网通过基站向终端发送第一身份验证请求。
通过上述实施例的描述可知,具体是终端通过天线接收第一身份验证请求。
此外,基于3GPP协议的规定,核心网在通过基站向终端发送第一身份验证请求后,会启动T3360定时器,并设置对应的定时时长。
步骤304,终端将第一身份验证请求发送给内部设置的USIM。
通过上述实施例的描述可知,具体是与USIM关联的Modem将天线接收到的第一身份验证请求发送给与之关联的USIM,进而使得USIM能够根据接收到的第一身份验证请求进行身份验证鉴权处理。
步骤305,USIM响应于第一身份验证请求,针对第一身份验证请求作出验证成功的第一身份验证响应,并发送给终端。
通过上述实施例的描述可知,第一身份验证响应具体是通过与USIM关联的Modem发送给终端。
步骤306,终端将验证成功的第一身份验证响应发送给基站,以便基站将第一身份验证响应发送给核心网。
示例性的,如果终端在向基站发送第一身份验证响应时,消息发送队列中还有SEG-3、SEG-4和SEG-5这3个终端能力信息SEG没有发送到基站,此时验证成功的第一身份验证响应需要添加到消息队列中,并等待这3个终端能力信息SEG全部发送到基站后,才可以进行发送,例如验证成功的第一身份验证响应需要在T6这个时刻才可以发送。
如果核心网启动的T3360定时器对应的定时时长的结束时刻为T5,即在验证成功的第一身份验证响应到达核心网前,T3360定时器已经超时,此时核心网便会触发重传身份验证请求的流程,即执行步骤307。
步骤307,核心网通过基站向终端发送第二身份验证请求。
需要说明的是,在当前场景中,为了便于描述规定核心网在T3360定时器超时后发送的第二身份验证请求为重传的第一身份验证请求,即终端接收到的第一身份验证请求和第二身份验证请求是完全相同的。
步骤308,终端将第二身份验证请求发送给内部设置的USIM。
通过上述实施例的描述可知,具体是与USIM关联的Modem将天线接收到的第二身份验证请求发送给与之关联的USIM,进而使得USIM能够根据接收到的第二身份验证请求进行身份验证鉴权处理。
此外,需要说明的是,对于本实施例适用的场景,核心网重传的身份验证请求必然是针对同一USIM的呼叫业务。故而,天线接收到的第二身份验证请求是由转发第一身份验证请求的Modem传输给同一张USIM。
步骤309,USIM响应于第二身份验证请求,针对第二身份验证请求作出验证失败的第二身份验证响应,并发送给终端。
通过上述实施例的描述可知,第二身份验证响应具体是通过与USIM关联的Modem发送给终端。
此外,通过上述实施例的描述可知,USIM会将接收到的第二身份验证请求与第一身份验证请求进行比较,进而确定这两条身份验证请求是否相同,从而作出合适的鉴权结果。
可理解的,由于第一身份验证请求和第二身份验证请求时相同的,而USIM已经 针对第一身份验证请求作出了验证成功的第一身份验证响应,此处又接收到与第一身份验证请求相同的第二身份验证请求就会误认为与核心网的身份验证鉴权失败,因此针对第二身份验证请求作出的是验证失败的第二身份验证响应。
具体的说,根据3GPP协议的规定,在基于上述场景USIM误认为与核心网的身份验证鉴权失败时,作出的验证失败的第二身份验证响应中携带的验证失败的原因值具体为Synch failure。
步骤310,终端将验证失败的第二身份验证响应发送给基站,以便基站将第二身份验证响应发送给核心网。
示例性的,在一个例子中,如果终端在向基站发送第二身份验证响应时,消息发送队列中还有没有发送到基站的消息,例如SEG-5,第一身份验证响应,此时验证失败的第二身份验证响应需要添加到消息队列中,并等待SEG-5和第一身份验证响应全部发送到基站后,才可以进行发送,例如验证失败的第二身份验证响应需要在T7这个时刻才可以发送。这样,核心网在收到验证失败的第二身份验证响应前是先接收到验证成功的第一身份验证响应的,由于第一身份验证请求和第二身份验证请求是完全相同的,因此核心网就会误以为当前接收到的第一身份验证响应是终端针对第二身份验证请求作出的。并且,由于第一身份验证响应的鉴权结果为验证成功,因此核心网就会认为与终端之间的身份验证鉴权成功了,故而会继续执行呼叫业务,而在第一身份验证响应之后接收到的第二身份验证响应会被核心网忽略掉,即核心网不会根据第二身份验证响应重新发起身份验证请求。
然而,基于3GPP协议的规定,终端在通过基站向核心网发送验证失败的原因值为Synch failure的第二身份验证响应后,会启动T3320定时器,设置对应的定时时长,并在设置的定时时长内等待核心网重新发起身份验证请求,如果在T3320定时器对应的定时时长内核心网没有重新发起身份验证请求,T3320定时器超时后便会自动触发掉话流程。
因此,终端在将第二身份验证响应发送给基站,启动T3320定时器后,在定时时长内会监听是否接收到核心网通过基站发送的重传的身份验证请求,或者直接监听当前执行的呼叫业务的走向信息,然后根据走向信息确定呼叫业务是否往成功方向跳转,即执行步骤311。
步骤311,当终端在T3320定时器对应的定时时长内监听到当前执行的呼叫业务往成功方向跳转时,主动关闭T3320定时器。
关于如何根据走向信息确定呼叫业务是否往成功方向跳转,详见上述实施例中步骤207的描述,此处不再赘述。
由此,通过上述USIM、终端、基站和核心网的交互过程,解决了身份验证鉴权阶段存在的掉话问题。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
参见图6,本申请实施例提供的又一种降低掉话率的方法的具体实现方式,具体包括:
步骤401,接收基站发送的第一身份验证请求。
步骤402,响应于第一身份验证请求,通过基站向核心网发送针对第一身份验证请求作出的验证成功的第一身份验证响应。
具体的说,本实施例中的步骤401和步骤402与图4示出的实施例中的步骤201和步骤202大致相同,步骤401和步骤402的具体实现过程详见步骤201和步骤202,此处不再赘述。
步骤403,生成鉴权多元组,建立第一身份验证请求和鉴权多元组之间的对应关系,并保存。
具体的说,在本实施例中生成的鉴权多元组是为了后续针对重传的身份验证请求时可以直接复用USIM已经作出的身份验证响应,而无需USIM再次处理,从而避免USIM在接收到相同的两个身份验证请求时,误认为与核心网之间的身份验证鉴权失败,进而作出验证失败的原因值为Synch failure的第二身份验证响应,同时启动T3320定时器,导致后续在T3320定时器对应的定时时长内没有接收到核心网重传的身份验证请求时触发掉话流程。
基于此,为了便于终端在接收到第二身份验证请求,并确定第二身份验证请求与第一身份验证请求相同时,快速、准确的从鉴权多元组中查找到能够复用的身份验证响应。在本实施例中,生成的鉴权多元组中需要包括第一身份验证请求,针对第一身份验证请求作出的验证成功的第一身份验证响应。
进一步地,为了确保第一身份验证请求和第二身份验证请求是针对同一会话的,还需要包括第一身份验证请求对应的呼叫业务的会话标识号。
进一步地,考虑到实际应用中,对于重传的身份验证请求与前一条身份验证请求的时间间隔不会太大,因此还需要考虑两条身份验证请求的间隔,故而鉴权多元组还需要包括接收到第一身份验证请求时的系统时间。
基于上述4种具体的参数信息,在生成鉴权多元组时,具体过程如下:
(1)确定接收到第一身份验证请求时的系统时间,得到第一时刻。
(2)获取第一身份验证请求对应的呼叫业务的会话标识号。
可理解的,本实施例中所说的会话标识号,即通信领域中常说的Session ID,是一种唯一标识当前访问会话的只读值。通常情况下,Session ID是按照顺序方式被分配的,也就是说,Session ID“706616433”之后跟着Session ID“706616434”等,从而可以区分两条身份验证请求是否相同。
此外,关于上述步骤(1)和步骤(2),在实际应用中不限定先后顺序。
(3)根据第一身份验证请求、第一身份验证响应、会话标识号和第一时刻生成鉴权多元组。
示例性的,在本实施例中,鉴权多元组中记录的第一身份验证请求包括随机数和鉴权值;其中,鉴权值基于随机数计算获得。
由于终端中的USIM在针对第一身份验证请求进行身份验证鉴权时需要用到第一身份验证请求中的鉴权值,而鉴权值是基于随机数计算获得的,这样就可以区分不同的身份验证请求,因此在本申请实施例中,生成鉴权多元组时所需的第一身份验证请求中包括了随机数和鉴权值。
示例性的,在本实施例中,鉴权多元组中记录的第一身份验证响应包括A&C参考编号、实际响应值和预期响应值。
由于在实际的应用场景中,终端中可能保存了多个不同身份验证请求对应的鉴权多元组,因此为了便于查找到能够复用给第二身份验证请求的第一身份验证响应,因此在本申请实施例中,生成鉴权多元组时所需的第一身份验证响应中包括了能够标识该响应的参考编号,以及根据第一身份验证请求中的消息计算出的实际响应值和核心网预期的预期响应值,从而便于确定本次鉴权是否成功。
(4)建立第一身份验证请求和鉴权多元组之间的对应关系,并保存。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。在实际的应用场景中,还有根据业务需要在鉴权多元组中增加其他字段信息。
步骤404,接收基站发送的第二身份验证请求。
具体的说,本实施例中的步骤404与图4示出的实施例中的步骤203大致相同,步骤404的具体实现过程详见步骤203,此处不再赘述。
步骤405,判断第一身份验证请求和第二身份验证请求是否相同。
具体的说,对于引入了鉴权多元组,即对于相同的两条身份验证请求,如果满足要求,重传的身份验证请求可以直接复用鉴权多元组中存储的身份验证响应的场景,判断第一身份验证请求和第二身份验证请求是否相同的操作具体是由终端完成的,即在本实施例中USIM是不处理重传的身份验证请求的。故而,在接收到第二身份验证请求后,终端会分别确定接收到第一身份验证请求时的系统时间和接收到第二身份验证请求时的系统时间,得到第一时刻和第二时刻;然后,判断第一时刻和第二时刻之间的时间间隔是否小于时间阈值。
相应地,在时间间隔小于时间阈值时,终端会继续判断第一身份验证请求的内容和第二身份验证请求的内容是否一致,例如可以通过比较能够标识每条身份验证请求的序列号确定。
相应地,在第一身份验证请求的内容和第二身份验证请求的内容一致时,终端还会分别获取第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号;然后,继续判断第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号是否相同。
相应地,在第一身份验证请求对应的呼叫业务的会话标识号和第二身份验证请求对应的呼叫业务的会话标识号相同时,确定第一身份验证请求和第二身份验证请求相同。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。在实际的应用场景中,可以根据实际的业务需求设置不同的判断条件,此处不做限制。
通过步骤405的判断,若确定第一身份验证请求和第二身份验证请求相同,则进入步骤406,反之则进入步骤407。
步骤406,从鉴权多元组中提取第一身份验证响应作为针对第二身份验证请求作出的验证成功的第二身份验证响应,并通过基站向核心网发送第二身份验证响应。
即,直接复用鉴权多元组中记录的身份验证响应,无需USIM对第二身份验证请 求进行处理,这样就不会反悔验证失败的第二身份验证响应,终端也就不许启动T3320定时器。
相应地,在不启动T3320定时器的情况下,就不会存在T3320定时器超时后触发掉话流程的操作,即对于这种可以复用鉴权多元组中记录的身份验证响应的场景,本实施例提供的降低掉话率的方案中直接不会触发掉话流程,从而就避免了掉话问题的出现,大大降低了掉话率,提升了用户体验。
步骤407,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证成功的第二身份验证响应。
具体的说,本实施例中的步骤407与图4示出的实施例中的步骤210大致相同,步骤407的具体实现过程详见步骤210,此处不再赘述。
这样,在得到针对第一身份验证请求作出的验证成功的第一身份验证响应后,通过获取与第一身份验证请求相关的数据,如第一身份验证响应、接收到第一身份验证请求的第一时刻、第一身份验证请求对应的呼叫业务的会话标识号,进而根据这些数据生成鉴权多元组进行保存,从而可以便于后续接收到核心网通过基站重传的与第一身份验证请求相同的第二身份验证请求时,能够直接复用鉴权多元组中记录的第一身份验证响应,避免USIM误认为核心网同步异常,即认为SQN out of range,从而返回鉴权失败的第二身份验证响应,导致终端触发掉话流程。
也就是说,在接收到与第一身份验证请求相同的第二身份验证请求时,终端先查找保存的鉴权多元组是否可以给第二身份验证请求复用,然后根据结果决定是直接复用已经存在的鉴权结果,还是交由USIM重新响应于第二身份验证请求进行身份验证鉴权操作,从而可以避免USIM返回鉴权失败,进而从源头阻止掉话流程的执行,有效降低了掉话率。
为了更好的理解本实施例提供的降低掉话率的方法,以下结合图7对终端实现本实施例提供的降低掉话率的方法时,核心网、基站、终端本身,以及终端内部的USIM具体的交互进行说明。
步骤501,在终端采用CSFB技术或SRVCC技术呼叫到核心网CN的过程中,基站先向终端发送获取终端能力信息的终端能力查询请求。
步骤502,终端响应于接收到的来自基站的终端能力查询请求,获取本机的终端能力信息,例如可以是多个终端能力信息SEG,并将获取到的终端能力信息SEG持续上报给基站,例如图7中的终端能力信息SEG-1~终端能力信息SEG-N。
步骤503,在终端向基站发送终端能力信息SEG的过程中,核心网通过基站向终端发送第一身份验证请求。
步骤504,终端将第一身份验证请求发送给内部设置的USIM。
步骤505,USIM响应于第一身份验证请求,针对第一身份验证请求作出验证成功的第一身份验证响应,并发送给终端。
步骤506,终端将验证成功的第一身份验证响应发送给基站,以便基站将第一身份验证响应发送给核心网。
参见图7可知,该场景的不同在于,终端向基站发送验证成功的第一身份验证响 应后,会生成并保存与第一身份验证请求存在对应关系的鉴权多元组,以便后续复用。
关于生成,并保存鉴权多元组的方式,详见上述图6示出的实施例中步骤403的描述,此处不再赘述。
步骤507,核心网通过基站向终端发送第二身份验证请求。
不难发现,图7示出的具体场景描述中的步骤501至步骤507与图5示出的具体场景描述中的步骤301至步骤307大致相同,此处不再赘述。
步骤508,终端判断是否复用保存的鉴权多元组。
具体的说,通过上述图6示出的实施例的描述可知,终端在接收到第二身份验证请求后,需要先判断第一身份验证请求和第二身份验证请求是否相同,并在确定第一身份验证请求和第二身份验证请求相同时,判断是否存在与第一身份验证请求对应的鉴权多元组,具体的判断过程详见上述实施例中步骤405和步骤406的描述,此处不再赘述。
也就是说,若判断确定可以复用保存的鉴权多元组,则进入步骤509;反之,则说明第一身份验证请求和第二身份验证请求不相同,进入步骤510,即触发新的身份验证鉴权操作。
步骤509,终端从鉴权多元组中提取第一身份验证响应作为针对第二身份验证请求作出的验证成功的第二身份验证响应,并通过基站向核心网发送第二身份验证响应。
也就是说,对于这种情况,终端通过基站发送给核心网的实质就是验证成的第一身份验证响应。
相应地,由于发送的是验证成功的第一身份验证响应,因此终端不会启动T3320定时器,这样就不会触发掉话流程。
步骤510,终端将第二身份验证请求发送给内部设置的USIM。
步骤511,USIM响应于第二身份验证请求,针对第二身份验证请求作出验证成功的第二身份验证响应,并发送给终端。
步骤512,终端将验证成功的第二身份验证响应发送给基站,以便基站将第二身份验证响应发送给核心网。
不难发现,图7示出的具体场景描述中的步骤510至步骤512与图5示出的具体场景描述中的步骤308至步骤310大致相同,只是在图7示出的场景中,USIM针对第二身份验证请求作出的是验证成功的第二身份验证响应,故而终端通过基站发送给核心网的也是验证成功的第二身份响应,这样核心网与终端之间的身份验证鉴权就可以成功,呼叫业务就可以正常进行,从而避免了身份验证鉴权阶段出现掉话问题。
此外,可理解的,步骤510至步骤512实质就是在第一身份验证请求和第二身份验证请求不相同时,USIM、终端、基站和核心网之间的交互,对于这种场景,后续建立的会话实质是针对第二身份响应的。
由此,通过上述USIM、终端、基站和核心网的交互过程,解决了身份验证鉴权阶段存在的掉话问题。
应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
参见图8,本申请实施例提供的又一种降低掉话率的方法的具体实现方式,本实施例具体是将上述两种实现方式组合到一起,使得身份验证鉴权阶段既可以采用图4示出实施例中降低掉话率的方法,又可以采用图6出实施例中降低掉话率的方法。
步骤601,接收基站发送的第一身份验证请求。
步骤602,响应于第一身份验证请求,通过基站向核心网发送针对第一身份验证请求作出的验证成功的第一身份验证响应。
具体的说,本实施例中的步骤601和步骤602与图4示出的实施例中的步骤201和步骤202大致相同,步骤601和步骤602的具体实现过程详见步骤201和步骤202,此处不再赘述。
步骤603,生成鉴权多元组,建立第一身份验证请求和鉴权多元组之间的对应关系,并保存。
具体的说,本实施例中的步骤603与图6示出的实施例中的步骤403大致相同,步骤603的具体实现过程详见步骤403,此处不再赘述。
步骤604,接收基站发送的第二身份验证请求。
步骤605,判断第一身份验证请求和第二身份验证请求是否相同。
具体的说,本实施例中的步骤603和步骤604与图6示出的实施例中的步骤403和步骤404大致相同,步骤603和步骤604的具体实现过程详见步骤403和步骤404,此处不再赘述。
步骤606,判断是否存在与第一身份验证请求对应的鉴权多元组。
具体的说,若通过判断确定存在与第一身份验证请求对应的鉴权多元组,则进入步骤607,反之则进入步骤608。
示例性的,在实际的应用场景中,终端在生成并保存鉴权多元组时,可能会由于某些异常,导致生成的鉴权多元组没有保存到指定位置,因此在第二身份验证请求与第一身份验证请求相同时,上述步骤606中的操作可以是根据第二身份验证请求查找是否存在对应关系的鉴权多元组。
步骤607,从鉴权多元组中提取第一身份验证响应作为针对第二身份验证请求作出的验证成功的第二身份验证响应,并通过基站向核心网发送第二身份验证响应。
具体的说,本实施例中的步骤607与图6示出的实施例中的步骤406大致相同,步骤607的具体实现过程详见步骤406,此处不再赘述。
步骤608,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器。
步骤609,在T3320定时器对应的定时时长内,获取当前执行的呼叫业务的走向信息。
步骤610,根据走向信息判断呼叫业务是否往成功方向跳转。
步骤611,关闭T3320定时器。
步骤612,在T3320定时器超时后,执行掉话流程。
步骤613,响应于第二身份验证请求,通过基站向核心网发送针对第二身份验证请求作出的验证成功的第二身份验证响应。
具体的说,本实施例中的步骤608至步骤613与图4示出的实施例中的步骤205至步骤210大致相同,步骤608至步骤613的具体实现过程详见步骤205至步骤210,此处不再赘述。
关于本实施例所能达到的效果,详见图4和图5所示实施例提供的降低掉话率的方法的有效效果,以及图6和图7所示实施例提供的降低掉话率的方法的有效效果,此处不再赘述。
此外,需要说明的是,上述各实施例提供的由终端执行的降低掉话率的方法,也可以由终端中包括的一种芯片系统,例如带有处理单元的USIM(或者说SIM)来执行。其中,该芯片系统可以包括处理器。该芯片系统可以与存储器耦合,使得该芯片系统运行时调用该存储器中存储的计算机程序,实现上述终端执行的步骤。
此外,需要说明的是,该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。
另外,本申请实施例还提供一种计算机可读存储介质,该计算机存储介质中存储有计算机指令,当该计算机指令在终端上运行时,使得终端执行上述相关方法步骤实现上述实施例中应用于终端的降低掉话率的方法。
另外,本申请实施例还提供了一种计算机程序产品,当该计算机程序产品在计算机上运行时,使得计算机执行上述相关步骤,以实现上述实施例中应用于终端的降低掉话率的方法。
另外,本申请实施例还提供了一种降低掉话率的系统。该系统包括基站、核心网和上述实施例中用于实现降低掉话率的方法的终端。
另外,本申请的实施例还提供一种芯片(也可以是组件或模块),该芯片可包括一个或多个处理电路和一个或多个收发管脚;其中,所述收发管脚和所述处理电路通过内部连接通路互相通信,所述处理电路执行上述相关方法步骤实现上述实施例中的降低掉话率的方法,以控制接收管脚接收信号,以控制发送管脚发送信号。
通过上述对终端的硬件结构的描述可知,终端包括但不限于:至少一张USIM、与至少一张USIM关联的调制解调器、一个或多个处理器、存储器,以及一个或多个计算机程序。
其中,一个或多个计算机程序存储在存储器上,当计算机程序被一个或多个处理器执行时,使得终端或芯片系统能够执行上述任一方法实施例中的步骤。
由于终端实现无线通信模式的切换时执行的上述步骤与上述方法实施例中描述的降低掉话率的方法相类似,因此未在此次描述的具体细节详见上述方法实施例部分的描述,此次不再赘述。
此外,通过上述描述可知,本申请实施例提供的终端、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的降低掉话率的方法,因此,其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果,此处不再赘述。
此外,应当理解的是,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进 行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的。

Claims (15)

  1. 一种降低掉话率的方法,其特征在于,应用于终端,所述方法包括:
    接收基站发送的第一身份验证请求,所述第一身份验证请求由核心网发起,且所述核心网向所述基站发送所述第一身份验证请求后,启动T3360定时器;
    响应于所述第一身份验证请求,通过所述基站向所述核心网发送针对所述第一身份验证请求作出的验证成功的第一身份验证响应;
    接收所述基站发送的第二身份验证请求,所述第二身份验证请求由所述核心网在所述T3360定时器对应的定时时长结束后发起;
    判断所述第一身份验证请求和所述第二身份验证请求是否相同;
    在所述第一身份验证请求和所述第二身份验证请求相同时,响应于所述第二身份验证请求,通过所述基站向所述核心网发送针对所述第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器;
    在所述T3320定时器对应的定时时长内,获取当前执行的呼叫业务的走向信息,所述呼叫业务与所述第一身份验证请求和所述第二身份验证请求相关联;
    根据所述走向信息判断所述呼叫业务是否往成功方向跳转;
    在所述呼叫业务往成功方向跳转时,关闭所述T3320定时器。
  2. 根据权利要求1所述的方法,其特征在于,在所述响应于所述第一身份验证请求,通过所述基站向所述核心网发送针对所述第一身份验证请求作出的验证成功的第一身份验证响应之后,所述方法还包括:
    确定接收到所述第一身份验证请求时的系统时间,得到第一时刻;
    获取所述第一身份验证请求对应的呼叫业务的会话标识号;
    根据所述第一身份验证请求、所述第一身份验证响应、所述会话标识号和所述第一时刻生成鉴权多元组;
    建立所述第一身份验证请求和所述鉴权多元组之间的对应关系,并保存。
  3. 根据权利要求2所述的方法,其特征在于,所述鉴权多元组中记录的所述第一身份验证请求包括随机数和鉴权值;
    其中,所述鉴权值基于所述随机数计算获得。
  4. 根据权利要求2所述的方法,其特征在于,所述鉴权多元组中记录的所述第一身份验证响应包括A&C参考编号、实际响应值和预期响应值。
  5. 根据权利要求2所述的方法,其特征在于,在所述响应于所述第二身份验证请求,通过所述基站向所述核心网发送针对所述第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器之前,所述方法还包括:
    判断是否存在与所述第一身份验证请求对应的所述鉴权多元组;
    在存在与所述第一身份验证请求对应的所述鉴权多元组时,从所述鉴权多元组中提取所述第一身份验证响应作为针对所述第二身份验证请求作出的验证成功的第二身份验证响应,并通过所述基站向所述核心网发送所述第二身份验证响应;
    在不存在与所述第一身份验证请求对应的所述鉴权多元组时,执行所述响应于所述第二身份验证请求,通过所述基站向所述核心网发送针对所述第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器的步骤。
  6. 根据权利要求1所述的方法,其特征在于,所述接收基站发送的第一身份验证请求,响应于所述第一身份验证请求,通过所述基站向所述核心网发送针对所述第一身份验证请求作出的验证成功的第一身份验证响应,包括:
    通过天线接收所述基站发送的所述第一身份验证请求;
    确定处理所述第一身份验证请求的第一USIM;
    通过与所述第一USIM关联的调制解调器,将所述第一身份验证请求发送给所述第一USIM;
    由所述第一USIM响应于所述第一身份验证请求,将针对所述第一身份验证请求作出的验证成功的所述第一身份验证响应发送给所述调制解调器;
    所述调制解调器通过所述天线将验证成功的所述第一身份验证响应发送给所述基站,由所述基站向所述核心网发送验证成功的所述第一身份验证响应。
  7. 根据权利要求6所述的方法,其特征在于,所述终端内设置了两张USIM;
    所述接收所述基站发送的第二身份验证请求,判断所述第一身份验证请求和所述第二身份验证请求是否相同,包括:
    通过所述天线接收所述基站发送的所述第二身份验证请求;
    确定处理所述的第二身份验证请求的第二USIM;
    通过与所述第二USIM关联的调制解调器,将所述第二身份验证请求发送给所述第二USIM;
    在所述第一USIM与所述第二USIM为同一张USIM时,由所述第一USIM判断所述第一身份验证请求和所述第二身份验证请求是否相同;
    在所述第一USIM与所述第二USIM为不同的USIM时,由所述第二USIM响应于所述第二身份验证请求,将针对所述第二身份验证请求作出的验证成功的所述第二身份验证响应发送给所述第二USIM关联的调制解调器;
    所述第二USIM关联的调制解调器通过所述天线将验证成功的所述第二身份验证响应发送给所述基站,由所述基站向所述核心网发送验证成功的所述第二身份验证响应。
  8. 根据权利要求7所述的方法,其特征在于,所述判断所述第一身份验证请求和所述第二身份验证请求是否相同,包括:
    分别确定接收到所述第一身份验证请求时的系统时间和接收到所述第二身份验证请求时的系统时间,得到第一时刻和第二时刻;
    判断所述第一时刻和第二时刻之间的时间间隔是否小于时间阈值;
    在所述时间间隔小于所述时间阈值时,判断所述第一身份验证请求的内容和所述第二身份验证请求的内容是否一致;
    在所述第一身份验证请求的内容和所述第二身份验证请求的内容一致时,分别获取所述第一身份验证请求对应的呼叫业务的会话标识号和所述第二身份验证请求对应的呼叫业务的会话标识号;
    判断所述第一身份验证请求对应的呼叫业务的会话标识号和所述第二身份验证请求对应的呼叫业务的会话标识号是否相同;
    在所述第一身份验证请求对应的呼叫业务的会话标识号和所述第二身份验证请求对应的呼叫业务的会话标识号相同时,确定所述第一身份验证请求和所述第二身份验证请求相同。
  9. 根据权利要求8所述的方法,其特征在于,所述判断所述第一身份验证请求的内容和所述第二身份验证请求的内容是否一致,包括:
    获取所述第一身份验证请求对应的第一序列号和所述第二身份验证请求对应的第二序列号;其中,对于不同的身份验证请求,序列号不相同;
    判断所述第一序列号和所述第二序列号是否相同;
    在所述第一序列号和所述第二序列号相同时,确定所述第一身份验证请求和所述第二身份验证请求的内容一致。
  10. 根据权利要求7所述的方法,其特征在于,所述响应于所述第二身份验证请求,通过所述基站向所述核心网发送针对所述第二身份验证请求作出的验证失败的第二身份验证响应,并启动T3320定时器,包括:
    由所述第一USIM响应于所述第二身份验证请求,生成验证失败的原因值为Synch failure的所述第二身份验证响应;
    由所述第一USIM将所述第二身份验证响应发送给所述调制解调器;
    由所述调制解调器通过所述天线将验证失败的所述第二身份验证响应发送给所述基站,由所述基站向所述核心网发送验失败的所述第二身份验证响应。
  11. 根据权利要求1至10任一项所述的方法,其特征在于,所述根据所述走向信息判断所述呼叫业务是否往成功方向跳转,包括:
    判断所述走向信息是否为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act;
    在所述走向信息为Routing Area Update Accept,或者Service Accept,或者connect,或者connect act时,确定所述呼叫业务是往成功方向跳转。
  12. 根据权利要求1至10任一项所述的方法,其特征在于,在所述判断所述第一身份验证请求和所述第二身份验证请求是否相同之后,所述方法还包括:
    在所述第一身份验证请求和所述第二身份验证请求不相同时,响应于所述第二身份验证请求,通过所述基站向所述核心网发送针对所述第二身份验证请求作出的验证成功的第二身份验证响应。
  13. 一种终端,其特征在于,包括:至少一张USIM、与所述至少一张USIM关联的调制解调器、一个或多个处理器、存储器,以及一个或多个计算机程序;
    其中,所述一个或多个计算机程序存储在所述存储器上,当所述计算机程序被所述一个或多个处理器执行时,使得所述终端执行如权利要求1至12中任意一项所述的降低掉话率的方法。
  14. 一种计算机可读存储介质,包括计算机程序,其特征在于,当所述计算机程序在终端上运行时,使得所述终端执行如权利要求1至12中任意一项所述的降低掉话率的方法。
  15. 一种芯片,其特征在于,包括:一个或多个处理电路和一个或多个收发管脚;其中,所述收发管脚和所述处理电路通过内部连接通路互相通信,所述处理电路执行权利要求1至12中任意一项所述的降低掉话率的方法,以控制接收管脚接收信号,以控制发送管脚发送信号。
PCT/CN2022/112510 2021-09-29 2022-08-15 降低掉话率的方法及终端 Ceased WO2023051060A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/571,646 US20240284266A1 (en) 2021-09-29 2022-08-15 Call Drop Rate Reduction Method and Terminal
EP22874455.3A EP4340422B1 (en) 2021-09-29 2022-08-15 Method for reducing call drop rate and terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111153780.XA CN113630776B (zh) 2021-09-29 2021-09-29 降低掉话率的方法及终端
CN202111153780.X 2021-09-29

Publications (1)

Publication Number Publication Date
WO2023051060A1 true WO2023051060A1 (zh) 2023-04-06

Family

ID=78390614

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/112510 Ceased WO2023051060A1 (zh) 2021-09-29 2022-08-15 降低掉话率的方法及终端

Country Status (4)

Country Link
US (1) US20240284266A1 (zh)
EP (1) EP4340422B1 (zh)
CN (2) CN114339749B (zh)
WO (1) WO2023051060A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114339749B (zh) * 2021-09-29 2023-09-19 荣耀终端有限公司 降低掉话率的方法及终端

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015184805A1 (en) * 2014-06-02 2015-12-10 Qualcomm Incorporated Method of reducing call drop rate by deferring a tvm report during and right after a handover procedure
CN105208530A (zh) * 2015-09-02 2015-12-30 哈尔滨海能达科技有限公司 一种组呼业务处理方法、终端及核心网网元
CN111182534A (zh) * 2019-12-20 2020-05-19 翱捷科技(上海)有限公司 移动终端及其在wcdma网络下进行串行鉴权的方法
CN111954217A (zh) * 2020-08-19 2020-11-17 中国移动通信集团江苏有限公司 用户身份验证方法、装置、电子设备及计算机存储介质
CN112637850A (zh) * 2020-11-30 2021-04-09 展讯半导体(成都)有限公司 鉴权异常的处理方法、系统及用户终端
CN113630776A (zh) * 2021-09-29 2021-11-09 荣耀终端有限公司 降低掉话率的方法及终端

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009116378A (ja) * 2007-11-01 2009-05-28 Renesas Technology Corp 半導体装置
KR101156164B1 (ko) * 2008-12-22 2012-06-18 한국전자통신연구원 주파수 집합 통신 환경에서의 단말 및 기지국, 이를 이용한호 접속 처리 방법
CN102316454B (zh) * 2011-10-12 2013-08-14 西安新邮通信设备有限公司 由无线网络控制器触发的终端差异性分析的方法
KR20130073850A (ko) * 2011-12-23 2013-07-03 삼성전자주식회사 페이크 네트워크의 식별을 위한 방법 및 장치
CN106411812B (zh) * 2015-07-27 2019-10-08 阿里巴巴集团控股有限公司 用户身份的验证方法、系统和验证服务器
CN106797562B (zh) * 2015-08-13 2019-04-26 华为技术有限公司 一种消息保护的方法、相关设备以及系统
US10091832B2 (en) * 2015-11-17 2018-10-02 Affirmed Networks, Inc. Call failure reduction
CN106789851A (zh) * 2015-11-24 2017-05-31 阿里巴巴集团控股有限公司 身份验证方法、系统、业务服务器和验证服务器
EP3396928B1 (en) * 2016-01-11 2021-06-30 Huawei Technologies Co., Ltd. Method for managing network access rights and related device
WO2018011619A1 (en) * 2016-07-14 2018-01-18 Telefonaktiebolaget Lm Ericsson (Publ) Enhanced aggregated re-authentication for wireless devices
CN108616862A (zh) * 2017-01-16 2018-10-02 中兴通讯股份有限公司 一种快速呼通方法和装置
US20200304984A1 (en) * 2019-03-22 2020-09-24 Apple Inc. Timer Activation for Dual SIM Dual Standby Devices
JP6870022B2 (ja) * 2019-03-28 2021-05-12 シャープ株式会社 端末装置、方法、および、集積回路
CN113498123B (zh) * 2020-03-20 2023-06-02 华为技术有限公司 一种网络接入系统、方法及终端

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015184805A1 (en) * 2014-06-02 2015-12-10 Qualcomm Incorporated Method of reducing call drop rate by deferring a tvm report during and right after a handover procedure
CN105208530A (zh) * 2015-09-02 2015-12-30 哈尔滨海能达科技有限公司 一种组呼业务处理方法、终端及核心网网元
CN111182534A (zh) * 2019-12-20 2020-05-19 翱捷科技(上海)有限公司 移动终端及其在wcdma网络下进行串行鉴权的方法
CN111954217A (zh) * 2020-08-19 2020-11-17 中国移动通信集团江苏有限公司 用户身份验证方法、装置、电子设备及计算机存储介质
CN112637850A (zh) * 2020-11-30 2021-04-09 展讯半导体(成都)有限公司 鉴权异常的处理方法、系统及用户终端
CN113630776A (zh) * 2021-09-29 2021-11-09 荣耀终端有限公司 降低掉话率的方法及终端
CN114339749A (zh) * 2021-09-29 2022-04-12 荣耀终端有限公司 降低掉话率的方法及终端

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4340422A4

Also Published As

Publication number Publication date
EP4340422A1 (en) 2024-03-20
US20240284266A1 (en) 2024-08-22
CN114339749A (zh) 2022-04-12
CN113630776B (zh) 2022-02-08
CN114339749B (zh) 2023-09-19
EP4340422B1 (en) 2025-06-04
EP4340422A4 (en) 2024-10-16
CN113630776A (zh) 2021-11-09

Similar Documents

Publication Publication Date Title
KR102374338B1 (ko) 무선 통신 시스템에서 데이터를 송수신하는 전자 장치 및 이를 위한 방법
CN110896528B (zh) 操作电子装置的功能和资源的方法
CN115297448B (zh) 网络回落方法、设备及存储介质
US20130150032A1 (en) Controlled Idle Mode Behavior in User Equipment Supporting Multiple Radio Access Techniques
CN111342863A (zh) 数据传输方法、数据传输装置及存储介质
TW201328267A (zh) 用於用戶識別模組的系統
US20240188041A1 (en) Paging cause processing method and apparatus, communication device, and storage medium
US20240179678A1 (en) Paging processing method, communication device and storage medium
WO2023147754A1 (zh) 一种用于用户设备发起ims注册的方法以及相应的用户设备
US20260032760A1 (en) Method for call, device, chip system, and storage medium
CN116997029A (zh) 无线网络接入方法、装置、通信设备及存储介质
WO2023051060A1 (zh) 降低掉话率的方法及终端
CN103781138B (zh) 一种WiMo发送端接入WLAN的方法、装置及系统
US12342350B2 (en) Data transmission methods and communication device
WO2021212430A1 (zh) 发送数据的方法、装置、用户设备及存储介质
CN109496448A (zh) 网络参数配置方法、装置及计算机可读存储介质
WO2020252643A1 (zh) 一种信息处理方法、装置及计算机存储介质
US20240397573A1 (en) Downlink transmission configuration and receiving methods and apparatuses, communication device and storage medium
CN116669172B (zh) 网络注册方法、装置、设备及存储介质
WO2025146008A1 (zh) 网络注册方法和终端
US20260081929A1 (en) Communication Method, Communication Apparatus, and Electronic Device
WO2025066583A1 (zh) 信息处理方法、终端设备及芯片系统
WO2025130026A1 (zh) 位置更新的方法、设备、芯片系统及存储介质
WO2025066500A1 (zh) 通信连接的方法及终端设备
WO2025055800A1 (zh) 网络注册处理方法、装置、系统及通信设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22874455

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022874455

Country of ref document: EP

Ref document number: 22874455.3

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022874455

Country of ref document: EP

Effective date: 20231214

WWE Wipo information: entry into national phase

Ref document number: 18571646

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWG Wipo information: grant in national office

Ref document number: 2022874455

Country of ref document: EP