Dynamic Massive MIMO End-Device Pairing Based on Predicted and Real-Time Connection Conditions

Abstract

A computer-implemented method for grouping devices in a massive multiple-input and multiple-output (MIMO) based cellular network comprises determining mobility states of end devices within cells of the massive MIMO based cellular network, estimating payload requirements of the end devices, and grouping the end devices into groups based on the determined mobility states and the estimated payload requirements.

Description

[Background technology]

[0001] The present invention relates to massive multiple-input and multiple-output (MIMO), and more particularly, the present invention relates to dynamic massive MIMO end device pairing based on predicted and real-time connection conditions.

[0002] Massive MIMO is a key enabling technology for 5G and future wireless technologies to expand end device and wireless cell capacity, due in part to efficient time / frequency resource utilization by incorporating Multiple User-MIMO (MU-MIMO) modes. The use of multiple radio antennas allows for beam direction toward diverse end devices, with each beam spatially canceling interference from other beams. This in turn results in higher connection capacity for base stations.

[0003] In massive MIMO, the number of transmit and receive antennas is assumed to be large. Such a large number of antennas provides significant multiplexing and diversity gains, serving a large number of users in parallel. By increasing the number of transmit antennas, higher data rates can be achieved without increasing bandwidth, because adding multiple antennas provides a greater degree of freedom in the wireless channel, in addition to the time and frequency dimensions, to achieve higher data rates.

[0004] Massive MIMO with beamforming also tends to minimize intra- and inter-cell interference by narrowing and concentrating the radiated energy towards the intended user's direction.

[0005] There are two distinct MIMO cases: transmit diversity, in which the same data is simultaneously transmitted by multiple antennas to boost the signal-to-interference and noise ratio (SINR), and spatial multiplexing, in which independent data streams are transmitted to each antenna to increase capacity. Therefore, in practice, massive MIMO is expected to significantly increase capacity and service enhancement in cellular network environments. However, capacity and service enhancement are closely dependent on end device mobility, payload requirements, and the channel quality perceived by the end device. While cell capacity and service enhancement can be enhanced only by grouping end users, the perceived service quality is often reduced because the increased number of users may not follow orthogonality and may result in interference.

[0006] In a real environment, some end devices may have relatively no mobility, while others may have higher mobility. The current design of MU-MIMO functioning methods is very sensitive to end device mobility, and as a result, capacity gains and service enhancements are severely affected due to the high mobility of end devices.

[0007] Another problem arises when some end devices have limited user plane payload requirements, while others have higher user plane payload requirements. With current designs, MU-MIMO performance is relatively reduced in low payload scenarios; therefore, traffic needs to be considered with respect to MU-MIMO efficiency.

[0008] Another case revolves around the channel signal quality perceived by end devices at cell edge locations or in interference areas due to multiple servers. For different end devices, the quality may vary due to varying path loss, receiver sensitivity, or the type of device used. Each end device may have different capabilities, such as which specific carriers are supported, signal receiver sensitivity, etc. In this case, the channel estimation may not be optimal, and therefore the wrong MIMO mode may be selected. Due to this, even though the capacity of the radio cell would be significantly improved, the service experience may be unacceptable in this massive MIMO scenario.

[0009] Channel orthogonality between multiple end devices is an important criterion that creates user separability and enables the opportunity to simultaneously share radio frequency resources. With mobility, there is an additional requirement to adjust beamforming weight assignments not only to maintain signal power levels (e.g., beam quality) at the user side, but also to continuously limit inter-user interference experienced between users assigned the same radio resource allocation. The scheduler will also be unable to realize potential multiplexing gains, as fewer radio resource blocks will be shared among users in the same cell, reducing spectral efficiency.

[0010] In situations where MU-MIMO end device pairing is not optimal, typical effects include higher signaling, suboptimal radio resource control (RRC) message flow, battery drain, performance degradation, SRS resource consumption, etc. Summary of the Invention

[0011] According to one embodiment, a computer-implemented method for grouping devices in a massive multiple-input and multiple-output (MIMO) based cellular network comprises determining mobility states of end devices within cells of the massive MIMO based cellular network, estimating payload requirements of the end devices, and grouping the end devices into groups based on the determined mobility states and the estimated payload requirements.

[0012] A computer program product, according to one embodiment, comprises one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions having program instructions for performing the method described above.

[0013] The system, according to one embodiment, includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to perform the method described above.

[0014] Other aspects and embodiments of the present invention will become apparent from the following detailed description, which, when taken in conjunction with the drawings, illustrates by way of example the principles of the invention. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a diagram of a computing environment according to one embodiment of the present invention.

[0016] [Figure 2] 1 is a flowchart of a method according to one embodiment of the present invention.

[0017] [Figure 3] FIG. 1 is a diagram of an architecture for assessing the mobility state of an end device, according to one embodiment.

[0018] [Figure 4] 1 is a table correlating observations of movement states with time and corresponding labels of predictable or unpredictable, according to one embodiment.

[0019] [Figure 5] FIG. 1 is a diagram of an analysis system and the parameters fed into the analysis block, according to one embodiment.

[0020] [Figure 6] 1 is a diagram of a massive MIMO system with multiple base stations and an analysis layer, according to one embodiment.

[0021] [Figure 7] FIG. 7 is a diagram of the massive MIMO system of FIG. 6 after end device grouping has been performed, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0022] The following description is made for the purpose of illustrating the general principles of this invention and is not meant to limit the inventive concepts claimed herein. Moreover, particular features described herein can be used in combination with other described features, in each of the various possible combinations and permutations.

[0023] Unless otherwise specifically defined herein, all terms are to be given their broadest possible interpretation, including the meanings implied by this specification and the meanings understood by those skilled in the art and / or defined in dictionaries, treatises, etc.

[0024] It should also be noted that, as used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless otherwise specified. It will be further understood that the terms "comprises" and / or "comprising," as used herein, specify the presence of stated 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.

[0025] The following description discloses several preferred embodiments of a system, method and computer program product for dynamic massive MIMO end device pairing based on predicted and real-time connection conditions.

[0026] In one general embodiment, a computer-implemented method for grouping devices in a massive multiple-input and multiple-output (MIMO) based cellular network comprises determining mobility states of end devices within cells of the massive MIMO based cellular network, estimating payload requirements of the end devices, and grouping the end devices into groups based on the determined mobility states and the estimated payload requirements.

[0027] In another general embodiment, a computer program product comprises one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions having program instructions for performing the method described above.

[0028] In another general embodiment, a system includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to perform the method described above.

[0029] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0030] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media"), collectively contained in one or more storage devices, that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as pits / lands formed on the major surface of a punch card or disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but the above does not qualify a storage device as transitory because the data is not transitory while it is stored.

[0031] Computing environment 100 comprises an example of an environment for the execution of at least a portion of computer code involved in performing the inventive method, such as massive MIMO pairing code 150. In addition to block 150, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a set of processors 110 (including processing circuitry 120 and cache 121), a communications fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 150, as identified above), a set of peripheral devices 114 (including a set of user interface (UI) devices 123, storage 124, and a set of Internet of Things (IoT) sensors 125), and a network module 115. Remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0032] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or among multiple locations. However, in this description of computing environment 100, for purposes of brevity, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in FIG. 1 within a cloud, it may be located within a cloud. On the other hand, computer 101 is not required to reside within a cloud except to any extent that may be expressly indicated.

[0033] Processor set 110 includes one or more computer processors of any type now known or later developed. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple linked integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0034] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to perform a series of operational steps, thereby realizing a computer-implemented method, such that the instructions so executed instantiate the method specified in the flowcharts and / or descriptions of the computer-implemented method contained herein (collectively referred to as the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least some of the instructions for performing the methods of the present invention may be stored in block 150 in persistent storage 113.

[0035] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as switches and conductive pathways that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0036] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless expressly stated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0037] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or directly to persistent storage 113. While persistent storage 113 may be read-only memory (ROM), typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, such as various known proprietary operating systems employing a kernel or open-source Portable Operating System Interface-type operating systems. The code contained in block 150 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0038] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 may be implemented in various forms, such as Bluetooth connections, near field communication (NFC) connections, connections made by cables (such as universal serial bus (USB)-type cables), pluggable connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device set 123 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage 124 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. The storage 124 may be persistent and / or volatile. In some embodiments, the storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., where computer 101 stores and manages a large database locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple, geographically distributed computers. IoT sensor set 125 consists of sensors that may be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0039] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101 from an external computer or external storage device, typically through a network adapter card or network interface included in network module 115.

[0040] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances using any now known or later developed technology for communicating computer data. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0041] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise that operates computer 101) and may take any of the forms discussed above with respect to computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to the end user, the recommendations would typically be communicated from network module 115 of computer 101 over WAN 102 to EUD 103. In this manner, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 may be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, and the like.

[0042] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, then this historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0043] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software in a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that comprise a host physical machine set 142, which is the universe of physical computers within and / or available to the public cloud 105. The virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It is understood that these VCEs may be stored as images and transferred among and between various hosts of physical machines either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0044] Some further description of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0045] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0046] In some aspects, systems according to various embodiments may include a processor and logic integrated with and / or executable by the processor, the logic configured to perform one or more of the process steps described herein. The processor may be of any configuration described herein, such as a discrete processor or processing circuitry including numerous components, such as processing hardware, memory, I / O interfaces, etc. "Integrated with" means that the processor has logic embedded therein as hardware logic, such as an application-specific integrated circuit (ASIC), FPGA, etc. "Executable by a processor" means that the logic is hardware logic; software logic, such as firmware, a portion of an operating system, a portion of an application program, etc., or any combination of hardware and software logic accessible by the processor and configured to cause the processor to perform some function when executed by the processor. As known in the art, software logic may be stored in local and / or remote memory of any memory type. Any processor known in the art may also be used, such as a software processor module and / or hardware processors, such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), graphics processing unit (GPU), etc.

[0047] Of course, this logic may be implemented as a method or computer program product on any device and / or system according to various embodiments.

[0048] Various embodiments described herein may be implemented in conjunction with massive MIMO, for example, to serve multiple end devices using the same resources. Any configuration of a known massive MIMO network, including known types of massive MIMO-based cellular networks, may be adapted in accordance with the teachings herein. In various embodiments, the number of end devices connecting to a base station is much less than the number of antennas coupled to the base station. Known types of beamforming are used to enhance communications between the base station and the end devices. The end devices may be any type of device capable of connecting to a network, such as a cellular phone, a tablet, a smartwatch, a mobile hotspot, etc.

[0049] To support massive MIMO, there is a need for effective end-device pairing with beamforming solutions, and these actions should be intelligently performed at lower layers of the radio base station protocol stack. Currently, there is no efficient way for a base station to predict end-device mobility; therefore, all end devices within the coverage area of ​​a base station cell are treated equally, regardless of their mobility. Also, there is currently no efficient way for a base station to predict end-device payload requirements, because the base station provides physical resource blocks (PRBs) or similar attributes for mapping payloads and services, but cannot determine the amount and burstiness of traffic that may be required from end devices and / or their applications. Furthermore, a base station currently lacks a central entity capable of analyzing traffic and accordingly pushing traffic to neighboring cells, nor does it have the ability to pull traffic from neighboring cells.

[0050] To optimize and automate the complex process of determining the correct set of end device groupings for effective massive MIMO implementation, various embodiments of the present invention enable predictive learning at a higher layer with an analytics layer supporting artificial intelligence (AI) / machine learning (ML) modeling and inference capabilities at lower layers for autonomous control loop operation. This higher layer may have end device-specific information regarding predicted mobility conditions, traffic requirements for the user plane, beamforming management, and cell-edge end-user quality, along with end device capabilities. In some approaches, such information is fed into an analytics engine, which, when aggregated, helps dynamically predict configurations, thus helping the base station select optimal end device groupings in near real time. The higher layer trained models may then make decisions on the end device groupings to optimize them. Beam optimization with optimal end device groupings results in enhanced performance of the massive MIMO system, and lower protocol layers at the base station may then implement effective scheduling mechanisms.

[0051] Referring now to Figure 2, a flowchart of a method 200 for grouping end devices in a massive MIMO-based cellular network is shown, according to one embodiment. Method 200 may be performed in accordance with the present invention in any of the environments shown in Figure 1, among other embodiments. Of course, more or fewer operations may be included in method 200 than those specifically illustrated in Figure 2, as will be understood by those skilled in the art upon reading this specification.

[0052] Each of the steps of method 200 may be performed by any suitable component of an operating environment. For example, in various embodiments, method 200 may be performed, in part or in whole, by a massive MIMO-based cellular network, a component thereof, or some other device having one or more processors therein. A processor (e.g., a processing circuit, chip, and / or module) implemented in hardware and / or software, preferably having at least one hardware component, may be utilized in any device to perform one or more steps of method 200. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, combinations thereof, or any other suitable computing device known in the art.

[0053] As shown in FIG. 2 , method 200 may begin at operation 202, where mobility states of end devices within cells of a massive MIMO-based cellular network are determined. At operation 204, payload requirements of the end devices are estimated. At operation 206, the end devices are grouped into groups based on the determined mobility states and estimated payload requirements. Once groups are created, system resources may be allocated to the end devices within each group in any manner that will be apparent to one of ordinary skill in the art after reading this disclosure. Further details about each of these operations, including example embodiments and how groupings are used within a network, are provided below.

[0054] In a preferred embodiment, the movement state of the end device is collected, for example, at predetermined intervals, continuously, according to a predefined schedule, upon the occurrence of an event, etc. Preferably, the movement state is collected at a higher hierarchical layer of the system executing the method.

[0055] 3 depicts an architecture 300 for assessing a motion state of an end device, according to one embodiment. Optionally, this architecture 300 may be implemented in conjunction with features from any other embodiments enumerated herein, such as those described with reference to other figures. However, it should be understood that such architecture 300, and others presented herein, may be used in various applications and / or permutations that may or may not be specifically described in the exemplary embodiments enumerated herein. Furthermore, the architecture 300 presented herein may be used in any desired environment.

[0056] Information about the location of the end device (which may be outdoors and / or indoors) may be collected based on any known location determination mechanism 302. Exemplary location determination mechanisms include: ·GPS Positioning Reference Signal (PRS) ·Triangulation method Handover count between wireless cells ·Beam configuration change in MAC layer ·Coverage / Quality Changes ·Angle of arrival Timing Advance Enhanced Cell ID (E-CID) ·Observed Time Difference Of Arrival (OTDOA) Assisted Global Navigation Satellite System (A-GNSS) Handover Includes:

[0057] The location measurement mechanism information is fed into the movement state block 304, which is responsible for determining and grouping end devices based on their movement state. By considering the movement state of the end devices, the problem of an end device in a group moving and therefore changing its signal characteristics, which in turn causes an end device to interfere with the communication of another end device in the group, can be reduced.

[0058] In some approaches, each end device is distinguished based on one of a number of predefined states. The predefined states may represent different movement states of the end device according to any desired classification. An exemplary set of movement states, presented merely as an example, is as follows:

[0059] No Movement state: These end devices are classified as devices with no or minimal movement. Exemplary end devices that typically have a no movement state include smart meters, Internet of Things (IOT) devices, stationary user devices, etc.

[0060] Low Movement state: These end devices are classified as devices with relatively slow movement, which means that their perceived conditions are slowly changing, which in turn means that there will be no sudden channel condition changes from the end device. Exemplary end devices that typically have a no-movement state are those associated with pedestrian traffic, devices used within a single building, etc.

[0061] Medium Mobility State: These end devices are classified as devices that have moderate speed and / or may be accessing higher user plane traffic. Such end devices may be associated with sudden channel condition changes to the channel reported to the base station. Exemplary end devices that may have a medium mobility state include autonomous vehicles in cities, etc.

[0062] High and ultra-fast movement state: These end devices are classified as devices with high or very high speeds and will therefore report sudden network condition changes. They will also fail to receive signaling due to poor channel quality. Exemplary end devices that may have a medium movement state include devices on a train moving at high speed, devices in a car on a highway, etc.

[0063] The movement state may be further distinguished based on, for example, predictability as a predictable pattern 306 or an unpredictable pattern 308. For example, the movement state of an end device may be characterized based on the predictability of the pattern of movement of the end device. Thus, in some embodiments, end devices having a predictable pattern of movement may be grouped, while end devices having an unpredictable pattern of movement are not placed in the group but are instead placed in another group, e.g., with a lower priority, and are served according to default parameters (e.g., best effort), etc.

[0064] With respect to predictable patterns, through the mobility state classification, an end device may be determined as having a predictable pattern if a particular end device ID follows a certain trend and / or pattern based on a predefined granularity such as time of day, day of the week, etc. For example, an end device of a commuting employee may tend to have the end device in a stationary state at certain times and on certain days, with a different pattern on weekends.

[0065] If such a pattern is observed, at least some of the time slots may be classified as having a predictable pattern. Furthermore, predictability may be exploited to assist the base station when scheduling resources, e.g., end devices with predictable patterns may be given higher priority for base station resources, at least during periods of predictable mobility.

[0066] With respect to unpredictable patterns, mobility state classification allows for cases where end devices do not follow mobility state patterns over different time granularities, in which case those cases may be identified as unpredictable traffic. Preferably, such end devices are not placed within a priority group, but rather are grouped separately and served according to a default service plan, e.g., resources are scheduled on a best-effort basis.

[0067] The model may be trained in a known manner using any desired type of exemplary trends and / or patterns, and used in conjunction with AI or ML to determine whether the model should classify the movement state of the end device.

[0068] Continuing with the commuting worker example above, reference is made to FIG. 4, which is an exemplary table 400 correlating observations of movement states with time of day and corresponding labels of predictable or unpredictable, where periods of unpredictability are indicated for particular intervals. As noted, movement within a given time period during the weekdays is predicable, while both Saturdays have periods of unpredictable movement states. Based on these observations, the movement states of end devices can be predicted to have predictable movement states at all times shown in the table except for 8:00 to 12:00 on Saturday, and whether end devices are grouped into particular groups during particular times can be made based on such predictions.

[0069] 2, the method may include collecting, preferably at a higher hierarchical layer, end device payload requirements, for example, at predetermined intervals, continuously, according to a predefined schedule, upon the occurrence of an event such as an end device connecting to a base station, etc.

[0070] Payload requirements may be estimated based at least in part on factors such as applications currently running on each end device, information about past usage, information about past payload requirements, and the like.

[0071] The collected payload information may include application usage and / or payload / service patterns of end device users. The payload and / or service patterns may reflect payload and / or service requirements over time and / or geographic location, among other things. For example, a cell with an office building inside may experience higher payloads used by end devices near that building during office hours. Similarly, a particular user may stream movies on their mobile phone at home in the evening, creating a pattern of higher payload requirements during certain times of the day that also has a geographic correlation to the user's home. Generating a good payload profile is useful because multi-user MIMO has higher efficiency for higher payload requirements / requests.

[0072] A payload profile may be created for an end device based on current device information, such as active applications, and / or by collecting device payload patterns over time. For example, a payload profile may be created by examining application and end device usage patterns by checking PRB, RRC, Physical Downlink Shared Channel (PDSCH), and / or Physical Downlink Control Channel (PDCCH) patterns. The payload profile of an end device may be used for grouping.

[0073] Exemplary traffic profile classifications are listed immediately below.

[0074] Bursty Payload: Certain applications for end devices may have an immediate surge in payload requirements, after which the payload requirements may drop. Such types of traffic requirements are inconsistent, and accordingly end devices may be placed in higher hierarchical groups to maintain state.

[0075] Low-grade payload: Certain traffic requirements may require a minimum payload, such as browsing a website, accessing a specific application, streaming, etc., which in turn means that the end device may not have higher throughput requirements. Accordingly, the end device may be placed in a lower tiered group and state will be well maintained.

[0076] High-grade payload: Certain end-user applications may have consistent requirements for higher traffic Service Level Agreements (SLAs), such as higher throughput requirements / additional capacity, and therefore end devices may be placed in higher tiered groups to maintain state.

[0077] The payloads and / or payload profiles can be used to group end devices into groups that optimize system resources. For example, if one end device is streaming movies and another is simply getting email every few minutes, a grouping algorithm can consider the predicted relative resource needs of the end devices and place them into groups that maximize data throughput without overloading the base station to which they are connected, and without wasting resources by reserving bandwidth for end devices that only require minimal data transfer.

[0078] Additional factors that may be considered when grouping end devices include signal-to-interference-and-noise ratio (SINR) information and / or end device capabilities. For example, grouping may be performed using motion conditions, estimated payload requirements, SINR information, and end device capabilities. In another approach, some of the end devices may be grouped into beamforming device groups based on SINR information and end device capabilities.

[0079] SINR information and / or device capabilities may be collected from end devices, for example, at predetermined intervals, continuously, according to a predefined schedule, upon occurrence of an event, etc. Considering that different channel quality requirements are set for different users depending on the application, this information may be collected to perform beamforming end device grouping to achieve, for example, different SINRs for different end devices inside the same cell.

[0080] Another exemplary embodiment revolves around signal quality perceived by end devices at cell edge locations and / or in areas prone to interference due to multiple servers, because quality may vary for different end devices due to varying path loss, receiver sensitivity, and / or the type of device used. For example, each end device may have different capabilities (e.g., supported carriers, whether massive MIMO is compatible with the end device, etc.) and / or signal receiver sensitivity than others in the cell. For example, if a legacy phone in a group is not compatible with massive MIMO, the channel estimation may be suboptimal in this case, and the wrong MIMO mode may be selected. This may result in an unacceptable service experience in massive MIMO, even if the capacity of the wireless cell is significantly improved. Accordingly, the desired SINR / channel quality is mapped to the service capabilities. In some approaches, additional end device capabilities, such as frequency group indicator (FGI) bits, are collected and used when grouping.

[0081] In some embodiments, end devices located toward the edge of a cell are pushed out of the cell or pulled into the cell based on cell-edge capacity requirements and beamforming device buffers. For example, if the cell-edge capacity requirements for an end device grouping are approaching or at their limits, the end device may be pushed to another grouping cell. Preferably, a communication is sent to a base station in another cell with a request to accept communication with the end device. Similarly, if the beamforming device buffer is approaching or at its limit, the end device may be pushed to a grouped end device of another cell. Alternatively, if the cell-edge capacity requirements and / or beamforming device buffer allow for the accommodation of another end device, the end device may be pulled to a cell grouped end device.

[0082] In one approach, cell-edge capacity requirements and / or beamforming end device buffer information are collected in a massive MIMO implementation. This information can be used as input to push / pull traffic at the cell edge, which helps to have efficient massive MIMO operation. This can help to modify the configuration in near real time.

[0083] Additionally, grouped end devices may be moved from one group to another (including groups of end devices removed from the group) based on changes in one or more of the parameters enumerated herein, such as mobility state, estimated payload requirements of the end devices, SINR information, channel quality, etc.

[0084] 5 depicts an analysis system 500 and parameters fed to the analysis block according to one embodiment. Optionally, this system 500 may be implemented in conjunction with features from any other embodiment enumerated herein, such as those described with reference to other figures. However, it should be understood that such an analysis system 500, and others presented herein, may be used in a variety of applications and / or permutations that may or may not be specifically described in the exemplary embodiments enumerated herein. Furthermore, the analysis system 500 presented herein may be used in any desired environment.

[0085] The information module 502 collects some or all of the aforementioned information types. On the left-hand side of the module, movement information is collected. In the illustrated approach, location information is collected from the end device's location measurement mechanism. This information may be collected in real time, over time, etc. The movement state of the end device is determined and the predictability of the movement state is characterized. Other information types collected by the module in this example include the end device's payload profile, the end device's SINR and channel quality profile, the device capability profile, and cell edge capacity.

[0086] Some or all of the information collected by the information module 502 is sent to an analysis block 504 for analysis. The analysis block 504 identifies groups of end devices with predictable mobility states that can be grouped by location profile. The analysis block considers payload profile requirements and end device capabilities along with SINR / channel quality profiles to make optimal grouping decisions in terms of resource availability at the base station.

[0087] FIG. 6 depicts a massive MIMO system 600 having multiple base stations and an analysis layer according to one embodiment. FIG. 7 depicts the massive MIMO system 600 after device grouping has been effectively performed. Optionally, the system 600 may be implemented in conjunction with features from any other embodiment enumerated herein, such as those described with reference to other figures. However, it should be appreciated that such analysis system 600, and others presented herein, may be used in various applications and / or permutations that may or may not be specifically described in the exemplary embodiments enumerated herein. Furthermore, the analysis system 600 presented herein may be used in any desired environment.

[0088] 6 , a centralized analytics layer 602 is responsible for setting up policies for end device groupings by providing various end devices with their intended state, such as mobility status, payload, device support capabilities, SINR profile, etc. The centralized analytics layer 602 may collect some of the information from multiple distributed layers so that it can make a centralized decision regarding each of the predicted end devices. In some aspects, a distributed analytics layer 604 leverages the centralized analytics layer 602, which can help achieve seamless mobility of end device groupings without additional measurement reporting from the end devices, for example, by getting help from policies prepared in the centralized analytics layer 602.

[0089] The distributed analysis layer 604 is responsible for assigning different logical profiling based on data radio bearers (DRBs) by sending RRC reconfiguration messages. The distributed analysis layer 604 groups end devices based on various criteria, preferably obtained in real time, such as payload, movement information, location profile, etc. The distributed analysis layer 604 groups also receive policies from the centralized analysis layer 602, which collects and analyzes historical end device profiles, such as movement state, payload usage, signal quality, device capabilities, etc.

[0090] End devices that meet the requirements for a particular group are grouped together. Many different groups can be created. End devices that are removed from any group are served with a default resource allocation (e.g., best effort) from the base station 605.

[0091] The analysis block 500 from FIG. 5 is located in the centralized analysis layer 602 and has the ability to collect information from multiple distributed layers so that it can make a central decision on predicted end device states. In a preferred embodiment, the analysis block 500 does not require additional end device measurements received from the base station 605 each time it wants to make a decision. This further reduces signaling load and improves end device battery life. Rather, the analysis block 500 leverages the analysis distributed layer 604, which can facilitate seamless migration of end device groupings by obtaining instructions executed by the distributed analysis layer 604.

[0092] Once the grouping is performed by the higher-level centralized analysis layer 602, the grouping criteria are sent by the trained model to the distributed analysis layer 604. The distributed analysis layer 604 is responsible for assigning different profiles based on the DRB by sending an RRC reconfiguration message.

[0093] The distributed analytics layer 604 may group end devices based on various criteria such as payload, movement, and location profile, and the grouping decisions may be driven by intent sent from the higher-level centralized analytics layer 602.

[0094] The distributed analysis layer 604 also has the function of redistributing cell edge end devices to common wireless cells for effective end device grouping according to information shared from the centralized analysis layer 602.

[0095] As shown in Figure 7, end devices 606 are grouped into groups in response to groupings created by the distributed analysis layer 604. Note also that additional sub-domains are created in real time, e.g., using DRB, by grouping end devices according to formulated policies received from higher analysis layers 602, 604. In this example, the end devices 606 in Domains 1 and 2 of Figure 6 include two vehicle-based devices with medium mobility states and two user devices with low or no mobility states. This configuration is likely to be inconsistent, resulting in interference and ultimately blocked network resources. Referring to Figure 7, two user devices are grouped together in Domain 2.1.

[0096] Therefore, a unique proposal has been described that formulates a policy for end device grouping at a higher analysis layer taking into account mobility state predictability, payload requirement state, grouping buffer, and network quality, and then executes a massive MIMO end device grouping strategy according to the analyzed predictable and unpredictable patterns.

[0097] Massive MIMO networks enhanced with the features presented herein not only increase per-cell capacity, but also improve the end-user experience by providing better and faster connections due to better utilization of network resources.

[0098] It will be apparent that the various features of the systems and / or methods described above may be combined in any manner to create multiple combinations from the description provided above.

[0099] It will be further appreciated that embodiments of the present invention may be provided in the form of a service that is deployed on behalf of a customer to provide the service on demand.

[0100] The description of various embodiments of the present invention has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best explain the principles, practical applications, or technical improvements of the embodiments over techniques found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method for grouping devices in a large-scale multiple-input and multiple-output (MIMO) based cellular network, the method comprising: determining a mobility state of an end device within a cell of the massive MIMO-based cellular network; estimating the payload requirements of the end device; and grouping the end devices into groups based on the determined movement states and the estimated payload requirements. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, further comprising characterizing the movement state of the end device based on predictability of patterns of movement of the end device, wherein end devices having unpredictable patterns of movement are not placed into the group.

3. 3. The computer-implemented method of claim 2, comprising: collecting signal-to-interference-and-noise ratio (SINR) information from the end devices; and performing the grouping using the mobility state, the estimated payload requirements, the SINR information, and the capabilities of the end devices.

4. 2. The computer-implemented method of claim 1, comprising: creating a payload profile for the end device by collecting device payload patterns over time; and using the payload profile for the end device for the grouping.

5. 5. The computer-implemented method of claim 4, comprising: collecting signal-to-interference-and-noise ratio (SINR) information from the end devices; and performing the grouping using the mobility state, the estimated payload requirements, the SINR information, and the capabilities of the end devices.

6. The computer-implemented method of claim 1 , wherein the payload requirements are estimated based at least in part on applications running on the respective end devices.

7. 2. The computer-implemented method of claim 1, comprising collecting signal-to-interference-and-noise ratio (SINR) information from the end devices and grouping some of the end devices into beamforming device groups based on the SINR information and capabilities of the end devices.

8. 2. The computer-implemented method of claim 1, comprising: pushing one of the end devices located toward an edge of the cell out of the cell based on cell-edge capacity requirements and beamforming device buffers.

9. 2. The computer-implemented method of claim 1, comprising pulling new end devices located toward an edge of the cell into the cell based on cell-edge capacity requirements and beamforming device buffers.

10. The computer-implemented method of claim 1 , comprising moving end devices from the group to another group based on changes in the movement state and estimated payload requirements of the end devices.

11. 1. A computer program product, comprising: One or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions comprising: program instructions for determining a mobility state of an end device within a cell of the massive MIMO based cellular network; program instructions for estimating a payload requirement of the end device; and program instructions for grouping the end devices into groups based on the determined movement state and the estimated payload requirements; having Computer program products.

12. 12. The computer program product of claim 11, comprising program instructions for characterizing the movement state of the end device based on predictability of a pattern of movement of the end device, wherein end devices having unpredictable patterns of movement are not placed into the group.

13. 13. The computer program product of claim 12, comprising: program instructions for collecting signal-to-interference-and-noise ratio (SINR) information from the end devices; and performing the grouping using the mobility state, the estimated payload requirements, the SINR information, and the capabilities of the end devices.

14. 12. The computer program product of claim 11, comprising: program instructions for creating a payload profile for the end device by collecting device payload patterns over time; and program instructions for using the payload profile of the end device for the grouping.

15. 12. The computer program product of claim 11, wherein the payload requirements are estimated based at least in part on applications running on the respective end devices.

16. 12. The computer program product of claim 11, comprising program instructions for collecting signal-to-interference-and-noise ratio (SINR) information from the end devices, and grouping some of the end devices into beamforming device groups based on the SINR information and capabilities of the end devices.

17. 12. The computer program product of claim 11, comprising program instructions for pushing one of the end devices located toward an edge of the cell out of the cell based on cell-edge capacity requirements and beamforming device buffers.

18. 12. The computer program product of claim 11, comprising program instructions for pulling new end devices located towards an edge of the cell into the cell based on cell-edge capacity requirements and beamforming device buffers.

19. 12. The computer program product of claim 11, comprising program instructions for moving end devices from the group to another group based on changes in motion status and estimated payload requirements of the end devices.

20. a processor; and Logic integrated into, executable by, or integrated into and executable by the processor, said logic comprising: determining a movement state of an end device within a cell of the massive MIMO-based cellular network; estimating a payload requirement of the end device; Grouping the end devices into groups based on the determined movement state and the estimated payload requirements. It is configured as follows: A system comprising:

Images