Method and system for aggregating and exchanging messages in an IoT communication system

Abstract

The present disclosure relates to a pre-5th-Generation (5G) or 5G communication system to be provided for supporting a higher data rate beyond 4th-Generation (4G) communication system such as Long Term Evolution (LTE). The method disclosed herein includes transmitting a message request; identifying at least one of a size of each of messages associated with the message request or a priority of each of the messages associated with the message request; determining to aggregate the message request when at least one of: the size of each of the messages associated with the message request is less than a threshold segment size or the priority of each of the messages associated with the message request is one of a low priority or a medium priority; aggregating the message request into a single message request; and transmitting the single message request.

Description

Technical Field

[0001] This disclosure relates to the field of Internet of Things (IoT) communications, and more particularly to message aggregation and exchange in IoT communication systems. Background Technology

[0002] To meet the increased demand for wireless data traffic since the deployment of fourth-generation (4G) communication systems, efforts have been made to develop improved fifth-generation (5G) or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "beyond 4G networks" or "post-LTE systems".

[0003] 5G communication systems are considered to be implemented in higher frequency (mmWave) bands (e.g., the 60GHz band) to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies are discussed in 5G communication systems.

[0004] In addition, in 5G communication systems, development is underway to improve system networks based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, cooperative multipoint (CoMP), and receiver interference cancellation.

[0005] In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coding and modulation (ACM), and filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code division multiple access (SCMA) have been developed as advanced access technologies.

[0006] Messaging services, also known as MSGin5G services, are defined by the 3rd Generation Partnership Project (3GPP) in 5G systems. The 3GPP enables various messaging models with advanced messaging capabilities and performance through 5G systems. MSGin5G services support messaging models such as point-to-point messaging, application-to-point messaging, group messaging, and broadcast messaging.

[0007] Furthermore, the MSGin5G service is primarily designed and optimized for messaging communication between massive Internet of Things (MIoT) devices, including both device-to-device and person-to-device communication. Typical IoT device communication involves sending and receiving small amounts of data, which can be delivered within messages. However, the characteristics of MIoT devices, such as, but not limited to, high-density connectivity, flexible mobility, limited power-saving computing capabilities, a large number of devices, and short bursts of small data traffic patterns, bring various new demands to messaging communication. Examples of these new demands include, but are not limited to, the need for lightweight messaging communication for provisioning and monitoring, ultra-low latency and high reliability messaging communication for remote control, and extremely high resource efficiency for massive connectivity.

[0008] Based on one requirement, considering the high throughput of message communication between MIoT devices or between MIoT devices and application servers, the MSGin5G service must optimize the resource utilization of both the control plane and the user plane in a resource-efficient manner. MIoT devices may have limitations in computing and storage, and can use batteries or small solar photovoltaic devices, making message communication lightweight and well-scheduled to save on the power and data traffic consumption of MIoT devices.

[0009] Additionally, MIoT devices may send data significantly smaller than the maximum segment size allowed for transmission via available delivery. However, in this scenario, if a larger number of messages are exchanged between MIoT devices for sending and receiving data significantly smaller than the maximum segment size, control plane and user plane resources may not be fully utilized. Furthermore, exchanging a larger number of messages between MIoT devices for sending and receiving data significantly smaller than the maximum segment size can result in substantial overhead.

[0010] Additionally, MIoT devices and application servers may exchange a significantly larger number of messages than the maximum segment size. In such scenarios, control plane and user plane resources may not be fully utilized. Summary of the Invention

[0011] Technical issues

[0012] The primary objective of these embodiments is to disclose methods and systems for aggregating and exchanging messages in Internet of Things (IoT) communication systems.

[0013] Another objective of this embodiment is to disclose a method and system for aggregating multiple message requests into a single message request and transmitting the single message request to at least one target device, wherein the size of each message in each message request is less than a threshold segment size, and the priority of each message is either low priority or medium priority.

[0014] Solution to the problem

[0015] Accordingly, embodiments of this document provide a method and system for exchanging messages in Internet of Things (IoT) communications. The method includes: a first device initiating a message request to transmit a message to a second device. The method includes: the first device checking at least one of the size or priority of the message associated with the message request. The method includes: the first device determining to aggregate the message request if at least one of the following conditions is met: the size of the associated message is less than a threshold segment size or the priority of the associated message is low or medium priority. The method includes: the first device aggregating multiple message requests into a single message request, wherein each of the multiple message requests is a message request determined to be aggregated. The method includes: the first device sending the single message request to the second device.

[0016] The method further includes: receiving a single message request comprising aggregated multiple message requests by a second device. The method also includes: splitting the single message request into at least one individual message request by the second device.

[0017] Accordingly, embodiments of this document provide an Internet of Things (IoT) communication system, including a first device and a second device. The first device is configured to initiate a message request for transmitting a message to the second device. The first device is configured to check at least one of the size or priority of the message associated with the message request. The first device is configured to determine an aggregated message request if at least one of the following conditions is met: the size of the associated message is less than a threshold segment size, or the priority of the associated message is low or medium priority. The first device is configured to aggregate multiple message requests into a single message request, wherein each of the multiple message requests is the message request determined to be aggregated. The first device is configured to send the single message request to the second device.

[0018] The second device is configured to receive a single message request that includes multiple aggregated message requests. The second device is also configured to split the single message request into at least one individual message request.

[0019] These and other aspects of the exemplary embodiments herein will be better understood and appreciated when considered in conjunction with the following description and accompanying drawings. However, it should be understood that while the following description indicates exemplary embodiments and their numerous specific details, it is given by way of illustration and not limitation. Many changes and modifications can be made within the scope of the exemplary embodiments herein without departing from the spirit of the embodiments herein, and the exemplary embodiments herein include all such modifications.

[0020] Before proceeding with the detailed implementation described below, it may be advantageous to define certain words and phrases used throughout this patent document: the terms “include” and “comprise” and their derivatives mean inclusion without limitation; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “associated with” and their derivatives can mean including, being included, interconnected with, containing, being contained, connected to or connected to, coupled to or coupled to, able to communicate with, cooperate with, interleaved, juxtaposed, proximate, combined with or combined with, having, having characteristics of, etc.; the term “controller” means any device, system, or part thereof that controls at least one operation, such device may be implemented in hardware, firmware, or software, or at least some combination of both. It should be noted that the functionality associated with any particular controller can be centralized or distributed, whether local or remote.

[0021] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, processes, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, optical disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable media does not include wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media that can permanently store data and media that can store data and subsequently overwrite it, such as rewritable optical discs or erasable memory devices.

[0022] Throughout this patent document, definitions of certain words and phrases are provided, and those skilled in the art will understand that, in many, if not most, instances, these definitions apply to the prior and future use of the words and phrases defined herein.

[0023] Invention Advantages

[0024] According to this disclosure, there are improvements and related improvements in the aggregation and exchange of messages in Internet of Things (IoT) communication systems. Attached Figure Description

[0025] The embodiments described herein are illustrated in the accompanying drawings, and similar reference numerals indicate corresponding parts throughout the drawings. The embodiments herein will be better understood from the following description with reference to the accompanying drawings, wherein:

[0026] Figure 1 A network of things (IoT) communication system is described according to embodiments disclosed herein;

[0027] Figure 2 and Figure 3 This is an example block diagram depicting various components of a user equipment (UE) for aggregating multiple message requests into a single message request according to embodiments disclosed herein;

[0028] Figure 4 This is an example block diagram depicting various components of a message server for managing message exchange in an IoT communication system by aggregating multiple message requests into a single message request, according to embodiments disclosed herein.

[0029] Figure 5 Example diagrams are provided to illustrate an example architecture for exchanging messages in an IoT communication system according to embodiments disclosed herein, wherein the IoT communication system is a 5G messaging system;

[0030] Figure 6A is an example sequence diagram depicting the aggregation of group messages from one or more application clients in an originator UE and the transmission of the aggregated group messages from the originator UE to a set of target devices according to embodiments disclosed herein.

[0031] Figure 6B is an example table depicting information elements (IEs) of a single group message request initiated at the UE according to embodiments disclosed herein;

[0032] Figure 6C is an example table depicting an IE that illustrates a single group message request transmitted from a UE to a group of target devices according to embodiments disclosed herein;

[0033] Figure 7A is an example sequence diagram depicting the aggregation of group messages from one or more application servers and the transmission of the aggregated group messages to a target UE according to embodiments disclosed herein.

[0034] Figure 7B is an example table of an IE that depicts a single group message request initiated at the application server according to an embodiment disclosed herein.

[0035] Figure 7C is an example table depicting an IE that aggregates a single group message request for a target UE at a message server according to an embodiment disclosed herein;

[0036] Figure 8A is an example sequence diagram depicting the aggregation of group messages from one or more initiating UEs and the transmission of the aggregated group messages to the same application server according to embodiments disclosed herein.

[0037] Figure 8B is an example table depicting an IE that initiates a single group message request at the initiating UE according to an embodiment disclosed herein;

[0038] Figure 8C is an example table depicting an IE that aggregates a single group message request for the same application server at a message server according to an embodiment disclosed herein.

[0039] Figure 9A is an example sequence diagram depicting the aggregation of point-to-point messages from one or more application clients in an initiating UE and the transmission of the aggregated point-to-point messages from the initiating UE to a target UE according to embodiments disclosed herein.

[0040] Figure 9B is an example table depicting an IE that illustrates a single point-to-point message request initiated at the initiating UE according to an embodiment disclosed herein.

[0041] Figure 9C is an example table depicting an IE that aggregates a single point-to-point message request for a target UE at the initiating UE according to embodiments disclosed herein;

[0042] Figure 9D is an example table of IEs depicting a rejection message received by the initiating UE in response to a single point-to-point message request for transmission, according to embodiments disclosed herein.

[0043] Figure 10 This is an example sequence diagram depicting the delivery of a single aggregated point-to-point message request from an initiating UE to a target UE according to embodiments disclosed herein;

[0044] Figure 11A is an example sequence diagram depicting the aggregation of point-to-application messages from one or more application clients in an initiating UE and the transmission of the aggregated point-to-application messages from the initiating UE to an application server according to embodiments disclosed herein.

[0045] Figure 11B is an example table depicting an IE that initiates a single point-to-application message request at the initiating UE according to an embodiment disclosed herein.

[0046] Figure 11C is an example table depicting a single point-to-application message request aggregated at the initiating UE for the application server according to an embodiment disclosed herein.

[0047] Figure 11D is an example table of IEs depicting a rejection message received by the initiating UE in response to a transmitted single-point-to-application message according to embodiments disclosed herein.

[0048] Figure 12A is an example sequence diagram depicting the aggregation of application-to-point messages from one or more application servers and the transmission of application-to-point messages from a message server to a target UE according to embodiments disclosed herein.

[0049] Figure 12B is an example table of an IE that depicts a single application-to-point message request initiated at the application server according to an embodiment disclosed herein.

[0050] Figure 12C is an example table depicting a single application-to-point message request aggregated at a message server for a target UE according to embodiments disclosed herein.

[0051] Figure 13A is an example sequence diagram depicting an end-to-end process for aggregating point-to-point messages from one or more application clients in an initiating UE and transmitting the aggregated point-to-point messages from the initiating UE to a target UE, according to embodiments disclosed herein.

[0052] Figure 13B is an example table depicting an IE that illustrates a single point-to-point message request initiated at the initiating UE according to an embodiment disclosed herein.

[0053] Figure 13C is an example table depicting an IE (Internet Interface) for a single point-to-point message request aggregated at the initiating UE for a target UE according to embodiments disclosed herein; and

[0054] Figure 13D is an example table of IEs depicting a rejection message received by the initiating UE in response to a transmitted single point-to-point message request according to embodiments disclosed herein. Detailed Implementation

[0055] The following discussion Figures 1 to 1 The 3D model and the various embodiments used to describe the principles disclosed in this patent document are merely exemplary and should not be construed in any way as limiting the scope of this disclosure. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0056] The exemplary embodiments described herein, along with their various features and advantageous details, are explained more fully in conjunction with the non-limiting embodiments illustrated in the accompanying drawings, and are described in detail below. Descriptions of well-known components and processing techniques are omitted to avoid unnecessarily obscuring the embodiments herein. The description herein is merely intended to facilitate understanding of how the exemplary embodiments herein can be practiced, and further to enable those skilled in the art to practice the exemplary embodiments herein. Accordingly, this disclosure should not be construed as limiting the scope of the exemplary embodiments herein.

[0057] This document discloses methods and systems for aggregating multiple message requests associated with small data and low priority into a single message request. These embodiments aggregate multiple message requests into a single message request by processing various aspects. Examples of these aspects may include, but are not limited to:

[0058] (1) How to make message communication resources efficient in order to optimize the resource utilization of both the control plane and the user plane?

[0059] (2) What scheduling strategy should be followed to ensure that the application server is not overloaded with messages at a specific time?

[0060] (3) How does the messaging service support distributing scheduling policies to application clients? and / or

[0061] (4) How to effectively utilize resources to send and receive typical small data?

[0062] Now refer to the attached diagram, and more specifically, refer to... Figures 1 to 1 3D, in which similar reference numerals consistently denote corresponding features throughout the figure, illustrates an example embodiment.

[0063] This embodiment uses terms such as "first device," "initiating UE," "message server," "source device," and "transmission device," which are interchangeable with devices that aggregate messages and transmit aggregated messages to a target device.

[0064] In this embodiment, terms such as "second device," "target UE," "target device," and "receiving device" may be used interchangeably to indicate the device that receives the aggregated message from the first device.

[0065] In this document, terms such as “message request” and “message” may be used interchangeably.

[0066] Figure 1 An Internet of Things (IoT) communication system 100 is depicted according to embodiments disclosed herein. The IoT communication system / massive IoT (MIoT) communication system 100 mentioned herein can be configured to enable IoT / MIoT devices to exchange messages for sending or receiving data between each other. In the examples herein, data may include at least one of media (such as audio, video, images, Graphics Interchange Format (GIF), etc.), text, web pages, etc.

[0067] The IoT communication system 100 includes multiple user equipment (UE) 102a to 102n, multiple application servers (AS) 104, and a message server 106.

[0068] Multiple UEs 102a to 102n, multiple application servers 104, and message server 106 can be interconnected. In this example, multiple UEs 102a to 102n, multiple application servers 104, and message server 106 can be interconnected using a communication network 108. The communication network 108 can include at least one of the following, but is not limited to: a wired network, a value-added network, a wireless network, a satellite network, or a combination thereof. Examples of wired networks can be, but are not limited to, a local area network (LAN), a wide area network (WAN), Ethernet, etc. Examples of wireless networks can be, but are not limited to, cellular networks, wireless LAN (Wi-Fi), Bluetooth, Bluetooth Low Energy, Zigbee, Wi-Fi Direct (WFD), ultra-wideband (UWB), Infrared Data Association (IrDA), Near Field Communication (NFC), etc. Examples of cellular networks can be, but are not limited to, 3GPP Long Term Evolution (LTE / 4G), LTE-A Advanced, 5G New Radio, 6G Wireless Systems, Evolved UTRA (E-UTRA), or any other next-generation network. In another example, multiple UEs 102a to 102n, multiple application servers 104, and message server 106 can be directly connected to each other (e.g., via direct communication, via an access point, etc.). In another example, multiple UEs 102a to 102n can be connected to message server 106, and multiple UEs 102a to 102n can be connected to one or more application servers 104 through message server 106. In another example, multiple UEs 102a to 102n, multiple application servers 104, and message server 106 can be connected to each other via trunks, hubs, and gateways. It should be understood that multiple UEs 102a to 102n, multiple application servers 104, and message server 106 can be connected to each other in any of a variety of ways (including the ways described above), and can be connected to each other simultaneously in two or more of the various ways (including the ways described above).

[0069] Multiple UEs 102a to 102n can be IoT devices or MIoT devices capable of exchanging information with each other, as well as other devices (such as one or more application servers 104, message servers 106, etc.). Examples of UEs (102a to 102n) can be, but are not limited to, smartphones, mobile phones, video phones, computers, tablet PCs, netbooks, laptops, wearable devices, vehicle infotainment systems, workstations, servers, personal digital assistants (PDAs), smart plugs, portable multimedia players (PMPs), MP3 layers, mobile medical devices, lights, voice-assisted devices, cameras, home appliances, one or more sensors, etc. Examples of home appliances can be, but are not limited to, televisions (TVs), digital video disk (DVD) players, audio equipment, refrigerators, air conditioners (ACs), air purifiers, chimneys, stovetops, vacuum cleaners, ovens, microwaves, washing machines, dryers, set-top boxes, home automation control panels, security control panels, game consoles, electronic keys, cameras, electronic picture frames, coffee machines, ovens, rice cookers, pressure cookers, etc. Examples of sensors may include, but are not limited to, temperature sensors, humidity sensors, infrared sensors, gyroscope sensors, atmospheric sensors, proximity sensors, RGB sensors (brightness sensors), light sensors, thermostats, ultraviolet (UV) light sensors, dust sensors, fire detection sensors, carbon dioxide (CO2) sensors, smoke sensors, window contact sensors, water sensors, electromyography (EMG) sensors, heart rate sensors, O2 level monitor sensors, blood glucose meters, door lock sensors, light controllers, air controllers, or any other equivalent sensors. The function of each sensor can be intuitively inferred by a person skilled in the art from its name, thus omitting a detailed description.

[0070] One or more UEs 102a to 102n can be connected to the same application server 104 or different application servers 104. In one example, UEs (102a to 102n), such as EMG sensors, heart rate sensors, O2 level monitor sensors, blood glucose meters, etc., can be associated with a first application server 104, where the first application server is a health application server. In another example, UEs (102a to 102n), such as light controllers, air controllers, door lock sensors, etc., can be associated with a second application server 104, where the second application server is a smart home application server 104.

[0071] UE 102a to 102n may include one or more applications. Examples of applications may include, but are not limited to, video streaming applications, audio applications, sensor-related applications, device control-based applications, etc.

[0072] The application servers 104 mentioned herein may be servers configured to acquire, store, and manage device information, capabilities, and location information of each of one or more UEs 102a to 102n existing in an IoT environment. Examples of IoT environments may include, but are not limited to, smart home environments, smart office environments, smart hospital environments, etc. Device information may include, but is not limited to, identification values ​​(e.g., device ID information) for each of one or more UEs 102, and device types for each of one or more UEs 102. In the examples herein, identification value / device ID information may include, but is not limited to, information such as, but not limited to, Media Access Control (MAC) identifiers (MAC ID), serial numbers, unique device IDs, etc.

[0073] The message server 106 can be configured to control multiple terminals, such as, but not limited to, multiple UEs 102a to 102n, one or more application servers 104, etc.

[0074] This embodiment enables one of the UEs (102a to 102n) and / or message server 106 to manage message transmission to at least one target device via an available transport protocol. In this embodiment, the UE (102a to 102n) that sends / transmits a message to the target device may be referred to hereinafter as the initiating UE, and the UE (102a to 102n) that receives the message may be referred to hereinafter as the target UE. In this embodiment, the target device may be the target UE (102a to 102n). In another embodiment, the target device may be application server 104. In another embodiment, the target device may be a group of target UEs 102a to 102n. In another embodiment, the target device may be a group of application servers 104. Examples of transport protocols may include, but are not limited to, Hypertext Transfer Protocol (HTTP), CoAP, Session Initiation Protocol (SIP), etc.

[0075] An initiating UE (e.g., UE 102a) / message server 106 initiates / receives a message request for transmitting messages to a target device (102a to 102n) / 104 (e.g., at least one of one or more UEs (102b to 102n) and one or more application servers 104). In one example, initiating UE 102a may initiate a message request when one or more applications on initiating UE 102a want to transmit one or more messages to the target device (102b to 102n) / 104. In another example, message server 106 may receive message requests from one or more initiating UEs (102a to 102n). In yet another example, message server 106 may receive message requests from one or more application servers 104.

[0076] In embodiments, a message may include at least one of group messages, point-to-point / individual messages, point-to-application messages, application-to-point messages, delivery reports, etc. In one example, a message may include a group message from an initiating UE (102a to 102n) targeting a group of target UEs (102a to 102n). In another example, a message may include a group message from multiple different initiating UEs 102a to 102n to a group of target UEs (102a to 102n). In another example, a message may include a group message from initiating UE 102a targeting a group of target UEs (102b to 102n) / application server 104. In another example, a message may include a group message from multiple different initiating UEs (102a to 102n) targeting a group of application servers 104. In yet another example, a message may include messages from multiple application servers 104 to target UEs (102a to 102n). In another example, the message may include a point-to-point message from initiating UE 102a targeting target UE 102b. In another example, the message may include a point-to-application message from initiating UE 102a targeting application server 104. In yet another example, the message may include an application-to-point message from application server 104 targeting target UEs (102a to 102n).

[0077] In an embodiment, the message request associated with the message may include at least one of the following: group message request, point-to-point / individual message request, point-to-application message request, application-to-point message request, delivery report request, etc.

[0078] In an embodiment, a message request may include one or more fields / information elements (IEs), such as, but not limited to, a unique message identifier (ID), an application ID, a disposal type, a payload, and a priority. The unique message ID identifies the message. The application ID identifies the application to which the payload on the target device (102b to 102n) / 104 is targeted. The disposal type indicates the type of disposal expected from the target device (102b to 102n) / 104. Examples of disposal types may include, but are not limited to, "Request to deliver report," "Request to read report," etc. The payload identifies the actual message. The message priority indicates one of low, medium, or high priority.

[0079] When initiating / receiving a message request, the initiating UE 102a / message server 106 checks at least one of the following, but not limited to: message size, message priority, etc. The sending UE 102a / message server 106 checks the message size (including header and payload) using the associated message request's IE and checks the message priority using the associated message request's priority IE. The initiating UE 102a / message server 106 compares the message size with a threshold segment size. The threshold segment size is the maximum size allowed for a message request / message to be transmitted to the target device (102b to 102n) / 104 via an available transport protocol. In this example, the threshold size may be defined / set based on the type of available transport protocol; however, it will be apparent to those skilled in the art that any other similar constraints can be considered for defining / setting the threshold segment size.

[0080] If the message size is less than the threshold segment size and / or the message priority is low or medium, the initiating UE 102a / message server 106 determines to aggregate the message requests associated with the corresponding message.

[0081] The initiating UE 102a / message server 106 initiates a process of aggregating multiple message requests into a single message request based on a scheduling policy. According to the scheduling policy, the initiating UE 102a / message server 106 determines a time period to wait for receiving subsequent message requests to be aggregated before sending the single message request to the target devices (102b to 102n) / 104. In this example, the time period may be determined based on a time period specified when implementing system 100 (e.g., by an operator). When determining the time period, the initiating UE 102a / message server 106 starts a timer with a timer value for the determined time period. When starting the timer, the initiating UE 102a / message server 106 recursively initiates / receives subsequent message requests and determines to aggregate each subsequent message request based on the size and / or priority of the message associated with each subsequent message request, until the timer expires or until the total number of message requests to be aggregated is less than or nearly equal to a threshold segment size.

[0082] When the timer expires, or if the total number of message requests to be aggregated is determined to be less than or nearly equal to the threshold segment size, the initiating UE 102a / message server 106 will determine that the multiple message requests to be aggregated are aggregated into a single message request. The sending UE 102a / message server 106 aggregates multiple message requests into a single message request by including at least one of the following (but not limited to): the identifier (ID) of the messaging client module 304 in the sending UE 102a, the ID of the messaging client module 304 in the target devices (102b to 102n) / 104, the message ID of the single message request to the target device, the total number of message requests to be aggregated in the single message request, and a list of the individual messages to be aggregated, etc. The size of the single message request is less than or equal to the threshold segment size.

[0083] The initiating UE 102a / message server 106 transmits a single message request to the target devices (102b to 102n) / 104. The initiating UE 102a can also transmit a single aggregated message request to the target devices (102b to 102n) / 104 via message server 106. Message server 106 transmits the single aggregated message request to the target devices (102b to 102n) / 104 according to the procedure defined in 3GPP specification 23.700-24, wherein a single message request comprising multiple aggregated message requests has been transmitted, rather than individual message requests.

[0084] Consider an example scenario where initiating UE 102a initiates a first message request comprising a 600-byte message with low priority. In this scenario, initiating UE 102a compares the message size with a threshold segment size (e.g., 1200 bytes). Since the first message request's message size is smaller than the threshold segment size and its priority is low, initiating UE 102a determines to aggregate the first message request. Then, initiating UE 102a initiates the process of aggregating the message request based on a scheduling policy. According to the scheduling policy, initiating UE 102a starts a timer. Initiating UE 102a initiates a second message request (e.g., comprising a 200-byte message with low priority) and a third message request (e.g., comprising a 400-byte message with medium priority). Initiating UE 102a determines that the total size of the first, second, and third message requests / messages equals the threshold segment size. In this scenario, initiating UE 102a terminates the timer and aggregates the first, second, and third message requests into a single message request. The initiating UE102a transmits a single message request to the target devices (102a to 102n) through the message server 106.

[0085] Consider another example scenario where initiating UE 102a initiates a first message request and determines to aggregate the first message request. Then, initiating UE 102a initiates the process of aggregating the message request based on a scheduling policy. According to the scheduling policy, initiating UE 102a starts a timer. Initiating UE 102a initiates second, third, and fourth message requests and determines that the total size of the first, second, third, and fourth message requests exceeds a threshold segment size. In this scenario, initiating UE 102a terminates the timer and aggregates the first, second, and third message requests into a single message request. Initiating UE 102a transmits the single message request to the target devices (102a to 102n) through message server 106.

[0086] Consider the example scenario where initiating UE 102a initiates a first message request and determines to aggregate the first message request. Then, initiating UE 102a initiates an aggregated message request based on a scheduling policy. According to the scheduling policy, initiating UE 102a starts a timer. Initiating UE 102a initiates second, third, and fourth message requests and determines to aggregate the second, third, and fourth message requests until the timer expires. The total size of the first, second, third, and fourth message requests is less than the threshold segment size. In this scenario, initiating UE 102a aggregates the first, second, third, and fourth message requests into a single message request. Initiating UE 102a transmits the single message request to the target devices (102a to 102n) through message server 106.

[0087] The embodiments described herein enable the target device (102b to 102n) / 104 to manage the reception of a single message request that includes multiple aggregated message requests.

[0088] The target device (102b to 102n) / 104 receives a single message request from the initiating UE 102a / message server 106, which includes multiple aggregated message requests. The target device (102b to 102n) / 104 then breaks down the single message request into one or more individual message requests.

[0089] This embodiment enables message server 106 to manage the exchange of messages between initiating UE 102a and target devices (102b to 102n) / 104.

[0090] Message server 106 receives a single message request from initiating UE 102a for target devices (102b to 102n) / 104. The single message request comprises aggregated multiple message requests. Each message request may be associated with at least one of the following (but not limited to): point-to-point message, group message, etc. Upon receiving a single message request from initiating UE 102a, message server 106 verifies initiating UE 102a to check whether initiating UE 102a is authenticated and authorized to transmit the single message request to target devices (102b to 102n) / 104. Message server 106 may verify initiating UE 102a based on one or more policies. In one example, a policy may indicate restrictions on certain types of messages or content to a specific target device (102b to 102n) / 104 due to at least one of associated location, user permissions, etc. In another example, a policy may indicate whether initiating UE 102a is registered for transmitting single message requests. In another example, the policy can instruct the initiating UE 102a whether it is configured or authorized by the application server 104 to transmit a single message request.

[0091] If the sending UE 102a is authorized and authenticated to transmit a single message request, the message server 106 parses the group ID present in the single message request (i.e., the ID of the messaging client module 304 in the target device) to determine the target device (102b to 102n) / 104 for which the single message request must be transmitted, and determines the registration status of the target device (102b to 102n) / 104 based on information / assistance received from the group management server (not shown). After parsing the group ID of the target device (102b to 102n) / 104 and determining the registration status, the message server 106 transmits the single message request received from the initiating UE 102a to the target device (102b to 102n) / 104.

[0092] Message server 106 can also request target devices (102b to 102n) / 104 to transmit a delivery report for a received single message request. In this scenario, when target devices (102b to 102n) / 104 receive a single message request from initiating UE 102a via message server 106, they transmit a delivery report to message server 106. Message server 106 then forwards / transmits the delivery report received from target devices (102b to 102n) / 104 to initiating UE 102a.

[0093] Therefore, exchanging a single message request, which includes multiple aggregated message requests, between devices optimizes the use of control plane and user plane resources, which further saves power consumption.

[0094] Figure 1Exemplary blocks of the IoT communication system 100 are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the IoT communication system 100 may include fewer or more blocks. Furthermore, the labels or names of the blocks are used for illustrative purposes only and do not limit the scope of the embodiments herein. One or more blocks may be combined together to perform the same or substantially similar functions in the IoT communication system 100.

[0095] Figure 2 This is an example block diagram depicting various components of a UE (e.g., UE 102a) for aggregating multiple message requests into a single message request according to embodiments disclosed herein. UE 102a includes a memory 202, an interface 204, and processing circuitry 206. UE 102a may also include at least one of at least one antenna, at least one RF transceiver coupled to processing circuitry 206, transmit processing circuitry, receive processing circuitry, a display, input / output (I / O) ports, etc. (not shown).

[0096] Memory 202 stores at least one of, but is not limited to, one or more applications, one or more messages, a threshold segment size allowing message requests to be transmitted via an available transmission protocol, aggregated message requests, etc. Examples of memory 202 may include, but are not limited to, NAND, embedded multimedia card (eMMC), secure digital card (SD), universal serial bus (USB), serial advanced technology accessory (SATA), solid-state drive (SSD), etc. Memory 202 may also include one or more computer-readable storage media. Memory 202 may also include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Furthermore, in some examples, memory 202 may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be construed as meaning that memory 202 is not removable. In some examples, memory 202 may be configured to store more information than is currently used for storage. In some examples, non-transitory storage media can store data that can change over time (e.g., in random access memory (RAM) or cache).

[0097] Interface 204 can be configured to enable UE 102a to communicate with one or more application servers 104 and message servers 106 via the interface. Examples of the interface may be, but are not limited to, wired or wireless fronthaul interfaces, wired or wireless backhaul interfaces, or any other structure that supports communication via wired or wireless connections.

[0098] Processing circuitry 206 includes at least one of a single processor, multiple processors, multiple homogeneous or heterogeneous cores, multiple different types of central processing units (CPUs), microcontrollers, special media, and other accelerators. Processing circuitry 206 can be configured to aggregate multiple message requests into a single message request and transmit the single message request to the target device (102b to 102n) / 104. Processing circuitry 206 can also be configured to receive a single message request from message server 106 and split the received single message request into multiple individual message requests.

[0099] like Figure 3 As depicted, the processing circuit 206 includes one or more application modules 302 and a client module / message client module 304.

[0100] One or more application modules 302 may be associated with one or more applications present in UE 102a. The application modules(s) 302 may be configured to initiate message requests for transmitting messages to target devices (102b to 102n) / 104. In an example, application module 302 may initiate a message request when an associated application wants to send data to target devices (102b to 102n) / 104. In an example, target devices (102b to 102n) / 104 may include at least one of the following: a group of target UEs (102b to 102n), a target UE (e.g., UE 102b), a group of application servers 104, a specific application server 104, etc. In an example, the message may include a group message targeting the same group of target UEs (102b to 102n). In another example, the message may include a point-to-point message targeting a specific target UE 102b. In yet another example, the message may include a group message targeting the same group of application servers 104. In another example, the message may include a point-to-application message targeting a specific application server 104.

[0101] Client module 304 can be configured to aggregate multiple message requests into a single message request and transmit the single message request to the target device (102b to 102n) / 104. Client module 304 receives message requests initiated by application module 302. Message requests can be associated with messages for the target device (102b to 102n) / 104. Client module 304 checks the message size and / or message priority. If the message size is less than a threshold segment size and / or the message priority is low or medium, then client module 304 determines to aggregate the associated message requests.

[0102] Client module 304 can aggregate message requests based on a scheduling policy. According to the scheduling policy, client module 304 determines the time period to wait for receiving subsequent message requests from application module 302. Upon determining the time period, client module 304 starts a timer. The timer value can be the determined time period to wait for receiving subsequent message requests. When the timer starts, client module 304 recursively collects / receives subsequent message requests from one or more application modules 302, and determines to aggregate each subsequent message request by checking the size and / or priority of the message associated with each subsequent message request, until the timer expires or the total number of message requests to be aggregated is less than or nearly equal to a threshold segment size. When the timer expires or the total number of message requests to be aggregated is less than or nearly equal to the threshold segment size, client module 304 aggregates the determined multiple message requests to be aggregated (including the message request initially received from application module 302 and subsequent message requests) into a single message request.

[0103] The client module 304 transmits a single message request to the message server 106, which in turn transmits a single message request to the target devices (102b to 102n) / 104.

[0104] If UE 102a is not authenticated and authorized to transmit a single message request to the target device (102b to 102n) / 104 or the single message request is invalid, the client module 304 may also receive a rejection message with a rejection reason from the message server 106.

[0105] The client module 304 can also receive a delivery report from the target devices (102b to 102n) / 104 via the message server 106 when a single message request is successfully delivered to the target devices (102b to 102n) / 104.

[0106] In an embodiment, if UE 102a is the target device (i.e., UE 102a is intended to receive a single message request from other UEs (102b to 102n) / application server 104), then client module 304 may also be configured to manage the reception of single message requests.

[0107] Client module 304 receives a single message request from the initiating UE (102b to 102n) or application server 104 via message server 106. Client module 304 splits / decodes the single message request into individual message requests. Client module 304 splits the single message request into individual message requests using a list of individual message IEs present in the single message request and a separator. The list of individual message IEs represents the total number of individual message requests aggregated in the single message request. The separator can be used to indicate the start of an individual message request. Client module 304 forwards the message associated with the individual message request to one or more application modules 302 for further processing. In this example, one or more application modules 302 may provide the received message to one or more applications.

[0108] The client module 304 can also be configured to receive a delivery report request from the message server 106 in a received single message request. In this scenario, the client module 304 transmits a delivery report to the message server 106 when it receives a single message request from the initiating UE (102a to 102n) via the message server 106.

[0109] Figure 2 and Figure 3 Exemplary blocks of the UE (102a to 102n) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the UE (102a to 102n) may include fewer or more blocks. Furthermore, the labels or names of the blocks are used for illustrative purposes only and do not limit the scope of the embodiments herein. One or more blocks may be combined together to perform the same or substantially similar functions in the UE (102a to 102n).

[0110] Figure 4 This is an example block diagram depicting various components of a message server 106 for managing message exchange in an IoT communication system 100 by aggregating multiple message requests into a single message request, according to embodiments disclosed herein. The message server 106 mentioned herein can be a cloud computing device (which may be part of a public or private cloud), a standalone server, a server in the cloud, a database, a computing device, etc. Examples of computing devices may include, but are not limited to, personal computers, laptops, tablets, desktop computers, laptop computers, handheld devices, mobile devices, etc. Furthermore, the message server 106 can be at least one of a microcontroller, processor, system-on-a-chip (SoC), integrated chip (IC), microprocessor-based programmable consumer electronics device, etc. The message server 106 includes a memory 402, an interface 404, and a controller 406.

[0111] Memory 402 stores at least one of, but is not limited to, information about UEs 102a to 102n and application server 104, aggregated multiple messages, threshold segment sizes, and one or more policies of the authentication initiator UEs (102a to 102n). Examples of memory 402 may include, but are not limited to, NAND, embedded multimedia card (eMMC), secure digital card (SD), universal serial bus (USB), serial advanced technology accessory (SATA), solid-state drive (SSD), etc. Memory 402 may also include one or more computer-readable storage media. Memory 402 may also include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Furthermore, in some examples, memory 402 may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier or propagating signal. However, the term "non-transitory" should not be construed as meaning that memory 402 is not movable. In some examples, memory 402 may be configured to store more information than memory. In some examples, non-transitory storage media may store data that can change over time (e.g., in random access memory (RAM) or cache).

[0112] Interface 404 can be configured to enable message server 106 to communicate with UEs 102a to 102n, one or more application servers 104, or group management servers, etc. Examples of the interface may be, but are not limited to, wired or wireless fronthaul interfaces, wired or wireless backhaul interfaces, or any other structure that supports communication via wired or wireless connections.

[0113] The controller 406 includes at least one of a single processor, multiple processors, multiple homogeneous or heterogeneous cores, multiple different types of central processing units (CPUs), microcontrollers, special media, and other accelerators.

[0114] In an embodiment, controller 406 may be configured to aggregate message requests received from (multiple) initiating UEs 102a or (multiple) application servers 104 into a single message request and transmit the single message request to target devices (102b to 102n) / 104.

[0115] Controller 406 receives a message request for transmitting a message to target devices (102b to 102n) / 104. In one example, controller 406 may receive the message request from different initiating UEs (102b to 102n). In another example, controller 406 may receive a message request from one or more application servers 104. In one example, target devices (102b to 102n) / 104 include target UEs (102b to 102n) or a group of target UEs (102b to 102n). In another example, target devices (102b to 102n) / 104 include application server 104 or a group of application servers 104. The message may include at least one of the following:

[0116] Group messages originating from the initiating UE (102a to 102n) targeting the same group of target UEs (102a to 102n);

[0117] Group messages from multiple different initiating UEs (102a to 102n) targeting the same group of target UEs (102a to 102n);

[0118] Group messages from multiple different initiating UEs (102a to 102n) targeting the same group of application servers 104;

[0119] Messages from one or more application servers 104 targeting the same UE (102a to 102n);

[0120] A point-to-point message from initiating UE 102a to target UE 102b;

[0121] A point-to-application message originating from UE 102a and targeting application server 104;

[0122] Application-to-delivery messages from application server 104 targeting UEs (102a-102bn); or

[0123] Delivery report from initiating UE 102a to target device (102b to 102n) / 104.

[0124] Controller 406 checks the size and / or priority of the message associated with the received message request. If the message size is such that only one message can be sent within a threshold segment size that can be transmitted via available transmission, controller 406 transmits the message to the target device (102a to 102n) / 104. If the message size is less than the threshold segment size and / or the message priority is low or medium priority, controller 406 determines to aggregate the message.

[0125] The controller 406 initiates a process based on a scheduling policy to receive multiple subsequent message requests from the initiating UE (102a to 102n) or application server 104 and to aggregate the multiple subsequent message requests into a single message request. The controller 406 aggregates multiple subsequent message requests into a single message request based on a scheduling policy, similar to the client module 304 of UE 102a, and therefore, for the sake of brevity, its repeated description is omitted.

[0126] When an aggregate message request is made, controller 406 transmits a single message request to the appropriate target device (102a to 102n) / 104 in accordance with the procedure defined in 3GPP specification 23.700-24.

[0127] In another embodiment, controller 406 may also be configured to receive a single message request from initiating UE 102a and transmit the received single message request to the corresponding target devices (102a to 102n) / 104. The single message request may include multiple aggregated message requests already associated with point-to-point messages and group messages. To transmit the single message request to the target devices (102b to 102n) / 104, controller 406 checks, based on one or more policies, whether initiating UE 102a is authenticated and authorized to transmit the single message request to the target devices (102b to 102n) / 104. If initiating UE 102a is not authenticated and authorized to transmit the single message request to the target devices (102b to 102n) / 104, controller 406 transmits a rejection message with a rejection reason to initiating UE 102a. If the initiating UE 102a is authenticated and authorized to transmit a single message request to the target devices (102b to 102n) / 104, the controller 406 parses the group ID of the target devices (102b to 102n) and transmits the single message request received from the initiating UE 102a to the corresponding target devices (102b to 102n) / 104.

[0128] In an embodiment, controller 406 may also be configured to transmit a delivery report request for the delivery report to target devices (102b to 102n) / 104 in a single message request. In response to the delivery report request, when target devices (102b to 102n) / 104 receive a single message request from initiating UE 102a, controller 406 receives a delivery report from target devices (102b to 102n) / 104. Controller 406 forwards the received delivery report to initiating UE 102a.

[0129] Figure 4Exemplary blocks of message server 106 are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, message server 106 may include fewer or more blocks. Furthermore, the labels or names of blocks are used for illustrative purposes only and do not limit the scope of the embodiments herein. One or more blocks may be combined to perform the same or substantially similar functionality in message server 106.

[0130] Figure 5 Example diagrams are provided to illustrate the exchange of messages in an IoT communication system 100 according to embodiments disclosed herein, wherein the IoT communication system 100 is a 5G messaging system.

[0131] As an example, the embodiments described herein describe the exchange of messages in a 5G messaging system, but it will be apparent to those skilled in the art that any other network system can be considered.

[0132] like Figure 5 As depicted, the 5G messaging system 100 includes one or more UEs 102a to 102n (e.g., traditional UEs, 5G Messaging (MSGin5G) UEs, non-3GPP UEs, etc.), an application server 104, and a message server / MSGin5G server 106. The MSGin5G UEs (102a to 102n) include (multiple) application modules / application clients 302 and client modules / MSGin5G clients 304.

[0133] In an embodiment, the MSGin5G client 304 of the MSGin5G UE (102a) can be configured to aggregate multiple message requests targeting the same set of target UEs / application servers 104 into a single message request.

[0134] In an embodiment, the MSGin5G client 304 can be configured to aggregate multiple message requests targeting a single UE (102a to 102n) or application server 104 into a single message request.

[0135] In an embodiment, the MSGin5G server 106 can be configured to aggregate multiple message requests targeting the application server 104 into a single message request.

[0136] In an embodiment, the MSGin5G server 106 can be configured to aggregate multiple message requests targeting a single set of target devices (102a to 102n) / 104 into a single message request.

[0137] In an embodiment, the MSGin5G server 106 can be configured to aggregate multiple message requests targeting a single UE (102a to 102n) into a single message request.

[0138] The messages associated with each of the aggregated message requests (as described above) have a size smaller than the threshold segment size (i.e., corresponding to small data) and a low or medium priority. The size or length of a single message request is less than or equal to the threshold segment size that allows the message request to be transmitted via the available delivery protocol.

[0139] The embodiments described herein are intended as examples to further explain message exchange in a 5G messaging system; however, it will be apparent to those skilled in the art that IoT communication systems supporting any other network can be considered. The UE (102a to 102n) in the 5G messaging system includes one or more application modules / application clients 302 associated with one or more applications, and a client module / MSGin5G client 304. The MSGin5G client 304 registers with the message server / MSGin5G server 106.

[0140] Figure 6A is an example sequence diagram depicting the aggregation of group messages from one or more application clients in an initiating UE 102a and the transmission of the aggregated group messages from the initiating UE 102a to the target devices (102b to 102n) / 104 according to embodiments disclosed herein.

[0141] At step 1, multiple application clients 302 on UE 102a / UE 1 (initiating UE 102a) initiate multiple first message requests to MSGin5G client 1 for transmitting messages to multiple target devices (102b to 102n) / 104. In this example, the target devices may include a group of UEs (102b to 102n) / a group of application servers 104. In this example, the first message request may be a first group message request associated with a group message.

[0142] In step 2, MSGin5G client 1 determines whether the initiated first group message request can be aggregated. To determine whether the first message request can be aggregated, MSGin5G client 1 checks the size and / or priority of the group messages associated with the first group message request. MSGin5G client 1 uses the IE of the first message request to check the size and / or priority of the group messages. The IE of individual group message requests is depicted in the example table in Figure 6B. If the size of the group message is less than the threshold segment size and the message priority is low or medium, then MSGin5G client 1 determines to aggregate the message requests.

[0143] When determining the message requests to be aggregated, MSGin5G client 1 initiates a process of aggregating multiple group message requests into a single message request / single group message request based on a scheduling policy. According to the scheduling policy, MSGin5G client 1 determines the time period to wait for receiving subsequent message requests from application client 302. When determining the time period, MSGin5G client 1 starts a timer with the timer value of the determined time period to wait for receiving subsequent message requests. When starting the timer, steps 1 and 2 can be executed recursively until the timer expires, or until the optimal use of the segment size is reached (i.e., the total number of messages to be aggregated is less than or nearly equal to the threshold segment size). Steps 1 and 2 can be executed to initiate subsequent group message requests from one or more application clients and determine whether each subsequent group message can be aggregated. When the timer expires or the optimal use of the segment size is reached, MSGin5G client 1 aggregates the multiple group message requests determined to be aggregated (e.g., including the first group message request and subsequent group message requests) into a single group message request. The IE of the single group message request is depicted in the example table of Figure 6C. The size / length of a single group message request is less than or equal to the threshold segment size that already allows the transmission of a single group message request.

[0144] In step 3, MSGin5G client 1 sends a single group message request to message server / MSGin5G server 106, which includes aggregated multiple group message requests.

[0145] In step 4, the MSGin5G server 106 verifies the MSGin5G client 1 to check whether the MSGin5G client 1 of UE1 is authenticated and authorized to transmit a single group message request to a group of target UEs (102b to 102n). The MSGin5G server 106 verifies the MSGin5G client 1 based on one or more policies, such as, but not limited to, restrictions on certain types of messages or content for certain UEs due to location or user permissions. If the MSGin5G client 1 is authenticated and authorized to transmit the single group message request, the MSGin5G server parses the group ID / MSGin5G group ID present in the single group message request (as depicted in the example table of Figure 6C) to determine the target devices (102b to 102n) / 104, and determines the registration status of the target devices (102b to 102n) based on information from the group management server. If the MSGin5G client 1 is authenticated and authorized to transmit the single group message request, the MSGin5G server 106 skips step 5.

[0146] If MSGin5G client 1 is not authenticated and authorized to transmit a single group message request or the single group message request is invalid, then MSGin5G server 106 executes step 5. In step 5, MSGin5G server 106 transmits a rejection message / aggregated group message rejection message with a rejection reason to MSGin5G client 1. The IE defined in 3GPP TR23.700-24 is included in the rejection message.

[0147] If MSGin5G client 1 is authenticated and authorized to transmit a single group message request, then at step 6, MSGin5G server 106 follows... Figure 10 The process defined in the document transmits a single group message request (as specified in step 2) to the target device (102a to 102n) / 104, wherein a single group message request comprising multiple aggregated group message requests has been transmitted, rather than a separate message request.

[0148] Consider an example scenario where, for example UE 1, the AC controller includes three application clients associated with three applications, and these three application clients 302 can be coupled to MSGin5G client 1. In this scenario, the three application clients initiate group message requests simultaneously or sequentially to transmit group messages for the same group of target devices (e.g., group 1), where group 1 includes a group of target UEs (102b to 102n) that are being used by family members (existing in the same group). The group message may indicate at least one of the following: current temperature, AC mode, notification of a change in AC mode, etc. In this example, consider that each group message may have a size smaller than a threshold segment size and a low priority. In this scenario, MSGin5G client 1 aggregates group message requests into a single group message request based on a scheduling policy. MSGin5G server 106 transmits the single group message request simultaneously to the target UEs of group 1. Thus, control plane and user plane resources are effectively utilized.

[0149] Figure 7A is an example sequence diagram depicting the aggregation of group messages from one or more application servers and the transmission of the aggregated group messages to a target UE (102a to 102n) according to embodiments disclosed herein.

[0150] At step 1, the MSGin5G server 106 receives multiple first message requests for the target device from the application server 104. In this example, as depicted in FIG7A, the message requests include group message requests associated with group messages, and the target device includes UE 2 / UE 102b (for example). UE 2 includes one or more application clients 302 and client modules 304 / MSGin5G client 2.

[0151] At step 2, the MSGin5G server 106 determines whether the initiated first group message request can be aggregated. To determine whether the first group message request can be aggregated, the MSGin5G server 106 checks the size and / or priority of the group message associated with the first group message request. The MSGin5G server 106 uses the IE of the first group message request to check the size and / or priority of the group message. The IE of individual group message requests initiated by the application server 104 is depicted in the example table of Figure 7B. If the size of the group message is less than the threshold segment size and the priority of the group message is low or medium priority, the MSGin5G server 106 determines to aggregate the first group message request. Additionally, steps 1 and 2 can be performed multiple times to receive multiple subsequent group message requests from one or more application servers 104 and determine whether each of the multiple subsequent group message requests can be aggregated. Steps 1 and 2 can be performed multiple times until a timer expires or until the optimal use of the segment size is reached. When the timer expires or the optimal segment size is reached, the MSGin5G server 106 will determine which multiple group message requests (e.g., including a first group message request and subsequent group message requests) should be aggregated into a single group message request. The IE of a single group message request is depicted in the example table in Figure 7C. The size / length of the single group message request is less than or equal to the threshold segment size that has already allowed the transmission of a single group message request.

[0152] In step 3, the MSGin5G server 106 transmits a single group message request to the UE 2, which includes aggregated multiple group message requests.

[0153] In step 4, UE 2's 5GSMS client 2 splits the received single group message request into multiple individual group message requests according to the application, and forwards the multiple individual group message requests to the application client 302.

[0154] Consider an example scenario where a home appliance server and a health application server (example application server 104) are associated with UE 2. The home application server may be coupled to at least one of a light controller, AC controller, door lock sensor, etc. The health application server may be coupled to at least one of an EMG sensor, blood glucose meter, etc. The home application server and the health application server simultaneously or sequentially transmit multiple group message requests to the MSGin5G server 106, these requests already being directed to the same UE2. The group message requests transmitted by the home appliance server may include group messages indicating the status / operation of devices present in the home. The group message requests transmitted by the health application server may include group messages indicating health notifications. In this example, consider that the group messages associated with each group message request have a size smaller than a threshold segment size and a medium priority. In this scenario, the MSGin5G server 106 aggregates the multiple group message requests received from the home appliance server and the health application server into a single message request based on a scheduling policy. The MSGin5G server 106 transmits the single message request to UE2. The 5GSMS client 2 of UE 2 splits the received single group message request into multiple separate group message requests for further processing.

[0155] Figure 8A is an example sequence diagram depicting the aggregation of group messages from one or more initiating UEs (102a to 102n) and the transmission of aggregated group message requests to the same application server 104 according to embodiments disclosed herein.

[0156] In step 1, the MSGin5G server 106 receives a first message request from the first UE 102a / UE 1 (initiating UE 102a) to transmit a message to the target device. In this example, as depicted in FIG8A, the message request may be a group message request that includes group messages, and the target device includes the application server 104.

[0157] At step 2, the MSGin5G server 106 determines whether the first group message request can be aggregated. To determine whether the first group message request can be aggregated, the MSGin5G server 106 checks the size and / or priority of the group message associated with the first group message request. The MSGin5G server 106 uses the IE of the first group message request to check the message size and / or priority. The IEs of individual group message requests received from UEs (102a to 102n) are depicted in the example table of Figure 8B. If the size of the group message is less than the threshold segment size and the priority of the group message is low or medium priority, the MSGin5G server 106 determines that the associated first message request can be aggregated. Additionally, steps 1 and 2 can be performed multiple times to receive multiple subsequent group message requests from UE 1 and UE 2 and determine whether each of the multiple subsequent group message requests can be aggregated. Steps 1 and 2 can be performed multiple times until a timer expires or until the optimal use of the segment size is reached. When the timer expires or the optimal segment size is reached, the MSGin5G server 106 determines which multiple group message requests to aggregate (e.g., including a first group message request received from UE1 and subsequent group message requests received from UE1 and UE2) to be aggregated into a single group message request. The IE of a single group message request is depicted in the example table in Figure 8C. The size / length of the single group message request is less than or equal to the threshold segment size that already allows the transmission of a single group message request.

[0158] In step 3, the MSGin5G server 106 parses the group ID / MSGin5G group ID present in the single group message request (as depicted in the example table of Figure 8C) to determine the application server 104 for which the single message request must be transmitted.

[0159] In step 4, the MSGin5G server 106 transmits a single group message request to the application server 104 according to the procedure defined in 3GPP TR 23.700-24, wherein a single group message request comprising multiple aggregated group message requests has been transmitted, instead of a separate group message request.

[0160] Consider an example scenario where light controller 1 and light controller 2 (examples for UEs 102a to 102n) simultaneously transmit multiple group message requests or transmit one group message request at a time to MSGin5G server 106. These requests are already directed to the same home application server (example for application server 104). The multiple group message requests include group messages for indicator light status, notifications for setting changes, etc. In this example, consider that the group messages associated with each group message request may have a size smaller than a threshold segment size and a low priority. In this scenario, MSGin5G server 106 aggregates the received multiple group message requests into a single group message request according to a scheduling policy. MSGin5G server 106 transmits the single group message request to the home application server instead of transmitting individual group message requests. This effectively utilizes control plane and user plane resources.

[0161] Figure 9A is an example sequence diagram depicting the aggregation of point-to-point messages from one or more application clients in an initiating UE 102a and the transmission of the aggregated point-to-point messages from the initiating UE 102a to the target UE 102b according to embodiments disclosed herein.

[0162] In step 1, the application client 1 of the first UE / UE 1 (initiating UE 102a) initiates a first message request for transmitting a message to the target device. In this example, as depicted in FIG9A, the message request may be a point-to-point message request including a point-to-point message, and the target device is the second UE / UE 2.

[0163] At step 2, UE 1's MSGin5G client 1 determines whether the first point-to-point message request can be aggregated. To determine whether the first point-to-point message request can be aggregated, MSGin5G client 1 checks the size and / or priority of the point-to-point message associated with the first point-to-point message request. MSGin5G client 1 uses the IE of the first point-to-point message request to check the size and / or priority of the point-to-point message. The IE of a single point-to-point message request is depicted in the example table in Figure 9B. If the size of the point-to-point message is less than the threshold segment size and the message priority is low or medium priority, then MSGin5G client 1 determines that the corresponding first point-to-point message request can be aggregated. Additionally, steps 1 and 2 can be performed multiple times to initiate multiple subsequent point-to-point message requests from one or more application clients and determine whether each group message request in the multiple group message requests can be aggregated by MSGin5G client 1. Steps 1 and 2 can be performed multiple times until a timer expires or until the optimal use of the segment size is reached. When the timer expires or the optimal segment size is reached, the MSGin5G client 1 will determine which multiple point-to-point message requests (including the first point-to-point message request and subsequent point-to-point message requests) should be aggregated into a single message request / single point-to-point message request. The IE of a single point-to-point message request is depicted in the example table in Figure 9C. The size / length of a single group message request is less than or equal to the threshold segment size that already allows the transmission of single point-to-point message requests.

[0164] In step 3, MSGin5G client 1 sends a single point-to-point message request for UE 2 to MSGin5G server 106.

[0165] In step 4, the MSGin5G server 106 verifies the MSGin5G client 1 of UE 1 to check whether the MSGin5G client 1 is authenticated and authorized to transmit a single point-to-point message request to UE 2. If the MSGin5G client 1 is authenticated and authorized, the MSGin5G server 106 skips step 5.

[0166] If MSGin5G client 1 is not authenticated and authorized, or the single point-to-point message request is invalid, then MSGin5G server 106 executes step 5. In step 5, MSGin5G server 106 transmits a message rejection / aggregated message rejection with a rejection reason to UE 1's MSGin5G client 1. The message rejection IE is depicted in the example table of Figure 9D.

[0167] If MSGin5G client 1 is authenticated and authorized to send a single point-to-point message to UE 2, then at step 7, MSGin5G server 106 sends the received point-to-point message from MSGin5G client 1 to UE 2 (e.g., Figure 10 (As depicted). Additionally, at step 7, upon receiving a delivery report from UE 2, the MSGin5G server 106 transmits the delivery report to the MSGin5G client 1. At step 9, the MSGin5G client 1 transmits the received delivery report to one or more application clients 1 of UE 1 for further processing.

[0168] Figure 10 This is an example sequence diagram depicting the delivery of a single aggregated point-to-point message request from an initiating UE / UE 1 to a target UE / UE 2 according to embodiments disclosed herein.

[0169] In step 1, the MSGin5G server 106 receives a single aggregated point-to-point message request (as depicted in step 7 of Figure 9A), which includes multiple aggregated point-to-point message requests, and this single aggregated point-to-point message request is already directed to UE 2. In step 2, the MSGin5G server 106 sends the single point-to-point aggregated message request received from UE 1 to the MSGin5G client 2 of UE 2.

[0170] In step 3, MSGin5G client 2 splits the received single point-to-point aggregated message request into multiple individual message requests according to the application, and forwards the multiple individual message requests to application client(s) of UE 2. In step 4, if requested by the single point-to-point message request received by MSGin5G client 2 in step 3 by MSGin5G server 106, application client 2 of UE 2 initiates the sending of a delivery report to MSGin5G client 2. In step 5, MSGin5G client 2 transmits the delivery report to MSGin5G server 106.

[0171] Consider an example scenario where the air controller (example for UE 1) simultaneously transmits multiple point-to-point message requests or transmits one point-to-point message request at a time to the MSGin5G server 106. These requests are already directed to UE 2, which the user is currently using at home. In this example, consider that the point-to-point messages associated with each request have a size smaller than a threshold segment size and a medium priority. In this scenario, MSGin5G client 1 aggregates the multiple point-to-point message requests received from the air controller into a single point-to-point message request based on a scheduling policy and sends the single point-to-point message to MSGin5G server 106. MSGin5G server 106 transmits the single point-to-point message request to UE 2. UE 2's 5GSMS client 2 splits the received single group message request into multiple individual group message requests for further processing.

[0172] Figure 11A is an example sequence diagram depicting the aggregation of point-to-application messages from one or more application clients in an initiating UE 102a and the transmission of the aggregated point-to-application messages from the initiating UE 102a to the application server 104 according to embodiments disclosed herein.

[0173] In step 1, the application client 1 of the first UE / UE 1 (initiating UE 102a) initiates a first message request for transmitting a message to the target device. In this example, as depicted in FIG11A, the first message request may be a first point-to-application message request including a point-to-application message, and the target device is application server 104.

[0174] At step 2, UE 1's MSGin5G client 1 determines whether the first point-to-application message request can be aggregated. To determine whether the first point-to-application message request can be aggregated, MSGin5G client 1 checks the size and / or priority of the point-to-application messages associated with the first point-to-application message request. MSGin5G client 1 uses the IE of the first point-to-application message request to check the size and / or priority of the point-to-application messages. The IE of a single point-to-application message request is depicted in the example table of Figure 11B. If the size of the point-to-application message is less than the threshold segment size and the priority of the point-to-application message is low or medium priority, then MSGin5G client 1 determines that the corresponding first point-to-application message request can be aggregated. In addition, steps 1 and 2 can be performed multiple times to initiate multiple subsequent point-to-application messages and determine whether each of the multiple subsequent point-to-application message requests can be aggregated. Steps 1 and 2 can be performed multiple times until the timer expires or until the optimal use of the segment size is reached. When the timer expires or until the optimal segment size is reached, MSGin5G client 1 aggregates multiple point-to-application message requests (including the first point-to-application message request and subsequent point-to-application message requests to be aggregated) into a single message request / single point-to-application message request. The IE of the single point-to-application message request is depicted in the example table in Figure 11C. The size / length of the single point-to-application message request is less than or equal to the threshold segment size that has already allowed the transmission of single point-to-application message requests.

[0175] In step 3, MSGin5G client 1 sends a single point-to-application message request to MSGin5G server 106, which is already directed to application server 104.

[0176] In step 4, the MSGin5G server 106 verifies the MSGin5G client 1 of UE 1 to check whether the MSGin5G client 1 is authenticated and authorized to transmit a single point-to-point message request to UE 2. If the MSGin5G client 1 is authenticated and authorized, the MSGin5G server 106 skips step 5.

[0177] If MSGin5G client 1 is not authenticated and authorized, or the single point-to-application message request is invalid, then MSGin5G server 106 executes step 5. In step 5, MSGin5G server 106 transmits a message rejection / aggregated message rejection with a rejection reason to UE 1's MSGin5G client 1. The message rejection IE is depicted in the example table of Figure 11D.

[0178] If MSGin5G client 1 is authenticated and authorized to send a single point-to-point message to application server 104, then in step 6, MSGin5G server 106 splits the received single point-to-application message request into multiple individual point-to-application message requests and transmits the multiple individual point-to-application message requests to application server 104.

[0179] At step 7A, if the MSGin5G server 106 made a request in the point-to-application message request, the application server 104 initiates the sending of a delivery report to the MSGin5G server 106. At step 7B, the MSGin5G server 106 communicates the delivery report received from the application server 104 to the MSGin5G client 1 of UE 1. At step 7C, the MSGin5G client 1 forwards the received delivery report to one or more application clients 302 of UE 1.

[0180] Consider an example scenario where a speedometer deployed on a road (example of UE 1) initiates multiple point-to-application (PTA) message requests simultaneously or one PTA message request at a time, which are already addressed to a traffic controller (example of application server 104). The multiple PTA message requests include PTA messages indicating vehicle speed. Each PTA message associated with the aggregated multiple PTA message requests can have a size smaller than a threshold segment size and a lower priority. In this scenario, the speedometer aggregates the initiated multiple PTA message requests into a single PTA message request based on a scheduling policy. The speedometer transmits the single PTA message request, which is already addressed to the traffic controller, to the MSGin5G server 106. The MSGin5G server 106 splits the single PTA message request into multiple individual PTA message requests and forwards these individual PTA message requests to the traffic controller. The traffic controller can use these multiple individual PTA message requests to impose fines on users who have exceeded the permitted speed limit.

[0181] Figure 12A is an example sequence diagram depicting the aggregation of application-to-point messages from one or more application servers and the transmission of application-to-point messages from the application servers to the target UE (102a to 102n) according to embodiments disclosed herein.

[0182] At step 1, the MSGin5G server 106 receives a first message request from the application server 104 to transmit a message for the target device. In this example, as depicted in FIG12A, the message request may be an application-to-point message request that includes an application-to-point message, and the target device includes a UE (e.g., UE 102a / UE 1).

[0183] The example sequence diagram depicted in Figure 12A can also be applied to transmitting group messages from a first UE 102a / UE 1 to a target group of UEs or a set of UEs. In this scenario, in the example, the message request / first message request can be a point-to-point message request. The MSGin5G server 106 receives the first message request from the first UE 102a / UE 1 to transmit a message for a target device. In another example, the message request / first message request can be a group message request. The MSGin5G server 106 receives the first message request from the first UE 102a / UE 1 to transmit a message to a target group of UEs or a set of UEs.

[0184] At step 2, the MSGin5G server 106 determines whether the first application-to-the-point message request can be aggregated. To determine whether the first application-to-the-point message request can be aggregated, the MSGin5G server 106 checks the size and / or priority of the application-to-the-point message associated with the first application-to-the-point message request. The MSGin5G server 106 uses the IE of the application-to-the-point message to check the size and / or priority of the application-to-the-point message. The IE of a single application-to-the-point message request is depicted in the example table in Figure 12B. If the size of the application-to-the-point message is less than the threshold segment size and the priority of the application-to-the-point message is low or medium priority, the MSGin5G server 106 determines that the corresponding first application-to-the-point message request can be aggregated. In addition, steps 1 and 2 can be performed multiple times so that the application server 104 receives multiple subsequent application-to-the-point message requests and determines whether each of the multiple subsequent group message requests can be aggregated. Steps 1 and 2 can be performed multiple times until the timer expires or until the optimal use of the segment size is reached. When the timer expires or the optimal usage for the segment size is reached, the MSGin5G server 106 aggregates multiple application-to-point message requests (including the first application-to-point message request and subsequent application-to-point message requests determined to be aggregated) into a single message request / single application-to-point message request. The IE of a single application-to-point message request is depicted in the example table in Figure 12C.

[0185] In step 3, the MSGin5G server 106 transmits an application point-to-point message request to the MSGin5G client 1 of UE 1. In step 4, the MSGin5G server 1 splits the received single application point-to-point message request into multiple individual point-to-point message requests and transmits the multiple individual point-to-point message requests to the application server 104.

[0186] Consider an example scenario where a traffic controller (example application server 104) transmits application-to-the-point message requests simultaneously or one at a time to an MSGin5G server 106. These requests are already directed to cameras (example UE 2) deployed to monitor traffic on the road. Application-to-the-point message requests may include messages indicating the camera's location / configuration, notifications of traffic rule violations monitored by the camera, etc. In this example, consider application-to-the-point messages associated with each request to have a size smaller than a threshold segment size and a medium priority. In this scenario, the MSGin5G server 106 aggregates the application-to-the-point message requests received from the traffic controller into a single application-to-the-point message request based on a scheduling policy. The MSGin5G server 106 transmits the single application-to-the-point message request to the camera. The camera's 5GSMS client 2 splits the received single group message request into multiple individual group message requests for further processing.

[0187] Figure 13A is an example sequence diagram illustrating an end-to-end process for aggregating point-to-point messages from one or more application clients in an initiating UE 102a and transmitting the aggregated point-to-point messages from the initiating UE 102a to a target UE 102b, according to embodiments disclosed herein.

[0188] As depicted in Figure 13A, the MSGin5G client 1 of UE 1 (initiating UE 102a) aggregates multiple point-to-point messages into a single message request and transmits the single message request to the MSGin5G server 106. The single message request can be directed to the target UE / UE 2. Steps 1 to 3 corresponding to Figure 9A depict the aggregation of multiple point-to-point messages into a single message request and the transmission of the single message request to the MSGin5G server 106; therefore, for brevity, their detailed description is omitted. Furthermore, the IE for a single point-to-point message request initiated at UE 1 is depicted in the example table of Figure 13B. The IE for a single point-to-point message request aggregated at UE 1 for the target UE 2 is depicted in the example table of Figure 13C.

[0189] Upon receiving a single message request from UE 1, MSGin5G server 106 checks whether UE 1 is authenticated and authorized to transmit the single message request, as depicted in step 4. If UE 1 is not authenticated and authorized to transmit the single message request, MSGin5G server 106 sends a message rejection / aggregation message rejection with a rejection reason to UE 1's MSGin5G client 1, as depicted in step 5. Steps 4 and 5 correspond to steps 4 and 5 of Figure 9A, and therefore, for brevity, their repeated detailed descriptions are omitted. Additionally, the IE of the rejection message received by UE 1 in response to the transmitted single point-to-point message request is depicted in Figure 13D.

[0190] If UE 1 is authenticated and authorized to transmit a single message request, then MSGin5G server 106 transmits a single message request to UE 2. In the corresponding... Figure 10 Steps 1 to 5 and steps 6 to 8 describe the transmission of a single message request from the MSGin5G server 106 to the UE 2, so for the sake of brevity, their repeated detailed descriptions are omitted.

[0191] In an embodiment, the example sequence diagram depicted in FIG13A can also be applied to point-to-application messages from multiple application clients in the first UE102a / UE1 to transmit messages for application server 104.

[0192] This document provides methods and systems for achieving the following objectives:

[0193] Enables IoT devices / MIoT devices to aggregate multiple messages into a single IoT message and forward the single IoT message to a group of UEs or application servers;

[0194] This enables the message server to aggregate multiple messages from different IoT / MIoT devices in the same group into a single IoT message and forward the single IoT message to members of that group; and

[0195] This enables message servers to aggregate multiple messages targeting the same IoT device, encoding multiple small IoT messages into a single IoT message that contains multiple messages.

[0196] The embodiments described herein aggregate multiple messages with small amounts of data into a single message based on the maximum segment size allowed to be transmitted to the target device via available transmission.

[0197] The embodiments described herein enable the following to be achieved:

[0198] Enables the MSGin5G client to aggregate group messages to the target group;

[0199] Enables the MSGin5G server to aggregate group messages to the target UE;

[0200] Enables the MSGin5G server to aggregate group messages to the target group;

[0201] This enables MSGin5G clients to aggregate messages to another target in point-to-point messaging;

[0202] Enables the MSGin5G server to deliver aggregated message requests to the target UE;

[0203] This enables the MSGin5G client to aggregate messages to the application in point-to-application messaging; and

[0204] This enables the MSGin5G server to aggregate application-to-the-point messages to the target UE.

[0205] The embodiments described in this article exchange messages in an IoT communication system by making full use of network resources.

[0206] In this embodiment, the IoT device is not required to send a message every time an event is sensed, thereby saving power, and the IoT device is not required to receive a single message every time it is woken up.

[0207] In this embodiment, the message server can aggregate multiple messages to the target device and send messages only when the required number of messages are available, thereby saving communication power and network bandwidth.

[0208] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control elements. Figure 1 , Figure 2 , Figure 3 and Figure 4 The element shown can be at least one of a hardware device or a combination of a hardware device and a software module.

[0209] The embodiments disclosed herein describe methods and systems for exchanging messages in an IoT communication system. Therefore, it should be understood that the scope of protection is extended to such programs, and in addition to the computer-readable component containing the messages therein, such computer-readable storage component contains program code components for implementing one or more steps of the method when the program is run on a server or mobile device or any suitable programmable device. In preferred embodiments, the method is implemented by a software program written in, for example, a Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL), another programming language, or by one or more VHDL or software modules executed on at least one hardware device. The hardware device can be any type of portable device that can be programmed. The device may also include components that are, for example, hardware components such as an ASIC, or a combination of hardware and software components, such as an ASIC and an FPGA, or at least one microprocessor and at least one memory having software modules disposed therein. The method embodiments described herein may be implemented partly in hardware and partly in software. Alternatively, this disclosure may be implemented on different hardware devices, for example, using multiple CPUs.

[0210] The foregoing description of specific embodiments will fully reveal the general nature of the embodiments herein, enabling others to readily modify and / or adapt such specific embodiments for various applications by applying existing knowledge without departing from the general concept, and therefore, such adaptations and modifications should and are intended to be understood within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although embodiments herein have been described with reference to examples, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the embodiments described herein.

[0211] Although this disclosure has been described with reference to various embodiments, various changes and modifications may be suggested to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method for exchanging messages in an Internet of Things (IoT) communication system, performed by a user equipment (UE) including a first entity and a second entity, the method comprising: The second entity receives a message request from at least one first entity to send a message to the target device, wherein the at least one first entity is an application client and the second entity is a fifth-generation messaging client (MSGin5G). The second entity identifies the size of the message associated with the message request; When the size of the message associated with the message request is less than the threshold segment size, the second entity determines whether to aggregate the message request. The message requests are aggregated by the second entity until the optimal segment size is reached; and The second entity sends an aggregated message request to the target device in the IoT communication system.

2. The method according to claim 1, wherein, The aggregated message request includes the MSGin5G client identifier ID, the message ID of the aggregated message request, the number of individual messages indicating the total number of aggregated messages, and a list of individual messages, wherein each of the individual messages contains an information element.

3. The method according to claim 1, further comprising: The second entity identifies the priority of the message associated with the message request.

4. The method according to claim 1, in, The aggregated message request also includes the destination MSGin5G client ID.

5. The method according to claim 3, further comprising: When the priority of the message associated with the message request is not high, determine whether to aggregate the message request.

6. The method according to claim 1, further comprising: The second entity receives an aggregated message response from the target device, including information related to rejection.

7. The method according to claim 6, further comprising: If the UE is not authorized to send the aggregated message request to the target UE or the aggregated message request is invalid, the second entity receives an aggregated message response from the target device, which includes information related to rejection.

8. The method according to claim 1, wherein, The message request includes a unique message identifier ID that indicates a separate message and the message payload.

9. The method according to claim 8, wherein, The message request also includes at least one of the following: an identifier ID of the application to which the payload is targeted, a disposal type indicating the disposal type expected from the target UE, and a priority type indicating the priority requested for the message.

10. The method according to claim 7, wherein, Information related to the rejection includes at least one of the following: the original MSGin5G client ID, the message ID, and the reason for rejection.

11. The method according to claim 1, wherein, The target device is another UE, comprising a first entity and a second entity, used to exchange messages in the IoT communication system.

12. A user equipment (UE) including a first entity and a second entity for exchanging messages in an Internet of Things (IoT) communication system, the UE comprising: transceiver; and The controller, coupled to the transceiver, is configured to: The second entity receives a message request from at least one first entity to send a message to the target device, wherein the at least one first entity is an application client and the second entity is a fifth-generation messaging client (MSGin5G). The second entity identifies the size of the message associated with the message request; When the size of each message associated with the message request is less than the threshold segment size, the second entity determines whether to aggregate the message request. The message requests are aggregated by the second entity until the optimal segment size is reached; and The second entity sends an aggregated message request to the target device in the IoT communication system.

13. The UE according to claim 12, wherein, The aggregated message request includes the MSGin5G client identifier ID, the message ID of the aggregated message request, the number of individual messages indicating the total number of aggregated messages, and a list of individual messages, wherein each of the individual messages contains an information element.

14. The UE according to claim 12, wherein, The controller is also configured to allow the second entity to identify the priority of messages associated with the message request.

15. The UE according to claim 12, in, The aggregated message request also includes the destination MSGin5G client ID.

16. The UE according to claim 14, wherein, The controller is also configured to: When the priority of the message associated with the message request is not high, determine whether to aggregate the message request.

17. The UE according to claim 12, wherein, The controller is also configured to: The second entity receives an aggregated message response from the target device, including information related to rejection.

18. The UE according to claim 17, wherein, The controller is also configured to: If the UE is not authorized to send the aggregated message request to the target UE or the aggregated message request is invalid, the second entity receives an aggregated message response from the target device, which includes information related to rejection.

19. The UE according to claim 12, wherein, The message request includes a unique message identifier ID that indicates a separate message and the message payload.

20. The UE according to claim 19, wherein, The message request also includes at least one of the following: an identifier ID of the application to which the payload is targeted, a disposal type indicating the disposal type expected from the target UE, and a priority type indicating the priority requested for the message.

21. The UE according to claim 18, wherein, Information related to the rejection includes at least one of the following: the original MSGin5G client ID, the message ID, and the reason for rejection.

22. The UE according to claim 12, wherein, The target device is another UE, comprising a first entity and a second entity, used to exchange messages in the IoT communication system.

Images