Detecting Unresponsive User Equipment

A system can communicate broadband cellular communications with a user equipment. The system can perform iterations of scheduling downlink data for the user equipment as part of the broadband cellular communications. The system can, in response to determining that hybrid automatic repeat request feedback, which corresponds to downlink data of the iterations of scheduling downlink data, has not been received within a defined time period, initiate a user equipment release transaction with regard to the user equipment, and send a user equipment context release request to a centralized unit of a base station of the system.

BACKGROUND

In cellular broadband communications, a core network can determine that a user equipment has become unresponsive.

SUMMARY

An example system can operate as follows. The system can communicate broadband cellular communications with a user equipment. The system can perform iterations of scheduling downlink data for the user equipment as part of the broadband cellular communications. The system can, in response to determining that hybrid automatic repeat request feedback, which corresponds to downlink data of the iterations of scheduling downlink data, has not been received within a defined time period, initiate a user equipment release transaction with regard to the user equipment, and send a user equipment context release request to a centralized unit of a base station of the system.

An example method can comprise facilitating, by a system comprising a processor, broadband cellular communications with a user equipment. The method can further comprise instructing, by the system, the user equipment to provide periodic hybrid automatic repeat request feedback from the user equipment to the system, wherein the hybrid automatic repeat request feedback corresponds to the broadband cellular communications. The method can further comprise, in response to determining that a defined number of consecutive hybrid automatic repeat request feedback indications of the hybrid automatic repeat request feedback has not been received, initiating, by the system, a user equipment release transaction for the user equipment, and sending, by the system, a user equipment context release request to a centralized unit of a base station.

An example non-transitory computer-readable medium can comprise instructions that, in response to execution, cause a system comprising a processor to perform operations. These operations can comprise at least one of sending or receiving broadband cellular communications to or from a user equipment, respectively. These operations can further comprise instructing the user equipment to send periodic hybrid automatic repeat request feedback from the user equipment to the system, wherein the hybrid automatic repeat request feedback corresponds to the broadband cellular communications. These operations can further comprise, in response to determining that a defined number of consecutive hybrid automatic repeat request feedback indications of the hybrid automatic repeat request feedback has not been received, initiating a user equipment release transaction for the user equipment.

DETAILED DESCRIPTION

Overview

The present techniques can generally relate to detecting unresponsive user equipment using hybrid automatic repeat request (HARQ) feedback.

In cellular communications, HARQ feedback can comprise a user equipment (UE) adding error detection (ED) information and/or forward error correction (FEC) information to a message that is sent to a gNodeB (gNB). When a gNB receives such a message, it can decode the error-correction code. Where a channel quality between the UE and gNB is sufficiently good, the gNB can obtain the correct data block (such as by correcting any transmission errors). When channel quality between the UE and gNB is bad, it can be that not all transmission errors can be corrected, the gNB can identify this situation using error detection code, and the received data block can be rejected and the gNB can request that the UE retransmit the data block.

HARQ feedback from a UE can be used to determine if the UE is active or not. A gNB can determine that a UE is unreachable through block error rate (BLER; radio link control (RLC) unacknowledged mode (UM)) or RLC maximum retransmission (RLC acknowledged mode (AM)) in DL or UE reestablishment.

However, where there is no data or uplink (UL) interference, detecting a radio link failure (RLF) can be difficult for a gNB. In some examples, it can be that moving a UE to a radio resource control (RRC) inactive state due to data inactivity is not the right approach, as a data inactivity timer can be in seconds. Additionally, it can be that moving a UE to RRC inactive status can be unsuccessful where the UE is unreachable.

Given these problems with prior approaches, the present techniques can be implemented to facilitate using HARQ feedback to detect a reachability of a UE.

A UE can connect to a gNB to get multiple services like enhanced mobile broadband (eMBB) or voice over new radio (VoNR). With eMBB, a data rate between the UE and the gNB will be in gigabits per second (gbps). It can be that efficiently using over-the-air resources can be valuable in achieving and sustaining high data rates. Operators can buy spectrum from a government via auction, and using all resources in the spectrum can be important to providing good quality of service (QoS), and thereby attracting more customers, which can, in turn, result in higher revenue.

There can be problems with prior approaches to detecting that a RLF for a UE. With regard to a transmission control protocol (TCP) and/or a user datagram protocol (UDP), detecting RLF can be difficult for a gNB when there is no data, or when UL interference is high. A TCP retry timeout can take multiple seconds, and this amount of time to detect RLF can be too long.

Another problem with prior approaches can be that a gNB can allocate radio resources and schedule UDP data continuously to a UE even when the UE has stopped responding to the received data at a HARQ level.

Another problem with prior approaches can be that a gNB can allocate radio resources and schedule UDP data (data centric service) continuously to a UE, even when the UE has stopped responding to the received data at a packed data convergence protocol (PDCP) level (e.g., a level 2 (L2) internal failure at the UE).

In these scenarios, there can be active data flowing in a DL from an application in a gNB, and hence it can be that the UE is not moved to a RRC INACTIVE state. This can waste physical resources and reduce spectrum usage efficiency, where that spectrum could be utilized by other UEs that are functioning normally.

Even with an abnormal UE, early detection and release can mean a faster way to get in service, reduce out-of-service time, and reduce unwanted battery drain during an abnormal period.

In example, the present techniques can be implemented such that a gNB detects DL HARQ as discontinuous reception (DTX), and a UE-initiated release triggered from the gNB's distributed unit (DU) to the gNB's centralized unit (CU). The CU can trigger a release of the UE to all gNBs that the UE is connected to and access and mobility management function (AMF).

When a gNB schedules DL data for a UE, then the gNB continuously detects HARQ feedback as DTX, the gNB can start a timer, T_HARQ_DTX (ms). After expiry of this timer, if the UE has not become reachable, the gNB can start a UE release procedure to save physical resources. In some examples, T_HARQ_DTX can be determined as:

In this determination, n310 can comprise a parameter that indicates a number of times when the UE is unable to successfully decode physical downlink control channel (PDCCH) information due to low reference signal received power (RSRP) detected. That is, n310 can indicate a number of times in which the UE cannot successfully decode a specified number of consecutive frames in the downlink.

n310 can also comprise a maximum number of consecutive “out-of-sync” indications for a PCell that are received from lower layers.

t310 can comprise a timer, in seconds, used to allow the UE to get back in synchronization with the gNB.

The timer t310 can start upon detecting physical layer problems for a PCell—e.g., upon receiving n310 consecutive out-of-sync indications from lower layers.

The timer t310 can stop upon receiving n311 consecutive in-sync indications from lower layers for a PCell, upon triggering a handover procedure, and/or upon initiating the connection re-establishment procedure.

At expiry of the timer t310, if security is not activated, then an RRC_IDLE state can be entered, and otherwise ELSE a connection establishment procedure can be initiated.

n311 can comprise a parameter that indicates a number of intervals for which the UE successfully decodes the PDCCH to be considered back in sync with the gNB. That is, n311 can indicate a number of times in which the UE successfully decodes a specified number of frames in the downlink in order for the UE to assume the radio link is in-synch.

n311 can also comprise a maximum number of consecutive “in-sync” indications for a PCell received from lower layers.

T_EVALUATE_OUT_SSB can comprise a timer that is used by a UE to evaluate whether downlink radio link quality on a configured radio link monitoring reference signal (RLM-RS) resource estimated over a last TEvaluate_out_SSB(SSB evaluation timer) period (which can be measured in ms) becomes worse than a threshold Qout_SSBwithin the TEvaluate_out_SSBevaluation period. Qout_SSBcan comprise a synchronization signal block (SSB) quality threshold value. The threshold Qoutcan indicate a level at which a downlink radio link cannot be reliably received and can correspond to an out-of-sync block error rate (BLERout). For SSB based radio link monitoring. Qout_SSBcan be derived based on hypothetical PDCCH transmission parameters.

t301 can comprise a timer that starts at a transmission of a RRC connection re-establishment request. The timer t301 can stop at reception of a RRC connection re-establishment message or a RRC connection re-establishment reject message, as well as when a selected cell becomes unsuitable.

Upon expiry, the timer t301 can go to an RRC_IDLE state.

On the expiry of a timer, a counter, HARQBasedRlfCounter, can be checked. HARQBasedRlfCounter can comprise a counter that is incremented when HARQ feedback that should be received from the UE has not been received. This check can comprise performing the following determination:

If (HARQBasedRlfCounter>=T_HARQ_DTX) then,initiate UE release transaction and send UE context release request to CU with cause (radio_network_layer, RL failure, etc.)

It can be that HARQ feedback occurs where a gNB is sending DL data for a UE, and the gNB does not receive an ACK or NACK for the DL data, so detects this absence of an ACK/NACK as DTX. When this occurs, a gNB can determine that a UE has moved out of the gNB's coverage area, and the gNB can take an action to release the UE once the T_HARQ_DTX condition is satisfied.

Example Architectures

FIG.1illustrates an example system architecture100that can facilitate detecting unresponsive user equipment in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecture100can be used to implement the example signal flows ofFIGS.4-5, and/or the example process flows ofFIGS.6-10.

In cellular communications, there can be a master cell group (MCG) to which a UE initially registers. A cell that is used to initiate initial access can be referred to as a primary cell (Pcell).

The examples herein generally relate to fifth generation (5G) cellular communications networks, where Pcells are used. It can be appreciated that the present techniques can be applied to other types of cellular communications networks for detecting unresponsive user equipment.

gNB102can generally comprise a cellular 5G base station, can comprise multiple antennas, and can concurrently communicate with multiple instances of UE106. UE106can generally comprise a computing device that is configured to be used directly by an end-user to communicate with gNB102. Pcell104can be a Pcell as described herein, and that is communicatively coupled to both gNB102and UE106.

Detecting unresponsive user equipment component108A can generally comprise a component of gNB102that facilitates detecting unresponsive user equipment for gNB102as described herein. Similarly, detecting unresponsive user equipment component108B can generally comprise a component of UE106that facilitates detecting unresponsive user equipment for UE106as described herein.

In some examples, detecting unresponsive user equipment component108A can implement part(s) of the signal flows ofFIGS.4-5, and/or the process flows ofFIGS.6-10to implement detecting unresponsive user equipment.

It can be appreciated that system architecture100(and each of the system architectures ofFIGS.2-3) is one example system architecture for generating and distributing security policies in a containerized environment, and that there can be other system architectures that facilitate generating and distributing security policies in a containerized environment.

FIG.2illustrates another example system architecture200that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecture200can be implemented by part(s) of system architecture100ofFIG.1to facilitate detecting unresponsive user equipment. In some examples, part(s) of system architecture200can be used to implement the example signal flows ofFIGS.4-5, and/or the example process flows ofFIGS.6-10.

System architecture200comprises gNB202(which can be similar to gNB102ofFIG.1), UE206(which can be similar to UE106), detecting unresponsive user equipment component208A (which can be similar to detecting unresponsive user equipment component108A), distributed unit (DU)210, and centralized unit (CU)212.

In general, for gNB202, DU210can provide support for lower layers of a protocol stack, such as radio link control (RLC), medium access control (MAC), and physical layer; and CU212can provide support for higher layers of the protocol stack, such as service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), and radio resource control (RRC).

UE206can communicate with gNB202via DU210, and DU210can communicate with CU212. Given that architecture, it can be that determinations can be made at DU210based on information received (or not received) from UE206faster than they can be made at CU212(since the information from UE206would take time to be transferred from DU210to CU212). In some examples, a determination by detecting unresponsive user equipment component208A that UE206is unresponsive can be made at DU210, which then sends a user equipment context release request to CU212to effectuate releasing UE206.

FIG.3illustrates another example system architecture300that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, part(s) of system architecture300can be implemented by part(s) of system architecture100ofFIG.1to facilitate detecting unresponsive user equipment. In some examples, part(s) of system architecture300can be used to implement the example signal flows ofFIGS.4-5, and/or the example process flows ofFIGS.6-10.

System architecture300comprises gNB302(which can be similar to an instance of gNB102ofFIG.1), UE306(which can be similar to UE106), detecting unresponsive user equipment component308A (which can be similar to detecting unresponsive user equipment component108A), and access and mobility management component (AMF)316. Communications network314comprises gNB302and AMF316.

AMF316can generally comprise a portion of a cellular communications network (along with gNB302) that is configured to handle connection and mobility management tasks.

A CU of a gNB that determines that UE306is unresponsive (here, gNB302) can send a user equipment context release to AMF316that UE306is communicatively coupled to as part of the broadband cellular communications.

Example Signal Flow

FIG.4andFIG.5illustrate an example signal flow400and500that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, part(s) of signal flow400and500can be implemented by part(s) of system architecture100ofFIG.1to facilitate detecting unresponsive user equipment.

As depicted, in signal flow400and500, communications are sent between UE402, gNB404, and 5G core (5GC)406(which comprises access and mobility management function (AMF)408and user plane function (UPF)410).

The signal flow of signal flow400and500is an example signal flow, and there can be signal flows that implement different signals, or the signals of signal flow400and500in a different order, as part of facilitating detecting unresponsive user equipment.

As depicted in signal flow400and500, the following occurs:5G-NR RRC connection setup412.Msg1: Preamble414Allocate temporary cell radio-network temporary identifier (C-RNTI)416Physical downlink control channel (PDCCH) downlink control information (DCI) Format 1_0 [random access radio network temporary identifier (RA_RNTI)]418Msg2: Random Access Response420Msg3: RRCSetupRequest422.PDCCH DCI Format 1_0 [C_RNTI]424Msg4: RRCSetup426.PDCCH DCI Format 0_0 [C_RNTI]428RRCSetupComplete430AMF selection432Initial UE message434[non-access-stratum-protocol data unit (NAS-PDU): Registration Request]NAS identity request/response436NAS authentication request/response438NAS security mode command/complete440UE capability enquiry442UE capability information444Initial context setup request446[NAS-PDU: Registration Accept]RRCReconfiguration448(configure physical uplink control channel (PUCCH) resources to report DL HARQ feedback on PUCCH; configure uplink control information (UCI) on physical uplink shared channel (PUSCH) configuration to report DL HARQ feedback on PUSCH)RRCReconfigurationComplete450Initial context setup response452SA UE attach procedure completed454Start downlink data transfer & monitoring of DL HARQ feedback on PUCCH and/or PUSCH456Downlink data458Downlink data460PDCCH DCI format 1_0/1_1462[C_RNTI]Downlink data464[MAC PDU contains physical downlink shared channel (PDSCH)]PDCCH DCI format 1_0/1_1466[C_RNTI]Downlink data468[MAC PDU contains PDSCH]HARQ feedback=ACK470HARQ feedback=ACK472Downlink data474Downlink data476gNB continuously detecting DL HARQ feedback report as discontinuous transmission (DTX) for all transmitted DL data packets478HARQ feedback=NACK480HARQ feedback=NACK482Channel condition getting worse484.HARQ feedback=NACK486HARQ feedback=DTX488.HARQ feedback=DTX490HARQ feedback=DTX492(gNB started detecting T_HARQ_DTX (ms) consecutive HARQ feedback detected at gNB as DTX for determined time in ms)T_HARQ_DTX (ms) parameter determined at gNB based on T_HARQ_DTX=(n310*T_EVALUATEOUT_SSB+t310+t301)494DL HARQ-based RLF detect condition met496(initiate UE release transaction and send UE context release request to CU with cause (e.g., radio_network_layer, RL failure)Standalone (SA) UE release procedure started by gNB-DU498

Example Process Flows

FIG.6illustrates an example process flow600that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow600can be implemented by detecting unresponsive user equipment component108A of gNB102FIG.1, or computing environment1100ofFIG.11.

In some examples, process flow600can be used to determine T_HARQ_DTX (as described herein) through a determination of:

Process flow600begins with602, and moves to operation604.

Operation604depicts determining n310. n310 can comprise a parameter as described herein.

After operation604, process flow600moves to operation606.

Operation606depicts determining T_EVALUATE_OUT_SSB. T_EVALUATE_OUT_SSB can comprise a timer as described herein.

After operation606, process flow600moves to operation608.

Operation608depicts determining t310. t310 can comprise a timer as described herein.

After operation608, process flow600moves to operation610.

Operation610depicts determining t301. t301 can comprise a timer as described herein.

After operation610, process flow600moves to operation612.

Operation612depicts determining T_HARQ_DTX=(n310*T_EVALUATE_OUT_SSB+t310+t301). That is, a value for T_HARQ_DTX can be determined by evaluating this expression.

FIG.7illustrates an example process flow700that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow700can be implemented by detecting unresponsive user equipment component108A of gNB102FIG.1, or computing environment1100ofFIG.11.

Process flow700begins with702, and moves to operation704.

Operation704is reached from702, or from operation708. Operation704depicts detecting HARQ as DTX and incrementing HARQBasedRlfCounter. HARQBasedRlfCounter can be a counter that incremented every time when HARQ as DTX is detected. When the count is matched with T_HARQ_DTX (as in operation706) then gNB can start a UE release procedure (as in operation710).

After operation704, process flow700moves to operation706.

Operation706depicts determining whether HARQBasedRlfCounter is at least T_HARQ_DTX. That is, using T_HARQ_DTX as determined through process flow600ofFIG.6, it can be determined whether that many consecutive HARQ feedbacks have not been received, where HARQBasedRlfCounter can comprise a counter that tracks a number of consecutive HARQ reports that have not been received.

Where it is determined in operation706that HARQBasedRlfCounter is at least T_HARQ_DTX, process flow700moves to operation710. Instead, where it is determined in operation706that HARQBasedRlfCounter is not at least T_HARQ_DTX, process flow700moves to operation708.

Operation708is reached from operation706where it is determined in operation706that HARQBasedRlfCounter is not at least T_HARQ_DTX. Operation708depicts resetting HARQBasedRlfCounter to zero.

After operation708, process flow700moves to operation704.

Operation710is reached from operation706where it is determined in operation706that HARQBasedRlfCounter is at least T_HARQ_DTX. Operation710depicts initiating a UE release transaction and sending UE context release request to CU with cause. This cause can be, for example, radio_network_layer and/or RL failure. Using the example ofFIG.2, this can comprise DU210sending a UE context release request to CU212, where in this UE context release request applies to UE206.

FIG.8illustrates an example process flow800that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow800can be implemented by detecting unresponsive user equipment component108A of gNB102FIG.1, or computing environment1100ofFIG.11.

Process flow800begins with802, and moves to operation804.

Operation804depicts communicating broadband cellular communications with a user equipment. Using the example ofFIG.1, this can comprise gNB102and UE106having set up a connection.

After operation804, process flow800moves to operation1806.

Operation806depicts performing iterations of scheduling downlink data for the user equipment as part of the broadband cellular communications. Using the example of the signal flow ofFIGS.4-5, this can comprise gNB404sending UE402downlink data464, downlink data468, downlink data474, and downlink data476.

After operation806, process flow800moves to operation808.

Operation808depicts, in response to determining that hybrid automatic repeat request feedback, which corresponds to downlink data of the iterations of scheduling downlink data, has not been received within a defined time period, initiating a user equipment release transaction with regard to the user equipment, and sending a user equipment context release request to a centralized unit of a base station of a system. that implements process flow800. Continuing with the example ofFIG.1, this can comprise gNB102not receiving a determined number of consecutive HARQ feedback messages from UE106. In such a case, gNB102can initiate a UE release for UE106, and a DU of gNB102can send a UE release request to a CU of gNB102.

In some examples, the system comprises a distributed unit of the base station, and wherein the sending of the user equipment context release request to the centralized unit is performed by the distributed unit.

In some examples, the system comprises the centralized unit, the user equipment is communicatively coupled to an access and mobility management function component as part of the broadband cellular communications, and operation808comprises triggering, by the centralized unit, a user equipment context release that corresponds to the user equipment context release request with the access and mobility management function component. That is, where the communications network comprises an AMF, a CU can trigger a release of the UE to the AMF of the communications network.

In some examples, operation808comprises determining a number of occurrences of the hybrid automatic repeat request feedback for the hybrid automatic repeat request feedback not being received within the defined time period based on a time value of a timer that is configured for measurement of whether the user equipment is synchronized with the system. This can be similar to using timer T310.

In some examples, operation808comprises determining a number of occurrences of the hybrid automatic repeat request feedback for the hybrid automatic repeat request feedback not being received within the defined time period based on a consecutive occurrences of in-sync indications for a primary cell with respect to the user equipment. This can be similar to N311.

In some examples, operation808comprises determining a defined number of hybrid automatic repeat request feedback indications of the hybrid automatic repeat request feedback based on a defined number of consecutive occurrences of out-of-sync indications for a primary cell with respect to the user equipment. This can be similar to n310 as described herein.

In some examples, operation808comprises determining the defined number of hybrid automatic repeat request feedback indications based on a product of, the defined number of consecutive occurrences of out-of-sync indications for the primary cell with respect to the user equipment, and a time value of a timer that is configured for measurement of whether the user equipment is synchronized with the system. This can be similar to n310*T_EVALUATE_OUT_SSB as described herein.

FIG.9illustrates an example process flow900that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow900can be implemented by detecting unresponsive user equipment component108A of gNB102FIG.1, or computing environment1100ofFIG.11.

Process flow900begins with902, and moves to operation904.

Operation904depicts facilitating broadband cellular communications with a user equipment. In some examples, operation904can be implemented in a similar manner as operation704ofFIG.7.

In some examples, operation904comprises, as part of establishing the broadband cellular communications with the user equipment, sending, by the system to the user equipment, a radio resource control reconfiguration message that indicates a configuration of physical uplink control channel resources to report the hybrid automatic repeat request feedback via a physical uplink control channel. In some examples, operation904comprises, as part of establishing the broadband cellular communications with the user equipment, sending, by the system to the user equipment, a radio resource control reconfiguration message that indicates to the user equipment to report the hybrid automatic repeat request feedback in uplink control information. In some examples, the radio resource control reconfiguration message indicates to the user equipment to report the hybrid automatic repeat request feedback in uplink control information via a physical uplink shared channel. This can be similar to RRCReconfiguration448(configure PUCCH resources to report DL HARQ feedback on PUCCH; configure UCI on PUSCH configuration to report DL HARQ feedback on PUSCH) ofFIG.4.

After operation904, process flow900moves to operation906.

Operation906depicts instructing the user equipment to provide periodic hybrid automatic repeat request feedback from the user equipment to the system, wherein the hybrid automatic repeat request feedback corresponds to the broadband cellular communications. In some examples, operation906can be implemented in a similar manner as operation706ofFIG.7.

After operation906, process flow900moves to operation908.

Operation908depicts, in response to determining that a defined number of consecutive hybrid automatic repeat request feedback indications of the hybrid automatic repeat request feedback has not been received, initiating a user equipment release transaction for the user equipment, and sending a user equipment context release request to a centralized unit of a base station. In some examples, operation908can be implemented in a similar manner as operation708ofFIG.7.

In some examples, operation908comprises determining the defined number of consecutive hybrid automatic repeat request feedback indications based on a time value of a timer that is configured for measurement of whether the user equipment is synchronized with the system. This timer can be similar to t310 as described herein.

In some examples, operation908comprises determining the defined number of consecutive hybrid automatic repeat request feedback indications based on a consecutive occurrences of in-sync indications for a primary cell with respect to the user equipment. These consecutive occurrences of in-sync indications can be similar to n311 as described herein.

In some examples, operation908comprises determining the defined number of consecutive hybrid automatic repeat request feedback indications based on a time measurement during which a downlink radio quality on a radio link monitoring reference signal resource is evaluated to determine whether a first value of the downlink radio quality is less than a second value of a synchronization signal block quality threshold metric. This can be similar to T_EVALUATE_OUT_SSB as described herein.

FIG.10illustrates an example process flow1000that can facilitate detecting unresponsive user equipment, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow1000can be implemented by detecting unresponsive user equipment component108A of gNB102FIG.1, or computing environment1100ofFIG.11.

Process flow1000begins with1002, and moves to operation1004.

Operation1004depicts at least one of sending or receiving broadband cellular communications to or from a user equipment, respectively. In some examples, operation1004can be implemented in a similar manner as operation704ofFIG.7.

After operation1004, process flow1000moves to operation1006.

Operation1006depicts instructing the user equipment to send periodic hybrid automatic repeat request feedback from the user equipment to the system, wherein the hybrid automatic repeat request feedback corresponds to the broadband cellular communications. In some examples, operation1006can be implemented in a similar manner as operation706ofFIG.7.

In some examples, operation1006comprises configuring a hybrid automatic repeat request feedback information reporting confirmation with the user equipment before initiating the receiving of the hybrid automatic repeat request feedback. In some examples, operation1006comprises configuring a hybrid automatic repeat request feedback periodicity with the user equipment before initiating the receiving of the hybrid automatic repeat request feedback. That is, it can be that HARQ feedback confirmation and periodicity can be configurable by a gNB to UE. Based on that configuration, the UE can report the HARQ feedback to the gNB.

After operation1006, process flow1000moves to operation1008.

Operation1008depicts, in response to determining that a defined number of consecutive hybrid automatic repeat request feedback indications of the hybrid automatic repeat request feedback has not been received, initiating a user equipment release transaction for the user equipment. In some examples, operation1008can be implemented in a similar manner as operation708ofFIG.7.

On some examples, operation1008comprises, in response to the determining that the defined number of consecutive hybrid automatic repeat request feedback indications of the hybrid automatic repeat request feedback has not been received, sending a user equipment context release request to a centralized unit of a base station, wherein the user equipment context release request indicates a reason for the user equipment context release request. That is, a UE context release request can be sent to a CU that identifies a cause for the UE context release request.

In some examples, the reason indicates a radio network layer. That is, the cause can be radio_network_layer. In some examples, the reason indicates a radio link failure.

Example Operating Environment

In order to provide additional context for various embodiments described herein,FIG.11and the following discussion are intended to provide a brief, general description of a suitable computing environment1100in which the various embodiments of the embodiment described herein can be implemented.

For example, parts of computing environment1100can be used to implement one or more embodiments of gNB102, Pcell104, and/or UE106, ofFIG.1.

In some examples, computing environment1100can implement one or more embodiments of the signal flows ofFIGS.4-5, and/or the process flows ofFIGS.6-10to facilitate detecting unresponsive user equipment.

While the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments can be also implemented in combination with other program modules and/or as a combination of hardware and software.

The system bus1108can be any of several types of bus structure that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory1106includes ROM1110and RAM1112. A basic input/output system (BIOS) can be stored in a nonvolatile storage such as ROM, erasable programmable read only memory (EPROM), EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer1102, such as during startup. The RAM1112can also include a high-speed RAM such as static RAM for caching data.

The computer1102further includes an internal hard disk drive (HDD)1114(e.g., EIDE, SATA), one or more external storage devices1116(e.g., a magnetic floppy disk drive (FDD)1116, a memory stick or flash drive reader, a memory card reader, etc.) and an optical disk drive1120(e.g., which can read or write from a CD-ROM disc, a DVD, a BD, etc.). While the internal HDD1114is illustrated as located within the computer1102, the internal HDD1114can also be configured for external use in a suitable chassis (not shown). Additionally, while not shown in environment1100, a solid state drive (SSD) could be used in addition to, or in place of, an HDD1114. The HDD1114, external storage device(s)1116and optical disk drive1120can be connected to the system bus1108by an HDD interface1124, an external storage interface1126and an optical drive interface1128, respectively. The interface1124for external drive implementations can include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 7-interface technologies. Other external drive connection technologies are within contemplation of the embodiments described herein.

A number of program modules can be stored in the drives and RAM1112, including an operating system1130, one or more application programs1132, other program modules1134and program data1136. All or portions of the operating system, applications, modules, and/or data can also be cached in the RAM1112. The systems and methods described herein can be implemented utilizing various commercially available operating systems or combinations of operating systems.

Computer1102can optionally comprise emulation technologies. For example, a hypervisor (not shown) or other intermediary can emulate a hardware environment for operating system1130, and the emulated hardware can optionally be different from the hardware illustrated inFIG.11. In such an embodiment, operating system1130can comprise one virtual machine (VM) of multiple VMs hosted at computer1102. Furthermore, operating system1130can provide runtime environments, such as the Java runtime environment or the NET framework, for applications1132. Runtime environments are consistent execution environments that allow applications1132to run on any operating system that includes the runtime environment. Similarly, operating system1130can support containers, and applications1132can be in the form of containers, which are lightweight, standalone, executable packages of software that include, e.g., code, runtime, system tools, system libraries and settings for an application.

A monitor1146or other type of display device can be also connected to the system bus1108via an interface, such as a video adapter1148. In addition to the monitor1146, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

The computer1102can operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s)1150. The remote computer(s)1150can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer1102, although, for purposes of brevity, only a memory/storage device1152is illustrated. The logical connections depicted include wired/wireless connectivity to a local area network (LAN)1154and/or larger networks, e.g., a wide area network (WAN)1156. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer1102can be connected to the local network1154through a wired and/or wireless communication network interface or adapter1158. The adapter1158can facilitate wired or wireless communication to the LAN1154, which can also include a wireless access point (AP) disposed thereon for communicating with the adapter1158in a wireless mode.

When used in a WAN networking environment, the computer1102can include a modem1160or can be connected to a communications server on the WAN1156via other means for establishing communications over the WAN1156, such as by way of the Internet. The modem1160, which can be internal or external and a wired or wireless device, can be connected to the system bus1108via the input device interface1144. In a networked environment, program modules depicted relative to the computer1102or portions thereof, can be stored in the remote memory/storage device1152. It will be appreciated that the network connections shown are examples, and other means of establishing a communications link between the computers can be used.

When used in either a LAN or WAN networking environment, the computer1102can access cloud storage systems or other network-based storage systems in addition to, or in place of, external storage devices1116as described above. Generally, a connection between the computer1102and a cloud storage system can be established over a LAN1154or WAN1156e.g., by the adapter1158or modem1160, respectively. Upon connecting the computer1102to an associated cloud storage system, the external storage interface1126can, with the aid of the adapter1158and/or modem1160, manage storage provided by the cloud storage system as it would other types of external storage. For instance, the external storage interface1126can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer1102.

CONCLUSION

In the subject specification, terms such as “datastore,” data storage,” “database,” “cache,” and substantially any other information storage component relevant to operation and functionality of a component, refer to “memory components,” or entities embodied in a “memory” or components comprising the memory. It will be appreciated that the memory components, or computer-readable storage media, described herein can be either volatile memory or nonvolatile storage, or can include both volatile and nonvolatile storage. By way of illustration, and not limitation, nonvolatile storage can include ROM, programmable ROM (PROM), EPROM, EEPROM, or flash memory. Volatile memory can include RAM, which acts as external cache memory. By way of illustration and not limitation, RAM can be available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). Additionally, the disclosed memory components of systems or methods herein are intended to comprise, without being limited to comprising, these and any other suitable types of memory.