SCell beam failure recovery

Abstract

The present invention discloses an apparatus, method and system for SCell beam failure recovery. A device (400) includes a transceiver (425) for communicating with an SCell (125) in a wireless communication network. The device (400) includes a processor (405) for receiving (605) a 5SR configuration from a wireless communication network (210), wherein the SR configuration includes a set of PUCCH resources, wherein the SR configuration corresponds to one or more logical channels. The processor (405) detects (610) that a beam failure procedure has been triggered for the SCell (125). The processor (405) triggers (615) a scheduling request for SCell beam failure recovery in response to determining that there are no UL-SCH resources available for new transmission of a beam failure MAC CE. The processor (405) transmits (620) an SR on the PUCCH resources of the SR configuration in response to triggering the scheduling request for SCell beam failure recovery.

Description

[0001] CROSS REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 906,576, entitled “Beam Failure Recovery Procedure for SCell,” filed on September 26, 2019, by Joachim Loehr, Hyejung Jung, Vijay Nangia, Prateek Basu Mallick, and Ravi Kuchibhotla, which is incorporated herein by reference. Technical Field

[0003] The subject matter disclosed herein relates generally to wireless communications, and more particularly to effective SCell beam failure recovery. Background Art

[0004] The following abbreviations are defined herein, at least some of which may be referred to in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation Core Network (“5GC”), 5th Generation System (“5GS”), 5G QoS Indicator (“5QI”), Authentication, Authorization and Accounting (“AAA”), Acknowledgement (“ACK”), Application Function (“AF”), Access and Mobility Management Function (“AMF”), Antenna Panel (“AP”), Application Programming Interface (“API”), Access Stratum (“AS”), Base Station (“BS”), Buffer Status Report (“BSR”), Code Division Multiple Access (“CDMA”), Control Element (“CE”), Core Network (“CN”), Channel Quality Indicator (“CQI”), Channel State Information (“CSI”), CSI Reference Signal (“CSI-RS”), Dual Connectivity (“DC”), Downlink Control Information (“DCI”), Downlink (“DL”), Demodulation Reference Signal (“DM-RS”), Data Radio Bearer (“DRB”), Discontinuous Transmission (“DTX”), Enhanced Inter-Cell Interference Coordination (“eICIC”), Evolved Node B (“eNB”), Evolved Packet Core (“ ), Evolved Packet System (“EPS”), Evolved UMTS Terrestrial Radio Access (“E-UTRA”), Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), European Telecommunications Standards Institute (“ETSI”), Guaranteed Bit Rate (“GBR”), Next Generation (i.e., 5G) Node B (“gNB”), Global Navigation Satellite System (“GNSS”), General Packet Radio Service (“GPRS”), Global Positioning System (“GPS”), General Public Service Identifier (“GPSI”), Global System for Mobile Communications (“GSM”), Hybrid Automatic Repeat Request (“HARQ”), Home Subscriber Server (“HSS”), Inter-Cell Interference Coordination (“ICIC”), Identifier (“ID”), Information Element (“IE”), Industrial Internet of Things (“IIOT”), Internet of Things (“IoT”), Key Performance Indicator (“KPI”), Layer 1 (“L1”, also known as the physical layer), Layer 1 Identifier (“L1 Identifier”), ID”), Layer 2 (“L2”, also known as Link Layer), Layer 2 Identifier (“L2 ID”), Layer 3 (“L3”, also known as Network Layer), Logical Channel (“LCH”), LCH Priority (“LCP”), Long Term Evolution (“LTE”), Machine Learning (“ML”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Negative Acknowledgement (“NACK”) or (“NAK”), Non-Access Stratum (“NAS”), Next Generation Radio Access Network (“NG-RAN”, RAN for 5GS Networks), Neural Network (“NN”), Network Slice Selection Assistance Information (“NSSAI”, e.g.Vector value containing one or more S-NSSAI values), New Radio ("NR", a 5G radio access technology; also referred to as "5G NR"), Observed Time Difference of Arrival ("OTDoA"), PC5 5QI ("PQI", corresponding to QoS for NR V2X communications over the PC5 interface), Packet Data Network ("PDN"), Packet Data Unit ("PDU", used in conjunction with 'PDU Session'), PC5 QoS Flow Indicator ("PFI"), Packet Data Network Gateway ("P-GW"), PC5 Link Identifier ("PLI"), Public Land Mobile Network ("PLMN"), Precoding Matrix Indicator ("PMI"), Physical Random Access Channel ("PRACH"), Physical Sidelink Control Channel ("PSCCH"), Physical Sidelink Shared Channel ("PSSCH"), QoS Flow Indicator ("QFI"), Quality of Experience ("QoE"), Quality of Service ("QoS"), Random Access Channel ("RACH"), Radio Access Network ("RAN"), Rank Indicator ("RI"), RAN Intelligent Controller ("RIC"), Radio Link Monitoring ("RLM"), Radio Network Information ("RNI"), RNI Service ("RNIS"), Radio Resource Management ("RRM"), Received Signal Received Power ("RSRP"), Received Signal Strength Indicator ("RSSI"), Receive ("RX"), Sidelink Control Information ("SCI"), Sidelink CSI RS ("S-CSI-RS"), Serving Gateway ("S-GW"), Signal to Interference and Noise Ratio ("SINR"), Sidelink ("SL"), Sidelink Reference Signal ("SL-RS"), Sidelink Synchronization Signal ("SLSS"), Sidelink Synchronization Signal Block ("SL-SSB"), Session Management ("SM"), Session Management Function ("SMF"), Single Network Slice Selection Assistance Information ("S-NSSAI"), Service Provider ("SP"), Semi-Persistent Scheduling ("SPS"), Sounding Reference Signal ("SRS"), Sidelink Received Signal Received Power ("S-RSRP"), Synchronization Signal ("SS"), Synchronization Signal Block ("SSB"), Transport Block ("TB") ”), Transmission Configuration Indicator (“TCI”), Time Difference of Arrival (“TDoA”), Transmission (“TX”), Uplink Control Information (“UCI”), Unified Data Management (“UDM”), User Data Repository (“UDR”), User Entity / Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), Uplink Shared Channel (“UL-SCH”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), UL Time Difference of Arrival (“UTDoA” or “U-TDoA”), UMTS Terrestrial Radio Access (“UTRA”), UMTS Terrestrial Radio Access Network (“UTRAN”), Vehicle-to-Everything (“V2X”,V2X communication covers both V2V and V2I), vehicle-to-infrastructure ("V2I"), vehicle-to-vehicle ("V2V"), ​​UEs capable of vehicle communication using 3GPP protocols ("V2X UE"), and Worldwide Interoperability for Microwave Access ("WiMAX"). As used herein, "HARQ-ACK" means that HARQ feedback can collectively represent positive acknowledgement ("ACK") and negative acknowledgement ("NACK") as well as discontinuous transmission ("DTX"). ACK means that the TB is received correctly, while NACK (or NAK) means that the TB is received in error. DTX means that the TB is not detected. ,

[0005] In some wireless communication systems, multiple-input multiple-output ("MIMO") technology is used to improve data throughput. In 5G wireless communication systems, large-scale MIMO can be achieved by using beam-based cell sector coverage, where several narrow beam width beams replace the single wide beam used in previous generations to achieve coverage of the cell sector. Since the cell coverage is beam-based, the mobile terminal (UE) in the 5G cell will synchronize with the beam, attach to the beam, and report from the beam. Under the current 3GPP standard, the UE will only be connected to a single beam. However, each beam in a large-scale MIMO system covers a limited area of ​​the cell sector, and therefore beam failure ("BF") may occur, for example due to UE mobility or environmental conditions (e.g., radio shadowing, interference, etc.). Summary of the invention

[0006] Disclosed is a procedure for SCell beam failure recovery. The procedure may be implemented by a device, a system, a method or a computer program product.

[0007] A method of a UE includes receiving an SR configuration from a wireless communication network. Here, the SR configuration includes a set of PUCCH resources, wherein the SR configuration corresponds to one or more logical channels. The method includes detecting that a beam failure recovery procedure has been triggered for an SCell in the wireless communication network. The method includes triggering an SR for SCell beam failure recovery in response to determining that there are no UL-SCH resources available for new transmission of a beam failure MAC CE. The method includes transmitting an SR on the PUCCH resources of the SR configuration in response to triggering the SR for SCell beam failure recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only some embodiments and are therefore not to be considered limiting in scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1is a schematic block diagram illustrating an embodiment of a wireless communication system for SCell beam failure recovery;

[0010] Figure 2 is a diagram illustrating an embodiment of beam failure recovery for SCell;

[0011] Figure 3 is a diagram of one embodiment of a protocol stack;

[0012] Figure 4 is a diagram illustrating one embodiment of a user equipment device that can be used for SCell beam failure recovery;

[0013] Figure 5 is a diagram illustrating an embodiment of a network equipment device that can be used for SCell beam failure recovery; and

[0014] Figure 6 is a flow chart illustrating one embodiment of a first method that may be used for SCell beam failure recovery. DETAILED DESCRIPTION

[0015] As will be appreciated by those skilled in the art, aspects of the embodiments may be embodied as systems, devices, methods, or program products. Thus, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects.

[0016] For example, the disclosed embodiments may be implemented as hardware circuits including custom very large scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code that may be organized, for example, as an object, procedure, or function.

[0017] In addition, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code (hereinafter referred to as code). The storage device may be tangible, non-transitory, and / or non-transmitting. The storage device may not embody a signal. In some embodiments, the storage device employs only a signal for accessing the code.

[0018] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing code. For example, the storage device may be (but not limited to) an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical or semiconductor system, apparatus or device, or any suitable combination of the foregoing.

[0019] More specific examples of storage devices (a non-exhaustive list) would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0020] The code for carrying out the operations of the embodiments may be any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, or the like, as well as conventional procedural programming languages ​​such as the "C" programming language or the like, and / or machine languages ​​such as assembly languages. The code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0021] In addition, the described features, structures or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that the embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail to avoid confusing aspects of the embodiments.

[0022] Throughout this specification, references to "one embodiment," "an embodiment," or similar language mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment. Therefore, unless otherwise expressly provided, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may (but not necessarily) all refer to the same embodiment, but rather mean "one or more but not all embodiments." Unless otherwise expressly provided, the terms "comprise," "include," "have," and their variations mean "including (but not limited to)." Unless otherwise expressly provided, a list of enumerated items does not mean that any or all items are mutually exclusive. Unless otherwise expressly provided, the terms "a," "an," and "said" also mean "one or more."

[0023] As used herein, a list with the conjunction "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of..." includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of" includes one or only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and does not include a combination of A, B, and C. As used herein, "a member selected from a group consisting of A, B, and C" includes one and only one of A, B, or C, and does not include a combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof" includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0024] Aspects of the embodiments are described below with reference to schematic flow charts and / or schematic block diagrams of methods, devices, systems, and program products according to the embodiments. It will be understood that each block of the schematic flow charts and / or schematic block diagrams and the combination of blocks in the schematic flow charts and / or schematic block diagrams can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that instructions executed by a processor of a computer or other programmable data processing device create a means for implementing the functions / actions specified in the flow charts and / or block diagrams.

[0025] Code may also be stored in a storage device, which may instruct a computer, other programmable data processing apparatus or other device to function in a specific manner so that the instructions stored in the storage device produce an article of manufacture containing instructions for implementing the functions / actions specified in the flowchart and / or block diagram.

[0026] The code may also be loaded onto a computer, other programmable data processing device or other apparatus to cause a series of operational steps to be executed on the computer, other programmable device or other apparatus to produce a computer-implemented process, so that the code executed on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0027] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality and operation of possible implementations of devices, systems, methods and program products according to various embodiments. In this regard, each box in the flowcharts and / or block diagrams may represent a module, segment or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function.

[0028] It should also be noted that in some alternative implementations, the functions noted in the blocks may not occur in the order noted in the figure. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods are conceivable that are equivalent in function, logic, or effect to one or more blocks or portions thereof of the illustrated figure.

[0029] Although various arrow types and line types may be used in flowcharts and / or block diagrams, it should be understood that they do not limit the scope of the corresponding embodiments. In fact, some arrows or other connecting symbols may be used to indicate only the logical flow of the depicted embodiments. For example, arrows may indicate waiting or monitoring periods of unspecified duration between enumerated steps of the depicted embodiments. It will also be noted that each box of the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and code that performs a specified function or action.

[0030] The description of an element in each figure may refer to an element of a previous figure. Like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0031] In general, the present disclosure describes systems, methods, and devices for beam failure recovery for SCell. For BFR on SCell, the UE monitors the quality of the SCell. In the event of a declared beam failure, the UE sends a beam failure recovery request (BFRQ) and sends the failed SCell index and new beam information (if any) to the network. The network can be notified using SR resources for BFR on the PUCCH. The BFR SR can be carried on a primary cell ("PCell") or a primary secondary cell ("PSCell"). In addition, the UE can send a MAC CE to provide the network with information about the new beam (if any). The current 3GPP specification does not restrict the transmission of MAC CE for BFR, i.e., in Rel-16, the UE can use the UL authorization of any serving cell to transmit the SCell BFR MAC CE.

[0032] However, the transmission of the SCell BFR MAC CE on a serving cell that has declared a beam failure may fail, for example, the UE will most likely not receive an UL grant / DCI on the serving cell with the beam failure, and therefore no UL transmission will occur. However, in addition to dynamically scheduled uplink transmissions, the UE may be configured with UL "configured grant" (e.g., semi-static) resources. The present disclosure provides embodiments that are intended to avoid transmitting a SCell BFR MAC CE on a serving cell that has experienced a beam failure, thereby not introducing multiplexing restrictions on the SCell BFR MAC CE.

[0033] According to the current agreement, a dedicated PUCCH resource similar to SR is introduced to request uplink resources for transmitting SCell BFR MAC CE. In addition, for the case where two SR / PUCCH are colliding, this SCell BFR PUCCH should have a higher priority than the normal (data-related) SR. There may be a situation where the network does not configure the UE with SCell BFR PUCCH, in which case the UE can trigger a random access procedure to request UL resources for transmitting SCell BFR MAC CE. Because performing a RACH procedure (specifically a contention-based RACH procedure) will result in a delayed beam failure recovery procedure (which is time-critical according to the RAN1 agreement), the present disclosure provides some solutions to avoid the additional delay incurred by performing the RACH procedure for the case where the UE is not configured with SCell BFR PUCCH resources.

[0034] According to 3GPP Release 16 ("Rel-16"), the UE considers the SCell beam failure recovery procedure to be successfully completed upon receipt of an UL grant that schedules a new transmission for the HARQ process on which the SCell BFR MAC CE was previously sent, i.e., thereby confirming the reception of the SCell BFR MAC CE. A problem may arise with this definition for the following situation: when the SCell BFR MAC CE is transmitted in accordance with a configured grant and after the associated configuredGrantTimer expires, the UE erroneously considers the next CG occasion / UL grant as a response / confirmation to the BFR, even though the gNB did not receive the SCell BFR MAC CE, i.e., if the corresponding configuredGrantTimer is not running, then the NDI bit is considered to be switched for the configured uplink grant. The present disclosure provides some solutions for avoiding the situation where the UE erroneously considers the beam failure recovery procedure to be successfully completed.

[0035] Currently, there is no defined UE behavior for the case where the beam failure recovery procedure does not complete successfully. The present disclosure provides some well-defined UE behaviors for the case where the BFR procedure does not complete successfully.

[0036] Figure 1 A wireless communication system 100 for SCell beam failure recovery of a wireless device according to an embodiment of the present disclosure is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network ("RAN") 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may be composed of base units 121 with which the remote units 105 communicate using wireless communication links. Although Figure 1 A specific number of remote units 105, base units 121, RAN 120, and mobile core networks 140 are depicted in the figure, but technicians in the field will recognize that any number of remote units 105, base units 121, RAN 120, and mobile core networks 140 may be included in the wireless communication system 100.

[0037] In one embodiment, the RAN 120 complies with the 5G system specified in the 3GPP specification. In another embodiment, the RAN 120 complies with the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication network, such as WiMAX, among other networks. The present disclosure is not intended to be limited to implementations of any particular wireless communication system architecture or protocol.

[0038] In one embodiment, the remote unit 105 may include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant ("PDA"), a tablet computer, a smart phone, a smart TV (e.g., a TV connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a game console, a security system (including a security camera), a car computer, a network device (e.g., a router, a switch, a modem), or the like. In some embodiments, the remote unit 105 includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, or the like. In addition, the remote unit 105 may be referred to as a UE, a user unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a user station, a user terminal, a wireless transmission / reception unit ("WTRU"), a device, or other terms used in the art.

[0039] The remote unit 105 may communicate directly with one or more of the base units 121 in the RAN 120 via uplink ("UL") and downlink ("DL") communication signals. In addition, the UL and DL communication signals may be carried over wireless communication links. Here, the RAN 120 is an intermediate network that provides access to the mobile core network 140 for the remote unit 105.

[0040] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection with the mobile core network 140. For example, an application 107 in the remote unit 105 (e.g., a web browser, a media client, a phone / VoIP application) may trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 via the RAN 120. The mobile core network 140 then relays traffic between the remote unit 105 and the application server 151 in the packet data network 150 using the PDU session. A PDU session represents a logical connection between the remote unit 105 and the UPF 141. To establish a PDU session, the remote unit 105 must register with the mobile core network. It should be noted that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. Thus, the remote unit 105 may simultaneously have at least one PDU session for communicating with the packet data network 150 and at least one PDU session for communicating with another data network (not shown).

[0041] The base units 121 may be distributed throughout a geographic area. In some embodiments, the base units 121 may also be referred to as access terminals, access points, base stations, base stations, node Bs, eNBs, gNBs, home node Bs, relay nodes, RAN nodes, or by other terms used in the art. The base units 121 are typically part of a radio access network (“RAN”), such as RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base units 121. These and other elements of a radio access network are not illustrated but are well known to those of ordinary skill in the art. The base units 121 are connected to the mobile core network 140 via the RAN 120.

[0042] The base unit 121 can serve a number of remote units 105 within a service area (e.g., a cell or cell sector) via a wireless communication link. As depicted, the base unit 121 can support a special cell 123 (i.e., a PCell or PScell) and / or an SCell 125. The base unit 121 can communicate directly with one or more of the remote units 105 via a communication signal. In general, the base unit 121 transmits a DL communication signal to serve the remote unit 105 in the time, frequency, and / or spatial domain. In addition, the DL communication signal can be carried by a wireless communication link. The wireless communication link can be any suitable carrier in a licensed or unlicensed radio spectrum. The wireless communication link facilitates communication between one or more of the remote units 105 and / or one or more of the base units 121.

[0043] In one embodiment, mobile core network 140 is a 5G core ("5GC") or an evolved packet core ("EPC"), which may be coupled to a packet data network 150, such as the Internet and private data networks, among other data networks. Remote units 105 may have subscriptions or other accounts with mobile core networks 140. Each mobile core network 140 belongs to a single public land mobile network ("PLMN"). The present disclosure is not intended to be limited to implementations of any particular wireless communication system architecture or protocol.

[0044] The mobile core network 140 includes several network functions ("NFs"). As depicted, the mobile core network 140 includes one or more user plane functions ("UPFs") 141. The mobile core network 140 also includes multiple control plane functions, including, but not limited to, an access and mobility management function ("AMF") 143 serving the RAN 120, a session management function ("SMF") 145, a policy control function ("PCF") 147, and a unified data management function ("UDM") 149. In various embodiments, the mobile core network 140 may also include an authentication server function ("AUSF"), a network repository function ("NRF") (used by various NFs to discover and communicate with each other through APIs), a network open function ("NEF"), or other NFs defined for the 5GC.

[0045] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, "network slice" refers to a portion of the mobile core network 140 that is optimized for a specific business type or communication service. Each network slice includes a set of CP and / or UP network functions. A network instance may be identified by an S-NSSAI, and a set of network slices that the remote unit 105 is authorized to use is identified by an NSSAI. In some embodiments, various network slices may include separate instances of network functions, such as SMF 145 and UPF 141. In some embodiments, different network slices may share some common network functions, such as AMF 143. For ease of illustration, Figure 1 Different network slices are not shown in , but are assumed to be supported.

[0046] although Figure 1 140, but those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140. Furthermore, where the mobile core network 140 is an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as MME, S-GW, P-GW, HSS, and the like. In certain embodiments, the mobile core network 140 may include an AAA server.

[0047] In various embodiments, the remote unit 105 may experience a beam failure while in the coverage area of ​​the base unit 121, wherein the remote unit 105 triggers a beam failure recovery procedure 130. In certain embodiments, the remote unit 105 responds to the beam failure by selectively ignoring a received UL grant that allocates resources, as discussed in further detail below. In certain embodiments, the remote unit 105 transmits a SCell beam failure recovery (“BFR”) MAC control element (“CE”) for the SCell with the beam failure based on the available dynamic UL grant without performing a BFR scheduling request (“SR”), as discussed in further detail below. In certain embodiments, if there are no valid PUCCH resources configured for the SCell BFR SR and the remote unit 105 does not have available UL resources for transmitting the BFR MAC CE, the remote unit 105 may use any valid SR physical uplink control channel (“PUCCH”) resources configured for the remote unit 105, as discussed in further detail below.

[0048] In some embodiments, the remote unit 105 is configured by the network, wherein the SR configuration is configured for data-related buffer status reporting ("BSR") and / or SR triggering (referred to as "BSR / SR triggering"), such as the SR configuration corresponding to a logical channel, for sending a SCell BFR SR, as discussed in further detail below. In some embodiments, the remote unit 105 considers the SCell beam failure recovery ("BLR") procedure to be successfully completed upon receipt of a dynamic UL grant that is scheduled for a new transmission of a HARQ process on which a SCell BFR MAC CE was previously sent, as discussed in further detail below.

[0049] In some embodiments, the remote unit 105 (re) triggers a SCell BFR SR (if there is no available UL grant) or instructs a multiplexing and assembly procedure to generate a SCell BFR MAC CE (if there is an available UL grant) upon expiration of the SCell BFR timer, as discussed in further detail below. In some embodiments, the remote unit 105 transmits a BFR SR (if SR is configured on the SpCell) using a regular (logical channel-related) SR configuration / PUCCH resource configured for the remote unit 105 on a special cell ("SpCell"), or performs a random access ("RACH") procedure on the SpCell (if SR is not configured on the SpCell), as discussed in further detail below.

[0050] although Figure 1Components of a 5G RAN and 5G core network are depicted, but the described embodiments for beam failure recovery of SCells are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfoxx, and the like. For example, in an LTE variant involving an EPC, AMF 143 may be mapped to an MME, SMF 145 may be mapped to the control plane portion of a PGW and / or the MME, UPF 141 may be mapped to the SGW and the user plane portion of the PGW, UDM / UDR 149 may be mapped to an HSS, and so on.

[0051] In the following description, the term "RAN node" is used for a base station, but it can be replaced by any other radio access node (e.g., gNB, eNB, BS, AP, NR, etc.). In addition, the operation is mainly described in the context of 5G NR. However, the proposed solution / method is also equally applicable to other mobile communication systems that support beamforming and / or beam-based cell sectors.

[0052] Figure 2 A recovery procedure 200 is depicted between a UE 205 and a RAN node 211 in a wireless communication network 210. It should be noted that the UE 205 may be one embodiment of the remote unit 105 described above. Similarly, the wireless communication network 210 may be an embodiment of the RAN 120 and the mobile core network 140 described above. Although Figure 2 Specific units are not shown, but it is assumed that UE 205 communicates with the wireless communication network 210 using a primary cell (e.g., at least one cell from a primary cell group or a master cell group) and at least one secondary cell (e.g., one or more secondary cells from a primary / master cell group and / or from a secondary cell group).

[0053] During procedure 200, UE 205 experiences a beam failure of a secondary cell ("SCell") 125 provided by RAN node 211. Initially, UE 205 detects a beam failure of the SCell (see box 215) and triggers a SCell beam failure recovery procedure (see box 220). Various solutions for SCell beam failure recovery ("BFR") are described below. In the depicted embodiment, UE 205 sends a beam failure recovery request to RAN node 211 (see messaging 225). In one embodiment, the beam failure recovery request may trigger the transmission of an SR sent according to the SR configuration. In another embodiment, the beam failure recovery request may be a MAC CE sent using UL-SCH resources. In certain embodiments, UE 205 optionally monitors for a BFR response from RAN node 211 (see box / message 230).

[0054] Figure 3 A protocol stack 300 is depicted according to an embodiment of the present disclosure. Figure 3 UE 205, RAN node 211, and mobile core network 140 are shown, but these represent a set of remote units 105 that interact with base unit 121 and mobile core network 140. As depicted, protocol stack 300 includes a user plane protocol stack 305 and a control plane protocol stack 310. User plane protocol stack 305 includes a physical ("PHY") layer 315, a medium access control ("MAC") sublayer 320, a radio link control ("RLC") sublayer 325, a packet data convergence protocol ("PDCP") sublayer 330, and a service data adaptation protocol ("SDAP") layer 335. Control plane protocol stack 310 also includes a physical layer 315, a MAC sublayer 320, an RLC sublayer 325, and a PDCP sublayer 330. Control plane protocol stack 310 also includes a radio resource control ("RRC") layer and a non-access stratum ("NAS") layer 345.

[0055] The AS protocol stack for the control plane protocol stack 310 consists of at least RRC, PDCP, RLC and MAC sublayers and a physical layer. The AS protocol stack for the user plane protocol stack 305 consists of at least SDAP, PDCP, RLC and MAC sublayers and a physical layer. Layer 2 ("L2") is divided into SDAP, PDCP, RLC and MAC sublayers. Layer 3 ("L3") includes an RRC sublayer 340 and a NAS layer 345 for the control plane, and includes, for example, an Internet Protocol ("IP") layer or a PDU layer (not depicted) for the user plane. L1 and L2 are referred to as "lower layers", while L3 and above (e.g., transport layer, application layer) are referred to as "higher layers" or "upper layers".

[0056] The physical layer 315 provides transport channels to the MAC sublayer 320. The MAC sublayer 320 provides logical channels to the RLC sublayer 325. The RLC sublayer 325 provides RLC channels to the PDCP sublayer 330. The PDCP sublayer 330 provides radio bearers to the SDAP sublayer 335 and / or the RRC layer 340. The SDAP sublayer 335 provides QoS flows to the mobile core network 140 (e.g., 5GC). The RRC layer 340 provides carrier aggregation and / or dual connectivity addition, modification, and release. The RRC layer 340 also manages the establishment, configuration, maintenance, and release of signaling radio bearers ("SRBs") and data radio bearers ("DRBs"). In certain embodiments, the RRC entity is used to detect and recover from radio link failures.

[0057] According to the first solution, the UE 205 ignores the received uplink grant that allocates uplink resources on the SCell 125 for which: 1) a beam failure is detected / declared, or 2) a beam failure recovery procedure is initiated and not successfully completed. According to one implementation of the first solution, the UE 205 autonomously (i.e., acting without explicit signaling or instructions from the RAN node 211) deactivates or clears any configured uplink grant. In addition, when: 1) a beam failure is detected or 2) a beam failure recovery procedure is initiated for the SCell 125, the UE 205 may also clear any PUSCH resources used for semi-persistent CSI reporting of the SCell 125. In some embodiments, if the SCell 125 is configured with a PUCCH, the UE 205 may also stop transmission on the PUCCH. Similarly, the UE 205 may also stop SRS transmission, except possibly for SRS in a resource set for the purpose of 'beam management'.

[0058] In one implementation of the first solution, the UE 205 (specifically, the MAC entity at the MAC layer 320 of the UE 205) stops uplink transmission for the SCell 125 when the beam failure recovery procedure is initiated for the SCell 125, and regards the timeAlignmentTimer (TAT) associated with the SCell 125 as expired. By stopping UL transmission on the SCell 125 for which the beam failure recovery procedure has been initiated, and thereby ensuring that the SCell BFR MAC CE is not transmitted on the SCell 125 that experiences a beam failure, a transmission failure of the SCell BFR MAC CE and a resulting delayed beam failure recovery procedure are avoided.

[0059] In one embodiment of the first solution, stopping UL transmission on the SCell 125 where the beam failure recovery procedure is initiated may be achieved by considering the timeAlignmentTimer associated with the SCell 125 as expired. For example, Section 5.2 of 3GPP TS 38.321 may be modified to specify: "When the MAC entity stops uplink transmission of the SCell due to the fact that the beam failure recovery procedure is initiated for the SCell, the MAC entity considers the timeAlignmentTimer associated with the SCell as expired". "When the MAC entity stops uplink transmission for a SCell due to the fact that the maximum uplink transmission timing difference between the timing advance groups ("TAGs") of the MAC entity or the maximum uplink transmission timing difference between the TAGs of any MAC entity of the UE is exceeded, the MAC entity shall consider the timeAlignmentTimer associated with the SCell expired. It should be noted that a TAG refers to one or more serving cells including cells with the same UL timing advance and the same DL timing reference cell. If a TAG contains a PCell, it is called a primary timing advance group ("pTAG"). If a TAG contains only a SCell, it is called a secondary timing advance group ("sTAG").

[0060] In addition, when the MAC entity stops uplink transmission for the SCell 125 due to the fact that the beam failure recovery process is started for the SCell 125, the MAC entity regards the timeAlignmentTimer associated with the SCell as expired. It should be noted that when the timeAlignmentTimer associated with the TAG to which this serving cell belongs is not running, the MAC entity does not perform any uplink transmission on the serving cell, except for the random access preamble transmission. In addition, when the timeAlignmentTimer associated with the master timing advance group is not running, the MAC entity does not perform any uplink transmission on any serving cell, except for the random access preamble transmission on the SpCell.

[0061] According to the second solution, if the available dynamic UL grant is on the SpCell, the UE 205 may transmit the SCell BFR MAC CE for the SCell with beam failure according to the available dynamic UL grant without performing BFR SR. However, if there is no available UL grant on the SpCell, the UE 205 may perform BFR SR (e.g., if BFR SR PUCCH is configured) or perform a RACH procedure on the SpCell (e.g., if BFR SR PUCCH is not configured). The UE 205 then waits for a UL grant on the SpCell.

[0062] In certain embodiments, the SCell BFR MAC CE may be prioritized over user plane data to speed up beam recovery in the SCell 125. For example, if the UE 205 is in a transmit power limited state and therefore power scaling must be applied to lower priority uplink transmissions, then within a given cell group (e.g., MCG or SCG), PUSCH transmissions on SpCell 123 are prioritized over PUSCH transmissions on SCell 125. Therefore, by including the BFR MAC CE only in the PUSCH of SpCell 123 and restricting the SCell BFR MAC CE from being multiplexed in the PUSCH of the SCell (where SCell 125 is any SCell in the cell group), the discarding of PUSCH transmissions including the SCell BFR MAC CE may be minimized.

[0063] As used herein, a master control node refers to a RAN node 211 that provides a control plane connection to the core network 140, for example, in the case of dual connectivity ("DC"). A RAN node 211 that has no control plane connection to the core network 140 but provides additional resources to the UE 205 (for example, in the case of DC) is referred to as a "secondary node". It should be noted that the service cells can be grouped together into one or more cell groups. The group of service cells associated with the master control node is referred to as a "master cell group" or "MCG". The MCG contains a PCell and optionally one or more SCells. A secondary cell group ("SCG") refers to a group of service cells associated with a secondary node, including a SpCell 123 (e.g., a PSCell) and optionally one or more SCells.

[0064] Under an MCG, there may be many cells, one of which is used to initiate initial access. This cell is called a PCell. It should be noted that the PCell and SCell in an MCG can be used together through carrier aggregation ("CA") technology. The PSCell is the "primary" cell of the SCG and is the cell used for initial access under the SCG. It should be noted that the PSCell and SCell in an SCG can be used together under CA. SpCell 123 refers to a PCell and / or a PSCell.

[0065] In one implementation of the second solution, if the UE 205 is power limited (i.e., if the total UE transmission power i of PUSCH or PUCCH or PRACH or SRS transmissions in the corresponding transmission occasion will exceed the configured maximum power Pcmax(i)), then from the power allocation perspective, PUSCH with BFR MAC-CE has the highest priority, except for PRACH transmission on PCell. Thus, the priority order (in descending order) may be: PRACH transmission on PCell>PUSCH with BFR MAC-CE>PUSCH with HARQ-ACK / SR or PUSCH with HARQ-ACK>PUCCH / PUSCH with CSI>PUSCH without HARQ-ACK / CSI>Aperiodic SRS>Periodic / Semi-persistent SRS or PRACH on SCell.

[0066] In another example, PUCCH / PUSCH with HARQ-ACK may have a higher priority than PUSCH with BFR MAC-CE. Here, the priority order (in descending order) may be: PRACH transmission on PCell>PUCCH / PUSCH with HARQ-ACK>PUSCH with BFR MAC-CE>PUCCH transmission with SR only>PUCCH / PUSCH with CSI>PUSCH without HARQ-ACK / CSI>Aperiodic SRS>Periodic / semi-persistent SRS or PRACH on SCell. According to yet another alternative, when power is limited, the UE may prioritize PUSCH with BFR MAC CE over PRACH transmission on PCell, i.e., PUSCH with BFR MAC has the highest priority in the priority order.

[0067] According to the third solution, if there are no valid PUCCH resources for the SCell BFR SR configuration and the UE 205 has no available UL resources for the transmission of the BFR MAC CE, the UE 205 may use any valid SR PUCCH resources configured for the UE 205. In one implementation of the third solution, in the case where the UE 205 does not have a BFR SR configuration, the UE 205 may use any valid SR PUCCH resources configured for the UE 205. In various embodiments, the BFR SR configuration includes a set of PUCCH resources for the SCell beam failure recovery request ("BFRQ").

[0068] In one implementation of the third solution, the UE 205 uses an SR configuration that provides the earliest available PUCCH resources for the case where the UE 205 does not have valid PUCCH resources for BFRSR. Alternatively, for the case where the UE 205 is not configured with a BFR SR configuration, the UE 205 may use some PUCCH resources of some pre-configured SR configurations (e.g., SR configurations associated with URLLC LCHs). Beneficially, for the case where the UE 205 does not have a BFR SR configuration and there is no available UL grant to send a BFR MAC CE, using one of the configured "regular" (data-related) SR configurations, i.e., an SR configuration associated with some LCH, instead of using a random access procedure for requesting UL resources will speed up the beam failure recovery request procedure.

[0069] It should be noted that the transmission of BFR SR / MAC CE is time critical. According to one implementation of the third solution, for the case where SCell BFR SR has been triggered and UE 205 has no available UL-SCH resources, the behavior of UE 205 is as follows: If there are valid PUCCH resources configured for BFR SR, then UE 205 uses the PUCCH resources for requesting PUSCH resources. However, if there are no valid PUCCH resources configured for BFR SR, then UE 205 may use any other valid PUCCH resources configured for SR for requesting PUSCH resources. For the case where UE 205 does not have any valid PUCCH resources, then UE 205 initiates a RACH procedure to request PUSCH resources.

[0070] In one embodiment of the third solution, when the UE 205 has valid PUCCH resources (BFR SR PUCCH resources, or any other valid PUCCH resources configured for SR) and available UL-SCH resources starting after the start of the valid PUCCH resources, the UE 205 selects whether to transmit PUCCH or PUSCH corresponding to the available UL-SCH depending on the time gap between the start of the valid PUCCH resources and the start of the PUSCH. In one example, if the time gap is greater than a threshold, then the UE 205 transmits the PUCCH, otherwise the UE 205 transmits the PUSCH with the BFR MAC CE. In one example, the time gap threshold may be based on the UL HARQ RTT timer, or configured by a higher layer. The available UL-SCH resources may correspond to a valid PUSCH associated with a UL grant, which is received at least at a specific time interval or cutoff time before the start of the valid PUCCH resources. The cutoff time may be related to the CSI processing time, or configured by a higher layer.

[0071] According to the fourth solution, the UE 205 is configured by the network, wherein the SR configuration is configured for data-related BSR / SR triggering, such as the SR configuration corresponding to the logical channel, for sending the SCell BFR SR. According to one embodiment of the fourth solution, the BFR SR can be mapped to the SR configuration to which the logical channel can also be mapped, that is, the SR configuration corresponds to one or more LCHs and the SCell BFR SR. Beneficially, by allowing the logical channel as well as the SCell BFR SR to be mapped to the SR configuration, the need to have a separate SR configuration just for the purpose of the SCell BFR SR is avoided. Therefore, the SCell BFRSR can be regarded as a virtual LCH from a configuration perspective. It should be noted that the fourth solution can be regarded as an extension of the third solution.

[0072] According to the fifth solution, the UE 205 considers that the SCell beam failure recovery procedure is successfully completed when a dynamic UL grant is received, and the dynamic UL grant is scheduled for a new transmission of the HARQ process on which the SCell BFR MAC CE was previously sent. In one embodiment of the fifth solution, the UE 205 is restricted to send the SCell BFR MAC CE only on the UL-SCH resources allocated by the dynamic UL grant, that is, the UE 205 is not allowed to send the SCell BFR MAC CE on the configured granted resources. By introducing this restriction, the following situation is avoided: in which the UE 205 has an UL grant indicating a new transmission for the HARQ process on which the SCell BFR MAC CE is sent (after the configuredGrantTimer expires), even if the UL transmission containing the SCell BFR MAC CE is not received by the RAN node 211. Therefore, the criterion for successfully completing the SCell beam failure recovery procedure is to receive a dynamic UL grant indicating a new transmission, such as a PDCCH / DCI addressed to the C-RNTI, i.e., a switched NDI.

[0073] According to the sixth solution, the UE 205 (re)triggers the SCell BFR SR (if there is no available UL grant) or indicates the multiplexing and assembly procedure to generate the SCell BFR MAC CE (if there is an available UL grant) when the SCell BFR timer expires. This new timer (referred to as the "SCell BFR timer") defines the time period during which the UE 205 monitors the reception of a BFR response message, for example, an UL grant indicating a new transmission of a HARQ process for transmitting the SCell BFR MAC CE thereon. In various embodiments, the UE 205 starts the SCell BFR timer and may restart the SCell BFR timer at each HARQ retransmission in the first symbol after the end of the SCell BFR MAC CE transmission or in the first symbol after the end of the SCell BFR SR transmission. According to one implementation of the sixth solution, when the SCell BFR timer is running, the UE 205 is in the DRX active time.

[0074] According to the seventh solution, a BFR SR configuration including PUCCH resources for SCell beam failure recovery request ("BFRQ") and parameters related to the SCell BFR SR procedure may be configured on SpCell 123 or PUCCH SCell (i.e., SCell configured with RRC parameter 'PUCCH-Config'). In one embodiment, the parameters related to the SCell BFR SR procedure include 'bfr-sr-ProhibitTimer' and 'bfr-sr-TransMax', where the UE 205 starts bfr-sr-ProhibitTimer within the MAC entity of the UE 205, instructing the physical layer of the UE 205 to signal the BFR SR on one valid PUCCH resource for BFR SR, and bfr-sr-TransMax is the maximum number of BFR SR transmissions for a given BFR SR procedure. Note here that the seventh solution may be considered as an extension of the sixth solution.

[0075] According to the eighth solution, if UE 205 receives a BFR SR configuration that configures PUCCH resources on a PUCCH SCell (e.g., for PUCCH load balancing across cells) instead of on SpCell 123, and the number of BFR SR transmissions on the PUCCH SCell reaches the maximum allowed BFR SR transmission (i.e., the value of bfr-sr-TransMax), then UE 205 transmits the BFR SR using the regular (logical channel-related) SR configuration / PUCCH resources configured for UE 205 on SpCell 123 (i.e., if SR is configured on SpCell 123), or performs a random access procedure on SpCell 123 (i.e., if SR is not configured on SpCell 123). In one embodiment of the eighth solution, the random access procedure on SpCell 123 is a contention-based random access. In another embodiment of the eighth solution, UE 205 is configured with a dedicated PRACH preamble for BFR SR.

[0076] According to the ninth solution, for the case where UE 205 transmits a regular (LCH-related) SR on SpCell 123 and a SCell BFR SR on PUCCH SCell within the overlapping duration, UE 205 prioritizes the PUCCH containing the regular SR on SpCell 123 over the PUCCH containing the BFR SR on the PUCCH SCell, for example, for power scaling.

[0077] Figure 4 A user equipment device 400 that can be used for SCell beam failure recovery according to an embodiment of the present disclosure is depicted. In various embodiments, the user equipment device 400 is used to implement one or more of the solutions described above. The user equipment device 400 may be an embodiment of the remote unit 105 and / or UE 205 described above. In addition, the user equipment device 400 may include a processor 405, a memory 410, an input device 415, an output device 420, and a transceiver 425.

[0078] In some embodiments, input device 415 and output device 420 are combined into a single device, such as a touch screen. In some embodiments, user equipment apparatus 400 may not include any input device 415 and / or output device 420. In various embodiments, user equipment apparatus 400 may include one or more of: processor 405, memory 410, and transceiver 425, and may not include input device 415 and / or output device 420.

[0079] As depicted, transceiver 425 includes at least one transmitter 430 and at least one receiver 435. Here, transceiver 425 communicates with one or more cells supported by one or more base units 121, including a PCell and at least one SCell. In addition, transceiver 425 may support at least one network interface 440 and / or an application interface 445. Application interface 445 may support one or more APIs. Network interface 440 may support 4GPP reference points, such as Uu and PC5. As will be appreciated by one of ordinary skill in the art, other network interfaces 440 may be supported.

[0080] In one embodiment, the processor 405 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 405 may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), or a similar programmable controller. In some embodiments, the processor 405 executes instructions stored in the memory 410 to perform the methods and routines described herein. The processor 405 is communicatively coupled to the memory 410, the input device 415, the output device 420, and the transceiver 425.

[0081] In various embodiments, the processor 405 controls the user equipment device 400 to implement the UE behavior described above. For example, via the transceiver 425, the processor 405 receives an SR configuration from a network entity in the wireless communication network (i.e., from a gNB in ​​the RAN). Here, the SR configuration includes a set of PUCCH resources, wherein the SR configuration corresponds to one or more logical channels. In some embodiments, the processor 405 receives a configuration from the network entity indicating that the SCell BFR is mapped to the SR configuration.

[0082] In some embodiments, receiving the SR configuration includes receiving a BFR SR configuration including PUCCH resources for SCell BFRQ and including parameters related to the SCell BFR SR procedure. In one embodiment, the BFR SR configuration is configured on one of the following: a primary cell and a primary secondary cell (i.e., on SpCell 123). In another embodiment, the BFR SR configuration is configured on a different SCell (i.e., an SCell configured with the RRC parameter 'PUCCH-Config').

[0083] The processor 405 detects that a beam failure procedure has been triggered for the SCell. The processor 405 triggers an SR for the SCell BFR in response to determining that there are no UL-SCH resources available for a new transmission of the beam failure MAC CE. The processor 405 transmits the SR on the PUCCH resources configured by the SR in response to triggering the SR for the SCell BFR. In some embodiments, transmitting the SR on the PUCCH resources configured by the SR includes sending the BFR SR using any valid SR PUCCH resources configured for the UE in response to determining that there are no valid PUCCH resources configured for the SCell BFR SR. In some embodiments, the processor 405 ignores the received UL grant that allocates resources on the SCell 125 until the BFR procedure 130 is successfully completed.

[0084] In some embodiments, the processor 405 further determines in response that UL resource allocation is available for new transmission after the SR has been transmitted. Here, the UL resource allocation is associated with a HARQ process and controls the transceiver to transmit a beam failure MAC CE on the allocated uplink resources. It should be noted that the UL resource allocation for the new transmission is later in time than the SR transmission allocation. For example, the network entity (i.e., gNB) allocates UL resources in response to receiving the SR from the UE.

[0085] In some embodiments, the processor 405 receives (i.e., via the transceiver 425) a dynamic UL grant that schedules a new transmission for the HARQ process on which the beam failure MAC CE is transmitted. The processor 405 determines the successful completion of the BFR procedure 130 in response to the receipt of the dynamic UL grant. In such embodiments, the dynamic UL grant includes a DCI addressed to the C-RNTI of the UE, wherein the dynamic UL grant has an NDI that is switched compared to a reference NDI for the HARQ process.

[0086] In some embodiments, the processor 405 transmits a beam failure MAC CE for the SCell 125 according to the available dynamic uplink grant in response to determining that there are UL-SCH resources available for new transmission. In some embodiments, the processor 405 prevents the beam failure MAC CE from being sent on semi-persistently scheduled uplink resources (i.e., NR configured grants).

[0087] In some embodiments, if the BFR procedure 130 is not successfully completed when the SCell BFR timer expires, the processor 405 re-triggers the SR for the SCell BFR. In some embodiments, transmitting the SR on the SR configured PUCCH resources includes if SR resources are configured on SpCell 123, SpCell 123 is one of the primary cell and the primary secondary cell, then transmitting the BFR SR using the SR configuration or PUCCH resources on SpCell 123, and if SR resources are not configured on SpCell 123, then performing a RACH procedure on SpCell 123.

[0088] In various embodiments, the processor 405 may detect a beam failure of the SCell and initiate a beam failure recovery (“BFR”) procedure. In certain embodiments, the processor 405 ignores any received UL grants that allocate resources on the SCell until the BFR is successfully completed. In certain embodiments, the processor 405 controls the transceiver 425 to transmit a BFR MAC CE for the SCell 125 based on the available dynamic UL grant without transmitting a BFR scheduling request. In certain embodiments, the processor 405 uses any valid SR PUCCH resources configured for the device in response to determining that there are no valid PUCCH resources for the SCell BFR SR configuration. In certain embodiments, the device 400 is configured by a network with an SR configuration to send a SCell BFR SR.

[0089] In some embodiments, the processor 405 determines that the BFR procedure 130 is successfully completed upon receiving a dynamic uplink grant that schedules a new transmission for the HARQ process of the SCell 125. In certain embodiments, the processor 405 re-triggers the SCell BFR SR upon expiration of the SCell BFR timer. In one embodiment, if SR resources are configured on the SpCell 123, the processor 405 controls the transceiver 425 to transmit a BFR scheduling request (“SR”) using the SR configuration or PUCCH resources on the special cell (“SpCell”) 123. In another embodiment, if SR resources are not configured on the SpCell 123, the processor 405 performs a random access (“RACH”) procedure on the SpCell 123.

[0090] In one embodiment, memory 410 is a computer-readable storage medium. In some embodiments, memory 410 includes volatile computer storage media. For example, memory 410 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 410 includes non-volatile computer storage media. For example, memory 410 may include a hard drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 410 includes both volatile and non-volatile computer storage media.

[0091] In some embodiments, the memory 410 stores data related to SCell beam failure recovery. For example, the memory 410 may store BFR resource configuration, SR configuration, and the like. In some embodiments, the memory 410 also stores program code and related data, such as an operating system or other controller algorithm operating on the device 400.

[0092] In one embodiment, input device 415 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, or the like. In some embodiments, input device 415 may be integrated with output device 420, for example, as a touch screen or similar touch-sensitive display. In some embodiments, input device 415 includes a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 415 includes two or more different devices, such as a keyboard and a touch panel.

[0093] In one embodiment, output device 420 is designed to output visual, audible, and / or tactile signals. In some embodiments, output device 420 includes an electronically controllable display or a display device capable of outputting visual data to a user. For example, output device 420 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, or the like to a user. As another non-limiting example, output device 420 may include a wearable display that is separate from but communicatively coupled to the rest of user equipment apparatus 400, such as a smart watch, smart glasses, a heads-up display, or the like. In addition, output device 420 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0094] In some embodiments, output device 420 includes one or more speakers for producing sound. For example, output device 420 can produce an audible alarm or notification (e.g., a beep or buzzer). In some embodiments, output device 420 includes one or more tactile devices for producing vibration, motion, or other tactile feedback. In some embodiments, all or part of output device 420 can be integrated with input device 415. For example, input device 415 and output device 420 can form a touch screen or similar touch-sensitive display. In other embodiments, output device 420 can be located near input device 415.

[0095] The transceiver 425 includes at least a transmitter 430 and at least one receiver 435. The one or more transmitters 430 may be used to provide UL communication signals to the base unit 121, such as the UL transmissions described herein. Similarly, the one or more receivers 435 may be used to receive DL communication signals from the base unit 121, as described herein. Although only one transmitter 430 and one receiver 435 are illustrated, the user equipment device 400 may have any suitable number of transmitters 430 and receivers 435. Furthermore, the transmitter 430 and the receiver 435 may be any suitable type of transmitter and receiver. In one embodiment, the transceiver 425 includes a first transmitter / receiver pair for communicating with a mobile communication network via a licensed radio spectrum, and a second transmitter / receiver pair for communicating with a mobile communication network via an unlicensed radio spectrum.

[0096] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network via a licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via an unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip that performs functions in conjunction with the use of both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, some of the transceivers 425, transmitters 430, and receivers 435 may be implemented as physically separate components that access shared hardware resources and / or software resources, such as, for example, a network interface 440.

[0097] In various embodiments, one or more transmitters 430 and / or one or more receivers 435 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system on a chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters 430 and / or one or more receivers 435 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as a network interface 440 or other hardware components / circuits may be integrated into a single chip with any number of transmitters 430 and / or receivers 435. In this embodiment, the transmitters 430 and receivers 435 may be logically configured as transceivers 425 using one or more common control signals, or logically configured as modular transmitters 430 and receivers 435 implemented in the same hardware chip or multi-chip module.

[0098] Figure 5 An embodiment of a network equipment device 500 that can be used for SCell beam failure recovery according to an embodiment of the present disclosure is described. In some embodiments, the network device 500 may be an embodiment of a RAN node and its supporting hardware, such as the base unit 121, RAN node 211 and / or gNB described above. In addition, the network equipment device 500 may include a processor 505, a memory 510, an input device 515, an output device 520, and a transceiver 525. In some embodiments, the network equipment device 500 does not include any input device 515 and / or output device 520.

[0099] As depicted, the transceiver 525 includes at least one transmitter 530 and at least one receiver 535. Here, the transceiver 525 communicates with one or more remote units 105. In addition, the transceiver 525 can support at least one network interface 540 and / or an application program interface 545. The application program interface 545 can support one or more APIs. The network interface 540 can support 3GPP reference points such as Uu, N1, N2, and N3. As understood by one of ordinary skill in the art, other network interfaces 540 can be supported.

[0100] In one embodiment, the processor 505 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 505 may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), or a similar programmable controller. In some embodiments, the processor 505 executes instructions stored in the memory 510 to perform the methods and routines described herein. The processor 505 is communicatively coupled to the memory 510, the input device 515, the output device 520, and the transceiver 525.

[0101] In various embodiments, the processor 505 controls the network equipment device 500 to implement the RAN node behavior described above. For example, the processor 505 can support one or more serving cells serving the UE, including PCell and / or SCell. In various embodiments, the transceiver 525 can receive BFRQ, as described herein. In addition, the processor 505 can allocate UL-SCH resources to the UE, as described herein.

[0102] In one embodiment, the memory 510 is a computer-readable storage medium. In some embodiments, the memory 510 includes a volatile computer storage medium. For example, the memory 510 may include a RAM, including a dynamic RAM ("DRAM"), a synchronous dynamic RAM ("SDRAM") and / or a static RAM ("SRAM"). In some embodiments, the memory 510 includes a non-volatile computer storage medium. For example, the memory 510 may include a hard drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 510 includes both volatile and non-volatile computer storage media. In some embodiments, the memory 510 stores data related to SCell beam failure recovery, such as storing UE identification, BFR resource configuration, SR configuration, resource authorization, and the like. In certain embodiments, the memory 510 also stores program code and related data, such as an operating system ("OS") or other controller algorithm and one or more software applications operating on the network equipment device 500.

[0103] In one embodiment, input device 515 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, or the like. In some embodiments, input device 515 may be integrated with output device 520, for example, as a touch screen or similar touch-sensitive display. In some embodiments, input device 515 includes a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 515 includes two or more different devices, such as a keyboard and a touch panel.

[0104] In one embodiment, output device 520 may include any known electronically controllable display or display device. Output device 520 may be designed to output visual, audible, and / or tactile signals. In some embodiments, output device 520 includes an electronic display capable of outputting visual data to a user. Furthermore, output device 520 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0105] In some embodiments, output device 520 includes one or more speakers for producing sound. For example, output device 520 can produce an audible alarm or notification (e.g., a beep or buzzer). In some embodiments, output device 520 includes one or more tactile devices for producing vibration, motion, or other tactile feedback. In some embodiments, all or part of output device 520 can be integrated with input device 515. For example, input device 515 and output device 520 can form a touch screen or similar touch-sensitive display. In other embodiments, all or part of output device 520 can be located near input device 515.

[0106] As discussed above, the transceiver 525 can communicate with one or more remote units and / or with one or more network functions that provide access to one or more PLMNs. The transceiver 525 operates under the control of the processor 505 to transmit messages, data, and other signals, and also receive messages, data, and other signals. For example, the processor 505 can selectively activate the transceiver (or portions thereof) at specific times in order to send and receive messages.

[0107] The transceiver 525 may include one or more transmitters 530 and one or more receivers 535. In some embodiments, the one or more transmitters 530 and / or the one or more receivers 535 may share transceiver hardware and / or circuitry. For example, the one or more transmitters 530 and / or the one or more receivers 535 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, and the like. In one embodiment, the transceiver 525 implements multiple logical transceivers using different communication protocols or protocol stacks while using common physical hardware.

[0108] Figure 6 One embodiment of a method 600 for SCell beam failure recovery according to an embodiment of the present disclosure is depicted. In various embodiments, the method 600 is performed by a UE, such as the remote unit 105, UE 205, and / or user equipment device 400 described above. In some embodiments, the method 600 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0109] The method 600 starts and receives 605 an SR configuration from a wireless communication network. Here, the SR configuration includes a set of PUCCH resources, wherein the SR configuration corresponds to one or more logical channels. The method 600 includes detecting 610 that a beam failure recovery procedure has been triggered for an SCell in the wireless communication network. The method 600 includes triggering 615 an SR for SCell beam failure recovery in response to determining that there are no UL-SCH resources available for a new transmission of a beam failure MAC CE. The method 600 includes transmitting 620 an SR on the PUCCH resources of the SR configuration in response to triggering the SR for SCell beam failure recovery. The method 600 ends.

[0110] Disclosed herein is a first device for SCell beam failure recovery according to an embodiment of the present disclosure. The first device may be implemented by a UE, such as the remote unit 105, UE 205 and / or user equipment device 400 described above. The first device includes a transceiver that communicates with the SCell in a wireless communication network. The first device includes a processor that receives an SR configuration from the wireless communication network, the SR configuration including a set of PUCCH resources, wherein the SR configuration corresponds to one or more logical channels. The processor detects that a beam failure procedure has been triggered for the SCell. The processor triggers a scheduling request for SCell beam failure recovery in response to determining that there are no UL-SCH resources available for new transmission of a beam failure MAC CE. The processor transmits an SR on the PUCCH resources of the SR configuration in response to the scheduling request that triggers SCell beam failure recovery.

[0111] In some embodiments, the processor receives a configuration from the wireless communication network indicating that SCell beam failure recovery is mapped to the SR configuration. In some embodiments, the processor further determines that UL resource allocation is available for new transmission in response to the transmission of a scheduling request. Here, the UL resource allocation is associated with a HARQ process and controls the transceiver to transmit a beam failure MAC CE on the allocated uplink resources.

[0112] In some embodiments, the processor receives (i.e., via the transceiver) a dynamic UL grant that schedules a new transmission for a HARQ process on which a beam failure MAC CE is transmitted. The processor determines successful completion of a beam failure recovery procedure in response to receipt of the dynamic UL grant. In such embodiments, the dynamic UL grant includes a DCI addressed to the C-RNTI of the UE, wherein the dynamic UL grant has an NDI that is switched compared to a reference NDI for the HARQ process.

[0113] In some embodiments, receiving the SR configuration includes receiving a beam failure recovery SR configuration including PUCCH resources for SCell BFRQ and including parameters related to the SCell beam failure recovery SR procedure. In one embodiment, the beam failure recovery SR configuration is configured on one of the following: a primary cell and a primary secondary cell (i.e., on SpCell 123). In another embodiment, the beam failure recovery SR configuration is configured on a different SCell (i.e., an SCell configured with the RRC parameter 'PUCCH-Config').

[0114] In some embodiments, transmitting the SR on the SR configured PUCCH resources includes sending the beam failure recovery SR using any valid SR PUCCH resources configured for the UE in response to determining that there are no valid PUCCH resources configured for the SCell beam failure recovery SR. In some embodiments, the processor ignores received UL grants that allocate resources on the SCell until the beam failure recovery procedure is successfully completed.

[0115] In some embodiments, the processor transmits a beam failure MAC CE for the SCell in accordance with an available dynamic uplink grant in response to determining that there are UL-SCH resources available for new transmissions. In some embodiments, the processor prevents the beam failure MAC CE from being sent on semi-persistently scheduled uplink resources (i.e., NR configured grants).

[0116] In some embodiments, if the beam failure recovery procedure is not successfully completed when the SCell beam failure recovery timer expires, the processor re-triggers SR for SCell beam failure recovery. In some embodiments, if SR resources are configured on SpCell 123, SpCell 123 is one of the primary cell and the primary and secondary cells, then transmitting SR on the PUCCH resources configured by SR includes transmitting a beam failure recovery scheduling request using the SR configuration or PUCCH resources on SpCell 123, and if SR resources are not configured on SpCell 123, then a RACH process is performed on SpCell 123.

[0117] Disclosed herein is a first method for SCell beam failure recovery according to an embodiment of the present disclosure. The first method may be performed by a UE, such as the remote unit 105, the UE 205, and / or the user equipment device 400 described above. The first method includes receiving an SR configuration from a wireless communication network, the SR configuration including a set of PUCCH resources, wherein the SR configuration corresponds to one or more logical channels. The first method includes detecting that a BFR procedure 130 has been triggered for an SCell 125 in the wireless communication network. The first method includes triggering a scheduling request for SCell BFR in response to determining that there are no UL-SCH resources available for a new transmission of a beam failure MAC CE, and transmitting an SR on the PUCCH resources of the SR configuration in response to triggering the scheduling request for SCell beam failure recovery.

[0118] In some embodiments, the first method includes receiving a configuration from a wireless communication network indicating that SCell beam failure recovery is mapped to an SR configuration. In some embodiments, the first method includes determining that UL resource allocation is available for new transmission in response to transmission of a scheduling request. Here, the UL resource allocation is associated with a HARQ process and a beam failure MAC CE is transmitted on the allocated uplink resources.

[0119] In certain embodiments, the first method further includes receiving a dynamic UL grant that schedules a new transmission for a HARQ process on which the beam failure MAC CE is transmitted, and determining successful completion of the beam failure recovery procedure in response to receiving the dynamic UL grant. In such embodiments, the dynamic UL grant may include a DCI addressed to the C-RNTI of the UE, wherein the dynamic UL grant has a switched NDI (i.e., compared to a reference NDI for the HARQ process).

[0120] In some embodiments, receiving the SR configuration includes receiving a BFR SR configuration including PUCCH resources for SCell BFRQ and including parameters related to the SCell BFR SR procedure. In one embodiment, the BFR SR configuration is configured on one of the following: a primary cell and a primary secondary cell (i.e., on SpCell 123). In another embodiment, the BFR SR configuration is configured on a different SCell (i.e., an SCell configured with the RRC parameter 'PUCCH-Config').

[0121] In some embodiments, transmitting the SR on the SR configured PUCCH resources includes sending the beam failure recovery SR using any valid SR PUCCH resources configured for the UE in response to determining that there are no valid PUCCH resources configured for the SCell beam failure recovery SR. In some embodiments, the first method includes ignoring a received UL grant that allocates resources on the SCell until the beam failure recovery procedure is successfully completed.

[0122] In some embodiments, the first method includes transmitting a beam failure MAC CE for the SCell according to an available dynamic uplink grant in response to determining that there are UL-SCH resources available for new transmission. In certain embodiments, the first method also includes preventing the beam failure MAC CE from being sent on semi-persistently scheduled uplink resources (i.e., configured grants). In some embodiments, the first method includes re-triggering the SR for SCell beam failure recovery if the beam failure recovery procedure is not successfully completed when the SCell beam failure recovery timer expires.

[0123] In some embodiments, if SR resources are configured on SpCell 123, and SpCell 123 is one of the primary cell and the primary secondary cell, then transmitting SR on the SR-configured PUCCH resources includes transmitting a beam failure recovery scheduling request on SpCell 123 using the SR configuration or PUCCH resources, and if SR resources are not configured on SpCell 123, then a RACH process is performed on SpCell 123.

[0124] Embodiments may be practiced in other specific forms. The described embodiments will be considered in all respects as illustrative and non-restrictive only. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method for a user to equip a UE, comprising: receiving a scheduling request SR configuration, the SR configuration comprising a set of physical uplink control channel PUCCH resources, wherein the SR configuration corresponds to one or more logical channels; receiving an indication indicating that a secondary cell SCell beam failure recovery is mapped to the SR configuration; Detecting that a beam failure recovery procedure has been triggered for the SCell; triggering a SR for beam failure recovery of the SCell in response to no uplink shared channel UL-SCH resources available for new transmission of a beam failure media access control MAC control element MAC-CE; and The SR is transmitted on the PUCCH resources of the SR configuration in response to triggering the SR for the SCell beam failure recovery.

2. The method according to claim 1, further comprising: determining, in response to the transmission of the SR, that an uplink (UL) resource allocation is available for a new transmission, wherein the UL resource allocation is associated with a hybrid automatic repeat request (HARQ) process; and A beam failure MAC-CE is transmitted on the allocated uplink resources.

3. The method according to claim 2, further comprising: receiving a dynamic UL grant scheduling a new transmission for the HARQ process on which the beam failure MAC-CE was transmitted; and Successful completion of a beam failure recovery procedure is determined in response to receipt of the dynamic UL grant.

4. The method of claim 3, wherein the dynamic UL grant comprises downlink control information (DCI) addressed to a cell-specific radio network temporary identifier (C-RNTI) of the UE, wherein the dynamic UL grant has a new data indicator (NDI) switched compared to a reference NDI for the HARQ process.

5. The method according to claim 1, wherein receiving the SR configuration includes receiving a beam failure recovery SR configuration, the beam failure recovery SR configuration includes a PUCCH resource for an SCell beam failure recovery request BFRQ, and includes parameters related to the SCell beam failure recovery SR procedure. The method according to claim 5 , wherein the beam failure recovery (SR) configuration is configured on one of a primary cell and a primary-secondary cell. The method according to claim 5 , wherein the beam failure recovery (SR) configuration is configured on different SCells.

8. The method according to claim 1, wherein transmitting the SR on the PUCCH resource of the SR configuration includes sending the beam failure recovery SR using any valid SR PUCCH resource configured for the UE in response to determining that there is no valid PUCCH resource configured for the SCell beam failure recovery SR.

9. The method according to claim 1, further comprising: Ignore received uplink UL grants allocating resources on the SCell until the beam failure recovery procedure is successfully completed.

10. The method according to claim 1, further comprising: The beam failure MAC control element for the SCell is transmitted according to an available dynamic uplink grant in response to determining that there are UL-SCH resources available for a new transmission.

11. The method according to claim 10, further comprising: Preventing the beam failure MAC control element from being sent on semi-persistently scheduled uplink resources.

12. The method according to claim 1, further comprising: If the beam failure recovery procedure is not successfully completed when the SCell beam failure recovery timer expires, the SR is re-triggered for SCell beam failure recovery.

13. The method according to claim 1, wherein transmitting the SR on the PUCCH resource of the SR configuration comprises: If SR resources are configured on a special cell SpCell, and the SpCell is one of a primary cell and a primary secondary cell, a beam failure recovery SR is transmitted on the SpCell using the SR configuration or PUCCH resources; and If SR resources are not configured on the SpCell, a random access RACH procedure is performed on the SpCell.

14. A user equipment UE, comprising: A transceiver, which communicates with the secondary cell SCell; and A processor that: receiving a scheduling request SR configuration, the SR configuration comprising a set of physical uplink control channel PUCCH resources, wherein the SR configuration corresponds to one or more logical channels; receiving an indication indicating that SCell beam failure recovery is mapped to the SR configuration; detecting that a beam failure recovery procedure has been triggered for the SCell; triggering a SR for beam failure recovery of the SCell in response to no uplink shared channel UL-SCH resources available for new transmission of a beam failure media access control MAC control element MAC-CE; and The SR is transmitted on the PUCCH resources of the SR configuration in response to triggering the SR for the SCell beam failure recovery.

15. The UE of claim 14, wherein the processor further: determining, in response to the transmission of the SR, that an uplink (UL) resource allocation is available for a new transmission, wherein the UL resource allocation is associated with a hybrid automatic repeat request (HARQ) process; and A beam failure MAC-CE is transmitted on the allocated uplink resources.

16. The UE of claim 15, wherein the processor further: receiving a dynamic UL grant scheduling a new transmission for the HARQ process on which the beam failure MAC-CE was transmitted; and Successful completion of a beam failure recovery procedure is determined in response to receipt of the dynamic UL grant.

17. The UE of claim 16, wherein the dynamic UL grant comprises downlink control information (DCI) addressed to a cell-specific radio network temporary identifier (C-RNTI) of the UE, wherein the dynamic UL grant has a new data indicator (NDI) switched compared to a reference NDI for the HARQ process.

18. The UE of claim 14, wherein receiving the SR configuration comprises: Receive the beam failure recovery SR configuration, which contains the PUCCH resources for the SCell beam failure recovery request BFRQ and contains parameters related to the SCell beam failure recovery SR procedure.

Images