Protocol for beamwidth control

Abstract

Techniques for beamwidth control and devices and components including apparatuses, systems, and methods for beamwidth control are described herein.

Description

[0001] Cross-references to other applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 393,783, filed on July 29, 2022, entitled “PROTOCOL FOR BEAM WIDTH CONTROL,” which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] The present application relates to wireless technologies, and in particular to techniques for beamwidth control. Background Art

[0004] The 3rd Generation Partnership Project (3GPP) Technical Specifications (TS) define standards for wireless networks. These TSs describe certain beam management and beam failure recovery procedures for operating within such networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 A network environment according to some embodiments is shown.

[0006] Figure 2 Dependence of coverage probability on base station beamwidth in a terahertz (THz) network according to some embodiments is illustrated.

[0007] Figure 3 Examples of the P-1 process, the P-2 process, and the P-3 process are illustrated.

[0008] Figure 4 A scenario is shown in which the probability of beam failure is reduced due to a change in the position of a UE according to some embodiments.

[0009] Figure 5 A scenario is shown in which the probability of beam failure due to a change in orientation of a UE is reduced according to some embodiments.

[0010] Figure 6 A scenario is shown in which the probability of beam failure due to dynamic blocking is reduced according to some embodiments.

[0011] Figure 7 An operational flow / algorithm structure according to some embodiments is illustrated.

[0012] Figure 8 A message sequence chart of a process for beamwidth control according to some embodiments is shown.

[0013] Fig. 9A and Fig. 9BTwo examples of the format of the BEAM_WIDTH_REQ signal according to some embodiments are shown.

[0014] Fig. 10A and Fig. 10B Two examples of the format of the BEAM_WIDTH_CONFIG signal are shown according to some embodiments.

[0015] Fig.11 A message sequence chart illustrating an example of a process for beamwidth control according to some embodiments.

[0016] Fig.12 A scene including the presence of a reflective surface is shown according to some embodiments.

[0017] Fig.13 An operational flow / algorithm structure according to some embodiments is illustrated.

[0018] Fig.14 An example scenario is illustrated in which a base station serves multiple user equipment in a given space in accordance with some embodiments.

[0019] Fig.15 An operational flow / algorithm structure according to some embodiments is illustrated.

[0020] Fig.16 An example of a joint loop of power control and beamwidth control according to some embodiments is illustrated.

[0021] Fig.17 A message sequence chart of a process for joint beamwidth and transmit power control according to some embodiments is shown.

[0022] Fig.18 A message sequence chart illustrating an example of a process for joint beamwidth and transmit power control according to some embodiments.

[0023] Fig.19 An operational flow / algorithm structure according to some embodiments is illustrated.

[0024] Fig. 20 An operational flow / algorithm structure according to some embodiments is illustrated.

[0025] Fig.21 An operational flow / algorithm structure according to some embodiments is illustrated.

[0026] Fig. 22 An operational flow / algorithm structure according to some embodiments is illustrated.

[0027] Fig.23 A beamforming component of a device according to some embodiments is illustrated.

[0028] Fig.24 User equipment according to some embodiments is illustrated.

[0029] Fig.25 A base station according to some embodiments is illustrated. DETAILED DESCRIPTION

[0030] The following specific embodiments relate to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as specific structures, architectures, interfaces, technologies, etc., are described for the purpose of illustration rather than limitation, so as to provide a thorough understanding of various aspects of various embodiments. However, it is obvious to those skilled in the art who benefit from the present disclosure that various aspects of various embodiments can be practiced in other examples that deviate from these specific details. In some cases, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the descriptions of various embodiments due to unnecessary details. For the purposes of this document, the phrase "A or B" refers to (A), (B), or (A and B). For the purposes of this document, the phrase "A is based on B" means "A is at least based on B".

[0031] The following is a glossary of terms that may be used in this disclosure.

[0032] As used herein, the term "circuit" refers to, is part of, or includes a hardware component such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or a memory (shared, dedicated, or group) configured to provide the described functionality, an application specific integrated circuit (ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high capacity PLD (HCPLD), a structured ASIC, or a programmable system on a chip (SoC)), a digital signal processor (DSP), etc. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements and a program code for executing the functionality of the program code (or a combination of circuits used in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a specific type of circuit.

[0033] As used herein, the term "processor circuit" refers to, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transferring digital data. The term "processor circuit" may refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional processes).

[0034] As used herein, the term "interface circuit" refers to, is a part of, or includes a circuit that enables information exchange between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, a network interface card, etc.

[0035] As used herein, the term "user equipment" or "UE" refers to a device that has radio communication capabilities and can describe a remote user of network resources in a communication network. In addition, the terms "user equipment" or "UE" may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. In addition, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0036] As used herein, the term "computer system" refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or networked resources.

[0037] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a specific device, such as a computer device, a mechanical device, a memory space, a processor / CPU time, a processor / CPU usage, a processor and accelerator load, a hardware time or usage, a power supply, an input / output operation, a port or a network socket, a channel / link allocation, throughput, memory usage, storage, a network, a database and an application, a unit of work, etc. "Hardware resources" may refer to computing, storage or network resources provided by physical hardware elements. "Virtualized resources" may refer to computing, storage or network resources provided by a virtualized infrastructure to an application, a device, a system, etc. The term "network resources" or "communication resources" may refer to resources that a computer device / system can access via a communication network. The term "system resources" may refer to any kind of shared entity that provides a service, and may include computing resources or network resources. System resources may be considered as a set of coherent functions, network data objects or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0038] As used herein, the term "channel" refers to any tangible or intangible transmission medium for communicating data or data streams. The term "channel" may be synonymous or equivalent to "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "link", "data link", "carrier", "radio frequency carrier" or any other similar term representing a path or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection made between two devices for sending and receiving information.

[0039] As used herein, the terms "instantiate," "instantiate," and the like refer to the creation of an instance. "Instance" also refers to a concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0040] The term "connected" may mean that two or more elements at a common communication protocol layer have an established signaling relationship with each other through a communication channel, link, interface, or reference point. The term "obtain" is used to indicate any of its ordinary meanings, such as calculating, deriving, receiving (e.g., from another element or device) and / or retrieving (e.g., from a memory / storage device as described below). The term "determine" is used to indicate any of its ordinary meanings, such as calculating, deriving, and / or selecting.

[0041] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure for providing wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as a networked computer, networking hardware, network equipment, network node, virtualized network function, etc.

[0042] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual contents of an information element, or a data element that contains the contents. An information element may include one or more additional information elements.

[0043] Techniques for beamwidth control are described herein, including techniques for bidirectional control signaling and techniques for joint beamwidth and power control. Figure 1 A network environment 100 according to some embodiments is illustrated. The nodes in such a network environment 100 may include one or more UEs 104a-104e and one or more access points, such as, for example, access nodes 108 and 112. The UEs 104a-104e may communicate with the access nodes 108 and 112 via an air interface compatible with 3GPP TS (such as those defining long term evolution (LTE) or fifth generation (5G) new radio (NR) system standards) (e.g., via an NR-Uu interface), as shown, for example, with reference to UEs 104c, 104d, and 104e. Each access node 108 and 112 may provide one or more 5G new radio (NR) cells to provide NR user plane and control plane protocol terminations to the UEs 104a-104e. Each access node 108 and 112 may be a base station such as a next generation Node B (gNB), or may be controlled by it. Additionally or alternatively, each of the UEs 104a-104e may communicate (e.g., via a sidelink) with one or more of the other UEs 104a-104e, as illustrated, for example, with reference to UEs 104a, 104b, and 104c.

[0044] Access nodes 108 and 112 may send information (e.g., data and control signaling) in the downlink direction by mapping logical channels onto transport channels and mapping transport channels onto physical channels. Logical channels may transfer data between the radio link control (RLC) layer and the medium access control (MAC) layer; transport channels may transfer data between the MAC layer and the physical (PHY) layer; and physical channels may transfer information across the air interface.

[0045] UEs 104a-104e may communicate with access nodes 108 / 112 and / or with each other via frequency bands in frequency range 1 (FR1) or frequency range 2 (FR2). For FR1 (e.g., below 7.225 GHz), the transmit antennas of UEs 104a-104e are typically implemented as omnidirectional antennas. For FR2 (e.g., 24.250 GHz and above, also known as millimeter waves), the transmit antennas of UEs 104a-104e may be implemented as panels with multiple antenna elements. For example, the multiple antenna elements of the panel may be driven as a phased array (e.g., to steer a beam in a desired direction).

[0046] The carrier frequencies of communication systems have been continuously increased to provide more bandwidth for achieving high-speed data transmission. Current 5G NR systems may use carrier frequencies ranging from approximately 25 GHz to 100 GHz in the millimeter wave bands (30 GHz-300 GHz), and are considering the use of carriers in the THz bands (0.1 THz-10 THz). Transmissions in such high frequency bands may be expected to experience increased propagation losses. Such losses may be compensated by using beamforming techniques, where narrow beams are used to focus the transmit power in the direction of interest. Figure 1 An example of such beamforming is shown, where a node at each end of a communication link transmits through a narrow beam (depicted as a solid curve). A beam management protocol may include monitoring beam quality and switching to another beam of the beam configuration when conditions change (depicted as a dashed curve). For example, a receiving node may indicate to a transmitting node that the quality of another beam is approaching or has become greater than the quality of a current beam (which may occur due to, for example, movement of the node or a change in the propagation path between the nodes), and in response, the transmitting node may switch to another beam.

[0047] However, the use of narrow beams brings new challenges, which may include reduced robustness to uncertainties such as obstruction, mobility, interference, and channel fluctuations. Such challenges may become particularly problematic when, for example, the node is unaware that such uncertainties currently exist on the other side of the link. Current standards do not provide effective solutions to these challenges.

[0048] Techniques as described herein may be used to implement dynamic control of beamwidth and power based on transmit / receive requirements. Such requirements may be based on, for example, device state (which may include one or more of a node's speed, orientation, direction of movement, etc.), environmental state (which may include the presence, movement, or other state of each of one or more of obstructions, nearby reflective surfaces, repeaters, etc.), or application parameters (which may include one or more of broadcast configuration, privacy issues, security issues, etc.). Techniques as described herein may be implemented for the purpose of optimizing beamwidth and power, for example, which may offset one or more challenges as described above by, for example, actively balancing coverage, throughput, and / or privacy of communications in a dynamic environment.

[0049] Potential advantages of such techniques may include any of the following: adapting traditional beam management frameworks for refining narrow beams; enhancing robustness of network coverage; improving performance in the presence of reflective surfaces; optimizing performance based on upper layer application requirements. Uses of such techniques as described herein include, for example, an on-demand beamwidth control protocol and an on-demand joint beamwidth and power control framework that can be integrated with existing (e.g., 5G NR) power control loops.

[0050] Optimized beam width can significantly improve the performance of the communication system in many scenarios. For example, beam misalignment can occur due to the mobility of the node (such as changes in one or more of the node's speed, direction of movement, or orientation). For example, the orientation of a UE (e.g., a smart phone, wearable device, UAV, etc.) can change due to the rotation of the device. When beam misalignment occurs, using optimized beam width can significantly enhance coverage.

[0051] Figure 2 The dependence of coverage probability on BS beamwidth in terahertz (THz) networks is illustrated, and example scenarios are included in which optimized beamwidth can significantly mitigate the coverage probability loss due to beam misalignment. In the figure, the top curve represents the scenario without beam misalignment, where the BS beamwidth is three degrees. The other two curves represent the scenario with beam misalignment where the BS beamwidth is also three degrees and the scenario with beam misalignment where the BS beamwidth is nine degrees (in each of these two cases, the beam misalignment is randomly distributed in the range from negative two degrees to positive two degrees). Figure 2 As shown, given a particular SINR coverage threshold (e.g., 10 dB), beam misalignment reduces the coverage probability by more than 40% (the difference indicated by the long vertical range line). However, even in the presence of beam misalignment, using a wider beam can recover most of this loss by increasing the coverage probability by about 25% (the difference indicated by the shorter vertical range line).

[0052] Traditional beam management protocols usually support beam width refinement in a network-controlled manner. For example, Section 6.1.6.1 of 3GPP Technical Report 38.802 (“3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Studies on Physical Layer Aspects of New Radio Access Technologies (Release 14)”, v14.2.0 (2017-09)) describes a set of downlink L1 / L2 beam management procedures for 5G NR, which include: Figure 3 The P-1 process, P-2 process, and P-3 process depicted in FIG. In the P-1 process, both the BS and the UE sweep through all of their beams to determine the initial alignment. In the P-2 process, which occurs after the P-1 process has been completed, the BS sweeps through several narrow beams to identify the refined beam, and in the P-3 process, the BS causes the UE to do the same.

[0053] Such procedures may suffer from high protocol overhead and increased power consumption at both the UE and the BS when beam misalignment occurs. At least in most cases, performing the P-1, P-2, and P-3 procedures results only in narrower beams and not in wider beams. Another potential disadvantage is that these procedures are controlled by the BS. Therefore, they do not provide link protection in scenarios that are not detected by the BS. Such scenarios may include, for example, mobility of the UE, or obstructions or other effects in the UE's local environment that result in path loss.

[0054] The UE-initiated beam failure recovery (BFR) protocol for 5G NR is described in Sections 8.5.1 to 8.5.4 and 8.5.7 of 3GPP TS 38.133 (“5G; NR; Requirements for support of radio resource management (3GPP TS 38.133 Version 17.5.0 Release 17),” v17.5.0 (2022-05)) and Section 6 of 3GPP TS 38.213 (“5G; NR; Physical layer procedures for control (3GPP TS 38.213 Version 17.2.0 Release 17),” v17.2.0 (2022-07)). According to the BFR protocol, after the UE has detected a beam failure (e.g., reference signal received power (RSRP) is below a threshold), the UE locally reselects a beam and reports it to the BS. However, the 5G NR BFR protocol is reactive in nature and does not preempt link failures in uncertain environments.

[0055] As described above, narrow beams can be used in high frequency bands to focus power and compensate for high path loss. However, when the propagation channel changes dynamically due to mobility, rotation, and / or obstruction, the use of narrow beams can weaken the link robustness and thereby reduce network coverage, such as Figures 4 to 6 This is illustrated in the example scene of .

[0056] Figure 4 1 shows a scenario of loss of coverage due to the mobility of UE 104d. At the beginning, the access node 108 serves UE 104d with a narrow beam 404. When UE 104d starts to move at a relatively high speed (e.g., in a car), it may travel beyond the coverage of the current beam before the next periodic or aperiodic beam measurement occurs, resulting in a beam failure. Although 5G NR supports recovery from such beam failures using the BFR protocol, the reselection process in the protocol may consume a lot of UE power and may also cause service delays. However, if the BS uses a wider beam 408, such as Figure 4 As shown, the probability of beam failure will be reduced, thereby making the link more robust to the mobility of UE 104d (e.g., more tolerant to high UE speeds).

[0057] Figure 5 1 shows a scenario where coverage is lost due to a change in orientation (e.g., rotation) of UE 104d during use of a narrow beam. Figure 5 As shown, indoor environments typically contain abundant non-line-of-sight (NLOS) multipath components, which are likely to be weaker than corresponding line-of-sight (LOS) components. When a LOS path is available for a static UE 104d, a typical strategy is to align narrow beams (beams 504 and 512) along the LOS path on both the BS and UE sides to provide optimal data rates. The sudden rotation of UE 104d can significantly misalign UE beam 512 and BS beam 504, resulting in beam failures as shown. However, in an abundant multipath environment, there is still a considerable probability that misaligned UE beam 516 points to some scatterers or reflective surfaces (e.g., walls) that can provide NLOS paths, and the misalignment probability can be reduced by using a wider beam 508 at the access node 108. In this scenario, a wider BS beam 508 may be able to provide coverage for such NLOS paths. Although the total channel gain of the NLOS path and the wide beam 508 may be lower than that of the LOS path with the narrow beam 504, the link may still support some low-rate services rather than having a complete outage.

[0058] Figure 6 A scenario is shown in which coverage may be lost due to dynamic blockages during use of a narrow beam (e.g., beam 604). It is known that high-frequency signals suffer high penetration losses when passing through blockers, such as human bodies. When blockages occur in an indoor environment with rich multipath, potential NLOS paths may exist around the blockers, which may be utilized to maintain connectivity. However, when the beams are narrow and the blockers are constantly moving (e.g., people moving along a hallway, moving cars traveling on a busy road), utilizing such NLOS paths may require frequent beam changes, which may increase UE power consumption. Employing wider beams at each node (e.g., beam 608 at access node 108 and beam 616 at UE 104d) may help cover multiple path directions at once. For example, in an indoor environment such as FIG. Figure 6 In the illustrated scenario, even if the LOS path is suddenly blocked by the dynamic blocking block 624, the access node 108 can still use the same wide beam 608 to send data to the UE 104d at a lower rate via the NLOS path, which in turn reduces the probability of link interruption. A wider beam also allows the same beam to be used in a changing environment: for example, the availability of various multipaths within the beam coverage changes over time due to the movement of the dynamic blocking blocks 620, 624.

[0059] Figures 4 to 6The example scenario in illustrates the degradation of link robustness due to the use of narrow beams in current communication systems. Techniques as described below may be implemented to support dynamic control of beam width according to transmit / receive requirements. In general, adjustment of beam width according to such techniques may be applied to any arbitrary set of devices forming a communication link (e.g., a pair of nodes, where each node in the pair may be any one of a BS, a UE, an unmanned aerial vehicle (UAV) (e.g., a drone), a satellite, etc.).

[0060] In one example, a technique for beam width control includes determining, at a transmitting node, a transmit beam width based on information from a receiving node. Such information may include, for example, mobility information (e.g., orientation, speed, or direction of movement) of the receiving node. For situations where such mobility of the receiving node may otherwise result in link failures (e.g., as described above with reference to Figure 4 and Figure 5 Such techniques may provide increased robustness in the scenario described above.

[0061] The information from the receiving node may be based on information collected from one or more sensors of the receiving node. For example, the one or more sensors may include one or more accelerometers or gyroscopes (e.g., one or more gyrometers) of the receiving node, which may be included in an inertial measurement unit (IMU). The information from the receiving node may also include information from other sensors (e.g., information from images captured by a camera) and / or information from an application (e.g., a map application). Information may be received in an information element and / or in a message (e.g., in an uplink control information (UCI) or downlink control information (DCI) message). The receiving node providing its mobility information may be a UE (e.g., a smart phone, a wearable device, a UAV, etc.) or an access point (e.g., an access node or BS, which may be on the ground or on a non-ground (NTN) platform (such as a satellite or airborne platform)).

[0062] Additionally or alternatively, determining the transmit beam width may be based on the location of the blockage or the direction of movement of the blockage, which may also be indicated by the receiving node or may be otherwise determined from information from the receiving node. Such techniques may provide increased robustness for dynamic blockage scenarios (e.g., as described above with reference to Figure 6 In either case, the receiving node may request a beam width change by the sending node, and the request may be based on the knowledge of the current beam configuration of the sending node. The sending node may change its transmit power according to the beam width change.

[0063] Figure 7An operational flow / algorithm structure 700 according to some embodiments is illustrated. The operational flow / algorithm structure 700 may be performed or implemented by: a UE, such as, for example, any of UEs 104a-104e; or a component of a UE, such as, for example, baseband processor 2404A. The operational flow / algorithm structure 700 may be performed or implemented by: an access node, such as, for example, access node 108 or 112 or other access node; or a component of an access node, such as, for example, baseband processor 2504A.

[0064] The operation flow / algorithm structure 700 may include: receiving first information indicating at least one of an orientation of the second node, a speed of the second node, or a moving direction of the second node at 704. The first information may also indicate at least one of a location of a blockage or a moving direction of a blockage, for example.

[0065] The operational flow / algorithm structure 700 may include, at 708, determining a beam width based on the first information. Determining the beam width may also be based on at least one of a location of the obstruction or a direction of movement of the obstruction. Additionally or alternatively, determining the beam width may be based on second information from an image captured by a camera.

[0066] The operation flow / algorithm structure 700 may include, at 712, transmitting data to the second node via a beam based on the beam width. The transmit power of the data transmission may be based on the beam width. The operation flow / algorithm structure 700 may also include: obtaining a beamforming configuration from a codebook based on the beam width. Additionally or alternatively, the operation flow / algorithm structure 700 may also include: generating a request indicating a requested beam width change, wherein the requested beam width change may be based on third information indicating a beam configuration of the second node.

[0067] Optimization of the beamwidth for a link may depend on consideration of the needs of both end nodes in a timely manner. Although a signaling protocol that allows a transmitting node and a receiving node to exchange requests could be used for this purpose, such a protocol is not currently supported. In contrast to current beam management protocols, it may be desirable for such a protocol to accommodate bidirectional beamwidth control requests. For example, it may be desirable for a protocol to allow both a transmitting node and a receiving node to adjust each other's beamwidth based on local information that may not otherwise be available at the other node. Adjustment of the beamwidth may change the beamforming gain, and it may be desirable to account for such changes by integrating power control into the protocol.

[0068] The techniques described herein include, for example, an on-demand beamwidth control framework for robust coverage, an on-demand beamwidth control protocol, a general on-demand beamwidth and power control framework, and a joint on-demand beamwidth and power control protocol. Such techniques as a whole are applicable to all coverage scenarios in the various coverage scenarios presented herein, and such protocols may also support existing methods in which coarse beams are refined to create narrow beams to provide high throughput.

[0069] Figure 8 A message sequence chart (MSC) for a process 800 for beamwidth control is shown. Such processes described below in the context of a link between node 1 and node 2 (where each node may be a BS, UE, or any other node described herein) may utilize a protocol that supports bidirectional on-demand beamwidth control requests.

[0070] In block 804a, node 1 collects data to be used for beam width estimation. Such data may include, for example, any of the following: link statistics (e.g., one or more of reference signal received power (RSRP), reference signal received quality (RSRQ), or signal to interference and noise ratio (SINR)); beam configuration of another node (e.g., beam width); and information from node 1's own sensors and / or applications. The sensors from which information is collected may include one or more accelerometers and / or gyroscopes (e.g., gyrometers), which may provide basic geometric information, such as position, velocity, and orientation. The sensors from which information is collected may also include sensors that capture images or other information, such as cameras. The applications from which information is collected may include, for example, geographic mapping applications (e.g., Apple Maps). Node 1 may use the sensor and / or application information thus collected to identify mobility patterns and / or obstructions that may affect beam width selection. Node 1 may be configured to continuously collect such data (e.g., by responding to an interrupt generated by a sensor or an alert generated by an application; by polling a sensor or application at regular intervals; etc.). In block 804b, Node 2 may collect data to be used for beamwidth estimation in the same manner, given, for example, its own link statistics, sensors, and applications; Node 1's beam configuration (eg, beamwidth); and so on.

[0071] In block 808a, Node 1 estimates locally its own optimal beamwidth and the optimal beamwidth of Node 2. Such beamwidth estimates may be based on information inferred from the collected data, such as, for example, mobility patterns, obstructions, etc. In one example, the UE implementation of Node 1 calculates the optimal beamwidth for the BS implementation of Node 2 given its own speed, distance to the BS, and measured RSRP. In block 808b, Node 2 may also estimate locally its own optimal beamwidth and the optimal beamwidth of Node 1.

[0072] If node 1 has determined that the beam width of node 2 should be adjusted, then in block 812a, node 1 transmits a beam width control request BEAM_WIDTH_REQ to node 2 to adjust the beam width. Likewise, if node 2 has determined that the beam width of node 1 should be adjusted, then in block 812b, node 2 transmits a beam width control request BEAM_WIDTH_REQ to node 2 to adjust the beam width. The BEAM_WIDTH_REQ signal indicates the beam width change being requested (e.g., as an angle), and examples of corresponding signal formats for such requests are presented below.

[0073] After receiving the request from Node 1, Node 2 estimates its final beam width change in block 816b by combining the beam width change requested by Node 1 with Node 2's own local estimate from block 808b. For example, Node 2 may estimate its final beam width change as the maximum of the two values, or alternatively, as the average (e.g., geometric mean) of the two values. In block 816a, Node 1 estimates its new beam width in a similar manner.

[0074] In block 820a, node 1 determines its own beam set for selection, and in block 820b, node 2 determines its own beam set for selection. In blocks 824a and 824b, the two nodes schedule a beam training process with each other, where a new beam pair will be selected and used for future data transmission.

[0075] In blocks 828a and 828b, each node transmits a feedback signal BEAM_WIDTH_CONFIG to the other node to confirm the successful beam width adjustment and indicate its new beam configuration. If the beam width control process 800 is performed in an asymmetric manner (e.g., if only node 1 is to change its beam width), the same protocol may be employed, with the signal transmitted by node 2 indicating "no change".

[0076] The beam width control process 800 can be performed in parallel with the existing beam tracking protocol. In this case, when a node receives a beam width control request, it can use the updated beam width to perform beam measurement. On the other hand, since the process 800 also configures a beam training process, the training process can be used to track the beamforming direction in a timely manner and switch the beam accordingly.

[0077] Two signals BEAM_WIDTH_REQ and BEAM_WIDTH_CONFIG may be used to adjust the beam width control protocol, as described above with reference to process 800. The signal BEAM_WIDTH_REQ indicates the requested beam width change value, and Fig. 9A and Fig. 9BTwo non-limiting examples of the format of this signal are shown. Fig. 9A A table showing beam width change values ​​as indicated by the signal BEAM_WIDTH_REQ is shown for an example where BEAM_WIDTH_REQ is implemented as a four-bit signal b0b1b2b3, and Fig. 9B Tables of beamwidth change values ​​as indicated by signal BEAM_WIDTH_REQ are shown for an example where BEAM_WIDTH_REQ is implemented as a three-bit signal b0b1b2. In these tables, the beamwidth change indicates an angle in degrees, where a positive value indicates a corresponding increase in beamwidth and a negative value indicates a corresponding decrease in beamwidth.

[0078] The signal BEAM_WIDTH_CONFIG indicates the status of the beam width adjustment and the current beam width in degrees used (after beam width adjustment), and Fig. 10A and Fig. 10B Two non-limiting examples of the format of this signal are shown. Fig. 10A A table showing beam width values ​​as indicated by the signal BEAM_WIDTH_CONFIG, for an example where BEAM_WIDTH_CONFIG is implemented as a four-bit signal c0c1c2c3, and Fig. 10B Tables of beamwidth values ​​as indicated by signal BEAM_WIDTH_CONFIG are shown for an example where BEAM_WIDTH_CONFIG is implemented as a three-bit signal c0c1c2. In these tables, the beamwidth values ​​indicate angles in degrees, and the values ​​c0c1c2c3=0000 and c0c1c2=000 indicate a failure in beamwidth adjustment. Such failures may occur, for example, due to codebook design, power control, etc.

[0079] Fig.11 An example 1100 MSC for process 800 is shown, where Figure 8The illustrated on-demand beamwidth control protocol is applied to a scenario starting with node 2 transmitting to node 1 using an initial beamwidth of four degrees. At block 808a, node 1 estimates that node 2 should increase its beamwidth by five degrees in order to improve link robustness for node 1's mobility. At block 808b, node 2 determines that there is no need to change node 1's current beamwidth based on its collected information. At block 812a, node 1 transmits BEAM_WIDTH_REQ=110 to node 2 using a 3-bit signal format, and at block 812b, node 2 transmits BEAM_WIDTH_REQ=000. At block 816a, node 1 estimates that there is no need to change its own beamwidth, and at block 816b, node 2 estimates that a beam change of five degrees is to be made to its own beamwidth. Node 2 increases its own beamwidth by approximately five degrees via scheduled beam training at block 824b, and transmits a feedback signal BEAM_WIDTH_CONFIG=101 to node 1 at block 828b. A beamwidth change as applied by a node may be different from a beamwidth change as estimated by the node (and / or a beamwidth change as requested by another node) due to factors such as the node's beamforming architecture, the node's codebook design, etc., which may determine the specific beamwidth value that can be actually implemented at the node.

[0080] Can be achieved as mentioned above Figures 8 to 11 The described protocol supports on-demand beamwidth control request signals, which can allow the transmitting node and the receiving node to jointly optimize their beamwidths together to improve the link quality in a timely manner. Importantly, the beamwidth control requests in such protocols do not disclose any private data of each node (e.g., location, mobility state, etc.) to other nodes. Such protocols can also be fully implemented in their entirety to support beamwidth control based on service and application requirements. In addition, the beamwidth control protocol can be implemented as bidirectional and can therefore support almost any type of link (e.g., BS-UE uplink (UL) / downlink (DL); device-to-device (D2D) side link; UAV link, satellite link, etc.). In an example scenario in a cellular network, such bidirectionality can enable the UE to adjust the network beam settings according to the UE's own needs, making such protocols an important component of a UE-centric / service-centric network architecture.

[0081] As described herein (e.g., reference Figures 7 to 11 ) for beam width control can also be used in the presence of reflective surfaces. Fig.12As shown in the example of , the reflective surface 1220 can configure the propagation environment by providing additional paths. The reflective surface 1220 can be deployed indoors (e.g., mounted on a wall, behind a painting, at the corner of two corridors, etc.) or outdoors (e.g., on the side of a building, at an intersection, etc.), and can provide a reflection channel where there is no LOS path (e.g., an NLOS path via the reflective surface 1220). Such a surface can be implemented as a passive phased antenna array, but can be programmable or otherwise reconfigurable (e.g., a reconfigurable smart surface (RIS)). For example, the BS can program the RIS by transmitting a set of programmable weights to a controller (e.g., a microcontroller) of the RIS (e.g., via a side channel, such as LTE), which then configures the array according to the weights.

[0082] Fig.13 An operational flow / algorithm structure 1300 according to some embodiments is illustrated. The operational flow / algorithm structure 1300 may be performed or implemented by: a UE, such as, for example, any of UEs 104a-104e; or a component of a UE, such as, for example, baseband processor 2404A. The operational flow / algorithm structure 1300 may be performed or implemented by an access node (e.g., access node 108 or 112) or a component thereof (e.g., baseband processor 2504A).

[0083] The operational flow / algorithm structure 1300 may include, at 1304, receiving first information indicating a location of a node.

[0084] The operational flow / algorithm structure 1300 may include, at 1308, determining a beam width based on the first information and the position of the reflective surface. Determining the beam width may be based on a configuration of the reflective surface. The reflective surface may be a reconfigurable intelligent surface (RIS). The operational flow / algorithm structure 1300 may also include receiving second information indicating at least one of an orientation of the node, a speed of the node, or a direction of movement of the node, and determining the beam width may be based on the second information.

[0085] The operational flow / algorithm structure 1300 may include, at 1312, sending a data transmission to the node via a beam based on the beam width. The transmit power of the data transmission may be based on the beam width. The operational flow / algorithm structure 1300 may also include obtaining a beamforming configuration from a codebook based on the beam width. Additionally or alternatively, the operational flow / algorithm structure 1300 may also include receiving an incoming data transmission from the node, and sending a request to the node indicating a requested beam width change. For example, the operational flow / algorithm structure 1300 may include generating a request indicating a requested beam width change, wherein the requested beam width change may be based on third information indicating a beam configuration of the node.

[0086] When both LOS and reflection channels are available, transmitting signals simultaneously through both channels can enhance signal strength and provide orthogonality. Fig.12 As shown, wide beams 1208 and 126 can be used to transmit signals over two channels, which may not be feasible when using narrow beam 1204. One challenge in implementing wide beams is that in some cases only one of the nodes is aware of the reflective surface. For example, an access point (e.g., access node 108) may know the location of the reflective surface, but UE 104d may lack such information. The node that is aware of the reflective surface can use the information described above with reference to Figures 8 to 11 One or more techniques (eg, an on-demand beamwidth control protocol) are described to overcome this information gap by requesting another node to adjust its beamwidth accordingly. Thus, a node may also use the presence of a reflective surface to initiate a beamwidth adjustment.

[0087] As described herein (e.g., reference Figures 7 to 11 )The techniques discussed for beamwidth control can also be used to address upper layer requirements (e.g., from applications / services). Fig.14 An example scenario is illustrated in which an access node 108 serves multiple UEs 104c-104e in a given space (e.g., a room, a lecture hall, a concert venue) by distributing the same data (e.g., a video conference) to all UEs in the UEs 104c-104e. In this case, the data is not distributed to any other UE 1404, and therefore a secure multicast service with optimized beam width to protect privacy can be expected. Using the location information of the served UEs 104c-104e and the dimensions of a given room, the access node 108 can construct an appropriate wide beam 1408 for multicasting to all UEs 104c-104e. In one example, the UEs 104c-104e can first communicate with a side link to collect (e.g., aggregate) the location information of the side link, which can then be shared by one or more of the UEs 104c-104e with the access node 108. Such a wide multicast beam may also help avoid possible data theft by UE 1404 outside the field of view (FoV) of beam 1408. It may also be desirable to configure access node 108 to limit the transmit power of beam 1408 to avoid leakage beyond a given space (e.g., as indicated by the location of UEs 104c-104e). As described above (e.g., with reference to Figures 8 to 11 The on-demand beamwidth control protocol described in ) can also be applied to Fig.14 Example scenario.

[0088] Fig.15An operational flow / algorithm structure 1500 according to some embodiments is illustrated. The operational flow / algorithm structure 1500 may be performed or implemented by: an access node, such as, for example, access node 108 or 112 or other access node; or a component of an access node, such as, for example, baseband processor 2504A.

[0089] The operational flow / algorithm structure 1500 may include receiving, at an access point, first information indicating, for each node in a plurality of nodes, a location of the node, at 1504. Receiving the first information may include receiving the first information from a node in the plurality of nodes.

[0090] The operational flow / algorithm structure 1500 may include determining a beam width based on the first information, at 1508. Determining the beam width may be based on a location of a reflective surface (eg, a reconfigurable smart surface (RIS)).

[0091] The operation flow / algorithm structure 1500 may include: at 1512, the access point sends data to the node via a beam based on the beam width. The transmission power of the data transmission may be based on the first information. The operation flow / algorithm structure 1500 may also include: obtaining a beamforming configuration from a codebook based on the beam width.

[0092] Current communication systems (e.g., 5G NR) typically support closed-loop power control schemes to combat path loss, fading, and interference. Figures 8 to 11 ) with existing (e.g., 5G NR) power control protocols is not unimportant, since changing the beamwidth can significantly affect the received signal power.

[0093] Fig.16 An example of a joint loop of power control and beam width control is illustrated, where both the access node 108 and the UE 104 d control each other's transmit power for DL / UL transmission, and both devices simultaneously request control of each other's beam width to enhance link robustness. In this scenario, using a wider BS / UE beam (e.g., changing from beam 1604 to beam 1612 at the access node 108 and from beam 1608 to beam 1616 at the UE 104 d) will result in SNR loss. In order to maintain the quality of the link, it may be desirable to increase the transmit power to compensate for the reduction in beamforming gain caused by the increase in beam width. In one example, the transmit power is increased according to the relative change in beam width. In this case, the change in transmit power can be obtained from a gain value table, which is indexed by the relative change in beam width (e.g., by the value of (new beam width) / (old beam width)). In another example, a joint beamwidth and power control loop (eg, a joint loop of a beamwidth and transmit power control protocol) as described below can be used.

[0094] Fig.17 An MSC is shown of a process 1700 for joint beamwidth and transmit power control. Such processes described below in the context of a link between node 1 and node 2 (where each node may be a BS, UE, or any other node described herein) may utilize a protocol that supports a joint loop of bidirectional on-demand beamwidth requests and transmit power control. Fig.17 In the example of FIG. 5 , both node 1 and node 2 request beam width control of each other, and at the same time both nodes control DL / UL power to maintain the same link quality before and after beam width adjustment.

[0095] Process 1700 includes the following steps as described above with reference to Figure 8 Blocks 804a, 804b, 808a, 808b, 812a, 812b, 816a, and 816b of process 800 for beamwidth control are described. In process 1700, after block 816a, node 1 has estimated its new beamwidth, and after block 816b, node 2 has estimated its new beamwidth.

[0096] In block 1704a, node 1 estimates the effective isotropic radiated power (EIRP) and / or RSRP difference that will be caused by the change in beamforming gain based on its old beamwidth and the new beamwidth. Similarly, in block 1704a, node 2 estimates the EIRP and / or RSRP difference that will be caused by the change in beamforming gain based on its old beamwidth and the new beamwidth. In block 1708a, node 1 transmits the estimated power difference to node 2 as a value GAIN_DIFF_1, and in block 1708b, node 2 transmits the estimated power difference to node 1 as a value GAIN_DIFF_2. In this way, nodes 1 and 2 can exchange GAIN_DIFF_1 and GAIN_DIFF_2 values ​​via bidirectional power control requests to indicate the estimated end-to-end EIRP / RSRP difference using the proposed new beamwidth.

[0097] In blocks 1712a and 1712b, if the power constraints at the nodes allow, each of nodes 1 and 2 adjusts its transmit power by the value of max(0, -GAIN_DIFF_1 - GAIN_DIFF_2) (for DL / UL transmissions separately). Such power adjustments can compensate for potential end-to-end beamforming gain loss. Blocks 1712a and 1712b can be configured such that if (GAIN_DIFF_1 + GAIN_DIFF_2) > 0 (e.g., if the beamforming gain increases with the new beam width), the transmit power at each node will not be reduced. Such exceptions can help prevent interruptions before the new beam is used.

[0098] In block 1716a, node 1 performs one or more data transmissions to node 2, and in block 1716b, node 2 performs one or more data transmissions to node 1. In block 1720a, node 1 measures the received signal power RX_PWR_1 of node 2's transmission in block 1716b, and in block 1720b, node 2 measures the received signal power RX_PWR_2 of node 1's transmission in block 1716a. If node 1 determines in block 1724a that RX_PWR_1 is higher than or equal to threshold THRES1, and if node 2 determines in block 1724b that RX_PWR_2 is higher than or equal to threshold THRES2, each node will determine its own beam set for selection and schedule a beam training process with another node by executing blocks 820a and 824a and blocks 820b and 824b, respectively, as described above with reference to Figure 8 In this case, in block 1732a, node 1 transmits a BEAM_WIDTH_CONFIG signal with a "successful" configuration to node 2, and in block 1732b, node 2 transmits a BEAM_WIDTH_CONFIG signal with a "successful" configuration to node 1.

[0099] However, if node 1 determines in box 1724a that RX_PWR_1 is less than threshold THRES1, or if node 2 determines in box 1724b that RX_PWR_2 is less than threshold THRES2 (for example, if either node does not meet the bidirectional power control request), then at box 1728, the node detecting the fault will transmit a BEAM_WIDTH_CONFIG signal to the other node with the "faulty" configuration to terminate the beam width control process.

[0100] If neither node requires any beamwidth control, then the existing closed-loop power control scheme can remain valid. If the beamwidth control occurs in an asymmetric manner (e.g., if only one of the nodes indicates a change in its own beamwidth), then the closed-loop power control scheme described above can still be used. Fig.17 More specifically, even if a node's beamwidth control signal would indicate "no change", in the event that another node is changing its beamwidth, it may still be desirable for the node to adjust its transmit power accordingly.

[0101] Thresholds THRES1 and THRES2 may have different definitions. In one example, THRES1 is defined as follows: THRES1 = RX_PWR_1_ORIGINAL + RX_PWR_1_TOL, where RX_PWR_1_ORIGINAL is the original received power before beam width and power adjustment, and RX_PWR_1_TOL is a tolerance term. THRES2 may be defined similarly.

[0102] Fig.18 An example 1800 MSC for process 1700 is shown, where Fig.17 The illustrated joint on-demand beamwidth and transmit power control protocol is applied to a scenario starting with node 2 transmitting to node 1 using an initial beamwidth of four degrees (eg, as described above with reference to Fig.11 As described above). In example 1800: at box 808a, node 1 estimates that node 2 should increase its beam width by five degrees in order to improve the link robustness for the mobility of node 1; at box 808b, node 2 determines that there is no need to change the current beam width of node 1 based on the information collected by itself; at box 812a, node 1 transmits BEAM_WIDTH_REQ=110 to node 2 using a 3-bit signal format, and at box 812b, node 2 transmits BEAM_WIDTH_REQ=000; at box 816a, node 1 estimates that there is no need to change its own beam width, and at box 816b, node 2 estimates that a beam change of five degrees is required for its own beam width.

[0103] In example 1800, since node 1 has estimated that it does not need to change its own beam width, in block 1704a, node 1 estimates a GAIN_DIFF_1 value of zero. In block 1704b of example 1800, node 2 estimates the EIRP / RSRP difference between its old beam and its new beam, and in this example, assumes that the resulting value of GAIN_DIFF_2 is -4dB. Therefore, before performing a beam width adjustment, node 2 may require both itself and node 1 to increase the transmit power by 4dB. In block 1708a of example 1800, node 1 transmits an indication of the value of GAIN_DIFF_1 to node 2, and in block 1708b of example 1800, node 2 sends an indication of the value of GAIN_DIFF_2 to node 1.

[0104] In blocks 1712a and 1712b of example 1800, respectively, each of nodes 1 and 2 adjusts its transmit power by 4 dB if the power constraints at the nodes allow. In block 1716a of example 1800, node 1 performs one or more data transmissions to node 2, and in block 1716b of example 1800, node 2 performs one or more data transmissions to node 1. In block 1720a of example 1800, node 1 measures a received signal power RX_PWR_1 of node 2's transmission in block 1716b, and in block 1720b of example 1800, node 2 measures a received signal power RX_PWR_2 of node 1's transmission in block 1716a. If nodes 1 and 2 determine in blocks 1724a and 1724b of example 1800, respectively, that the receive power threshold is met (e.g., if both nodes do increase Tx power by 4 dB based on bidirectional measurements), node 2 will increase its own beamwidth by approximately five degrees (depending on its beamforming architecture, its codebook design, etc.) via scheduled beam training in block 824b of example 1800, and transmit a feedback signal BEAM_WIDTH_CONFIG=101 to node 1 in block 1732b of example 1800. However, if node 2 determines in block 1724b of example 1800 that the receive power threshold is not met (e.g., if node 1 increases its own transmit power by only, for example, 1 dB), node 2 will not adjust its own beamwidth and will transmit a different feedback BEAM_WIDTH_CONFIG=000 to node 1 in block 1728 of example 1800 to terminate the process.

[0105] Fig.19 An operational flow / algorithm structure 1900 according to some embodiments is illustrated. The operational flow / algorithm structure 1900 may be performed or implemented by: a UE, such as, for example, any of UEs 104a-104e; or a component of a UE, such as, for example, baseband processor 2404A. The operational flow / algorithm structure 1900 may be performed or implemented by: an access node, such as, for example, access node 108 or 112; or a component of an access node, such as, for example, baseband processor 2504A.

[0106] The operational flow / algorithm structure 1900 may include, at 1904, receiving, at a first node, a first incoming transmission from a second node.

[0107] The operation flow / algorithm structure 1900 may include measuring, at the first node, first information indicating at least one of a signal strength of a first incoming transmission, an orientation of the first node, a speed of the first node, or a moving direction of the first node, at 1908. The signal strength of the first incoming transmission may be at least one of a reference signal received power (RSRP), a reference signal received quality (RSRQ), or a signal to interference and noise ratio (SINR).

[0108] The operational flow / algorithm structure 1900 may include, at 1912, generating a request to the second node indicating a first requested beamwidth change, wherein the first requested beamwidth change is based on the first information. The first requested beamwidth change may be based on the second information indicating the beamwidth of the first incoming transmission. Additionally or alternatively, the first requested beamwidth change may include an angle (e.g., an angle specified in degrees). The operational flow / algorithm structure 1900 may include causing the first node to send the request to the second node.

[0109] The operational flow / algorithm structure 1900 may include receiving, at a first node, a request from a second node indicating a second requested beamwidth change; and sending an outgoing transmission based on a transmit beamwidth to the second node, wherein the transmit beamwidth is based on the second requested beamwidth change.

[0110] The operational flow / algorithm structure 1900 may include: determining a transmit beam width change based on third information indicating at least one of a signal strength of a first incoming transmission, a beam width of the first incoming transmission, an orientation of the first node, a speed of the first node, or a moving direction of the first node; and sending an outgoing transmission based on the transmit beam width to a second node, wherein the transmit beam width is based on the transmit beam width change. The operational flow / algorithm structure 1900 may also include: receiving, at the first node, from the second node, a request indicating a second requested beam width change, wherein the transmit beam width is based on the second requested beam width change.

[0111] Fig. 20 An operational flow / algorithm structure 2000 according to some embodiments is illustrated. The operational flow / algorithm structure 2000 may be performed or implemented by: a UE, such as, for example, any of UEs 104a-104e; or a component of a UE, such as, for example, baseband processor 2404A. The operational flow / algorithm structure 2000 may be performed or implemented by: an access node, such as, for example, access node 108 or 112; or a component of an access node, such as, for example, baseband processor 2504A.

[0112] The operational flow / algorithm structure 2000 may include, at 2004, sending, by the first node, a first outgoing transmission to the second node via a first beam based on a first beam width.

[0113] The operational flow / algorithm structure 2000 may include receiving, by the first node from the second node, a request indicating a first requested beamwidth change, at 2008. The first requested beamwidth change may include an angle (eg, an angle specified in degrees).

[0114] The operational flow / algorithm structure 2000 may include, at 2012, sending, by the first node, a second outgoing transmission to the second node via a second beam based on a second beam width, wherein the second beam width is based on the first requested beam width change. The first requested beam width change may be based on second information indicating a beam width of the first incoming transmission. Additionally or alternatively, the first requested beam width change may include an angle (e.g., an angle specified in degrees). The operational flow / algorithm structure 2000 may include causing the first node to send a request to the second node.

[0115] The operation flow / algorithm structure 2000 may also include: receiving, by the first node, an incoming transmission from the second node; measuring first information, the first information including at least one of a signal strength of the incoming transmission, an orientation of the first node, a speed of the first node, or a moving direction of the first node; determining a second requested beamwidth change based on the first information; and generating a request indicating the second requested beamwidth change. The signal strength of the incoming transmission may be at least one of RSRP, RSRQ, or SINR. The second requested beamwidth change may be based on second information indicating a beamwidth of the incoming transmission. The second beamwidth may be based on the second requested beamwidth change. The operation flow / algorithm structure 2000 may also include: causing the first node to send a request to the second node. Additionally or alternatively, the operation flow / algorithm structure 2000 may also include: obtaining a beamforming configuration from a codebook based on the second beamwidth.

[0116] Fig.21 An operational flow / algorithm structure 2100 according to some embodiments is illustrated. The operational flow / algorithm structure 2100 may be performed or implemented by: a UE, such as, for example, any of UEs 104a-104e; or a component of a UE, such as, for example, baseband processor 2404A. The operational flow / algorithm structure 2100 may be performed or implemented by: an access node, such as, for example, access node 108 or 112; or a component of an access node, such as, for example, baseband processor 2504A.

[0117] The operational flow / algorithm structure 2100 may include sending, by the first node and to the second node, a first request indicating a first requested beam width change, at 2104. The first requested beam width change may include an angle (e.g., an angle specified in degrees). The first requested beam width change may be based on at least one of an orientation of the first node, a speed of the first node, or a direction of movement of the first node.

[0118] The operational flow / algorithm structure 2100 may include receiving, by the first node and from the second node, a second request indicating a second requested beamwidth change, at 2108. The second requested beamwidth change may include an angle (e.g., an angle specified in degrees). The first requested beamwidth change may include a first angle, and the second requested beamwidth change may include a second angle.

[0119] The operational flow / algorithm structure 2100 may include, at 2112, sending, by the first node and to the second node, first information indicating a first power difference, wherein the first power difference is based on the first requested beamwidth change and the second requested beamwidth change.

[0120] The operation flow / algorithm structure 2100 may also include: determining an adjusted transmit power based on the first power difference; and sending, by the first node, a first data transmission at the adjusted transmit power and to the second node. The operation flow / algorithm structure 2100 may also include: receiving, by the first node and from the second node, second information indicating a second power difference, wherein the adjusted transmit power may be based on the second power difference.

[0121] The operational flow / algorithm structure 2100 may include: receiving, by the first node and from the second node, a second data transmission; measuring, by the first node, a received power of the second data transmission; and sending, by the first node and to the second node, beamwidth configuration information based on the received power. The beamwidth configuration information may be based on information from a codebook. The operational flow / algorithm structure 2100 may also include: determining, by the first node, a first beamwidth based on a first requested beamwidth change and a second requested beamwidth change, wherein the first power difference may be based on the first beamwidth, and the beamwidth configuration information may be based on the first beamwidth.

[0122] Fig. 22An operational flow / algorithm structure 2200 according to some embodiments is illustrated. The operational flow / algorithm structure 2200 may be performed or implemented by: a UE, such as, for example, any of UEs 104a-104e; or a component of a UE, such as, for example, baseband processor 2404A. The operational flow / algorithm structure 2200 may be performed or implemented by: an access node, such as, for example, access node 108 or 112; or a component of an access node, such as, for example, baseband processor 2504A.

[0123] The operational flow / algorithm structure 2200 may include, at 2204, sending, by the first node, a first transmission to the second node via a first beam based on a first beam width. The first information may indicate a requested beam width change, and the requested beam width change may include an angle (e.g., an angle specified in degrees). Additionally or alternatively, the first information may indicate at least one of an orientation of the second node, a speed of the second node, or a moving direction of the second node.

[0124] The operational flow / algorithm structure 2200 may include, at 2208, determining, by the first node and based on first information received from the second node, a second beamwidth.

[0125] The operational flow / algorithm structure 2200 may include, at 2212, determining, by the first node and based on the first beamwidth and the second beamwidth, a first power difference.

[0126] The operational flow / algorithm structure 2200 may include, at 2216, sending, by the first node to the second node, an indication of the first power difference.

[0127] The operation flow / algorithm structure 2200 may also include: transmitting a second transmission to the second node via a second beam based on the first beam width and at a first power based on the first power difference. In this case, the operation flow / algorithm structure 2200 may also include: receiving, by the first node and from the second node, second information indicating a second power difference, wherein the first power may be based on the second power difference.

[0128] The operational flow / algorithm structure 2200 may also include sending, by the first node, a third transmission to the second node via a third beam based on the second beam width and at a second power based on the first power difference.

[0129] The operational flow / algorithm structure 2200 may also include: by the first node: after sending an indication of the first power difference to the second node, receiving an incoming data transmission from the second node; measuring the received power of the incoming data transmission; and sending an indication of a beamwidth configuration based on the received power to the second node.

[0130] The operation flow / algorithm structure 2200 may also include obtaining, by the first node and based on the second beamwidth, a beamforming configuration from a codebook.

[0131] Fig.23 A receiving component 2300 of a device according to some embodiments is illustrated. The device may be, for example, any of the UEs 104a-104e or the access nodes 108 or 112. The receiving component 2300 may include a first antenna panel (i.e., panel 1 2304) and a second antenna panel (i.e., panel 2 2308). Each antenna panel may include a plurality of antenna elements.

[0132] The antenna panels may be coupled to corresponding analog beamforming (BF) components. For example, panel 1 2304 may be coupled to analog BF component 2312, and panel 2 2308 may be coupled to analog BF component 2316.

[0133] The analog BF components may be coupled to one or more radio frequency (RF) chains. For example, the analog BF component 2312 may be coupled to one or more RF chains 2320, and the analog BF component 2316 may be coupled to one or more RF chains 2324. The RF chain may amplify the received analog RF signal, down-convert the RF signal to baseband, and convert the analog baseband signal to a digital baseband signal that may be provided to the digital BF component 2328. The digital BF component 2328 may provide the baseband (BB signal) for further BB processing.

[0134] In various embodiments, control circuitry that may reside in a baseband processor may provide BF weights to analog / digital BF components to provide receive beams at corresponding antenna panels. These BF weights may be specified in a codebook and / or may be determined by the control circuitry based on received reference signals and corresponding quasi-co-location (QCL) / transmit configuration indication (TCI) information, as described, for example, in one or more 3GPP 5G NR TSs. In some embodiments, the BF weights may be phase shift values ​​provided to a phase shifter of an analog BF component 2312 or complex weights provided to a digital BF component 2328. In some embodiments, the BF components and antenna panels may operate together to provide a dynamically phased array capable of steering a beam in a desired direction.

[0135] In various embodiments, beamforming may include analog beamforming, purely digital beamforming, or hybrid analog-digital beamforming.Digital beamforming may utilize separate RF chains corresponding to antenna elements, respectively.

[0136] Although beamforming component 2300 describes receive beamforming, other embodiments may include a beamforming component that performs transmit beamforming in a similar manner.

[0137] Fig.24UE 2400 according to some embodiments is illustrated. UE 2400 may be similar to Figure 1 Any one of UE 104a-104e is UE of the present invention, and is basically interchangeable therewith.

[0138] UE 2400 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., microphone, carbon dioxide sensor, pressure sensor, humidity sensor, thermometer, motion sensor, accelerometer, laser scanner, fluid level sensor, inventory sensor, voltage / current meter, actuator, etc.), video monitoring / surveillance equipment (e.g., camera, camcorder, etc.), a wearable device (e.g., a smart watch), or a loose IoT device.

[0139] UE 2400 may include a processor 2404, an RF interface circuit 2408, a memory / storage 2412, a user interface 2416, a sensor 2420, a driver circuit 2422, a power management integrated circuit (PMIC) 2424, antenna structures 2426, and a battery 2428. The components of UE 2400 may be implemented as an integrated circuit (IC), a portion of an integrated circuit, a discrete electronic device or other module, logic component, hardware, software, firmware, or a combination thereof. Fig.24 The block diagram of UE 2400 is intended to show a high-level view of some of the components of UE 2400. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0140] Components of UE 2400 may be coupled to various other components via one or more interconnects 2432, which may represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, optical connection, etc., which allows various circuit components (on a common or different chip or chipset) to interact with each other.

[0141] The processor 2404 may include processor circuits such as a baseband processor circuit (BB) 2404A, a central processor unit circuit (CPU) 2404B, and a graphics processor unit circuit (GPU) 2404C. The processor 2404 may include any type of circuit or processor circuit that executes or otherwise operates computer-executable instructions (such as program codes, software modules, or functional processes from the memory / storage device 2412) to cause the UE 2400 to perform operations as described herein.

[0142] In some embodiments, the baseband processor 2404A can access the communication protocol stack 2436 in the memory / storage device 2412 to communicate through a 3GPP compatible network. Generally speaking, the baseband processor 2404A can access the communication protocol stack to: perform user plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and non-access layer. In some embodiments, the PHY layer operations may be performed in addition / alternatively by components of the RF interface circuit 2408.

[0143] The baseband processor 2404A may generate or process baseband signals or waveforms that carry information in a 3GPP-compatible network. In some embodiments, the waveforms used for NR may be based on cyclic prefix OFDM ("CP-OFDM") in the uplink or downlink, and discrete Fourier transform spread OFDM ("DFT-S-OFDM") in the uplink.

[0144] The memory / storage 2412 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 2436) that may be executed by one or more processors in the processor 2404 to cause the UE 2400 to perform various operations described herein. The memory / storage 2412 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 2400. In some embodiments, some of the memory / storage 2412 may be located on the processor 2404 itself (e.g., L1 cache and L2 cache), while other memory / storage 2412 is located outside the processor 2404 but is accessible via a memory interface. The memory / storage 2412 may include any suitable volatile or non-volatile memory, such as, but not limited to, 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 memory, or any other type of memory device technology.

[0145] The RF interface circuit 2408 may include a transceiver circuit and a radio frequency front end module (RFEM), which allows the UE 2400 to communicate with other devices through a radio access network. The RF interface circuit 2408 may include various elements arranged in a transmit path or a receive path. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuits, control circuits, etc.

[0146] In the receive path, the RFEM may receive the radiated signal from the air interface via the antenna structure 2426 and proceed to filter and amplify the signal (using a low noise amplifier). The signal may be provided to the transceiver's receiver, which down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 2404.

[0147] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the signal through a power amplifier before the RF signal is radiated across the air interface via the antenna structure 2426.

[0148] In various embodiments, the RF interface circuit 2408 may be configured to send / receive signals in a manner compatible with NR access technology.

[0149] The antenna structure 2426 may include antenna elements to convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. These antenna elements may be arranged into one or more antenna panels. The antenna structure 2426 may have antenna panels that are omnidirectional, directional, or a combination thereof to achieve beamforming and multiple input / multiple output communications. The antenna structure 2426 may include microstrip antennas, printed antennas manufactured on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna structure 2426 may have one or more panels that are designed for a specific frequency band including a band in FR1 or FR2.

[0150] The user interface 2416 includes various input / output (I / O) devices designed to enable the user to interact with the UE 2400. The user interface 2416 includes input device circuits and output device circuits. The input device circuit includes any physical or virtual components for accepting input, especially including one or more physical or virtual buttons (e.g., reset button), physical keyboard, keypad, mouse, touchpad, touch screen, microphone, scanner or headset, etc. The output device circuit includes any physical or virtual components for displaying information or otherwise delivering information (such as sensor readings, actuator positions or other similar information). The output device circuit may include any number or combination of audio or visual displays, especially including one or more simple visual outputs / indicators (e.g., binary state indicators (such as light emitting diodes "LEDs") and multi-character visual outputs) or more complex outputs (such as display devices or touch screens (e.g., liquid crystal displays "LCDs", LED displays, quantum dot displays, projectors, etc.)), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the UE 2400.

[0151] Sensor 2420 may include a device, module, or subsystem that is designed to detect events or changes in its environment and transmit information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, among others: an inertial measurement unit including an accelerometer, gyroscope, or magnetometer; a microelectromechanical system or nanoelectromechanical system including a 3-axis accelerometer, 3-axis gyroscope, or magnetometer; a liquid level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravity meter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; a microphone or other similar audio capture device; and the like.

[0152] The driver circuit 2422 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 2400. The driver circuit 2422 may include various drivers to allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the UE 2400. For example, the driver circuit 2422 may include: a display driver for controlling and allowing access to a display device, a touch screen driver for controlling and allowing access to a touch screen interface, a sensor driver for obtaining sensor readings of the sensor 2420 and controlling and allowing access to the sensor 2420, a driver for obtaining an actuator position of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0153] The PMIC 2424 can manage the power provided to various components of the UE 2400. Specifically, with respect to the processor 2404, the PMIC 2424 can control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0154] In some embodiments, the PMIC 2424 may control or otherwise be part of various power saving mechanisms of the UE 2400, including DRX, as discussed herein.

[0155] The battery 2428 can power the UE 2400, but in some examples, the UE 2400 can be installed in a fixed location and can have a power source coupled to the power grid. The battery 2428 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, the battery 2428 can be a typical lead-acid automobile battery.

[0156] Fig.25 An access node 2500 (e.g., a base station or gNB) according to some embodiments is illustrated. Access node 2500 may be similar to access node 108 or 112 and may be substantially interchangeable therewith.

[0157] The access node 2500 may include a processor 2504 , an RF interface circuit 2508 , a core network (CN) interface circuit 2512 , a memory / storage device circuit 2516 , and an antenna structure 2526 .

[0158] Components of access node 2500 may be coupled to various other components via one or more interconnects 2528 .

[0159] The processor 2504, RF interface circuit 2508, memory / storage circuit 2516 (including communication protocol stack 2510), antenna structure 2526 and interconnect 2528 may be similar to those of reference Fig.13 Like named elements are shown and described.

[0160] The CN interface circuit 2512 may provide connectivity to a core network (e.g., a 5GC network) using a 5th generation core network (5GC) compatible network interface protocol (such as a carrier Ethernet protocol) or some other suitable protocol. Network connectivity may be provided to / from the access node 2500 via optical fiber or wireless backhaul. The CN interface circuit 2512 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 2512 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0161] As described above, one aspect of the present technology is the collection and use of data available from specific and legitimate sources for beam width control. The present disclosure contemplates that, in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, location-based data, online identifiers, phone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information.

[0162] The present disclosure recognizes that the use of such personal information data in the present technology can be used to benefit users. For example, the personal information data can be used to reduce the probability of link failure.

[0163] The present disclosure envisions that entities responsible for collecting, analyzing, disclosing, transmitting, storing or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding the requirements of the industry or government that maintain user privacy. Such information about the use of personal data should be highlighted and easily accessible to users, and should be updated as the collection and / or use of data changes. The user's personal information should be collected only for legal use. In addition, such collection / sharing should only occur after receiving user consent or other legal basis specified in applicable law. In addition, such entities should consider taking any necessary steps to protect and safeguard access to such personal information data, and ensure that other entities with access to personal information data comply with the privacy policies and procedures of other entities. In addition, such entities can subject themselves to third-party assessments to prove that they comply with widely accepted privacy policies and practices. In addition, policies and practices should be adjusted for specific types of personal information data collected and / or accessed, and applied to applicable laws and standards, including considerations that are exclusive to jurisdictions that can be used to impose higher standards. For example, in the United States, collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0164] Notwithstanding the foregoing, the present disclosure also contemplates implementation schemes in which users selectively block the use or access to personal information data. That is, the present disclosure contemplates that hardware elements and / or software elements may be provided to prevent or block access to such personal information data. For example, the technology of the present invention may be configured to allow a user to "opt in" or "opt out" of collecting mobility data at any time during or after registration for a service. In yet another example, a user may choose to limit the length of time for maintaining mobility-associated data, or to completely block the transmission of mobility data. In addition to providing "opt-in" and "opt-out" options, the present disclosure also contemplates providing notifications related to access or use of personal information. For example, a user may be notified that mobility data will be provided to the network.

[0165] In addition, it is the intention of the present disclosure that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once the data is no longer needed, the risk can be minimized by limiting the collection of data and deleting the data. In addition, and when applicable, including in certain health-related applications, data de-identification can be used to protect the privacy of users. De-identification can be promoted when appropriate by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than at the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods such as differential privacy.

[0166] Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that various embodiments may also be implemented without access to such personal information data. That is, various embodiments of the present technology will not fail to function properly due to the lack of all or a portion of such personal information data. For example, content may be selected and delivered to a user based on aggregated non-personal information data or an absolute minimum amount of personal information, such as content that is disposed only on the user's device or other non-personal information that may be used for content delivery services.

[0167] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the following example section. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below. For another example, the circuits associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below in the example section.

[0168] Example

[0169] In the following sections, additional exemplary embodiments are provided.

[0170] Embodiment 1 includes a beam width control method, the method comprising: at a first node, receiving a first incoming transmission from a second node; measuring first information at the first node, the first information indicating at least one of a signal strength of the first incoming transmission, an orientation of the first node, a speed of the first node, or a moving direction of the first node; and generating a request to the second node indicating a first requested beam width change, wherein the first requested beam width change is based on the first information.

[0171] Embodiment 2 includes the method of embodiment 1 or some other example herein, wherein the signal strength of the first incoming transmission is at least one of RSRP, RSRQ, or SINR.

[0172] Embodiment 3 includes the method of any one of Embodiments 1-2 or some other embodiment herein, wherein the first requested beamwidth change is based on second information indicating a beamwidth of the first incoming transmission.

[0173] Embodiment 4 includes the method of any one of Embodiments 1 to 3 or some other embodiment herein, wherein the method further comprises causing the first node to send the request to the second node.

[0174] Embodiment 5 includes the method of any one of Embodiments 1-4 or some other embodiment herein, wherein the first requested beamwidth change is based on a position of a reflecting surface.

[0175] Embodiment 6 includes the method of any one of Embodiments 1-5 or some other embodiment herein, wherein the first requested beamwidth change comprises an angle.

[0176] Embodiment 7 includes the method of any one of Embodiments 1-6 or some other embodiment herein, wherein the first requested beamwidth change comprises an angle specified in degrees.

[0177] Embodiment 8 includes the method described in any one of Embodiments 1 to 7 or some other embodiment herein, wherein the method further comprises: receiving, at the first node, a request from the second node indicating a second requested beam width change; and sending an outgoing transmission based on a transmit beam width to the second node, wherein the transmit beam width is based on the second requested beam width change.

[0178] Embodiment 9 includes the method described in any one of Embodiments 1 to 7 or some other embodiment herein, wherein the method further comprises: determining a change in transmit beam width based on third information indicating at least one of a signal strength of a first incoming transmission, a beam width of the first incoming transmission, an orientation of the first node, a speed of the first node, or a moving direction of the first node; and sending an outgoing transmission based on the transmit beam width to a second node, wherein the transmit beam width is based on the transmit beam width change.

[0179] Embodiment 10 includes the method of embodiment 9 or some other embodiment herein, wherein the method further comprises: receiving, at the first node, a request from the second node indicating a second requested beam width change, and the transmit beam width is changed based on the second requested beam width.

[0180] Embodiment 11 includes a beam width control method, comprising: sending a first outgoing transmission by a first node to a second node via a first beam based on a first beam width; receiving a request by the first node from the second node indicating a first requested beam width change; and sending a second outgoing transmission by the first node to the second node via a second beam based on a second beam width, wherein the second beam width is based on the first requested beam width change.

[0181] Embodiment 12 includes the method of embodiment 11 or some other embodiment herein, wherein the transmit power of the second beam is changed based on the first requested beam width.

[0182] Embodiment 13 includes the method of any one of Embodiments 11-12 or some other embodiment herein, wherein the first requested beamwidth change comprises an angle.

[0183] Embodiment 14 includes the method of any one of Embodiments 11 to 13 or some other embodiment herein, wherein the first requested beamwidth change comprises an angle specified in degrees.

[0184] Embodiment 15 includes the method described in any one of Embodiments 11 to 14 or some other embodiment herein, wherein the method further includes: receiving, by a first node, an incoming transmission from a second node; measuring first information, the first information including at least one of a signal strength of the incoming transmission, an orientation of the first node, a speed of the first node, or a direction of movement of the first node; determining a second requested beam width change based on the first information; and generating a request indicating a second requested beam width change.

[0185] Embodiment 16 includes the method of embodiment 15 or some other example herein, wherein the signal strength of the incoming transmission is at least one of RSRP, RSRQ, or SINR.

[0186] Embodiment 17 includes the method of any one of Embodiments 15-16 or some other embodiment herein, wherein the second requested beamwidth change is based on second information indicating a beamwidth of the first incoming transmission.

[0187] Embodiment 18 includes the method of any one of Embodiments 15 to 17 or some other embodiment herein, wherein the method further comprises causing the first node to send the request to the second node.

[0188] Embodiment 19 includes the method of any one of Embodiments 15 to 18 or some other embodiment herein, wherein the second beamwidth is changed based on the second requested beamwidth.

[0189] Embodiment 20 includes the method of any one of Embodiments 11 to 19 or some other embodiment herein, wherein the method comprises: obtaining a beamforming configuration from a codebook based on the second beamwidth.

[0190] Embodiment 21 may include an apparatus comprising means for performing one or more elements of a method as described or related to any of Embodiments 1 to 20, or any other method or process described herein.

[0191] Embodiment 22 may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described or related to any one of Embodiments 1 to 20 or any other method or process described herein.

[0192] Embodiment 23 may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of a method as described or related to any of Embodiments 1 to 20, or any other method or process described herein.

[0193] Embodiment 24 may include methods, techniques or processes described in or related to any one of Embodiments 1 to 20, or parts or components thereof.

[0194] Embodiment 25 may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or a portion thereof, described in or related to any one of Embodiments 1 to 20.

[0195] Embodiment 26 may include a signal as described in or related to any one of Embodiments 1 to 20, or a portion or component thereof.

[0196] Embodiment 27 may include a datagram, information element, packet, frame, segment, PDU or message as described in or related to any one of Embodiments 1 to 20, or a portion or component thereof, or otherwise described in the present disclosure.

[0197] Embodiment 28 may include a signal encoded with data as described or associated with any one of Embodiments 1 to 20, or a portion or component thereof, or as otherwise described in this disclosure.

[0198] Embodiment 29 may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message as described in or related to any one of Embodiments 1 to 20, or a portion or component thereof, or otherwise described in the present disclosure.

[0199] Embodiment 30 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or a portion thereof, as described or related to any one of Embodiments 1 to 20.

[0200] Embodiment 31 may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process, or a portion thereof, as described or related to any one of Embodiments 1 to 20.

[0201] Embodiment 32 may include signals in a wireless network as shown and described herein.

[0202] Embodiment 33 may include a method of communicating in a wireless network as shown and described herein.

[0203] Embodiment 34 may include a system for providing wireless communications as shown and described herein.

[0204] Embodiment 35 may include an apparatus for providing wireless communications as shown and described herein.

[0205] Unless explicitly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in view of the above teachings or may be obtained from the practice of various embodiments.

[0206] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications.

Claims

1. A method for performing beam width control by a first node, the method comprising: receiving a first incoming transmission from a second node; measuring first information indicating at least one of a signal strength of the first incoming transmission, an orientation of the first node, a speed of the first node, or a direction of movement of the first node; as well as A request is generated to the second node indicating a first requested beamwidth change, wherein the first requested beamwidth change is based on the first information.

2. The method of claim 1, wherein the signal strength of the first incoming transmission is at least one of: a reference signal received power (RSRP), a reference signal received quality (RSRQ), or a signal to interference and noise ratio (SINR).

3. The method of any one of claims 1 or 2, wherein the first requested beamwidth change is based on second information indicative of the beamwidth of the first incoming transmission.

4. The method according to any one of claims 1 to 3, wherein the method further comprises causing the first node to send the request to the second node.

5. The method of any one of claims 1 to 4, wherein the first requested beamwidth change is based on a position of a reflecting surface.

6. The method of any one of claims 1 to 5, wherein the first requested beamwidth change comprises an angle.

7. The method of any one of claims 1 to 6, wherein the first requested beamwidth change comprises an angle specified in degrees.

8. The method according to any one of claims 1 to 7, wherein the method further comprises: receiving a request from the second node indicating a second requested beamwidth change; as well as An outgoing transmission based on a transmit beamwidth is sent to the second node, wherein the transmit beamwidth is changed based on the second requested beamwidth.

9. The method according to any one of claims 1 to 7, wherein the method further comprises: determining a transmit beamwidth change based on third information indicative of at least one of the signal strength of the first incoming transmission, the beamwidth of the first incoming transmission, the orientation of the first node, the speed of the first node, or the direction of movement of the first node; as well as An outgoing transmission based on a transmit beamwidth is sent to the second node, wherein the transmit beamwidth is changed based on the transmit beamwidth.

10. The method according to claim 9, wherein: The method also includes receiving, at the first node, a request from the second node indicating a second requested beamwidth change, and The transmit beamwidth is changed based on the second requested beamwidth.

11. One or more computer-readable media having instructions that, when executed by one or more processors, cause the first node to: sending a first outgoing transmission to a second node via a first beam based on a first beam width; receiving a request from the second node indicating a first requested beamwidth change; as well as A second outgoing transmission is sent to the second node via a second beam based on a second beamwidth, wherein the second beamwidth is changed based on the first requested beamwidth.

12. The one or more computer-readable media of claim 11, wherein a transmit power of the second beam is changed based on the first requested beamwidth.

13. The one or more computer-readable media of any one of claims 11 or 12, wherein the first requested beamwidth change comprises an angle.

14. The one or more computer-readable media of any one of claims 11 to 13, wherein the first requested beamwidth change comprises an angle specified in degrees.

15. One or more computer-readable media according to any one of claims 11 to 14, wherein the instructions, when executed by the one or more processors, further cause the first node to: receiving an incoming transmission from said second node; measuring first information, the first information comprising at least one of a signal strength of the incoming transmission, an orientation of the first node, a speed of the first node, or a direction of movement of the first node; determining a second requested beamwidth change based on the first information; as well as A request is generated indicating the second requested beamwidth change.

16. The one or more computer-readable media of claim 15, wherein the signal strength of the incoming transmission is at least one of: reference signal received power (RSRP), reference signal received quality (RSRQ), or signal-to-interference-and-noise ratio (SINR).

17. The one or more computer-readable media of any one of claims 15-16, wherein the second requested beamwidth change is based on second information indicative of a beamwidth of the incoming transmission.

18. The one or more computer-readable media of any one of claims 15 to 17, wherein the instructions, when executed by one or more processors, further cause the first node to send the request to the second node.

19. The one or more computer-readable media of any one of claims 15 to 18, wherein the second beamwidth is changed based on the second requested beamwidth.

20. The one or more computer-readable media of any one of claims 11 to 19, wherein the instructions, when executed by one or more processors, further cause the first node to obtain a beamforming configuration from a codebook based on the second beamwidth.

Images