WO2008063036A1 - System and method for creating routing rules between fleet members - Google Patents

System and method for creating routing rules between fleet members Download PDF

Info

Publication number
WO2008063036A1
WO2008063036A1 PCT/KR2007/005992 KR2007005992W WO2008063036A1 WO 2008063036 A1 WO2008063036 A1 WO 2008063036A1 KR 2007005992 W KR2007005992 W KR 2007005992W WO 2008063036 A1 WO2008063036 A1 WO 2008063036A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
dispatcher
routing rule
fleet
fleet members
session
Prior art date
Application number
PCT/KR2007/005992
Other languages
French (fr)
Inventor
Sang-Kyung Sung
Venkateswar Jeedigunta
Mayuresh Madhukar Patil
Ji-Hye Lee
Original Assignee
Samsung Electronics Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks

Abstract

Disclosed is a system and a method for enabling direct communication between fleet members in a dispatcher session. A system for creating a routing rule between fleet members includes a dispatcher, a plurality of fleet members, and a control server for controlling and managing session establishment between the dispatcher and the fleet members. The dispatcher inserts a routing rule, which contains information regarding fleet members wanting direct communication, to a routing rule setup request message and transmits the message. The control server stores the routing rale when the routing rule setup request message is received, and when media is received from a fleet member participating a dispatcher session, the control server transfers the media to fleet members specified by the stored routing rule of the dispatcher.

Description

SYSTEM AND METHOD FOR CREATING ROUTING RULES BETWEEN FLEET MEMBERS

Technical Field

The present invention relates to the field of mobile communications. This invention is related to dispatcher sessions in the applications like PoC (Push to talk over Cellular) and SIMPLE IM. More specifically this is related to a dispatcher session control mechanism. This invention is also related to SIP technology and RTP protocol.

Background Art

A dispatcher session is basically a pre-arranged group session with one member called as dispatcher who has the control of a session. Here in a dispatcher session there must be at least one member with dispatching capability, and other members are called as fleet members. Currently fleet members cannot talk to each other directly. Dispatcher can talk to any fleet member. Dispatcher has the highest priority in a dispatcher session. Dispatcher can always transfer his dispatcher role to any other dispatcher. Dispatcher related information will be stored in shared XDMS. Dispatcher can change the group properties any time using the XDM operations.

Dispatcher operations in current state of art will now be described. The dispatch session can be initiated by dispatcher, for that dispatcher will send the INVITE request and in INVITE request dispatcher will specify the dispatcher related feature tag to identify it is a dispatch session request, and dispatcher also specify the tag to identify his role as a dispatcher in dispatch session. Following Table 1 shows a basic INVITE request structure, particularly an exemplary INVITE request for establishing a dispatcher session, and "dispatch=entire- group" and "+g.poc.dispatcher" specify the dispatcher-related tags.

Table 1

INVITE Request-URI:<sip:OMA-Highway-Maintenance-

Company@networkX.net

;session=prearranged>; dispatch=entire-group; SIP/2.0 Via: SIP/2.0/TCP networkX.example.net:5060 Max-Forwards: 70

From: POCA <sip:PoC-ClientA@networkX.net>;tag=9fxced76sl To: <siρ: sip:OMA-Highway-Maintenance-Company@networkX.net > P-Preferred-Identity:"PoC User A" <sip:PoC-UserA@networkA.net> Accept-Contact: *;+g.poc.talkburst; require;explicit

User- Agent: PoC-client/OMA2.0 Acme-Talk5000/vl .01 Contact:<sip:PoC-ClientA.networkA.net>;+g.poc.talkburst; +g.poc. dispatcher; Supported: timer

Session-Expires: 1 δOOjrefresher^uac

Allow:

INVITE5ACK5CANCEL5BYE5REFER5MESSAGE5SUBSCRIBE5NOTIF

Y,

PUBLISH5OPTIONS

Priv- Answer-Mode: Auto

Content-Type:application/SDP

Content-Length: ....

c= IN IP6 5555::aaa:bbb:ccc:ddd a= poc-qoe professional m= audio 3456 RTP/AVP 97 a= rtpmap:97 AMR a= rtcρ:5560 a= label: 1 m= video 4567 RTP/AVP 34 a= rtpmap:34 H263/90000 a= rtcp:5570 a= label:2 m= application 2000 udp TBCP a= fmtp :TB CP multimedia= 1 ;queuing= 1 ; tb_priority=2 ; timestamp= 1

SL= floorid:0 mstrm:l 2 As shown in FIG. 1, dispatcher 130 will initiates the dispatch session with specifying the "dispatch^entire-group" tab in Request-URL The dispatcher 130 will also specify his preference of behaving as a dispatcher by including "+g.poc.dispatcher" tag in Contact header field. When controlling server 120 receives this request then controlling server 120 will checks the group policies of that group and validates the INVITE request and after validation dispatcher establish the session by sending the INVITE request to other members 100 and 110 of group. Note Controlling server 120 also include the feature tags related to dispatch session to identify as a dispatch session. Once invite users accepts the INVITE request by sending the 200 OK response, Controlling server 120 sends the 200 OK response to dispatcher 130. This way dispatch session is established. Here in this example PoC User A will act as a dispatcher of the session. Once session is established PoC User A can control dispatch session. In dispatch session other users are called as fleet members. As mentioned in the previously fleet members can not talk to each other directly.

A single group can have multiple dispatchers, but at a time only one dispatcher will be act as a dispatcher and other will act as fleet members. Current state of art also gives flexibility to dispatcher to transfer his dispatching role to other dispatcher of a group. This is achieved using REFER method with following Table 2 shows the SIP header field values in REFER request. So controlling server sends a Re-INVITE to other dispatcher for transferring the dispatching role. Following Table 2 shows exemplary important SIP headers in a REFER request when transferring the dispatching role to other dispatcher, and "Dispatcher Feature Tag with "Require" and "explicit" tag" in the table is related to the dispatcher.

Table 2

SIP Headers of REFER request

Request-URI: PoC Session Identity

REFER-To: Specify PoC Group Identity or SIP URI of User (who is having dispatcher capability in group

Accept-Contact: Dispatcher Feature Tag with "Require" and "explicit" tag Currently, the dispatcher can control various aspects of a dispatcher session and it has the control over the number of ad-hoc sessions between the fleet members. Currently, there is no direct communication between the fleet members. Some times it is beneficial for having the direct communication between the fleet members under the control of a dispatcher. This can be achieved by creating an ad-hoc session between the fleet members as in prior art. This will be a separate session than current dispatcher session, so this requires creation of a different session between the fleet members. This requires CF to maintain the extra session between the fleet members or requires new CF to maintain the ad hoc session. There is one more use case where dispatcher is busy for a particular duration of time. During this time period dispatcher session will be idle. If dispatcher allows the communication among fleet members during this time period then dispatcher session will not remain idle during this period. Currently, there are no solutions available for this.

Disclosure

Technical Problem

Currently if dispatcher wants to enable the communication between the fleet members then he has to allow ad-hoc session between the fleet members. So this requires additional Session initiation procedures. Controlling server needs to maintain the session context for this additional ad-hoc session. The dispatcher may not have total control on the ad-hoc session. If dispatcher make the dispatcher session to normal session, it requires Re-Invite request to be send to all and which requires lot of resources and also dispatcher will not be able to control session and this is very important in dispatch session.

Technical solution

The present invention presents new use cases for having direct communication between the fleet members. FIG. 1 shows dispatcher use case scenario where there is a dispatcher A 130 and there are two groups one is called maintenance group 100 and other one is called crane group 110. The maintenance group members B, C, D, and E and the crane group members F, G, H, and I are working independently. There is a dispatcher session between the two groups 100 and 110 and the dispatcher A 130. The dispatcher A 130 controls a session as he is being dispatcher of the session. The main new use cases can be explained as follows.

As preconditions, User A is a dispatcher, and has dispatcher session. Currently, maintenance group can communicate to dispatcher A 130. Each member communicates to dispatcher A 130.

In addition, currently crane group 110 can communicate to dispatcher A 130. Each member communicates to dispatcher A 130.

New use cases will now be described. Two groups are working independently in different location. There is an accident occurred in place where maintenance people are working, so there is a need for a crane group for clearing off a place. In a normal Scenario fleet members B, C, D, and E 100 will talk to dispatcher A 130, as they cannot communicate to members of the crane group 110 directly. It is beneficial in some cases that some users of maintenance group 100 communicate to crane group 110 directly for clear and fast understanding of a situation. Dispatcher A 130 should control who can talk to whom, dispatcher can create such communication when needed for better control of a situation. This innovation proposes dispatcher A 130 should be able to set some routing rules so that members of the fleet group 110 can communicate directly.

There is one more use case where dispatcher A 130 is BUSY and there is an accident and need for urgent attention from members of the crane group 110, as dispatcher A 130 is busy effectively dispatcher session also becomes idle. So to avoid this situation dispatcher A 130 should be able to set some routing rules between the some of the fleet members.

The routing rules allow dispatcher A 130 to create a communication between some users without explicitly creating an ad-hoc group between them and manage it separately. The above use cases demand to have a communication between the some of fleet members under the control of a dispatcher A 130. The present invention proposes above use cases as well it provides the solutions for above use cases. As stated in the previous section, current state of art cannot achieve this. This invention proposes the control plane and the user plane solutions. This solution can also be applied to other SIP (Session Initiation Protocol) based applications where dispatcher session concept is present e.g. SIMPLE IM (Instant Messaging).

It is an object of the present invention to set up user plane routing rules for accomplishing communication between the fleet members.

In addition, the present invention provides a system and a method for setting up the user plane routing rules within a dispatcher session.

Furthermore, the present invention extends the SIP methods for accomplishing this. The present invention also extends the RTP/RTCP protocol.

In addition, the present invention proposes a new RTCP APP message for sending system information, and the present invention also proposes SIP-based solution and appropriate schemas for accomplishing above use cases.

In accordance with an aspect of the present invention, there is provided a system for creating a routing rule between fleet members, the system including a dispatcher; a plurality of fleet members; and a control server for controlling and managing session establishment between the dispatcher and the fleet members, wherein the dispatcher inserts a routing rule to a routing rule setup request message and transmits the message, the routing rule containing information regarding fleet members wanting direct communication, the control server stores the routing rule when the routing rule setup request message is received, and when media is received from a fleet member participating a dispatcher session, the control server transfers the media to fleet members specified by the stored routing rule of the dispatcher.

According to another aspect of the present invention, there is provided a method for creating a routing rule between fleet members in a system having a dispatcher, a plurality of fleet members, and a control server for controlling and managing session establishment between the dispatcher and the fleet members, the method including the steps of transmitting a routing rule to the control server by the dispatcher after inserting the routing rule to a routing rule setup request message, the routing rule containing information regarding fleet members wanting direct communication; storing the routing rule by the control server when the routing rule setup request message is received; and transferring media by the control server to fleet members specified by the stored routing rule of the dispatcher when the media is received from a fleet member participating in a dispatcher session. Advantageous Effects

The present invention provides an easy way of enabling the communication between the fleet members with requiring additional procedures for session initiation procedures, as well as easy ways of disabling the communication between the fleet members without session modification procedures. The dispatcher has the total control on this so can control the dispatch session in better way. The present invention saves lots of resources because no session modification procedures are required now. The present invention gives more flexibility to the dispatcher.

Brief Description of the Drawings

The foregoing and other objects, features, and advantages of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which:

FIG. 1 shows a conventional dispatcher use case scenario;

FIG. 2 shows a process for setting user plane routing rules according to an embodiment of the present invention;

FIG. 3 shows a system message packet format according to an embodiment of the present invention;

FIG. 4 shows a route system message for setting routing rules according to an embodiment of the present invention;

FIG. 5 shows a route notification packet system message according to an embodiment of the present invention;

FIG. 6 shows a media burst request message for setting routing rules according to an embodiment of the present invention;

FIG. 7 shows an INFO-based solution for setting routing rules in to CF according to an embodiment of the present invention;

FIG. 8 shows a MESSAGE-based solution for setting routing rules in to CF according to an embodiment of the present invention;

FIG. 9 shows the basic hierarchy of body structure elements for setting routing rules according to the present invention; and

FIG. 10 shows the flow of signals for controlling direct communication between fleet members according to the present invention. Best Mode

Mode for Invention

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein is omitted to avoid making the subject matter of the present invention unclear.

This invention proposes system and methods for setting up a user plane routing rules, which allows dispatcher to create direct communication between the fleet members. This will avoid creating separate ad-hoc group and manage it separately. This innovation proposes two solutions for setting up routing rules, one based on User plane protocol and other one based on the control plane protocol. The details about the each solution are explained next.

The setup of user plane routing rules will be described first.

This part of an invention proposes to have dispatcher defined user plane routing rules in a PoC server who controls dispatcher session. Once this routing rule has been set fleet member can communicate directly with each other so there is no need to have special ad-hoc session between them. So this will avoid unnecessary hassles of creating a separate session.

FIG. 2 shows a basic proposal for setting routing rules according to an embodiment of the present invention. Here dispatcher 200 will set some rules in CF 210 and then CF 210 can then forward the RTP packets between these fleet members 230, 231, 232, and 233. The dispatcher 200 can disable these routing rules anytime. So whenever Dispatcher is busy he can set these rules and this will help in avoiding the emergency conditions. In this proposal, we are proposing two kinds of solutions one is User plane solution and other one is control plane solution. In the user plane solution we are using the RTCP APP message for setting these rules and in control plane solution we are proposing SIP methods for setting these rules.

The User Plane Solution for setting routing rules will be described. In this method, user plane protocol is used for setting routing rules. This invention extends the RTCP protocol for setting the routing rules. Basically this extends RTCP (RTP Control Protocol) APP (application) message. This defines a new APP message for sending any system information. This invention proposes a structure for the same and uses this message for setting up the routing rules.

This invention defines a new APP packet called "System Message" for sending the control information. This message can be easily extended for the future need of system information exchange between the user and server. FIG. 3 shows structure for general system message. The subtype field is used to indicate the system message for PoC. The value for subtype can be assigned to indicate it as PoC "system message". The SSRC field is used to indicate the user who is sending this packet. The name field is used to specify the version of the PoC application. The ID field is used to indicate the type of System message. This will help us in defining the various system messages. This is an 8 bit wide field where user can define new types of system message. The length field is positioned right next to the ID field, and is used for the defining the total length of user defined structure. The User Define Structure field is defined for particular type of system message. This invention defines it for setting routing information and for sending notification to fleet members about routing information.

This system message RTCP APP message is used for sending any system related information. This invention uses this message for setting user plane routing information. FIGs. 4 and 5 show the associated messages for setting routing information and sending notification about the routing information.

FIG. 4 shows system message used for setting up the routing rules. Here SSRC will be Dispatcher SSRC to indicate the source of this packet. To indicate this is a routing packet, ID field is used. Length field will be used for indicating number of entries in the packet. Dispatcher 200 will use the SSRCs of each fleet member to enable RTP data packet routing among them. For example, suppose dispatcher 200 want to set routing between the user B, C, and D then dispatcher 200 will add SSRCs of B, C, and D in this packet. So this way dispatcher can set routing rules in controlling function. Dispatcher can disable this routing rule by sending empty route system message.

FIG. 5 shows system message format for sending notification to fleet members about set routing rules. This packet format is also similar to route system message. Here ID will be set as "route_Notif ' for indication of routing notification. CF 120 will add his ID in the SSRC field; dispatcher 130 will add the SSRCs of fleet members with whom recipient fleet member can talk directly.

This way system message is used for setting routing rules into a CF 120. This invention also provides alternate solution for setting these rules using the existing MBCP messages. The alternate solution is explained next. This alternate solution uses existing MBCP message for setting the rules in to CF by reusing the existing field in the TBCP message. For example, this method can use MBCP Media Burst Request message for sending the routing information. The structure of MBCP message is shown below in FIG. 6.

The present invention proposes new fields for MBCP Media Burst Request message for setting the routing rules. Here the Dispatcher 130 sends the media burst request with use of Option field in the request for setting routing information. Here dispatcher 130 sets the ID as route for indicating the route setting request. Dispatcher 130 also adds SSRCs values of the fleet members for setting the routing rules. Dispatcher 130 will send this request to CF 120 and then CF 120 will extract the route information and set this rule. CF 120 will also process this Talk burst request normally. Once Dispatcher 130 is having floor is can announce to users about the rules set.

The second solution for setting routing rules, i.e. control plane solution, will now be described.

In this method control plane procedures are used for setting the routing rules in a CF. SIP methods are utilized for the setting of routing rules. In this proposal two kinds of solutions are proposed, one is using the SIP INFO method, other is using MESSAGE Method. The detail solutions are as follows.

Firstly, the SIP INFO method based solution for routing rules setting will be described.

In this method, SIP INFO method is utilized for sending the routing rules to the CF 120. SIP INFO method is used for sending the application specific information. Here we utilize the SIP INFO method for the setting the routing rules. Basic behavior for this method is shown in FIG. 7.

1. Dispatcher 200 sends the INFO method with Body to CF 210. Here Body will indicate the routing rules. The schema format for this is discussed later in this document.

2. CF (controlling server) 210 validates the Body of INFO as per the schema defined in this invention. CF 210 will also send 200 OK responses to client device, i.e. dispatcher 200.

The ENFO body will have the routing rules. The schema of this body is defined later in this document. This way user can set the routing rules using the SIP INFO method.

Secondly, the SIP MESSAGE method based solution for routing rules setting will be described.

In this method, SIP MESSAGE method is utilized for sending the routing rules to the CF 210. SIP MESSAGE method is used for sending the application specific information. Here we utilize the SIP MESSAGE method for the setting the routing rules. Basic behavior for this method is shown in FIG. 8.

1. Dispatcher 200 sends the INFO method with Body to CF 210. Here Body will indicate the routing rules. The schema format for this is discussed later in this document.

2. CF (controlling server) 210 validates the Body of MESSAGE as per the schema defined in this invention. CF will also send 200 OK responses to client device, i.e. dispatcher 200.

3. Similarly MESSAGE Method can be used for sending notification to the fleet members 230, 231, 232, and 233.

The MESSAGE body will have the routing rules. The schema of this body is defined later in this document. This way user can set the routing rules using the SIP MESSAGE method.

(C) Schema format for the setting the routing rules

FIG. 9 shows the basic hierarchy of body structure elements for setting the routing rules in a CF 210. This body is included in the SIP Methods defined above. PoC server will extract this body and then validate it as per schema defined in Table 3.

As shown in FIG. 9, the body has one root element called "DispatcherRoutingRules" and it has one attribute called "State". This "State" is used to enable and disable the routing rules. The root element has one child element called "Route" which will define the routing rules. Route element has the three elements "State", "ValidTime", and "RoutelD". RouteID is used to give the ID value to particular route. We can individually disable the routing rules using the state attribute. "ValidTime" is used for setting the valid time duration for the route set, so that CF 210 can automatically disable the route rule after ValidTime period. The route element has "URI" as child element. This URI element will be used for setting name of the users. For example, the dispatcher wants to set the route between the USER B, C, and D. Then Dispatcher will include three URI elements and set the value of this element to SIP URI of particular fleet members. Following are some of the examples for body structure in various cases. Following Table 3 shows a body structure schema format. Table 3

Figure imgf000014_0001

Figure imgf000015_0001

For example, Dispatcher A wants to set routing rules in to CF for fleet member B, C, and D. So Dispatcher can use any of the above methods for sending the rules to CF. In this case, a body structure as shown in following Table 4 is used.

Table 4

Figure imgf000015_0002
Figure imgf000016_0001

For example, Dispatcher A wants to set rules as user B and C should be able to communicate directly and user D, E and F must be able to communicate directly. Dispatcher will use a body as shown in following Table 5 to set the rules.

Table 5

Figure imgf000016_0002

For another example, dispatcher A wants to disable the routing rules set in the CF. In this case, the dispatcher uses a body as shown in following Table 6 to set the rules.

Table 6

Figure imgf000016_0003

The logical informative flow according to the present invention will now be described with reference to FIG. 10.

FIG. 10 shows the logical information flow according to the present invention. In this scenario, there is a dispatcher user A, and there are other fleet members, i.e. user B, user C, and user D in a dispatcher group. The logical steps of this scenario will be described.

In step 10, the user of dispatcher A wants to initiates a dispatcher session, and the dispatcher A sends a dispatcher session participation request message, including dispatcher tags, to the CF (controlling server) in order to establish a dispatcher session. In other words, the dispatcher A sends an INVITE SIP request together with dispatcher tags to the CF.

In step 12, the CF validates the INVITE request and checks for validity of the dispatcher A regarding the dispatcher role.

In following steps 14-18, the CF sends dispatcher session participation request messages, i.e. INVITEs, to all other fleet members of the dispatcher group.

Then, the fleet members accept the invitation by responding with 200 OK responses in steps 20-24, and a dispatcher session is established in step 26. Whenever a user of fleet B wants to send media, he can request the floor, and once the fleet B gets the floor, he sends the media to the CF in step 28.

The CF then forwards the received media to the dispatcher A in step 30.

It will be assumed that the dispatcher user wants to enable communication between the users of fleets B and D in step 32.

Then, the dispatcher sends a routing rule request to the CF in step 34 so that communication between fleets B and D is possible. More particularly, a routing rule setup request message containing routing rules is transmitted to the CF so that routing rules are set for direct communication between predetermined fleet members, as mentioned above. The routing rule setup request message is the same as the system message.

The CF validates the routing rule request received from the dispatcher and stores the rules. Then, the CF sends a response regarding the routing rule request to the dispatcher A.

The CF then notifies users B and D of the rules that have been set.

If fleet D has media to send, it sends the media to the CF in step 44. The CF then forwards the media to the dispatcher A.

The CF also forwards the media to fleet B according to the routing rules set by the dispatcher A.

This way as seen by above example this invention gives very easy and flexible way for setting the routing rules for enabling the communication between the fleet members. This saves lots of resources of sending session initiation request for establishing the separate ad-hoc session between the fleet members.

As mentioned above, the present invention proposes a very easy and flexible way of enabling the communication between the fleet members of dispatcher session by setting routing rules. The invention proposes a user plane method for setting the routing rules by using new MBCP Messages or existing MBCP messages. The invention also proposes a control plane method for setting the routing rules.

In addition, the present invention uses generic MBCP messages (MBCP system messages) to give users the flexibility of developing any number of new MBCP messages. These are called system messages, because the number of RTCP APP messages is limited to 32. Future applications like PoC may require more messages, so the system messages give the flexibility of creating any number of MBCP messages.

Although several exemplary embodiments of the present invention have been described for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims.

Claims

Claims
1. A system for creating a routing rule between fleet members, the system comprising: a dispatcher; a plurality of fleet members; and a control server for controlling and managing session establishment between the dispatcher and the fleet members, wherein the dispatcher inserts a routing rule to a routing rule setup request message and transmits the message, the routing rule containing information regarding fleet members wanting direct communication, the control server stores the routing rule when the routing rule setup request message is received, and when media is received from a fleet member participating a dispatcher session, the control server transfers the media to fleet members specified by the stored routing rule of the dispatcher.
2. The system as claimed in claim 1, wherein the dispatcher is adapted to transmit the routing rule setup request message after a dispatcher session is established between the fleet members.
3. The system as claimed in claim 1, wherein the control server is adapted to transfer the received media to the dispatcher and to fleet members specified by the routing rule of the dispatcher.
4. The system as claimed in claim 1, wherein the control server is adapted to store the routing rule when the routing rule setup request message is received and to transfer a response message regarding the routing rule setup request message to the dispatcher.
5. The system as claimed in claim 1, wherein the control server is adapted to store the routing rule when the routing rule setup request message is received and to notify fleet members specified by the routing rule of the routing rule.
6. A method for creating a routing rule between fleet members in a system having a dispatcher, a plurality of fleet members, and a control server for controlling and managing session establishment between the dispatcher and the fleet members, the method comprising the steps of: transmitting a routing rule to the control server by the dispatcher after inserting the routing rule to a routing rule setup request message, the routing rule containing information regarding fleet members wanting direct communication; storing the routing rule by the control server when the routing rule setup request message is received; and transferring media by the control server to fleet members specified by the stored routing rule of the dispatcher when the media is received from a fleet member participating in a dispatcher session.
7. The method as claimed in claim 6, further comprising a step of conducting an operation for establishing a dispatcher session between the fleet members by the dispatcher before the transmitting step.
8. The method as claimed in claim 6, further comprising a step of transferring the received media to the dispatcher by the control server.
9. The method as claimed in claim 6, further comprising a step of transmitting a response message regarding the routing rule setup request message to the dispatcher by the control server after the storing step.
10. The method as claimed in claim 6, further comprising a step of notifying fleet members specified by the routing rule of the routing rule by the control server after the storing step.
PCT/KR2007/005992 2006-11-24 2007-11-26 System and method for creating routing rules between fleet members WO2008063036A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
IN2183/CHE/2006 2006-11-24
IN2183CH2006 2006-11-24

Publications (1)

Publication Number Publication Date
WO2008063036A1 true true WO2008063036A1 (en) 2008-05-29

Family

ID=39429919

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2007/005992 WO2008063036A1 (en) 2006-11-24 2007-11-26 System and method for creating routing rules between fleet members

Country Status (2)

Country Link
KR (1) KR101348002B1 (en)
WO (1) WO2008063036A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2571298A1 (en) * 2010-09-17 2013-03-20 Huawei Technologies Co., Ltd. Method, server and system for processing emergency call in push to talk over cellular (poc) service

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1587332A1 (en) * 2004-04-16 2005-10-19 Research In Motion Limited Method and Apparatus for Dynamic Group Address Creation
WO2005122470A1 (en) * 2004-06-11 2005-12-22 Nokia Corporation A communication system
WO2006027407A1 (en) * 2004-09-08 2006-03-16 Nokia Corporation Group details of group services

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7386000B2 (en) * 2001-04-17 2008-06-10 Nokia Corporation Packet mode speech communication
US7130282B2 (en) * 2002-09-20 2006-10-31 Qualcomm Inc Communication device for providing multimedia in a group communication network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1587332A1 (en) * 2004-04-16 2005-10-19 Research In Motion Limited Method and Apparatus for Dynamic Group Address Creation
WO2005122470A1 (en) * 2004-06-11 2005-12-22 Nokia Corporation A communication system
WO2006027407A1 (en) * 2004-09-08 2006-03-16 Nokia Corporation Group details of group services

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2571298A1 (en) * 2010-09-17 2013-03-20 Huawei Technologies Co., Ltd. Method, server and system for processing emergency call in push to talk over cellular (poc) service
EP2571298A4 (en) * 2010-09-17 2014-12-03 Huawei Tech Co Ltd Method, server and system for processing emergency call in push to talk over cellular (poc) service
US9071943B2 (en) 2010-09-17 2015-06-30 Huawei Technologies Co., Ltd. Method, server, and system for processing emergency call in PoC service

Also Published As

Publication number Publication date Type
KR101348002B1 (en) 2014-02-13 grant
KR20080047306A (en) 2008-05-28 application

Similar Documents

Publication Publication Date Title
US7366780B2 (en) System and method for controlling and managing sessions between endpoints in a communications system
US6798755B2 (en) Apparatus and method for controlling and managing individual directed sessions in a communications system
US7023813B2 (en) Methods for managing a pool of multicast addresses and allocating addresses in a communications system
US20060172754A1 (en) Method and system for servicing full duplex call in push-to-talk over cellular
US20040125760A1 (en) Methods for affiliating endpoints with a group and determining common communication capabilities for the affiliated endpoints
US7155248B2 (en) System and method for initiating push-to-talk sessions between outside services and user equipment
US20130279375A1 (en) Method and apparatus for enabling interoperability between a broadband network and a narrowband network
US20050124365A1 (en) Floor control in multimedia push-to-talk
US20060234744A1 (en) Method and system for splitting terminals in push-to-talk over cellular network
US20050276268A1 (en) Communication system
US20060223563A1 (en) Method and system for transmitting information of respondent participating in push-to-talk over cellular network session
US20060031294A1 (en) Communication system
US20050135374A1 (en) Activation of services in a communication system
US20060229095A1 (en) Method and system for performing media storage service in push-to-talk over cellular network
US20050265313A1 (en) Communication system
US20090106389A1 (en) Sharing Multimedia
US20070121872A1 (en) Apparatus and method for controlling a telecommunications conference
CN101043252A (en) Method and system for transmitting MBMS mechanism based IMS service
US20070129051A1 (en) Method, user equipment, and system for opening an ad-hoc PoC session in a PoC system
US20080298294A1 (en) Inter-Domain Group-Communications
US20060178160A1 (en) System and method for management of communication rights
US20060189340A1 (en) Method and system for guaranteeing seamless session when replacing PoC terminal in PoC system
US20070135106A1 (en) Method, terminal, and system for establishing PoC group session in PoC system
US20080003999A1 (en) Method and system for processing PoC Ad-Hoc group session information using RTCP connection message
US20080320083A1 (en) Methods and Apparatus for Push to Talk Type Service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07851147

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct app. not ent. europ. phase

Ref document number: 07851147

Country of ref document: EP

Kind code of ref document: A1