Method and system for processing mission-critical data communication using a pre-established session

Abstract

The present disclosure relates to a communication method and system that integrates IoT technology with a 5G communication system that supports higher data rates beyond 4G systems and is applied to intelligent services based on 5G communication technology and IoT-related technologies. A method for using a pre-established session to initiate mission-critical data (MCData) communication includes an involved MCData server (200) receiving at least one pre-established session setup request from an originating MCData client device (100a), the pre-established session setup request including a pre-established session indication that indicates to the involved MCData server to initiate at least one pre-established session. The method includes the involved MCData server initiating at least one pre-established session with the originating MCData client device based on the pre-established session indication. The method includes the involved MCData server sending at least one MCData communication status message to the originating MCData client device.

Description

Technical Field

[0001] The present invention relates to a method and system for handling mission-critical data communication using a pre-established session. Background Art

[0002] In order to meet the increasing demand for wireless data traffic since the self-deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "ultra 4G networks" or "post-LTE systems". The 5G communication system is considered to be implemented in a higher frequency (mmWave millimeter wave) band (e.g., 60 GHz band) to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimension MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technologies have been discussed in 5G communication systems. In addition, in 5G communication systems, system network improvements based on advanced small cells, cloud radio access network (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multi-point (CoMP), receiver interference cancellation, etc. are underway. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superimposed coding (SWSC) as advanced coding modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as advanced access technologies have been developed.

[0003] The Internet is a human-centered connection network in which people can generate and consume information, and now it is evolving into the Internet of Things (IoT), in which distributed entities such as things can exchange and process information without human intervention. The Internet of Everything (IoE) has emerged by combining IoT technology and big data processing technology through connection to a cloud server. IoT implementation requires technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology", and "security technology", and recently, sensor networks, machine-to-machine (M2M) communication, machine type communication (MTC), etc. have been studied. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination of existing information technology (IT) and various industrial applications, IoT can be applied to a variety of fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine type communication (MTC), and machine-to-machine (M2M) communication can be achieved through beamforming, MIMO, and array antennas. Cloud radio access network (RAN), as an application of the above big data processing technology, can also be regarded as an example of the integration between 5G technology and IoT technology.

[0005] In 3GPP specification TS 24.282, when an MCData client initiates a pre-established session using a participating MCData function, compared with other on-demand session setup requests, the participating MCData function has no way to distinguish the pre-established session setup request.

[0006] In addition, once the pre-established session is set up and the MCData client uses this pre-established session to initiate MCData communication, the MCData client needs to know whether the session setup is successful or failed, and there is no existing system that can share the communication status from the participating MCData function to the MCData client. In addition, once the pre-established session is set up, and if the participating MCData function decides to use it to request any incoming calls, there is no existing system for the participating MCData function to request incoming session setup from the MCData client.

[0007] In addition, once MCData communication is initiated using a pre-established session, the MCData client can terminate the MCData communication (keeping the pre-established session active), and there is no existing system that uses the pre-established session to notify the termination status of the MCData communication. In addition, once MCData communication is initiated using a pre-established session, a remote MCData client can terminate the MCData communication, and there is no existing system to notify the MCData client of the termination request of the MCData communication using this pre-established session.

[0008] Therefore, it is desirable to solve the above disadvantages or other disadvantages or at least provide a useful alternative. Summary of the Invention

[0009] The main objective of the embodiments herein is to provide a method for initiating mission-critical data (MCData) communication using a pre-established session.

[0010] Another objective of the embodiments herein is to receive at least one pre-established session setup request from an originating MCData client device, where the pre-established session setup request includes a pre-established session indication indicating that a participating MCData server initiates at least one pre-established session.

[0011] Another object of the embodiments herein is to receive at least one MCData communication status message from a participating MCData server using at least one pre - established session.

[0012] Accordingly, embodiments herein disclose a method for initiating mission - critical data (MCData) communication using a pre - established session. The method includes a participating MCData server receiving at least one pre - established session setup request from an originating MCData client device. The pre - established session setup request includes a pre - established session indication to the participating MCData server indicating about initiating at least one pre - established session. Further, the method includes: the participating MCData server establishing at least one pre - established session with the originating MCData client device based on the pre - established session indication. Further, the method includes the participating MCData server sending at least one MCData communication status message to the originating MCData client device.

[0013] In one embodiment, the method further includes the participating MCData server receiving an MCData communication reference request message from the originating MCData client device to establish an MCData communication session with a controlling MCData server. Further, the method includes the participating MCData server sending an acknowledgement to the originating MCData client device in response to receiving the MCData communication reference request message. Further, the method includes: the participating MCData server sending an MCData communication invitation request message to the controlling MCData server to establish an MCData communication session with the originating MCData client device. Further, the method includes the participating MCData server receiving one of an MCData communication session establishment success message, an MCData communication session failure message, and an MCData communication session rejection message from the controlling MCData server.

[0014] In an embodiment, the method further includes the participating MCData server performing one of the following operations: in response to receiving a successful MCData communication session establishment message from the control MCData, sending an MCData communication status message to the originating MCData client device server, where the MCData communication status message includes an establishment success indication indicating successful establishment of MCData communication in a pre-established session; in response to receiving an MCData communication session failure message from the control MCData server, sending an MCData communication status message to the originating MCData client device, where the MCData communication status message includes an establishment failure indication indicating that MCData communication was not successfully established in the pre-established session; in response to receiving an MCData communication session rejection message from the control MCData server, sending an MCData communication status message to the originating MCData client device, where the MCData communication status message includes an establishment failure indication indicating that MCData communication was not successfully established in the pre-established session.

[0015] In one embodiment, the method further includes the participating MCData server receiving an acknowledgment message from the originating MCData client device in response to at least one MCData communication status. Additionally, the method includes the participating MCData server maintaining at least one pre-established session with the originating MCData client device.

[0016] In one embodiment, the method further includes the participating MCData server receiving an MCData communication end request message from the originating MCData client device to terminate the MCData communication session towards the control MCData server. Additionally, the method includes the participating MCData server sending an acknowledgment message to the originating MCData client device in response to receiving the MCData communication end request message. Additionally, the method includes the participating MCData server sending an MCData communication end request message to the control MCData server to terminate the MCData communication session with the originating MCData client device. Additionally, the method includes the participating MCData server receiving an MCData communication session termination message from the control MCData server.

[0017] In addition, the method includes: in response to receiving an MCData communication session termination message from a control MCData server, participating in the control MCData server sending an MCData communication status message to an originating MCData client device, the MCData communication status message including a termination indication indicating that the MCData communication has successfully terminated within a predetermined session. In addition, the method includes, in response to receiving the MCData communication status, the participating MCData server receiving an acknowledgement message from the originating MCData client device. In addition, the method includes the participating MCData server maintaining at least one pre-established session with the originating MCData client device.

[0018] In one embodiment, the method further includes the participating MCData server receiving an MCData communication invitation message request from the control MCData server to establish an MCData communication session with the originating MCData client device. In addition, the method includes, in response to receiving the MCData communication invitation message request from the control MCData server, the participating MCData server sending an MCData communication status message to the originating MCData client device, wherein the MCData communication status message includes an establishment request indication indicating that the request will establish MCData communication within a pre-established session. In addition, the method includes, in response to the MCData communication status, the participating MCData server receiving an acknowledgement message from the originating MCData client device. In addition, the method includes, in response to receiving the acknowledgement message, the participating MCData server sending an acknowledgement message to the control MCData server. In addition, the method includes the participating MCData server maintaining at least one pre-established session with the originating MCData client device.

[0019] In one embodiment, the method further includes receiving, by a participating MCData server, an MCData communication end request message from a controlling MCData server to terminate an MCData communication session with the controlling MCData server. Additionally, the method includes sending, by the participating MCData server in response to receiving the MCData communication end request message from the controlling MCData server, an MCData communication status message to an originating MCData client device, wherein the MCData communication status message includes a termination request indication indicating that the request will terminate the MCData communication within a pre-established session. Further, the method includes receiving, by the participating MCData server from the originating MCData client device, an acknowledgement message in response to the MCData communication status. Additionally, the method includes sending, by the participating MCData server in response to receiving the acknowledgement message, an acknowledgement message to the controlling MCData server. Further, the method includes maintaining, by the participating MCData server, at least one pre-established session with the originating MCData client device.

[0020] Accordingly, embodiments herein provide a Mission Critical Data (MCData) server for initiating MCData communication using a pre-established session. The participating MCData server includes a processor, a memory, and a communicator. The processor is configured to receive at least one pre-established session setup request from an originating MCData client device, wherein the pre-established session setup request includes a pre-established session indication indicating to the participating MCData server about initiating at least one pre-established session. Additionally, the processor is configured to initiate at least one pre-established session with the originating MCData client device based on the pre-established session indication. Further, the processor is configured to send at least one MCData communication status message to the originating MCData client device.

[0021] 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. However, it should be understood that the following description, although 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 of the invention, and the embodiments herein include all such modifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The method is illustrated in the drawings, in which throughout the various figures, like reference numerals indicate corresponding parts. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0023] Figure 1A block diagram of a system for initiating mission-critical data (MCData) communication using a pre-established session, according to embodiments disclosed herein;

[0024] Figure 2 A block diagram of a participating MCData server for initiating MCData communication using a pre-established session, according to embodiments disclosed herein;

[0025] Figure 3 A sequence diagram showing a method for setting up a pre-established session within MCData communication, according to embodiments disclosed herein;

[0026] Figure 4 and Figure 5 A sequence diagram showing a method for initiating an outgoing MCData communication using a pre-established session, according to embodiments disclosed herein;

[0027] Figure 6 A sequence diagram showing a method for initiating an incoming MCData communication using a pre-established session, according to embodiments disclosed herein;

[0028] Figure 7 A sequence diagram showing a method for terminating an MCData communication initiated by an originating MCData client device using a pre-established session, according to embodiments disclosed herein; and

[0029] Figure 8 A sequence diagram showing a method for terminating an MCData communication initiated by a control MCData server using a pre-established session, according to embodiments disclosed herein. Detailed Description

[0030] As is conventional in the art, embodiments may be described and illustrated in terms of blocks which perform one or more of the described functions. These blocks may be referred to herein as units or modules, etc., and are physically implemented by analog or digital circuitry 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. The circuitry may be implemented, for example, in one or more semiconductor chips, or on a substrate support such as a printed circuit board. The circuitry constituting a module 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 performing some of the functions of the block and a processor performing other functions of the block. Without departing from the scope of the present invention, each block of an embodiment may be physically divided into two or more interacting and discrete blocks. Similarly, without departing from the scope of the present invention, the blocks of an embodiment may be physically combined into more complex blocks.

[0031] The accompanying drawings are used to help easily understand various technical features, and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. Thus, the present disclosure should be construed as extending to any variations, equivalents, and alternatives other than those specifically set forth in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.

[0032] In the present disclosure, various embodiments are adopted from 3GPP specification TS 24.282. The terms "MCData client", "MCData user" are "originating MCData client device", the term "participating in the MCData function" is "participating in the MCData server", and the term "controlling the MCData function" is "controlling the MCData server".

[0033] Accordingly, embodiments herein disclose a method for initiating mission-critical data (MCData) communication using a pre-established session. The method includes receiving, by a participating MCData server, at least one pre-established session setup request from an originating MCData client device. The pre-established session setup request includes a pre-established session indication indicating to the participating MCData server about initiating at least one pre-established session. Additionally, the method includes: the participating MCData server establishing at least one pre-established session with the originating MCData client device based on the pre-established session indication. Further, the method includes sending, by the participating MCData server, at least one MCData communication status message to the originating MCData client device.

[0034] Now referring to the accompanying drawings, and more particularly to Figures 1 to 8 , a preferred embodiment is shown.

[0035] Figure 1 A block diagram of a system (1000) for initiating MCData communication using a pre-established session, according to an embodiment disclosed herein, is shown. In one embodiment, the system (1000) includes an originating MCData client device (100a), a controlling MCData server (100b), and a participating MCData server (200).

[0036] The participating MCData server (200) receives at least one pre - established session setup request (i.e., INVITE message (invitation message)) from the originating MCData client device (100a). The pre - established session setup request includes a pre - established session indication that indicates to the participating MCData server (200) the initiation of at least one pre - established session. In addition, the participating MCData server (200) initiates at least one pre - established session with the originating MCData client device (100a) based on the pre - established session indication.

[0037] In addition, the participating MCData server (200) receives an MCData communication reference request (i.e., REFER (method = INVITE) (private / group) message) from the originating MCData client device (100a) to establish MCData communication to the control MCData server (100b). In addition, the participating MCData server (200) sends an acknowledgement (i.e., 200OK) to the originating MCData client device (100a) in response to receiving the MCData communication reference request message. In addition, the participating MCData server (200) sends an MCData communication invitation request message (i.e., INVITE message) to the control MCData server (100b) to establish an MCData communication session with the originating MCData client device (100a). In addition, the participating MCData server (200) receives one of an MCData communication session establishment success message (i.e., establish - success), an MCData communication session failure message (i.e., establish - fail), and an MCData communication session rejection message (i.e., establish - fail) from the control MCData server (100b).

[0038] In addition, in response to receiving the MCData communication session establishment success message from the control MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes an establishment success indication indicating that MCData communication has been successfully established in the pre - established session.

[0039] In addition, in response to receiving an MCData communication session failure message from the control MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes a setup failure indication indicating that the MCData communication was not successfully established in the pre-established session.

[0040] In addition, in response to receiving an MCData communication session rejection message from the control MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes a setup failure indication indicating that the MCData communication was not successfully established in the pre-established session.

[0041] In addition, in response to at least one MCData communication status, the participating MCData server (200) receives an acknowledgment message (i.e., 200OK) from the originating MCData client device (100a). In addition, the participating MCData server (200) maintains at least one pre-established session with the originating MCData client device (100a).

[0042] In addition, the participating MCData server (200) receives an MCData communication end request message (i.e., REFER (method = BYE)) from the originating MCData client device (100a) to terminate the MCData communication session to the control MCData server (100b). In addition, in response to receiving the MCData communication end request message, the participating MCData server (200) sends an acknowledgment message (i.e., 200OK) to the originating MCData client device (100a). In addition, the participating MCData server (200) sends an MCData communication end request message (i.e., BYE message) to the control MCData server (100b) to terminate the MCData communication session with the originating MCData client device (100a). In addition, the participating MCData server (200) receives an MCData communication session termination message from the control MCData server (100b). In addition, in response to receiving the MCData communication session termination message from the control MCData server (100b), the participating MCData server (200) sends an MCData communication status message (i.e., Re-INVITE (with communication state = "terminated")) to the originating MCData client device (100a). From the control MCData server (100b). The MCData communication status message includes a termination indication indicating that the MCData communication has been successfully terminated within the pre-established session. In addition, in response to receiving the MCData communication status, the participating MCData server (200) receives an acknowledgment message (i.e., 200OK) from the originating MCData client device (100a). In addition, the participating MCData server (200) maintains at least one pre-established session with the originating MCData client device (100a).

[0043] In addition, the participating MCData server (200) receives a MCData communication invitation message request (i.e., INVITE message) from the control MCData server (100b) to establish a MCData communication session with the originating MCData client device (100a). In addition, in response to receiving the MCData communication invitation message request from the control MCData server (100b), the participating MCData server (200) sends a MCData communication status message (i.e., Re-INVITE (with communication state = “establish-request”)) to the originating MCData client device (100a). The MCData communication status message includes an establishment request indication indicating that the request will establish MCData communication within a pre-established session. In addition, the participating MCData server (200) receives an acknowledgement message (i.e., 200OK) from the originating MCData client device (100a) in response to the MCData communication status. In addition, the participating MCData server (200) sends the acknowledgement message to the control MCData server (100b) in response to receiving the acknowledgement message. In addition, the participating MCData server (200) maintains at least one pre-established session with the originating MCData client device (100a).

[0044] In addition, the participating MCData server (200) receives a MCData communication termination request message (i.e., BYE message) from the control MCData server (100b) to terminate the MCData communication session to the control MCData server (100b). In addition, in response to receiving the MCData communication termination request message from the control MCData server (100b), the participating MCData server (200) sends a MCData communication status message (i.e., Re-INVITE (with communication state = “terminate-request”)) to the originating MCData client device (100a), where the MCData communication status message includes a termination request indication indicating that the request will terminate MCData communication in a pre-established session. In addition, the participating MCData server (200) receives an acknowledgement message (i.e., 200OK) from the originating MCData client device (100a) in response to the MCData communication status. In addition, the participating MCData server (200) sends the acknowledgement message to the control MCData server (100b) in response to receiving the acknowledgement message. In addition, the participating MCData server (200) maintains at least one pre-established session with the originating MCData client device (100a).

[0045] Figure 2 A block diagram of a participating MCData server (200) for initiating MCData communication using a pre - established session, according to an embodiment disclosed herein. The participating MCData server (200) includes a memory (210), a processor (220), and a communicator (230).

[0046] The memory (210) also stores instructions to be executed by the processor (220). The memory (210) may include non - volatile storage elements. Examples of such non - volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memories, or in the form of electrically programmable memory (EPROM) or electrically erasable programmable (EEPROM) memory. Additionally, in some examples, the memory (210) 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 a propagated signal. However, the term "non - transitory" should not be construed to mean that the memory (210) is immovable. In some examples, the memory (210) may be configured to store an amount of information larger than the memory. In certain examples, the non - temporary storage medium may store data that can change over time (e.g., in random access memory (RAM) or cache). In one embodiment, the memory (210) may be an internal storage unit, or it may be an external storage unit of the participating MCData server (200), cloud storage, or any other type of external storage.

[0047] In one embodiment, the processor (220) includes a pre - established session initiator (220a) and an MCData communication status engine (220b).

[0048] The pre - established session initiator (220a) receives at least one pre - established session setup request (i.e., INVITE message) from an originating MCData client device (100a). The pre - established session setup request includes a pre - established session indication that indicates to the pre - established session initiator (220a) the initiation of at least one pre - established session. Additionally, the pre - established session initiator (220a) initiates at least one pre - established session with the originating MCData client device (100a) based on the pre - established session indication.

[0049] The MCData communication status engine (220b) receives an MCData communication reference request (i.e., REFER (method=INVITE) (private / group)) message from an originating MCData client device (100a) to establish an MCData communication session with a control MCData server (100b). In addition, in response to receiving the MCData communication reference request message, the MCData communication status engine (220b) sends an acknowledgement (i.e., 200OK) to the originating MCData client device (100a). In addition, the MCData communication status engine (220b) sends an MCData communication invitation request message (i.e., INVITE message) to the control MCData server (100b) to establish an MCData communication session with the originating MCData client device (100a). In addition, the MCData communication status engine (220b) receives an MCData communication session establishment success message (i.e., establish-success), an MCData communication session failure message (i.e., establish-fail), and an MCData communication session rejection message (i.e., establish-fail) from the control MCData server (100b).

[0050] In addition, in response to receiving the MCData communication session establishment success message from the control MCData server (100b), the MCData communication status engine (220b) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes an establishment success indication indicating successful establishment of MCData communication in a pre-established session.

[0051] In addition, in response to receiving the MCData communication session failure message from the control MCData server (100b), the MCData communication status engine (220b) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes an establishment failure indication indicating unsuccessful establishment of MCData communication in a pre-established session.

[0052] In addition, in response to receiving the MCData communication session rejection message from the control MCData server (100b), the MCData communication status engine (220b) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes an establishment failure indication indicating unsuccessful establishment of MCData communication in a pre-established session.

[0053] In addition, in response to at least one MCData communication state, the MCData communication state engine (220b) receives an acknowledgement message (i.e., 200 OK) from the originating MCData client device (100a). In addition, the MCData communication state engine (220b) maintains at least one pre-established session with the originating MCData client device (100a).

[0054] In addition, the MCData communication state engine (220b) receives an MCData communication end request message (i.e., REFER (method = BYE) message) from the originating MCData client device (100a) to terminate the MCData communication session to the control MCData server (100b). In addition, in response to receiving the MCData communication end request message, the MCData communication state engine (220b) sends an acknowledgement message (i.e., 200 OK) to the originating MCData client device (100a). In addition, the MCData communication state engine (220b) sends an MCData communication end request message (i.e., BYE message) to the control MCData server (100b) to terminate the MCData communication session with the originating MCData client device (100a).

[0055] In addition, the MCData communication state engine (220b) receives an MCData communication session termination message from the control MCData server (100b). In addition, in response to receiving the MCData communication session termination message from the control MCData server (100b), the MCData communication state engine (220b) sends an MCData communication state message (i.e., Re-INVITE (with communicationstate = “terminated”)) to the originating MCData client device (100a), where the MCData communication state message includes a termination indication indicating that the MCData communication has successfully terminated in the pre-established session. In addition, in response to receiving the MCData communication state, the MCData communication state engine (220b) receives an acknowledgement message (i.e., 200 OK) from the originating MCData client device (100a). In addition, the MCData communication state engine (220b) maintains at least one pre-established session with the originating MCData client device (100a).

[0056] In addition, the MCData communication status engine (220b) receives an MCData communication invitation message request (i.e., INVITE message) from the control MCData server (100b) to establish an MCData communication session with the originating MCData client device (100a). Further, in response to receiving the MCData communication invitation message request from the control MCData server (100b), the MCData communication status engine (220b) sends an MCData communication status message (i.e., Re-INVITE (with communication state = “establish-request”)) to the originating MCData client device (100a), where the MCData communication status message includes an establishment request indication indicating successful establishment of MCData communication in a pre-established session.

[0057] In addition, in response to the MCData communication status, the MCData communication status engine (220b) receives an acknowledgement message (i.e., 200OK) from the originating MCData client device (100a). Further, in response to receiving the acknowledgement message, the MCData communication status engine (220b) sends an acknowledgement message to the control MCData server (100b). In addition, the MCData communication status engine (220b) maintains at least one pre-established session with the originating MCData client device (100a).

[0058] In addition, the MCData communication status engine (220b) receives an MCData communication end request message (i.e., BYE message) from the control MCData server (100b) to terminate the MCData communication session with the control MCData server (100b). In addition, in response to receiving the MCData communication end request message from the control MCData server (100b), the MCData communication status engine (220b) sends an MCData communication status message (i.e., Re-INVITE (with communication state = "terminate-request")) to the originating MCData client device (100a), where the MCData communication status message includes a termination request indication indicating that the request will terminate the MCData communication within the pre-established session. In addition, the MCData communication status engine (220b) receives an acknowledgement message (i.e., 200OK) in response to the MCData communication status from the originating MCData client device (100a). In addition, in response to receiving the acknowledgement message, the MCData communication status engine (220b) sends an acknowledgement message to the control MCData server (100b). In addition, the MCData communication status engine (220b) maintains at least one pre-established session with the originating MCData client device (100a).

[0059] The communicator (230) is configured to communicate internally between internal hardware components and with external devices via one or more networks.

[0060] Although Figure 2 various hardware components involved in the MCData server (200) are shown, it should be understood that other embodiments are not limited thereto. In other embodiments, the MCData server (200) may include fewer or more components involved. In addition, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present invention. One or more components may be combined together to perform the same or substantially similar functions to initiate MCData communication using the pre-established session.

[0061] Figure 3 is a sequence diagram showing a method for setting up a pre-established session in MCData communication according to an embodiment disclosed herein.

[0062] In step 301, the participating MCData server (200) receives at least one pre - established session setup request (i.e., INVITE) from the originating MCData client device (100a), where the pre - established session setup request includes a pre - established session indication indicating the initiation of at least one pre - established session by the participating MCData server (200). In step 302, the participating MCData server (200) sets service controls and obtains media parameters. In step 303, in response to receiving at least one pre - established session setup request, the participating MCData server (200) sends an acknowledgement (i.e., 200OK) to the originating MCData client device (100a).

[0063] According to Sub-clause 18.1 : The originating MCData client device (100a) can establish one or more pre - established sessions with the participating MCData server (200) at any time after registering in the Session Initiation Protocol (SIP) and setting service settings. The originating MCData client device (100a) can use the pre - established sessions to initiate an independent short data service (SDS) using the media plane, conduct an SDS session using the media plane, or perform file distribution (FD) after the pre - established sessions are established. The participating MCData server (200) can use the pre - established sessions to terminate an independent SDS using the media plane, an SDS session using the media plane, or FD after the pre - established sessions are established. Using the pre - established sessions requires using resource sharing specified by the participating MCData server (200) in 3GPP TS 29.214 and 3GPP TS 24.229. The use of resource sharing by the participating MCData server (200) is defined in sub - clause 18.2.

[0064] According to Sub-clause 18.2 : The participating MCData server (200) uses resource sharing: The participating MCData server (200) uses resource sharing by:

[0065] 1) via the SIP core specified in 3GPP TS 24.229; or

[0066] 2) as specified in 3GPP TS 29.214, by directly interfacing with the Policy and Charging Control (PCC) to control resource sharing via the Rx reference point.

[0067] If resource sharing is supported, the participating MCData server (200) may allow the originating MCData client device (100a) to use a pre - established session. The participating MCData server (200) may determine from the received third - party SIP REGISTER request that the SIP core supports resource sharing if a Resource - Share header field with the value "supported" is included in the "message / sip" MIME body of the third - party SIP REGISTER request specified in 3GPP TS 24.229. When using resource sharing, the participating MCData server (200) uses the "+g.3gpp.registration - token" header field parameter in the Contact header field of the third - party REGISTER request to identify the MCData UE being registered (e.g., the originating UE or the remote UE), and to identify whether resource sharing and the pre - established session can be used with a particular MCData UE.

[0068] According to Sub-clause 18.3.1 This sub - clause describes the process of establishing a pre - established MCData session, which can be used to initiate an independent SDS using the media plane or an SDS session. The originating MCData client device (100a) or the participating MCData server (200) may initiate the release of the pre - established session defined in sub - clause 18.3.3.

[0069] According to Sub-clause 18.3.1.1 SDP offer generation: When composing an SDP offer according to 3GPP TS 24.229, IETF RFC 4975, IETF RFC 6135, and IETF RFC 6714, the MCData client:

[0070] 1) Shall include an "m = message" media - level section for the MCData media stream, which includes:

[0071] a) A port number;

[0072] b) A protocol field value of "Transmission Control Protocol (TCP) / Message Session Relay Protocol (MSRP)" or "TCP / TLS / MSRP" for TLS;

[0073] c) An "a = sendrecv" attribute;

[0074] d) An "a = path" attribute containing its own MSRP URI;

[0075] e) Set the content type to "a=accept types:application / vnd.3gpp.mcdata-signalling application / vnd.3gpp.mcdata-payload"; and

[0076] f) Set the a=setup attribute to "actpass".

[0077] According to Sub-clause 18.3.1.2 : SDP Answer Generation: When composing the SDP answer according to 3GPP TS 24.229, the participating MCData server (200):

[0078] 1) If necessary, for the media streams accepted in the received SDP offer, the IP address and port number in the received SDP answer shall be replaced with the IP address and port number of the participating MCData server (200); and

[0079] 2) If the IP address is replaced, its MSRP URI shall be inserted before the MSRP URI in the "a=path" attribute of the SDP answer.

[0080] According to Sub-clause 18.3.2.1 : Procedure of the originating MCData client device (100a): When the originating MCData client device (100a) initiates a pre-established session, the originating MCData client device (100a) shall:[[]]

[0081] 1) Collect ICE candidates according to IETF RFC 5245; and

[0082] Collect ICE candidates only on the interface used by the MCData UE to obtain the MCData service.

[0083] 2) Generate an initial SIP INVITE request by following the UE-originated session procedure specified in 3GPP TS 24.229, and the description is given below.

[0084] The originating MCData client device (100a):

[0085] 1) Set the Request-URI of the SIP INVITE request to the public service identity of the participating MCData server (200) serving the MCData user (i.e., the MCData client device (100a));

[0086] 2) A P-Preferred-Identity header field can be included in the SIP INVITE request, which contains the public user identity specified in 3GPP TS 24.229;

[0087] 3) According to IETF RFC 3840, the g.3gpp.mcdata.sds media function label should be included in the Contact header field of the SIP INVITE request;

[0088] 4) According to IETF RFC 3841, an Accept-Contact header field with the media function label g.3gpp.mcdata.sds and the parameters "require" and "explicit" should be included;

[0089] 5) According to IETF RFC 6050, in the SIP INVITE request, the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" (encoded as specified in 3GPP TS 24.229) should be included in the P-Preferred-Service header field;

[0090] 6) According to IETF RFC 3841, an Accept-Contact header field with the media feature label g.3gpp.icsi-ref set to the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" and the parameters "require" and "explicit" should be included;

[0091] 7) The "timer" option label should be included in the supported header fields;

[0092] 8) A Session-Expires header field according to IETF RFC 4028 should be included, and the "refresher" header field should not be included. If included, the "refresher" header field parameter should be set to "uac".

[0093] 9) It should be included in the application / vnd.3gpp.mcdata-info+xml MIME body <mcdata-params>of the element <mcdatainfo>element <mcdata-params>The element has <anyext>Element and set to the value "true" <pre-built-session-ind>Element;

[0094] 10) shall include the SDP provided according to 3GPP TS 24.229, as clarified in Subclause 18.3.1.1, and include ICE candidates in the SDP offer according to IETF RFC 5245; and

[0095] 11) shall send a SIP INVITE request according to 3GPP TS 24.229.

[0096] After receiving a SIP 2xx response to the SIP INVITE request, the originating MCData client device (100a):

[0097] 1) shall interact with the media plane as specified in 3GPP TS 24.582.

[0098] According to Sub-clause 18.3.2.2 : Participate in the MCData server (200) process: After receiving the "SIP INVITE request for establishing a pre-established session", the participating MCData server (200):

[0099] 1) shall check whether a public service identifier has been allocated. If not, it shall return a SIP 404 (Not Found) response. Otherwise, continue with the remaining steps.

[0100] 2) shall determine the MCData ID of the MCData user for establishing the pre-established session and perform actions to verify the MCData ID of the originating MCData client device (100a) and authorize the request according to the local policy; if not authorized, the participating MCData server (200) shall return a SIP 403 (Forbidden) response and set the warning text to "225 User not authorized to initiate pre-established session", as specified in Subclause 4.9. Otherwise, continue with the remaining steps.

[0101] 3) shall determine whether resource sharing is supported (see Subclause 18.2);

[0102] 4) If the SIP core supports resource sharing, determine that there is a binding between the MCData ID of the MCData user establishing the pre-established session and the MCData UE identified by the "+g.3gpp.registration-token" header field parameter in the Contact header field of the third-party REGISTER request (see subclause 18.2), and that the UE identification matches the identification in the "+g.3gpp.registration-token" header field parameter in the Feature-Caps header field in the "SIP INVITE request for establishing the pre-established session";

[0103] 5) If resource sharing is not supported, or there is no binding between the MCData ID of the MCData user and the identification of the MCData UE identified by the "+g.3gpp.registration-token" header field parameter in the Feature-Caps header field, then the participating MCData server (200) shall return a SIP 403 (Forbidden) response, and set the warning text as specified in subclause 4.9 "226 function not allowed due to the pre-established session not supported, 226", and shall not continue the remaining steps;

[0104] 6) It shall be determined whether the media parameters are acceptable, and if the MSRP URI is provided in the SDP offer, if not, then use a SIP 488 (Not Acceptable Here) response to reject the request, and skip the remaining steps;

[0105] 7) It shall be verified whether the media resources are available to support the media parameters, if not, then a SIP 500 (Server Internal Error) response shall be used to reject the request, and the remaining steps shall not be continued;

[0106] 8) A URI shall be allocated to identify the pre-established session;

[0107] 9) A SIP 200 (OK) response to the SIP INVITE request shall be generated in accordance with 3GPP TS 24.229; and

[0108] a) It shall include a Contact header field containing the URI identifying the pre-established session;

[0109] b) The public service identification shall be included in the P-Asserted-Identity header field;

[0110] c) SHALL include a supporting header field containing the "norefersub" option tag;

[0111] d) If the SIP core supports resource sharing, it SHALL include a Resource-Share resource sharing header field response as specified in 3GPP TS 24.229, which includes:

[0112] A) The value "media-sharing";

[0113] B) The "origin" header field parameter set to "session-initiator";

[0114] C) The "timestamp" header field parameter; and

[0115] D) The "rule" header field parameter, with one resource sharing rule for each media stream, in the same order as the corresponding m-line appears in the SDP. The construction of each resource sharing rule is as follows:

[0116] - The "new-sharing-key" part; and

[0117] - The "directionality" part, indicating the direction of the pre-established media stream; and

[0118] e) SHALL include the SDP response specified in 3GPP TS 24.229 and the clarifications in sub-clause 18.3.1.2, and include ICE candidates in the SDP response according to IETF RFC 5245;

[0119] 10) SHALL interact with the media plane as specified in 3GPP TS 24.582;

[0120] 11) SHALL send a SIP 200 (OK) response to the originating MCData client device (100a) according to the rules and procedures of 3GPP TS 24.229; and

[0121] 12) SHALL evaluate ICE candidates according to IETF RFC 5245.

[0122] If the ICE candidate evaluation result leads to the selection of a candidate pair other than the default candidate pair, further offer / answer exchanges are required using the procedures in sub-clause 18.3.4.

[0123] According to Sub-clause 18.3.3.1.1 : The originating MCData client device (100a) initiates the release process: The originating MCData client device (100a) needs to be prepared to release the pre - established session upon receiving a SIP BYE request generated by the SIP core (e.g., due to network release of media plane resources). When the originating MCData client device (100a) needs to release the pre - established session created as in Sub - clause 18.3.2, the originating MCData client device (100a) shall execute the process described in Sub - clause 13.2.2.2.2.1 of 3GPP specification TS 24.282.

[0124] According to Sub-clause 18.3.3.1.2 : The participating MCData server (200) initiates the release process: After receiving a SIP BYE request from the originating MCData client device (100a) in the pre - established session, the originating MCData client device (100a) shall check whether there is an MCData session using the pre - established session, and:

[0125] 1) If there is an established MCData session, the originating MCData client device (100a) shall remove the originating MCData client device (100a) from the MCData session by executing the session release process for each MCData session specified in 3GPP TS 24.582; and

[0126] 2) If there is no MCData session using the pre - established session, the originating MCData client device (100a) shall follow the process described in Sub - clause 13.2.3.2.2 of 3GPP specification TS 24.282.

[0127] According to Sub-clause 18.3.3.2.1 , the originating MCData client device (100a) initiates the release process: After receiving a SIP BYE request from the originating MCData client device (100a) in the pre - established session, the participating MCData server (200):

[0128] 1) Shall check whether there is an MCData session using the pre - established session, and:

[0129] a) If there is an established MCData session, the participating MCData server (200) shall remove the originating MCData client device (100a) from the MCData session by executing the process specified in Sub - clause 13.2.2.2.3.1 of 3GPP specification TS24.282; and

[0130] b) If there is an MCData session in the process of being established, the participating MCData server (200):

[0131] i) A SIP CANCEL request shall be sent during the establishment process to cancel the MCData session in accordance with 3GPP TS 24.229; and

[0132] ii) If a SIP 200 (OK) response to the SIP INVITE request is received from the remote end, the MCData session shall be released as specified in Sub-clause 13.2.2.2.3.1 of 3GPP Specification TS 24.282; and

[0133] c) If there is no MCData session using the pre-established session, the participating MCData server (200) shall:

[0134] i) Interact with the media plane to disconnect the media plane resources from the originating MCData client device (100a) as specified in 3GPP TS 24.582; and

[0135] ii) Generate and send a SIP 200 (OK) response to the SIP BYE request in accordance with the rules and procedures of 3GPP TS 24.229.

[0136] After receiving a SIP 200 (OK) response to the SIP BYE request from the remote end, the participating MCData server (200):

[0137] 1) Shall interact with the media plane to release the media plane resources (100a) to the originating MCData client device as specified in 3GPP TS 24.582; and

[0138] 2) Send a SIP 200 (OK) response to the SIP BYE request to the originating MCData client device (100a).

[0139] According to Sub-clause 18.3.3.2.2 : The participating MCData server (200) initiates the release process: When the participating MCData server (200) needs to release a pre-established session created in Sub-clause 8.2.2 of 3GPP Specification TS 24.282, the participating MCData server (200):

[0140] 1) First, all participants of the MCData calls using the pre-established session shall be released. The participating MCData server (200) shall remove the originating MCData client device (100a) from the MCData session by performing the process specified in Sub-clause 13.2.2.2.3.1 of 3GPP Specification TS 24.282;

[0141] 2) The SIP BYE request shall be generated according to the rules and procedures of 3GPP TS 24.229;

[0142] 3) The Request-URI of the SIP BYE request shall be set to the URI identifying the pre-established session;

[0143] 4) The SIP BYE request shall be sent to the originating MCData client device (100a) within the SIP dialog of the pre-established session according to the rules and procedures of 3GPP TS 24.229; and

[0144] 5) Once the SIP 200 (OK) response to the SIP BYE request is received, interaction with the media plane shall be performed as specified in 3GPP TS 24.582.

[0145] According to Sub-clause 6.3.1.2 : SIP INVITE request: The participating MCData server (200) needs to distinguish the following SIP INVITE requests: SIP INVITE requests for initiation and termination; SIP INVITE requests with the Request-URI set to the public service identifier of the participating MCData server (200) and routed to the participating MCData server (200); and those contained in the application / vnd.3gpp.mcdata-info+xml MIME body, the <mcdatainfo>The element contains <mcdata-params>element <mcdata-params>The element has <anyext>The element and is set to the value "true" <pre-built-session-ind>An element. Such a request is referred to as a "SIP INVITE request for establishing a pre - established session" during the course of the present disclosure.

[0146] Figure 4 and Figure 5 is a sequence diagram showing a method for initiating an outgoing MCData communication using a pre - established session according to an embodiment disclosed herein.

[0147] In step 401, a pre - established session is established between an originating MCData client device (100a) and a participating MCData server (200). In step 402, the participating MCData server (200) receives an MCData communication reference request message from the originating MCData client device (100a) to establish an MCData communication session to a control MCData server (100b). In step 403, the participating MCData server (200) sends an acknowledgement to the originating MCData client device (100a) in response to receiving the MCData communication reference request message. In step 404, the participating MCData server (200) sends an MCData communication invitation request message to the control MCData server (100b) to establish an MCData communication session with the originating MCData client device (100a). In step 405, the participating MCData server (200) receives an MCData communication session establishment success message from the control MCData server (100b).

[0148] In step 406, the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a) in response to receiving the MCData communication session establishment success message from the control MCData server (100b), where the MCData communication status message contains an establishment success indication indicating that the MCData communication has been successfully established in the pre - established session. In step 407, the participating MCData server (200) receives an acknowledgement message from the originating MCData client device (100a) in response to at least one MCData communication status. In step 408, the participating MCData server (200) maintains at least one pre - established session with the originating MCData client device (100a).

[0149] In step 501, a pre - established session is established between the originating MCData client device (100a) and the participating MCData server (200). In step 502, the participating MCData server (200) receives an MCData communication reference request message from the originating MCData client device (100a) to establish an MCData communication session to the controlling MCData server (100b). In step 503, the participating MCData server (200) sends an acknowledgement to the originating MCData client device (100a) in response to receiving the MCData communication reference request message. In step 504, the participating MCData server (200) sends an MCData communication invitation request message to the controlling MCData server (100b) to establish an MCData communication session with the originating MCData client device (100a). In step 505, the participating MCData server (200) receives an MCData communication session establishment failure or rejection message from the controlling MCData server (100b).

[0150] In step 506, in response to receiving the MCData communication session establishment failure or rejection message from the controlling MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes a setup failure indication indicating that the MCData communication has not been successfully established within the pre - established session. In step 507, the participating MCData server (200) receives an acknowledgement message from the originating MCData client device (100a) in response to at least one MCData communication status. In step 508, the participating MCData server (200) maintains at least one pre - established session with the originating MCData client device (100a).

[0151] According to Sub-clause 9.2.5.1.1 Generating an INVITE request upon receiving a REFER request: This sub - clause is referenced from other procedures. When generating an initial SIP INVITE request according to 3GPP TS 24.229, upon receiving an incoming SIP REFER request, the participating MCData server (200):

[0152] 1) shall include in the SIP INVITE request the <entry>All the header fields contained in the header part of the SIP URI included in the element and referenced by the "cid" URL in the Refer-To header field of the input SIP REFER request;

[0153] 2) According to IETF RFC 4028

[38] , the Session-Expires header field shall be included.

[0154] 3) The option tag "timer" shall be included in the Supported header field;

[0155] 4) The content of the P-Asserted-Identity header field of the input SIP REFER request shall be copied to the P-Asserted-Identity header field of the output SIP INVITE request;

[0156] 5) The g.3gpp.mcdata.sds media function tag with the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" and the g.3gpp.icsi-ref media function tag shall be included in the Contact header field of the output SIP INVITE request;

[0157] 6) The ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds" (encoded as specified in 3GPP TS 24.229) shall be included in the P-Asserted-Service header field of the output SIP INVITE request; and

[0158] 7) According to the rules and procedures of IETF RFC 4538, the option tag "tdialog" shall be included in the Supported header field in the SIP INVITE request;

[0159] 8) According to the following, the SDP offer specified in Subclause 9.2.3.3.1 shall be included in the SIP INVITE request:

[0160] a) The SDP negotiated during the pre-established session establishment and any subsequent pre-established session modification; and

[0161] b) The SDP offer (if any) contained in the <entry>in the "body" URI parameter of the SIP-URI contained in the element and referenced by the "cid" URL in the Refer-To header field of the SIP REFER request for the input for pre - establishing a session;

[0162] 9) The application / vnd.3gpp.mcdata - info+xml MIME body from the "body" URI header field of the SIP-URI in the application / resource list MIME body and referenced by the "cid" URL in the Refer-To header field of the SIP REFER request shall be copied to the output SIP INVITE request; and

[0163] 10) If the input SIP REFER request contains in the application / resource list MIME body <entry>For the MIME body of the application / resource list referred to by the "cid" URL in the "body" URI header field of the SIP-URI contained in the element, the MIME body of the application / resource list in the "body" URI header field shall be copied to the SIP INVITE request.

[0164] According to Sub-clause 9.2.5.1.2 : Generate a Re-INVITE request to the originating MCData client device (100a) during the pre-established session: This sub-clause is referenced from other procedures. Participating MCData server (200):

[0165] 1) A SIP re-invite request shall be generated according to 3GPP TS 24.229 for transmission in the SIP dialog of the pre-established session;

[0166] 2) In the output Re-INVITE request, the following shall be included in the application / vnd.3gpp.mcdata-info+xml MIME body:

[0167] a) If a SIP 2xx response is received to the SIP-INVITE request sent to the controlling MCData server (100b), then with a value set to "establish-success, establishment successful" <mcdata-communication-state>Element; or

[0168] b) If an error response is received for the SIP-INVITE request sent to the control MCData server (100b), then <mcdata-communication-state>Element;

[0169] According to Sub-clause 9.2.5.2 : Initiate one-to-one SDS communication: Use the procedures in this subclause to initiate one-to-one standalone SDS in a pre-established session using the media plane or a one-to-one SDS session.

[0170] According to Sub-clause 9.2.5.2.1.1 : Client-originated procedure (originating MCData client device (100a) procedure): After receiving a request from an MCData user to initiate a one-to-one standalone SDS using the media plane or a one-to-one SDS session in a pre-established session, the originating MCData client device (100a) shall generate a SIP REFER request outside the dialog specified in IETF RFC 3515 updated by IETF RFC6665 and IETF RFC 7647, as described below.

[0171] Originating MCData client device (100a):

[0172] 1) Set the Request URI of the SIP REFER request to the session identifier of the pre-established session;

[0173] 2) Set the Refer-To header field of the SIP REFER request specified in IETF RFC 3515 using the Content-ID ("cid”) Uniform Resource Locator (URL) specified in IETF RFC 2392, which points to the application / resource-listing MIME ontology specified in IETF RFC 5366, and set the Content-ID header field to this "cid” URL;

[0174] 3) If an end-to-end security context needs to be established and the security context does not exist or the existing security context has expired, then:

[0175] i) If necessary, instruct the key management client to request key material from the key management server as described in 3GPP TS 33.180;

[0176] ii) Use the key material to generate the PCK as described in 3GPP TS 33.180;

[0177] iii) Generate a PCK-ID using the PCK and set its four most significant bits to "0001” to indicate that the purpose of the PCK is to protect one-to-one communication, and the remaining 28 bits are randomly generated, as described in 3GPP TS 33.180;

[0178] iv) The PCK shall be encrypted to a UID associated with the originating MCData client device (100a) using the MCData ID and time-related parameters of the invited user as described in 3GPP TS 33.180;

[0179] v) A MIKEY-SAKKE I_MESSAGE shall be generated using the encapsulated PCK and PCK-ID specified in 3GPP TS 33.180;

[0180] vi) The MCData ID of the originating MCData shall be added to the originator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.180; and

[0181] vii) The MIKEY-SAKKE I_MESSAGE shall be signed using the signature key of the originating MCData user provided in the key material and time-related parameters, and added to the MIKEY-SAKKE payload as described in 3GPP TS 33.180;

[0182] 4) A single <entry>An element that contains a "uri" attribute set to the MCData ID of the called user and is extended with the following URI header fields:

[0183] Characters not formatted as ASCII characters will be omitted in the following URI header fields;

[0184] a) A URI header field named "body", filled with:

[0185] i) If a one-to-one standalone SDS message is requested, an application / sdp MIME body that contains an SDP offer with media attributes specified in subclause 9.2.3.2.1 of 3GPP specification TS 24.282;

[0186] ii) An application / vnd.3gpp.mcdata-info MIME body with the following:

[0187] A) If a one-to-one standalone SDS message is requested, set to the value "one-to-one-sds" of <request-type>Element. If a one-to-one SDS session is requested, set to the value "one-to-one-sds-session" <request-type>Element; and

[0188] B) the ID of the originating MCData client device (100a) that is set to be the originating MCData client device (100a) <mcdata-client-id>Element; and

[0189] 5) According to IETF RFC 6050, the P-Preferred-Service header field set to the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcsi.mcdata.sds" (encoded as specified in 3GPP TS 24.229) shall be included;

[0190] 6) The P-Preferred-Identity header field may be included in the SIP INVITE request containing the public user identity specified in 3GPP TS 24.229;

[0191] 7) According to IETF RFC 4488, the following shall be included:

[0192] a) The option tag "norefersub" in the Supported header field; and

[0193] b) The value "false" in the Refer-Sub header field.

[0194] 8) The Target-Dialog header field specified in IETF RFC 4538 that identifies the pre-established session shall be included;

[0195] 9) According to IETF RFC 3840, the g.3gpp.mcdata.sds media function label shall be included in the Contact header field of the SIP REFER request; and

[0196] 10) The SIP REFER request shall be sent according to 3GPP TS 24.229.

[0197] Upon receiving the final SIP 2xx response to the SIP REFER request, the originating MCData client device (100a):

[0198] 1) Shall interact with the media plane as specified in 3GPP TS 24.582.

[0199] Upon receiving a SIP re-INVITE request within the pre-established session targeted by the received SIP REFER request, the originating MCData client device (100a):

[0200] 1) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <mcdata-communication-state>The element is set to the value of "establish - success":

[0201] i) The MCData communication establishment success should be notified to the MCData user;

[0202] 2) If in the application / vnd.3gpp.mcdata - info+xml MIME body of the SIP INVITE request <mcdata-communication-state>The element is set to the value of "establish - fail":

[0203] i) The MCData communication establishment failure shall be notified to the MCData user; and

[0204] 3) It shall interact with the media plane as specified in 3GPP TS 24.582;

[0205] During Sub-clause 9.2.5.2.2.1 In: Origination process: After receiving the SIP REFER request, it has:

[0206] 1) The Request - URI set to identify the public service identity participating in the pre - established session on the MCData server (200);

[0207] 2) The Refer - To header field containing the Content - ID ("cid") Uniform Resource Locator (URL) specified in IETF RFC 2392, which points to the one or more specified in IETF RFC 5366 <entry>Element Application / Resource List MIME Body, <entry>The element has a SIP-URI that includes the MCData ID set as the called user <uri>Attribute;

[0208] 3) The SIP-URI "body" URI header field specified above, which contains the one set to "one-to-one-sds" or "one-to-one-sds-session" <request-type>The application / vnd.3gpp.mcdata-info MIME body of the element; and

[0209] 4) The Content-ID header field set to the "cid" URL;

[0210] The participating MCData server (200):

[0211] 1) If the request cannot be processed due to resource shortage or risk of congestion, the SIP INVITE request can be rejected with a SIP 500 (Server Internal Error) response. The participating MCData server (200) can include the Retry-After header field in the SIP 500 (Server Internal Error) response specified in IETF RFC 3261 and shall not continue with the remaining steps;

[0212] 2) Determine the MCData ID of the calling user according to the public user identity in the P-Asserted-Identity header field of the SIP REFER request;

[0213] 3) If the participating MCData server (200) cannot find the binding between the public user identity and the MCData ID, or if the validity period of the existing binding has expired, the participating MCData server (200) shall reject the SIP REFER request with a SIP 404 (Not Found) response, and the SIP 404 (Not Found) response has a warning text set to "141 user unknown to the participating function" in the warning header field specified in sub-clause 4.9, and shall not continue with any of the remaining steps;

[0214] 4) The process in sub-clause 11.1 of 3GPP specification TS 24.282 shall be followed to determine whether the MCData user identified by the MCData ID is authorized for MCData communication;

[0215] i) If the procedure indication in sub-clause 11.1 of 3GPP specification TS 24.282 does not allow the user identified by the MCData ID to initiate MCData communication, the SIP REFER request shall be rejected with a SIP 403 (Forbidden) response. The SIP 403 (Forbidden) response shall have a warning text set to "200 user not authorised to transmit data" in the warning header field as specified in sub-clause 4.9, and the remaining steps in this sub-clause shall not be continued;

[0216] 5) If the received SIP REFER request does not contain an application / resource list MIME body referenced by the "cid" URL in the Refer-To header field, the SIP REFER request shall be rejected with a SIP 403 (Forbidden) response. The SIP 403 (Forbidden) response shall include a warning text of "145 unable to determine called party" in the warning header field as specified in sub-clause 4.9 of 3GPP specification TS 24.282, and the remaining steps shall not be continued;

[0217] 6) If the received SIP REFER request contains an application / resource list MIME body referenced by the "cid" URL in the Refer-To header field, determine whether the communication type is one-to-one independent SDS or one-to-one SDS session, where the Refer-To header field has more than one <entry>element, each <entry>The element has an application / vnd.3gpp.mcdata-info MIME body, and each body has <request-type>element.

[0218] 7) The public service identifier of the controlling MCData server (100b) associated with the MCData ID of the originating user should be determined;

[0219] i) if the Participating MCData Server (200) cannot identify the Controlling MCData Server (100b), it shall reject the REFER request via a SIP 404 (Not Found) response with the warning text "142 unable to determine the controlling function" in the Warning header field as specified in subclause 4.9 of 3GPP specification TS 24.282, and shall not proceed with any of the remaining steps;

[0220] 8) if the SIP REFER request contains a Refer-Sub header field containing a value of "false" and a Supported header field containing a value of "norefersub", the SIP REFER request SHOULD be processed as specified in 3GPP TS 24.229, IETF RFC 3515 as updated by IETF RFC 6665, and IETF RFC 4488, without establishing an implicit subscription;

[0221] 9) A final SIP 200 (OK) response to the SIP REFER request should be generated according to 3GPP TS 24.229;

[0222] According to IETF RFC 4488, the participating MCData server (200) inserts a Refer-Sub header field containing a value of "false" in a SIP 200 (OK) response to a SIP REFER request to indicate that it has not created an implicit subscription.

[0223] 10) A response to the SIP REFER request shall be sent to the originating MCData client device (100a) in accordance with 3GPP TS 24.229;

[0224] 11) A SIP INVITE request shall be generated as described in subclause 9.2.5.1.1.

[0225] 12) The Request-URI of the SIP INVITE request shall be set to the public service identifier of the MCData server (100b) controlling the service of the calling MCData user determined in step 7) above; and

[0226] 13) The SIP INVITE request shall be forwarded according to 3GPP TS 24.229.

[0227] After receiving the SIP 200 (OK) response to the SIP INVITE request, the participating MCData server (200):

[0228] 1) Shall interact with the media plane as specified in 3GPP TS 24.582;

[0229] 2) Shall generate a SIP re-INVITE request as specified in sub-clause 9.2.5.1.2, with the following specifications:

[0230] i) The Request-URI shall be set to identify the public service identity of the pre-established session;

[0231] 3) Shall send the SIP re-INVITE request to the originating MCData client device (100a) according to 3GPP TS 24.229; and

[0232] 4) After receiving the SIP 2xx response to the SIP re-INVITE, shall interact with the media plane as specified in 3GPP TS 24.582.

[0233] In Sub-clause 9.2.5.3 the group SDS communication process is initiated: The process in this sub-clause is used to initiate group-independent SDS using the media plane or a group SDS session in a pre-established session.

[0234] In Sub-clause 9.2.5.3.1.1 : The client-originated process (originating MCData client device (100a) process): After receiving a request from the MCData user to initiate a one-to-one independent SDS or a one-to-one SDS session using the media plane in a pre-established session, the originating MCData client device (100a) shall generate a SIP REFER request outside the dialog, as specified in IETF RFC 3515 updated by IETF RFC 6665 and IETF RFC 7647, and according to the UE process specified in 3GPP TS 24.229, as specified in sub-clause 9.2.5.1.1, with the following specifications:

[0235] 1) Skip step 3); and

[0236] 2) Shall include a single <entry>element, the <entry>The element contains a "uri" attribute set to the MCData group identifier and is extended with the following URI header fields:

[0237] Characters not formatted as ASCII characters are omitted in the following URI header fields;

[0238] a) A URI header field named "body", filled with:

[0239] i) If a group-independent SDS message is requested, an application / sdp MIME body containing an SDP offer with the media attributes specified in subclause 9.2.3.2.1;

[0240] ii) An application / vnd.3gpp.mcdata-info MIME body with the following content:

[0241] A) If a group-independent SDS message is requested, set to the value "group-sds" <request-type>Element. If a group SDS session is requested, set to the value "group-sds-session" <request-type>Element;

[0242] B) Set to the MCData group identifier <mcdata-request-uri>Element; and

[0243] C) Set to the MCData client ID of the originating MCData client device (100a) <mcdata-client-id>Element;

[0244] In Sub-clause 9.2.5.3.2.1 : Origination process (i.e., participating in the MCData server (200) process): After receiving a SIP REFER request, having:

[0245] 1) A Request-URI set to identify a common service identifier for a pre-established session on the MCData server (200);

[0246] 2) A Refer-To header field containing a Content-ID ("cid") Uniform Resource Locator (URL), as specified in IETF RFC2392, which points to a resource containing one or more <entry>Application / Resource List MIME body for an element, as specified in IETF RFC 5366, one or more <entry>The element has a "uri" attribute that contains a SIP-URI set as the MCData group identifier;

[0247] 3) The "uri" body" header field of the SIP-URI specified above, which contains an application / vnd.3gpp.mcdata-info MIME body that has been set to "group-sds" or "group-sds-session" <request-type>Element; and

[0248] 4) The Content-ID header field set to the "cid” URL;

[0249] The participation function shall follow the procedure described in Subclause 9.2.5.2.2.1.

[0250] Figure 6 is a sequence diagram showing a method for initiating an incoming MCData communication using a pre - established session according to an embodiment disclosed herein.

[0251] In step 601, a pre - established session is established between the originating MCData client device (100a) and the participating MCData server (200). In step 602, the participating MCData server (200) receives an MCData communication invitation message request from the control MCData server (100b) to establish an MCData communication session with the originating MCData client device (100a). In step 603, in response to receiving the MCData communication invitation message request from the control MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes a setup request indication indicating that the request is to establish MCData communication within the pre - established session. In step 604, in response to the MCData communication status, the participating MCData server (200) receives an acknowledgement message from the originating MCData client device (100a). In step 605, the participating MCData server (200) sends an acknowledgement message to the control MCData server (100b) in response to receiving the acknowledgement message. In step 606, the participating MCData server (200) maintains at least one pre - established session with the originating MCData client device (100a).

[0252] According to Sub-clause 9.2.5.1.3 : Generate a Re - INVITE request to terminate the MCData client (100b) during the pre - established session: Refer to this subclause from other procedures, Participating MCData server (200):

[0253] 1) A SIP re - INVITE request shall be generated according to 3GPP TS 24.229 to be sent in the SIP dialogue of the pre - established session;

[0254] 2) According to IETF RFC 4028

[38] , the Session - Expires header field shall be included.

[0255] 3) The option tag "timer" shall be included in the "Supported" header field;

[0256] 4) In accordance with IETF RFC 3841, the Accept-Contact header field shall be included, containing the media feature tag g.3gpp.mcdata.sds, as well as the "require" and "explicit" header field parameters;

[0257] 5) In accordance with IETF RFC 3841, the Accept-Contact header field shall be included with the media feature tag g.3gpp.icsi-ref having a value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", as well as the parameters "require" and "explicit";

[0258] 6) In accordance with IETF RFC 3840, the MCData session identifier of the MCData session with the media feature tags g.3gpp.mcdata.sds, isfocus media feature tag, and g.3gpp.icsi-ref media feature tag, having a value of "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds", shall be included in the Contact header field.

[0259] According to Sub-clause 9.2.5.2.1.2 : Client termination procedure: When a SIP re-INVITE request is received in a pre-established session without an associated MCData session, the originating MCData client device (100a):

[0260] 1) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <mcdata-communication-state>The element is set to the value "establish-request":

[0261] i) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <request-type>If the element is set to the "one-to-one-sds" value, the procedure in subclause 9.2.3.2.4 of 3GPP specification TS 24.282 shall be followed;

[0262] ii) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <request-type>If the element is set to the value "one-to-one-sds-session", the procedures in Subclause 9.2.4.2.4 of 3GPP specification TS24.282 shall be followed;

[0263] According to Sub-clause 9.2.5.2.2.2 : Participate in the termination process of the MCData server (200): After receiving "SIP INVITE request for standalone SDS over media plane for terminating participating MCData function, SIP INVITE request for standalone SDS over media plane for terminating participating MCData function" or "SIP INVITE request for SDS session for terminating participating MCData function, SIP INVITE request for SDS session for terminating participating MCData function", the participating MCData server (200):

[0264] 1) If the request cannot be processed due to insufficient resources or the risk of congestion, the "SIP INVITE request for terminating participating MCData function, SIP INVITE request for terminating participating MCData function" can be rejected using a SIP 500 (Server Internal Error) response. The participating MCData server (200) may include a Retry-After header field in the SIP 500 (Server Internal Error) response, as specified in IETF RFC 3261, and should not continue with the remaining steps.

[0265] 2) The <mcdata-request-uri>Retrieve the binding between the MCData ID and the public user identifier based on the MCData ID present in the element;

[0266] i) If there is no binding between the MCData ID and the public user identifier, the participating MCData server (200) shall reject the SIP INVITE request with a SIP 404 (Not Found) response. Otherwise, proceed with the remaining steps;

[0267] 3) A SIP re-invite request shall be generated as specified in Subclause 9.2.5.1.3, with the following specifications:

[0268] i) The Request-URI shall be set to the public service identifier that identifies the pre-established session;

[0269] ii) If the input SIP INVITE request contains an application / vnd.3gpp.mcdata-info+xml MIME body, the application / vnd.3gpp.mcdata-info+xml MIME body shall be copied into the output SIP INVITE request, with the following specifications:

[0270] a) It shall include the <mcdata-communication-state>Element; and

[0271] iii) The following shall be included in the Contact header field:

[0272] a) The g.3gpp.mcdata.sds media function label;

[0273] b) The g.3gpp.icsi-ref media function label containing the value "urn:urn-7:3gpp-service.ims.icsi.mcdata.sds";

[0274] c) The isfocus media function label;

[0275] d) The MCData session identifier mapped to the MCData session identifier provided in the Contact header field of the incoming SIP INVITE request; and

[0276] e) Any other uri parameters provided in the Contact header field of the incoming SIP INVITE request;

[0277] 4) A SIP re-INVITE request shall be sent to the terminating MCData client (100b) in accordance with 3GPP TS 24.229; and

[0278] 5) After receiving a SIP 2xx response to the SIP re-INVITE, interaction with the media plane shall be performed as specified in 3GPP TS 24.582.

[0279] According to Clause 9.2.5.3.1.2 : Client termination procedure: After receiving a SIP re-INVITE request in a pre-established session without an associated MCData session, the originating MCData client device (100a):

[0280] 1) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <mcdata-communication-state>The element is set to the value of "establish-request":

[0281] i) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <request-type>If the element is set to the value "group-sds", the procedure in subclause 9.2.3.2.4 of 3GPP specification TS 24.282 shall be followed;

[0282] ii) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <request-type>If the element is set to "group-sds-session", the procedure in sub-clause 9.2.4.2.4 of 3GPP specification TS 24.282 shall be followed.

[0283] According to Sub-clause 9.2.5.3.2.2 : Participate in the termination process of the MCData server (200): After receiving "SIP INVITE request for standalone SDS over media plane for terminating participating MCData server (200), the SIP INVITE request for standalone SDS over the media plane for terminating the participating MCData server (200)" or "SIP INVITE request for SDS session for terminating participating MCData server (200), the SIP INVITE request for the SDS session for terminating the participating MCData server (200)", the participating MCData server (200) shall follow the procedure described in section 9.2.5.2.2.2.

[0284] Figure 7 is a sequence diagram showing a method for initiating the termination of MCData communication using a pre-established session by an originating MCData client device (100a) according to an embodiment disclosed herein.

[0285] In step 701, a pre-established session is established between the originating MCData client device (100a) and the participating MCData server (200). In step 702, the participating MCData server (200) receives an MCData communication end request message from the originating MCData client device (100a) to terminate the MCData communication session to the control MCData server (100b). In step 703, the participating MCData server (200) sends an acknowledgment message to the originating MCData client device (100a) in response to receiving the MCData communication end request message. In step 704, the participating MCData server (200) sends an MCData communication end request message to the control MCData server (100b) to terminate the MCData communication session with the originating MCData client device (100a).

[0286] In step 705, the participating MCData server (200) receives an MCData communication session termination message from the controlling MCData server (100b). In step 706, in response to receiving the MCData communication session termination message from the controlling MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes a termination indication indicating successful termination of MCData communication within a pre-established session. In step 707, the participating MCData server (200) receives an acknowledgement message from the originating MCData client device (100a) in response to receiving the MCData communication status. In step 708, the participating MCData server (200) maintains at least one pre-established session with the originating MCData client device (100a).

[0287] According to Sub-clause 9.2.5.4.1.1 : Client originating process of the originating MCData client device (100a): After receiving a request from the MCData user to keep the MCData session within a pre-established session, the originating MCData client device (100a):

[0288] 1) shall interact with the media plane as specified in 3GPP TS 24.582;

[0289] 2) shall generate an initial SIP REFER request outside the dialog according to the procedures specified in 3GPP TS 24.229 updated by IETF RFC 6665 and IETF RFC 7647, IETF RFC4488 and IETF RFC 3515;

[0290] 3) set the Request-URI of the SIP REFER request to the public service identifier that identifies the pre-established session on the participating MCData server (200) serving the MCData user;

[0291] 4) shall include a Refer-Sub header field with the value "false" according to the rules and procedures of IETF RFC 4488;

[0292] 5) shall include a supported header field with the value "norefersub" according to the rules and procedures of IETF RFC 4488;

[0293] 6) set the Refer-To header field of the SIP REFER request to the MCData session identifier to be left;

[0294] 7) In the URI of the Refer-To header field, include a "method" SIP URI parameter with the value "BYE";

[0295] 8) The Target-Dialog header field specified in IETF RFC 4538 shall be included to identify the pre-established session; and

[0296] 9) The SIP REFER request shall be sent in accordance with 3GPP TS 24.229.

[0297] After receiving a SIP 2xx response to the SIP REFER request, the originating MCData client device (100a) shall interact with the media plane as specified in 3GPP TS 24.582.

[0298] Upon receiving a SIP re-INVITE request within the pre-established session targeted by the sent SIP REFER request, the originating MCData client device (100a):

[0299] 1) If in the application / vnd.3gpp.mcdata-info+xml MIME body of the SIP INVITE request <mcdata-communication-state>The element is set to the value "terminated":

[0300] i) Notify the MCData user of the successful termination of MCData communication;

[0301] According to Sub-clause 9.2.5.4.2.1 : Participate in the origination process of the MCData server (200): Upon receiving a SIP REFER request, where the SIP REFER request has a "method" SIP URI parameter with a value of "BYE" in the URI in the "Refer-To" header field from the MCData client, the participating MCData server (200):

[0302] 1) The MCData ID of the calling user shall be determined based on the public user identity in the P-Asserted-Identity header field of the SIP REFER request;

[0303] 2) If the participating MCData server (200) cannot find the binding between the public user identities, the participating MCData server (200) shall reject the SIP REFER request with a SIP 404 (Not Found) response, and the SIP 404 (Not Found) response has a warning text set to "141 user unknown to the participating function" in the warning header field, as specified in sub-clause 4.9, and shall not continue to execute any remaining steps;

[0304] 3) If the SIP REFER request contains a Refer-Sub header field with a value of "false" and a Supported header field with a value of "norefersub", the SIP REFER request shall be processed as specified in 3GPP TS 24.229, IETF RFC 3515 updated by IETF RFC 6665, and IETF RFC 4488 without establishing an implicit subscription;

[0305] 4) A SIP 200 (OK) response to the SIP REFER request shall be generated, and in the SIP 200 (OK) response:

[0306] a) According to the rules and procedures of IETF RFC 4488, a Supported header field with a value of "norefersub" shall be included; and

[0307] b) The presence of the Refer-Sub header field in the SIP REFER request shall be checked. If present and set to the value "false", the Refer-Sub header field with the value "false" shall be included according to the rules and procedures of IETF RFC 4488;

[0308] 5) A SIP 200 (OK) response to the SIP REFER request shall be sent to the MCData client according to 3GPP TS 24.229;

[0309] 6) A SIP BYE request shall be generated and in the SIP BYE request:

[0310] a) The Request-URI shall be set to the MCData session identifier, which is contained in the Refer-To header field of the received REFER request; and

[0311] b) The content of the P-Asserted-Identity header field of the received REFER request shall be copied to the P-Asserted-Identity header field of the output SIP BYE request; and

[0312] 7) The SIP BYE request shall be sent to the controlling MCData server (100b) according to 3GPP TS 24.229.

[0313] After receiving the SIP 200 (OK) response to the SIP BYE, the participating MCData server (200) shall interact with the media plane specified in 3GPP TS 24.582

[15] to release the media plane resources associated with the SIP session of the controlling MCData server (100b). The participating MCData function shall generate a SIP re-INVITE request as specified in subclause 9.2.5.1.2, with the following explanations, and send the request to the originating MCData client according to 3GPP TS 24.229:

[0314] 1) The Request-URI shall be set to the public service identifier that identifies the pre-established session; and

[0315] 2) <mcdata-communication-state>The element is set to the value "terminated".

[0316] Figure 8 It is a sequence diagram showing a method for terminating the initiation of MCData communication by a control MCData server (100b) using a pre - established session according to an embodiment disclosed herein.

[0317] Step 801, establish a pre - established session between the originating MCData client device (100a) and the participating MCData server (200). At step 802, the participating MCData server (200) receives an MCData communication end - request message from the control MCData server (100b) to terminate the MCData communication session with the control MCData server (100b). At step 803, in response to receiving the MCData communication end - request message from the control MCData server (100b), the participating MCData server (200) sends an MCData communication status message to the originating MCData client device (100a), where the MCData communication status message includes a termination - request indication indicating that the request will terminate the MCData communication within the pre - established session.

[0318] At step 804, the participating MCData server (200) receives an acknowledgement message from the originating MCData client device (100a) in response to the MCData communication status. At step 805, the participating MCData server (200) sends an acknowledgement message to the control MCData server (100b) in response to receiving the acknowledgement message. At step 806, the participating MCData server (200) maintains at least one pre - established session with the originating MCData client device (100a).

[0319] According to Sub-clause 9.2.5.4.1.2 : The client termination process of the originating MCData client device (100a): After receiving a SIP re - INVITE request in a pre - established session without an associated MCData session, the originating MCData client device (100a):

[0320] 1) If in the application / vnd.3gpp.mcdata - info+xml MIME body of the SIP INVITE request <mcdata-communication-state>The element is set to the value "terminate - request":

[0321] i) According to 3GPP TS 24.229, a SIP 200 (OK) response shall be sent to the participating MCData server (200); and

[0322] ii) All media plane resources corresponding to the MCData communication being released shall be released.

[0323] According to Sub-clause 9.2.5.4.2.2 : The termination process of the participating MCData server (200): After receiving a SIP BYE request from the control MCData server (100b), the participating MCData server (200):

[0324] 1) Shall interact with the media plane as specified in 3GPP TS 24.582;

[0325] 2) Shall send a SIP 200 (OK) response to the control MCData server (100b);

[0326] 3) As Sub-clause 9.2.5.1.2 specified, a SIP re - invite request shall be generated and described as follows:

[0327] i) The Request - URI shall be set to the public service identifier that identifies the pre - established session; and

[0328] ii) The <mcdata-communication-state>The element is set to the value "terminate-request";

[0329] 4) A SIP re-INVITE request shall be sent to the originating MCData client device (100a) according to 3GPP TS 24.229; and

[0330] 4) After receiving a SIP 2xx response to the SIP re-INVITE, interaction with the media plane shall be performed as specified in 3GPP TS 24.582.

[0331] The embodiments disclosed herein can be implemented using at least one software program that runs on at least one hardware device and performs network management functions to control components.

[0332] The foregoing description of specific embodiments will so fully disclose the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt various applications of such specific embodiments without departing from the general concept, and, therefore, such adaptations and modifications are intended to be and are to be understood as being within the meaning and range of the equivalent forms 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, although the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that modifications may be made to practice the embodiments herein within the spirit and scope of the embodiments as described herein. < / entry> < / entry> < / entry> < / entry> < / entry> < / entry> < / uri> < / entry> < / entry> < / entry> < / entry> < / entry> < / entry> < / anyext> < / mcdatainfo> < / anyext> < / mcdatainfo>

Claims

1. A method performed by a mission-critical data (MCData) server involved, the method comprising: Receiving, from an originating MCData client device, at least one Session Initiation Protocol (SIP) invitation request message, wherein the SIP invitation request message includes a pre-established session indication indicating to the involved MCData server about initiating at least one pre-established session; Based on the pre-established session indication, initiating at least one pre-established session with the originating MCData client device; Generating a re-invitation request message, the re-invitation request message including information associated with the MCData communication status within the at least one pre-established session; and Sending the re-invitation request message including the information to the originating MCData client device.

2. The method according to claim 1, further comprising: Before generating the re-invitation request message, receiving from a control MCData server one of: an MCData communication session establishment success message, an MCData communication session failure message, and an MCData communication session rejection message.

3. The method according to claim 2, further comprising: Receiving, from the originating MCData client device, an acknowledgement message in response to the re-invitation request message, wherein, in the case of the MCData communication session establishment success message, the information associated with the MCData communication status includes an establishment success indication indicating that MCData communication is successfully established within the pre-established session, and wherein, in the case of the MCData communication session failure message or the MCData communication session rejection message, the information associated with the MCData communication status includes an establishment failure indication indicating that MCData communication is not successfully established within the pre-established session.

4. The method according to claim 1, Among them, wherein the information associated with the MCData communication status includes a termination indication indicating termination of MCData communication within the pre-established session.

5. The method according to claim 1, Among them, in the case of receiving the SIP invitation request message, the information associated with the MCData communication status includes an establishment request indication requesting to establish MCData communication within the pre-established session.

6. The method according to claim 1, Among them, wherein the information associated with the MCData communication status includes a termination request indication for terminating MCData communication within the pre-established session.

7. A mission-critical data (MCData) server involved, the involved MCData server comprising: A memory; and A processor coupled to the memory and configured to: Receive, from an originating MCData client device, at least one Session Initiation Protocol (SIP) invitation request message, wherein the SIP invitation request message includes a pre-established session indication indicating to the involved MCData server about initiating at least one pre-established session, Initiate at least one pre - established session with the originating MCData client device based on the pre - established session indication, generate a re - invitation request message, the re - invitation request message including information associated with the MCData communication status within the at least one pre - established session, and send the re - invitation request message including the information to the originating MCData client device.

8. The participating MCData server according to claim 7, wherein, The processor is further configured to: Before generating the re - invitation request message, receive one of the following from the control MCData server: an MCData communication session establishment success message, an MCData communication session failure message, and an MCData communication session rejection message.

9. The participating MCData server as claimed in claim 8, wherein, The processor is further configured to: Receive an acknowledgement message in response to the re - invitation request message from the originating MCData client device, wherein, in the case of the MCData communication session establishment success message, the information associated with the MCData communication status includes an establishment success indication indicating that MCData communication has been successfully established within the pre - established session, and wherein, in the case of the MCData communication session failure message or the MCData communication session rejection message, the information associated with the MCData communication status includes an establishment failure indication indicating that MCData communication has not been successfully established within the pre - established session.

10. The participating MCData server according to claim 7, wherein The information associated with the MCData communication status includes a termination indication indicating the termination of MCData communication within the pre - established session.

11. The participating MCData server as claimed in claim 7, wherein, In the case of receiving a SIP invitation request message, the information associated with the MCData communication status includes an establishment request indication requesting the establishment of MCData communication within the pre - established session.

12. The participating MCData server according to claim 7, wherein, The information associated with the MCData communication status includes a termination request indication for terminating MCData communication within the pre - established session.

Images