Method, user equipment, and system for opening an ad-hoc PoC session in a PoC system

PRIORITY

0001This application claims priority under 35 U.S.C. § 119 to an application entitled “Method, User Equipment, and System for Opening an ad-hoc PoC Session in a PoC System” filed in the Korean Intellectual Property Office on Nov. 23, 2005 and assigned Serial No. 2005-112557 and filed Nov. 22, 2006 and assigned Serial No. 2006-115693, the contents of both of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

00021. Field of the Invention

0003The present invention relates generally to a method, user equipment, and system for opening an ad-hoc Push-To-Talk (PTT) over Cellular (PoC) session in a PoC system, and more particularly to a method, user equipment, and system that can open an ad-hoc PoC session for a call target group whose group Identifier (ID) is managed in a remote network domain when the ad-hoc PoC session is opened.

00042. Description of the Related Art

0005With the significant development of mobile communication and extension of communication networks, various extended services and applications using mobile phones are being provided. Due to user demands, services beyond the basic call service such as positioning, multimedia and Push-To-Talk (PTT) services, are being provided. Specifically, the PTT service supports various additional functions such as instant messenger and state display, as well as a group call and a voice call that are possible in a conventional radio system or a Trunked Radio System (TRS).

0006A concept of this PTT service is being actively discussed to standardize a PTT over Cellular (PoC) service using a mobile communication network. One characteristic that distinguishes the PoC service from the conventional mobile communication service is that users can perform communication while moving between multiple sessions as needed. The requirement that users should be able to perform communication while moving between multiple sessions is prescribed in the standard of the Open Mobile Alliance (OMA) serving as an organization for developing a standard for a mobile communication service.

0007This OMA PoC technology exploits a Session Initiation Protocol (SIP)/SIP extension protocol corresponding to a typical application layer protocol for controlling Internet Protocol (IP) multimedia telephony in order to deliver session participation information of a group call and exploits an Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for managing group information.

0008A PoC spec currently being standardized by the OMA includes a PoC service that supports a multiparty conference function of a half-duplex communication scheme and supports various types according to purpose of a group. That is, PoC conferences are classified into ad-hoc, prearranged and chat PoC groups according to characteristics of a participating group.

0009An ad-hoc group call and a prearranged group call open a dial-out session by a client sending a session open request to a server acting as a focus (hereinafter conference server) and the conference server sends a session request to respective clients belonging to a group.

0010A chat group call has characteristics of a session open and join procedure in which clients have dial-in access to a conference server of a chat group when they recognize in advance associated session identification information or group session information provided through group advertising.

0011To open a PoC multimedia session, a PoC call requester at a transmitting side makes a request for processing a call by sending a multimedia INVITE message using the SIP. At this time, the multimedia INVITE message can include various formats of audio, video, text, and so on according to media types. A receiving side performs various answer procedures according to presence of a prearranged session and answer mode setting.

0012To process a PoC call, a PoC Client A at the transmitting side sends an SIP INVITE message containing SIP address information of a target receiver to an associated SIP/IP core network A. The SIP INVITE message contains elements of PoC address information of the client sending a call request, required media parameters, and characteristic value information indicating the PoC service. The SIP INVITE message is delivered to a Participating PoC server (or Participating PoC Function (PF) entity) through an associated IP Multimedia Subsystem (IMS) server (of a Proxy-Call Session Control Function (P-CSCF) and Serving-Call Session Control Function (S-CSCF)) using a path query in a Dynamic Host Configuration Protocol (DHCP) server or Domain Name Server (DNS). When a multimedia session is requested, the required media parameters include a plurality of characteristic values indicative of parameters such as an audio and video encoding method, rate and payload type.

0013When a basic call request is made, the PF entity connected to a PoC user can be implemented which is separated from the controlling PoC server (or Controlling PoC Function (CF) entity) for managing a talk burst of an opened session. The SIP INVITE message sent to the PF entity is transferred to the CF entity through the associated SIP/IP core network.

0014A PoC session control network with the CF receives a response message from a network at the receiving side after transferring an SIP INVITE message to the network at the receiving side. The SIP response message from the network at the receiving side can be a provisional response message of 1XX, a successful response message of 2XX, or an error response message of 4XX˜6XX according to setting of the PF and the PoC client at the receiving side. In the case of the automatic answer mode, an SIP <b>183</b> “session progress” signal can be received, through which a connection between the PoC server and client can be established in the IMS network of a call requester. A call acknowledgment signal of the PoC client at the receiving side is returned as an SIP <b>183</b> “session progress” signal or an SIP <b>200</b> “OK” response, and is transferred to the PoC client A through the PoC server of the CF and PF.

0015After receiving the SIP <b>200</b> “OK” response or the SIP <b>183</b> “session progress” signal from the PoC server at the receiving side, the CF entity determines that a PoC call has been connected and sends a floor granted signal for assigning the floor for a talk burst to the PoC client A. The response of the SIP <b>200</b> “OK” or <b>183</b> “session progress” signal can be classified as a “confirmed” or “unconfirmed” response. The CF entity requires a buffering function when the “unconfirmed” response is received.

0016The PoC client A at the transmitting side receives a talk burst transmission granted signal, for example, a floor granted signal for transferring call connection sound, through a Real Time Control Protocol (RTCP) after receiving the response signal to the SIP INVITE message. The floor granted signal is generated from the CF entity having the right to arbitrate a talk burst and is sent to the PoC client through the PF entity for managing an associated PoC client. Since the floor granted signal uses a bearer path without the SIP, it can be sent without passing through the SIP/IP core network such as the IMS. When identifying the call connection sound, the PoC user sends a media stream (or a typical voice stream) using a Real-time Transport Protocol (RTP).

0017As defined in the PoC 1.0 standard document, an ad-hoc PoC group session can be opened according to edition of the PoC client at the transmitting side. At this time, target PoC address information mapped to an ad-hoc group is constructed with a single SIP or TEL Uniform Resource Identifier (URI). According to function for opening a flexible ad-hoc group session newly defined in the PoC 2.0 standard, a call target group can have a group URI rather than a single URI.

0018For this, the PoC client at the transmitting side can open the flexible ad-hoc group session by including a group type indicator for the group URI in a message to be sent to open the ad-hoc PoC group session and performing a session procedure. In this case, when a call target group URI is managed in a domain equal to that of a PoC server operating as the CF entity in an ad-hoc session, an ad-hoc group session management server can open the ad-hoc group session by receiving information of clients mapped to an associated group identifier from a PoC XML Document Management Server (XDMS).

0019However, when the call target group URI is not managed in a domain (hereinafter a home network domain) equal to that of the PoC server operating as the CF entity in the ad-hoc session, the ad-hoc group session management server cannot receive client information mapped to an associated group from a PoC XDMS within a different domain. That is, the ad-hoc group session management server should send a session invitation to associated clients by directly collecting a list of clients belonging to a remote network other than the home network. Conventionally, a method for efficiently opening a flexible ad-hoc group session is not provided for when a call target group identifier used to open an ad-hoc session is not managed in a PoC server within a home network domain or a connected PoC XDMS.

SUMMARY OF THE INVENTION

0020It is, therefore, an object of the present invention to provide a method, user equipment, and system for opening an ad-hoc PoC session in a PoC system that can acquire a client list mapped to a group URI from an associated network if the client list mapped to a target URI of the ad-hoc group is not managed in a PoC server within a home network domain when a PoC ad-hoc group session is opened.

0021It is another object of the present invention to provide a method, user equipment, and system for opening an ad-hoc PoC session in a PoC system that can receive associated group information from a PoC server for managing an ad-hoc group session if a group URI is managed in a network domain different from that of a group session initiator when the PoC ad-hoc group session including single and group URIs is opened.

0022In accordance with the present invention, there is provided a method for opening an ad-hoc PoC session in a PoC system, including sending a session INVITE message from a PoC client requesting session initiation to a first PoC server of a home network, the session INVITE message including information of at least one group identifier, checking the group identifier information within the session INVITE message received by the first PoC server and sending a group list information request message to a second PoC server hosting a group identifier when there exists identifier information of a group of a network other than the home network, and acquiring list information about a group included in the group list information request message and sending the acquired group list information to the first PoC server.

0023In accordance with the present invention, there is provided a system for opening an ad-hoc PoC session in a PoC system, including a PoC client for requesting session initiation and sending a session INVITE message including information of at least one group identifier, a first PoC server for checking the group identifier information within the session INVITE message received from the PoC client and sending a group list information request message to an associated server hosting a group identifier when there exists identifier information of a group of a network other than a home network, and a second PoC server for receiving the group list information request message from the first PoC server, acquiring list information about a group included in the group list information request message, and sending the acquired group list information to the first PoC server.

0024In accordance with the present invention, there is provided a user equipment for opening an ad-hoc PoC session in a PoC system, including a data transceiver for transmitting packet data to and receiving packet data from a PoC server, and a controller for transmitting a session INVITE message including at least one URI and a group identifier for opening a PoC ad-hoc group session.

BRIEF DESCRIPTION OF THE DRAWINGS

0025The above and other objects and aspects of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

0026<figref idref="DRAWINGS">FIG. 1</figref> illustrates a structure of a conventional PoC service system and an associated network structure;

0027<figref idref="DRAWINGS">FIG. 2</figref> illustrates a structure of a conventional PoC server;

0028<figref idref="DRAWINGS">FIG. 3</figref> illustrates a controlling PoC function block and a participating PoC function block of a PoC server in accordance with the present invention;

0029<figref idref="DRAWINGS">FIG. 4</figref> illustrates internal structures of a PoC UE and an ad-hoc PoC group server for opening an ad-hoc PoC session including a plurality of single and group URIs in accordance with the present invention;

0030<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating a process for opening the ad-hoc PoC session including the plurality of single or group URIs in the ad-hoc PoC group server in accordance with the present invention;

0031<figref idref="DRAWINGS">FIG. 6</figref> is a signal flow diagram illustrating a process for opening an ad-hoc PoC session in an originating PoC network in accordance with the present invention;

0032<figref idref="DRAWINGS">FIG. 7</figref> is a signal flow diagram illustrating a process for opening an ad-hoc PoC session in a terminating PoC network in accordance with the present invention;

0033<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example of the format of an SIP INVITE message for opening the ad-hoc PoC session in <figref idref="DRAWINGS">FIG. 6</figref>;

0034<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example of the format of an SIP INVITE message for opening the ad-hoc PoC session in <figref idref="DRAWINGS">FIG. 7</figref>; and

0035<figref idref="DRAWINGS">FIG. 10</figref> illustrates an example of the format of a message for sending a group list mapped to an associated group URI to a home network in <figref idref="DRAWINGS">FIG. 7</figref>.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0036Preferred embodiments of the present invention will be described in detail herein below with reference to the accompanying drawings. In the following, there will be described an example in which the present invention is applied to a PoC system for a PTT service using a cellular mobile communication network among PTT systems. Conventionally, the PoC system exploits a conventional SIP or extension SIP corresponding to a typical application layer protocol for controlling IP multimedia telephony in order to deliver session participation information of a group call and exploits an Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for acquiring group information. Functions of the present invention as described below can be implemented by the above-described protocols.

0037<figref idref="DRAWINGS">FIG. 1</figref> is a conceptual diagram illustrating a conventional PoC service system and an associated network structure, to which the present invention is applied. Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a PoC client <b>11</b> is a service requester embedded in a PoC UE <b>10</b>. The PoC client <b>11</b> is connected to an SIP/IP core network <b>30</b> serving as a core network for supporting SIP and IP multimedia through an access network <b>20</b>. The PoC client <b>11</b> can access a PoC service while residing in the PoC UE <b>10</b>. The PoC client <b>11</b> functions to generate, participating in or end a PoC session. Also, the PoC client creates, processes and transfers a media burst, supports an instant personal alert, authenticates a connection to the PoC service and subscribes to presence information, among other functions.

0038To support the PoC service, the SIP/IP core network <b>30</b> is connected to a PoC server <b>60</b>, a PoC XDMS <b>50</b> and a PoC XDMS <b>70</b>. The PoC server <b>60</b> can perform a controlling PoC function (CF) for maintaining and managing a PoC session or a participating PoC function (PF) for supporting the PoC client desiring to participate in a PoC session opened in a different network domain.

0039The PoC service can be accompanied with a service for opening a group session as in a conference call. For this, the OMA standard defines an XML Document Management Client (XDMC) and an XDMS for a group list service. In <figref idref="DRAWINGS">FIG. 1</figref>, the XDMC residing within the PoC UE <b>10</b> is an XDMC <b>12</b>. The XDMS can be classified into the PoC XDMS <b>50</b> corresponding to a particular server for the PoC service and a shared XDMS <b>40</b> commonly available in other service enablers. When a group list-related request is received from the XDMC <b>12</b>, an aggregation proxy server <b>90</b> routes the received request to each XDMS according to proper rule.

0040<figref idref="DRAWINGS">FIG. 2</figref> illustrates a conventional PoC server. Functions of the PoC server are divided into a CF for maintaining and managing the overall PoC session and a PF responsible for maintenance and management between sessions. These functions will be described with reference to Tables 1 and 2. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Controlling PoC Function (CF)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row><entry /><entry>Provides centralized PoC session handling</entry></row><row><entry /><entry>Provides the centralized Media distribution</entry></row><row><entry /><entry>Provides the centralized Talk Burst Arbitration functionality</entry></row><row><entry /><entry>including talker identification</entry></row><row><entry /><entry>Provides SIP session handling, such as SIP session origination,</entry></row><row><entry /><entry>termination, etc</entry></row><row><entry /><entry>Provides policy enforcement for participation in group sessions</entry></row><row><entry /><entry>Provides the participants information</entry></row><row><entry /><entry>Collects and provides centralized media quality information</entry></row><row><entry /><entry>Provides centralized charging reports</entry></row><row><entry /><entry>May Provide transcoding between different codecs</entry></row><row><entry /><entry>Support Talk Burst Control Protocol Negotiation</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0041Referring to Table 1, the CF performs, among functions of the PoC server, a function that serves to manage the overall PoC sessions, particularly to receive, sequence and authorize the right-to-speak (or floor) requests of the PoC clients, to distribute a talk burst requested by an arbitrary PoC client to all the other PoC clients participating in group calling, and to provide information of the PoC clients participating in the group calling.

0042Referring to Table 2 below, the PF serves to manage the sessions that are linked with the CF and the respective PoC clients in the PoC session. In particular, the PF serves to relay the right-to-speak when the PoC client requests the right-to-speak or when the right-to-speak is assigned to the PoC client in the CF. Moreover, the PF serves to relay media between the CF and the PoC client, to perform transcoding when different codecs are used between the CF and the PoC client, and to filter any one of two simultaneous sessions in response to the PoC client's selection when the PoC client participates in one session while participating in the other session. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 2</entry></row><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Participating PoC Function (PF)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>Provides PoC session handling</entry></row><row><entry>May provide the Media relay function between PoC</entry></row><row><entry>Client and Controlling PoC server</entry></row><row><entry>May provide user media adaptation procedures</entry></row><row><entry>May provide the Talk Burst control message relay function</entry></row><row><entry>PoC Client and Controlling PoC server</entry></row><row><entry>Provides SIP session handling, such as SIP session origination,</entry></row><row><entry>termination, etc, on behalf of the represented PoC Client</entry></row><row><entry>Provides policy enforcement for incoming PoC session (e.g.,</entry></row><row><entry>access control, incoming PoC session barring, availability status, etc)</entry></row><row><entry>May collect and provide media quality information</entry></row><row><entry>Provides the participant charging reports</entry></row><row><entry>May provide filtering of the media streams in the case of simultaneous</entry></row><row><entry>sessions</entry></row><row><entry>May provide transcoding between different codecs</entry></row><row><entry>May support Talk Burst Control Protocol Negotiation</entry></row><row><entry>Stores the current Answer Mode and Incoming PoC Session</entry></row><row><entry>Barring preferences of the PoC Client</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0043In the PoC system configured as described above, a PoC user can input information about a group and group members to the PoC XDMS <b>50</b> through its own UE and can learn information about PoC users capable of being called thereby through an individual or group list received from the PoC XDMS <b>50</b>. In another method capable of generating, correcting and managing a group and group members in the PoC XDMS <b>50</b>, information can be input through the XDMC implemented in a reliable communication network such as the Internet and an Intranet.

0044To use a PoC call service, a PoC user registers his/her own PoC address in the SIP/IP core network, which stores information about the PoC user in response to a request. Thus, when another PoC user attempts a PoC group call, his/her own information is first registered in the SIP/IP network and a call request is sent to the SIP/IP core network using group identification information received from the PoC XDMS <b>50</b>. Then, the SIP/IP core network transfers the PoC call request to a home PoC server in which the PoC user making the call request is registered after address and domain position decision processes using information of the PoC user making the call request. The PoC server prepares to open a PoC session in response to the PoC call request, and transfers a call request signal to an associated SIP/IP core network after acquiring user information from the PoC XDMS. In the case of the call request for users within an intra-domain, the PoC server performs both the PF and CF. The PoC server for managing a PoC user for receiving the call request sends the call request to the associated PoC user after a position decision process of the SIP/IP core network using its own received PoC user information.

0045<figref idref="DRAWINGS">FIG. 3</figref> illustrates a CF block and a PF block of the PoC server. Referring to <figref idref="DRAWINGS">FIG. 3</figref>, PoC clients <b>111</b>, <b>121</b>, <b>131</b>, and <b>141</b> access a CF <b>100</b> through PFs <b>110</b>, <b>120</b>, <b>130</b>, and <b>140</b> to set up a PoC session. For PoC clients having the floor assigned by the CF <b>100</b> to speak, media are provided to the respective PoC clients. At this time, the PoC client having the floor can speak after identifying information of participants in a group session.

0046The call processing technology for a call connection in the PoC system can perform various procedures according to requests and situations of transmitting and receiving sides. Characteristics of the PoC system required by the OMA according to settings of the transmitting and receiving sides are as follows.

0047First, the receiving side can set its own answer mode according to the PoC user's request. The answer mode can be divided into automatic and manual answer modes. In the automatic answer mode, a receiver immediately sends the answer from an associated network to the transmitting side instead of the manual answer when an associated PoC client is included in a PoC client list designated by the receiving side. The network can automatically send the answer in place of the UE because the PoC server has a function for performing the answer mode and storing an associated user list according to an answer-mode setting request of the UE. The manual answer mode operates when an associated user is unclear or is not included in a user list relative to the automatic answer mode, or when the receiver sets the manual answer mode for all users. A PoC call request is sent to the user's UE through a receiving network and a call connection is established by permission of the PoC user.

0048Second, the PoC system classifies session modes into on-demand and pre-established session modes according to connection setup with the PoC server within a home network of a user. The pre-established session mode is technology for pre-establishing a session between the PoC client and the PoC server belonging to the home network thereof in response to the PoC user's request. This pre-established session is necessary to quickly open a session when the PoC user pre-negotiates media parameters to be later used with the PoC server without re-negotiating the media parameters with the PoC server. For the pre-established session, the PoC client provides supportable media parameters to a body, i.e., a Session Description Protocol Multipurpose Internet Mail Extensions (SDP MIME) body, in an SIP INVITE method, and provides and responds to media parameters received from the server. A response message from the server includes identification information of a newly pre-established session and a conference URI and is returned to the PoC user. When the above-described pre-established session is used, pre-negotiation can be performed for an IP address, a port number, a codec to be used and a talk burst control protocol, among other parameters. The on-demand session mode indicates a state in which PoC users do not set up a pre-established session. In the on-demand session mode, a PoC call connection procedure is performed after receiving an INVITE message from another PoC user.

0049The answer mode set for a call request in the PoC system can be stored in both the PoC server serving as the network element and the PoC client serving as the user's UE. When the answer mode is set in the home network for managing the PoC client, it is implemented in the PoC server for performing the PF within the home network to which the PoC client belongs. When the answer mode is set in the network, the PF immediately and automatically sends a response of a session progress message to a call request network when a PoC call request is received from a different PoC server. Thus, if the automatic answer mode is set, it has a simpler call request procedure than when a response is made after a session setup message is transferred to the PoC client. Thus, an initial floor assignment time is reduced. Because a result different from the user's response intention can occur according to when the automatic answer is made in the network, the answer mode can also be set in the PoC client. At this time, a priority of the answer mode of the PoC client is higher than that of the answer mode set in the network. This is to address a privacy problem when the answer mode is not reflected in real time due to a signal delay or error in a radio access network or IP core network if the PoC client changes its own answer mode and sends an answer mode update request to the PoC server. The PoC service can set the answer mode of the user in both the PoC server and client. The answer mode is decided by the PoC client considering the most recent intention of the user. According to this decision, a media stream (of actual voice or video of the user) can be transferred.

0050The basic structure of the present invention is provided with the conventional PoC system, i.e., a UE with a PoC client function, a PoC server for managing multiple sessions, and sub networks (e.g., an SIP/IP core network and a radio access network) for connecting both ends thereof

0051<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating the PoC UE <b>10</b> and the PoC server <b>60</b> in accordance with the present invention.

0052As illustrated in <figref idref="DRAWINGS">FIG. 4</figref>, the system of the present invention is provided with the PoC UE <b>10</b>, the PoC server <b>60</b> and an SIP/IP core network <b>30</b>. In accordance with the present invention, the PoC server <b>60</b> can perform the CF or PF according to possession of a group session. However, the present invention considers only the CF because an ad-hoc session is opened in response to a request of a session initiator. The CF entity for opening the ad-hoc session can perform the PF for an actual session initiation client.

0053The PoC server <b>60</b> is provided with a data transceiver <b>420</b>, a PoC session controller <b>430</b> and a PF composer <b>440</b>.

0054In the PoC server <b>60</b>, the data transceiver <b>420</b> can include transport protocol stacks for transmitting and receiving packet data. The data transceiver <b>420</b> can include a Real-time Transport Protocol/Real Time Control Protocol/File Transfer Protocol (RTP/RTCP/FTP) stack, User Datagram Protocol/Transport Control Protocol (UDP/TCP) stack, IP stack and lower layer stack.

0055When receiving an ad-hoc session open request from the PoC client, the PoC session controller (or simultaneous session controller) <b>430</b> sends a group list information request to a PoC XDMS within its network domain or an XDMS within a remote network domain according to associated group URI.

0056The PF composer <b>440</b> serves as the component used to support and manage multiple sessions. This PF composer <b>440</b> transfers media data received through the multiple sessions <b>451</b>, <b>452</b>, and <b>453</b>, to the simultaneous session controller <b>430</b>.

0057The PoC server <b>60</b> is connected to the PoC client <b>102</b> through the SIP/IP core network <b>30</b> for supporting SIP based communication.

0058The PoC UE <b>10</b> is configured with the PoC client <b>102</b>, a display unit <b>400</b>, a controller <b>402</b>, a user interface <b>404</b> and a data transceiver <b>410</b>.

0059The PoC client <b>102</b> selects groups through an SIP message and sends an ad-hoc session request to the PF composer <b>440</b>. Further, the PoC client <b>102</b> uses a PoC service while controlling the controller <b>402</b> and controls multimedia supporting the SIP. The display unit <b>400</b> outputs visual media such as an image and video received from the PoC server <b>60</b>. The controller <b>402</b> processes data to output received data to the display unit <b>400</b>. The user interface <b>404</b> transfers a user's input to the PoC UE <b>10</b>. In particular, a function is required which can select groups and request an ad-hoc session through the user interface <b>404</b>. The data transceiver <b>410</b> can include transport protocol stacks for transmitting and receiving packet data. The data transceiver <b>410</b> can include a RTP/RTCP/FTP stack, UDP/TCP stack, IP stack and lower layer stack.

0060The present invention pertains to technology for opening an ad-hoc PoC session for a call target group including a plurality of individual PoC users and at least one PoC group when a conference session for an OMA PoC group call service is opened. In particular, the present invention provides a method capable of opening a general PoC group session such that a group ID mapped to a call target group is not limited to a home network domain of a PoC server for opening an ad-hoc session.

0061Further, the present invention provides a method for opening an ad-hoc PoC session in a PoC system in which a PoC server for managing an ad-hoc group session can receive associated group information when a group URI is managed in a network domain different from that of a group session initiator when a PoC ad-hoc group session including a plurality of single and group URIs is opened. For this, the present invention proposes the following four methods.

0062First, there is provided a method for acquiring a group list by determining whether a target group URI is included in a home network when an ad-hoc group session including a plurality of single and group URIs is requested.

0063Second, there are provided a method and procedure for acquiring a group list from a PoC XDMS of an associated domain using the SIP technology when a group URI belongs to a remote network domain.

0064Third, there is provided a method for notifying that a CF server of an ad-hoc session is located in a network at a transmitting side and a session for an associated group URI is opened in a remote network when client list information is acquired from the remote network.

0065Fourth, there are provided a method and procedure for performing a connection to a prearranged ad-hoc session when a session open request is sent to an associated server since conference information and information about a server for opening the ad-hoc session are stored and managed in a server of a remote network.

0066An ad-hoc session including a general group URI accommodates a function of the conventional PoC system using a basic procedure. However, there is a problem in that the PoC server for performing the CF cannot directly acquire group list information from a PoC XDMS belonging to a remote network domain. The present invention is a technical solution for addressing such a problem.

0067<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating a process for opening an ad-hoc PoC session including a plurality of single and group URIs in an ad-hoc PoC group server in accordance with the present invention. In <figref idref="DRAWINGS">FIG. 5</figref>, the PoC server performs both the CF and PF because it opens an ad-hoc session.

0068First, when receiving a session INVITE message in step <b>500</b>, the PoC server proceeds to step <b>502</b> to determine whether URI information contained in the received session INVITE message is a single or group URI.

0069If the URI information is the single URL as a determination result, the PoC server proceeds to step <b>504</b> to send a general session INVITE message to an associated client. However, if the URI information is the group URL as the determination result, the PoC server proceeds to step <b>506</b> to determine whether the associated group URI is recognized in a home network.

0070If the group URI is not recognized in the home network as a determination result in step <b>506</b>, the PoC server proceeds to step <b>514</b> to send a group list information request to a PoC XDMS of the home network and receive a response. When the list information response fails in step <b>516</b>, the PoC server proceeds to step <b>518</b> to transfer a session INVITE message containing an associated group URI and CF notification to the SIP/IP core network. In step <b>516</b>, an associated PoC server receiving the session INVITE message acquires a group list mapped to the group URI from a PoC XDMS connected to its network domain. When acquiring the group list mapped to the group URI, the associated PoC server sends the group list to the CF entity in step <b>520</b>.

0071After receiving the group list information from the network domain in which the associated group URI is managed in step <b>520</b>, the PoC server proceeds to step <b>512</b> to make an ad-hoc group invitation using the received group list.

0072If the group URI is recognized in the home network as the determination result in step <b>506</b>, the PoC server proceeds to step <b>508</b> to determine whether the group URI is managed in the home network.

0073If the group URI is managed in the home network, the PoC server sends a group list request to the XDMS within a home network domain mapped to its network and receives a response in step <b>510</b>. Then, the PoC server proceeds to step <b>512</b> to make a group invitation according to acquired group list information.

0074If the group URI is not managed in the home network as a determination result in step <b>508</b>, the PoC server proceeds to step <b>518</b> to transfer a session INVITE message containing an associated group URI and CF notification to the SIP/IP core network. After the group list information is received in a network domain in which the associated group URI is managed in step <b>520</b>, an ad hoc group invitation is created.

0075In steps <b>506</b> and <b>508</b>, the PoC server can determine whether the group URI is recognized and managed in the home network using a format and domain name of the associated URI. Because the determination as to whether the group URI is managed using the URI format is not directly related to the present invention, its detailed description is omitted.

0076In the above-described process, the PoC server (CF<b>1</b>) can send a request for member list information mapped to the group URI to the PoC XDMS for managing a PoC group list of the home PoC network. However, if group list information is not acquired because the group URI belongs to a remote network domain, a session INVITE message containing the associated group URI is forwarded to the SIP/IP core network. The session INVITE message is sent to the PoC server (CF<b>2</b>) for hosting the group URI through the SIP/IP core network of the remote network.

0077Then, the PoC server (CF<b>2</b>) within the remote network requests list information mapped to the group URI through the PoC XDMS belonging to the associated network.

0078The PoC server (CF<b>2</b>) determines that it does not serve as the CF entity for a session through an “isfocus” option tag contained in the received session INVITE message and then returns the requested group list information to the PoC server (CF<b>1</b>) through a redirect message.

0079Upon receiving the group list information, the PoC server (CF<b>1</b>) sends an ad-hoc group session request message to a target client of an ad-hoc group included in the group list information.

0080The PoC server (CF<b>1</b>) includes session initiator information, a conference URI, and a URI type (i.e., an adhoc group) as well as the tag of “isfocus” and an address of the PoC server (CF<b>1</b>) in the session INVITE message and sends the session INVITE message to the PoC server (CF<b>2</b>). Upon receiving the session INVITE message from a PoC client that has already participated in the session, the PoC server (CF<b>2</b>) stores information contained in the session INVITE message and sends the acquired group list information to the PoC server (CF<b>1</b>) such that a requested session can be opened.

0081When receiving a session participation request message from a client belonging to a group list, the PoC server (CF<b>2</b>) redirects, to the associated client, information about the stored address of the PoC server serving as the conference server and the conference URI, such that the session participation request message can be sent to the associated conference server. Further, when receiving the session participation request message from the client belonging to the group list, the PoC server (CF<b>2</b>) immediately forwards a session connection message to the conference server using the stored information such that the client can participate in an ad-hoc group session.

0082<figref idref="DRAWINGS">FIG. 6</figref> illustrates a procedure between a PoC client A at the transmitting side for opening an ad-hoc session, a PoC server A and a PoC XDMS.

0083The PoC client A sends a session INVITE message for opening the ad-hoc session to the PoC server through an SIP/IP core network in steps <b>600</b> and <b>602</b>. The PoC client A sends the session INVITE message containing single and group URIs on the basis of conference establishment using request-contained lists in the SIP according to the conventional Internet Engineering Task Force (IETF) technology. Each group URI can include information of a group type parameter (of session=“1-1”, “prearranged” or “group”) according to setting within a UE.

0084When receiving the session INVITE message, the PoC server A within the home network operates as the CF entity after receiving an ad-hoc group session open request and checks a target URI inserted as a Multipurpose Internet Mail Extensions (MIME) parameter in step <b>604</b>. The PoC server A checks the group type parameter and determines whether the associated URI is recognized and managed in the home network domain.

0085If the target URI is single URIs as a determination result, the PoC server sends the session INVITE message to clients mapped to the single URIs in steps <b>606</b> and <b>608</b>.

0086If the target URI is a group URI, the PoC server A acquires a group URI list from the XDMS of the home network in step <b>610</b> and makes an ad-hoc group invitation using the group list in steps <b>612</b> to <b>614</b>.

0087However, if the target URI is a group URI incapable of being supported by the home network, the PoC server checks a host of the group URI in step <b>616</b> and sends a session INVITE message to an associated server X in steps <b>618</b> and <b>620</b>. At this time, the sent session INVITE message contains a PoC conference URI generated from the PoC server A and an “isfocus” header value as well as an associated URI in a contact header and further includes address information of the CF A. Herein, the “isfocus” header value indicates the conference server for hosting the ad-hoc session. Further, the session INVITE message can additionally include a URI parameter of “session=adhoc” for indicating a session type in the PoC conference URI. In the session INVITE message, an MIME body can include information of a list of clients included in an ad-hoc group, for example, a single URI and information of a list of clients belonging to a group within a home domain.

0088Then, the PoC server A can reuse an initial session open field value relative to an answer mode requested by the PoC client A and a nickname and address information of a PoC client at the transmitting side when acquiring group list information from a network X at the receiving side and sending the session INVITE message.

0089With reference to <figref idref="DRAWINGS">FIG. 7</figref>, a signal flow for opening an ad-hoc group session will be described when the network X at the receiving side for receiving the session INVITE message sends list information mapped to an associated group URI to the PoC server A as illustrated in <figref idref="DRAWINGS">FIG. 6</figref>.

0090When receiving the session INVITE message routed through the SIP/IP core networks A and X in steps <b>702</b> and <b>704</b>, the PoC server X checks a target URI and parameters included in the session INVITE message in step <b>706</b>. Then, the PoC server X acquires a group list mapped to a PoC group URI corresponding to the target URI included in the session INVITE message from the PoC XDMS within its domain in step <b>708</b>.

0091When receiving the session INVITE message, the PoC server X determines that it is a host server for the group URI. The PoC server X serving as a conference server may generate a conference URI. However, in the present invention, the PoC server X determines that the CF A is the CF for the ad-hoc session when receiving the session INVITE message containing a session type URI parameter included in an “isfocus” option tag or a conference URI. In steps <b>710</b> to <b>713</b>, the PoC server X sends, to the CF A, a redirect message containing the associated group URI list acquired in step <b>708</b>. That is, the PoC server X for hosting a group for receiving the session INVITE message redirects the group list information when determining that it does not serve as the conference server according to reception of the “isfocus” option tag of the contact header within the message.

0092On the other hand, the group URI list can be transmitted in an MIME body of a “<b>302</b> Moved Temporarily” message.

0093After performing steps <b>702</b> to <b>713</b>, the PoC server X can store information about an associated ad-hoc group session and can transfer information for opening an ad-hoc session and inviting a list in a different domain to a client making a request when another session INVITE message for a group URI X is received. At this time, group URI information to be sent to the conference server includes information such as a conference URI of the CF A, an address of the PoC server A and list information of an ad-hoc group session.

0094When receiving a session participation request (or INVITE) message from a client mapped to the group URI in step <b>716</b>, the PoC server X sends a redirect message containing the address information of the PoC server A serving as the conference server and information of an ad-hoc group conference URI stored in step <b>714</b> to the client that has sent the session participation request message. When receiving the redirect message, the client sends the session participation request message to the ad-hoc group conference server using the conference URI information contained in the redirect message in steps <b>720</b> and <b>722</b>. In another method, the PoC server X can participate in an ad-hoc group session by directly forwarding, to the PoC server A, a received INVITE signal in place of the redirect message of step <b>718</b>.

0095After receiving a URI of a group member from the PoC server X, the PoC server A checks the maximum number of allowable ad-hoc group members according to service rule. When the number of ad-hoc group members exceeds the maximum number of allowable ad-hoc group members, the following two procedures can be performed. First, an INVITE message may not be sent to all URIs of an associated group. That is, when sequentially receiving a URI of each group member in relation to multiple group URIs belonging to a different network domain, the INVITE message is sent only for member URIs received within the number of allowable ad-hoc groups. When the number of ad-hoc groups starts to exceed the number of allowable ad-hoc groups, the INVITE message may not be sent to all groups of received group member URIs. Until the number of ad-hoc groups exceeds the number of allowable ad-hoc groups, the INVITE message can be sent for group member URIs in order included in a redirect message.

0096<figref idref="DRAWINGS">FIG. 8</figref> illustrates the format of the session INVITE message in step <b>600</b> of <figref idref="DRAWINGS">FIG. 6</figref>.

0097First, the session INVITE message contains information for indicating a PoC service by inserting “+g.poc.talkburst” into the 9^thline of a header and information for indicating a transmission of an MIME type client list by inserting “Require: recipient-list-invite” into the 13^thline of the header. Also, an MIME body containing single and group URIs as well as a Session Description Protocol (SDP) parameter offer is included and transferred in the session INVITE message. Each URI includes a session type parameter. The single and group URIs are shown on the 8^thto 12^thlines of a list part of the body. In <figref idref="DRAWINGS">FIG. 8</figref>, it is assumed that member lists of SKT and KTF mapped to group URIs can be collected from the XDMS of the home network A and a member list of TMO can be managed in a remote network rather than the home network.

0098When receiving the session INVITE message as illustrated in <figref idref="DRAWINGS">FIG. 8</figref>, the PoC server A checks single and group URI information and sends a session INVITE message for sending a request for group list information about a TMO group incapable of being collected from the home network to an associated network X.

0099<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example of the format of the session INVITE message sent from the PoC server A to the PoC server X in steps <b>700</b> to <b>704</b> of <figref idref="DRAWINGS">FIG. 7</figref>.

0100Request_URI is set to a URI of a “TMO” group in the first line of a header of the session INVITE message and “Contact: sip: conf_uri_a@conf.Samsung.example.com;isfoucus;session=adhoc” is inserted into a contact header of the 8^thline, such that conference URI information, focus information and session type information can be transferred to the PoC server X. Further, client list information capable of being collected from the home network of the PoC server A can be selectively included in a list part of a message body as in the 8^thto 14^thlines thereof. The list information can be transferred which includes list information within the home network, such that participant information of an ad-hoc group can be transferred to clients at a receiving side and therefore participation in the ad-hoc group can be decided.

0101When receiving the session INVITE message as illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, the PoC server X acquires list information mapped to an associated group URI from a PoC XDMS X, and sends a message containing the acquired information to the PoC server A.

0102<figref idref="DRAWINGS">FIG. 10</figref> illustrates an example of the format of the “<b>302</b> Moved Temporarily” message sent in steps <b>710</b>, <b>712</b> and <b>713</b> of <figref idref="DRAWINGS">FIG. 7</figref>. Referring to <figref idref="DRAWINGS">FIG. 10</figref>, the PoC server X redirects, to the PoC server A, the “<b>302</b> Moved Temporarily” message in which list information regarding a group URI “OMA_TMO@example.domain_x.net” is included in the 8^thto 11^thlines of a list part of a message.

0103The present invention can address a problem when a session open request is made by individually inputting ad-hoc group targets after collecting group information in an XCAP or SIP SUBSCRIBE method when an ad-hoc group session including a plurality of groups is opened. In the present invention, a server side can automatically open a session without directly collecting a list of clients belonging to a remote network other than a home network, to enhance user convenience and promote efficient use of network resources.

0104Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions, and substitutions are possible, without departing from the scope of the present invention. Therefore, other possible embodiments and modifications without departing from the principle of the present invention may fall into the protected scope of the present invention.