Related Applications

[0001] This application claims the benefit of United States Provisional Patent Application No. 62/402,056, filed September 30, 2016, which is hereby incorporated by reference herein in its entirety.

Technical Field

[0002] The present disclosure relates to handling radio link monitoring and radio link failure. In particular, the present disclosure relates to handling radio link monitoring and/or radio link failure when using a high frequency beam (e.g., line of sight (LOS) beam).

Background

[0003] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless mobile device. Wireless communication system standards and protocols can include the 3rd Generation Partnership Project (3GPP) long term evolution (LTE); 3GPP fifth generation (5G) New Radio (NR); the Institute of Electrical and Electronics

Engineers (IEEE) 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access (WiMAX); and the IEEE 802.1 1 standard for wireless local area networks (WLAN), which is commonly known to industry groups as Wi-Fi. In 3GPP radio access networks (RANs) in LTE systems, the base station can include a RAN Node such as a Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) and/or Radio Network Controller (RNC) in an E-UTRAN, which communicate with a wireless communication device, known as user equipment (UE). In 5G wireless RANs (e.g., 5G NR), RAN Nodes can include a 5G Node such as a Next Generation Node B (also commonly denoted as G Node B or gNB). [0004] RANs use a radio access technology (RAT) to communicate between the RAN Node and UE. RANs can include global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and/or E-UTRAN, which provide access to communication services through a core network. Each of the RANs operates according to a specific 3GPP RAT. For example, the GERAN 104 implements GSM and/or EDGE RAT, the UTRAN 106 implements universal mobile telecommunication system (UMTS) RAT or other 3GPP RAT, and the E-UTRAN 108 implements LTE RAT.

[0005] A core network can be connected to the UE through the RAN Node. In LTE, the evolved packet core (EPC) network can include a serving gateway (SGW), a packet data network (PDN) gateway (PGW), an access network detection and selection function (ANDSF) server, an enhanced packet data gateway (ePDG) and/or a mobility management entity (MME). In 5G, a next generation core topology may be used. The 5G core may be designed to support different RATs, such as both LTE and 5G NR. 5G NR may leverage higher frequencies to provide increased bandwidth and/or lower latency connections. In addition, 5G NR may leverage beamforming to provide increased bandwidth and/or lower latency. It is appreciated that beamforming is a technology for combating high frequency radio characteristics.

Brief Description of the Drawings

[0006] FIG. 1 is an example of an environment in which the present systems and methods may be implemented in accordance with some embodiments.

[0007] FIG. 2 illustrates a simulation result that shows the relative received power of a transmission in terms of decibels (dB) with respect to time in terms of seconds (s or sec) when blocked by a moving vehicle.

[0008] FIG. 3 is a simulation result of transmission control protocol (TCP) performance with different blockage durations.

[0009] FIG. 4 is a simulation result that shows a probabilistic packet dropping model for the 0.7 sec and 1 .8 sec blockages.

[0010] FIG. 5 is a block diagram that illustrates inter-layer inter-actions and the corresponding UE procedures for RLM and RLF handling.

[0011] FIG. 6 shows a scenario of possible outcomes for when a 1800 ms (e.g., a 1 .8 sec) blockage happens. [0012] FIG. 7 is a block diagram that illustrates inter-layer inter-actions and the corresponding UE procedures for RLM and RLF handling when a blockage (e.g., beam-level problem) is assumed and NR RLM (e.g., beam-change or reselection of other suitable beam) and RLF is handled in L1 without L3 involvement (transparent from L3 (RRC), for example).

[0013] FIG. 8 is a block diagram that illustrates inter-layer inter-actions and the corresponding UE procedures for RLM and RLF handling when a blockage (e.g., beam-level problem) is assumed and NR RLM (e.g., beam-change or reselection of other suitable beam) and RLF is handled in L1 with L3 involvement.

[0014] FIG. 9 is a flow diagram of a method for wireless communication.

[0015] FIG. 10 illustrates an architecture of a system of a network in accordance with some embodiments.

[0016] FIG. 1 1 illustrates example components of a device in accordance with some embodiments.

[0017] FIG. 12 illustrates example interfaces of baseband circuitry in accordance with some embodiments.

[0018] FIG. 13 is an illustration of a control plane protocol stack in accordance with some embodiments.

[0019] FIG. 14 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Detailed Description of Preferred Embodiments

[0020] A detailed description of systems and methods consistent with

embodiments of the present disclosure is provided below. While several

embodiments are described, it should be understood that the disclosure is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed herein, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the disclosure. [0021] Beamformed beams (such as high frequency beams, for example) may be directional. As a result, beamformed beams may be susceptible to obstructions within the directional path of the beam (this directional beam/path is often referred to as a line of sight (LOS) beam/path). Examples of obstructions include buildings, vehicles, and human movements. It is appreciated that an obstruction to a LOS beam may significantly degrade the signal strength of the beam.

[0022] Techniques, apparatus, and methods are disclosed that enable new radio link monitoring (RLM) and new radio link failure (RLF) detection in beam-based communication. The new RLM and new RLF detection take into consideration beam level problems and/or beam blockage problems. In some embodiments, the techniques, apparatus, and methods introduce a blockage detection indicator. If the RAN node (e.g., eNB, gNB) detects the blockage, the network can send the detection indicator to the UE via radio resource control (RRC) signaling. If the UE detects the blockage in the physical layer, the blockage indication can be sent from the physical layer to a higher layer.

[0023] In some embodiments, an apparatus is described. The apparatus includes a memory (or a memory interface for accessing a memory) and one or more baseband processors. The memory stores a beam level failure timer. The one or more baseband processors are to determine, at a physical layer, a beam level problem with a beam with a serving cell; initiate the beam level failure timer upon detection of the beam level problem; determine, at the physical layer, a beam level failure if the beam level problem remains when the beam level failure timer expires; determine, at the physical layer, a status of a radio link with the serving cell; and provide, from the physical layer, information to an upper layer, the information including an indication of the beam level failure and/or an indication of the status of the radio link.

[0024] In some embodiments, a computer-readable medium having instructions stored thereon is described. The instructions, when executed by a computing device, cause the computing device to determine a blockage of a high frequency beam link with a radio access network (RAN) node based on a blockage detection algorithm, start a blockage timer with a blockage timer value upon detection of the blockage, determine if the high frequency beam link is recovered before the blockage timer expires, and provide an out-of-sync indication to a higher layer upon expiration of the blockage timer. [0025] In some embodiments, an apparatus for a first device is also described. The apparatus includes circuitry to measure a channel quality of a link with a second device and one or more processors. The one or more processors are to determine, at layer 1 (L1 ), a blockage of a high frequency beam based at least in part on a channel quality measurement of the high frequency beam; perform, at L1 , radio link monitoring (RLM) on the high frequency beam; determine if there is a disparate beam with a channel quality measurement that satisfies a threshold; and provide an out-of-sync indication to layer 3 (L3), when there is not a disparate beam with a channel quality measurement that satisfies the threshold.

[0026] It is noted that RAN #71 approved a study of the technical framework and architecture of 5G new RAT (NR) systems to support eMMB, mMTC, and URLLC, etc., considering frequency ranges up to 100 GHz for the increased bandwidths (BWs) and high data rate support to support up to 10+ gigabits per second (Gbps). For such NR systems, it is well understood that beamforming is a technology for combatting high frequency radio characteristics. As being directional, the

beamforming of high frequency radio signals is prone to obstructions (blockage) of the line of sight (LOS) path of the radio signals. Examples of obstructions include buildings, vehicles, and human movements. Obstructions may block or significantly degrade the ability of the radio signals to continue in the LOS path and hence may significantly degrade the signal strength of the radio signals at a receiver.

[0027] Turning now to the figures, FIG. 1 is an example of an environment 100 in which the present systems and methods may be implemented. The environment 100 includes a portion of a radio access network (RAN) system that includes an air interface (a network interface such as a millimeter wave (mmWave) based interface or a wireless local area network (WLAN) based interface) being provided between a gNB 106 and a UE 102 (i.e., on Access Link A 1 14) and an (optional) cellular air interface (such as an LTE/LTE-Advanced access link) being provided between an anchor 104 and the UE 102 (i.e., on Access Link B 1 12), and the UE 102. The UE 102 is located within macro cell coverage 108 and the 5G small cell coverage area 1 10. Access Link A 1 14 may be provided via a directional beam (e.g., a line of sight (LOS) beam) that is formed using beamforming techniques. Accordingly, Access Link A 1 14 (e.g., the directional beam) may be prone to obstructions (e.g., vehicle 1 18, human, object, etc.) that may obstruct the directional beam (e.g., Access Link A 1 14). For example, a vehicle 1 18, traveling on a path 120 may obstruct (e.g., cause a blockage of) Access Link A 1 14 as the vehicle 1 18 passes between the gNB 106 and the UE 102 (at point 122, for example).

[0028] The UE 102 and/or the gNB 106 may perform the new radio link

monitoring (RLM) and new radio link failure (RLF) detection as discussed herein. For example, if the gNB 106 detects the blockage (e.g., obstruction), the network can send the detection indicator to the UE via radio resource control (RRC) signaling (using Access Link B 1 12, for example). Additionally or alternatively, if the UE 102 detects the blockage in the physical layer, the blockage indication can be sent from the physical layer to a higher layer.

[0029] In some embodiments Access Link A 1 14 and Access Link B 1 12 use a same frequency and technology. In other embodiments, Access Link A 1 14 and Access Link B 1 12 use different frequencies (e.g., LTE licensed frequencies and unlicensed frequencies) and different link technology (e.g., LTE, LTE over mmWave, and Wi-Fi).

[0030] The blockage behavior of a vehicle obstructing a directional beam (e.g., Access Link A 1 14) is modeled in FIGs. 2-5. It is appreciated that this model assumes that the distance between the blocker (e.g. , the vehicle 1 18) and

transmitter (e.g., the UE 102, in this case) is much farther away than the distance between the blocker and receiver (e.g., the gNB 106, in this case), which seems reasonable to certain NR deployment scenarios. For this model, the following parameters are used. The blocker is a vehicle (e.g., vehicle 1 18) of width = 4.8 meters (m) and height = 1 .4 m. The blocker polar coordinates are AoA span = 0.48 radians (rad), ZoA span = 0.14 rad, and distance to the receiver = 10 m. The carrier frequency is 28 gigahertz (GHz). The number of transmit (TX) antennas is eight (8) with half power beam width = 12.4045 degrees (°). The number of receive (RX) antennas is four (4) with half power beam width = 24.8091 °.

[0031] FIG. 2 illustrates a simulation result 200 that shows the relative received power of a transmission in terms of decibels (dB) with respect to time in terms of seconds (s or sec) when blocked by a moving vehicle (e.g. , vehicle 1 18), at the speed of 15 kilometers per hour (km/h) (e.g., ramp-down 202 and ramp-up 204), 30 km/h (e.g., ramp-down 206 and ramp-up 208), 60 km/h (e.g., ramp-down 210 and ramp-up 212), and 120 km/h (e.g., ramp-down 214 and ramp-up 216). The trace in FIG. 2 was sampled at every 0.2 ms, which is the subframe duration that is currently being considered for NR. [0032] It is appreciated that in this model there is roughly ~35 dB of signal strength degradation by the blocker. It is appreciated, however, that the amount of signal strength degradation may significantly differ based on the distance between the transmitter and receiver, the carrier frequency, the number of antennas, the size of the blocker, etc. Needless to say, the length of the blockage differs by the vehicular speed, such that the slower speed results in the longer blockage experience. It is noted that each blockage consists of a ramp-down, a deep blockage, and a ramp-up (going back to normal) period, with sharp transitions between the periods. The ramping times (in the beginning and end of the blockage) and the duration of the deep blockage are proportional to the entire blockage experienced, here each taking roughly half of the entire duration. For example, the 15 km/h speed results in the ramp-down 202 of 0.575 sec, the deep blockage of 1 .153 sec, and the ramp-up 204 of 0.566 sec.

[0033] In addition to the impact of a blockage on signal strength (as shown in FIG. 2), a blockage also impacts transmission control protocol (TCP) performance. Long service interruption may impact the user throughput, even to that of non-real time application. This is illustrated in an end-to-end simulation that evaluates the blockage impacts on the TCP protocol, which may be used by error-sensitive and delay-tolerant applications.

[0034] FIG. 3 is a simulation result of TCP performance 300 with different blockage durations. The TCP performance 300 is measured in terms of traffic received (bits/sec) with respect to time (sec). For this simulation, it is assumed that the NR data rate is 10 Gbps with the subframe duration of 0.2 ms.

[0035] In this simulation, a file transfer protocol (FTP) file of 300 megabytes (MB) is downloaded from a FTP server. The transfer starts at 100.0 sec and the blockage starts 302 at 100.2 sec. To simplify the analysis, this simulation considers a blockage of 10 ms, 200 ms, 0.7 sec, and 1 .8 sec, where the ramp-up and ramp- down time of the 0.7 sec and 1 .8 sec blockages is set by 200 ms. The simulation also assumes that before or after the blockage, the UE uses the highest downlink (DL) modulation and coding scheme (MCS) index to achieve the 10 Gbps, but during the deep blockage period, all the packets are completely dropped.

[0036] FIG. 4 is a simulation result that shows a probabilistic packet dropping model for the 0.7 sec and 1 .8 sec blockages. It is noted that the MCS index of -2 means that the packet is dropped at that time instant. [0037] To model the dynamic packet dropping during ramping times, this simulation considers a probabilistic way where the drop probability is inversely proportional to the relative power, with the proportionally adjusted MCS indices during the ramp-down (402 and 406) and ramp-up (404 and 408) periods. It is noted that the time scales are different between the blockage MCS model of 0.7 sec and the blockage MCS model of 1 .8 sec.

[0038] FIG. 3 shows that the throughput reaches up to 10 Gbps quickly due to the slow-start with auto-tuning before 100.2 sec. Once the blockage is started 302, the rate decreases significantly (to zero for 0.7 sec and 1 .8 sec blockages) due to the packet drops by the above model (as shown in FIG. 4, for example). The

fluctuations during ramping times are due to the radio link control (RLC)

acknowledged mode (AM) retransmissions. In this simulation, traditional RLF during the deep blockage was not considered, but as a reference, the maximum RLC retransmission 304 (four (4) RLC retransmissions, for example) is reached at 100.4555 sec for the 0.7 sec blockage.

[0039] It is noted that the DL TCP throughput of 10 Gbps is well resumed for the blockage duration of 10 ms, 200 ms, and 0.7 sec. However, for the blockage duration of 1 .8 sec, the DL TCP throughput does not resume to 10 Gbps, but ramps up slowly due to TCP retransmission timeout (RTO) and TCP congestion control 306, which prolongs the file transfer time. So a short blockage duration does not impact TCP performance when the network resumes to full speed, while a long blockage duration impacts TCP performance because RTO and congestion control cause the throughput to not be able to resume to full speed (10 Gbps).

[0040] Accordingly, techniques are needed for handling and appropriately recovering from blockage situations. In some embodiments, the present systems and methods introduce a blockage indication to the UE in a higher layer so that the UE can perform related actions (such as deferring RLF, etc.).

[0041] It is appreciated that in 3GPP LTE systems, radio link monitoring (RLM), radio link failure (RLF) detection, and radio link re-establishment procedure are defined in 3GPP TS 36.133 Έ-UTRA Requirements for support of radio resource management" and TS 36.331 Έ-UTRA RRC Protocol Specification." An example of inter-layer interactions for handling RLM and RLF is shown in FIG. 5.

[0042] FIG. 5 is a block diagram 500 that illustrates inter-layer inter-actions and the corresponding UE procedures for RLM and RLF handling. L1 (e.g., physical (PHY)) layer 502 periodically sends an in-sync (IS) indication 506 or an out-of-sync (OOS) indication 508 to L3 (e.g., RRC) layer 504. In-sync or out-of-sync is determined based on cell specific reference (CRS) channel quality and the associated hypothetical physical downlink control channel (PDCCH) block error ratio (BLER). If the L3 layer 504 receives N310 consecutive out-of-sync indications 510, timer T310 starts running to wait for RL recovery (i.e., N31 1 consecutive in-sync indications are received). If T310 expires 512, timer T31 1 starts to attempt RRC connection re-establishment. If T31 1 expires 514, the UE enters into idle state 516. For more detailed information, see 3GPP TS36.133 for RLM and TS36.331 for RLF detection and radio link re-establishment.

[0043] Narrow-beam (e.g., directional beam) operation may be used in 3GPP 5G systems (also called New Radio (NR)), especially in high frequency bands. Then the issue is how to do RLM and how to detect and handle RLF in beam-based communication in NR systems. Another issue with narrow-beam operation is how to differentiate beam-level problems, beam-blockage problems, radio link problems, and radio link failures, and how to handle each case.

[0044] The present systems and methods introduce a blockage detection indicator (or blockage indicator). If the RAN node (e.g., eNB, gNB) detects a blockage, the network (e.g., E-UTRAN) can send a blockage detection indicator to the UE via RRC signaling. Additionally or alternatively, if the UE detects a blockage at the physical layer, a blockage detection indication can be sent from the physical layer to a higher layer (e.g., L3, RRC layer). Additionally, the present systems and methods introduce new RLM and RLF detection and handling in beam-based communication with consideration of beam-level problem or blockage problem.

[0045] It is assumed that both the UE and the transmission reception point (TRP) (e.g., RAN node, gNB, eNB, etc.) uses beamforming for communication. When a blockage happens, it is possible that a wide beam can be used to recover the blockage. Examples of a wide beam include a reference signal transmitted using a wide beam (e.g., as cell-specific reference signal (CRS) in LTE) and a set of reference signals transmitted using multiple narrow beams covering a wide angular area (i.e., beam sweeping). When a wide beam is available, there are three possible scenarios, which are illustrated in Table 1 below.

Table 1

[0046] In some embodiments, a TRP sends a blockage indication to the UE when a good quality of a wide beam and a bad quality of a narrow beam are detected. It is noted that currently there is no agreement as to what physical signal(s) will be used for performing radio link monitoring and blockage. Therefore, this description does not focus on the signaling design but rather the detection indication for different cases.

[0047] In some embodiments, a blockage indication is sent to the UE when a blockage is detected by some blockage detection algorithms. The detection can be based on acknowledgement/negative acknowledgement (ACK/NACK) at the eNB. Alternatively, the blockage can be detected (i.e., blockage detection) via diversity beams/links at the UE or the eNB. Regardless of the detection methods, once a blockage is detected, it is sent to the UE higher layer (e.g., RRC layer). If the detection is at the UE, it can be a physical layer detection or a blockage detection via diversity beams. If the detection is performed at the eNB, the detection can be based on ACK/NACK. [0048] In some embodiments, an eNB detects a blockage and signals (e.g., sends, provides) a blockage indication to the UE (from the eNB to the UE, for example). If the detection is performed at the eNB, the eNB can send a blockage indication to the UE via RRC signaling. Below is one of the examples of an information element (IE) that may be used for such signaling.

[0049] In some embodiments, a UE detects a blockage and signals (e.g., sends, provides) a blockage indication to the eNB (from the UE to the eNB, for example). If the detection is performed at the UE, the UE can report this to the network to perform recovery. This report can be sent via PUCCH or RRC. If it is sent via RRC, an exemplary IE can be included in the RLF-cause, as shown below. rlf-Cause-NR ENUMERATED {

t310-Expiry, randomAccessProblem, rlc-MaxNumRetx, t312-Expiry-r12,

[0050] Alternatively, it can be a separate blockage IE including the cause of the blockage and measurement result, as shown below. blockageReporting SEQUENCE {

blockage-Cause ENUMERATED {

narrowBeamLinkProblem, wideBeamLinkProblem,

sparel , spare2},

measResultListNR MeasResultListNR

},

[0051] In some embodiments, a blockage may be detected by the UE at the PHY layer and the UE provides (e.g., signals, provides, sends) a blockage indication from the PHY layer to a higher layer. If the detection is performed at the UE in the PHY layer, it will be useful for the higher layer to know so that the UE can decide to perform any of the following actions. If the RLF timer is running and a blockage is detected, the UE may suspend the RLF timer or not to declare RLF so that there is enough time for recovery (from the blockage). If the RLF timer is running and a blockage is not detected, the UE may declare RLF and re-establish a connection. In this way, the UE may be able to recover faster through re-establishment procedure (when the RLF is not caused by a blockage, for example). If a blockage is detected and a physical layer recovery fails, it would be good to avoid the TCP impact due to the long blockage, and fall back (to LTE, for example) is a good solution when the 5G link is not available.

[0052] FIG. 6 shows a scenario of possible outcomes 600 for when a 1800 ms (e.g., a 1.8 sec) blockage happens. The possible outcomes in FIG. 6 are that the UE fallbacks 602 to the slower LTE link (a LTE 37 Mbps link, for example) and then switches back 604 (e.g., switchback) to the NR link when the blockage ends or performs no fallback/switchback (as also shown in FIG. 3, for example). In FIG. 6, ideal blockage detection is assumed where the blockage starts and is detected at 100.2 sec. The NR link is resumed at 101 .8 sec. As shown, fallback allows the file to be completely downloaded at 102.1 sec, while if no fallback TCP performance is impacted and may not ramp back up to the 5G speed such that the file is not completely downloaded until after 102.8 sec. It is noted that in the case of the fallback and switchback, the LTE link is carrying traffic at the 3.657e ⁺⁰⁷ bits/sec (or 36.57 Mbps) as shown during the blockage.

[0053] In view of the foregoing, this disclosure introduces a blockage timer to allow the UE to wait for 5G recovery before TCP performance is impacted.

However, in certain embodiments, the UE should fallback to LTE when the blockage timer expires to avoid TCP performance degradation (due to RTO and congestion control, as described). This timer is configurable by the network. With reference to FIG. 6, the fallback 602 to the slower LTE can be triggered either upon detection of the blockage (as shown in FIG. 6) or upon expiration of a blockage timer (which is started upon detection of the blockage, for example).

[0054] In some embodiments, a default blockage timer value can be configured by the network and broadcasted (via a system information block (SIB), for example) to notify any UE within a NR cell to know when (e.g., the default blockage timer value) to fall back to LTE. In one example, the network sends the default blockage timer information via a SIB. When the UE detects blockage, the UE starts the blockage timer with a timer value (a default blockage timer value included in the default blockage timer information, for example). If the 5G link is recovered before the blockage timer expires, the UE stops the blockage timer. If, however, the blockage timer expires before the 5G link is recovered (i.e., the 5G link is still blocked), the UE performs path switching (e.g., to LTE or to a master eNB (MeNB) if the blockage happens with a secondary eNB (SeNB)).

[0055] It is noted that the network can configure different default blockage timer values inside a SIB based on the UE capability and/or based on blockage event criteria (if a blockage is detected similar to the event-triggered measurement procedures, for example) and/or based on the received reference signal received power/reference signal received quality (RSRP/RSRQ) values when detecting blockage and/or based on the UE's speed, etc. In some embodiments, the network may calibrate the blockage timer (default) values based on the measured statistics of each NR cell for further optimization.

[0056] In some embodiments, a dedicated blockage timer value can be

configured by the network and sent to a UE via RRC signaling (so that the network can determine/control when that UE may fall back to LTE, for example). In these embodiments, when a UE detects a blockage, the UE reports the blockage (via a blockage indication, for example) to the network via a MeNB if it is in a standalone case. Otherwise, the UE may not be able to report the blockage to the network (if the only connection with the network is now blocked, for example). In response to the blockage report, the network may send a dedicated blockage timer value to the UE (via RRC signaling, for example). It is appreciated that if the UE cannot report the blockage or if the network does not provide a dedicated blockage timer value, the UE may default to a default blockage timer value (provided as discussed above, for example) or a predefined blockage timer value (set at the time of manufacture, for example). The UE starts a blockage timer using the obtained blockage timer value (based on the network configured dedicated blockage timer value, for example). As discussed above, if the 5G link is recovered before the blockage timer expires, the UE stops the blockage timer. If, however, the timer expires before the 5G link is recovered (the 5G link still blocked, for example), the UE performs path switching to a different path (to LTE or to a MeNB if the blockage happens with a SeNB, for example).

[0057] It is noted that the difference between the above embodiments with the default blockage timer value and the above embodiments with the dedicated blockage timer value is that the embodiments with the dedicated blockage timer value allow the network to determine the blockage timer value after the UE reports a detected blockage to the network. [0058] In some embodiments, the network can send a path switching command (after preparation) instead of the blockage timer information, if the network decides to fall back to LTE like a handoff (HO). Alternatively, the path switching command may be sent in addition to (in the same message as, for example) the blockage timer information. Thus, the network can optionally send some path switching information to the UE in case that the UE performs path switching after the configured blockage timer expired.

[0059] In some embodiments, the UE can optionally send assist information (or assistance information) to the network to help the network determine the blockage timer duration. The assistance information may include a blockage ramp time successful rate and/or the amount of data that has been received during the ramp time (from the time that the signal strengths dropped to the time that the UE detected blockage, for example).

[0060] In addition to the usage of a blockage timer, as discussed above, the present systems and methods also propose various considerations and possible options for NR RLM and RLF detection and handling (including blockage or beam- level problem detection and handling). It is appreciated that the considerations and possible options for NR RLM and RLF detection and handling may be used in connection with any of the foregoing embodiments or may be used without any of the foregoing embodiments.

[0061] It is appreciated that a 3GPP 5G system (we also call NR: New Radio) may have some new aspects to be considered in RLM and RLF detection and RLF handling. In basic, the following high-level operations may still be valid in NR RLM and RLF handling. These operations are that RLM is done in L1 , and L1 informs L3 of the result of RLM, that L3 runs timer T1 (e.g., T310) to wait for radio link (RL) recovery upon RL problem detection, that L3 runs timer T2 (e.g., T31 1 ) to attempt connection re-establishment when RL is not recovered during T1 , and that L3 enters idle if connection re-establishment fails during T2. The present systems and methods propose the following new aspects to be considered in NR RLM and RLF handling.

[0062] In certain embodiments, NR communication will use narrow beam(s) (e.g., for high frequency band communication). In these cases, it is not clear how to determine out-of-sync and in-sync in L1 . For example, the out-of-sync determination and the in-sync determination may or may not be based on non-UE specific reference signals (e.g., CRS) or UE-specific/beam-specific reference signals. With narrow-beam operation in NR, unlike the existing LTE system, the RLM may be based on UE-specific/beam-specific reference signals, which are also transmitted via narrow beam. Another alternative may be to use a kind of shared reference, which is periodically transmitted via the beam regardless of whether actual data is transmitted or not. It is noted that a demodulation reference signal (DMRS) is a kind of UE-specific reference signal and it can also be transmitted via the beam (e.g., narrow beam). However, in certain embodiments, it is only sent when the actual data channel is transmitted, which means that if there is no data transmission, there will be no DMRS transmitted, so the UE cannot perform a channel quality

measurement in that case. In certain NR embodiments, periodical out-of-sync and in-sync indication(s) from L1 may be used or the indications may be event driven. For example, a newly defined event-driven indication from L1 may be used. In these cases, L1 indicates when a radio link problem is detected or when an actual radio link failure is declared in L1 . With the event-driven indication, the previously used numbers such as N310 and N31 1 may not be needed.

[0063] In addition, or in other embodiments, L3 may or may not be aware of blockage or beam-level problem in addition to RLF (in the case of narrow-beam operation in NR communication, for example). It is noted that a blockage or a beam- level problem does not necessarily mean that the UE cannot communicate with the network. For example, the UE could still communicate with the network by another suitable beam if there is any. With this in mind, it may be beneficial to provide a clear definition on RLF to avoid the confusion between blockage (a beam-level problem, for example) and RLF. For example, RLF could be defined so that RLF would (only) be declared when the UE cannot communicate with the network by any means. In other words, RLF is not restricted to the current beam. This means that RLF may be defined in certain embodiments so that it only occurs when the UE cannot find any suitable beam to communication with the NR Node B (NB) and/or any other RAN node (e.g., eNB).

[0064] If blockage (a beam-level problem, for example) detection and beam- management (e.g., reselection of another suitable beam) is purely handled in L1 (Layerl ), then the RRC (e.g., L3) may not need to be aware of it. Otherwise, L3 (e.g., Layer3, RRC protocol layer) may be aware of blockage or a beam-level problem in addition to RLF. Depending on which of these assumptions is made, it is appreciated that different blockage or beam-level problem detection and handling operations may be assumed. Two possible alternatives are provided below.

[0065] In a first alternative, the case where blockage (or beam-level problem) detection and beam-management rely on L1 (without involvement from L3, for example), L1 performs RLM on the selected beam. This means that L1 can switch from beam#1 to beam#2 without RRC involvement (so that once beam#2 is reselected, Qin/Qout will be based on beam#2, for example). In this first alternative, upon problem detection (here it means RL problem) (and blockage indication reporting to L3, for example), L3 waits for RL recovery (during timer T1 , for example). This allows L1 to perform RLM on the selected beam (e.g., any suitable beam) and perform RL recovery before intervention from L3.

[0066] In a second alternative, the case where blockage (or beam-level problem) detection and beam-management involves L3, L1 performs RLM only on the current beam. This means that L1 cannot switch from beam#1 to beam#2 unless RRC indicates that it should make the path switch (so that before the reception of an RRC indication, Qin/Qout will only be based on the (current) beam#1 , for example). In this second alternative, upon problem detection (here it means current beam problem) (and blockage indication reporting to RRC (e.g., L3), so RRC will indicate that L1 is to do beam-switching, for example), L3 triggers L1 to reselect a beam (during timer T1 , for example).

[0067] FIG. 7 is a block diagram 700 that illustrates inter-layer inter-actions and the corresponding UE procedures for RLM and RLF handling when a blockage (e.g., beam-level problem) is assumed and NR RLM (e.g., beam-change or reselection of other suitable beam) and RLF are handled in L1 without L3 involvement (transparent from L3 (RRC), for example).

[0068] L1 (e.g., physical (PHY)) layer 502 periodically sends an in-sync indication 506 or an out-of-sync indication 508 to the L3 (e.g., RRC) layer 504. L1 performs RLM on the selected beam. Here for example, L1 can switch from beam#1 to beam#2 in L1 without L3 involvement. In the case that the current selected beam is beam#1 , RLM is based on beam#1 quality and if it is reselected to beam#2 in L1 , then once it is changed, RLM is based on beam#2. If there is no suitable beam selected in L1 during the period, L1 will indicate an out-of-sync indication (e.g., out- of-sync indication 508) to L3. RLM may be done based on the channel quality of a UE specific reference signal or shared reference signal that is also transmitted via the beam by the eNB. Out-of-sync and in-sync indications may be generated as follows.

[0069] In a first embodiment, L1 performs RLM on the selected beam in L1 and in-sync indication/out-of-sync indication 506/508 will be generated based on the channel quality of beam#1 . If, for example, L1 can switch from beam#1 to beam#2 without RRC involvement, then before switching to beam#2, in-sync indication/out- of-sync indication 506/508 will be generated based on the channel quality of beam#1 , and after switching to beam#2, in-sync/out-of-sync indication 506/508 will be generated based on the channel quality of beam#2.

[0070] In a second embodiment, out-of-sync indication 508 is generated if L1 cannot find any suitable beam meeting the minimum channel quality and in-sync indication 506 is generated if L1 can find any suitable beam meeting the minimum channel quality requirements. While FIG. 7 indicates periodic indications, it is appreciated that the embodiments described herein could alternatively be used in the context of event-driven indications, as discussed previously.

[0071] With the reception of N310 out-of-sync indications 510, the L3 procedures follow the above high-level steps as discussed with respect to FIG. 5. It is

appreciated that in FIG. 7 the blockage (or beam-level problem) detection and/or handling (e.g., reselection of beam) is handled in L1 transparently (without involvement, for example) from L3 (e.g., RRC).

[0072] FIG. 8 is a block diagram 800 that illustrates inter-layer inter-actions and the corresponding UE procedures for RLM and RLF handling when a blockage (e.g., beam-level problem) is assumed and NR RLM (e.g., beam-change or reselection of other suitable beam) and RLF is handled in L1 with L3 involvement. As discussed previously, L1 (e.g., physical (PHY)) layer 502 periodically sends an in-sync indication 506 or an out-of-sync indication 508 to the L3 (e.g., RRC) layer 504 (it is appreciated that an event-driven approach could additionally or alternatively be used, for example). Although not specifically shown in FIG. 8, it is assumed that separate in-sync indications 506 and separate out-of-sync indications 508 are used for radio link (including all beams, for example) and for blockage (of the current beam, for example). These separate in-sync indications 506 and separate out-of- sync indications 508 are generated and informed (i.e., from L1 502) to L3 504 as follows. [0073] A first in-sync indication 506A and a first out-of-sync indication 508A is used for the whole radio link level (which means including all beams, for example) (e.g., indications for radio link), while a second in-sync indication 506B and a second out-of-sync indication 508B is used for the current beam level (or on/off indication for blockage problem) (e.g., indications for blockage). Since indications (e.g., the first and second set of in-sync and out-of-sync indications 506/508) are generated in separate, RLM may also be performed/done in separate. In some embodiments, RLM may be done based on the channel quality of a UE specific reference signal (e.g., DMRS) that is transmitted via a beam or a shared reference signal that is also transmitted via the beam (by the eNB, for example). In FIG. 8, it is assumed that N310/T310 510/512 is used for radio link level (radio link indication as described above, in connection with indications 506A/508A) and that a separate Nxxx 810 and Txxx 812 are used for beam level (or blockage indication, in connection with indications 506B/508B).

[0074] In some embodiments (e.g., Case 3 806 and Case 4 808), when L3 504 receives N310 consecutive out-of-sync indications for radio link level 510 from L1 502, L3 504 starts T310 512 to find out any suitable beam (waiting for an in-sync indication 506A from L1 502, for example), but if L3 504 fails to find out (an in-sync indication 506A is not received, for example) during T310 512 and if T310 512 expires, L3 504 declares RLF and T31 1 is started.

[0075] In some embodiments (e.g., Case 1 802 and Case 2 804), when L3 504 receives Nxxx consecutive out-of-sync indications for beam-level (or blockage indication) 810 from L1 502, L3 504 starts Txxx 812 to wait for the current beam to recover (waiting for an in-sync indication 506B from L1 502, for example), but if it fails to recover (an in-sync indication 506B is not received, for example) during Txxx 812 and if Txxx 812 expires, L3 504 indicates (not shown) L1 502 to do beam-switch or reselection to another suitable beam and T310 512 is started. Alternatively, each case may be divided as shown and the UE may have different behavior on a case- by-case basis as shown (e.g., Cases 1 -4 802, 804, 806, 806). It is noted that in the FIGs. (e.g., FIGs. 5, 7, and 8) the dashed arrow is an in-sync indication 506 and the solid arrow is an out-of-sync indication 508.

[0076] In some embodiments, NR RLM and RLF handling involves L1 502 directly informing RLF (via a direct RLF indication, for example) to L3 504. This is similar to the event-driven indication for RLM (as discussed previously). In these embodiments, L1 502 handles RLF declaration (RLF declaration to L3 504, for example) in addition to RLM. When L3 504 receives an RLF indication from L1 502, L3 504 starts T31 1 to attempt RRC connection re-establishment. With this option, L3 504 may not need to count N310 and to start T310 in L3 504. L3 504, however, may need to indicate N310 and T310 to L1 502 in order to do RLF declaration in L1 502.

[0077] FIG. 9 is a flow diagram of a method 900 for wireless communication. The method 900 is performed by a device, such as a user equipment (UE) or the like. In particular, the method 900 may be performed by a processor (e.g., a baseband processor) within the device. Although the operations of the method 900 are illustrated as being performed in a particular order, it is understood that the operations of the method 900 may be reordered without departing from the scope of the method 900.

[0078] At 902, a beam level problem with a serving cell is determined (e.g., detected) at the physical layer. At 904, a beam level timer is initiated upon detection of the beam level problem. At 906, a beam level failure is determined at the physical layer if the beam level remains when the beam level timer expires. At 908, a status of a radio link with the serving cell is determined at the physical layer. At 910, information from the physical layer is provided to an upper layer. The information includes an indication of the beam level failure and/or an indication of the status of the radio link.

[0079] The operations of the method 900 may be performed by an application- specific processor, programmable application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like.

[0080] FIG. 10 illustrates an architecture of a system 1000 of a network in accordance with some embodiments. The system 1000 is shown to include a user equipment (UE) 1001 and a UE 1002. The UEs 1001 and 1002 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

[0081] In some embodiments, any of the UEs 1001 and 1002 can comprise an Internet of Things (loT) UE, which can comprise a network access layer designed for low-power ΙοΤ applications utilizing short-lived UE connections. An loT UE can utilize technologies such as machine-to-machine (M2M) or machine-type

communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to- device (D2D) communication, sensor networks, or loT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network describes interconnecting loT UEs, which may include uniquely identifiable

embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

[0082] The UEs 1001 and 1002 may be configured to connect, e.g.,

communicatively couple, with a radio access network (RAN) 1010. The RAN 1010 may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs 1001 and 1002 utilize connections 1003 and 1004, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 1003 and 1004 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.

[0083] In this embodiment, the UEs 1001 and 1002 may further directly exchange communication data via a ProSe interface 1005. The ProSe interface 1005 may alternatively be referred to as a sidelink interface comprising one or more logical channels, including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery

Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0084] The UE 1002 is shown to be configured to access an access point (AP) 1006 via connection 1007. The connection 1007 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.1 1 protocol, wherein the AP 1006 would comprise a wireless fidelity (WiFi®) router. In this example, the AP 1006 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).

[0085] The RAN 1010 can include one or more access nodes that enable the connections 1003 and 1004. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNBs), RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The RAN 1010 may include one or more RAN nodes for providing macrocells, e.g., macro RAN node 101 1 , and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low power (LP) RAN node 1012.

[0086] Any of the RAN nodes 101 1 and 1012 can terminate the air interface protocol and can be the first point of contact for the UEs 1001 and 1002. In some embodiments, any of the RAN nodes 101 1 and 1012 can fulfill various logical functions for the RAN 1010 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0087] In accordance with some embodiments, the UEs 1001 and 1002 can be configured to communicate using Orthogonal Frequency-Division Multiplexing

(OFDM) communication signals with each other or with any of the RAN nodes 101 1 and 1012 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an Orthogonal Frequency- Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0088] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 101 1 and 1012 to the UEs 1001 and 1002, while uplink transmissions can utilize similar techniques. The grid can be a time- frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0089] The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the UEs 1001 and 1002. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 1001 and 1002 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 1002 within a cell) may be performed at any of the RAN nodes 101 1 and 1012 based on channel quality information fed back from any of the UEs 1001 and 1002. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 1001 and 1002.

[0090] The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1 , 2, 4, or 8).

[0091] Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

[0092] The RAN 1010 is shown to be communicatively coupled to a core network (CN) 1020—via an S1 interface 1013. In embodiments, the CN 1020 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface 1013 is split into two parts: the S1 -U interface 1014, which carries traffic data between the RAN nodes 101 1 and 1012 and a serving gateway (S-GW) 1022, and an S1 -mobility

management entity (MME) interface 1015, which is a signaling interface between the RAN nodes 101 1 and 1012 and MMEs 1021 .

[0093] In this embodiment, the CN 1020 comprises the MMEs 1021 , the S-GW 1022, a Packet Data Network (PDN) Gateway (P-GW) 1023, and a home subscriber server (HSS) 1024. The MMEs 1021 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 1021 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 1024 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The CN 1020 may comprise one or several HSSs 1024, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 1024 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

[0094] The S-GW 1022 may terminate the S1 interface 1013 towards the RAN 1010, and routes data packets between the RAN 1010 and the CN 1020. In addition, the S-GW 1022 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

[0095] The P-GW 1023 may terminate an SGi interface toward a PDN. The P- GW 1023 may route data packets between the CN 1020 (e.g., an EPC network) and external networks such as a network including the application server 1030

(alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 1025. Generally, an application server 1030 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW 1023 is shown to be communicatively coupled to an application server 1030 via an IP communications interface 1025. The application server 1030 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 1001 and 1002 via the CN 1020.

[0096] The P-GW 1023 may further be a node for policy enforcement and charging data collection. A Policy and Charging Enforcement Function (PCRF) 1026 is the policy and charging control element of the CN 1020. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP- CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 1026 may be communicatively coupled to the application server 1030 via the P-GW 1023. The application server 1030 may signal the PCRF 1026 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 1026 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 1030.

[0097] FIG. 1 1 illustrates example components of a device 1 100 in accordance with some embodiments. In some embodiments, the device 1 100 may include application circuitry 1 102, baseband circuitry 1 104, Radio Frequency (RF) circuitry 1 106, front-end module (FEM) circuitry 1 108, one or more antennas 1 1 10, and power management circuitry (PMC) 1 1 12 coupled together at least as shown. The components of the illustrated device 1 100 may be included in a UE or a RAN node. In some embodiments, the device 1 100 may include fewer elements (e.g., a RAN node may not utilize application circuitry 1 102, and instead include a

processor/controller to process IP data received from an EPC). In some

embodiments, the device 1 100 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

[0098] The application circuitry 1 102 may include one or more application processors. For example, the application circuitry 1 102 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors

and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 1 100. In some embodiments, processors of application circuitry 1 102 may process IP data packets received from an EPC.

[0099] The baseband circuitry 1 104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1 104 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1 106 and to generate baseband signals for a transmit signal path of the RF circuitry 1 106. Baseband processing circuity 1 104 may interface with the application circuitry 1 102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1 106. For example, in some embodiments, the baseband circuitry 1 104 may include a third generation (3G) baseband processor 1 104A, a fourth generation (4G) baseband processor 1 104B, a fifth generation (5G) baseband processor 1 104C, or other baseband processor(s) 1 104D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 1 104 (e.g., one or more of baseband processors 1 104A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1 106. In other embodiments, some or all of the functionality of baseband processors 1 104A-D may be included in modules stored in the memory 1 104G and executed via a Central Processing Unit (CPU) 1 104E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments,

modulation/demodulation circuitry of the baseband circuitry 1 104 may include Fast- Fourier Transform (FFT), precoding, or constellation mapping/demapping

functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1 104 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

[0100] In some embodiments, the baseband circuitry 1 104 may include one or more audio digital signal processor(s) (DSP) 1 104F. The audio DSP(s) 1 104F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 1 104 and the application circuitry 1 102 may be implemented together such as, for example, on a system on a chip (SOC).

[0101] In some embodiments, the baseband circuitry 1 104 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1 104 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), or a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 1 104 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0102] RF circuitry 1 106 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1 106 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. The RF circuitry 1 106 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1 108 and provide baseband signals to the baseband circuitry 1 104. RF circuitry 1 106 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1 104 and provide RF output signals to the FEM circuitry 1 108 for transmission.

[0103] In some embodiments, the receive signal path of the RF circuitry 1 106 may include mixer circuitry 1 106A, amplifier circuitry 1 106B and filter circuitry 1 106C. In some embodiments, the transmit signal path of the RF circuitry 1 106 may include filter circuitry 1 106C and mixer circuitry 1 106A. RF circuitry 1 106 may also include synthesizer circuitry 1 106D for synthesizing a frequency for use by the mixer circuitry 1 106A of the receive signal path and the transmit signal path. In some

embodiments, the mixer circuitry 1 106A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1 108 based on the synthesized frequency provided by synthesizer circuitry 1 106D. The amplifier circuitry 1 106B may be configured to amplify the down-converted signals and the filter circuitry 1 106C may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1 104 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, the mixer circuitry 1 106A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0104] In some embodiments, the mixer circuitry 1 106A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1 106D to generate RF output signals for the FEM circuitry 1 108. The baseband signals may be provided by the baseband circuitry 1 104 and may be filtered by the filter circuitry 1 106C.

[0105] In some embodiments, the mixer circuitry 1 106A of the receive signal path and the mixer circuitry 1 106A of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 1 106A of the receive signal path and the mixer circuitry 1 106A of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1 106A of the receive signal path and the mixer circuitry 1 106A may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1 106A of the receive signal path and the mixer circuitry 1 106A of the transmit signal path may be configured for super-heterodyne operation.

[0106] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1 106 may include analog- to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1 104 may include a digital baseband interface to communicate with the RF circuitry 1 106.

[0107] In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0108] In some embodiments, the synthesizer circuitry 1 106D may be a

fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1 106D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0109] The synthesizer circuitry 1 106D may be configured to synthesize an output frequency for use by the mixer circuitry 1 106A of the RF circuitry 1 106 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1 106D may be a fractional N/N+1 synthesizer.

[0110] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1 104 or the application circuitry 1 102 (such as an applications processor) depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be

determined from a look-up table based on a channel indicated by the application circuitry 1 102.

[0111] Synthesizer circuitry 1 106D of the RF circuitry 1 106 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0112] In some embodiments, the synthesizer circuitry 1 106D may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 1 106 may include an IQ/polar converter.

[0113] FEM circuitry 1 108 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1 1 10, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1 106 for further processing. The FEM circuitry 1 108 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1 106 for transmission by one or more of the one or more antennas 1 1 10. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1 106, solely in the FEM circuitry 1 108, or in both the RF circuitry 1 106 and the FEM circuitry 1 108.

[0114] In some embodiments, the FEM circuitry 1 108 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 1 108 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 1 108 may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1 106). The transmit signal path of the FEM circuitry 1 108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by the RF circuitry 1 106), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1 1 10).

[0115] In some embodiments, the PMC 1 1 12 may manage power provided to the baseband circuitry 1 104. In particular, the PMC 1 1 12 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1 1 12 may often be included when the device 1 100 is capable of being powered by a battery, for example, when the device 1 100 is included in a UE. The PMC 1 1 12 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0116] FIG. 1 1 shows the PMC 1 1 12 coupled only with the baseband circuitry 1 104. However, in other embodiments, the PMC 1 1 12 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, the application circuitry 1 102, the RF circuitry 1 106, or the FEM circuitry 1 108.

[0117] In some embodiments, the PMC 1 1 12 may control, or otherwise be part of, various power saving mechanisms of the device 1 100. For example, if the device 1 100 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1 100 may power down for brief intervals of time and thus save power.

[0118] If there is no data traffic activity for an extended period of time, then the device 1 100 may transition off to an RRCJdle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1 100 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1 100 may not receive data in this state, and in order to receive data, it transitions back to an RRC_Connected state.

[0119] An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[0120] Processors of the application circuitry 1 102 and processors of the baseband circuitry 1 104 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1 104, alone or in combination, may be used to execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1 102 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g.,

transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

[0121] FIG. 12 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 1 104 of FIG. 1 1 may comprise processors 1 104A-1 104E and a memory 1 104G utilized by said processors. Each of the processors 1 104A-1 104E may include a memory interface, 1204A-1204E, respectively, to send/receive data to/from the memory 1 104G.

[0122] The baseband circuitry 1 104 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 1212 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1 104), an application circuitry interface 1214 (e.g., an interface to send/receive data to/from the application circuitry 1 102 of FIG. 1 1 ), an RF circuitry interface 1216 (e.g., an interface to send/receive data to/from RF circuitry 1 106 of FIG. 1 1 ), a wireless hardware connectivity interface 1218 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components,

Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 1220 (e.g., an interface to send/receive power or control signals to/from the PMC 1 1 12.

[0123] FIG. 13 is an illustration of a control plane protocol stack in accordance with some embodiments. In this embodiment, a control plane 1300 is shown as a communications protocol stack between the UE 1001 (or alternatively, the UE 1002), the RAN node 101 1 (or alternatively, the RAN node 1012), and the MME 1021 .

[0124] A PHY layer 1301 may transmit or receive information used by the MAC layer 1302 over one or more air interfaces. The PHY layer 1301 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as an RRC layer 1305. The PHY layer 1301 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.

[0125] The MAC layer 1302 may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, de-multiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.

[0126] An RLC layer 1303 may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer 1303 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. The RLC layer 1303 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.

[0127] A PDCP layer 1304 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

[0128] The main services and functions of the RRC layer 1305 may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. Said MIBs and SIBs may comprise one or more information elements (lEs), which may each comprise individual data fields or data structures.

[0129] The UE 1001 and the RAN node 101 1 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer 1301 , the MAC layer 1302, the RLC layer 1303, the PDCP layer 1304, and the RRC layer 1305.

[0130] In the embodiment shown, the non-access stratum (NAS) protocols 1306 form the highest stratum of the control plane between the UE 1001 and the MME 1021 . The NAS protocols 1306 support the mobility of the UE 1001 and the session management procedures to establish and maintain IP connectivity between the UE 1001 and the P-GW 1023.

[0131] The S1 Application Protocol (S1 -AP) layer 1315 may support the functions of the S1 interface and comprise Elementary Procedures (EPs). An EP is a unit of interaction between the RAN node 101 1 and the CN 1020. The S1 -AP layer services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transfer.

[0132] The Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as the stream control transmission protocol/internet protocol (SCTP/IP) layer) 1314 may ensure reliable delivery of signaling messages between the RAN node 101 1 and the MME 1021 based, in part, on the IP protocol, supported by an IP layer 1313. An L2 layer 1312 and an L1 layer 131 1 may refer to communication links (e.g., wired or wireless) used by the RAN node and the MME to exchange information.

[0133] The RAN node 101 1 and the MME 1021 may utilize an S1 -MME interface to exchange control plane data via a protocol stack comprising the L1 layer 131 1 , the L2 layer 1312, the IP layer 1313, the SCTP layer 1314, and the S1 -AP layer 1315.

[0134] FIG. 14 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Specifically, FIG. 14 shows a diagrammatic representation of hardware resources 1400 including one or more processors (or processor cores) 1410, one or more memory/storage devices 1420, and one or more communication resources 1430, each of which may be communicatively coupled via a bus 1440. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1402 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1400.

[0135] The processors 1410 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1412 and a processor 1414.

[0136] The memory/storage devices 1420 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1420 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM), static random-access memory

(SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0137] The communication resources 1430 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1404 or one or more databases 1406 via a network 1408. For example, the communication resources 1430 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular

communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication

components.

[0138] Instructions 1450 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1410 to perform any one or more of the methodologies discussed herein. The instructions 1450 may reside, completely or partially, within at least one of the processors 1410 (e.g., within the processor's cache memory), the memory/storage devices 1420, or any suitable combination thereof. Furthermore, any portion of the instructions 1450 may be transferred to the hardware resources 1400 from any combination of the peripheral devices 1404 or the databases 1406. Accordingly, the memory of processors 1410, the memory/storage devices 1420, the peripheral devices 1404, and the databases 1406 are examples of computer-readable and machine-readable media.

Example Embodiments

[0139] The following examples pertain to further embodiments.

[0140] Example 1 is an apparatus for a communication device, the apparatus comprising a memory interface and one or more baseband processors. The memory interface to send or receive, to or from a memory, a timer value of a beam level failure timer. The one or more baseband processors to: determine, at a physical layer, a beam level problem with a beam of a serving cell; upon detection of the beam level problem, initiate the beam level failure timer from the timer value;

determine, at the physical layer, a beam level failure if the beam level problem remains when the beam level failure timer expires; determine, at the physical layer, a status of a radio link with the serving cell; and provide, from the physical layer, information to an upper layer, the information including at least one of an indication of the beam level failure and an indication of the status of the radio link.

[0141] Example 2 is the apparatus of Example 1 , wherein the upper layer manages beam level failure and radio link failure.

[0142] Example 3 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: monitor, at the physical layer, a dedicated reference signal that is conveyed via the beam; and determine the beam level problem when the dedicated reference signal fails to satisfy a threshold.

[0143] Example 4 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: monitor, at the physical layer, a cell common reference signal that is conveyed via the beam; and determine the beam level problem when the cell common reference signal fails to satisfy a threshold.

[0144] Example 5 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: determine acknowledgement/negative acknowledgement (ACK/NACK) performance associated with the beam; and determine the beam level problem based on the ACK/NACK performance.

[0145] Example 6 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: determine a signal quality of the beam with the serving cell; determine a signal quality of a disparate beam with a disparate serving cell; compare the signal quality of the beam with the signal quality of the disparate beam; and determine the beam level problem when the signal quality of the beam does not satisfy a first threshold while the signal quality of the disparate beam satisfies a second threshold.

[0146] Example 7 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: determine, at the physical layer, a radio link failure if the beam level problem remains when a radio link failure timer expires, wherein the radio link failure timer has a different interval than the beam level failure timer.

[0147] Example 8 is the apparatus of Example 1 , wherein the information is provided to the upper layer periodically.

[0148] Example 9 is the apparatus of Example 1 , wherein the information is provided to the upper layer aperiodically.

[0149] Example 10 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: determine, at the upper layer, a beam level failure based on the indication of the beam level failure from the physical layer;

determine, at the upper layer, that a disparate serving cell is available upon determining the beam level failure; provide, from the upper layer, an indication for the physical layer to switch a data path from the serving cell to the disparate serving cell; and switch, at the physical layer, the data path from the serving cell to the disparate serving cell.

[0150] Example 1 1 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: determine, at the upper layer, a radio link failure; determine, at the upper layer, that a disparate serving cell is available upon determining the radio link failure; provide, from the upper layer, an indication for the physical layer to switch a data path from the serving cell to the disparate serving cell; and switch, at the physical layer, the data path from the serving cell to the disparate serving cell. [0151] Example 12 is the apparatus of Example 1 , wherein the one or more baseband processors are further to: provide a blockage indication to the serving cell upon determining the beam level failure, wherein the blockage indication is provided by the upper layer.

[0152] Example 13 is the apparatus of any of Examples 1 -12, wherein the communication device comprises an evolved Node B (eNB) or a

transmission/reception point (TRP), and the serving cell comprises a user equipment (UE), and wherein the blockage indication is provided to the serving cell via a radio resource control (RRC) message.

[0153] Example 14 is the apparatus of Example 13, wherein the RRC message includes a radio link failure (RLF)-cause information element (IE), and wherein the blockage indication is provided in the RLF-cause IE.

[0154] Example 15 is the apparatus of Example 13, wherein the RRC message includes a blockage reporting information element (IE), and wherein the blockage indication is provided in the blockage reporting IE.

[0155] Example 16 is the apparatus of any of Examples 1 -12, wherein the communication device comprises a user equipment (UE), and the serving cell comprises an evolved Node B (eNB) or a transmission/reception point (TRP), and wherein the blockage indication is provided to the serving cell via a physical uplink control channel (PUCCH).

[0156] Example 17 is a computer-readable medium having instructions stored thereon, the instructions, when executed by a computing device, cause the computing device to: determine a blockage of a high frequency beam link with a radio access network (RAN) node based on a blockage detection algorithm; start a blockage timer with a blockage timer value upon detection of the blockage;

determine if the high frequency beam link is recovered before the blockage timer expires; and provide an out-of-sync indication to a higher layer upon expiration of the blockage timer.

[0157] Example 18 is the computer-readable medium of Example 17, wherein the instructions further cause the computing device to: provide a blockage indication to the RAN node.

[0158] Example 19 is the computer-readable medium of Example 18, wherein the instructions further cause the computing device to: receive path switching information from a network associated with the RAN node, wherein the path switching information is received before the blockage timer expires.

[0159] Example 20 is the computer-readable medium of any of Examples 17-19, wherein the instructions further cause the computing device to: cancel the blockage timer when the high frequency beam link is recovered before the blockage timer expires; and switch paths to a different link when the high frequency beam link is still blocked and the blockage timer expires.

[0160] Example 22 is the computer-readable medium of Example 20, wherein the RAN node is a secondary RAN and the different link is a link with a master RAN.

[0161] Example 23 is the computer-readable medium any of Examples 17-19, wherein the blockage timer value is configured by a network associated with the RAN node.

[0162] Example 24 is the computer-readable medium of Example 23, wherein the blockage timer value is configured by the network and broadcasted to the computing device via a system information block (SIB).

[0163] Example 25 is the computer-readable medium of Example 23, wherein the blockage timer value is configured by the network and sent to the computing device via a radio resource control (RRC) message.

[0164] Example 26 is an apparatus for a first device, the apparatus comprising: circuitry to measure a channel quality of a link with a second device; and one or more processors to: determine, at layer 1 (L1 ), a blockage of a high frequency beam based at least in part on a channel quality measurement of the high frequency beam; perform, at L1 , radio link monitoring (RLM) on the high frequency beam; determine if there is a disparate beam with a channel quality measurement that satisfies a threshold; and provide an out-of-sync indication to layer 3 (L3), when there is not a disparate beam with a channel quality measurement that satisfies the threshold.

[0165] Example 27 is the apparatus of Example 26, wherein the out-of-sync indication is beam-specific, and wherein the out-of-sync indication is an out-of-sync indication for the high frequency beam.

[0166] Example 28 is the apparatus of Example 27, wherein the one or more processors are further to: determine that a second high frequency beam has a channel quality measurement that satisfies the threshold; switch to the second high frequency beam to communicate with the second device, wherein the switch is made at L1 without RRC involvement; and provide, at L1 , an in-sync indication for the second high frequency beam to L3.

[0167] Example 29 is the apparatus of Example 26, wherein the out-of-sync indication is radio link level-specific and is an out-of-sync indication for all beams.

[0168] Example 30 is the apparatus of Example 29, wherein the one or more processors are further to: provide, at L1 , an in-sync indication to L3 when there is a disparate beam with a channel quality measurement that satisfies the threshold.

[0169] Example 31 is a method for wireless communication, comprising:

determining, at a physical layer, a beam level problem with a beam with a serving cell; initiating a beam level failure timer upon detection of the beam level problem; determining, at the physical layer, a beam level failure if the beam level problem remains when the beam level failure timer expires; determining, at the physical layer, a status of a radio link with the serving cell; providing, from the physical layer, information to an upper layer, the information including at least one of an indication of the beam level failure and an indication of the status of the radio link.

[0170] Example 32 is the method of Example 31 , wherein the upper layer manages beam level failure and radio link failure.

[0171] Example 33 is the method of Example 31 , further comprising: monitoring, at the physical layer, a dedicated reference signal that is conveyed via the beam; and determining the beam level problem when the dedicated reference signal fails to satisfy a threshold.

[0172] Example 34 is the method of Example 31 , further comprising: monitoring, at the physical layer, a cell common reference signal that is conveyed via the beam; and determining the beam level problem when the cell common reference signal fails to satisfy a threshold.

[0173] Example 35 is the method of Example 31 , further comprising: determining acknowledgement/negative acknowledgement (ACK/NACK) performance associated with the beam; and determining the beam level problem based on the ACK/NACK performance.

[0174] Example 36 is the method of Example 31 , further comprising: determining a signal quality of the beam with the serving cell; determining a signal quality of a disparate beam with a disparate serving cell; comparing the signal quality of the beam with the signal quality of the disparate beam; and determining the beam level problem when the signal quality of the beam does not satisfy a first threshold while the signal quality of the disparate beam satisfies a second threshold.

[0175] Example 37 is the method of Example 31 , further comprising: determining, at the physical layer, a radio link failure if the beam level problem remains when a radio link failure timer expires, wherein the radio link failure timer has a different interval than the beam level failure timer.

[0176] Example 38 is the method of Example 31 , wherein the information is provided to the upper layer periodically.

[0177] Example 39 is the method of Example 31 , wherein the information is provided to the upper layer aperiodically.

[0178] Example 40 is the method of Example 31 , further comprising: determining, at the upper layer, a beam level failure based on the indication of the beam level failure from the physical layer; determining, at the upper layer, that a disparate serving cell is available upon determining the beam level failure; providing, from the upper layer, an indication for the physical layer to switch a data path from the serving cell to the disparate serving cell; and switching, at the physical layer, the data path from the serving cell to the disparate serving cell.

[0179] Example 41 is the method of Example 31 , further comprising: determining, at the upper layer, a radio link failure; determining, at the upper layer, that a disparate serving cell is available upon determining the radio link failure; providing, from the upper layer, an indication for the physical layer to switch a data path from the serving cell to the disparate serving cell; and switching, at the physical layer, the data path from the serving cell to the disparate serving cell.

[0180] Example 42 is the method of Example 31 , further comprising: providing a blockage indication to the serving cell upon determining the beam level failure, wherein the blockage indication is provided by the upper layer.

[0181] Example 43 is the method of any of Examples 31 -42, wherein the first device comprises an evolved Node B (eNB) or a transmission/reception point (TRP), and the serving cell comprises a user equipment (UE), and wherein the blockage indication is provided to the serving cell via a radio resource control (RRC) message.

[0182] Example 44 is the method of Example 43, wherein the RRC message includes a radio link failure (RLF)-cause information element (IE), and wherein the blockage indication is provided in the RLF-cause IE. [0183] Example 45 is the method of Example 43, wherein the RRC message includes a blockage reporting information element (IE), and wherein the blockage indication is provided in the blockage reporting IE.

[0184] Example 46 is the method of any of Examples 31 -42, wherein the first device comprises a user equipment (UE), and the serving cell comprises an evolved Node B (eNB) or a transmission/reception point (TRP), and wherein the blockage indication is provided to the serving cell via a physical uplink control channel (PUCCH).

[0185] Example 47 is an apparatus comprising means to perform a method as exemplified in any preceding Example.

[0186] Example 48 is a machine-readable storage including machine-readable instructions, when executed, to implement a method or realize an apparatus as exemplified in any preceding Example.

[0187] Example 49 is a device that sends a blockage indicator based on wide beam and narrow beam quality.

[0188] Example 50 is a device that sends a blockage indicator based on a diversity of beams.

[0189] Example 51 is an apparatus that sends a blockage indicator from the physical (PHY) layer of a device the to a higher layer (RRC layer) of the device if the device (e.g., UE) detects a blockage.

[0190] Example 52 is a device that sends a blockage indicator to the UE via RRC if the network detects a blockage.

[0191] Example 53 is the device of any of the Examples described herein where a dedicated blockage timer and a default blockage timer are configured by the network.

[0192] Example 54 is the device of any of the Examples described herein where assistance information is sent by the UE to the network so that the network can better determine a blockage timer duration.

[0193] Example 55 is the device of any of the Examples described herein where blockage (or beam-level problem) detection and beam-management rely on Layerl (L1 ).

[0194] Example 56 is the device of Example 55 or any of the Examples described herein where L1 performs RLM on the selected beam. Performing RLM on the selected beam means that L1 can switch from beam#1 to beam#2 without RRC involvement. So once beam#2 is reselected, Qin/Qout will be based on beam#2 rather than beam#1 .

[0195] Example 57 is the device of Example 55 or any of the Examples described herein where upon problem detection (meaning radio link (RL) problem), L3 waits for RL recovery (during timer T1 (e.g., T310)).

[0196] Example 58 is the device of Example 55 or any of the Examples described herein where blockage (or beam-level problem) detection and beam-management involves L3.

[0197] Example 59 is the device of Example 58 or any of the Examples described herein where L1 performs RLM only on the current beam (here this means L1 cannot switch beam#1 to beam#2 unless RRC indicates, so before the reception of RRC indication Qin/Qout will be only based on beam#1 ).

[0198] Example 60 is the device of Example 58 or any of the Examples described herein where upon problem detection (current beam problem here, so RRC will indicate L1 to do beam-switching), L3 triggers L1 to reselect a beam (during timer T1 ).

[0199] Example 61 is the device of Example 55 or any of the Examples described herein where L1 performs RLM on the selected beam in L1 (here, for example, if L1 can switch beam#1 to beam#2 without RRC involvement, before switching to beam#2, in-sync indication/out-of-sync indication will be generated based on channel quality of beam#1 , and after switching to beam#2, in-sync/out-of-sync indication will be generated based on channel quality of beam#2).

[0200] Example 62 is the device of Example 55 or any of the Examples described herein where an out-of-sync indication is generated if L1 cannot find any suitable beam meeting the minimum channel quality and an in-sync indication is generated if L1 can find any suitable beam meeting the minimum channel quality.

[0201] Example 63 is the device of any of the Examples described herein where L3 does not need to count N310 and to start T310 in L3. However L3 may need to indicate N310 and T310 to L1 in order to do RLF declaration in L1 .

[0202] Embodiments and implementations of the systems and methods described herein may include various operations, which may be embodied in machine- executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic for performing the operations or may include a combination of hardware, software, and/or firmware.

[0203] Computer systems and the computers in a computer system may be connected via a network. Suitable networks for configuration and/or use as described herein include one or more local area networks, wide area networks, metropolitan area networks, and/or Internet or IP networks, such as the World Wide Web, a private Internet, a secure Internet, a value-added network, a virtual private network, an extranet, an intranet, or even stand-alone machines which communicate with other machines by physical transport of media. In particular, a suitable network may be formed from parts or entireties of two or more other networks, including networks using disparate hardware and network communication technologies.

[0204] One suitable network includes a server and one or more clients; other suitable networks may contain other combinations of servers, clients, and/or peer-to- peer nodes, and a given computer system may function both as a client and as a server. Each network includes at least two computers or computer systems, such as the server and/or clients. A computer system may include a workstation, laptop computer, disconnectable mobile computer, server, mainframe, cluster, so-called "network computer" or "thin client," tablet, smart phone, personal digital assistant or other hand-held computing device, "smart" consumer electronics device or appliance, medical device, or a combination thereof.

[0205] Suitable networks may include communications or networking software, such as the software available from Novell®, Microsoft®, and other vendors, and may operate using TCP/IP, SPX, IPX, and other protocols over twisted pair, coaxial, or optical fiber cables, telephone lines, radio waves, satellites, microwave relays, modulated AC power lines, physical media transfer, and/or other data transmission "wires" known to those of skill in the art. The network may encompass smaller networks and/or be connectable to other networks through a gateway or similar mechanism.

[0206] Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, magnetic or optical cards, solid-state memory devices, a nontransitory computer-readable storage medium, or any other machine- readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and nonvolatile memory and/or storage elements may be a RAM, an

EPROM, a flash drive, an optical drive, a magnetic hard drive, or other medium for storing electronic data. The eNB (or gNB, or other base station) and UE (or other mobile station) may also include a transceiver component, a counter component, a processing component, and/or a clock component or timer component. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high-level procedural or an object-oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

[0207] Each computer system includes one or more processors and/or memory; computer systems may also include various input devices and/or output devices. The processor may include a general purpose device, such as an Intel®, AMD®, or other "off-the-shelf" microprocessor. The processor may include a special purpose processing device, such as ASIC, SoC, SiP, FPGA, PAL, PLA, FPLA, PLD, or other customized or programmable device. The memory may include static RAM, dynamic RAM, flash memory, one or more flip-flops, ROM, CD-ROM, DVD, disk, tape, or magnetic, optical, or other computer storage medium. The input device(s) may include a keyboard, mouse, touch screen, light pen, tablet, microphone, sensor, or other hardware with accompanying firmware and/or software. The output device(s) may include a monitor or other display, printer, speech or text synthesizer, switch, signal line, or other hardware with accompanying firmware and/or software.

[0208] It should be understood that many of the functional units described in this specification may be implemented as one or more components, which is a term used to more particularly emphasize their implementation independence. For example, a component may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, or off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.

[0209] Components may also be implemented in software for execution by various types of processors. An identified component of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, a procedure, or a function.

Nevertheless, the executables of an identified component need not be physically located together, but may comprise disparate instructions stored in different locations that, when joined logically together, comprise the component and achieve the stated purpose for the component.

[0210] Indeed, a component of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.

Similarly, operational data may be identified and illustrated herein within

components, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components may be passive or active, including agents operable to perform desired functions.

[0211] Several aspects of the embodiments described will be illustrated as software modules or components. As used herein, a software module or component may include any type of computer instruction or computer-executable code located within a memory device. A software module may, for instance, include one or more physical or logical blocks of computer instructions, which may be organized as a routine, program, object, component, data structure, etc., that perform one or more tasks or implement particular data types. It is appreciated that a software module may be implemented in hardware and/or firmware instead of or in addition to software. One or more of the functional modules described herein may be separated into sub-modules and/or combined into a single or smaller number of modules.

[0212] In certain embodiments, a particular software module may include disparate instructions stored in different locations of a memory device, different memory devices, or different computers, which together implement the described functionality of the module. Indeed, a module may include a single instruction or many instructions, and may be distributed over several different code segments, among different programs, and across several memory devices. Some

embodiments may be practiced in a distributed computing environment where tasks are performed by a remote processing device linked through a communications network. In a distributed computing environment, software modules may be located in local and/or remote memory storage devices. In addition, data being tied or rendered together in a database record may be resident in the same memory device, or across several memory devices, and may be linked together in fields of a record in a database across a network.

[0213] Reference throughout this specification to "an example" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment. Thus, appearances of the phrase "in an example" in various places throughout this specification are not necessarily all referring to the same embodiment.

[0214] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on its presentation in a common group without indications to the contrary. In addition, various embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations.

[0215] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of materials, frequencies, sizes, lengths, widths, shapes, etc., to provide a thorough

understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of embodiments. [0216] It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into single systems, partially combined into other systems, split into multiple systems or divided or combined in other ways. In addition, it is contemplated that

parameters/attributes/aspects/etc. of one embodiment can be used in another embodiment. The parameters/attributes/aspects/etc. are merely described in one or more embodiments for clarity, and it is recognized that the

parameters/attributes/aspects/etc. can be combined with or substituted for parameters/attributes/etc. of another embodiment unless specifically disclaimed herein.

[0217] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

[0218] Those having skill in the art will appreciate that many changes may be made to the details of the above-described embodiments without departing from the underlying principles. The scope of the present embodiments should, therefore, be determined only by the following claims.