Dynamic massive MIMO terminal device pairing based on predictive and real-time connection status

Abstract

A computer-implemented method for grouping devices in a massive multiple-input multiple-output (MIMO)-based cellular network includes determining a mobility state of a terminal device in a cell of the massive MIMO-based cellular network, estimating a payload requirement of the terminal device, and grouping the terminal device in a cell of the massive MIMO-based cellular network. And grouping the terminal devices in groups based on the determined mobility state and the estimated payload requirements.

Description

Background Art

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

[0002] Partially due to the efficient time / frequency resource utilization by including the multi-user MIMO (MU-MIMO) mode, massive MIMO is an important technology for realizing 5G and future wireless technologies to enhance the capacity of terminal devices and radio cells. The use of multiple radio antennas enables beam steering to diverse terminal devices, where each beam cancels interference from other beams spatially. This in turn results in a higher connection capacity of the base station.

[0003] In massive MIMO, it is assumed that the number of transmit and receive antennas is high. This large number of antennas will provide significant multiplexing and diversity gains and serve a large number of users in parallel. By increasing the number of transmit antennas, a higher data rate can be achieved without increasing the bandwidth. This is because, by adding multiple antennas, in addition to the time and frequency dimensions, more degrees of freedom can be provided in the wireless channel to provide a higher data rate.

[0004] Furthermore, massive MIMO together with beamforming tends to minimize intra-cell and inter-cell interference by narrowing the radiated energy and focusing it in the direction of the intended users.

[0005] There are two different MIMO scenarios: transmit diversity, where the same data is transmitted simultaneously by multiple antennas to improve the signal-to-interference and noise ratio (SINR); and spatial multiplexing, where independent data streams are transmitted on each antenna to increase capacity. Thus, in practice, massive MIMO is promising to significantly increase the capacity and service enhancement in a cellular network environment. However, the capacity and service enhancement depend closely on the terminal device's mobility state, payload requirements, and the channel quality perceived by the terminal device. Since the capacity and service enhancement of the cell can only be enhanced by grouping the end-users, but the number of additional users without following orthogonality can lead to interference, the perceived quality of service often degrades.

[0006] In a real environment, some terminal devices have a relatively stationary state, while other terminal devices can have a higher mobility state. The current design of the MU-MIMO working method is very sensitive to the terminal device's mobility state, and thus the capacity gain and service enhancement are very negatively affected by the high mobility state of the terminal devices.

[0007] Another problem arises when some terminal devices have limited user plane payload requirements and other terminal devices have higher user plane payload requirements. As currently designed, the performance of MU-MIMO is relatively degraded in low payload scenarios; therefore, traffic must be considered for MU-MIMO efficiency.

[0008] Another case revolves around the channel signal quality perceived by the terminal device at a cell edge location or in an interference area due to multiple servers. The quality may vary for different terminal devices due to varying path loss, receiver sensitivity, or the type of device used. Each terminal device may have different capabilities (such as which specific carrier is supported), signal reception sensitivity, etc. Since the channel estimate may not be optimal in this case, the wrong MIMO mode may be selected. Therefore, although the capacity of the radio cell will be significantly increased, the service experience may become unacceptable in such a massive MIMO scenario.

[0009] Channel orthogonality between multiple terminal devices is an important criterion for creating user separability and allowing the opportunity to share radio frequency resources simultaneously. For mobility, there is a need to adjust the beamforming weight assignments to not only maintain the signal power level (e.g., beam quality) at the user end, but also to continuously limit the increased inter-user interference experienced between users assigned the same radio resource allocation. The scheduler will also not be able to realize potential reuse gains because fewer radio resource blocks are shared between users in the same cell, thereby reducing spectral efficiency.

[0010] In the case where MU-MIMO terminal device pairing is not done optimally, typical effects include higher signal, non-optimal radio resource control (RRC) message flow, battery consumption, 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 multiple-output (MIMO)-based cellular network includes determining a mobility state of a terminal device in a cell of the massive MIMO-based cellular network, estimating a payload requirement of the terminal device, and grouping the terminal devices in groups based on the determined mobility state and the estimated payload requirement.

[0012] According to one embodiment, a computer program product includes one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media. The program instructions include program instructions for executing the aforementioned method.

[0013] According to one embodiment, a system includes a processor and logic that is integrated with the processor, executable by the processor, or both integrated with and executable by the processor. The logic is configured to perform the foregoing method.

[0014] Other aspects and embodiments of the present invention will become apparent from the following detailed description, which, when taken in conjunction with the accompanying drawings, illustrate the principles of the invention by way of example. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0017] Figure 3 depicts an architecture for evaluating the mobility state of a terminal device according to one embodiment.

[0018] Figure 4 depicts a table associating observations of the mobility state with time of day and predictable or unpredictable corresponding labels according to one embodiment.

[0019] Figure 5 depicts an analysis system and parameters fed into an analysis block according to one embodiment.

[0020] Figure 6 depicts a massive MIMO system with multiple base stations and an analysis layer according to one embodiment.

[0021] Figure 7 depicts a massive MIMO system after terminal device grouping has been performed according to one embodiment Figure 6 has been performed. DETAILED DESCRIPTION

[0022] The following description is for illustrative purposes of the general principles of the invention and is not meant to limit the inventive concepts claimed herein. Additionally, the specific features described herein can be used in each and every possible combination and permutation with the other described features.

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

[0024] It must also be noted that, as used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless otherwise specified. It will also be understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude 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 systems, methods, and computer program products for dynamic massive MIMO terminal device pairing based on predicted and real-time connection status.

[0026] In a general embodiment, a computer-implemented method for grouping devices in a massive multiple-input multiple-output (MIMO) based cellular network includes determining a mobility state of a terminal device in a cell of the massive MIMO based cellular network, estimating a payload requirement of the terminal device, and grouping the terminal devices in groups based on the determined mobility state and the estimated payload requirement.

[0027] In another general embodiment, a computer program product includes one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media. The program instructions include program instructions for executing the aforementioned method.

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

[0029] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, again depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0030] A computer program product embodiment (“CPP embodiment” or “CPP”) is a term used in this disclosure to describe any collection of one or more storage media (also referred to as “media”) collectively included in a set of one or more storage devices, the set of one or more storage devices collectively including machine-readable code corresponding to instructions and / or data for performing 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. By way of non-limitation, computer-readable storage media can be electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, 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 devices such as punch cards or pits / lands formed in the main surface of a disk, or any suitable combination of the foregoing. Computer-readable storage media (as the term is used in this disclosure) should not be construed to store in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, optical pulses transmitted through an optical fiber cable, electrical signals transmitted through a wire, and / or other transmission media. As will be understood by those of ordinary skill in the art, data is typically moved at certain incidental points in time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not render the storage device transient because the data is not transient when it is stored.

[0031] The computing environment 100 includes an example of an environment for executing at least some of the computer code involved in performing the methods of the present invention, such as the massive MIMO pairing code 150. In addition to block 150, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a set of processors 110 (including processing circuitry 120 and a cache 121), a communication fabric 111, volatile memory 112, persistent storage 113 (including an operating system 122 and block 150, as identified above), a set of peripherals 114 (including a set of user interface (UI) devices 123, a storage device 124, and a set of Internet of Things (IoT) sensors 125), and a network module 115. The 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] The computer 101 can take the form of a desktop computer, a laptop computer, a tablet computer, a smart phone, a smart watch, or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or to be developed in the future that is capable of running programs, accessing a network, or querying a database such as the remote database 130. As is well known in the computer art and depending on the technology, the execution of computer-implemented methods can be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of the computing environment 100, the detailed discussion focuses on a single computer (especially the computer 101) to keep the presentation as simple as possible. The computer 101 can be located in the cloud, even if it is not shown in the cloud in Figure 1 the figure. On the other hand, the computer 101 does not need to be in the cloud, unless to any degree that can be affirmatively indicated.

[0033] The set of processors 110 includes one or more computer processors of any type now known or to be developed in the future. The processing circuitry 120 can be distributed across multiple packages, such as multiple cooperating integrated circuit chips. The processing circuitry 120 can implement multiple processor threads and / or multiple processor cores. The cache 121 is memory located within the (multiple) processor chip packages and is typically used for data or code that should be made available for rapid access by the threads or cores running on the set of processors 110. Cache memory is typically organized into multiple levels based on its relative proximity to the processing circuitry. Alternatively, some or all of the cache in the set of processors can be located "off-chip". In some computing environments, the set of processors 110 can be designed to work with qubits and perform quantum computing.

[0034] Computer-readable program instructions are typically loaded onto computer 101 so that a processor set 110 of computer 101 executes a series of operational steps to implement a computer-implemented method, such that the instructions thus executed will instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively referred to as "the method 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 method of the present invention. In computing environment 100, at least some of the instructions for executing the method of the present invention may be stored in block 150 in persistent storage device 113.

[0035] Communication structure 111 is a signal conduction path that allows the various components of computer 101 to communicate with each other. Generally, this structure consists of switches and conductive paths, such as switches and conductive paths that make up a bus, a bridge, a physical input / output port, etc. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0036] Volatile memory 112 is any type of volatile memory known now or to be developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Generally, volatile memory 112 is characterized by random access, but this is not required unless affirmatively indicated. In computer 101, volatile memory 112 is located in a single package and inside computer 101, but, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computer 101.

[0037] Persistent storage device 113 is any form of non-volatile storage device for a computer known now or to be developed in the future. The non-volatility of this storage device means that the stored data is maintained regardless of whether power is supplied to computer 101 and / or directly to persistent storage device 113. Persistent storage device 113 may be read-only memory (ROM), but generally at least a portion of the persistent storage device allows for the writing, deletion, and re-writing of data. Some common forms of persistent storage devices include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, such as various known proprietary operating systems or open-source portable operating system interface type operating systems that employ a kernel. The code included in block 150 generally includes at least some of the computer code involved in executing the method of the present invention.

[0038] The peripheral device set 114 includes a collection of the peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a Near Field Communication (NFC) connection, a connection constituted by a cable (such as a Universal Serial Bus (USB) type cable), a plug-in connection (for example, a Secure Digital (SD) card), a connection constituted by a local communication network, and even a connection constituted by a wide area network such as the Internet. In various embodiments, the UI device set 123 can include components such as a display screen, a speaker, a microphone, wearable devices (such as goggles and smart watches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. The storage device 124 is an external storage device (such as an external hard disk drive) or a pluggable storage device (such as an SD card). The storage device 124 can be persistent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where the computer 101 needs to have a large amount of storage (for example, in the case where the computer 101 locally stores and manages a large database), the storage device can be provided by a peripheral storage device designed to store a very large amount of data, such as a Storage Area Network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 is constituted by sensors that can be used in Internet of Things applications. For example, one sensor can be a thermometer, and another sensor can be a motion detector.

[0039] The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers via the WAN 102. The network module 115 can include hardware such as a modem or a Wi-Fi signal transceiver, software for encapsulating and / or de-encapsulating data transmitted on a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are executed on the same physical hardware device. In other embodiments (for example, embodiments using Software Defined Network (SDN)), the control function and the forwarding function of the network module 115 are executed on physically separated devices, such that the control function manages several different network hardware devices. The computer-readable program instructions for executing the method of the present invention can generally be downloaded to the computer 101 from an external computer or an external storage device through a network adapter or a network interface included in the network module 115.

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

[0041] The end user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating the computer 101) and may take any of the forms discussed above in connection with the computer 101. The EUD 103 typically receives helpful and useful data from the operation of the computer 101. For example, in the hypothetical case where the computer 101 is designed to provide recommendations to the end user, the recommendations will typically be transmitted from the network module 115 of the computer 101 to the EUD 103 via the WAN 102. In this way, the EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, the EUD 103 may be a client device such as a thin client, a thick client, a mainframe computer, a desktop computer, etc.

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

[0043] A public cloud 105 is any computer system that can be used by multiple entities, which provides on-demand availability of computer system resources and / or other computing capabilities (notably data storage (cloud storage) and computing power), without direct active management by the user. Cloud computing typically exploits the sharing of resources to achieve consistency and economy of scale. The direct and active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers of a set of host physical machines 142, which is the universe of physical computers in the public cloud 105 and / or the universe of physical computers available for the public cloud. A virtual computing environment (VCE) typically takes the form of virtual machines from a set of virtual machines 143 and / or containers from a set of containers 144. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after instantiation of the VCE. The cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages the active instantiations of the VCE deployment. The gateway 140 is a collection of computer software, hardware, and firmware that allows the public cloud 105 to communicate via the WAN 102.

[0044] Some further explanations of the virtualized computing environment (VCE) will now be provided. A VCE can be stored as an "image". New active instances of the VCE can be instantiated from this image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user space instances (referred to as containers). From the perspective of the programs running within them, these isolated user space instances typically appear as actual computers. A computer program running on a normal operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU capabilities, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of the container and the devices allocated to the container, which is a feature known as containerization.

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

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

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

[0048] The various embodiments described herein are implemented in conjunction with massive MIMO, e.g., using the same resources to serve multiple terminal devices. Any configuration of a known massive MIMO network can be adapted according to the teachings herein, including known types of massive MIMO-based cellular networks. In various embodiments, the number of terminal devices connected 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 communication between the base station and the terminal devices. The terminal device can be any type of device capable of connecting to a network, such as a cellular phone, a tablet computer, a smart watch, a mobile hotspot, etc.

[0049] To support massive MIMO, effective terminal device pairing and beamforming solutions are required, and these actions should be intelligently performed at lower layers of the radio base station protocol stack. In the current state of the art, there is no effective way to predict the terminal device movement state at the base station; thus, all terminal devices in the coverage area of the base station cell are treated equally regardless of their movement. Additionally, currently at the base station, there is no effective way to predict the terminal 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 the traffic that may be required from the terminal devices and / or their applications. Further, the base station currently has no central entity with the ability to analyze traffic and push traffic to adjacent cells accordingly, nor the ability to pull traffic from adjacent cells.

[0050] To optimize and automate the complex process of determining the correct set of terminal device groupings for effective massive MIMO implementation, various embodiments of the present invention enable an analytics layer to support artificial intelligence (AI) / machine learning (ML) modeling and predictive learning at a higher layer and have inferencing capabilities at lower layers of an autonomous control loop operation. The higher layer may have terminal device specific information regarding the predicted movement state, traffic requirements on the user plane, beamforming management, and cell-edge end-user quality with terminal device capabilities. In some methods, this information is fed into an analytics engine which, when aggregated, helps dynamically predict configurations and thus helps the base station select the best terminal device groupings near real-time. The higher layer training model can make decisions on terminal device groupings to optimize the terminal device groupings. Beam optimization via the optimal terminal device groupings results in enhanced massive MIMO system performance, such that the lower protocol layers of the base station can perform effective scheduling mechanisms.

[0051] Now referring to Figure 2 , a flowchart of a method 200 for grouping terminal devices in a massive MIMO-based cellular network according to one embodiment is shown. In various embodiments, method 200 may be performed in accordance with the present invention in any environment within the environment depicted in Figure 1 . Of course, as will be understood by one of ordinary skill in the art upon reading this specification, method 200 may include more or fewer operations than those specifically described in Figure 2 .

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

[0053] As Figure 2 shown, method 200 can initiate at operation 202, where the mobility state of a terminal device in a cell of a massive MIMO-based cellular network is determined. At operation 204, the payload requirements of the terminal device are estimated. At operation 206, the terminal devices are grouped into groups based on the determined mobility state and the estimated payload requirements. Once the (multiple) groups are created, system resources can be allocated to the terminal devices in each group in any manner that will become apparent to one of ordinary skill in the art after reading this disclosure. More details regarding each of these operations, including exemplary embodiments, and how grouping is used in a network are provided below.

[0054] In a preferred embodiment, the mobility state of the terminal device is collected (e.g., at predetermined intervals, continuously, according to a predefined schedule, upon the occurrence of an event, etc.). Preferably, the mobility state is collected at a higher level of the system performing the method.

[0055] Figure 3 An architecture 300 for evaluating the mobility state of a terminal device according to one embodiment is depicted. As an option, this architecture 300 can be implemented in combination with features from any of the other embodiments listed herein (such as those described with reference to other figures). However, this architecture 300 and the other architectures presented herein can be used in various applications and / or arrangements, which may or may not be specifically described in the illustrative embodiments listed herein. Additionally, the architecture 300 presented herein can be used in any desired environment.

[0056] Information regarding the location of a terminal device (which can be outdoor and / or indoor) can be collected based on any known location measurement mechanism 302. Illustrative location measurement mechanisms include:

[0057] ■ GPS

[0058] ■ Positioning Reference Signal (PRS)

[0059] ■ Triangulation method

[0060] ■ Handover count between radio cells

[0061] ■ Beam configuration change in the MAC layer

[0062] ■ Coverage / quality change

[0063] ■ Angle of arrival

[0064] ■ Timing advance

[0065] ■ Enhanced Cell ID (E-CID)

[0066] ■ Observed Time Difference of Arrival (OTDOA)

[0067] ■ Assisted Global Navigation Satellite System (A-GNSS)

[0068] ■ Handover.

[0069] The position measurement mechanism information is fed into the mobile state block 304, which serves to determine the terminal device and group the terminal devices based on the mobile state of the terminal device. By considering the mobile state of the terminal device, the movement of the terminal devices in the group can be reduced and thus the signal characteristics can be changed so that the communication of another terminal device in the group is now interfered with by the terminal device.

[0070] In some methods, each terminal device is differentiated based on one of a plurality of predefined states. The predefined state can represent different mobile states of the terminal device according to any desired differentiation. The following is a set of illustrative mobile states presented only by way of example.

[0071] No movement state: These terminal devices are classified as devices that do not move or have minimal movement. Illustrative terminal devices that typically do not have a movement state include Internet of Things (IoT) devices such as smart meters, static user equipment, etc.

[0072] Low movement state: These terminal devices are classified as devices with relatively low-speed movement, which means that their perceived conditions change slowly, which in turn means that there will be no sudden change in channel conditions from the terminal device. Illustrative terminal devices that typically do not have a movement state are those associated with pedestrian traffic, devices used within a single building, etc.

[0073] Medium mobility state: These terminal devices are classified as devices with medium speed and / or capable of accessing higher user plane traffic. Such terminal devices may be associated with sudden changes in channel conditions on the reporting channel towards the base station. Illustrative terminal devices that may have a medium mobility state include autonomous vehicles in a city, etc.

[0074] High-speed and ultra-high-speed mobility states: These terminal devices are classified as devices with high or very high speeds and thus necessarily report sudden changes in network conditions. They also necessarily miss signal reception due to poor channel quality. Illustrative terminal devices that may have a medium mobility state include devices on a fast-moving train, devices in vehicles on a highway, etc.

[0075] The mobility state can be further classified, for example, into a predictable mode 306 or an unpredictable mode 308 based on predictability. For example, the mobility state of a terminal device can be characterized based on the predictability of the movement pattern of the terminal device. Thus, in some embodiments, terminal devices with a predictable movement pattern can be grouped, while terminal devices with an unpredictable movement pattern are not placed in that group, for example, placed in another group with lower priority, served according to default parameters (e.g., best effort service), etc.

[0076] Regarding the predictable mode, classified by the mobility state, if a specific terminal device ID follows certain trends and / or patterns based on predefined granularities such as time, date, etc., the terminal device can be determined to follow a predictable mode. For example, the terminal device of a commuting employee may exhibit such a trend where the terminal device is in a non-mobile state at certain hours and certain days, while having a different pattern on weekends.

[0077] When such a pattern is observed, at least some of the time slots can be classified as a predictable mode. Additionally, predictability can be utilized to assist the base station in scheduling resources. For example, during at least the period of the predictable mobility state, terminal devices with a predictable mode can be given a higher priority for base station resources.

[0078] Regarding the unpredictable mode, classified by the mobility state, if a terminal device does not follow a mobility state pattern at different time granularities, those situations are identified as unpredictable traffic. Preferably, such terminal devices are not placed in a priority group but are grouped separately and served according to a default service plan. For example, resources are scheduled on a best effort basis.

[0079] A model can be trained in a known manner with any desired type of exemplary trends and / or patterns, and the model is used together with AI or ML to determine whether to classify the mobility state of a terminal device.

[0080] Continuing with the above example of a working professional, refer to Figure 4 , which is an exemplary table 400 that associates observations of the mobile state with the time of day and corresponding tags, whether predictable or unpredictable, where the unpredictable periods are represented as an interval. As described above, the movement during a working day within a given time period is predictable, while the two Saturdays have periods of unpredictable movement state. Based on these observations, it can be predicted that the mobile state of the terminal device has a predictable mobile state in all time periods shown in the table (except for Saturdays from 8:00 to 12:00), and based on this prediction, it can be determined whether the terminal device is grouped in a particular group during a particular time period.

[0081] Referring again to Figure 2 operation 204, the method can include collecting terminal device payload requirements preferably at a higher level. For example, the collection can be performed at a predetermined interval, continuously, according to a predefined schedule, upon the occurrence of an event such as the terminal device connecting to a base station, and so on.

[0082] The payload requirements can be estimated based at least in part on factors such as the applications currently running on the respective terminal device, information about past usage, information about past payload requirements, and so on.

[0083] The collected payload information can include terminal device consumer application usage and / or payload / service patterns. The payload and / or service patterns can reflect payload and / or service requirements over time and / or at a specific geographical location. For example, a cell with an office building may see a higher payload used by terminal devices near the building during office hours. Similarly, a particular user may stream movies on his or her mobile phone at home in the evening, thus creating a pattern of higher payload requirements during certain times, which is also geographically relevant to the user's home. Generating a good payload profile is useful because multi-user MIMO is more efficient for higher payload requirements / requests.

[0084] A payload profile can be created for the terminal device based on factors such as the current device information of the active applications and / or by collecting the device payload patterns over time. For example, the application and terminal device usage patterns can be considered by examining the PRB, RRC, physical downlink shared channel (PDSCH), and / or physical downlink control channel (PDCCH) patterns to create the payload profile. The payload profile of the terminal device can be used for grouping.

[0085] Illustrative traffic profile classifications are listed immediately below.

[0086] Burst Payload: Certain applications of the terminal device may have an immediate surge in payload requirements, and then the payload requirements may decrease. This type of traffic requirement is inconsistent, so the terminal device can be placed in a group with a higher level to maintain the state.

[0087] Low-Level Payload: Certain traffic requirements may require a minimum payload, such as browsing websites, accessing certain applications, streaming, etc., which in turn means that the terminal device may not have higher throughput requirements. Therefore, the terminal device can be placed in a group with a lower level, and the state will be adequately maintained.

[0088] High-Level Payload: Certain end-user applications may have consistent requirements for a higher traffic service level agreement (SLA), such as higher throughput requirements / additional capacity, so the terminal device can be placed in a group with a higher level to maintain the state.

[0089] Payloads and / or payload profiles can be used to group terminal devices into groups that optimize system resources. For example, if one terminal device is streaming a movie while another terminal device is merely retrieving emails every few minutes, the grouping algorithm can consider the expected relative resource requirements of the terminal devices and place the terminal devices in groups to maximize data throughput without overloading the connected base station(s) and without wasting resources by reserving bandwidth for terminal devices that only require minimal data transmission.

[0090] Additional factors that can be considered when grouping terminal devices include signal-to-interference and noise ratio (SINR) information and / or the capabilities of the terminal device. For example, mobility status, estimated payload requirements, SINR information, and the capabilities of the terminal device can be used to perform the grouping. In another approach, some of the terminal devices can be grouped into a beamforming device group based on SINR information and the capabilities of the terminal device.

[0091] SINR information and / or device capabilities can be collected from the terminal device (e.g., at predefined intervals, continuously, according to a predefined schedule, when an event occurs, etc.). Assuming different channel quality requirements are set for different users according to the application, this information can be collected to perform beamforming terminal device grouping, such as to achieve different SINRs on different terminal devices within the same cell.

[0092] Another illustrative embodiment revolves around the signal quality perceived by a terminal device due to multiple servers at the cell edge location and / or in a vulnerable area, as the quality may vary for different terminal devices due to varying path loss, receiver sensitivity, and / or the type of device used. For example, each terminal device may have different capabilities (such as supported carriers, whether massive MIMO is compatible with the terminal device, etc.) and / or signal reception sensitivity compared to other terminal devices in the cell. Since in such cases (e.g., in the case where a traditional phone in a group is not compatible with massive MIMO), the channel estimation may not be optimal, the wrong MIMO mode may be selected. Thus, although the capacity of the radio cell will be significantly increased, the service experience may become unacceptable in massive MIMO. Therefore, the desired SINR / channel quality is mapped to service capabilities. In some methods, additional terminal device capabilities such as frequency group indication (FGI) bits are collected and used in the packet.

[0093] In some embodiments, based on the cell edge capacity requirement and the beamforming device buffer, the terminal devices located towards the edge of the cell are pushed out of the cell or pulled into the cell. For example, in the case where the cell edge capacity requirement for terminal device grouping is close to or at the limit, the terminal device can be pushed to another grouped cell. Preferably, the communication is sent to the base station in another cell that has a request to undertake the communication with the terminal device. Similarly, when the beamforming device buffer is close to or at the limit, the terminal device can be pushed to the grouped terminal devices in another cell. Alternatively, in the case where the cell edge capacity requirement and / or the beamforming device buffer allows accommodating another terminal device, the terminal device can be pulled into the grouped terminal devices in the cell.

[0094] In one method, the cell edge capacity requirement and / or the beamforming terminal device buffer information is collected in a massive MIMO implementation. This information can be used as an input to push / pull traffic at the cell edge, which helps in having an efficient massive MIMO operation. This can help in modifying the configuration near real-time.

[0095] Furthermore, based on a change in one or more of the parameters listed herein (such as the mobility state, the estimated payload requirement of the terminal device, SINR information, channel quality, etc.), the grouped terminal devices can be moved from the group to another group (including a group of ungrouped terminal devices).

[0096] Figure 5Depicts analysis system 500 according to one embodiment and the parameters fed into the analysis block. As an option, the present system 500 may be implemented in combination with features from any of the other embodiments listed herein (such as those described with reference to other figures). However, such an analysis system 500 and the other systems presented herein may be used in a variety of applications and / or arrangements, which may or may not be specifically described in the illustrative embodiments listed herein. Additionally, the analysis system 500 presented herein may be used in any desired environment.

[0097] Information module 502 collects some or all of the above-mentioned types of information. On the left side of this module, mobility information is collected. In the method shown, location information is collected from the location measurement mechanism of the terminal device. This information may be collected in real time, over time, etc. The mobility state of the terminal device is determined and the predictability of the mobility state is characterized. In this example, other types of information collected by this module include the payload profile of the terminal device, the SINR and channel quality profile of the terminal device, the device capability profile, and the cell edge capacity.

[0098] Some or all of the information collected by information module 502 is sent to analysis block 504 for analysis. Analysis block 504 identifies groups of terminal devices whose mobility states are predictable and can be grouped according to a location profile. The analysis block also considers the payload profile requirements and terminal device capabilities, as well as the SINR / channel quality profile, to make an optimal grouping decision in view of the resource availability at the base station.

[0099] Figure 6 Depicts a massive MIMO system 600 with multiple base stations and an analysis layer according to one embodiment. Figure 7 Depicts the massive MIMO system 600 after device grouping has been effectively performed. As an option, the present system 600 may be implemented in combination with features from any of the other embodiments listed herein (such as those described with reference to other figures). However, such an analysis system 600 and the other systems presented herein may be used in a variety of applications and / or arrangements, which may or may not be specifically described in the illustrative embodiments listed herein. Additionally, the analysis system 600 presented herein may be used in any desired environment.

[0100] First refer to Figure 6, the centralized analysis layer 602 is responsible for setting policies for terminal device grouping according to the expected states of different terminal devices (such as mobility state, payload, device support capabilities, SINR profile, etc.). The centralized analysis layer 602 can collect some of the information from multiple distributed layers so that it can make centralized decisions for each predicted terminal device. In some aspects, the distributed analysis layer 604 utilizes the centralized analysis layer 602, which can help achieve seamless mobility of terminal device grouping (e.g., by obtaining assistance from the policies prepared by the centralized analysis layer 602) without additional measurement reports from the terminal devices.

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

[0102] Terminal devices that meet the requirements of a specific group are grouped together. Many different groups can be created. Any ungrouped terminal devices are served by default resource allocation (e.g., best effort service) from the base station 605.

[0103] From Figure 5 The analysis block 500 is placed in the centralized analysis layer 602 and has the ability to collect information from multiple distributed layers so that it can make central decisions based on the predicted terminal device states. In a preferred embodiment, whenever the analysis block 500 wants to make some decisions, the analysis block 500 does not require additional terminal device measurements received from the base station 605. This in turn reduces the signaling load and improves the battery life of the terminal devices. Instead, the analysis block 500 utilizes the distributed analysis layer 604 for analysis, which can help with the seamless mobility of terminal device grouping by obtaining the instructions executed by the distributed analysis layer 604.

[0104] Once the grouping is performed by the higher-level centralized analysis layer 602, the grouping criteria are sent to the distributed analysis layer 604 according to the trained model. The distributed analysis layer 604 is responsible for allocating different profiles based on DRBs by sending RRC reconfiguration messages.

[0105] The distributed analysis layer 604 can group terminal devices based on different criteria such as payload, mobility, and location profile. In addition, the grouping decision can be determined by the intent sent from the higher-level centralized analysis layer 602.

[0106] The distributed analysis layer 604 also has the function of redistributing cell-edge terminal devices over a common radio cell for effective terminal device grouping based on information shared from the centralized analysis layer 602.

[0107] As Figure 7 shown, in response to the grouping created by the distributed analysis layer 604, the terminal devices 606 are grouped into groups. It should also be noted that additional sub-domains have been created in real time (e.g., using DRB) by grouping the terminal devices according to the formulated policies received from the higher analysis layers 602, 604. In this example, Figure 6 the terminal devices 606 in domains 1 and 2 of Figure 7 include two vehicle-based devices with medium mobility states and two user devices with low or no mobility states. This configuration is inconsistent and may lead to interference and, ultimately, blockage of network resources. Referring to

[0108] , two user devices have been grouped together in domain 2.1.

[0109] A massive MIMO network enhanced with the features presented herein not only increases the capacity of each cell but also improves the end-user experience by providing better and faster connections due to better utilization of network resources.

[0110] It is clear that the various features of the foregoing systems and / or methods can be combined in any way to create multiple combinations from the description presented above.

[0111] It should also be understood that embodiments of the present invention can be provided in the form of services deployed on behalf of customers to provide services on demand.

[0112] The description of the various embodiments of the present invention has been presented for purposes of illustration, but the description of the various embodiments is not intended to be comprehensive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein were chosen to best explain the embodiments, the principles of practical applications, or technical improvements to technologies found in the marketplace, or to enable other technicians of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for grouping devices in a massive multiple-input multiple-output (MIMO) based cellular network, the method include: Determining a mobility state of a terminal device in a cell of the massive MIMO-based cellular network; estimating payload requirements of the terminal device; as well as The terminal devices are grouped in groups based on the determined mobility states and the estimated payload requirements.

2. The computer-implemented method of claim 1, include: The movement state of the terminal device is characterized based on the predictability of the pattern of movement of the terminal device, wherein terminal devices with unpredictable patterns of movement are not placed in the group.

3. The computer-implemented method of claim 2, include: collecting signal to interference and noise ratio (SINR) information from the terminal device; and performing the grouping using the mobility status, the estimated payload requirement, the SINR information, and the capability of the terminal device.

4. The computer-implemented method of claim 1, include: creating a payload profile for the terminal device by collecting device payload patterns over time; and using the payload profile of the terminal device for the packet.

5. The computer-implemented method of claim 4, include: collecting signal to interference and noise ratio (SINR) information from the terminal device; and performing the grouping using the mobility status, the estimated payload requirement, the SINR information, and the capability of the terminal device.

6. The computer-implemented method of claim 1, wherein the payload requirement is estimated based at least in part on an application running on the respective terminal device.

7. The computer-implemented method of claim 1, include: Signal to Interference and Noise Ratio (SINR) information is collected from the terminal devices, and some of the terminal devices are grouped into a beamforming device group based on the SINR information and capabilities of the terminal devices.

8. The computer-implemented method of claim 1, include: One of the terminal devices located at the edge of the cell is pushed out of the cell based on the cell edge capacity requirement and the beamforming device buffer.

9. The computer-implemented method of claim 1, include: New terminal devices located at the edge of the cell are pulled into the cell based on the cell edge capacity requirements and the beamforming device buffer.

10. The computer-implemented method of claim 1, include: Terminal devices are moved from the group to another group based on the estimated payload requirements and changes in mobility status of the terminal devices.

11. A computer program product, the computer program product include: One or more computer-readable storage media, and program instructions stored together on the one or more computer-readable storage media, the program instructions comprising: Program instructions for determining the mobility status of a terminal device in a cell of the massive MIMO-based cellular network; program instructions for estimating payload requirements of said terminal device; and Program instructions for grouping the terminal devices in groups based on the determined mobility states and the estimated payload requirements.

12. The computer program product according to claim 11, include: Program instructions for characterizing the movement state of the terminal device based on the predictability of the pattern of movement of the terminal device, wherein terminal devices having unpredictable patterns of movement are not placed in the group.

13. The computer program product according to claim 12, include: program instructions for collecting signal to interference and noise ratio (SINR) information from the terminal device; and performing the grouping using the mobility status, the estimated payload requirement, the SINR information, and the capability of the terminal device.

14. The computer program product according to claim 11, include: program instructions for creating a payload profile for the terminal device by collecting device payload patterns over time; and program instructions for using the payload profile of the terminal device for the packet.

15. The computer program product of claim 11, wherein the payload requirement is estimated based at least in part on an application running on the corresponding terminal device.

16. The computer program product according to claim 11, include: Program instructions for collecting Signal to Interference and Noise Ratio (SINR) information from the terminal devices, and grouping some of the terminal devices into a group of beamforming devices based on the SINR information and capabilities of the terminal devices.

17. The computer program product according to claim 11, include: Program instructions for pushing one of the terminal devices located at an edge of the cell out of the cell based on cell edge capacity requirements and a beamforming device buffer.

18. The computer program product according to claim 11, include: Program instructions for pulling new terminal devices located at the edge of the cell into the cell based on cell edge capacity requirements and beamforming device buffers.

19. The computer program product according to claim 11, include: Program instructions for moving terminal devices from the group to another group based on estimated payload requirements and changes in mobility status of the terminal devices.

20. A system, include: processor; as well as Logic integrated with the processor, executable by the processor, or integrated with the processor and executable by the processor, the logic being configured to: Determining a mobility state of a terminal device in a cell of the massive MIMO-based cellular network; estimating payload requirements of the terminal device; as well as The terminal devices are grouped in groups based on the determined mobility states and the estimated payload requirements.

Images