CN110679163B - Method and apparatus for transmitting and receiving data in a mission critical data communication system - Google Patents

Abstract

Embodiments herein provide a method for managing Short Data Service (SDS) handling notifications in a mission critical data (MCData) communication system. The method includes identifying, by a receiving MCData User Equipment (UE), an SDS handle request type Information Element (IE) in an SDS message received from a sending MCData UE. Further, the method includes starting, by the receiving MCData UE, a timer when a handling request type Information Element (IE) is set to transfer and read. Further, the method includes sending, by the receiving MCData UE, a merged disposition notification to the sending MCData UE by stopping the timer when reading the SDS message before the timer expires.

Description

Method and apparatus for transmitting and receiving data in a mission critical data communication system

Technical Field

The present disclosure relates to mission critical data (MCData) communication systems, and more particularly, to methods and systems for managing Short Data Service (SDS) handling (displacement) notifications in MCData communication systems. This application is based on and claims priority from indian application No. 201741010591 filed on 25/3/2017, the disclosure of which is incorporated herein by reference.

Background

Public safety networks are used for Mission Critical (MC) data/voice/video communication. MC communications may include a defined MCData service set. Such MCData services are typically built on existing third generation partnership project (3GPP) transport communication mechanisms provided by the Evolved Packet System (EPS) architecture to establish, maintain and terminate the actual communication paths between users. Generally, an MCData server provides centralized support for such MCData services. The MCData server may also facilitate or manage MCData communications between various user portions of the network.

In a standby deployment, such MCData services may be off-network. In such a deployment, the MCData devices communicate directly with each other without the need for a server to centrally support the service.

The MCData service is intended to provide one-to-one, one-to-many, and group communications between users. In the present case, public safety communities require services beyond voice, i.e. data and video applications. MCData often uses a set of functions and enablers (enabler) that allow many end-user services to be built on a common platform. The Short Data Service (SDS) feature is a function used in the MCData service. The SDS may be used alone or in combination with other services, or may be used by other services to implement certain features, such as shared location, presence-like (presence-like) data and command instructions to perform particular operations. SDS functions may include one-to-one messaging (messaging) or one-to-many or group messaging. Furthermore, the SDS message may be a separate SDS message or may be part of an SDS session.

The above information is provided merely as background information to assist the reader in understanding the present invention. The applicant has not made any determination nor has it asserted that any of the above applies to the prior art of the present application.

Disclosure of Invention

Technical problem

Efficient systems and methods are necessary to support various features of the SDS for reducing the number of retransmissions of the handling notification and optimizing resource consumption for handling requests and notifications.

Technical solution

A primary object of embodiments herein is to provide a method and system for managing Short Data Service (SDS) handling notifications in a mission critical data (MCData) communication system.

It is another object of embodiments herein to provide a method for merging a "delivered" notification and a "read" notification at a receiving MCData UE into a single "delivered and read" notification upon receiving an SDS message.

Another object of embodiments herein is to start a timer at a receiving MCData UE when a handle request type Information Element (IE) in an SDS message is set to "deliver and read".

It is another object of embodiments herein to send a consolidated treatment notification to a sending MCData UE by stopping a timer when reading an SDS message before the timer expires.

It is another object of embodiments herein to provide a method for merging handling notifications in a network (on-network) MCData communication system for SDS.

It is a further object of embodiments herein to provide a method for consolidated handling of notifications in an off-network (MCData) communication system for SDS.

Advantageous effects

By the method of the present application, various features of the SDS are supported for reducing the number of retransmissions used to handle notifications and optimizing resource consumption for handling requests and notifications.

Drawings

The present invention is illustrated in the accompanying drawings in which like reference numerals refer to corresponding parts throughout the various views. The embodiments herein will be better understood from the following description with reference to the accompanying drawings, in which:

fig. 1A illustrates an exemplary on-network MCData communication system in which a receiving MCData UE sends a merged disposition notification to a sending MCData UE, according to embodiments disclosed herein;

fig. 1B illustrates an exemplary on-network MCData communication system in which multiple receiving MCData UEs each send a merged disposition notification to a sending MCData UE, according to embodiments disclosed herein;

fig. 2 is an exemplary off-network MCData communication system in which a receiving MCData UE sends a merged treatment notification to a sending MCData UE, according to embodiments disclosed herein;

fig. 3 is an exemplary off-network MCData communication system in which multiple receiving MCData UEs each send a merged disposition notification to a sending MCData UE, according to embodiments disclosed herein;

fig. 4 is a block diagram illustrating various hardware components of a receiving MCData UE according to embodiments disclosed herein; and

fig. 5 is a flow diagram illustrating a method for managing handling of notifications when a handling request type Information Element (IE) is set to pass and read in a Short Data Service (SDS) message in accordance with embodiments disclosed herein; and

fig. 6 is a flow diagram illustrating a method for managing handling of notifications based on a handling request type IE set in an SDS message in accordance with embodiments disclosed herein; and

fig. 7 is a block diagram illustrating an MCData UE according to embodiments disclosed herein.

Best mode for carrying out the invention

Accordingly, embodiments herein provide a method for managing Short Data Service (SDS) handling notifications in a mission critical data (MCData) communication system. The method includes identifying, by a receiving MCData User Equipment (UE), an SDS handle request type Information Element (IE) in an SDS message received from a sending MCData UE. Further, the method comprises: when the handling request type IE is set to transfer and read, a timer is started by the receiving MCData UE. Further, the method comprises: when the SDS message is read before the timer expires, a consolidated disposition notification is sent by the receiving MCData UE to the sending MCData UE by stopping the timer.

Accordingly, embodiments herein provide a receiving MCData UE for managing SDS handling notifications in an MCData communication system. The MCData UE comprises: a handling notification engine configured to identify an SDS handling request type IE in an SDS message received from a transmitting MCData UE. Further, the disposition notification engine is configured to start a timer when the disposition request type IE is set to transfer and read. Further, the disposition notification engine is configured to send the merged disposition notification to the sending MCData UE by stopping the timer when reading the SDS message before the timer expires.

These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating preferred embodiments and numerous specific details thereof, is given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

Detailed Description

Various embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. In the following description, only specific details such as detailed configurations and components are provided to assist in a comprehensive understanding of the embodiments of the disclosure. Thus, it will be apparent to those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the disclosure. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments. As used herein, the term "or" as used herein, unless otherwise specified, is intended to be non-exclusive. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, these examples should not be construed as limiting the scope of the examples herein.

Embodiments may be described and illustrated with respect to blocks performing one or more of the described functions, as is conventional in the art. These blocks (which may be referred to herein as managers, units or modules, etc.) are physically implemented by analog and/or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc., and may optionally be driven by firmware and software. For example, the circuitry may be embodied in one or more semiconductor chips, or on a substrate support such as a printed circuit board or the like. The circuitry making up the blocks may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware for performing some of the functions of the blocks and a processor for performing other functions of the blocks. Each block of an embodiment may be physically separated into two or more interactive and discrete blocks without departing from the scope of the present disclosure. Likewise, the blocks of an embodiment may be physically combined into more complex blocks without departing from the scope of the present disclosure.

The terms "transmit" and "receive" herein are used for labeling purposes only and may be used interchangeably without departing from the scope of the embodiments. It should be noted that the embodiments in the present disclosure are applicable to both on-network MCData communication systems and off-network MCData communication systems, and are also applicable to one-to-one communication and group communication of short data services.

The terms "read" and "render" are used interchangeably in this specification and denote that the MCData client has displayed or processed the received SDS message for use by the user. In an embodiment, the received SDS message is processed by the MCData UE for use by the user. Once the MCData UE displays the SDS message, it instructs the MCData client with the display indication to send the appropriate treatment notification.

Embodiments herein implement a method for managing off-network short data services and/or handling notifications in network short data services. The method includes identifying, by a receiving MCData User Equipment (UE), an SDS handle request type Information Element (IE) in an SDS message received from a sending MCData UE. Further, the method comprises: when the handling request type Information Element (IE) is set to transfer and read, a timer is started by the receiving MCData UE. Further, the method comprises: when the SDS message is read before the timer expires, a consolidated disposition notification is sent by the receiving MCData UE to the sending MCData UE by stopping the timer.

In one embodiment, the merged handling notification includes a "delivery" notification and a "read" notification to the sending MCData UE.

In one embodiment, the receiving MCData UE sends a "delivered" notification to the sending MCData UE when the SDS message is not read before the timer expires.

In one embodiment, when reading the SDS message after the timer expires, the receiving MCData UE sends a "read" notification to the sending MCData UE.

In one embodiment, a time interval associated with a timer for sending the merged treatment notification is configurable.

In one embodiment, the merged disposition notification is sent by stopping the timer when the SDS message is read prior to expiration of the timer during at least one of the one-to-one communication and the group communication with the sending MCData UE.

In one embodiment, the merged disposition notification is sent by stopping a timer in at least one of the on-net MCData communication system and the off-net MCData communication system.

In one embodiment, the received SDS message (either a one-to-one SDS message or a group SDS message) may be one of the individual SDS messages or an SDS message portion of an SDS session.

With MCData SDS, MCData User Equipment (UE) can send short data messages to other MCData users on-and off-network. In addition, the SDS also allows for handling notification requests, i.e., "transfer," read, "" transfer, and read. The sending MCData UE may request the receiving MCData UE to send a treatment notification for "deliver", "read", and both "deliver and read". The delivery notification is an indication that the receiving MCData client has received the SDS message. The read notification refers to an indication that the SDS message is presented to the user by the receiving MCData UE.

In existing systems, a receiving MCData UE sends two separate and independent handling notifications (i.e., a delivery notification when receiving an SDS message and a read notification when presenting an SDS message to a user). In off-network MC communications, transmission bandwidth is limited and most important. As the number of transmissions increases, resources are consumed, which reduces the overall performance of the system.

Meanwhile, the proposed exemplary embodiments allow the receiving MCData UE to merge the "delivered" notification and the "read" notification into a single "delivered and read" notification upon receiving the SDS message. This integration helps reduce the amount of disposition notification traffic by up to 50%, thereby reducing resource consumption in both the on-net MCData communication system and the off-net MCData communication system.

The proposed exemplary embodiment of sending a merged treatment notification can be used with any messaging service and is not limited to MCData. Furthermore, the proposed exemplary embodiments may be used to provide a set of procedures (procedure), associated timers and counters for the transmitting MCData UE and the receiving MCData UE to successfully transmit, receive and acknowledge the successful receipt of the SDS message.

Referring now to the drawings, and more particularly to fig. 1-6, wherein like reference numerals designate corresponding features throughout the several views, there is shown a preferred embodiment.

Fig. 1A illustrates an exemplary on-network MCData communication system in which a receiving MCData UE sends a merged disposition notification to a sending MCData UE, according to embodiments disclosed herein.

Before describing the embodiments in detail, the MCData communication system is briefly described here. In general, as shown in figures 1A-1B, MCData communication system 100 includes a sending MCData UE102a, a set of receiving MCData UEs 102B-102n, and an MCData server 104 in network 106. MCData server 104 acts as a central server to enable network 106 to provide MCData services to MCData UEs 102a-102 n.

In some examples, network 106 includes a 3GPP E-UTRAN access element (not shown) and a 3GPP E-UTRAN core element (not shown). For example, the transmitting MCData UE102a gains access to the network 106 through an LTE-Uu interface (not shown) or through an evolved node B (eNB, not shown). Further, the MCData server 104 may be coupled to various access/core elements of the network 106. For example, the MCData server 104 may be coupled to the serving gateway/packet data gateway through one or more suitable interface reference points. Various core elements, such as a Mobility Management Entity (MME) and a multimedia broadcast/multicast service gateway (MBMS GW), may provide core 3GPP E-UTRAN services to MCData server 104 and/or MCData UEs 102a-102n to facilitate MCData communication services over network 106.

In one embodiment, the MCData UEs 102a-102n can be used, for example, in electronic devices, User Equipments (UEs), and so on. Each of MCData UEs 102a-102n may include an MCData client (i.e., application) for communicating with MCData server 104. The first MCData UE102a includes a first MCData client; the second MCData UE102b includes a second MCData client, and so on.

The MCData client residing in each of MCData UEs 102a-102n acts as a user agent for all MCData application transactions. The MCData client supports SDS, file distribution, data streaming, and IP connectivity MCData functions used by MCData services such as session management, robot control, enhanced state, database queries, and secure internet.

The MCData server 104 provides centralized support for the MCData service suite. The use of SDS, file distribution, data flow, and Internet Protocol (IP) connected MCData communication functions enables session management, robotics, enhanced status, database queries, and secure internet MCData services that require one-to-one data or group communication. All MCData clients supporting users belonging to a single group need to use the same MCData server 104 for that group. In one embodiment, HTTP is used as a communication transfer means for MCData communication.

Referring now to fig. 1A, MCData communication system 100 includes a sending MCData UE102a, an MCData server 104 in network 106, and a receiving MCData UE102 b. The MCData server 104 facilitates/provides one-to-one SDS communication between the first MCData UE102a and the second MCData UE102b over the network 106.

The sending MCData UE102a sends a one-to-one SDS message to the MCData server 104 in the network 106. The one-to-one SDS message includes an SDS handle request type Information Element (IE) set to "deliver and read". The MCData server 104 receives the one-to-one SDS message from the sending MCData UE102a and sends the one-to-one SDS message to the receiving MCData UE102 b. After receiving the one-to-one SDS message, the receiving MCData UE identifies an SDS handle request type IE that is set to "transfer and read" in the one-to-one SDS message.

In addition, receiving MCData UE102b starts a timer (i.e., TDU1 timer associated with on-network data communication system 100). Before the timer expires, when the timer runs and a one-to-one SDS message is read by the MCData client at receiving MCData UE102b, receiving MCData UE102b stops running the timer and sends a consolidated disposition notification including a "deliver and read" notification to sending MCData UE102 a. The time interval or value of the TDU1 timer used to send the merged treatment notification to the sending MCData UE102b is configurable.

In one embodiment, the receiving MCData UE102b sends a "delivered" notification to the sending MCData UE102a when the one-to-one SDS message is not read before the timer expires.

In another embodiment, when reading the one-to-one SDS message after the timer expires, the receiving MCData UE102b sends a "read" notification to the sending MCData UE102 a.

Thus, with the proposed exemplary embodiment, in network MCData communication system 100, upon reading a one-to-one SDS message before the timer expires, receiving MCData UE102b starts the TDU1 timer and sends a merged disposition notification to sending MCData UE102a by stopping the timer. This reduces the number of times the delivery notification and the read notification are transmitted to the sending MCData UE102b, respectively.

Fig. 1B illustrates an exemplary on-network MCData communication system 100 in which a plurality of receiving MCData UEs each send a merged disposition notification to a sending MCData UE, according to embodiments disclosed herein.

For group communication, the sending MCData UE102a sends a group SDS message through the MCData server 104 to a plurality of receiving MCData UEs 102b-102 n. The group SDS message includes an SDS handle request type IE set to "deliver and read". Upon receiving the group SDS message, each receiving MCData UE (i.e., 102b-102n) identifies an SDS handle request type IE in the group SDS message that is set to "deliver and read".

Further, after identifying the SDS handle request type Information Element (IE) that is set to "transfer and read," each of the receiving MCData UEs 102b starts a timer (i.e., TDU1 timer). When the timer runs and the MCData client reads the group SDS message at the receiving MCData UE (102b-102n) before the timer expires, each of the receiving MCData UEs (102b-102n) stops running the timer and sends a consolidated disposition notification unit including a "deliver and read" notification individually to the sending MCData UE102 a. The time interval or value of the TDU1 timer used to send the merged treatment notification to the sending MCData UE102b is configurable.

If the group SDS message is not read before the timer (i.e., TDU1 timer) expires, receiving MCData UE102b sends a "delivered" notification to sending MCData UE102 a. In another case, when reading the group SDS message after the timer expires, the receiving MCData UE102b sends a "read" notification to the sending MCData UE102 a.

Fig. 2 is an exemplary off-network MCData communication system 200 in which a receiving MCData UE sends a merged treatment notification to a sending MCData UE, according to embodiments disclosed herein. As shown in fig. 2, the sending MCData UE102a sends (202) a one-to-one SDS message to the receiving MCData UE102 b. The one-to-one SDS message includes an SDS handle request type IE set to "pass and read". After receiving the one-to-one SDS message, the receiving MCData UE102b identifies an SDS handle request type IE in the one-to-one SDS message set to "transfer and read".

In addition, receiving MCData UE102b starts (204) a timer (i.e., TFS3 timer, which is associated with off-network data communication system 200). When the timer runs and a one-to-one SDS message is read (206) by the MCData client at the receiving MCData UE102b (i.e., before the timer expires), the receiving MCData UE102b stops the timer and sends (208) a consolidated disposition notification including a "deliver and read" notification to the sending MCData UE102 a. The time interval or value of the TFS3 timer used to send the merged treatment notification to the sending MCData UE102b is configurable.

Although not shown in fig. 2, when the one-to-one SDS message is not read before the timer expires, the receiving MCData UE102b sends "delivered" to the MCData UE102 a. In one embodiment, when reading the one-to-one SDS message after the timer expires, the receiving MCData UE102b sends a "read" notification to the sending MCData UE102 a.

Thus, with the proposed exemplary embodiment, in the off-network MCData communication system 200, the receiving MCData UE102b starts the TFS3 timer and sends a merged disposition notification to the sending MCData UE102a by stopping the timer when reading the SDS message before the timer expires. This reduces the number of times the transmission notification and the read notification are transmitted to the sending MCData UE102b, respectively.

Fig. 3 is an exemplary off-network MCData communication system 200 in which a plurality of receiving MCData UEs each send a merged disposition notification to a sending MCData UE, according to embodiments disclosed herein.

For group communication, the sending MCData UE102a sends (302) a group SDS message to the receiving MCData UE102b and the plurality of receiving MCData UEs 102c-102 n. The group SDS message includes an SDS handle request type IE set to "deliver and read". Upon receiving the group SDS message, each receiving MCData UE (i.e., 102b and 102c-102n) identifies an SDS handle request type IE in the group SDS message that is set to "deliver and read".

Further, after identifying the SDS handle request type IE, which is set to "transfer and read," each of the receiving MCData UEs 102b starts 304 a timer (i.e., TFS3 timer). When the timer runs and the group SDS message is read (306) by the MCData client at the receiving MCData UE (102b) before the timer expires, each of the receiving MCData UEs (102b, 102c-102n) stops running the timer and sends (308) a consolidated disposition notification including the "deliver and read" notification separately to the sending MCData UE102 a. The time interval or value of the TFS3 timer used to send the merged treatment notification to the sending MCData UE102b is configurable.

Although not shown in fig. 3, receiving MCData UEs 102b and 102c-102n send a "delivered" notification to sending MCData UE102a if the group SDS message was not read before the timer (i.e., TFS3 timer) expired. In another case, upon reading the group SDS message after the timer expires, receiving MCData UEs 102b and 102c-102n send a "read" notification to sending MCData UE102 a.

Fig. 4 is a block diagram illustrating various hardware components of a receiving MCData UE102a according to embodiments disclosed herein. The receiving MCData UE includes a communicator 402, an SDS timer 404, a handle notification engine 406, a processor 408, and a memory 410.

In one embodiment, communicator 402 may be configured to receive a one-to-one SDS message from a sending MCData UE102a in the event of one-to-one communication in both the network MCData communication system 100 and the off-network MCData communication system 200.

In another embodiment, the communicator 402 may be configured to receive a group SDS message from the sending MCData UE102a in the event of a group MCData communication in both the mesh MCData communication system 100 and the off-mesh MCData communication system 200.

Further, communicator 402 can be further configured to send a consolidated handling notification message to sending MCData UE102a when an IE in the handling notification is set or enabled as "deliver and read" in a one-to-one SDS message or in a group SDS message sent by sending MCData UE102 a.

The SDS timer 404 includes a TDU1 timer and a TFS3 timer. Receiving MCData UE102b starts timer TDU1 upon receiving an SDS message from transmitting MCData UE102a in network MCData communication system 100. Receiving MCData UE102b starts timer TFS3 upon receiving an SDS message from transmitting MCData UE102a in off-network MCData communication system 200.

The time intervals associated with the timers TDU1 and TFS3 are configurable.

Handle notification engine 406 is configured to send the merged handle notification to sending MCData UE102a when the handle request type IE in the one-to-one request message or the group request message received from sending MCData UE102a is set to "deliver and read".

In one embodiment, the disposition notification engine 406 is configured to stop running the timer and send the merged disposition notification to the sending MCData UE102a when reading the SDS message before the timer (i.e., timer TDU1 in the network MCData communication system 100 or timer TFS3 in the off-network communication system 200) expires. .

In various embodiments, the disposition notification engine 406 is configured to send a "delivered" notification to the sending MCData UE when the SDS message is not read before the expiration of a timer (i.e., timer TDU1 in the network MCData communication system 100 or timer TFS3 in the off-network communication system 200).

In another embodiment, the disposition notification engine 406 is configured to send a "read" notification to the sending MCData UE102a when the SDS message is read after the timer expires.

In one embodiment, processor 408 (e.g., a hardware unit, a device, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), etc.) is communicatively coupled to memory 410 (e.g., volatile memory and/or non-volatile memory); the memory 410 includes storage locations configured to be addressable by the processor 408.

In one embodiment, memory 410 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or forms of electrically programmable memories (EPROM) or Electrically Erasable and Programmable (EEPROM) memories. Additionally, in some examples, memory 410 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 propagated signal. However, the term "non-transitory" should not be construed as meaning that the memory 408 is not removable. In some examples, memory 410 may be configured to store larger amounts of information than memory. In some examples, a non-transitory storage medium may store data that varies over time (e.g., in Random Access Memory (RAM) or cache).

Fig. 5 is a flow diagram 500 illustrating a method for managing handling of notifications when a processing request type Information Element (IE) is set to "deliver and read" in a Short Data Service (SDS) message in accordance with an embodiment disclosed herein. The various steps of flowchart 500 are performed by disposition notification engine 406.

In step 502, the method includes identifying an SDS handle request type IE from an SDS message received by the sending MCData UE102 a.

At step 504, the method includes starting a timer (i.e., a TDU1 timer for the on-network MCData communication system 100 or a TFS3 timer for the off-network MCData communication system 200) when the handle request type IE is set to "transfer and read".

At step 506, the method includes sending the merged disposition notification to the sending MCData UE102a by stopping the timer when reading the SDS message before the timer expires.

Fig. 6 is a flow diagram 600 illustrating a method for managing handling of notifications based on a handling request type Information Element (IE) set in an SDS message in accordance with embodiments disclosed herein. The various steps of flowchart 600 are performed by disposition notification engine 406.

In step 602, the method includes receiving an SDS message from the sending MCData UE102 a. At step 604, the method includes determining a handle request type IE in the received SDS message.

In one embodiment, if it is determined at step 604 that the handling request type IE in the SDS message is set to "delivery only," then at step 606 the method includes sending the delivered notification to the sending MCData UE102a and the method terminates after sending the delivered notification.

In one embodiment, if, at step 604, it is determined that the handle request type IE is set to "read only," then, at step 608, the method includes determining whether the SDS message was read. Further, at step 610, the method includes sending a read notification to the sending MCData UE102a, and the method terminates in response to determining that the SDS message was read.

Further, in one embodiment, if it is determined at step 604 that the handling request type IE is set to "transfer and read", then at step 612, the method includes starting a timer (i.e., timer TDU1 in the mesh MCData communication system 100 or timer TFS3 in the off-network communication system 200) for sending the merged handling notification (including the transfer and read notifications). At step 614, the method includes determining whether the SDS message was read before the timer started in step 612 expired. In one embodiment, at step 614, if it is determined that the SDS message was read before the timer expired, then at step 616, the method includes sending a consolidated disposition notification for the SDS message (with delivery and read notifications) to the sending MCData UE102a by stopping the timer started in step 612, and the method terminates after sending the consolidated disposition notification.

In another embodiment, if it is determined at step 614 that the message was not read before the timer expired, the method includes sending a notification of the delivery to the sending MCData UE102a at step 618. Further, after sending the delivered notification to the sending MCData UE102a, at step 618, the method includes determining whether the SDS message was read as in step 608. Further, at step 610, the method includes sending a read notification to the sending MCData UE102b, and the method terminates in response to determining that the SDS message was read.

Unlike conventional mechanisms, the proposed exemplary embodiments can be used to merge "delivered" notifications and "read" notifications at a client into a single "delivered and read" notification when a short data service message is received. This consolidation helps reduce the amount of disposition notification traffic by up to 50%, which results in less resource consumption in both the mesh MCData communication system 100 and the off-mesh MCData communication system 200.

Fig. 7 is a block diagram illustrating an MCData UE according to an embodiment disclosed herein.

Referring to fig. 7, the MCData UE 700 may include a processor 710, a transceiver 720, and a memory 730. However, all of the illustrated components are not required. The MCData UE 700 may be implemented with more or fewer components than those shown in fig. 7. Further, according to another embodiment, processor 710 and transceiver 720 and memory 730 may be implemented as a single chip.

The above-described components will now be described in detail.

Processor 710 may include one or more processors or other processing devices that control the proposed functions, processes, and/or methods. The operation of transmitting the MCData UE or receiving the MCData UE may be implemented by the processor 710. The terms "transmit" and "receive" herein are used for labeling purposes only and may be used interchangeably without departing from the scope of the embodiments.

The processor 710 may identify an SDS handle request type Information Element (IE) in an SDS message received from the sending MCData UE. Processor 710 may start a timer when a handle request type Information Element (IE) is set to transfer and read. The processor 710 may send the merged disposition notification to the transmitting MCData UE through the transceiver 720 by stopping the timer when reading the SDS message before the timer expires.

The transceiver 720 may include an RF transmitter for up-converting and amplifying a transmission signal and an RF receiver for down-converting the frequency of a reception signal. However, according to another embodiment, the transceiver 720 may be implemented with more or fewer components than shown in the components.

The transceiver 720 may be connected to the processor 710 and transmit and/or receive signals. The signal may include control information and data. In addition, the transceiver 720 may receive a signal through a wireless channel and output the signal to the processor 710. The transceiver 720 may transmit a signal output from the processor 710 through a wireless channel.

The memory 730 may store control information or data included in a signal obtained by the MCData UE 700. Memory 730 may be connected to processor 710 and store at least one instruction or protocol or parameter for the proposed function, process, and/or method. Memory 730 may include Read Only Memory (ROM) and/or Random Access Memory (RAM) and/or a hard disk and/or CD-ROM and/or DVD and/or other storage devices.

The embodiments disclosed herein may be implemented by at least one software program running on at least one hardware device and performing network management functions to control these elements. The hardware described herein may be a consolidated notification manager configured for consolidating treatment notifications at a receiving client for any message service.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Thus, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments described herein.

Claims (13)

1. A method for managing short data service, SDS, handling notifications in a mission critical data, MCData, communication system, the method comprising:

identifying, by the receiving MCData user equipment UE, an SDS handle request type information element IE in the SDS message received from the sending MCData UE;

starting, by the receiving MCData UE, a timer when the handling request type information element IE is set to transfer and read; and

sending, by the receiving MCdata UE, a consolidated disposition notification to the sending MCdata UE that includes delivery and read notifications by stopping the timer when the SDS message is read before the timer expires.

2. The method of claim 1, wherein the receiving MCData UE sends a delivered notification to the sending MCData UE when the SDS message is not read before the timer expires.

3. The method of claim 2, wherein the receiving MCData UE sends a read notification to the sending MCData UE when the SDS message is read after the timer expires.

4. The method of claim 1, wherein a time interval associated with the timer for sending the consolidated treatment notification is configurable.

5. The method of claim 1, wherein the consolidated treatment notification is sent by stopping the timer when the SDS message is read prior to expiration of the timer during at least one of a one-to-one communication and a group communication with the sending MCData UE.

6. The method as recited in claim 1, wherein the consolidated disposition notification is sent by stopping the timer in at least one of an on-net MCData communication system and an off-net MCData communication system.

7. A receiving mission critical data, MCData, user equipment, UE, for managing short data service, SDS, handling notifications in an MCData communication system, the MCData UE comprising a handling notification engine configured to:

identifying an SDS handle request type information element, IE, in an SDS message received from a transmitting MCData UE;

starting a timer when the handle request type information element IE is set to transfer and read; and

when reading the SDS message before the timer expires, sending a combined handling notification including delivery and read notifications to the sending MCData UE by stopping the timer.

8. The receiving MCData UE of claim 7 wherein the disposition notification engine is configured to send a delivered notification to the sending MCData UE when the SDS message is not read before the timer expires.

9. The receiving MCData UE of claim 8 wherein the disposition notification engine is configured to send a read notification to the sending MCData UE when the SDS message is read after expiration of the timer.

10. The receiving MCData UE of claim 7 wherein a time interval associated with the timer for sending the consolidated treatment notification is configurable.

11. The receiving MCData UE of claim 7 wherein the disposition notification engine is configured to stop the timer and send the merged disposition notification when the SDS message is read prior to expiration of the timer during at least one of a one-to-one communication and a group communication with the sending MCData UE.

12. The receiving MCData UE of claim 7 wherein the disposition notification engine is configured to stop the timer and to send the consolidated disposition notification in at least one of an on-network MCData communication system and an off-network MCData communication system.

13. A non-transitory computer-readable recording medium storing a program which, when executed by a computer, performs the method of claim 1.

Images