KR101348002B1 - 플리트 멤버 간 라우팅 규칙 생성 시스템 및 방법 - Google Patents

Abstract

본 발명은 디스패처 세션에서 플리트 멤버들간 직접적인 통신이 가능하도록 하기 위한 시스템 및 방법에 관한 것이다. 이를 위해 본 발명은 디스패처와 복수의 플리트 멤버와 디스패처와 복수의 플리트 멤버간 세션 개설 제어 및 관리하는 제어 서버를 포함하고, 플리트 멤버간 라우팅 규칙을 생성하기 위한 시스템에서, 복수의 플리트 멤버들 중 직접 통신을 원하는 플리트 멤버들의 정보를 포함하는 라우팅 규칙을 라우팅 규칙 설정 요청 메시지에 포함시켜 전송하는 디스패처와, 라우팅 규칙 설정 요청 메시지가 수신되면 라우팅 규칙을 저장한 후, 디스패처 세션에 참여하고 있는 소정의 플리트 멤버로부터 미디어가 수신되면 저장된 상기 디스패처의 라우팅 규칙에 포함된 플리트 멤버들로 미디어를 전달하는 제어 서버를 포함하는 것을 특징으로 한다.

라우팅, 규칙, 디스패처, 플리트

Description

플리트 멤버 간 라우팅 규칙 생성 시스템 및 방법{SYSTEM AND METHOD FOR CREATING ROUTING RULES BETWEEN FLEET MEMBERS}

본 발명은 이동 통신 분야에 관한 것이다. 본 발명은 PoC(Puch to talk over the Cellura) 및 SIMPLE IM과 같은 애플리케이션에서의 디스패처(dispatcher) 세션에 관한 것이다. 더 구체적으로 본 발명은 디스패처 세션 제어 메커니즘에 관한 것이다. 또한, 본 발명은 SIP 기술 및 RTP 프로토콜에 관한 것이다.

기본적으로 디스패처 세션이라 함은 디스패처라고 부르는 멤버가 제어권을 갖고 있는 미리 구성된 그룹 세션을 뜻한다. 디스패처 세션에서 적어도 한 멤버는 디스패칭 능력을 갖고 있어야 하며, 다른 멤버들을 플리트(fleet) 멤버라고 부른다. 현재의 기술 수준에서 플리트 멤버들을 직접 서로 대화할 수 없다. 디스패처는 어느 플리트 멤버와도 대화할 수 있다. 디스패처는 디스패처 세션에서 가장 높은 우선 순위를 갖는다. 디스패처는 언제라도 자신의 디스패처 역할을 임의의 다른 다스패처에게 이전할 수 있다. 디스패처와 관련된 정보는 공유 XDMS에 저장된다. 디스패처는 XDM 동작을 이용하여 어느 때라도 그룹 특성을 변경할 수 있다.

현재 기술 수준에서의 디스패처 동작을 살펴보면, 디스패처 세션은 디스패처 가 개시할 수 있으며, 이를 위해서 디스패처는 디스패처 세션 설정을 위해 인바이드(INVITE) 요청을 보내고, 이 INVITE 요청이 디스패처 세션 요청임을 식별할 수 있도록 디스패처 관련 피처 태그(feature tag)를 지정하며, 또한 디스패처 세션에서 디스패처로서의 자신의 역할을 식별할 수 있도록 상기 태그를 지정한다. 이하의 <표 1>은 기본적인 INVITE 요청 구조로서 디스패처 세션을 설정하기 위한 INVITE 요청의 예를 보여주고 있으며, “dispatch=entire-group”와 “+g.poc.dispatcher” 부분은 디스패처 관련 태그를 나타낸다.

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: <sip: 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/v1.01 Contact: <sip:PoC-ClientA.networkA.net>;+g.poc.talkburst;+g.poc.dispatcher; Supported: timer Session-Expires: 1800;refresher=uac Allow: INVITE,ACK,CANCEL,BYE,REFER,MESSAGE,SUBSCRIBE, NOTIFY,PUBLISH,OPTIONS 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= rtcp: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:TBCP multimedia=1;queuing=1; tb_priority=2; timestamp=1 a= floorid:0 mstrm:1 2

도 1에 도시한 바와 같이, 디스패처(130)는 요청 URI(Request-URI)에서 “dispatch=entire-group” 탭을 지정함으로써 디스패처 세션을 개시하게 된다. 또한, 디스패처(130)는 컨텍(Contact) 헤더 필드에 “+g.poc.dispatcher” 태그를 포함시킴으로써 디스패처로서 거동하기를 선호함을 나타낸다. 제어 서버(120)가 이 요청을 수신하면 그 그룹의 그룹 정책을 점검하고 INVITE 요청을 검증하며, 검증 후에 디스패처(130)는 INVITE 요청을 그룹의 다른 멤버(100, 110)에게 보냄으로써 세션을 설정한다. 제어 서버(120)는 디스패처 세션으로서의 식별을 위한 디스패처 세션과 관련된 피처 태그도 포함한다는 것에 주목하기 바란다. 초대 사용자가 200 OK 응답을 보냄으로써 INVITE 요청을 수락하고 나면 제어 서버(120)는 그 200 OK 응답을 디스패처(130)로 보낸다. 이러한 방식으로 디스패처 세션이 설정된다. 이 예에서 PoC 사용자 A가 세션의 디스패처 역할을 하게 된다. 세션이 설정되고 나면 PoC 사용자 A는 디스패처 세션을 제어할 수 있다. 디스패처 세션에서 다른 사용자들은 플리트 멤버라고 불린다. 전술한 바와 같이 플리트 멤버들은 직접 서로 대화할 수 없다.

한 그룹에 다수의 디스패처가 있을 수 있지만, 소정 시점에서 디스패처의 역할을 하는 것은 단 하나뿐이며, 나머지는 플리트 멤버의 역할을 하게 된다. 현재의 기술 수준으로도 디스패처가 자신의 디스패칭 역할을 그룹의 다른 디스패처에게 이전할 수 있는 융통성이 있다. 이는 리퍼(REFER) 방법을 이용하여 달성할 수 있는데, 하기 표 2는 REFER 요청 중의 SIP 헤더 필드값을 보여준다. 따라서, 제어 서버는 다른 디스패처에게 Re-INVITE를 보내어 디스패칭 역할을 이전한다. 이하, <표 2>는 디스패칭 역할을 다른 디스패처에게 이전할 때의 REFER 요청 중의 주요 SIP 헤더의 예이다. <표 2>에서“Dispatcher Feature Tag with “Require” and “explicit” tag”는 디스패처 관련 부분이다.

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

현재 기술 수준에서 디스패처는 디스패처 세션의 여러 측면을 제어할 수 있으며, 플리트 멤버 사이의 다수의 애드혹(ad-hoc) 세션에 대한 제어권을 갖고 있다. 현재 기술로는 플리트 멤버 사이에서 직접 통신이 불가능하다. 때로는 디스패처의 제어 하에 있는 플리트 멤버 사이에서 직접 통신이 가능하게 하는 것이 유리하다. 이는 종래 기술에서와 같이 플리트 멤버 사이에서 애드혹 세션을 생성함으로써 달성할 수 있다. 그러한 세션은 현재의 디스패처 세션과는 별도의 세션이 될 것이며, 따라서 플리트 멤버 사이에서 다른 세션이 생성되어야 한다. 이를 위해서는 CF가 플리트 멤버 사이에서 추가 세션을 유지해야 하거나, 새로운 CF가 애드혹 세션을 유지해야 한다. 특정 기간 동안 디스패처가 바쁜 이용 경우도 있다. 그 기간 동안은 디스패처 세션이 놀게 된다. 만약 그 기간 동안 디스패처가 플리트 멤버 간의 통신을 허용한다면 디스패처가 그 기간 동안 놀지 않게 될 것이다. 현재 기술 수준으로는 이를 위한 해결책이 없다.

현재 기술로는, 디스패처가 플리트 멤버 사이에서 통신을 가능하게 하려고 하는 경우 플리트 멤버 사이에서 애드혹 세션을 허용해야 한다. 이를 위해서는 추가적인 세션 초기화 절차가 필요하다. 그러한 추가적인 애드혹 세션을 위한 세션 문맥을 제어 서버가 유지해야 한다. 또한, 디스패처가 애드혹 세션을 완전히 제어하지 못할 수 있다. 디스패처가 디스패처 세션을 보통 세션으로 만든다면, Re-Invite 요청을 모두에게 보내야 하고, 많은 자원이 필요하며, 디스패처가 세션을 제어하지 못하게 되고, 이는 디스패처 세션에서 매우 중요하다.

플리트 멤버 사이에서 직접 통신이 가능하게 하는 새로운 이용 경우를 제시한다. 도 1에 도시한 디스패처 이용 경우 시나리오에서는 디스패처(A)(130)와 2개의 그룹이 있으며, 그 중 하나는 유지 그룹(100)이라고 하고, 나머지 그룹은 크레인(crane) 그룹(110)이라 한다. 유지 그룹 멤버(B, C, D, E)와 크레인 그룹 멤버(F, G, H, I)는 독립적으로 작업한다. 이들 두 그룹(100, 110)과 디스패처(A)(130) 사이에 디스패처 세션이 있다. 디스패처(A)(130)는 자신이 디스패처인 세션을 제어한다. 이 새로운 주요 이용 경우에 대해 설명하면 하기와 같다.

선행 조건으로 사용자(A)는 디스패처이고, 디스패처 세션을 갖는다. 또한, 현재 유지 그룹은 디스패처(A)(130)와 통신할 수 있다. 각각의 멤버가 디스패처(A)와 통신한다.

또한, 현재 크레인 그룹(110)은 디스패처(A)(130)와 통신할 수 있다. 각각의 멤버가 디스패처(A)(130)와 통신한다.

새로운 이용 경우에 대하여 살펴보면, 두 그룹은 다른 위치에서 독립적으로 작업하고 있다. 유지 인원들이 작업하고 있는 장소에서 사고가 일어나 크레인 그룹이 그 장소를 치울 필요가 생겼다. 일반적인 시나리오에서는 플리트 멤버(B, C, D, E)(100)가 디스패처(A)(130)와 대화하게 되는데, 왜냐하면 크레인 그룹(110)의 멤버와는 직접 통신할 수 없기 때문이다. 어떤 경우에는 유지 그룹(100)의 일부 사용자가 크레인 팀(110)과 직접 통신하는 것이 상황의 명확하고 빠른 이해에 도움이 된다.디스패처(A)(130)는 누가 누구와 대화할 수 있는지를 제어해야 하며, 디스패처(A)(130)는 상황을 더 잘 제어하기 위해 필요할 때 그러한 통신을 생성할 수 있다. 본 발명의 혁신적인 제안에 따르면 디스패처(A)(130)는 플리트 그룹(110)의 멤버들이 직접 통신할 수 있도록 몇몇 라우팅 규칙을 정할 수 있어야 한다.

또 다른 이용 경우로서, 디스패처(A)(130)가 바쁜 도중 사건이 생겨 크레인 그룹(110)의 멤버들이 긴급 대응해야 하나, 디스패처(A)(130)가 바쁘기 때문에 디스패처 세션이 놀게 된다. 이 상황을 피하기 위해서는 디스패처(A)(130)가 일부 플리트 멤버 사이에서 몇몇 라우팅 규칙을 정할 수 있어야 한다.

이러한 라우팅 규칙은 디스패처(A)(130)가 일부 사용자 사이에 애드혹 그룹을 생성해서 별도로 관리하는 일 없이 이들 사용자 사이에 통신을 생성할 수 있게 한다.상기 이용 경우는 디스패처(A)(130)의 제어 하에 플리트 멤버 중 일부 사이에서 통신을 요구한다. 본 발명은 전술한 이용 경우 및 이를 위한 해결책을 제시한 다. 상기에서 서술한 바와 같이 현재의 기술 수준으로는 이를 달성할 수 없다. 본 발명은 제어 평면 및 사용자 평면 해결책을 제시한다. 이 해결책은 심플 인스턴트 메시징(SIMPLE IM(Instant Messaging))과 같이 디스패처 세션 개념이 존재하는 다른 SIP(Session Initiation Protocol)에 기초한 애플리케이션에도 적용할 수 있다.

본 발명은 플리트 멤버 간의 통신을 이루기 위한 사용자 평면 라우팅 규칙을 설정하는 것을 목적으로 한다.

또한, 본 발명은 디스패처 세션 내에서 사용자 평면 라우팅 규칙을 설정하기 위한 시스템과 방법을 제시한다.

또한, 본 발명은 이를 달성하기 위한 SIP 방법을 확장한다. 본 발명은 RTP/RTCP 프로토콜도 확장한다.

또한, 본 발명은 시스템 정보를 보내기 위한 새로운 RTCP APP 메시지를 제안하며, 전술한 이용 경우를 달성하기 위한 SIP에 기초한 해결책 및 적절한 방안도 제시한다.

상기한 바를 달성하기 위한 본 발명은 디스패처와 복수의 플리트 멤버와 디스패처와 복수의 플리트 멤버 간 세션 개설 제어 및 관리하는 제어 서버를 포함하고, 상기 플리트 멤버 간 라우팅 규칙을 생성하기 위한 시스템에 있어서, 상기 복수의 플리트 멤버들 중 직접 통신을 원하는 플리트 멤버들의 정보를 포함하는 라우팅 규칙을 라우팅 규칙 설정 요청 메시지에 포함시켜 전송하는 상기 디스패처와, 상기 라우팅 규칙 설정 요청 메시지가 수신되면 상기 라우팅 규칙을 저장한 후, 디스패처 세션에 참여하고 있는 소정의 플리트 멤버로부터 미디어가 수신되면 상기 저장된 상기 디스패처의 라우팅 규칙에 포함된 플리트 멤버들로 미디어를 전달하는 상기 제어 서버를 포함하는 것을 특징으로 한다.

또한, 본 발명은 디스패처와 복수의 플리트 멤버와 디스패처와 복수의 플리트 멤버 간 세션 개설 제어 및 관리하는 제어 서버를 포함하는 시스템에서 상기 플리트 멤버 간 라우팅 규칙을 생성하기 위한 방법에 있어서, 상기 디스패처가 상기 복수의 플리트 멤버들 중 직접 통신을 원하는 플리트 멤버들의 정보를 포함하는 라우팅 규칙을 라우팅 규칙 설정 요청 메시지에 포함시켜 상기 제어 서버로 전송하는 과정과, 상기 제어 서버가 상기 라우팅 규칙 설정 요청 메시지가 수신되면 상기 라우팅 규칙을 저장하는 과정과, 상기 제어 서버는 디스패처 세션에 참여하고 있는 소정의 플리트 멤버로부터 미디어가 수신되면 상기 저장된 상기 디스패처의 라우팅 규칙에 포함된 플리트 멤버들로 미디어를 전달하는 과정을 포함하는 것을 특징으로 한다.

세션 초기화 절차를 위한 추가 절차를 필요로 하는 플리트 멤버 간의 통신을 쉬운 방식으로 가능하게 한다. 또한, 세션 수정 절차 없이 플리트 멤버 사이의 통신을 쉽게 정지시킨다. 또한, 디스패처가 이 과정을 전체적으로 제어함으로써 디스패처 세션을 더 잘 제어한다. 또한, 세션 수정 절차가 더 이상 필요하지 않으므로 자원이 다량 절감된다. 또한, 디스패처에게 더 많은 융통성이 부여된다.

이하, 본 발명의 바람직한 실시 예들을 첨부한 도면을 참조하여 상세히 설명 한다. 또한, 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략한다.

본 발명은 디스패처가 플리트 멤버 간에 직접 통신을 생성할 수 있도록 하는 사용자 평면 라우팅 규칙을 설정하기 위한 시스템과 방법을 제공한다. 이를 위해 별도로 애드혹 그룹을 생성하고 따로 관리할 필요가 없다. 본 발명은 라우팅 규칙을 설정하기 위한 두 가지 해결책을 제안하는데, 그 중 하나는 사용자 평면 프로토콜에 기초한 것이고, 나머지 하나는 제어 평면 프로토콜에 기초한 것이다. 각 해결책을 이하에서 상세히 설명한다.

첫 번째로 사용자 평면 라우팅 규칙 설정에 대하여 설명하도록 한다.

본 발명의 이 부분에서는 디스패처가 디스패처 세션을 제어하는 POC 서버에서 사용자 평면 라우팅 규칙을 정의하도록 제안한다. 이 라우팅 규칙이 정해지고 나면 플리트 멤버가 직접 서로 대화할 수 있게 되어, 이들 사이에 특별한 애드혹 세션이 불필요하게 된다. 그 결과, 별도의 세션을 생성하는 수고를 덜게 된다.

도 2에는 본 발명의 실시 예에 따라 라우팅 규칙을 설정하기 위한 기본적인 제안이 도시되어 있다. 디스패처(200)가 제어 서버(CF)(210)에서 일부 규칙을 설정하면, CF(210)는 RTP 패킷을 플리트 멤버(230, 231, 232, 233) 사이로 전달한다. 디스패처(200)는 이들 라우팅 규칙을 언제라도 정지시킬 수 있다. 따라서 디스패처가 바쁠 경우에는 이러한 규칙을 설정해서 긴급 상태를 피할 수 있게 된다. 이와 관련하여 두 종류의 해결책을 제안하는데, 그 중 하나는 사용자 평면 해결책이고, 나머지 하나는 제어 평면 해결책이다. 사용자 평면 해결책에서는 RTCP APP 메시지 를 이용하여 그러한 규칙을 설정하고, 제어 평면 해결책에서는 SIP 방법을 이용하여 그러한 규칙을 설정한다.

먼저, 라우팅 규칙을 설정하기 위한 사용자 평면 해결책에 대하여 살펴보면, 이 방법에서는 사용자 평면 프로토콜을 이용해서 라우팅 규칙을 설정한다. 본 발명은 RTCP 프로토콜을 확장해서 라우팅 규칙을 설정한다. 기본적으로 이 과정에서는 RTCP(RTP Control Protocol) APP(application) 메시지를 확장한다. 이는 임의의 시스템 정보를 보내기 위한 새로운 APP 메시지를 정의한다. 본 발명은 이를 위한 구조를 제안하며, 이 메시지를 이용해서 라우팅 규칙을 설정한다.

본 발명은 제어 정보를 보내기 위해서 "시스템 메시지"라고 부르는 새로운 APP 패킷을 정의한다. 이 메시지는 추후에 사용자와 서버 사이에서 시스템 정보를 교환하기 위해 쉽게 확장할 수 있다. 도 3은 일반적인 시스템 메시지의 구조를 보여주고 있다. 서브타입 필드는 PoC를 위한 시스템 메시지를 나타내기 위해 이용된다. 서브타입 값을 할당해서 이를 PoC "시스템 메시지"로 나타낼 수 있다. 그리고 SSRC 필드는 이 패킷을 보내는 사용자를 나타내기 위해 이용된다. 또한, 이름 필드는 PoC 애플리케이션의 버전을 보여주기 위해 이용된다. 또한, 아이디 필드는 시스템 메시지의 타입을 나타내기 위해 이용된다. 이는 다양한 시스템 메시지를 정의하는 데에 도움을 준다. 이것은 8비트 넓이의 필드로서, 사용자가 새로운 시스템 메시지 타입을 정의할 수 있다. 또한, 아이디 필드 바로 옆에 위치하는 길이 필드는 사용자 정의 구조의 전체 길이를 정의하기 위해 이용된다. 그리고 사용자 정의 구조 필드는 특정 타입의 시스템 메시지를 위해 정의된다. 본 발명에서는 라우팅 정 보를 설정하고 라우팅 정보에 대한 통보를 플리트 멤버에게 보내기 위해 사용자 정의 구조를 정의한다.

이 시스템 메시지인 RTCP APP 메시지는 임의의 시스템 관련 정보를 보내기 위해 이용된다. 본 발명은 이 메시지를 이용해서 사용자 평면 라우팅 정보를 설정한다. 도 4 및 도 5는 라우팅 정보를 설정하고, 그 라우팅 정보에 대한 통보를 보내는 것과 관련된 메시지를 보여주고 있다.

도 4는 라우팅 규칙을 설정하기 위해 이용되는 시스템 메시지를 보여주고 있다. 여기서, SSRC는 이 패킷의 소스를 나타내기 위한 디스패처 SSRC가 된다. 이것이 라우팅 패킷임으로 나타내기 위해서 ID 필드를 이용한다. 길이 필드를 이용해서 패킷 내 엔트리의 수를 나타낸다. 디스패처(200)는 각 플리트 멤버의 SSRC를 이용해서 그 멤버 사이에서 RTP 데이터 패킷 라우팅을 가능하게 한다. 예를 들면, 디스패처(200)가 사용자 B, C, D 사이에서 라우팅을 설정하기를 원한다고 가정하면, 디스패처(200)는 B, C, D의 SSRC를 이 패킷 내에 추가한다. 이러한 방식으로 디스패처는 제어 함수에 라우팅 규칙을 설정할 수 있다. 디스패처는 비어 있는 라우트 시스템 메시지를 보냄으로써 이 라우팅 규칙을 중지시킬 수 있다.

도 5는 설정된 라우팅 규칙에 대한 통보를 플리트 멤버에 보내기 위한 시스템 메시지 포맷을 보여주고 있다. 이 패킷 포맷은 라우트 시스템 메시지와도 유사하다. 여기서 ID 필드는 “route_Notif”로 설정하여 라우팅 통보임을 나타낸다. CF(120)는 자신의 ID를 SSRC 필드에 추가하고, 디스패처(130)는 수신측 플리트 멤버가 직접 대화할 수 있는 플리트 멤버의 SSRC를 추가한다.

이와 같이 시스템 메시지는 CF(120)에 라우팅 규칙을 설정하기 위해 이용된다. 본 발명은 기존의 MBCP 메시지를 이용해서 그러한 규칙을 설정하는 대안적 해결책도 제시하는데, 이에 대해 설명하겠다. 대안적 해결책은 기존의 MBCP 메시지를 이용해서 CF에 규칙을 설정하는데, 이는 TBCP 메시지 중의 기존 필드를 재사용함으로써 이루어진다. 예를 들면, 이 방법은 MBCP 미디어 버스트 요청 메시지를 이용해서 라우팅 정보를 보낼 수 있다. MBCP 메시지의 구조를 도 6에 도시하였다.

본 발명은 라우팅 규칙을 설정하기 위한 MBCP 미디어 버스트 요청 메시지를 위한 새로운 필드를 제안한다. 여기서 디스패처(130)는 라우팅 정보를 설정하기 위한 요청에서 옵션(Option) 필드를 이용하여 미디어 버스트 요청을 보낸다. 이때 디스패처(130)는 라우트 설정 요청을 나타내도록 ID를 라우트로 설정한다. 또한, 디스패처(130)는 라우팅 규칙을 설정하기 위한 플리트 멤버의 SSRC값을 추가한다. 디스패처(130)가 이 요청을 CF(120)로 보내면 CF(120)는 라우트 정보를 추출해서 이 규칙을 설정한다. 또한, CF(120)는 이 토크(talk) 버스트 요청을 정상적으로 처리한다. 일단 플로어(floor)를 갖고 나면 디스패처(130)는 설정된 규칙을 사용자에게 공표할 수 있다.

다음으로, 라우팅 규칙을 설정하기 위한 두번째 해결책인 제어 평면 해결책에 대하여 살펴보도록 한다.

이 방법에서는 제어 평면 절차를 이용해서 CF에 라우팅 규칙을 설정한다. 라우팅 규칙을 설정하기 위해 SIP 방법을 이용한다. 여기서는 두 종류의 해결책을 제안하는데, 그 중 하나는 SIP INFO 방법을 이용하는 것이고, 다른 하나는 메시 지(MESSAGE) 방법을 이용하는 것이다. 이에 대해 자세히 설명하겠다.

첫 번째로 SIP INFO 방법에 기초하여 라우팅 규칙을 설정하는 해결책에 대하여 살펴보도록 한다.

이 방법에서는 SIP INFO 방법을 이용해서 라우팅 규칙을 CF(120)로 보낸다. SIP INFO 방법을 이용해서 특정 애플리케이션에 관계된 정보를 보낸다. 이때, 라우팅 규칙을 설정하기 위해 SIP INFO 방법을 이용한다. 이 방법을 위한 기본적인 동작을 도 7에 도시하였다.

1. 디스패처(200)는 INFO 방법을 본문과 함께 CF(210)로 보낸다. 여기서 본문은 라우팅 규칙을 뜻한다. 이를 위한 스키마 포맷은 후술한다.

2. 제어 서버인 CF(210)는 본 발명에서 정의하는 스키마에 따라 INFO의 본문을 검증한다. 또한, CF(210)는 200 OK 응답을 클라이언트 장치인 디스패처(200)로 보낸다.

이때, INFO 본문은 라우팅 규칙을 포함한다. 이 본문의 스키마는 본 명세서 후반부에서 정의한다. 이러한 방식으로 사용자는 SIP INFO 방법을 이용해서 라우팅 규칙을 설정할 수 있다.

두 번째로, SIP 메시지(MESSAGE) 방법에 기초한 라우팅 규칙 설정 해결책에 대하여 살펴보도록 한다.

이 방법에서는 SIP MESSAGE 방법을 이용해서 CF(210)에 라우팅 규칙을 보낸다. 특정 애플리케이션에 관계된 정보를 보내기 위해 SIP MESSAGE 방법을 이용한다. 이때 SIP MESSAGE 방법을 이용해서 라우팅 규칙을 설정한다. 이 방법을 위한 기본적인 동작을 도 8에 도시하였다.

1. 디스패처(200)는 INFO 방법을 본문과 함께 CF(210)로 보낸다. 여기서 본문은 라우팅 규칙을 뜻한다. 이를 위한 스키마 포맷은 후술한다.

2. 제어 서버인 CF(210)는 본 발명에서 정의하는 스키마에 따라 MESSAGE의 본문을 검증한다. 또한, CF(210)는 200 OK 응답을 클라이언트 장치인 디스패처(200)로 보낸다.

3. 마찬가지로 MESSAGE 방법을 이용해서 플리트 멤버들(230, 231, 232, 233)에 통보를 보낼 수 있다.

MESSAGE 본문은 라우팅 규칙을 포함한다. 이 본문의 스키마는 본 명세서 후반부에서 정의한다. 이러한 방식으로 사용자는 SIP MESSAGE 방법을 이용해서 라우팅 규칙을 설정할 수 있다.

(C) 라우팅 규칙을 설정하기 위한 스키마 포맷

도 9는 CF(210)에 라우팅 규칙을 설정하기 위한 본문 구조 요소들의 기본적 계층 구조를 보여주고 있다. 이 본문은 전술한 SIP 방법에 포함되어 있다. PoC 서버는 이 본문을 추출한 후 <표 3>에 정의되어 있는 스키마에 따라 검증한다.

도 9에 도시된 바와 같이, 본문은 "DispatcherRoutingRules"이라고 부르는 루트 요소 하나와 상태(State)라고 부르는 속성 하나를 갖는다. 이 상태(State)는 라우팅 규칙을 실행 및 정지시키기 위해 이용된다. 상기 루트 요소는 라우트(Route)라고 부르는 자식 요소를 하나 갖는데, 이 자식 요소는 라우팅 규칙을 정의한다. 라우트 요소는 상태(State), 유효 시간(ValidTime), 라우트 아이 디(RouteID)의 세 요소를 갖는다. 라우트 아이디(RouteID)는 특정 라우트에 ID값을 주기 위해 이용된다. 상태(State) 속성을 이용해서 라우팅 규칙을 각각 중지시킬 수 있다. 유효시간(ValidTime)은 라우트 집합을 위한 유효 지속 시간을 설정하기 위해 이용되며, 이는 유효 시간이 경과한 후 CF(210)가 라우트 규칙을 자동으로 중지시킬 수 있게 한다. 라우트 요소는 "URI"를 자식 요소로서 갖고 있다. 이 URI 요소는 사용자의 이름을 설정하기 위해 이용된다. 예를 들면, 디스패처가 사용자 B, C, D 사이에 라우트를 설정하기를 원한다고 하자. 그러면 디스패처는 URI 요소를 3개 포함하고, 이 요소의 값을 특정 플리트 멤버의 SIP URI로 설정할 것이다. 여러 경우에 대한 본문 구조의 몇 가지 예를 이하에서 설명하겠다. 하기의 <표 3>은 본문 구조 스키마 포맷을 도시하고 있다.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="urn:oma:params:xml:ns:DispatcherRoute" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:oma:params:xml:ns:DispatcherRoute"> <!-- Defination of Simple Elements --> <xs:element name="URI" type="xs:anyURI"/> <xs:attribute name="State"> <xs:restriction base="xs:string"> <xs:enumeration value="ON"/> <xs:enumeration value="OFF"/> </xs:restriction> </xs:attribute> <xs:attribute name="ValidTime" type="xs:time"/> <xs:attribute name="RouteID" type="xs:String"/> <xs:element name="Route"> <xs:complexType> <xs:element ref="URI" minOccurs=0 maxOccurs="unbounded"/> </xs:complexType> <xs:attribute ref="RouteID" use="Required"/> <xs:attribute ref="ValidTime" use="Optional"/> <xs:attribute ref="State" use="Required"/> </xs:element> <xs:element name="DispatcherRoutingRules"> <!-- Defination of Root Elements --> <xs:complexType> <xs:element ref="Route" minOccurs="0" maxOccurs="unbounded"/> </xs:complexType> <xs:attribute ref=”State” use=”Required”> </xs:element> </xs:schema>

예를 들어 디스패처 A는 플리트 멤버 B, C, D를 위한 라우팅 규칙을 CF에 설정하기를 원한다. 따라서, 디스패처는 전술한 방법 중 하나를 이용해서 규칙을 CF에 보낼 수 있다. 이와 같은 예일 경우에는 하기의 <표 4>와 같은 본문 구조를 사용한다.

<?xml version="1.0" encoding="UTF-8"?> <DispatcherRoutingRules xmlns=="urn:ietf:params:xml:ns: DispatcherRoute state="ON""> <Route RouteID="r1" State="ON"> <URI>b@exmple.com</URI> <URI>c@exmple.com</URI> <URI>d@exmple.com</URI> </Route> </DispatcherRoutingRules>

예를 들어, 디스패처 A는 사용자 B와 C가 직접 통신할 수 있어야 하고 사용자 D, E 및 F가 직접 통신할 수 있어야 하므로 규칙을 설정하기를 원한다. 이와 같은 예일 경우에는 디스패처는 하기의 <표 5>와 같은 본문을 이용해서 규칙을 설정한다.

<?xml version="1.0" encoding="UTF-8"?> <DispatcherRoutingRules xmlns=="urn:ietf:params:xml:ns: DispatcherRoute state="ON""> <Route RouteID="r1" State="ON"> <URI>b@exmple.com</URI> <URI>c@exmple.com</URI> </Route> <Route RouteID="r2" State="ON"> <URI>d@exmple.com</URI> <URI>e@exmple.com</URI> <URI>f@exmple.com</URI> </Route> </DispatcherRoutingRules>

또 다른 예로 디스패처 A가 CF에 설정된 라우팅 규칙을 중지시키기를 원한다. 이와 같은 예일 경우에는 디스패처는 하기의 <표 6>와 같은 본문을 이용해서 규칙을 설정한다.

<?xml version="1.0" encoding="UTF-8"?> <DispatcherRoutingRules xmlns=="urn:ietf:params:xml:ns: DispatcherRoute state="OFF""> </DispatcherRoutingRules>

그러면 이제 본 발명에 따른 논리적 정보 흐름에 대하여 도 10을 참조하여 살펴보도록 한다.

도 10은 본 발명에 따른 논리적 정보 흐름을 보여주고 있다. 이 시나리오에서는 디스패처 사용자 A가 있고, 다른 플리트 멤버 사용자 B, 사용자 C, 그리고 사용자 D가 디스패처 그룹 내에 있다. 이 시나리오의 논리적 단계들은 다음과 같다.

10단계에서 디스패처 A의 사용자가 디스패처 세션을 개시하기를 원하며, 디스패처 A는 디스패처 태그를 포함하는 디스패처 세션 개설을 위한 디스패처 세션 참여 요청 메시지를 제어 서버인 CF로 전송한다. 즉, 디스패처 A는 INVITE SIP 요청을 디스패처 태그와 함께 제어 서버인 CF로 보낸다.

12단계에서 CF는 INVITE 요청을 검증하고 디스패처 A의 디스패처 역할의 유효성을 점검한다.

이후 14 및 18단계를 통해 CF는 디스패처 그룹의 모든 나머지 플리트 멤버에게 디스패처 세션 참여 요청 메시지인 INVITE를 보낸다.

그러면 플리트 멤버들은 20단계 내지 24단계를 통해 200 OK 응답으로 답신함으로써 초대를 수락하며, 26단계에서 디스패처 세션이 개시된다. 이후 28단계에서 플리트 B의 사용자가 미디어를 보내기를 원한다면 언제라고 발언권(floor)을 요청할 수 있으며, 플리트 B가 발언권을 얻고 나면 28단계에서 미디어를 제어 서버로 보낸다.

그러면 제어 서버는 수신한 미디어를 30단계에서 디스패처 A로 전달한다.

이후 디스패처가 32단계에서 디스패처의 사용자가 플리트 B의 사용자와 플리트 D이 사용자 사이에서 통신이 가능하게 하기를 원한다고 가정한다.

그러면 디스패처는 34단계에서 라우팅 규칙 요청을 제어 서버에게 보내어 플리트 B와 플리트 D 사이에서 통신이 가능하게 한다. 이때 라우팅 규칙 요청이라 함은 상기에서 기술한 바와 같이 소정의 플리트 멤버들 간의 직접 통신을 위한 라우팅 규칙을 설정하기 위한 라우팅 규칙을 라우팅 규칙 설정 요청 메시지에 포함시켜 제어 서버로 전송하여 라우팅 규칙을 설정하도록 요청하는 것을 의미한다. 또한, 여기서, 라우팅 규칙 설정 요청 메시지는 상기에서의 시스템 메시지와 동일한 메시지이다.

이후 제어 서버는 디스패처로부터 수신한 라우팅 규칙 요청을 검증하고 이들 규칙을 저장한다. 그리고 제어 서버는 라우팅 규칙 요청에 대한 응답을 디스패처 A에게 보낸다.

이후 제어 서버는 설정된 규칙에 대한 통보를 사용자 B와 사용자 D에게 보낸다.

이후 플리트 D가 보낼 미디어가 있다고 가정하면, 44단계에서 그 미디어를 제어 서버로 보낸다. 그러면 제어 서버는 이 미디어를 디스패처 A에게 전달한다.

또한, 제어 서버는 디스패처 A가 설정한 라우팅 규칙에 따라 상기 미디어를 플리트 B에게도 전달한다.

전술한 예에서 제시한 방식으로 본 발명은 플리트 멤버 사이에서 통신이 가능하도록 라우팅 규칙을 설정하는 매우 쉽고 융통성 있는 방법을 제공한다. 이는 플리트 멤버 사이에 별도의 애드혹 세션을 설정하기 위한 세션 초기화 요청을 보내는 데에 필요한 다량의 자원을 절약한다.

상기한 바와 같이 본 발명은 라우팅 규칙을 설정함으로써 디스패처 세션의 플리트 멤버 사이에서 통신이 가능하게 하는 매우 쉽고 융통성 있는 방법을 제시한다. 이를 위해 본 발명은. 새로운 MBCP 메시지 또는 기존 MBCP 메시지를 이용하여 라우팅 규칙을 설정하기 위한 사용자 평면 방법을 제시한다. 또한, 본 발명은 라우팅 규칙을 설정하기 위한 제어 평면 방법을 제시한다.

또한, 본 발명은 일반 MBCP 메시지(MBCP 시스템 메시지)를 이용하여 사용자가 임의 개수의 새로운 MBCP 메시지를 개발할 수 있는 융통성을 제공한다. 이를 시스템 메시지라고 부른다. 이 RTCP APP 메시지는 32개로 제한되기 때문이다. PoC와 같은 향후 애플리케이션은 더 많은 메시지를 요구할 수 있으므로, 이 시스템 메시지는 임의 개수의 MBCP 메시지를 생성할 수 있는 융통성을 제공한다.

도 1은 일반적인 디스패처를 이용하는 경우의 시나리오를 도시한 도면,

도 2는 본 발명의 실시 예에 따라 사용자 평면 라우팅 규칙 설정을 설명하기 위한 도면,

도 3은 본 발명의 실시 예에 따라 시스템 메시지 패킷 포맷을 도시한 도면,

도 4는 본 발명의 실시 예에 따라 라우트 규칙 설정을 위한 라우트 시스템 메시지를 도시한 도면,

도 5는 본 발명의 실시 예에 따라 라우트 통보 패킷 시스템 메시지를 도시한 도면,

도 6은 본 발명의 실시 예에 따라 라우팅 규칙을 설정하기 위한 미디어 버스트 요청 메시지를 도시한 도면,

도 7은 본 발명의 실시 예에 따라 CF에서 라우팅 규칙을 설정하기 위한 INFO에 기초한 해결책을 도시한 도면,

도 8은 본 발명의 실시 예에 따라 CF에서 라우팅 규칙을 설정하기 위한 MESSAGE에 기초한 해결책을 도시한 도면,

도 9는 본 발명의 라우팅 규칙을 설정하기 위한 본문 구조 요소들의 기본적 계층 구조를 도시한 도면,

도 10은 본 발명에 따라 프리트 멤버들 간 직접 통신이 되도록 제어하기 위한 신호 흐름도.

Claims (10)

1. 디스패처와 복수의 플리트 멤버와 디스패처와 복수의 플리트 멤버 간 세션 개설 제어 및 관리하는 제어 서버를 포함하고, 상기 플리트 멤버 간 라우팅 규칙을 생성하기 위한 시스템에 있어서,

   상기 복수의 플리트 멤버들 중 직접 통신을 원하는 플리트 멤버들의 정보를 포함하는 라우팅 규칙을 라우팅 규칙 설정 요청 메시지에 포함시켜 전송하는 상기 디스패처와,

   상기 라우팅 규칙 설정 요청 메시지가 수신되면 상기 라우팅 규칙을 저장한 후, 디스패처 세션에 참여하고 있는 소정의 플리트 멤버로부터 미디어가 수신되면 상기 저장된 상기 디스패처의 라우팅 규칙에 포함된 플리트 멤버들로 미디어를 전달하는 상기 제어 서버를 포함하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 시스템.
2. 제 1항에 있어서, 상기 디스패처는,

   상기 복수의 플리트 멤버 간의 디스패처 세션이 개설된 후 상기 라우팅 규칙 설정 요청 메시지를 전송하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 시스템.
3. 제 1항에 있어서, 상기 제어 서버는,

   상기 수신된 미디어를 상기 디스패처에게 전달하고, 상기 디스패처의 라우팅 규칙에 포함된 플리트 멤버들에게 전달하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 시스템.
4. 제 1항에 있어서, 상기 제어 서버는,

   상기 라우팅 규칙 설정 요청 메시지가 수신되면 상기 라우팅 규칙을 저장한 후, 상기 라우팅 규칙 설정 요청 메시지에 대한 응답 메시지를 상기 디스패처로 전송하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 시스템.
5. 제 1항에 있어서, 상기 제어 서버는,

   상기 라우팅 규칙 설정 요청 메시지가 수신되면 상기 라우팅 규칙을 저장한 후, 상기 라우팅 규칙에 포함된 플리트 멤버들에게 상기 라우팅 규칙을 통보하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 시스템.
6. 디스패처와 복수의 플리트 멤버와 디스패처와 복수의 플리트 멤버 간 세션 개설 제어 및 관리하는 제어 서버를 포함하는 시스템에서 상기 플리트 멤버 간 라우팅 규칙을 생성하기 위한 방법에 있어서,

   상기 디스패처가 상기 복수의 플리트 멤버들 중 직접 통신을 원하는 플리트 멤버들의 정보를 포함하는 라우팅 규칙을 라우팅 규칙 설정 요청 메시지에 포함시켜 상기 제어 서버로 전송하는 과정과,

   상기 제어 서버가 상기 라우팅 규칙 설정 요청 메시지가 수신되면 상기 라우팅 규칙을 저장하는 과정과,

   상기 제어 서버는 디스패처 세션에 참여하고 있는 소정의 플리트 멤버로부터 미디어가 수신되면 상기 저장된 상기 디스패처의 라우팅 규칙에 포함된 플리트 멤버들로 미디어를 전달하는 과정을 포함하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 방법.
7. 제 6항에 있어서,

   상기 전송 과정 전에 상기 디스패처가 상기 복수의 플리트 멤버 간의 디스패처 세션 개설을 위한 동작을 수행하는 과정을 더 포함하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 방법.
8. 제 6항에 있어서,

   상기 제어 서버가 상기 수신된 미디어를 상기 디스패처에게 전달하는 과정을 더 포함하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 방법.
9. 제 6항에 있어서, 상기 저장 과정 수행 후,

   상기 제어 서버가 상기 라우팅 규칙 설정 요청 메시지에 대한 응답 메시지를 상기 디스패처로 전송하는 과정을 더 포함하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 방법.
10. 제 6항에 있어서, 상기 저장 과정 수행 후,

    상기 제어 서버가 라우팅 규칙에 포함된 플리트 멤버들에게 상기 라우팅 규칙을 통보하는 과정을 더 포함하는 것을 특징으로 하는 상기 플리트 멤버 간 라우팅 규칙 생성 방법.

Images