System and method for sharing intelligent reflective surfaces (IRS) in a network
The system addresses the challenges of 5G/6G networks by using a network device to manage IRS resources, enabling efficient communication and resource sharing, and reducing the need for additional base stations, thus enhancing network performance and user experience.
Patent Information
- Application Number
- JP2023521943
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-03-31
- Filing Date
- 2023-03-24
- Publication Date
- 2025-04-22
AI Technical Summary
Existing 5G and 6G networks face challenges such as lack of control over the wireless channel and high power consumption, and they do not efficiently utilize available technologies like AI, terahertz communications, and IRS resources for optimal network performance and coverage.
The proposed system and method involve a network device that manages intelligent reflective surface (IRS) resources by sending scheduling data requests and responses between the IRS manager and network devices, allowing for the allocation and sharing of IRS resources between multiple base stations to improve communication efficiency and coverage.
This solution enables effective, simultaneous, and improved communication between base stations and user equipment (UEs) in 5G/6G networks, reduces the need for additional base station deployments, and provides economical next-generation network systems with enhanced user experience and IRS resource sharing capabilities.
Smart Images

Figure 2025512628000001_ABST
Abstract
Description
[Technical field]
[0001] Reservation of Rights Portions of the disclosure of this patent specification contain material that is subject to intellectual property rights, including but not limited to copyright, design, trademark, IC layout design, and / or trade dress protection, which belong to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred to as the Owner). The Owner has no objection to the reproduction by any person of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all and any rights. All rights with respect to such intellectual property are fully reserved by the Owner.
[0002] The present invention relates generally to IRS network architecture, and more particularly to sharing IRS resources in a communication network. [Background technology]
[0003] The following description of related art is intended to provide background information regarding the field of the present disclosure. This section may include certain aspects of the art that may be related to various aspects of the present disclosure. However, it should be understood that this section is used only to enhance the reader's understanding of the present disclosure and is not to be used as an admission of prior art.
[0004] Existing communication technologies (e.g., 5G) and future technologies (e.g., 6G) face two main practical limitations. First, there is a lack of control over the wireless channel, and second, the power consumption of the wireless interfaces associated with the network is high. To address the need for future cellular networks that are environmentally friendly and sustainable, the concept of reconfiguring the wireless propagation environment using Intelligent Reflective Surfaces (IRS) and Reconfigurable Intelligent Surfaces (RIS) has emerged in the last few years. A typical IRS architecture consists of many low-cost passive antennas that can smartly reflect impinging electromagnetic waves for improved performance.
[0005] 5G wireless technology being developed by 3GPP is intended to provide more users with higher multi-Gbps peak data rates, ultra-low latency, higher reliability, huge network capacity, improved availability, and a more uniform user experience. Higher performance and improved efficiency will enable new user experiences and connect newer industries. Although some of the above goals have been achieved, existing 5G networks still have many challenges that need to be resolved. For example, existing 5G networks may not optimally serve multiple industry verticals, may not support private networks, and may not provide an architecture to support flexible network deployment.
[0006] Reconfigurable Intelligent Surfaces (RIS) are rapidly emerging as a key wireless technology trend for 5G and even Beyond 5G networks. RIS correspond to smart wireless surfaces of a multitude of small antennas or reconfigurable metamaterial elements ("unit cells") that enable control of the propagation environment through tunable scattering of electromagnetic waves. These intelligent surfaces have reflective, refractive, and absorptive properties that are reconfigurable and adaptable to the wireless channel environment.
[0007] Furthermore, existing 5G networks do not yet use many of the available or emerging technologies in an optimal manner to solve many of the above-mentioned problems. Examples of such available technologies include artificial intelligence, terahertz communications, optical wireless technology, free space optic networks, blockchain, three-dimensional networking, quantum communications, unmanned aerial vehicles, cell-free communications, integrated wireless information and energy transfer, integrated sensing and communications, integrated access backhaul networks, dynamic network slicing, holographic beamforming, and big data analytics.
[0008] Furthermore, with respect to 6G networks, existing systems and methods do not provide any 6G network interface architecture and any protocols between the 6G network and the IRS that satisfactorily address the concerns highlighted above with respect to current 5G networks. Furthermore, current methods and systems do not provide a feature of sharing IRS resources of the IRS among multiple base stations in a 6G / 5G network.
[0009] Therefore, there is a need in the art for a system and method for providing an IRS architecture for 5G networks and subsequent networks (6G networks) that can overcome the above-mentioned problems in the art and that can take advantage of the convergence of at least one or more of the above-mentioned available technologies. Summary of the Invention [Problem to be solved by the invention]
[0010] Some of the objectives of the present disclosure that are met by at least one embodiment herein are listed herein below.
[0011] It is an object of the present disclosure to facilitate efficient, simultaneous, and improved communication between a base station (BS) and one or more UEs of a 5G / 6G network.
[0012] It is an objective of this disclosure to eliminate the need for additional and costly deployment of BSs for better network coverage in 6G and beyond networks.
[0013] It is an object of the present disclosure to facilitate economical next generation based systems and methods that can enable a communication or network interface between a BS and an IRS in 6G and beyond networks.
[0014] It is an object of the present disclosure to facilitate systems and methods that can enable control of an IRS by a BS using a communication or network interface in 6G and beyond networks.
[0015] It is an object of this disclosure to provide UE support for the implementation of an efficient IRS architecture.
[0016] It is an object of the present invention to improve the user experience.
[0017] It is an object of the present invention to share the IRS resources of an IRS among multiple base stations. [Means for solving the problem]
[0018] Some of the objectives of the present disclosure that are met by at least one embodiment herein are listed herein below.
[0019] An embodiment of a network device for sharing intelligent reflective surface (IRS) resources of an intelligent reflective surface (IRS) in a communication network is disclosed. In an embodiment, the network device includes one or more processors coupled to a memory storing a set of instructions that, when executed by the one or more processors, causes the network device to receive a scheduling data request from an IRS manager, where the IRS manager determines poor signal reception by the plurality of user equipments (UEs) based at least in part on measurement reports received from the network device corresponding to each of the plurality of UEs, transmit the scheduling data request. The one or more processors further cause the network device to transmit a scheduling data response to the IRS manager in response to the received scheduling data request, and receive an IRS resource command from the IRS manager, where the IRS manager transmits the IRS resource command in response to the scheduling data response. Furthermore, the one or more processors cause the network device to transmit the received IRS resource command to an IRS controller associated with the IRS, where the IRS controller is configured to allocate IRS resources to each of the plurality of UEs based on the IRS resource command.
[0020] In an embodiment, the IRS manager sends a scheduling data request when it determines that a plurality of UEs are within the coverage of the IRS. In an embodiment, the measurement report includes a channel quality indicator (CQI) and a channel state information (CSI) parameter of the serving cell, and a reference signal received power (RSRP) information and a reference signal received quality (RSRQ) parameter of a pilot signal received from the IRS by each of the plurality of UEs. In an embodiment, the processor is further configured to communicate with the IRS manager via a Common Communications Interface Module (CCIM) interface. In an embodiment, the processor is configured to communicate with the IRS controller via a DUI interface. In an embodiment, the scheduling data request includes a list of cell IDs of the serving cell, a list of the plurality of UEs, and a number of transmission time intervals (TTIs). In an embodiment, the scheduling data response includes an amount of data to be scheduled, a balance packet delay budget (PDB) for the scheduled data, an assigned modulation and coding scheme (MCS), and received channel status information (CSI). In an embodiment, the IRS resource command includes a list of cell IDs, a list of UEs from the plurality of UEs, a list of assigned IRS resources for each cell, and a corresponding validity time of the assignment of the IRS resources. In an embodiment, the IRS manager is configured to derive a determined assigned portion of the IRS resources for each served cell based on the received scheduling data response. In an embodiment, the processor configures the MAC scheduler to start using the assigned IRS resources for the plurality of UEs under the coverage of the IRS.
[0021] An embodiment of a method for sharing intelligent reflective surface (IRS) resources of an intelligent reflective surface (IRS) in a communication network is disclosed. In an embodiment, the method includes receiving a scheduling data request from an IRS manager by a network device, the IRS manager sending the scheduling data request when the IRS manager determines poor signal reception by the plurality of user equipments (UEs) based at least in part on measurement reports received from the network device corresponding to each of the plurality of UEs. The method further includes sending a scheduling data response by the network device to the IRS manager in response to the received scheduling data request, and receiving an IRS resource command from the IRS manager by the network device, the IRS manager sending the IRS resource command in response to the scheduling data response. The method further includes sending the received IRS resource command by the network device to an IRS controller associated with the IRS, the IRS controller being configured to allocate IRS resources to each of the plurality of UEs based on the IRS resource command.
[0022] In an embodiment, the measurement report includes a channel quality indicator (CQI) and channel state information (CSI) parameters of the serving cell, and reference signal received power (RSRP) information and reference signal received quality (RSRQ) parameters of the pilot signal received from the IRS by each of the plurality of UEs. In an embodiment, the network device is further configured to communicate with the IRS manager via a common communications interface module (CCIM) interface. In an embodiment, the network device is configured to communicate with the IRS controller via a DUI interface. In an embodiment, the scheduling data request includes a list of cell IDs of the serving cell, a list of the plurality of UEs, and a number of transmission time intervals (TTIs). In an embodiment, the scheduling data response includes an amount of data to be scheduled, a balanced packet delay budget (PDB) for the scheduled data, an assigned modulation coding scheme (MCS), and received channel status information (CSI). In an embodiment, the IRS resource command includes a list of cell IDs, a list of UEs from the plurality of UEs, a list of IRS resources assigned to each cell, and a corresponding validity time of the assignment of the IRS resources. In an embodiment, the method further includes configuring, by the network device, a MAC scheduler for a plurality of UEs under coverage of the IRS to begin using the allocated IRS resources. In an embodiment, the IRS manager is configured to derive a determined allocated portion of the IRS resources for each served cell based on the received scheduling data response.
[0023] An embodiment of a non-transitory computer readable medium (CRM) for sharing IRS resources of an IRS is disclosed. The non-transitory CRM includes a set of instructions that, when executed by a processor included in a network device, causes the processor to receive a scheduling data request from an IRS manager, where the IRS manager determines poor signal reception by the plurality of user equipments (UEs) based at least in part on measurement reports received from a network device corresponding to each of the plurality of UEs, transmit the scheduling data request. The set of instructions, when executed, further causes the processor to transmit a scheduling data response to the IRS manager in response to the received scheduling data request, and receive an IRS resource command from the IRS manager, where the IRS manager transmits the IRS resource command in response to the scheduling data response. The set of instructions, when executed, further causes the processor to transmit the received IRS resource command to an IRS controller associated with the IRS, where the IRS controller is configured to allocate IRS resources to each of the plurality of UEs based on the IRS resource command.
[0024] The accompanying drawings, which are incorporated herein and constitute a part of the present invention, depict exemplary embodiments of the disclosed methods and systems, with like reference numerals referring to the same parts throughout the various drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed on clearly illustrating the principles of the invention. Some drawings may use block diagrams to illustrate components and may not show the internal circuitry of each component. Those skilled in the art will appreciate that the inventions in such drawings include inventions in electrical components, electronic components, or circuits commonly used to implement such components. [Brief description of the drawings]
[0025] [Figure 1]FIG. 1 illustrates a typical IRS deployment scenario in an example 5G or 6G network architecture in accordance with an embodiment of the present disclosure. [Figure 2a] FIG. 1 illustrates an example use case of an IRS deployment according to an embodiment of the present disclosure. [Figure 2b] FIG. 1 illustrates an example use case of an IRS deployment according to an embodiment of the present disclosure. [Figure 2c] FIG. 1 illustrates an example use case of an IRS deployment according to an embodiment of the present disclosure. [Figure 2d] FIG. 1 illustrates an example use case of an IRS deployment according to an embodiment of the present disclosure. [Figure 2e] FIG. 1 illustrates an example use case of an IRS deployment according to an embodiment of the present disclosure. [Figure 2f] FIG. 1 illustrates an example use case of an IRS deployment according to an embodiment of the present disclosure. [Diagram 3] FIG. 1 illustrates an example IRS coverage scenario according to an embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates an example IRS deployment scenario in accordance with an embodiment of the present disclosure. [Figure 5a] FIG. 1 illustrates an example functional architecture of a RAN interfacing with an IRS according to an embodiment of the present disclosure. [Figure 5b] FIG. 2 illustrates an example network device implemented in an IRS network architecture according to an embodiment of the present disclosure. [Figure 5c] FIG. 2 illustrates an example UE according to an embodiment of the present disclosure. [Figure 6] FIG. 2 illustrates an example DUI protocol interface stack in accordance with an embodiment of the present disclosure. [Figure 7a] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 7b] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 7c] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 7d] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 7e] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 7f] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 7g] FIG. 1 illustrates example steps involved in a protocol for interfacing between a RAN and an IRS according to an embodiment of the present disclosure. [Figure 8a] FIG. 1 illustrates example steps involved in a UE procedure for identifying an IRS, measuring signal parameters, and communicating a measurement report to a 5G or 6G network, in accordance with an embodiment of the present disclosure. [Figure 8b] FIG. 1 illustrates example steps involved in a UE procedure for identifying an IRS, measuring signal parameters, and communicating a measurement report to a 5G or 6G network, in accordance with an embodiment of the present disclosure. [Figure 8c] FIG. 1 illustrates example steps involved in a UE procedure for identifying an IRS, measuring signal parameters, and communicating a measurement report to a 5G or 6G network, in accordance with an embodiment of the present disclosure. [Figure 9] FIG. 2 illustrates an example scenario of an IRS network architecture providing sharing of an IRS among multiple network devices, in accordance with an embodiment of the present disclosure. [Figure 10] FIG. 1 illustrates an exemplary computer system in which embodiments of the present disclosure may be utilized, in accordance with an embodiment of the present disclosure. [Figure 11]FIG. 11 illustrates an example RAN architecture 1100 in which the IRS manager is deployed as a centralized, standalone entity that communicates with the gNB-CU-CP via a CCIM interface [CCIM: CU-CP-IRS Manager], in accordance with an embodiment of the present disclosure. [Figure 12] FIG. 12 illustrates an example RAN architecture 1200 in which an IRS manager is deployed as a distributed entity co-located with a gNB-CU-CP, in accordance with an embodiment of the present disclosure. [Figure 13] FIG. 13 illustrates an example RAN architecture 1300 in which an IRS manager is located as a centralized entity, in accordance with an embodiment of the present disclosure. [Figure 14] FIG. 2 illustrates an exemplary CCIM interface protocol stack according to an embodiment of the present disclosure. [Figure 15a] FIG. 2 illustrates an exemplary initial set of procedures that may be used in a CCIM interface according to an embodiment of the present disclosure. [Figure 15b] FIG. 2 illustrates an exemplary initial set of procedures that may be used in a CCIM interface according to an embodiment of the present disclosure. [Figure 15c] FIG. 2 illustrates an exemplary initial set of procedures that may be used in a CCIM interface according to an embodiment of the present disclosure. [Figure 15d] FIG. 2 illustrates an exemplary initial set of procedures that may be used in a CCIM interface according to an embodiment of the present disclosure. [Figure 16a] FIG. 13 illustrates 6G F1 interface procedures that need to be supported for IRS sharing functionality according to an embodiment of the present disclosure. [Figure 16b] FIG. 13 illustrates 6G F1 interface procedures that need to be supported for IRS sharing functionality according to an embodiment of the present disclosure. [Figure 17] FIG. 17 illustrates an example sequence of steps 1700 for IRS sharing according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0026] The above will become more apparent from the following more detailed description of the invention.
[0027] In the following description, for the purpose of explanation, various specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent that the embodiments of the present disclosure may be practiced without these specific details. Some features described below may be used independently of each other or with any combination of other features. Individual features may not address all of the problems discussed above, or may address only some of the problems discussed above. Some of the problems discussed above may not be fully addressed by any of the features described herein.
[0028] The following description merely provides exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments provides those skilled in the art with an enabling description for implementing the exemplary embodiments. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
[0029] Specific details are provided in the following description to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other cases, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0030] It is also noted that the individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flow diagram may show operations as a sequential process, many of the operations may be performed in parallel or simultaneously. In addition, the order of operations may be rearranged. A process is terminated when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or to the main function.
[0031] The words "exemplary" and / or "illustrative" are used herein to mean serving as an example, instance, or example. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as "exemplary" and / or "illustrative" is not necessarily to be construed as preferred or advantageous over other aspects or designs, and is not intended to exclude equivalent exemplary structures and techniques known to those skilled in the art. Furthermore, to the extent that the terms "includes," "has," "contains," and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive without excluding any additional or other elements -- in the same manner as the term "comprising" as an open transition term.
[0032] References throughout this specification to "one embodiment" or "an embodiment" or "an instance" or "one instance" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0033] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising" as used herein specify the presence of the mentioned features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.
[0034] A new paradigm for wireless communications that fully supports artificial intelligence, the sixth generation (6G) system, is expected to be deployed in the next few years. Some fundamental issues that may need to be addressed in 6G networks include larger system capacity, higher data rates, lower latency, and improved quality of service (QoS) compared to 5G networks.
[0035] Even with current fifth generation (5G) technology, greater system capacity, higher data rates, less latency, and improved quality of service (QoS) are desirable. 5G networks do not yet use available or emerging technologies.
[0036] Additionally, future networks, such as but not limited to 6G networks, may desirably be designed to enable an expansion of human experience across the physical, biological, and digital worlds. At the same time, 6G networks may desirably enable next-generation industrial business environments beyond Industry 4.0 (the Fourth Industrial Revolution) in various dimensions of performance. Such dimensions may include but are not limited to positioning, sensing, ultra-reliability, energy efficiency, and extreme real-time. 6G networks may provide novel radio and access architectures for both communication and sensing, co-design of AI-optimized wide area networks (WANs) and data centers, and dynamic orchestration of personalized services to revolutionize the long tail of niche consumer interests.
[0037] Mobile broadband demand will continue to grow for consumers and businesses alike, but the use of ultra-high reliability and low latency will be driven largely by specialized, localized use cases associated with non-public networks and often augmented intelligence. This will occur as an integral part of the automated and secure network transformation anticipated and attempted in current 5G networks. Things ranging from automobiles, industrial machines, and home appliances to watches and apparel will learn and organize themselves to meet human needs by automatically adapting to human behavior, environment, and business processes. Energy efficiency is yet another key design criterion for the design of 6G network architectures, since network performance depends on the energy available in the domain of the respective architecture.
[0038] One of the most challenging requirements comes from remote control in conjunction with augmented reality and immersive media experiences. In addition to extreme ultra-reliable low latency (URLLC) performance requirements, this calls for ultra-high rates of 100Gbit / s and above, enabling uncompressed transmission of high-quality 360-degree video. Such demands require a degree of flexibility and specialization that exceeds the capabilities of 5G networks. 6G networks must therefore be intent and open service driven, in short, business needs drive the creation of 6G products and services. The creation of products and services will be an integral part of automated e2e service workflows, guided and guided by policies and intents. In other words, use case driven means meeting the diverse needs and preferences of each user or specialized 6G sub-network, whether it is a human, a physical machine or a digital twin. In summary, key requirements for 6G architecture may include: (a) network programmability, (b) deployment flexibility, (c) simplicity and efficiency, (d) security, robustness, and reliability, and (e) automation.
[0039] The disclosed network architecture addresses the problem of network flexibility as proposed hereafter. The present disclosure also proposes 5G and 6G network architectures that support network sensing as a built-in feature. The present disclosure also proposes an IRS architecture for 5G and Beyond 5G networks (e.g., 6G) that leverages at least one of the above-mentioned existing technologies and at least partially solves the convergence problem. The present disclosure provides a mechanism for providing support by existing UEs to enable a successful network interface architecture between the network and the IRS.
[0040] FIG. 1 illustrates a typical IRS deployment scenario 100 in an exemplary 5G or 6G network architecture according to an embodiment of the present disclosure. In an embodiment, the main features of an IRS include the absence of power amplification, operation at RF levels with no or limited digital signal processing, and the ability to reconfigure multiple functions. The disclosed embodiment of the IRS architecture takes these features into account and provides a solution to at least the problems highlighted above. As shown, the deployment scenario 100 includes an IRS 102 configured to reflect signals from base stations 104a and 104b to access points 106a and 106b.
[0041] 2a-2f illustrate example use cases of an IRS deployment according to an embodiment of the present disclosure. In general, use cases currently being explored for an IRS (indistinguishably referred to as a RIS in this description) include use as a smart quasi-passive relay for coverage extension, use as a single RF multi-stream transmitter for capacity improvement, and use for information aided transmission in the context of ambient backscattering and symbiotic radio. For example, as shown in FIG. 2a, an IRS deployment 200 is used for a RIS-aided unmanned aerial vehicle (UAV) 202. In yet another example, as shown in FIG. 2b, an IRS deployment 204 is used for RIS-aided mm-wave communication. In yet another example, as shown in FIG. 2c, an IRS deployment 206 is used for RIS-aided simultaneous wireless information and power transfer (SWIPT). In yet another example, an IRS deployment 208 is used for RIS-assisted physical layer security, as shown in Fig. 2d. In yet another example, an IRS deployment 210 is used for RIS-assisted mobile edge computing, as shown in Fig. 2e. In yet another example, an IRS deployment 212 is used for a RIS-assisted device-to-device (D2D) system, as shown in Fig. 2f.
[0042] In general, RIS enables dynamic and goal-directed control of radio signals between transmitters and receivers, thus transforming the wireless environment into a service. This ability in terms of reconfiguring wireless channels has motivated many potential improvements in various network critical performance indicators (KPIs) such as capacity, coverage, energy efficiency, positioning, and security. This is in addition to supporting new capabilities such as sensing and wireless power transfer.
[0043] RIS introduces new system nodes that change the wireless environment from passive to intelligent participants, and as a result, the channels become programmable. This trend challenges fundamental wireless system design paradigms and creates opportunities for innovation that will progressively impact the evolution of wireless system architectures, access technologies, and network protocols.
[0044] Moreover, reconfigurable intelligent surfaces (RIS) can construct intelligent and programmable wireless environments in a controllable manner. RIS can perform passive reflection, passive absorption, and passive scattering, allowing the physical environment to be changed intelligently and interactively. RIS can change the electromagnetic properties of elements and generate phase shifts independently for the incident signal without using any RF signal processing. RIS technology also has many technical features that go beyond the current mainstream technologies. Compared with massive MIMO, RIS-assisted wireless networks greatly improve system performance by optimizing smart signal propagation.
[0045] Moreover, the RIS element is completely passive and has low power consumption, making it environmentally friendly and sustainable green. The RIS design does not require expensive components such as ADC / DAC and power amplifiers, so the feasibility of wide-area deployment can be greatly enhanced. In addition, the electromagnetic wave can be reconstructed at any point on its continuous surface, thus forming any shape to adapt to different application scenarios and supporting higher spatial resolution. The RIS makes it possible to intelligently control the propagation environment, improve the reliability of transmission, and achieve higher spectral efficiency.
[0046] RIS may be applicable in one or more scenarios, for example, to overcome non-line of sight (NLOS) limitations and address coverage hole issues in an environmentally friendly way. Another scenario is to serve cell edge users, mitigate multi-cell co-channel interference, extend coverage, and implement dynamic mobile user tracking. A further scenario may be to reduce electromagnetic pollution and solve multipath problems. Yet another scenario is to use RIS for positioning, perception, holographic communication, and augment reality. A further scenario is to realize sensing-communication integration.
[0047] Future evolving communication systems in 5G and 6G networks will face more complex wireless environments and higher quality of service requirements, which bring greater challenges to the architecture and design of RIS. First, reasonable electromagnetic and channel models may need to be established. The fundamental limitations and potential benefits of RIS-assisted communication systems may need to be explored. Since no RF chain is configured in RIS, new systems and methods are needed for channel estimation.
[0048] Secondly, in the design of IRS architecture, passive beamforming design and passive information transfer optimization are required. In addition, RIS deployment in 6G will bring a new network paradigm. In addition, research and development of new materials is one of the bottlenecks in the development of RIS technology. New control mechanisms can be explored through electromagnetic modeling, control methods, and baseband characteristics of metasurfaces. Finally, as theoretical research on electromagnetic propagation and channel models continues to develop, it is necessary to consider data-driven and model-driven AI optimization design to fully utilize the characteristics of the physical layer and improve the efficiency of the algorithm.
[0049] As a new foundational technology, RIS has the characteristics of low cost, low power consumption, and easy deployment, which supports future green communication and enables future sensing-communication integration. IRS helps to boost the desired signal power while nullifying reflected interference. Alternatively, reflected interference can be tuned to counter direct interference (although it is more difficult to implement). This improves the SINR of cell edge users by creating "signal hotspots" and "no interference zones" in the vicinity of the IRS. The present invention proposes an IRS network architecture that can be implemented in all the above use cases / scenarios.
[0050] FIG. 3 illustrates an exemplary IRS coverage scenario 300 according to an embodiment of the present disclosure. As shown in the figure, there are certain areas, such as behind some tall buildings, behind a hill structure, or at the cell edge, where there is a definite possibility of signal degradation from a given base station (5G or 6G). In such areas, the signal of the base station (BS) can be improved by deploying an IRS in an appropriate location with appropriate dimensions. Based on the dimensions of the IRS, the beam width can be adjusted either vertically or horizontally to support one or more UEs affected by such signal degradation. In an embodiment, the beam can also be steered either vertically or horizontally. Based on the dimensions of the IRS antenna elements, the maximum steering of the beam in both vertical and horizontal directions generates a virtual spherical area called the IRS coverage area. Thus, users suffering from signal degradation within this kind of spherical coverage area can get an improved signal from the base station by using the reflected / regenerated beam from the associated IRS.
[0051] Referring to FIG. 3, IRS-1 (302-1) is deployed so that it can receive the direct signal from the base station 304 and reflect / regenerate another beam to provide an improved base station signal to the area behind the large building. Based on the number of antenna array elements supported by IRS-1 (302-1), a coverage of IRS-1 is virtually created. All UEs within this coverage can benefit from IRS-1 (302-1). Similarly, IRS-2 (302-2) is deployed closer to the hill to assist UEs suffering from poor coverage behind the hill.
[0052] In the case of IRS-N (302-N) scenario, some cell edge UEs received degraded signals from the serving base station and were often dropped suddenly. In such scenarios, a deployment such as IRS-N assists the cell edge UEs to consistently provide a stable and improved signal from the base station. This allows the affected UEs to avoid unnecessary call drops, and the deployment of IRS-N improves the capacity of the serving cell by expanding the coverage, based on the dimensions of the deployed IRS-N. In an embodiment, the base station 304 communicates with the IRS-1, IRS-2, and IRS-N via the proposed DUI interface ("DUI I / F") 306.
[0053] In an embodiment, within a cell coverage, one or more IRSs may be deployed based on the nature of the geographic area of the cell coverage. The dimensions of such IRSs may be the same or different based on the dimensions of the objects obstructing the base station signal. In an embodiment, the obstacles may correspond to tall buildings, hills, and therefore there is attenuation throughout the signal path to the cell edge. In an embodiment, the deployment of the IRS may be static, where possible coverage holes in the cell coverage are known in advance and are more or less permanent due to structures such as buildings, tunnels, bridges, hills, trees, etc. In yet another embodiment, the deployment of the IRS may be dynamic, where possible coverage holes in the cell coverage are temporary, such as due to natural disasters, public safety scenarios, rallies, etc., in which case the IRS may be deployed by UAVs, air balloons, satellites, etc.
[0054] The disclosed embodiments propose an IRS and 5G / 6G network interface architecture, and further a communication protocol between the 5G / 6G network and the IRS. The disclosed embodiments also provide for the calculation of (calculated) IRS gradient information in the base station, which is forwarded to the IRS via the proposed network interface.
[0055] In one embodiment, the IRS slope information is calculated based on SINR or Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) information at the base station. In another embodiment, the beamforming for the IRS is calculated based on knowledge of the location of the IRS and the location of the user and provided channel quality indicator (CQI) information from the UE.
[0056] In one embodiment, the IRS gradient information is calculated as a precoding matrix or beamforming or IRS gradient matrix, also called digital IRS steering or beamforming, applied when using an antenna array to simultaneously transmit one or more spatially directive signals. Every antenna of the IRS transmission array emits a different signal designed in the digital domain according to an optimization criterion arrived at by using information of the quality of the signal experienced by the UE. In an embodiment, the IRS applies a precoding matrix or beamforming matrix provided by a base station scheduler entity to provide directivity (beamforming), i.e., align the reflection angle of the IRS antenna elements towards the intended UE, and select the transmission power (power allocation). In particular, using or allocating power and phase separately is also an embodiment of the present disclosure. In short, precoding is a specific strategy selected at the transmitter to convey information to one or more receivers. Furthermore, the IRS may be dynamically and automatically configured based on the requirements.
[0057] The disclosed mechanism provides a way for a base station (BS) to recognize the IRS so that the tilt of the IRS can be controlled taking into account the distribution of a given user (or UE) in the vicinity of the deployed IRS panel. In an embodiment, this is accomplished by one or more base stations by taking into account the distribution of users (or UEs) and signal strength (SINR).
[0058] In one embodiment, the disclosed base station (BS) is aware of the IRS either through prior knowledge encoded in a database or through a signaling mechanism between the IRS and the BS (described later in this description). When the IRS appears or becomes active in the network, it may be configured to send a handshake signal to all connected BSs via available physical connections. One or more of the following information may be exchanged: IRS ID, location in latitude / longitude, etc. In an embodiment, the connection between the IRS and the BS may be through an RF connection (IAB, microwave link, etc.).
[0059] A network interface protocol including a handshake signaling schema is disclosed. In one embodiment, the interface mechanism between a base station (BS) and an IRS panel is shown in Figure 4. Referring to Figure 4, a direct connection is established between the BS and the IRS via a microcontroller (hereinafter also referred to as an IRS controller) to implement a mechanism for calculating tilt control information at a given time and communicating such information to the IRS via the connection.
[0060] The control of the tilt of the IRS panel by the BS can have two aspects: In an embodiment, the BS is configured to collect a signal-to-noise-plus-interference ratio (SINR) profile at the BS and generate from it an RF Signature profile of the area near the IRS. In an exemplary embodiment, the SINR profile is collected via one or more extended user measurement reports generated by UEs in the area served by the BS and transmitted to the BS.
[0061] In another embodiment, the BS (or a scheduler module in the BS) is configured to calculate the gradient required to achieve the SINR target and to do so using one or more information elements such as, but not limited to, the distribution of users for a given area, user or SINR or Block Error Rate (BLER) profiles, etc. In an embodiment, the gradient can be based on user location information that can be obtained by sensing mechanisms implemented in the UE, and such information is fed to the BS (scheduler).
[0062] The disclosed IRS architecture also describes mechanisms for collecting the above information from the UE and management of such collection mechanisms. In an embodiment, one or more control messages are transmitted from the BS to the IRS. In an embodiment, the periodicity of such control messages may be pre-configured based on requirements or other factors.
[0063] In an embodiment, the IRS may be controlled by the BS using one or more control messages. In particular, any intelligent entity or network device, such as but not limited to a radio controller (radio resource management entity or baseband entity), a core network, or an O-RAN RIC (Radio intelligent controller), may convey the control messages and control the IRS.
[0064] In one of the embodiments, a 6G NR DU and IRS interface, which has been referred to in this description as the "DUI I / F", is proposed, which is implemented as a logical interface between the BS and the IRS controller for passing signaling messages between the DU and the IRS, as will be detailed later in this description.
[0065] 4 illustrates an exemplary IRS deployment scenario according to an embodiment of the present disclosure. In one embodiment, an interface mechanism between a base station (BS) and an IRS panel is provided. As shown, the IRS 404 includes a copper backplane and control circuit board. The IRS 404 and base station 402 communicate via a microcontroller 406, which may or may not be part of the IRS 404, to exchange messages (e.g., control messages).
[0066] FIG. 5a illustrates a functional architecture 500 of a next or future generation RAN (e.g., 6G RAN) with support for IRS. For illustrative purposes, various blocks or modules or subsystems of the disclosed base station or network device are illustrated in the architecture 500. In an embodiment, the 6g-NB-DU (6G base station node DU) 506-1 and 506-M support multiple cells, and each cell may be connected to one or more IRS controllers (e.g., IRS-1 controller, IRS-2 controller, IRS-3 controller) via the proposed DUI I / F 504. Each of the IRS controllers corresponds to an IRS-1 (502-1), an IRS-2 (502-2), and an IRS-3 (502-3), respectively. In an embodiment, 6g-NB-CUs (6G base station node CUs) 510-1 and 510-P maintain an IRS-to-cell mapping table (e.g., 514-1 and 514-P) for each supported cell context as shown in the figure. The 6g-NB-CUs (6G base station node CUs) communicate with each other via a 6G-XN interface 512. The 6g-NB-CUs (6G base station node CUs) communicate with a sixth generation code (6GC) 522 via a 6G-NG interface 520.
[0067] In an exemplary embodiment, whenever an IRS is deployed in a cell, an entry is made in an IRS-cell mapping table maintained in the 6g-NB-CU (6G base station node CU). In an embodiment, the entry includes IRS-ID, number of antenna elements supported by the IRS, capabilities of the IRS like mechanical / electrical tilt support, active / passive support, geographic location like altitude, azimuth, elevation, coverage capability of the IRS, shareable / non-shareable status, deployment details in cell edge / cell middle / cell center areas, etc. In an embodiment, the above information may be obtained either from an element management system (EMS) or directly from an IRS controller during the (DU-IRS) DUI-AP (Application Protocol) setup procedure (described later with reference to Figures 7a-7g). In an embodiment, the IRS-cell mapping table may be managed or updated in real time or may be configured periodically. In yet another embodiment, the IRS-cell mapping table may be managed according to a predefined plan based on expected network use cases / scenarios in a particular geolocation.
[0068] In an embodiment, the UE may be configured to frequently update or send its physical location information to the 6G-NB-CU-CP using either a Radio Resource Control (RRC) Measurement Report message or a new RRC message such as UE Location Information Update. Whenever the reported UE location enters or approaches the coverage of any pre-deployed IRS, the 6g-NB-CU-CP (e.g., 510-1) informs the 6g-NB-DU (e.g., 506-1) of the UE details, its location information, and related IRS information. The 6g-NB-DU (e.g., 506-1) then creates an entry in its IRS-UE mapping table and requests the given UE to start reporting its current location information, moving speed, moving direction, etc. while reporting regular or periodic channel state information (CSI) reports. When the given UE sends this additional information, the 6g-NB-DU (e.g., 506-1) verifies whether the UE has entered the coverage area of the IRS and whether it is under the particular IRS. The 6g-NB-DU (e.g., 506-1) then starts coordinating with an associated IRS controller (e.g., IRS-1 controller) to reserve a number of antenna array elements for reflecting a particular beam towards the UE.
[0069] When multiple UEs are in the coverage area of the IRS, the 6g-NB-DU determines whether a different beam (other than the already generated beam) needs to be generated to serve those UEs. In an embodiment, it may be up to the 6g-NB-DU to determine whether a given UE should have only a reflected beam or both a direct beam and a reflected beam. If the UE is served by both a direct beam and a reflected beam, there may be no problem when the UE moves from the coverage area of the IRS to the coverage area of a normal cell served by the 6g-NB-DU (or BS). However, when the UE is served only by a reflected beam, the 6g-NB-DU needs to closely track the movement of the UE moving from the coverage area of the IRS to the coverage area of a normal cell and trigger an intra-cell inter-beam handover when appropriate.
[0070] In an embodiment, the 6g-NB-CU-CP can either activate or deactivate the use of the IRS by the 6g-NB-DU by sending an IRS activation or IRS deactivation message to the 6g-NB-DU via the 6g-F1 interface 508. The 6g-NB-CU-CP (e.g., 510-1) frequently updates / sends the IRS details and usage to the EMS 518 via the SNMP / TR069 / O1 interface 516, which may be used for further billing purposes if required.
[0071] It will be appreciated by those skilled in the art that the exemplary use cases described in connection with Figures 2a-2f may be implemented using the functional architecture 500 with IRS support / deployment. In general, the disclosed IRS architecture may be implemented for use as a smart quasi-passive relay for coverage extension, as a single RF multi-stream transmitter for capacity improvement, and for information-aided transmission in the context of environmental backscatter and symbiotic radio. For example, as shown in Figure 2a, the IRS deployment 200 may be used in a RIS-assisted unmanned aerial vehicle (UAV) and implement the disclosed IRS network architecture. In yet another example, as shown in Figure 2b, the IRS deployment 204 may be used for RIS-assisted mm-wave communication and implement the disclosed IRS network architecture. In yet another example, as shown in Figure 2c, the IRS deployment 206 may be used for RIS-assisted simultaneous wireless information and power transfer (SWIPT) and implement the disclosed IRS network architecture. In yet another example, as shown in Fig. 2d, an IRS deployment 208 may be used for RIS-assisted physical layer security and may implement the disclosed IRS network architecture. In yet another example, as shown in Fig. 2e, an IRS deployment 210 may be used for RIS-assisted mobile edge computing and may implement the disclosed IRS network architecture. In yet another example, as shown in Fig. 2f, an IRS deployment 212 may be used for a RIS-assisted device-to-device (D2D) system and may implement the disclosed IRS network architecture.
[0072] Fig. 5b illustrates a network device 524 according to an embodiment. One or more components of the 6G or 5G network described with reference to Fig. 5a may be integrated and implemented as the proposed network device 524.
[0073] In an embodiment, the network device 524 may include one or more processors 526 coupled with a memory 528, which may store instructions that, when executed by the one or more processors, may cause the network device 524 to implement the disclosed IRS architecture. The one or more processors (526) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operational instructions. Among other capabilities, the one or more processors (526) may be configured to fetch and execute computer-readable instructions stored in the memory 528 of the network device 524. The memory 528 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 528 may include any non-transitory storage device, including, for example, a volatile memory, such as a RAM, or a non-volatile memory, such as an EPROM, a flash memory, etc.
[0074] The memory 528 includes one or more modules, such as an IRS setup module 530, an IRS configuration module 532, a resource command module 534, an IRS activation module 536, a DU configuration module 538, a proximity notification module 540, and an RRC configuration module 542. The IRS setup module 530 is configured to perform one or more steps or procedures (e.g., 700) for initial setup of the IRS. The IRS configuration module 532 is configured to perform one or more steps or procedures (e.g., 706) for configuration of the IRS, as detailed later in this description. The resource command module 534 is configured to perform one or more steps or procedures (e.g., 708) for commanding reservation of antenna array elements (or other resources) of the IRS for communication with the UE. The IRS activation module 536 is configured to perform one or more steps or procedures (e.g., 710, 720) for activating or deactivating the IRS. The DU configuration module 538 is configured to perform one or more steps or procedures (e.g., 712) indicating the latest set of deployed IRSs and their details. The proximity notification module 540 is configured to perform one or more steps or procedures (e.g., 716) whenever one or more UEs (e.g., 718) are detected in the vicinity of the coverage of a particular IRS. The RRC configuration module 542 is configured to perform one or more steps or procedures for radio resource control (RRC) connection reconfiguration. The RRC connection reconfiguration procedure is used to configure measurement control to add UE location information to one or more measurement reports received from the UE.
[0075] In an embodiment, the one or more modules mentioned above may be configured to perform one or more functions, steps, procedures described herein in the context of a 6G network. For example, all steps for implementing a communication protocol (and its protocol stack) between the 6G network and one or more IRSs may be performed by the network device 524. Furthermore, steps, procedures related to the configuration and / or setup of one or more IRSs may also be performed by the network device 524. Furthermore, steps or procedures for setting up the UE to periodically transmit measurement reports may be performed by the network device 524, for example, by the RRC configuration module 542.
[0076] Additionally, steps or procedures for processing and analyzing measurement reports from UEs to determine gradients (i.e., gradient information) related to the IRS may be performed by the network device 524. While different nodes or modules may have been described as performing various functions and steps for providing the disclosed IRS architecture, it will be understood that all or a portion of the functions may be performed by one or more network devices 524. For example, the network device 524 may be a 6G-enabled network device including one or more processors 526 coupled to a memory 528 that stores a set of instructions that, when executed by the one or more processors, cause the network device to calculate IRS gradient information related to one or more IRSs based at least in part on a first set of information received from one or more UEs. The first set of information includes one or more of signal-to-interference-and-noise-ratio (SINR) information, reference signal received power (RSRP) information, and reference signal received quality (RSRQ) information received from the one or more UEs.
[0077] The one or more processors 526 further cause the network device 524 to communicate the calculated IRS tilt information to the one or more IRSs via the network interface, where the IRS tilt information is used to control one or more operational aspects of the one or more IRSs. The one or more operational aspects of the one or more IRSs include mechanical aspects, such as, but not limited to, mechanical tilt. In an embodiment, the one or more operational aspects of the one or more IRSs include digital aspects, such as, but not limited to, digital tilt. In an embodiment, the one or more operational aspects of the one or more IRSs include electrical aspects, such as, but not limited to, transmit power. It will be appreciated that each of the one or more IRSs includes multiple tiles or panels. In an exemplary embodiment, the disclosed operational aspects of the one or more IRSs may be controlled at various levels of granularity, e.g., at a tile level, a panel level, etc.
[0078] In an embodiment, the one or more processors 526 further cause the network device 524 to calculate IRS gradient information based on one or more of the locations of the one or more IRSs, the locations of the one or more UEs, and channel quality indicator (CQI) information from the one or more UEs, where the IRS gradient information indicates beamforming for the one or more IRSs.
[0079] In an embodiment, the one or more processors 526 further cause the network device 524 to calculate IRS gradient information as a precoding matrix or beamforming or IRS gradient matrix used to simultaneously transmit one or more spatially directional signals from each of the one or more IRSs, each of which includes multiple antennas. In an embodiment, all antennas of the one or more IRS transmit arrays are configured to emit different signals designed in the digital domain based on the respective IRS gradient information. In an embodiment, the one or more IRSs apply the precoding matrix or beamforming matrix provided by the network device 524 to provide directionality toward an intended UE of the one or more UEs and select a corresponding transmit power.
[0080] In an embodiment, the one or more IRSs use the IRS tilt information to calculate digital and mechanical tilts for each of the antennas and assign power and phase to each of the antennas. In an embodiment, the one or more processors 526 further cause the network device 524 to recognize the one or more IRSs either through prior knowledge encoded in a database or through a signaling mechanism established between the one or more IRSs and the network device by the network interface. In an embodiment, the one or more processors 526 further cause the network device 524 to receive a handshake signal from the new IRS when it is activated via a physical connection between the new IRS and the network device during a setup process.
[0081] In an embodiment, the one or more processors 526 further cause the network device 524 to create an entry in the IRS-cell mapping table, the entry including one or more fields including an IRS-ID, number of antenna elements supported by the new IRS, support for mechanical / electrical tilt, capability of the IRS in terms of active / passive support, geographic location such as altitude, azimuth, elevation, coverage capability of the IRS, shareable / non-shareable status, deployment details. In an embodiment, the network interface implements a network interface protocol established between the network device and the one or more IRSs, the network interface protocol including a handshake signaling schema.
[0082] In an embodiment, the network interface is established through a direct connection between the network device 524 and one or more IRSs via a microcontroller. In an embodiment, the one or more processors 526 further cause the network device 524 to calculate IRS tilt information required to achieve a SINR target based on one or more of a distribution of users, a user profile, a SINR profile, and a block error rate (BLER) profile for a given area served by the network device. In an embodiment, the one or more processors 526 further cause the network device 524 to send one or more control messages to the one or more IRSs at a preconfigured periodicity, and the one or more IRSs are controlled by the network device using the one or more control messages.
[0083] In an embodiment, various modules may be integrated together or implemented in multiple network devices (524) to achieve the same or similar functions without departing from the scope of the ongoing description. For example, the network device 524 corresponds to one or more nodes of a next generation RAN (e.g., 6G RAN) with support for an IRS. In an embodiment, the network device 524 may correspond to a 6g-NB-DU (6G base station node DU) and / or a 6g-NB-CU (6G base station node CU), or a combination thereof. In yet another embodiment, the network device 524 may correspond to a base station (BS), or any such network entity that may be configured to communicate with an IRS and / or UE in the context of the ongoing description.
[0084] In an embodiment, the network device 524 enables the establishment of a network interface protocol with the IRS, as described with reference to Figures 7a-7g. In an embodiment, a DU-I interface (or DU I / F) is established between the network device and the IRS using various setup procedures outlined herein. Using the proposed network interface, the network device 524 may enable the setup of an IRS available to reflect signals to one or more UEs in a particular region or area served by the network device 524. A mapping of one or more parameters of the IRS to mechanical or digital tilt for optimal performance is pre-determined and stored in the network device 524. The network device 524 receives one or more measurement reports from the one or more UEs to determine at run-time the optimal mechanical or digital tilt based at least in part on the pre-determined mapping. The network device 524 sends the optimal mechanical or digital tilt information to the IRS using the proposed network interface, and the IRS controller uses the optimal tilt information to realign the IRS panel or IRS tile.
[0085] In yet another embodiment, the network device 524 performs all functions, steps, procedures to instruct the UE to perform measurements of one or more parameters related or unrelated to IRS. For example, the network device (524) may provide / configure a trigger event in the UE to trigger any such measurements. Such measurements may be performed by the UE and transmitted to the network device 524 in the form of one or more measurement reports. The network device 524 may determine the gradient information or data to be communicated to the IRS controller based on the one or more measurement reports. In yet another embodiment, the network device 524 enables configuration of the IRS in such a way that the IRS controller reserves a portion of the IRS resources for the network device 524. Similarly, another network device 524 may share the IRS resources by configuring yet another portion of the IRS resources by communicating with the IRS controller as described herein.
[0086] In an embodiment, a user equipment (UE) is disclosed that communicates with one or more intelligent reflective surfaces (IRS) and one or more network devices, as shown in FIG. 5C. FIG. 5c illustrates an exemplary UE 544 according to an embodiment of the present disclosure. In an embodiment, the UE or computing device (as shown in various figures) may communicate with the network device 524 and / or a given IRS via a set of executable instructions present on any operating system. In an embodiment, the electronic device may include, but is not limited to, any electrical, electronic, electromechanical, or appliance, such as a mobile phone, a smartphone, a virtual reality (VR) device, an augmented reality (AR) device, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device, or a combination of one or more of the above devices, and the computing device may include one or more built-in or external accessories, including but not limited to a visual aid device such as a camera, an audio aid, a microphone, an input device for receiving input from a user such as a keyboard, a touchpad, a touch-enabled screen, an electronic pen, and the like. It will be understood that the electronic device may not be limited to the above-mentioned devices, and various other devices may be used. The smart computing device may be one of a number of suitable systems for storing data and other private / confidential information.
[0087] In an embodiment, the UE 544 includes a processor 546 coupled to a memory 548. The memory 548 includes one or more modules, such as a measurement module 550, a trigger point module 552, an identification module 554, a reporting module 556, and a GPS / location module 558. The one or more modules in the memory 548 may be configured to perform one or more functions related to the UE side of the procedures / steps disclosed herein, for example, with reference to Figures 8a-8c.
[0088] As an example, the measurement module 550 may be configured to measure one or more parameters related to signal strength received from the BS (or network device) and signal strength received from the IRS. In yet another example, the trigger point module 552 may be configured to enable setting or configuration of one or more trigger points for triggering measurement of one or more parameters by the measurement module 550. The identification module 554 may be configured to enable identification of the IRS based on an identification parameter such as an IRS ID. The reporting module 556 may be configured to create and share one or more measurement reports of a prescribed format having one or more predefined fields. The GPS / location module 558 may be configured to determine or provide location specific information to other modules for inclusion in the measurement report. One or more of the modules may be integrated to form a single module without departing from the scope of the ongoing description. For purposes of brevity, other components and modules of a standard UE are not shown in the figures and described herein. For example, communication components such as antennas, memory storage for reports and related data, etc. are assumed to be part of the UE described herein. Certain modules of the UE 544 may be configured to respond to one or more messages from the network device 524 or the BS to implement the IRS architecture disclosed herein or to support various embodiments of the disclosed IRS mechanisms.
[0089] As described above, the UE 544 includes one or more processors coupled to a memory storing a set of instructions that, when executed by the one or more processors, cause the network device to transmit a first set of information. In an embodiment, the first set of information includes one or more of signal-to-interference-and-noise-ratio (SINR) information, reference signal received power (RSRP) information, reference signal received quality (RSRQ) information, location and channel quality indicator (CQI) information associated with the UE to the one or more network devices. The one or more network devices are configured to calculate IRS slope information associated with one or more IRSs based at least in part on the first set of information received from the one or more UEs. The one or more network devices are configured to communicate the calculated IRS slope information to the one or more IRSs via a network interface, and the IRS slope information is used to control one or more aspects of operation of the one or more IRSs.
[0090] FIG. 6 illustrates a DUI (DU-IRS) interface protocol stack 600 according to an embodiment of the present disclosure. As shown, the protocol stack includes a radio control layer 604 and a transport control layer 606. The radio control layer 604 includes a (DU-IRS) DUI-AP (Application Protocol) layer 608. The transport control layer includes a physical layer 610, a data link layer 612, an IP layer 614, and a stream control transmission protocol 616. In an embodiment, a network device (524) or a BS establishes a DUI (DU-IRS) protocol stack to enable communication between the BS and the IRS for configuration, setup, and control purposes, as described herein. Various configuration messages having specific formats may be used to support communication protocols in the context of a 6G network.
[0091] In an embodiment, the DUI may be implemented as a logical or physical interface between the DU and the IRS controller. The disclosed DUI protocol stack is implemented on both ends of the DUI interface. For example, one implementation is on the DU side and the other implementation is on the IRS controller side. The transport network layers, including the physical layer, the data link layer, the IP layer, and the SCTP layer, may be implemented according to standard definitions known in the art. In an embodiment, the radio network layer, including the DUI-AP, which is a DU-IRS interface application component, implements a layer 3 control protocol. The procedures and messages related to the DUI-AP are described in detail with reference to the sequence diagrams shown in Figures 7a to 7d. For example, the protocol communication messages include "DUI LINK SETUP REQUEST" and "DUI LINK SETUP RESPONSE" shown in Figure 7a, "DUI LINK CONFIGURATION UPDATE" and "DUI LINK CONFIGURATION UPDATE CONFIRM" shown in Figure 7b, "IRS RESOURCE COMMAND" and "IRS RESOURCE COMMAND ACCEPT" shown in Figure 7c, and "IRS ACTIVATION COMMAND" and "IRS ACTIVATION COMMAND ACCEPT" shown in Figure 7d. The proposed protocol communication messages are part of the proposed DUI-AP protocol.
[0092] In an embodiment, the DUI-AP may be realized by an initial set of procedures used in the DUI I / F, as shown in Figures 7a to 7g.
[0093] 7a shows that a DU I / F setup procedure 700 is initiated by an IRS controller 704 towards a 6g-NB-DU 702 to establish a DUI link. In an embodiment, when a new IRS appears or becomes active or available, the corresponding IRS controller (e.g., 704) shares / sends its capabilities to the 6g-NB-DU 702 via a setup request message. The 6g-NB-DU 702 authenticates the new IRS, assigns a unique IRS ID, and issues an "Activate" command to the IRS controller 704 by sending a setup response message. The IRS controller 704 updates its table with the ID and the status is set to "Active".
[0094] Fig. 7b shows the DU I / F configuration update procedure 706. This procedure is initiated by the IRS Controller 704 towards the 6g-NB-DU 702 to update the change in the capabilities of the IRS Controller 704. In an embodiment, the IRS Controller 704 shares its updated capabilities to the 6g-NB-DU 702 via a "Configuration update" message. The 6g-NB-DU 702 updates its IRS-UE table, sends the update to the associated 6g-NB-CU-CP, and issues an "Activate / Deactivate" command based on the update to the IRS Controller 704 by sending a "Configuration update confirm" message. The IRS Controller 704 then stays in the "Activate / Deactivate" status according to the received command.
[0095] FIG. 7c shows an IRS resource command procedure 708. This procedure is initiated by the 6g-NB-DU 702 towards the IRS controller 704 to command the reservation of antenna array elements for communication with the 6g-NB-DU 702 and also for direct communication with the UE. Thus, one set of antenna arrays (for a given IRS) may be reserved for communication with the 6g-NB-DU 702 for a particular UE, and another set of antenna arrays is reserved for direct communication with the UE. Here, the 6g-NB-DU 702 may share details such as horizontal and vertical beam widths, horizontal and vertical beam steering positions, altitude of the given UE to which the beam should be pointed, etc. Thus, the 6g-NB-DU 702 sends an IRS resource command message to the IRS controller 704. The IRS controller configures the antenna array of the IRS according to the received command, reserves the required antenna array elements, and responds to the 6g-NB-DU 702 by sending an IRS resource command accept message. The IRS resource command may also include a pre-coded matrix that provides the power and phase of each element that the IRS should employ to achieve the required directivity of the reflection of the signal from the base station. Upon receiving the IRS resource command accept message, the 6g-NB-DU 702 starts transmitting a beam towards the IRS and may or may not continue transmitting a direct beam towards the UE. The IRS controller 704 configures the IRS to start receiving the beam from the 6g-NB-DU 702 and begin to convert and transmit a direct beam towards the UE.
[0096] 7d shows an IRS activation command procedure 710. This procedure is initiated by the 6g-NB-DU 702 towards the IRS controller 704 to activate or deactivate the IRS. The 6g-NB-DU 702 sends an IRS activation command (activate / deactivate, validity time, etc.) message to the IRS controller 704. The IRS controller 704 sends an IRS activation command accept message to the 6g-NB-DU 702. The IRS controller 704 is configured to set the status of the IRS according to the received command. In an embodiment, this procedure is mainly used during energy saving scenarios and during maintenance scenarios.
[0097] Figures 7e-g show the initial set of procedures to support IRS. Figure 7e shows the DU configuration update procedure 712. This procedure is initiated by the 6g-NB-DU 702 towards the 6g-NB-CU-CP 714 to show the latest set of deployed IRSs and their details. In an embodiment, the 6g-NB-CU-CP 714 creates entries for the new IRSs, assigns each a unique IRS ID and updates the details of any other IRSs already present in the IRS-Cell mapping table. The 6g-NB-CU-CP 714 responds with a DU configuration update confirm with a list of newly assigned IRS-IDs associated with the newly established IRSs. The 6g-NB-DU 702 updates its table with the IDs and the status of the respective IRS is set to active.
[0098] FIG. 7f shows an IRS proximity indication procedure 716. This procedure 716 is initiated by the 6g-NB-CU-CP 714 towards the 6g-NB-DU 702 whenever one or more UEs (e.g., 718) are detected in the vicinity of the coverage of a particular IRS to start coordinating with a particular IRS in relation to those UEs. The 6g-NB-DU 702 receives the IRS proximity indication along with a list of UEs associated with the list of IRSs, reserved IRS resources, etc. After receiving the IRS proximity indication message, the 6g-NB-DU 702 updates its table with a list of UEs according to their mapping with the respective IRSs. The 6g-NB-DU 702 further starts requesting those UEs (e.g., 718) to transmit their location information along with channel status information (CSI). The scheduler module of the 6g-NB-DU 702 starts using the reserved IRS sources for its use towards a particular set of UEs (e.g., 718).
[0099] FIG. 7g shows an IRS Activate Command procedure 720. This procedure is initiated by the 6g-NB-CU-CP 714 towards the 6g-NB-DU 702 to activate or deactivate the IRS. As shown, the 6g-NB-CU-CP 714 sends an IRS Activate command [activate / deactivate, validity time, etc.] to the 6g-NB-DU 702. The 6g-NB-DU 702 initiates the IRS Activate / Deactivate procedure towards the IRS controller as described above. The 6g-NB-DU 702 sends an IRS Activate Command Accept message to the 6g-NB-CU-CP 714. This procedure may be primarily used during energy saving scenarios and also during maintenance scenarios.
[0100] In an embodiment, an initial set of procedures to support IRS is performed by the 6g-NB-CU-CP using Radio Resource Control (RRC) Connection Reconfiguration. The RRC Connection Reconfiguration procedure is used by the 6g-NB-CU-CP to configure measurement control to add the UE's location information to one or more measurement reports. After receiving this request, the UE starts adding its location information to all subsequent measurement reports. In an alternative embodiment, along with the previous proximity indication procedure, the UE can start adding location information either through a measurement report or using a proximity indication message when it detects that it is approaching or entering an IRS coverage area.
[0101] The present disclosure relates to a system and method for implementing an Intelligent Reflective Surface (IRS) in 5G and beyond networks. The system may include a network device including one or more processors that may enable the system to establish a network interface protocol with the IRS. In an embodiment, a DU-I interface is established between the network device and the IRS, and various setup procedures may be performed using the DU-I interface. Using the proposed network interface, the network device may enable the setup of an IRS available to reflect signals to one or more UEs in a particular region or area. A mapping of one or more parameters of the IRS to mechanical or digital tilts for optimal performance is pre-determined and stored in the network device. The network device receives one or more measurement reports from one or more UEs to determine at runtime an optimal mechanical or digital tilt based at least in part on the pre-determined mapping. The network device sends the optimal mechanical or digital tilt information to the IRS using the proposed network interface, and the IRS controller uses the optimal tilt information to realign its panels or tiles.
[0102] An embodiment of a non-transitory computer readable medium (CRM) is disclosed. The CRM includes one or more instructions stored on the CRM that, when executed by a processor, causes a process to perform a set of steps. For example, execution of the set of instructions causes the processor to calculate IRS slope information associated with one or more IRSs based at least in part on a first set of information received from one or more UEs, and communicate the calculated IRS slope information to the one or more IRSs via a network interface, where the IRS slope information is used to control one or more aspects of operation of the one or more IRSs. In an embodiment, the first set of information includes one or more of signal-to-interference-and-noise ratio (SINR) information, reference signal received power (RSRP) information, reference signal received quality (RSRQ) information, location and channel quality indicator (CQI) information.
[0103] 8a-8c show a set of UE procedures to support the IRS architecture disclosed herein. In an embodiment, the handover mechanism is disclosed for a B5G (Beyond 5G -- i.e., 5G / 6G network) network -- the IRS controller is also part of the network architecture as described above. Such a network needs to collect one or more measurement reports including RF reports indicating the raw power seen by the UE in the form of Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), SINR, and Channel Quality Indicator (CQI) or Channel State Information (CSI) reports indicating the channel quality of the serving cell.
[0104] One or more measurement reports collected by the BS (or network device) assist the network to receive an appropriate call to handover a given UE (e.g., UE 544) to another cell or to another IRS controller in the same cell coverage (i.e., cell edge scenario). The present disclosure assumes various scenarios to illustrate the approach, as shown in Fig. 8a-8c. For example, UE1 is moving, connected to 6G-NB-DU-1 (i.e., cell 1) and in connected / active state. UE1 starts to move away from the coverage of 6G-NB-DU-1 (cell 1) and is now in the vicinity of the coverage of IRS-1. In such a case, UE1 needs to be handed over to the IRS-1 controller for further data transmission / reception. In an embodiment, the following data points and action flows need to be considered in the following order: 1. The UE looks for a pilot signal from an IRS controller (e.g., corresponding to IRS-1) and is then configured with a trigger point to start measurements. 2.Identification of the reflected signal / data by the IRS controller using IRS ID. 3. The IRS ID must be transmitted in the SIB1 portion of the pilot signal. 4. The UE measures the CQI / CSI of the serving cell and the RSRP / RSRQ of the signal received by the IRS. 5. The UE sends measurement reports based on configured trigger events and / or periodic timers. 6. The handover procedure is completed based on criteria set on the network side.
[0105] In an embodiment, the UE 544 is configured with one or more trigger points for the UE to look for pilot signals from an IRS controller (e.g., 704) and then initiate corresponding measurements. Thus, the UE may be configured with an event-based trigger of measurements (when an IRS is available in the same cell edge case and for handover), or even a periodic timer-based trigger. In an exemplary embodiment, one or more exemplary events may be configured to trigger the measurement of the IRS. Such an exemplary event includes event I1, when the serving cell's RSRP / RSRQ falls below a preconfigured specific threshold. Another exemplary event may be event I2, when the serving cell CQI index in the CSI report falls below a threshold or leads to the use of QPSK. Yet another exemplary event may be event I3, when a neighboring cell provides better signal strength than the serving cell.
[0106] In an embodiment, such exemplary events (i.e., I1 to I3) may be triggered based on the availability of an IRS in a given cell with a given approximate coverage. In another embodiment, a new mechanism is proposed to specify whether the regular event A1 or the preconfigured event I1 needs to be triggered.
[0107] 8a shows a UE procedure for supporting IRS according to an embodiment. In one case, UE 802-1 shares and verifies the availability of a given IRS. When event A1 or other events (Ax) are triggered, UE 802-1 shares location information together with accuracy level with the network (CU-CP 804) as part of the RRC message container IEI.
[0108] The CU-CP 804 checks for the presence of IRS availability, configures event I1 or sends a new RRC message (i.e., StartIRSMeas_IE) as an RRC container, and then configures the IRS controller to start reflecting pilot signals over the DLCCH configured for SIB1 so that the UE can detect the IRS ID and further prepare a measurement report (MR). The UE 802 then measures the RF to check whether the event (e.g., I1) is still valid and therefore the event Ix is triggered. If the UE 802-1 does not support GPS, the UE shares location information using C-plane or U-plane (SUPL) methods and measurements based on CellID, eCellID, OTDOA, etc.
[0109] FIG. 8b shows a UE procedure for RRC measurement report according to an embodiment. For example, when event A1 is triggered, UE 802-1 sends a measurement report together with location information. The network device identifies that UE 802-1 is within the coverage area of the IRS, configures event I1 or sends a new RRC message (StartIRSMeas_IE) as an RRC container, and then configures the IRS controller to start reflecting pilot signals by DLCCH configured for SIB1 so that UE 802-1 can detect the IRS ID and further prepare MR. The RRC_MessageContainer IE may correspond to {{StartIRMeas_IE:BOOLEAN{}}. Similarly, MR (measurement report) may be sent by UE 802-1 based on the configuration, which may also be performed based on a periodic timer configured for a given UE. The procedure includes identification of the signal / data reflected by the IRS controller using the IRS ID. Similar to the cell ID, the IRS may be identified using the IRS ID that is a broadcasted part of the pilot signal / SIB1. The part of SIB1 containing PLMN-IdentityInfo -- CellAccessRelatedInfo -- is obtained. This IE contains the CellIdentity of the given Cell. Therefore, the same IEI is used to convey the IRS ID of the IRS controller. This becomes the identifier of the IRS for further processing at the UE level. This IRS ID can be sent instead of the Cell ID or together with the Cell ID according to a mapping table present in the DU / CU related to IRS ID and Cell ID.
[0110] In an embodiment, referring to Fig. 8c, the IRS ID needs to be transmitted in the SIB1 part of the pilot signal. Assuming that the controller of the IRS has sufficient computing power, there may be two possible ways to encode the IRS ID into the SIB1 transmitted in the pilot signal.
[0111] In the first option, the IRS ID is pre-coded into the SIB1 signal on the CU-CP side (RRC) when it is pre-determined to transmit it via an IRS reflector to the UE 802. In this way, the IRS can simply reflect the signal based on a previously received configuration.
[0112] In the second option, the IRS ID is encoded after decoding it when received from the CU-DU (gNodeB) and inserted into the SIB1 message, which is then transmitted to the UE 802 indicated by its IRS reflector according to the received configuration. In an embodiment, the UE measures the CQI / CSI of the serving cell and the RSRP / RSRQ of the signal received by the IRS. When the UE detects that an event is triggered or a timer expires, it starts sniffing the pilot signal from the IRS reflector and after reading SIB1, the IRS ID is detected. Once the IRS ID is known and the raw power measurement is made, the UE 802 makes it part of the measurement report -- part of the CSI report -- that is transmitted to either the RRC of the CU-CP and / or other MAC schedulers of the DU.
[0113] CSI to MAC Scheduler -- When the DU MAC scheduler receives the CSI report and identifies to downgrade the modulation scheme to QPSK, it indicates the RRC for handover of the UE to the IRS based on the location information made available in the CSI report, which is mapped to the availability of coverage of the IRS. If the location information is not available in the UE 802, the DU MAC scheduler can connect to the RRC via the DU-CU interface to get the location information of the UE and check whether the UE is under the coverage of the IRS, and if the response is YES, the RRC can trigger the handover.
[0114] In an embodiment, the UE is configured to send measurement reports based on configured trigger events and / or periodic timers and handover procedures that are completed based on criteria set on the network side. In an embodiment, the measurement reports can be of two types: NR measurement reports to the RRC of the CU-CP based on the received configuration, and CSI reports on the serving cell to the MAC scheduler.
[0115] Based on the CSI report where the CQI index falls below the configured threshold, i.e., an index reflecting the use of QPSK, the gNodeB needs to allocate more PRBs to maintain the TP. In such a case, when the gNodeB recognizes that the UE is in the vicinity of the IRS, it starts to reflect the pilot signal with pre-coded SIB1. Now, the UE measures the raw power of the IRS as seen by the UE and records it in the NR measurement report. Based on the measurement report, a handover to the IRS is triggered by the CU-CP -> DU.
[0116] Similarly, the MR may be transmitted by the UE based on a configuration that may also be performed based on a periodic timer configured for a given UE. The IE may be modified to reflect the above configuration for the new event trigger.
[0117] FIG. 9 illustrates an example IRS sharing scenario 900 in which a single IRS 904 may be shared by one or more cells in a 5G / 6G network. In an embodiment, different parts of the IRS may be reserved by different base stations (e.g., 902-1, 902-2) with overlapping network coverage. The IRS 904 is in a common overlapping area for multiple base stations. Due to the intelligent system and method implemented in the IRS 904, different parts of the IRS 904 may be reserved or utilized to bounce or regenerate respective signals from the BS towards respective UEs being served by the BS. This mechanism has the advantage of optimal utilization and deployment of the same IRS resources without compromising service quality. As mentioned above, the proposed DU I / F enables the BSs (902-1, 902-2) to set up and configure the IRS 904 in the 5G network and subsequent networks (6G network).
[0118] In an exemplary embodiment, an IRS controller of an IRS 904 allows different BSs to configure parts of the IRS 904 while maintaining exclusivity without interference with other parts. In an embodiment, various identification mechanisms for uniquely identifying one or more parts may be implemented by the IRS controller to uniquely identify and address one or more parts. Also, the mapping between the various parts and the corresponding BSs may be either stored locally in the IRS 904 or may be stored in a central location accessible to participating BSs. In an embodiment, there may be a limit on the maximum number of BSs that can share a given IRS depending on parameters such as, but not limited to, the dimensions of the IRS 904, the separation of different parts from each other, hardware / software requirements for individual control of each part, etc. In an embodiment, the part of the IRS 904 utilized by a first BS (e.g., 902-1) may be released for further reconfiguration for use by a second BS (e.g., 902-2) after a predetermined period of time or based on the usage pattern of the reserved part. Such reconfiguration may occur while another portion of the IRS 904 is still being utilized by a third BS. Reconfiguration of a portion of the IRS by a BS follows the same configuration procedures described herein.
[0119] In an exemplary embodiment, the IRS microcontroller intelligently maintains a mapping of the different portions to different BSs. Such a mapping may be either stored locally in the IRS or shared with participating BSs, either on demand or as part of the initial discovery / setup procedure of the IRS. To this end, the BS may request or query the IRS regarding the availability of resources (i.e., portions of the IRS) according to signal strength and directivity requirements in the context of a particular UE that needs to be served by the BS. In an embodiment, the sharing of the portions of the IRS is based on a one-time configuration setup procedure at deployment time, and the portions are not released or reconfigured later.
[0120] Referring to FIG. 9, UE1 is connected to a cell of gNB1 (902-1), and UE2 is connected to a cell of gNB2 (902-2), and the UEs experience direct signal degradation from the respective cells. Since these two UEs are under the coverage of the same IRS controller (corresponding to IRS 904), the resources of IRS 904 can be shared with both cells either statically or dynamically. When UE1 and UE2 report their location information to their respective gNB-CU-CPs, the gNB-CU-CPs check their respective IRS-cell mapping tables and find that the coverage of the same IRS is applicable to both cells. Thus, the gNB-CU-CPs may decide to share common IRS resources between these two cells. In an embodiment, the gNB-CU-CP may use an internal AI / ML strategy to determine to reserve "X%" of IRS antenna resource elements for cell1 and "Y%" of IRS antenna resource elements for cell2. This reservation of IRS antenna element resources is communicated to the respective gNB-DU by 6G-F1 interface procedures. In an embodiment, the gNB-DU further requests the UE to report location information along with the CSI information and dynamically makes a decision on whether to use the IRS 904 to enhance the UE experience.
[0121] When a UE moves out of the IRS coverage area, the gNB-CU-CP informs each gNB-DU to release the reserved IRS resources and plan its future scheduling accordingly. As shown, gNB1 (902-1) transmits a direct beam 906-1 toward its shared IRS resources of IRS 904, and gNB2 (902-2) transmits a direct beam 906-2 toward its shared IRS resources of IRS 904. Furthermore, gNB1 (902-1) transmits a direct beam 908-1 toward UE1, and gNB2 (902-2) transmits a direct beam 908-2 toward UE2, and both UE1 and UE2 suffer from attenuated (direct) signals. Furthermore, a corresponding reflected / regenerated beam 910-1 is directed toward UE1, and a corresponding reflected / regenerated beam 910-2 is directed toward UE2.
[0122] FIG. 10 illustrates an exemplary computer system in which embodiments of the present invention may be utilized, according to an embodiment of the present disclosure. As illustrated in FIG. 10, computer system 1000 may include an external storage device 1010, a bus 1020, a main memory 1030, a read-only memory 1040, a mass storage device 1050, a communication port 1060, and a processor 1070. Those skilled in the art will appreciate that a computer system may include more than one processor and communication port. The processor 1070 may include various modules related to embodiments of the present invention. The communication port 1060 may be an RS-232 port for use with a modem-based dial-up connection, a 10 / 100 Ethernet port, a gigabit or 10 gigabit port using copper or fiber, a serial port, a parallel port, or any other existing or future port. The communication port 1060 may be selected depending on the network, such as a local area network (LAN), a wide area network (WAN), or any network to which the computer system connects. Memory 1030 can be a random access memory (RAM) or any other dynamic storage device commonly known in the art. Read-only memory 1040 can be any static storage device, such as, but not limited to, a programmable read-only memory (PROM) chip for storing static information, such as start-up or BIOS instructions for processor 1070. Mass storage 1050 can be any current or future mass storage solution that can be used to store information and / or instructions.Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid state drives (internal or external, e.g., having a Universal Serial Bus (USB) and / or Firewire interface), one or more optical disks, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., a SATA array).
[0123] Bus 1020 communicatively couples processor 1070 to other memory, storage, and communication blocks and can be, for example, a Peripheral Component Interconnect (PCI) / PCI-Extension (PCI-X) bus for connecting expansion cards, drives, and other subsystems, a Small Computer System Interface (SCSI), USB, etc., as well as other buses such as a Front Side Bus (FSB) that connects processor 1070 to a software system.
[0124] Optionally, operator and management interfaces, such as a display, keyboard, and cursor control devices, may also be coupled to bus 1020 to support direct operator interaction with the computer system. Other operator and management interfaces may be provided through a network connection connected via communications port 1060. The above-mentioned components are intended only to illustrate various possibilities. The above-mentioned exemplary computer system should in no way limit the scope of the present disclosure.
[0125] FIG. 11 illustrates an exemplary RAN architecture 1100 in which an IRS manager 1102 is deployed as a centralized standalone entity that communicates with a gNB-CU-CP via a CCIM interface [CCIM: CU-CP-IRS Manager], according to an embodiment. Here, the IRS manager 1102 uses the CCIM interface to collect UE measurement reports, location information, scheduling data, etc. from the gNB-CU-CPs (e.g., 1104-1, 1104-p). Additionally, the IRS manager 1102 uses the CCIM interface to share decisions regarding shared IRS resources with the gNB-CU-CPs, which forward the decisions to the gNB-DUs (e.g., 1108-1, 1108-2..., 1108-N) via a 6G F1 interface. In an embodiment, the IRS manager 1102 can handle multiple gNB-CU-CPs. As shown in FIG. 11, each of the gNB-DUs includes an IRS-UE mapping table (e.g., 1110-1, 1110-2, ..., 1110-N). Each of the IRS-UE mapping tables includes a mapping between various UEs being served and the IRS resources being utilized by the IRS to serve the UEs. As shown, the mapping information may be shared with an IRS controller 1112 of a given IRS (e.g., 1114) over a DUI interface. The IRS controller 1112 configures the shared IRS 1114 accordingly to appropriately allocate / assign IRS shared resources (e.g., 1116-1, 1116-2, ..., 1116-N) for cell-1, cell-2, ..., cell-N. It may be noted that the IRS manager 1102 may be implemented as a network device having one or more processors coupled to a memory that stores a set of instructions that, when executed by the one or more processors, cause the IRS manager 1102 to perform the described functions of the IRS manager 1102. It may be noted that the IRS controller 1112 may be similar to the IRS controller 704 described above.
[0126] FIG. 12 illustrates an exemplary RAN architecture 1200 in which an IRS manager is implemented as a distributed entity co-located with a gNB-CU-CP, according to an embodiment. Here, an IRS manager (e.g., 1102-A, 1102-B) can communicate with its gNB-CU-CP (e.g., 1104-1, 1104-P) via an internal CCIM interface that may be specific to a given implementation. In an embodiment, an IRS manager (e.g., 1102-A) can only handle one gNB-CU-CP (e.g., 1104-1) with which it is co-located. If IRS sharing needs to be supported across multiple gNB-CU-CPs, the messages defined above need to be defined for the 6G Xn interface, and those messages are used for a given IRS manager (e.g., 110-2A) to communicate with a peer IRS manager (e.g., 1102-B) via the Xn interface. Subsequent communication and operation continues in a similar manner as described with reference to FIG. 11 above. It may be noted by those skilled in the art that the embodiment described and illustrated in Figure 12 contemplates integration of the IRS manager into the gNB-CU-CP (e.g., 1104-1, 1104-P), thereby making the IRS manager, for example, part of the base station or network device 524 illustrated in Figure 5B. Various other implementations may be possible without departing from the scope of the ongoing description.
[0127] FIG. 13 illustrates an example RAN architecture 1300 in which an IRS manager is implemented as a centralized entity, according to an embodiment. In an embodiment, the IRS manager may be implemented as a static IRS manager 1304 and / or a dynamic IRS manager 1308. Furthermore, the dynamic IRS manager 1308 is part of the Near-RT RIC 1306 and is configured to handle dynamic sharing of IRS resources. In an embodiment, the dynamic IRS manager 1308 communicates with the gNB-CU-CPs (e.g., 1104-1, 1104-P) via their respective E2 interfaces. In an embodiment, all communication needs for the dynamic IRS manager 1308 will be contained within the E2 interface. Also, in an embodiment, the static IRS manager 1304 may be implemented as part of the SMO 1302, which may handle static sharing of IRS resources. Communication between the static IRS manager 1304 of the SMO 1302 and the gNB-CU-CP (e.g., 1104-1, 1104-P) may occur over an O1 interface as shown. Subsequent communication and operation continues in a manner similar to that described with reference to FIG. 11 above. Various other implementations may be possible without departing from the scope of the ongoing description.
[0128] 14 illustrates an exemplary common communications interface module (CCIM) interface protocol stack according to an embodiment. In an embodiment, the disclosed IRS architecture for sharing IRS resources may require a protocol stack for communication between a radio network layer 1402 and a transport network layer 1404. As shown, the radio network layer protocols 1402 include a common communications interface module (CCIM) application program interface (API) layer 1406. As shown, the transport network layer protocols include a stream control transmission protocol (SCTP) layer 1408, an internet protocol layer 1410, a data link layer 1412, and a physical link layer 1414.
[0129] 15a-15d show an exemplary initial set of procedures that may be used in a CCIM interface according to an embodiment. Referring to FIG. 15a, a measurement report update procedure 1500 is shown. As shown, this procedure 1500 is used by the gNB-CU-CP 1104 to update and share UE measurement reports with an IRS manager (e.g., 1102). In an embodiment, the measurement reports may also carry location information of the UE. A measurement report update message is sent from the gNB-CU-CP to the IRS manager. In an embodiment, the message may include a list of cells being served, a list of UEs with poor SINR or below a predefined threshold, location information of such UEs, and a list of IRS IDs to which these UEs belong.
[0130] 15b, a scheduling data request procedure 1502 is shown. This procedure 1502 is used by the IRS manager 1102 to request the gNB-CU-CP 1104 to share MAC scheduler data for a list of UEs (suffering from poor signal reception). In an embodiment, a scheduling data request message is sent from the IRS manager 1102 to the gNB-CU-CP 1104. In an embodiment, the scheduling data request message may include a list of cells, a list of UEs with poor SINR or below a predefined threshold, and the number of TTIs for which scheduling data is requested.
[0131] 15c, a scheduling data response procedure 1504 is shown. This procedure 1504 is used by the gNB-CU-CP 1104 to update the IRS manager 1102 with MAC scheduler data. In an embodiment, this scheduling data response message is sent from the gNB-CU-CP 1104 to the IRS manager 1102. In an embodiment, the message may include a list of cells, a list of UEs, the amount of data yet to be scheduled for these UEs, a balanced packet delay budget (PDB) for the data to be scheduled, an assigned modulation and coding scheme (MCS), and received channel status information (CSI) information.
[0132] 15d, an IRS resource command procedure 1506 is shown. This procedure 1506 is used by the IRS manager 1102 to command the allocated IRS resources to the gNB-CU-CP 1104. In an embodiment, a message is sent by the IRS manager 1102 to the gNB-CU-CP 1104. In an embodiment, the message may include a list of cells, a list of UEs, an allocation portion of the IRS resources allocated to each cell, and a validity time for the allocation of the IRS resources.
[0133] 16a-b show 6G F1 interface procedures that may be required to be supported for the IRS sharing feature. Referring to FIG. 16a, a scheduling data request procedure 1600 is shown. This procedure 1600 is used by the gNB-CU-CP 1104 to request the gNB-DU 1108 to share MAC scheduler data for a list of distressed UEs. In an embodiment, this scheduling data request message is sent from the gNB-CU-CP 1104 to the gNB-DU 1108 and may include a list of cells, a list of UEs with poor SINR, and the number of TTIs for which scheduling data is requested.
[0134] 16b, a scheduling data response procedure 1602 is shown. This procedure is used by the gNB-DU 1108 to update the gNB-CU-CP 1104 with MAC scheduler data. This scheduling data response message is sent from the gNB-DU 1108 to the gNB-CU-CP 1104. In an embodiment, the message may include a list of cells, a list of UEs, the amount of data not yet scheduled for these UEs, a balanced PDB for the data to be scheduled, the assigned MCS, and received CSI information.
[0135] It may be noted that these IRS sharing related procedures may be included within the E2 interface and O1 interface to support IRS manager functions when those IRS manager functions are supported in the quasi-RT RIC and SMO, respectively, as shown and described in the architecture above with reference to FIG. 13 .
[0136] FIG. 17 illustrates an exemplary sequence of steps of a method 1700 for sharing IRS resources of an IRS in a 5G / 6G communication network. In an embodiment, the method 1700 includes, at step 1702, receiving a CCIM measurement report update message by the IRS manager 1102 from the CU-CP 1104. At step 1704, the IRS manager 1102 detects that UEs from different cells are experiencing consistently poor SINR and that these UEs are within the coverage of the same IRS (e.g., 904). A CCIM scheduling data request sent via the CCIM-API layer includes a list of cell IDs, a list of UEs, and a number of TTIs. At step 1706, a scheduling data request message is sent via the 6G F1 interface by the IRS manager 1102 to the CU-CP 1104 via the CCIM-API interface. In steps 1708 and 1710, the CU-CP 1104 sends a scheduling data request message to the DU-1 1108-1 and the DU-2 1108-2, respectively, via the 6G F1 interface. In steps 1712 and 1714, the DU-1 1108-1 and the DU-2 1108-2 send a scheduling data response message, including the amount of data to be scheduled, the balanced PDB, the allocated MCS, and the received CSI, to the CU-CP 1104, respectively, via the 6G F1 interface. In step 1716, the CU-CP 1104 sends a scheduling data response CCIM message to the IRS manager 1102 via the CCIM-API interface. In step 1718, the IRS manager 1102 derives the determined allocation portion of the IRS resources for each cell being served based on the received scheduling data. In step 1720, the IRS manager 1102 sends an IRS resource command via the CCIM API interface, including a list of cell IDs, a list of UEs, a list of IRS resources assigned to each cell, and a validity time.In steps 1722 and 1724, the CU-CP 1104 sends an IRS resource command including a list of cell IDs, a list of UEs, a list of IRS resources allocated to each cell, and an effective time to the DU-1 1108-1 and the DU-2 1108-2, respectively, via the 6G F1 interface. In steps 1726 and 1728, the MAC schedulers of the DU-1 1108-1 and the DU-2 1108-2, respectively, start to use the allocated IRS resources for all their UEs under the coverage of the IRS. In steps 1730 and 1734, the DU-1 1108-1 and the DU-2 1108-2 send their respective IRS resource commands to the IRS controller 1112. In steps 1732 and 1736, the IRS controller 1112 generates an appropriate beam for each UE according to the IRS resource commands received in steps 1730 and 1734, respectively.
[0137] Although considerable emphasis has been placed herein on the preferred embodiment, it will be understood that many embodiments can be made and that many modifications can be made to the preferred embodiment without departing from the principles of the invention. These and other modifications of the preferred embodiment of the invention will become apparent to those skilled in the art from the disclosure herein, whereby it will be clearly understood that the foregoing illustrative matter is undertaken merely as an illustration of the invention, and not as a limitation.
[0138] Advantages of the present disclosure The present disclosure provides efficient, simultaneous, and improved communications in next generation networks (eg, 6G) by utilizing an IRS architecture.
[0139] The present disclosure provides systems and methods for eliminating the need for costly deployment of base stations for improved coverage in areas having one or more obstructions.
[0140] The present disclosure provides an economical next generation based system and method that can avoid problems faced by UEs due to poor signals, signal degradation, and lack of coverage.
[0141] The present disclosure provides an effective system and method that can enable seamless quality of service regardless of the user's location.
[0142] The present disclosure provides systems and methods for sharing IRS resources of an IRS among multiple base stations to serve one or more cells. [Explanation of symbols]
[0143] 100 Typical IRS Deployment Scenarios 102 IRS 104a base station 104b base station 106a Access Point 106b Access Point 200 IRS Deployment 202 RIS-Supported Unmanned Aerial Vehicles (UAVs) 204 IRS Deployment 206 IRS Deployment 208 IRS Deployment 210 IRS Deployment 212 IRS Deployment 300 IRS Coverage Scenarios 302-1 IRS-1 302-2 IRS-2 302-N IRS-N 304 base station 306 DUI Interface ("DUI I / F") 402 Base Station 404 IRS 406 Microcontroller 500 Functional Architecture 502-1 IRS-1 502-2 IRS-2 502-3 IRS-3 504 DUI I / F 506-1 6g-NB-DU (6G base station node DU) 506-M 6g-NB-DU (6G Base Station Node DU) 508 6g-F1 interface 510-1 6g-NB-CU (6G base station node CU) 510-P 6g-NB-CU (6G base station node CU) 512 6G-XN interface 514-1 IRS-Cell Mapping Table 514-P IRS-Cell Mapping Table 516 SNMP / TR069 / O1 interface 518 EMS 520 6G-NG interface 522 6th Generation Code (6GC) 524 Network Devices 526 processor 528 Memory 530 IRS Setup Module 532 IRS Configuration Module 534 Resource Command Module 536 IRS Activation Module 538 DU Configuration Module 540 Proximity Notification Module 542 RRC Configuration Module 544 UE 546 processor 548 Memory 550 Measurement Module 552 Trigger Point Module 554 Identification Module 556 Reporting Module 558 GPS / Location Module 600 DUI (DU-IRS) interface protocol stack 604 Radio Control Layer 606 Transport Control Layer 608 (DU-IRS) DUI-AP (Application Protocol) Layer 610 Physical Layer 612 Data Link Layer 614 IP Layer 616 Stream Control Transmission Protocol 700 DU I / F setup procedure 702 6g-NB-DU 704 IRS Controller 706 DU I / F configuration update procedure 708 IRS Resource Command Procedures 710 IRS Activation Command Procedure 712 DU configuration update procedure 714 6g-NB-CU-CP 716 IRS Proximity Indication Procedures 718UE 720 IRS Activation Command Procedure 802-1 UE 804 CU-CP 900 IRS Sharing Scenario 902-1 Base station 902-2 Base station 904 IRS 906-1 Direct Beam 906-2 Direct Beam 908-1 Direct Beam 908-2 Direct Beam 910-1 Reflected / Regenerated Beam 910-2 Reflected / Regenerated Beams 1000 Computer Systems 1010 External Storage Device 1020 Bus 1030 Main memory 1040 Read-only memory 1050 Mass Storage Device 1060 communication port 1070 processor 1100 RAN Architecture 1102 IRS Manager 1102-A IRS Manager 1102-B IRS Manager 1104-1 gNB-CU-CP 1104-P gNB-CU-CP 1108-1 gNB-DU 1108-2 gNB-DU 1108-N gNB-DU 1110-1 IRS-UE mapping table 1110-2 IRS-UE mapping table 1110-N IRS-UE Mapping Table 1112 IRS Controller 1114 IRS 1116-1 IRS Shared Resources for Cell-1 1116-2 IRS Shared Resources for Cell-2 1116-N IRS Shared Resources for Cell-N 1200 RAN Architecture 1300 RAN Architecture 1302 SMO 1304 Static IRS Manager 1306 Semi-RT RIC 1308 Dynamic IRS Manager 1402 Wireless Network Layer 1404 Transport Network Layer 1406 Common Communications Interface Module (CCIM) Application Program Interface (API) Layer 1408 Stream Control Transmission Protocol (SCTP) Layer 1410 Internet Protocol Layer 1412 Data Link Layer 1414 Physical Link Layer 1500 Measurement report update procedure 1502 Scheduling data request procedure 1504 Scheduling Data Response Procedure 1506 IRS Resource Command Procedures 1600 Scheduling Data Request Procedure 1602 Scheduling Data Response Procedure 1700 methods
Claims
1. 1. A network device for sharing Intelligent Reflective Surface (IRS) resources of an Intelligent Reflective Surface (IRS) in a communication network, comprising: When executed by one or more processors, the network device receiving a scheduling data request from an IRS manager, the IRS manager transmitting the scheduling data request when the IRS manager determines poor signal reception by a plurality of user equipments (UEs) based at least in part on measurement reports received from the network device corresponding to each of the plurality of UEs; sending a scheduling data response to the IRS manager in response to the received scheduling data request; receiving an IRS resource command from the IRS manager, the IRS manager sending the IRS resource command in response to the scheduling data response; and and transmitting the received IRS resource command to an IRS controller associated with the IRS, the IRS controller being configured to allocate the IRS resources to each of the plurality of UEs based on the IRS resource command.
2. The network device of claim 1 , wherein the IRS manager transmits the scheduling data request when the IRS manager determines that the plurality of UEs are within coverage of the IRS.
3. 2. The network device of claim 1, wherein the measurement report includes a channel quality indicator (CQI) and channel state information (CSI) parameters of a serving cell, and reference signal received power (RSRP) information and reference signal received quality (RSRQ) parameters of a pilot signal received from the IRS by each of the plurality of UEs.
4. 10. The network device of claim 1, wherein the processor is configured to communicate with the IRS manager via a Common Communications Interface Module (CCIM) interface.
5. The network device of claim 1 , wherein the processor is configured to communicate with the IRS controller via a DUI interface.
6. 2. The network device of claim 1, wherein the scheduling data request includes a list of cell IDs of a serving cell, a list of the plurality of UEs, and a number of transmission time intervals (TTIs).
7. 2. The network device of claim 1, wherein the scheduling data response includes an amount of data to be scheduled, a balanced packet delay budget (PDB) for the scheduled data, an assigned modulation and coding scheme (MCS), and received channel status information (CSI).
8. 2. The network device of claim 1, wherein the IRS resource command includes a list of cell IDs, a list of UEs from the plurality of UEs, a list of IRS resources assigned to each cell, and corresponding validity times of assignment of IRS resources.
9. 10. The network device of claim 1, wherein the IRS manager is configured to derive a determined allocated portion of IRS resources for each served cell based on a received scheduling data response.
10. 10. The network device of claim 1, wherein the processor configures a MAC scheduler to begin using assigned IRS resources for the plurality of UEs under coverage of the IRS.
11. 1. A method for sharing Intelligent Reflective Surface (IRS) resources of an Intelligent Reflective Surface (IRS) in a communications network, comprising: receiving, by a network device, a scheduling data request from an IRS manager, the IRS manager sending the scheduling data request upon determining poor signal reception by a plurality of user equipments (UEs) based at least in part on measurement reports received from the network device corresponding to each of the UEs; sending, by the network device, a scheduling data response to the IRS manager in response to the received scheduling data request; receiving an IRS resource command from the IRS manager by the network device, the IRS manager sending the IRS resource command in response to the scheduling data response; and transmitting the received IRS resource command by the network device to an IRS controller associated with the IRS, the IRS controller being configured to allocate the IRS resources to each of the plurality of UEs based on the IRS resource command.
12. 12. The method of claim 11, wherein the measurement report includes a channel quality indicator (CQI) and a channel state information (CSI) parameter of a serving cell, and a reference signal received power (RSRP) information and a reference signal received quality (RSRQ) parameter of a pilot signal received from the IRS by each of the plurality of UEs.
13. 12. The method of claim 11, wherein the network device is configured to communicate with the IRS manager via a Common Communications Interface Module (CCIM) interface.
14. The method of claim 11 , wherein the network device is configured to communicate with the IRS controller via a DUI interface.
15. 12. The method of claim 11, wherein the scheduling data request includes a list of cell IDs of a serving cell, a list of the plurality of UEs, and a number of transmission time intervals (TTIs).
16. 12. The method of claim 11, wherein the scheduling data response includes an amount of data to be scheduled, a balanced packet delay budget (PDB) for the scheduled data, an assigned modulation and coding scheme (MCS), and received channel status information (CSI).
17. 12. The method of claim 11, wherein the IRS resource command includes a list of cell IDs, a list of UEs from the plurality of UEs, a list of IRS resources assigned to each cell, and corresponding validity times of assignment of IRS resources.
18. 12. The method of claim 11, further comprising: configuring, by the network device, a MAC scheduler for the plurality of UEs under coverage of the IRS to begin using allocated IRS resources.
19. 12. The method of claim 11, wherein the IRS manager is configured to derive a determined allocation portion of IRS resources for each served cell based on a received scheduling data response.
20. When executed by a processor included in a network device, the processor receiving a scheduling data request from an IRS manager, the IRS manager transmitting the scheduling data request when the IRS manager determines poor signal reception by a plurality of user equipments (UEs) based at least in part on measurement reports received from the network device corresponding to each of the plurality of UEs; sending a scheduling data response to the IRS manager in response to the received scheduling data request; receiving an IRS resource command from the IRS manager, the IRS manager sending the IRS resource command in response to the scheduling data response; and and a non-transitory computer-readable medium (CRM) including a set of instructions to cause an IRS controller associated with the IRS to transmit the received IRS resource command, the IRS controller being configured to allocate the IRS resources to each of the plurality of UEs based on the IRS resource command.
Citation Information
Patent Citations
Systems and methods using reflection-based communication elements - Patents.com
JP2025505409A