KR20070060030A - 프레젼스 서비스 제공을 위한 시스템 및 방법 - Google Patents

Abstract

본 발명은 프레젼스 서버를 포함하여 외부객체에 의해 프레젼스 소스의 동작을 제어하기 위한 시스템 및 방법에 관한 것이다.

이를 위해 본 발명은 프레젼스 서비스 제공을 위해, 사용자 에이젼트가 이벤트 패키지(event package)를 사용하여 EPA(Event Publication Agent)로 퍼블리케이션 룰에 대한 동기화를 요청하면, 상기 EPA가 상기 퍼블리케이션 룰에 대한 동기화에 대한 응답 메시지를 상기 사용자 에이젼트로 전송하고, 상기 사용자 에이젼트가 타켓 상태(target state) 정보를 포함하는 퍼블리케이션 룰을 전달하고, 상기 EPA는 퍼블리케이션 룰이 업 데이트되면 상기 업 데이트 된 퍼블리케이션 룰을 알릴 수 있도록 한다.

프레젼스, Publication Rule, EPA, ESC.

Description

프레젼스 서비스 제공을 위한 시스템 및 방법{SYSTEM AND METHOD FOR PROVIDING A PRESENCE SERVICE}

도 1은 일반적인 프레젼스 서비스를 구현하는 아키텍쳐를 도시하는 도면,

도 2는 일반적인 프레젼스 서비스를 수행하기 위한 신호 흐름도,

도 3a 내지 3d는 도 2의 프레젼스 서비스 수행 시 송수신되는 메시지 포맷을 도시하는 도면,

도 4는 일반적인 OMP Presence SIMPLE V1.0 아키텍처를 도시하는 도면,

도 5는 일반적인 프레젼스 소스에서의 프레젼스 서비스를 위한 동작 흐름도,

도 6은 본 발명의 실시 예에 따라 일정 간격으로 상태를 PUBLISH하도록 하는 Rule을 도시하는 도면,

도 7은 본 발명의 실시 예에 따라 즉각적(instant)으로 State을 PUBLISH하도록 하는 Rule을 도시하는 도면,

도 8은 본 발명의 실시 예에 따라 Publication Rule의 취소(cancel)를 수행하기 위한 Rule을 도시하는 도면,

도 9는 본 발명의 실시 예에 따라 EPA Registration를 위해 EPA와 Registrar간의 신호 흐름도,

도 10은 도 9의 EPA Registration 과정에 따라 송수신되는 메시지 포맷을 도 시하는 도면,

도 11은 본 발명의 실시 예에 따른 EPA 제어 메커니즘의 신호 흐름도,

도 12와 13a 내지 13k는 도 11의 EPA 제어 메커니즘의 신호 흐름에 따라 송수신되는 메시지 포맷을 도시하는 도면.

본 발명은 프레젼스 서버를 포함하여 외부객체에 의해 프레젼스 소스의 동작을 제어하기 위한 시스템 및 방법에 관한 것이다.

일반적으로 프레젼스 서비스(Presence Service)는 일련의 장치(device)들을 통한 어느 관심 대상 예를 들어 사용자(user), 그룹(group) 등의 커뮤니케이션(communication)의 능력(ability)과 의지(willingness) 및 현 상태 등을 이 대상에 관심을 가지고 있는 일련의 객체들에게 적절히 전달하는 서비스를 말한다. 전달받은 관심대상의 상태 정보를 토대로 일련의 객체들은 관심대상의 현 상황을 파악할 수 있고, 원하는 때에 가장 최적한 즉, 가장 성공할 확률이 높은 커뮤니케이션(communication) 수단을 선택하여 관심대상에 접촉을 시도할 수도 있다.

도 1을 참조하면, 프레젼스 서비스의 단순화된 아키텍쳐(Architecture)를 보여준다. 프레젼스 서비스의 관심대상을 존재자(Presentity)라 하며, Presentity와 관련된 정보 즉, 프레젼스 정보(Presence Information)는 프레젼스 소스(Presence Source)(104) 들을 통하여 프레젼스 서버(Presence Server)(102)에게 전달(publish)되게 된다. 프레젼스 서버(102)는 이러한 프레젼스 정보들을 통합(composition)하여 Presentity에 대한 통합된 프레젼스 정보를 생성하여, Presentity에 관심을 가지고 있는 객체(subscribed) 즉, 인지자(Watcher)(100)들에게 허락된(authorized) 프레젼스 정보을 추려(selectively)내어 전달(notification)한다.

이와 같은 프레젼스 서비스의 엔티티(Entity)들 간의 신호 흐름을 도 2를 참조하여 살펴보도록 한다. 프레젼스 소스(104)와 프레젼스 서버(102)간에는[RFC3856]에 정의된 Publication mechanism이 적용되어, Presentity에 대한 프레젼스 정보(PI : Presence Information)를 프레젼스 소스(102) 또는 이벤트 공고 에이젼트(EPA : Event Publication Agent)가 204-205단계와 208-209단계 및 210-211단계를 통해 SIP PUBLISH를 사용하여 프레젼스 서버(104) 또는 Event State Compositor (ESC)에게 전달한다. 이하, 프레젼스 정보들을 하나로 통합하는 기능을 수행하는 프레젼스 서버(104)는 ESC(Event State Compositor)로 기재하도록 한다. 또한, 프레젼스 정보를 제공하는 기능을 수행하는 프레젼스 소스(102)는 EPA(Event Publication Agent)로 기재하도록 한다.

한편, 인지자(Watcher)(100)와 프레젼스 서버(102)간에는 [RFC3856]에 정의된 Presence Event Package가 적용되어, 인지자(Watcher)가 200단계 내지 203단계를 통해 Presentity에 대한 프레젼스 정보(PI)를, 프레젼스 이벤트(Presence Event)에 대한 SIP SUBSCRIBE를 사용하여 요청(request)한다.

프레젼스 서버 또는 Presence Agent (PA)(102)는 상기의 204단계, 208단계, 210단계에서 프레젼스 소스(104) 또는 Presence User Agent (PUA)에게서 전달받은 프레젼스 정보을 SIP NOTIFY를 사용하여 인지자(Watcher)(100)에게 전달한다.

상기한 도 2의 신호 흐름에서 사용되는 메시지 포맷(message exchange)의 예를 도 3과 같이 도시할 수 있다. 200단계는 (a), 201단계는 (b), 202단계는 (c), 203단계는 (d), 204단계는 (e), 205단계는 (f), 206단계는 (g), 208단계는 (h), 209단계는 (i), 210단계는 (j), 211단계는 (k), 212단계는 (l), 213단계는 (m), 214단계는 (n)과 같은 메시지를 전송할 수 있다. 이러한 프레젼스 서비스는 OMA Presence SIMPLE V1.0 에서 구현될 수 있다.

상기와 같은 프레젼스 서비스를 지원하는 OMA Presence SIMPLE V1.0의 아키텍쳐는 도 4와 같이 도시할 수 있다.

상기 기술된 기존 프레젼스 서비스 아키텍쳐에서, 프레젼스 소스(104)는 자신의 관점에서 바라본 Presentity에 대한 가장 업 데이트(up-to-date)한 프레젼스 정보을 유지하며, 이 프레젼스 정보에 업 데이트(update)가 있을 때마다 즉, 프레젼스 정보에 변화가 있을 때마다 프레젼스 서버(102)에게 SIP PUBLISH 메시지(message)를 통해 프레젼스 정보를 전달한다. 프레젼스 서버(102)는 각 프레젼스 소스(104)에서 전달받은 프레젼스 정보들을 정해진 메카니즘에 따라 하나로 통합(compose)하여 psentity에 대해 가장 업 데이트(up-to-date)하며 통합된 프레젼스 정보를 유지하고 있다. 또한, 프레젼스 서버(102)는 인지자(Watcher)(100)들의 프레젼스 이벤트 패키지(presence Event Package)을 사용한 SIP SUBSCRIBE 요청에 따라, 이 프레젼스 정보를 SIP NOTIFY를 사용하여 정해진 Policy에 따라 적절히 배분(distribute)한다. 이때 인지자(Watcher)(100)들의 프레젼스 이벤트 패키지(presence Event Package)를 사용한 SIP SUBSCRIBE 요청은 프레젼스 정보가 업데이트 될 때마다 프레젼스 정보를 제공받기 위한 요청이다.

이와 같은 현재 프레젼스 서비스 아키텍쳐에서의 프레젼스 소스(104)의 동작은 도 5와 같이 도시할 수 있다.

500단계에서 프레젼스 소스(104)가 인에이블(enabled) 되면, 502단계에서 Presentity에 대한 프레젼스 정보가 있는지를 검사하여 프레젼스 정보가 있으면, 504단계로 진행하여 프레젼스 정보를 프레젼스 서버(102)로 PUBLISH한다. 이후, 506단계에서 프레젼스 소스(104)는 PUBLISH된 프레젼스 정보에 대한 업데이트가 있으면 508단계로 진행하여 업데이트 된 프레젼스 정보를 프레전스 서버(102)로 PUBLISH한다.

상기와 같은 프레젼스 소스(104)는 다음과 같은 두가지 행동양식(behavior)이 관찰된다.

첫째, 프레젼스 소스의 동작은 암묵적이다. 현재 프레젼스 서비스 아키텍쳐에서 프레젼스 소스는 항상 적절히 동작을 하고 있다고 가정되며, 프레젼스 소스의 동작을 초기화(enable)나 마무리(disable)시키는 방법이 없다. 따라서, 그 동작이 암묵적이다.

둘째, 프레젼스 소스의 행동양식은 독립적이다. Presentity에 대한 프레젼스 정보 업데이트가 있는지에 대해 자체적으로 판단하며, 프레젼스 정보에 대한 업데 이트가 있을 때마다 publication을 한다. 즉, 외부로부터의 요청(request)나 ㅈ제제어(control) 없이 스스로 판단하여 publication을 결정하여 수행하므로, 그 행동양식이 독립적이다.

이러한 프레젼스 소스의 행동양식은, [PDM]에 기술되었듯이, 소정 사용자(즉, Presentity)의 일련의 장치들을 이용한 커뮤니케이션의 능력(ability)과 의지(willingness)의 전달이라는 프레젼스 서비스의 기존 목적과, 이에 부합하는 기존 아키텍쳐에서는 어느 정도 무시가 될 수 있다. 이는, 기존 아키텍쳐에서, 프레젼스 정보는 주로 커뮤니케이션의 능력(ability)과 의지(willingness)와 같은 분리된(discrete)한 정보들로 구성될 것이다. 또한, 이를 publication하는 프레젼스 소스들은 주로 사용자 단말(device)이나 홈 가입자 서버(HSS : Home Subscriber Server)와 같은 persistent network entity들로 구성될 것이어서 그 동작의 enable/disable이 직접으로 이루어지거나 또는 전혀 무관하기 때문이다.

그러나, [RPID]에서도 볼 수 있듯이, Presentity의 커뮤니케이션 능력 및 의지 전달이라는 본연의 프레젼스 서비스의 목적이, Presentity의 현재 상태(status)와 같은 Presentity의 제반 정보를 알리는 메커니즘으로까지 확장되고 있음을 고려할 때, 상기 관찰된 프레젼스 소스의 행동양식은 다음과 같은 두가지 문제점을 내포하고 있다.

첫째, 프레젼스 소스의 암묵적인 동작은, 프레젼스 정보에 대한 선택적(selective)인 프레젼스 정보 요청과 publication을 불가능하게 한다. 예를 들어, Presentity가 사용하는 장치의 어느 특정 능력(capability)에 대한 어느 특정 시점의 snapshot을 알고자 하면, 이에 대한 프레젼스 정보 publication request를 요구된 시점에 이를 담당하는 프레젼스 소스에게 전달하여 해당 프레젼스 정보의 snapshot이 publication되어야 한다. 그러나, 현재의 프레젼스 서비스 아키텍쳐에서는, 인지자(Watcher)가 [Filter]에 기술된 방법을 이용하여 프레젼스 정보의 특정부분을 프레젼스 서버에게 선택적으로 요청은 할 수 있으나, 프레젼스 서버에게 해당 정보의 publication을 담당하는 프레젼스 소스가 사전에 활성화되어 있지 않으면, 인지자(Watcher)가 요청한 프레젼스 정보 정보를 알 수 있는 방법이 없다.

둘째, 독립적인 프레젼스 소스의 행동양식은 제어되지 않은(uncontrollable) 결과를 초래할 수 있다. 예를 들어, 소정 프레젼스 소스의 publication의 대상이 되는 프레젼스 정보가 위치정보에 관한 것이라고 하면, 이를 담당하는 프레젼스 소스는 위치정보의 업데이트가 있을 때마다 해당 프레젼스 정보를 프레젼스 서버에게 publication할 것이다. 그러나, 거의 연속적(quasi-continuous)이라는 위치정보의 특성은, 잦은 프레젼스 정보 업데이트 및 이에 따른 publication을 초래하여, SIP 기반 네트워크에 부담과 프레젼스 소스, 프레젼스 서버의 높은 처리능력을 요구하게 될 것이다. [RFC3903]에서는, publication expiration interval의 조정과, Retry-After SIP header를 503 Server Unavailable SIP response에 포함시키는 방법들을 이용하여, 프레젼스 서버가 프레젼스 소스의 publication rate을 간접적으로 제어할 수 있는 매커니즘을 제안한다. 그러나, publication expiration interval의 조정방법은 프레젼스 정보 업데이트가 아니라 프레젼스 정보 리프레쉬(refresh)를 위한 publication의 rate 제어에만 사용이 가능하며, Retry-After SIP header를 사용하는 방법은 다음 publication에만 적용된다. 따라서, [RFC3903]에서 제시된 방법들은, 그 사용이 매우 제한적이며 근본적인 해결책이 되지 못한다.

따라서, 본 발명은 ESC를 포함하여 외부객체에 의해, EPA의 publication 동작을 제어할 수 있기 위한 시스템 및 방법을 제공함에 있다.

또한, 본 발명은 EPA를 요구(on-demand)에 따라 활성화(activate) 및 비활성화(deactivate)시킬 수 있어, 특정 상태(State)에 대한 solicitation을 가능하게 하기 위한 시스템 및 방법을 제공함에 있다.

발명의 실시 예에 따라, 프레젼스 서비스 제공을 위한 시스템에 있어서, 대상 프레젼스 정보(target state)에 대해 요청되는 EPA(Event Publication Agent)의 퍼블리케이션 동작을 퍼블리케이션 룰(Publication Rule)을 사용하여 기술하고, 상기 퍼블리케이션 룰을 대상 프레젼스 정보의 퍼블리케이션을 담당하는 EPA에게 전달하고, 필요에 따라 상기 퍼블리케이션 룰을 업 데이트하거나 취소할 수 있고, 본 발명에서 제안되는 이벤트 패키지(event package)를 사용하여 상기 EPA로 퍼블리케이션 룰에 대한 동기화를 요청하는 룰러(Ruler)와, 퍼블리케이션 할 수 있는 프레젼스 정보들의 정보를 Media Feature Tag를 이용하여 SIP 레지스트라 (Registrar) 에 등록(registration)하고, 상기 룰러들로부터 상기 프레젼스 정보에 대한 상기 퍼블리케이션 룰들을 전달받아 취합하고, 취합된 퍼블리케이션 룰에 따라 상기 프레젼스 정보에 대한 ESC(Event State Compositor)로의 퍼블리케이션을 수행하고, 상기 퍼블리케이션 룰에 대한 업 데이트나 취소 요청이 있으면 이에 따라 상기 퍼블리케이션 룰을 변경하고 변경된 룰에 따라 상기 프레젼스 정보에 대한 ESC로의 퍼블리케이션 동작을 변경하고, 상기 룰러로부터 상기 이벤트 패키지를 이용하여 상기 퍼블리케이션 룰에 대한 동기화 요청이 있으면 이에 대한 응답 메시지를 상기 룰러로 전송하고, 퍼블리케이션 룰이 업 데이트되면 상기 업 데이트 된 퍼블리케이션 룰을 상기 룰러에게 알리는 상기 EPA와, 상기 EPA가 등록한 Media Feature Tag 정보에 따라 대상 프레젼스 정보에 대한 퍼블리케이션 룰을 대상 프레젼스 정보의 퍼블리케이션을 담당하는 EPA로 라우팅을 결정하는 SIP 레지스트라 (Registrar)를 포함하여 구성됨을 특징으로 한다.

본 발명의 실시 예에 따라, 프레젼스 서비스 제공을 위한 방법에 있어서, EPA(Event Publication Agent)가 퍼블리케이션 할 수 있는 프려젼스 정보들을 Media Feature Tag를 이용하여 SIP 등록하는 과정과, 룰러가 대상 프레젼스 정보에 대한 퍼블리케이션 룰을 해당 EPA에게 보내는 과정과, 상기 EPA가 등록한 Media Feature Tag 정보에 따라 대상 프레젼스 정보에 대한 퍼블리케이션 룰을 대상 프레젼스 정보의 퍼블리케이션을 담당하는 EPA로 라우팅하는 과정과, 상기 EPA가 상기 퍼블리케이션 룰을 전달 받는 과정과, 상기 EPA가 이러한 퍼블리케이션 룰에 따라 대상 프레젼스 정보에 대한 ESC(Event State Compositor)로의 퍼블리케이션을 수행 하는 과정과, 상기 룰러가 상기 퍼블리케이션 룰에 대한 업 데이트 또는 취소를 통해 상기 퍼블리케이션 룰에 대한 변경을 요청하는 과정과, 상기 EPA가 상기 퍼블리케이션 룰의 변경 요청을 전달 받는 과정과, 상기 EPA가 변경된 퍼블리케이션 룰에 따라 ESC로의 퍼블리케이션을 수행하는 과정과, 상기 룰러가 대상 프레젼스 정보에 대한 이벤트 패키지(event package)를 사용하여 EPA로 퍼블리케이션 룰에 대한 동기화를 요청하는 과정과, 상기 EPA가 상기 퍼블리케이션 룰에 대한 동기화에 대한 응답 메시지를 상기 룰러로 전송하는 과정과, 상기 EPA는 퍼블리케이션 룰이 업 데이트되면 상기 업 데이트 된 퍼블리케이션 룰을 상기 룰러에게 알리는 과정을 포함하는 것을 제공함을 특징으로 한다.

여기서, Ruler역할로는 User Agent, ESC, 또는 그 어떤 entity도 가능하다. 해당 entity에 대한 Rule로서의 검증은 EPA가 authorization check을 통해 수행하게 된다.

본 발명에서는, EPA 제어를 위해서 하기와 같은 (1) 퍼블리케이션 룰(publication Rule) 기술 및 표현 방법, (2) Publication Rule 전달 방법, (3) Publication Rule 처리 방법, (4) Publication Rule 동기화 방법, (5) Publication Rule 업데이트 방법, (6) Publication Rule 취소 방법, (7) EPA Identification 및 라우팅 방법, (8) Publication Rule 구현 방법에 대하여 제안하도록 한다.

(1) Publication Rule 기술 및 표현 방법

본 발명에서는 EPA 제어 파라미터(Control Parameter) 또는 Publication Rule 기술 및 표현 방법을 살펴보도록 한다.

먼저, Publication Rule 기술 방법을 살펴보면, 본 발명에서 EPA에 대한 제어 파라미터의 기술을 크게 헤더(Header) 정보와 Publication Rule의 두 가지 부분으로 나누어 제안한다.

Header 정보는 기술된 Publication Rule을 EPA로 전달하고 이를 EPA가 취합하는데 사용되는 정보들을 포함한다. Publication Rule은, 실제 EPA의 publication을 제어할 수 있는 파라미터들을 기술하는데 사용된다. Header 정보는 기술될 Publication Rule에 대한 일반적인 정보들이 기술된다. 이 정보들은, 담당 EPA로의 라우팅(routing) 및 EPA의 Presence Rule Composition 자세한 사항은 하기에서 기술하도록 한다. 기술된 Publication Rule의 적용을 위해 활용되는 정보들을 나타낸다. 본 발명에서는, 이를 위해 다음과 같이 Header 정보는 Requestor정보, Time stamp정보, EPA to control정보, Target state to control정보, Target entity to control정보를 포함할 수 있다.

첫번째로 Requestor 정보는 EPA 제어를 요청한 엔티티(entity)에 대한 정보이다. 이 정보는 요청자(requestor)의 SIP URI가 기술된다. 이 정보는 EPA에 의해 요청자가 기술된 Publication Rule에 따라 해당 상태의 publication을 제어할 권한이 있는지를 판단하는데 활용될 수 있다.

두번째로 Time stamp 정보는 Publication Rule이 요청된 시점을 나타내는 정보이다.

세번째로 EPA to control 정보는 제어할 EPA를 identity할 수 있는 SIP URI 가 기술되며, 이를 위해 Globally Routable User Agent URI (GRUU, [GRUU])가 사용될 수 있다. 따라서, 이 정보는 Publication Rule을 EPA로 전달시, 라우팅(routing) 정보로 활용이 된다. 이 정보가 기술되어 있지 않다면, 라우팅 프록시(Routing Proxy)는 다음에 기술될 타겟 상태(target state)와 타겟 엔티티(target entity) 정보를 이용하여 타켓(target) EPA로의 라우팅 정보를 알아낼 수 있다. 두 가지 정보가 모두 기술되는 경우, EPA to control 정보에 의한 라우팅 정보가, 타겟 상태와 타겟 엔티티(Entity) 정보에 의해 암시되는 라우팅 정보보다 우선적으로 활용될 수 있다.

네번째로 Target state to control 정보는 Publication 제어의 대상이 되는 타켓 상태를 지정하는 정보이다. 예를 들면, 위치 정보(location state)와 같은 정보이다. 이러한 정보 값은, EPA가 SIP RESISTRATION시 능력(capability)으로 등록한 미디어 특징 테그(media feature tag)로 표시된다. 이 정보는, 다음에 기술되는 타겟 엔티티(Entity) 정보와 함께, 상태의 publication을 담당하는 EPA를 identity하는 라우팅 정보로 활용될 수 있다. 그러나, 위에 기술되었듯이, EPA to control 정보에 의해 기술되는 EPA의 URI 정보가 이미 기술되었다면, 이 정보가 우선적인 라우팅 정보로 활용이 된다.

다섯번째로, Target entity to control 정보는 Publication 제어의 대상이 되는 엔티티(entity)를 의미한다 예를 들면, "sip:brian@example.com"와 같은 정보이다. 이 엔티티(entity)의 SIP AOR (Address of Record)가 기술된다. 이 정보는, 위에 기술된 타겟 상태 정보와 함께, 이 상태의 publication을 담당하는 EPA를 identity하는 라우팅 정보로 활용될 수 있다. 그러나, EPA to control에 의해 기술되는 EPA의 URI 정보가 이미 기술되었다면, 이 정보가 우선적인 라우팅 정보로 활용이 된다.

다음으로 Publication Rule 정보를 살펴보도록 한다. 본 발명에서는, Publication Rule이 다음과 같이 Target state to control 정보, Target entity to control 정보, Valid time 정보, Publication trigger mechanism 정보, State maximum accuracy 정보, Cancel 정보들을 포함할 것을 제안한다.

첫번째로 Target state to control 정보는 Publication Rule이 적용될 ㅅ상태를 나타내며, Target state to control 정보 값은 EPA가 SIP RESISRATION시 capability로 등록한 미디어 특징 태그(media feature tag)로 표시된다.

두번째로 Target entity to control 정보는 Publication Rule이 적용될 대상을 나타내며, 대상이 되는 엔티티(entity)의 SIP AOR URI로 표현된다.

세번째로 Valid time 정보는 기술된 Publication Rule이 유효한 기간을 나타낸다. 이는 from과 until의 조합이나 또는 duration으로 표현된다. from / until로 유효한 기간을 표현할 경우, from은 rule의 적용되기 시작하는 시점을, until은 rule의 적용이 끝나는 시점을 표현한다. 그 값들이 기술되지 않은 경우는 indefinite을 의미한다. 즉, from만 기술되고, until이 기술되지 않은 경우, 제시되는 rule은 from 시점부터 이 rule이 cancel 될 때까지 계속 유효함을 의미한다. Until만 기술된 경우는, 제시된 rule은 곧바로 적용되며, 이 rule이 취소(cancel)되지 않는 한, until 시점까지 유효함의 조합으로 표현이 된다. duration으로 유효 한 기간을 표현할 경우, duration의 값은 sec로 해석이 되며, 중간에 취소되지 않는한, 이 rule은 곧바로 duration 동안 적용이 된다. from, until, duration이 모두 기술되지 않은 경우에는, 이 rule이 취소될 때까지 indefinite하게 유효함을 나타낸다. from, until, duration이 모두 기술된 경우는, 유효하지 않은(invalid)한 경우이다. duration의 값이 0인 경우는, 기술된 rule은 즉시 적용되며, EPA는 곧바로 타겟 상태와 타켓 엔티티(Entity)에 의해 결정되는 상태를 ESC에게 PUBLISH해야 한다. PUBLISH후, 이 rule은 무의미해지며 EPA의 rule set으로부터 삭제된다.

네번째로 Publication trigger mechanism 정보는 해당 상태의 publication을 트리거링(trigger)하는 방법을 기술하는 정보이다. 예를 들어 이러한 정보는 해당 상태의 업데이트가 있을 때마다 publication하는 방법, 일정 시간 간격(time interval)에 따라 규칙적으로 publication하는 방법을 포함한다.

다섯번째로 State maximum accuracy 정보는 Publication될 타겟 상태의 최대 정확도를 기술하는 정보이다. Publication될 상태는 요구된 최대 정확도보다 자세하면 안 된다. Accuracy에 대한 의미는 해당 상태에 따라 다르게 정의된다.

여섯번째로 Cancel 정보는 상기 기술된 유효 시간(valid time) 동안, 타겟 상태과 타겟 엔티티(entity)에 의해 결정되는 상태에 대한 Publication Rule을 삭제된다. 이 때, 유효 시간이 기술되어 있지 않으면, 타겟 상태과 타겟 엔티티(entity)에 의해 결정되는 상태의 모든 기존의 Publication Rule이 삭제된다. Publication Rule이 없는 경우, default Publication Rule은, [RFC3903]에 정의된 대로, 해당 상태에 업 데이트가 있을 때 ESC로 PUBLISH하는 것이다.

그러면, 이제 Publication Rule 표현 방법에 대하여 살펴보도록 한다. 상기에 기술된 정보들은 표현하기 위해, 본 발명에서는 다음과 같이, XML을 이용하는 방법을 제안한다. Publication Rule 전달 방법에 대하여 도 6 내지 도 8을 참조하여 살펴보도록 한다. 도 6은 본 발명의 실시 예에 따라 일정 간격으로 상태를 PUBLISH하도록 하는 Rule의 예를 도시하는 도면이고, 도 7은 즉각적(instant)으로 상태를 PUBLISH하도록 하는 Rule의 예를 도시하는 도면이고, 도 8은 기존 Publication Rule의 취소의 예를 도시하는 도면이다.

상기 기술된 EPA control parameter들은 XML을 통해 publication rule로서 표현될 수 있다. 도 6을 참조하면 XML로 기술된, EPA control parameter들을 포함하는 Publication Rule의 예를 보여준다. 도 6을 참조하면, 상기의 (1)에 기술된 Header 정보들은 <Header> element의 child element들로 기술되었으며, requestor, time stamp, EPA to control, target state to control, target entity to control 정보들은, 각각 <requestor>, <time>, <target_contact>, <target_state>, <target_entity>로 표현된다. 도 6에서, requestor는 esc.example.com로 기술되는 example.com의 도메인에 있는 ESC이며, 제어하고자 하는 EPA는 sip:brian@example.com으로 표현되는 엔티티(entity)의 위치에 대한 상태를 publish하는 EPA이다. 도 6에서 EPA to control의 값은 기술되어 있지 않으므로, example.com의 proxy는 타겟 상태과 타겟 엔티티(entity)의 값을 근거로 이를 담당하는 EPA(들)을 결정하여, 이 메시지는 해당 EPA(들)로 라우팅할 것이다.

Publication Rule 정보는, [Common-Policy]에 기술된 common-policy framework에 부합하게 표현된다. Common-policy에서는, <conditions>에 기술된 모든 항목이 만족할 경우에만, <actions>에 기술된 항목이 실행되며, 이 때 <transforms>에 기술된 항목에 따라 전달될 정보가 변형이 된다. 이에 따라, target state to control, target entity to control, valid time은 <conditions>의 child element들인 <target_state>, <target_entity>, <valid_time>으로 표현되며, publication trigger mechanism은 <actions>의 child element인 <trigger>로 표현되고, state maximum accuracy는 <transformations>의 child element인 <max_accuracy>로 표현된다. Cancel은 <actions>의 child element로 표현될 수 있다. <trigger>의 child element로 <interval>, <update>을 정의할 수 있으며, 각각 해당 상태를 지정된 간격으로 정기적으로 PULISH하는 방법과, 해당 상태에 업데이트가 있을 때 PUBLISH하는 방법을 의미한다.

본 발명의 실시 예에 따른 도 6의 Publication Rule은, sip:brian@example.com의 location 상태를 publication 하는 방법에 대한 것으로, EPA는 1800 sec마다 주기적으로 sip:brian@example.com의 location 상태를 ESC에게 PUBLISH할 것이며, 이 때 위치 정보의 정확도는 최대 100m이다. 즉, 100m보다 자세한 정보는 publish되면 안 된다. 이러한 Publication Rule은, 2005년 8월 14일 09:00 (GMT+9) 부터 2005년 9월 14일 23:00: (GMT+9)까지 유효함을 알 수 있다.

도 7을 참조하면, sip:brian@example.com의 ua-prof에 대한 상태를 EPA가 즉시 ESC에게 PUBLISH하도록 하는 Publication Rule을 도시한다.

도 8을 참조하면, sip:brian@example.com의 game 상태에 대한 기존의 모든 Publication Rule들은 취소하는 것을 도시한다.

이렇게 XML로 표현된 Publication Rule은, 그 MIME Content-Type이 정의되어야하며, 이의 예로,‘application/pub_rule+xml’이 사용될 수 있다.

(2) EPA Control Parameter 또는 Publication Rule 전달 방법

본 발명에서는, 상기 (1)에 따라 기술된 Publication Rule의 전달을 위해, [RFC3428]에 기술된 SIP MESSAGE 요청 또는 이에 상응하는 새로운 SIP Method, 예를 들면, PUBLISHREQ를 사용하여 전달하는 방법을 제안한다.

SIP MESSAGE 요청 사용시, [RFC3428]에 기술된 내용을 따르며, 이 외에 추가적으로 다음과 같은 동작들을 제안한다.

Publication Rule은 상기 (1)에 기술한 바와 같이 XML로 표현되며, SIP MESSAGE 요청의 바디(body)에 포함되어, 기술된 Publication Rule을 담당하는 EPA에게 전달되게 된다. 따라서, 컨텐츠 타입(Content-Type)은 Publication Rule을 표현하며, ‘application/pub_rule+xml’과 같은 값이 될 것이다.

SIP MESSAGE 요청의 Request URI는, 위와 같이 body에 기술되는 Publication Rule이 적용되는 대상의 SIP AOR URI이며, 따라서. Presence Rule의 Header에 기술된 <target_entity>와 동일한 값이 기술된다.

SIP MESSAGE 요청의 To header는, 위와 같이 body에 기술되는 Publication Rule이 적용되는 대상의 SIP AOR이며, 따라서. Presence Rule의 Header에 기술된 <target_entity>와 동일한 값이 기술된다.

SIP MESSAGE 요청의 From header는, 이 request를 보내는 entity의 logical identification로 기술되며, 따라서, Publication Rule의 Header에 기술된 <requestor>와 동일한 값이 기술된다.

해당 publication rule이 적용될 수 있는 EPA가 다수일 시, SIP Proxy와 같은 이의 라우팅을 담당하는 엔티티(entity)는 이 SIP MESSAGE 요청을 분기(fork)하여, 각각의 EPA들에게 전달한다. 이 EPA들로부터의 200-class final response들은, [RFC3428]에 기술되었듯이, 그 중 하나만이 SIP MESSAGE requestor에게 전달되나, 이것이 유일한 200-class final response로 간주되면 안 된다. 각각의 EPA들과 SIP MESSAGE 요청자(requestor)는 각각 서로 다른 오퍼레이션(operation)들로 간주되어야 한다.

(3) EPA Control Parameter 또는 Publication Rule 처리 방법

본 발명에서는, 상기 (2)에 기술된 방법을 통해 전달받은 Publication Rule들을, EPA가 다음과 같이 처리할 것을 제안한다.

첫번째로, 전달받은 Publication Rule의 요청자 정보를 이용하여, 이 요청자가 Publication Rule을 요구할 수 있는지를 확인한다. 즉, 요청자의 Publication Rule 요청에 대한 인증(authorization)을 검증한다. 요청자가 이에 대한 권한을 가지고 없으면, 전달받은 Publication Rule을 거절(reject)한다. 그렇지 않으면, 다음 단계를 적용한다.

두번째로, 전달받은 Publication Rule을 기존의 Publication Rule과 취합 (compose)한다. 어느 한 시점에 한가지의 Publication Rule만이 적용되도록 취합되며, 두 개 이상의 Publication Rule이 서로 충돌할 시에는 적절히 resolve 한다. 예를 들어, 어느 시점에 서로 간격(interval)이 다른 두 개의 트리거링 메커니즘(tigger mechanism)이 존재한다면, 미리 정해진 규칙에 따라 두 가지 중 하나를 선택한다. 이러한 충동 해결(Conflict resolution) 방법은 그 대상이 되는 상태에 따라 다를 수 있다.

세번째로 성공적인 Publication Rule의 취합(composition) 후, SIP MESSAGE 요청에 대한 응답 메시지(Final response)로 200 OK를 보낸다.

네번째로 이렇게 처리된 Publication Rule에 따라, 해당 상태의 [RFC3903]에 기술된 SIP PUBLISH request를 사용하여 ESC에게 PUBLISH 한다.

(4) Synchronization of Publication Rule

다수의 EPA Publication Rule들은, 상기 기술된 (2)의 과정을 통해 EPA에게 전달되고, (3)의 과정을 통해 처리 및 취합된다. 이렇게 EPA에서 최종 가공된 Publication Rule은, 이를 요청한 또는 추후 요청할 수도 있는 엔티티(entity)들에게 동기화될 필요가 있다.

본 발명에서는, 이러한 EPA Publication Rule의 동기화 (synchronization)를 위하여, ‘publish_rule’ 이라는 이벤트 패키지(event package)를 제안한다. 제안되는 이벤트 패키지는 [RFC3265]에 기술된 기본적인 SIP 이벤트 팩키지(event package)의 framework을 따르며, 그 동작은 다음과 같다.

EPA에 저장된 Publication Rule의 동기화를 요청은, ‘publish_rule’ event에 대한 SIP SUBSCRIBE 요청을 통해 이루어진다. SIP SUBSCRIBE 메시지는 다음과 같이 구성된다. 상기의 (2)에 기술된 SIP MESSAGE 요청과 같이 EPA로 라우팅되야 하므로, SIP MESSAGE 요청의 SIP 헤더와 근본적으로 유사하다. 그러나, Publication Rule이 바디로 포함되는 SIP MESSAGE 요청과는 달리, SIP SUBSCRIBE는 바디에 아무것도 포함하지 않으므로, Publication Rule에 포함되는 타겟 컨텐츠, 타겟 상태, 타겟 엔티티(entity)와 같은 라우팅 정보들은 ‘publish_rule’ Event Header의 parameter로 기입된다.

첫번째로 SIP SUBSCRIBE 요청의 Request URI는, Publication Rule이 적용되는 대상 즉, 타겟 엔티티(entity)의 SIP AOR URI이다. 또는, GRUU ([GRUU])와 같은 방법을 통해 특정 EPA의 instance를 직접 지정할 수도 있다.

두번째로 SIP SUBSCRIBE 요청의 To header는, 기술되는 Publication Rule이 적용되는 대상 즉, 타겟 엔티티(entity)의 SIP AOR URI이다.

세번째로 SIP SUBSCRIBE 요청의 From header는, 이 요청을 보내는 엔티티(entity)의 logical identification로 기술되며, 따라서, Publication Rule의 Header에 기술된 <requestor>와 동일한 값이 기술된다.

네번째로 SIP SUBSCRIBE request의 Event header는, ‘publish_rule’이라는 값을 가지며, 이의 파라미터로, Publication Rule의 Header 정보인 타겟 상태, 타겟 엔티티(entity)가 정의된다. 즉, 이 SIP SUBSCRIBE 요청이 나타내는(subscribe) Publication Rule들을 identity할 수 있는 정보들이 파라미터로 제공된다.

다섯번째로 SIP SUBSCRIBE 요청의 Accept header는, Publication Rule에 해당하는 값을 표현한다. 상기 (1)에서 살펴본 실시 예에 의하며, ‘application/pub_rule+xml’ 이다.

여섯번째로 SIP SUBSCRIBE 요청의 Contact header는, 이 SIP SUBSCRIBE request를 보내는 실질적인 엔티티(entity)의 SIP URI를 의미한다. 이는 추후, EPA가 SIP NOTIFY를 보낼 때 사용하게 된다.

일곱번째로 SIP SUBSCRIBE 요청의 Expire header는, 이 ‘publish_rule’ event package의 유효기간을 sec로 나타낸다.

해당 publication rule이 적용될 수 있는 EPA가 다수일 시, SIP Proxy와 같은 이의 라우팅을 담당하는 엔티티(entity)는 이 SIP SUBSCRIBE 요청을 분기하여 각각의 EPA들에게 전달한다. 이 EPA들로부터의 200-class final response들은, [RFC3265]에 기술되었듯이, 그 중 하나만이 SIP SUBSCRIBE 요청자에게 전달되나, 이것이 유일한 200-class final response로 간주되면 안 된다. 각각의 EPA들과 SIP SUBSCRIBE 요청자는 각각 서로 다른 ‘publish_rule’ 이벤트 패키지의 예(instance)들로 간주되어야 한다.

EPA에 전달된 SIP SUBSCRIBE 요청은, [RFC3265]에 기술된 기본적인 framework에 준하여 처리되며, 그 동작은 다음과 같다.

첫번째로 From header에 의해 표현되는 SIP SUBSCRIBE 요청자가, Event header를 통해 요청한 Publication Rule의 정보를 접근(Access)할 수 있는지에 대한 인증(authorization)을 검사한다. 기본적인 authorization은 해당 Publication Rule의 타겟 엔티티(entity)에게 주어진다. 접근 권리가 없으면, 해당 SIP SUBSCRIBE 요청을 거절하고, 있으면 이에 대해 200 OK message를 보낸다.

두번째로 200 OK message 이후, 곧바로 해당 Publication Rule의 현재 EPA가 보유하고 있는 snapshot을 다음에 설명되는 SIP NOTIFY 요청의 바디에 실어서 요청자에게 보낸다.

‘publish_rule’ event package의 NOTIFY request 의 제작방법은, [RFC3265]에 기술된 기본적인 framework에 준하여 처리되며, 그 동작은 다음과 같다.

첫번째로 SIP NOTIFY 요청의 Request URI는, SIP SUBSCRIBE request의 Contact Header 값이 사용된다.

두번째로 SIP NOTIFY 요청의 Event header는, 그 값이 ‘publish_rule'로 기술된다.

세번째로 SIP NOTIFY 요청의 Subscription-State header는, 그 값이 active 이며, 이 event package의 남아 있는 유효시간이 expires parameter에 기술된다.

네번째로 SIP NOTIFY 요청의 Contact header는, 현재 EPA의 SIP URI가 기술된다. GRUU ([GRUU])가 지원될 경우, GRUU 값이 기술된다.

다섯번째로 SIP NOTIFY 요청의 Content-Type header는, 그 값이 ‘application/publish_rule+xml’로 기술된다.

여섯번째로 SIP NOTIFY 요청의 Content-Length header는, body에 들어가는 Publication Rule의 크기가 byte으로 기술된다.

일곱번째로 SIP NOTIFY 요청의 body에는, 현재 EPA가 보유하고 있는 요청된 대상에 대한 Publication Rule의 snapshot 이 기술된다.

이러한 SIP NOTIFY 요청을 성공적으로 받은 ‘publish_rule’ 이벤트의 ㄱ가가입자(subscriber)는, 200 OK message를 응답으로 보낸다.

이렇게 subscribe된 Publication Rule에 업데이트가 있을 때마다, ‘publish_rule' 이벤트의 유효기간이 남아있는 한, 해당 Publication Rule은 subscriber에게 SIP NOTIFY 요청을 통해 전달되게 된다.

그러나, 상기 (1)에 기술된 바와 같이, Publication Rule의 유효 시간의 duration의 0인 경우는, 해당 Publication Rule에 따라 즉각적인 한번의 PUBLISH를 유발시키고, 해당 Publication Rule은 PUBLISH후 삭제된다. 따라서, 이 경우는 기존의 Publication Rule에 영향을 미치지 않으므로 즉, 기존 Publication Rule에 아무런 업데잇이 없게 되므로, SIP NOTIFY 요청이 발생되지 않는다.

(5) EPA Control Parameter 또는 Publication Rule의 업데이트 방법

상기 (2)와 (3)의 과정을 통해 전달 및 처리된 EPA의 Publication Rule에 대한 업데이트는, 동일한 과정을 통해 이루어질 수 있다. 즉, 업데이트 될 Publication Rule을 SIP MESSAGE 요청의 바디에 포함시켜 해당 EPA에게 전달하며, 해당 EPA는 그 처리결과를 요청자에게 응답(response)한다. 프레젼스 정보 취합을 마친 Publication Rule은, 상기 (4)의 ‘publish_rule’ event package를 통해, EPA외의 다른 엔티티(entity)와 동기화될 수 있다.

(6) EPA Control Parameter 또는 Publication Rule의 취소 방법

Publication Rule의 취소는 상기 (1-1)에 기술된 방법을 통해 가능하다. 즉, 특정 또는 모든 기간에 대한 최소 요청을 Publication Rule의 형태로 기술하여, 상기 기술된 (2)의 SIP MESSAGE 요청을 통해 EPA에게 전달하면, EPA는 상기의 (3)의 과정에 따라 이를 처리하며, 결과적으로 기술된 기간 동안의 Publication Rule을 삭제한다.

도 8을 참조하면, 취소 요청(cancel request)을 포함하는 Publication Rule의 예를 도시한다. 도 8은 ‘sip:brian@example.com’의 ‘game’ 상태를 PUBLISH하는 EPA가 기존의 모든 Publication Rule들을 삭제할 것을 요청하는 경우이다.

(7) EPA Identification 및 Routing 방법: EPA Capability의 SIP Registration

본 발명에서 제안되는, EPA Control Mechanism의 구현을 위해서는, Publication Rule을 적절한 EPA에게 전달하는 방법이 요구된다. 이를 위해, 본 발명에서는 다음에 기술되는 바와 같이, [RFC3840]에 준하는 Media Feature Tag를 사용하여, 특정 EPA의 state publication capability를 Underlying SIP Network에 등록하여 사용할 것을 제안한다.

EPA는 타겟 엔티티(entity)에 대한 타겟 상태를 ESC에게 PUBLISH하는 역할을 한다. 따라서, Underlying SIP 네트워크는, 특정 상태의 PUBLISH를 담당하는 EPA를 상기 (1)에 기술된 타겟 상태와 타겟 엔티티(entity)를 통해 Identification함으로써, 해당 EPA로 라우팅할 수 있다. 이를 위해, Underlying SIP Network에는 어떤 EPA가, 어떤 타겟 엔티티(entity)에 대한 어떤 타겟 상태를 PUBLISH한다는 정보 즉, EPA capability에 대한 정보가 저장되어 있어야 한다.

본 발명에서는, 이러한 정보들을 Underlying SIP 네트워크에 저장하기 위해, 다음의 두 가지 방법을 제안한다.

첫번째로 EPA capability 정보가 정적인(static) 경우에는 예를 들면, 시스템 상의 location server에서 그 정보가 administration에 의해 Underlying SIP N네트워크에 직접적으로 static하게 설정되어 추후 EPA로의 라우팅에 활용될 수 있다.

두번째로 EPA capability 정보가 동적인(dynamic) 경우에는 즉, 사용자 에이젼트(UA : User Agent)와 같이 그 설정이 동적으로 바뀔 수 있는 경우, [RFC3840]에 준하는 미디어 특징 태그(Media Feature Tag)를 이용하여 [RFC3261]에 따라 SIP registration을 한다. 그러면, EPA 능력(capability) 정보가 SIP Registrar에 등록되고, 추후 이 EPA로의 라우팅에 활용될 수 있다.

PUBLISH되는 특정 상태에 대한 미디어 특징 태그의 정의는 [RFC2506]에 준하여 이루어진다. 예를 들어, UA-Profile을 PUBLISH 할 수 있는 능력은, [RFC2506]에 정의된 Global tree에, ‘+g.publish.ua-prof’ 처럼 정의될 수 있다.

도 9를 참조하면, sip:ua1.example.com 의 주소를 가지는 UA가 sip:brian@example.com에 대한 UA-profile 상태를 PUBLISH 한다는 능력을, SIP Registration을 통해 등록하는 신호 흐름을 도시하고, 도 10에는 도 9의 신호 흐름에 대한 메시지 포맷의 예를 도시하고 한다.

도 9에서 EPA가 registrar로 900단계에서 도 10의 (a)와 같은 메시지 포맷을 이용하여 등록을 위한 메시지를 전송한다. 이후, 이를 수신한 registrar는 EPA로 200 OK 메시지를 통해 응답한다.

EPA identification과 라우팅은, 상기 기술된 방법 외에도 GRUU ([GRUU][GRUU]서도 가능하다. 즉, 상기 (1)의 ‘EPA to control’에 기술되었듯이, 그 publication 제어의 대상이 되는 EPA가 GRUU를 사용하여 직접 표현될 수 있는 경우에는, 이 GRUU를 통한 직접적인 EPA identification 및 라우팅이 가능하다.

(8) EPA Control Mechanism 또는 Publication Rule 구현 방법

본 발명의 따른 Publication Rule 구현 방법을 도 11 및 도 12를 참조하여 살펴보도록 한다. 도 11 및 도 13은 상기에서 기술된 EPA Control Mechanism의 시신호 흐름과 메시지 흐름의 예를 도시하는 도면이다. 이하, 도 11에서는 타겟 상태정보가 게임정보임을 가정하고 설명하도록 한다.

먼저, 도 12를 참조하면, Ruler 1은 sip:brian@example.com을 요청하는 UA이며, Ruler 2는 sip:admin@example.com 즉, 이 System의 administrator를 represent하는 UA이다. EPA는 sip:brian@example.com의 game 상태를 ESC에게 PUBLISH한다. 이러한, EPA의 publication 동작은 Ruler 1과 Ruler 2의 Publication Rule에 의해 제어된다.

10단계 내지 13단계는, 상기 (4)에 기술된 ‘publish_rule’ event package를 사용하여, Ruler 1이 EPA의 Publication Rule에 대한 동기화(synchronization)를 요청하는 과정과 EPA가 이에 대해 응답 메시지를 전송하는 과정을 도시한다. 이 때, Publication Rule은 현재 blank 상태이다. 여기서 10단계 내지 13단계에서 각각 전송되는 메시지 포맷은 도 13의 (a) 내지 (d)에 각각 대응된다.

14단계와 15단계에서는, 상기 기술된 (1), (2), (3)의 방법을 이용하여, Ruler 1이 EPA에게 Publication Rule을 전달하고, EPA의 이에 대한 처리 및 응답과정을 도시한다. 예를 들어, Ruler 1은 14단계에서 sip:brian@example.com의 game 상태를 100sec마다 PUBLISH 할 것을 EPA에게 요청할 수 있다. 여기서 14단계와 15단계에서 각각 전송되는 메시지 포맷은 도 13의 (e)와 (f)에 각각 대응된다.

16단계와 17단계에서는, 상기 과정에 의해 업 데이트 된 Publication Rule이 Ruler 1에 동기화되는 과정을 보여준다. 즉, 16단계에서 EPA는 업 데이트 된 Publication Rule을 Ruler 1에게 알리고, 이를 수신한 Ruler 1는 응답 메시지로 200 OK 메시지를 EPA에게 전송한다. 여기서 16단계 내지 17단계에서 각각 전송되는 메시지 포맷은 도 13의 (g) 내지 (h)에 각각 대응된다.

18단계와 19단계에서는, 설정된 Publication Rule에 따라, EPA가 ESC에게 sip:brian@example.com의 게임 상태를, [RFC3903]에 준하는 방법으로, PUBLISH 하는 과정을 보여준다. 여기서 18단계 내지 19단계에서 각각 전송되는 메시지 포맷은 도 13의 (i) 내지 (j)에 각각 대응된다.

20단계와 23단계에서는, Ruler 1이, 상기 (1), (2)에 기술된 방법을 이용하 여, EPA에게 즉각적으로 sip:brian@example.com의 게임 상태를 PUBLISH 하도록 요청하고, 이에 따라 해당 상태를 ESC에게 PUBLISH 하는 과정을 보여준다. 이때, 상기 (1), (3)에 기술되었듯이, 이러한 즉각적인(instant) Publication Rule은 한 번의 PUBLISH에만 적용되며, PUBLISH 후에는 그 효력이 상실되어 기존의 Publication Rule이 적용됨을 알 수 있다. 또한, 상기 (4)에 기술되었듯이, Instant Publication Rule은 기존 Publication Rule을 변화시키지 않으므로, 이에 대한 동기화가 필요하지 않음을 알 수 있다. 여기서 20단계 내지 21단계에서 각각 전송되는 메시지 포맷은 도 13의 (k) 내지 (n)에 각각 대응된다.

24단계와 25단계에서는, 이러한 기존의 Publication Rule 즉, 100sec마다 PUBLISH에 따라 정상적으로 PULISH가 이루어지는 과정을 보여준다. 여기서 22단계 내지 23단계에서 각각 전송되는 메시지 포맷은 도 13의 (o) 내지 (p)에 각각 대응된다.

26단계와 27단계에서는, sip:admin@example.com으로 대표되는 System Administrator가 EPA의 publication interval을 500sec로 늘릴 것을 요청하는 과정을 보여준다. 즉, 26단계에서 Ruler 2가 EPA의 publication interval을 500sec로 늘릴 것을 요청한다. 그러면, 이를 수신한 EPA는 요청한 요청자의 자격을 검사한 후 취합한 후 27단계에서 200 OK 메시지를 응답으로 전송한다. System Administrator는, Publication Rule을 요청할 수 있는 권리가 부여되어 있어, 상기 (3)에 기술된 authorization 과정을 통과할 수 있다. 여기서 26단계 내지 27단계에서 각각 전송되는 메시지 포맷은 도 13의 (q) 내지 (r)에 각각 대응된다.

28단계와 29단계에서는 System Administrator에 의해 업데이트 된 Publication Rule을 Ruler 1에게 동기화하는 과정을 보여준다. 여기서 28단계 내지 29단계에서 각각 전송되는 메시지 포맷은 도 13의 (s) 내지 (t)에 각각 대응된다.

30단계와 31단계에서는 업데이트 된 Publication Rule에 따라 EPA가 ESC에게 sip:brian@example.com의 game 상태를, [RFC3903]에 준하는 방법으로, PUBLISH하는 과정이다. 여기서 30단계 내지 31단계에서 각각 전송되는 메시지 포맷은 도 13의 (u) 내지 (v)에 각각 대응된다.

32단계와 33단계에서는 Ruler1이 상기 (1), (2)에 기술된 방법에 따라, 기존의 모든 Publication Rule을 취소(cancel)하는 요청을 보내는 과정이다. 이때, Publication Rule의 취소(cancel) 요청은 Publication Rule을 초기화로 설정하기 위한 요청이다. 여기서 32단계 내지 33단계에서 각각 전송되는 메시지 포맷은 도 13의 (w) 내지 (x)에 각각 대응된다.

34단계와 35단계에서는 Ruler1에게 취소((cancel)된 Publication Rule의 결과를 동기화(synchronization)하는 과정을 보여준다. 여기서 34단계 내지 35단계에서 각각 전송되는 메시지 포맷은 도 13의 (y) 내지 (z)에 각각 대응된다.

이상 본 발명의 원리는 발명의 핵심 요지와 바람직한 실시 예를 위주로 기술되었지만, 본 발명이 속하는 기술분야에 있어서 통상의 지식을 가진 사람이라면, 첨부된 청구 범위에 정의된 본 발명의 정신 및 범위를 벗어나지 않으면서 본 발명을 여러 가지로 변형 또는 변경하여 실시할 수 있음을 알 수 있을 것이다. 그러므로 본 발명의 원리를 채택하는 향후 실시 예의 변경은 본 발명의 기술을 벗어날 수 없을 것이다.

본 발명은 ESC를 포함하여 외부객체에 의해, EPA의 동작을 제어할 수 있는 분명(explicit)한 방법들을 제안함으로써 EPA의 publication 동작의 제어를 가능하게 하는 이점이 있다. 또한, EPA를 요구(on-demand)에 따라 활성화(activate) 및 비활성화(deactivate)시킬 수 있어, 특정 상태에 대한 solicitation을 가능하게 하는 이점이 있다. 따라서, 본 발명에서 제안된 방법을 이용하면, 기존의 시스템과는 달리, 시스템상에서의 상태 Publication 동작에 대한 제어를 가능하게 한다. 이를 통해, 시스템상의 트래픽 로드(traffic load) 및 user experience를 향상시킬 수 있다.

Claims (2)

1. 프레젼스 서비스 제공을 위한 시스템에 있어서,

   대상 프레젼스 정보(target state)에 대해 요청되는 EPA(Event Publication Agent)의 퍼블리케이션 동작을 퍼블리케이션 룰(Publication Rule)을 사용하여 기술하고, 상기 퍼블리케이션 룰을 대상 프레젼스 정보의 퍼블리케이션을 담당하는 EPA에게 전달하고, 필요에 따라 상기 퍼블리케이션 룰을 업 데이트하거나 취소할 수 있고, 이벤트 패키지(event package)를 사용하여 상기 EPA로 퍼블리케이션 룰에 대한 동기화를 요청하는 룰러(Ruler)와,

   퍼블리케이션 할 수 있는 프레젼스 정보들의 정보를 Media Feature Tag를 이용하여 SIP 레지스트라 (Registrar)에 등록(registration)하고, 상기 룰러들로부터 상기 프레젼스 정보에 대한 상기 퍼블리케이션 룰들을 전달받아 취합하고, 취합된 퍼블리케이션 룰에 따라 상기 프레젼스 정보에 대한 ESC(Event State Compositor)로의 퍼블리케이션을 수행하고, 상기 퍼블리케이션 룰에 대한 업 데이트나 취소 요청이 있으면 이에 따라 상기 퍼블리케이션 룰을 변경하고 변경된 룰에 따라 상기 프레젼스 정보에 대한 ESC로의 퍼블리케이션 동작을 변경하고, 상기 룰러로부터 상기 이벤트 패키지를 이용하여 상기 퍼블리케이션 룰에 대한 동기화 요청이 있으면 이에 대한 응답 메시지를 상기 룰러로 전송하고, 퍼블리케이션 룰이 업 데이트되면 상기 업 데이트 된 퍼블리케이션 룰을 상기 룰러에게 알리는 상기 EPA와,

   상기 EPA가 등록한 Media Feature Tag 정보에 따라 대상 프레젼스 정보에 대 한 퍼블리케이션 룰을 대상 프레젼스 정보의 퍼블리케이션을 담당하는 EPA로 라우팅을 결정하는 SIP 레지스트라(Registrar)를 포함하여 구성됨을 특징으로 하는 프레젼스 서비스 제공을 위한 시스템.
2. 프레젼스 서비스 제공을 위한 방법에 있어서,

   EPA(Event Publication Agent)가 퍼블리케이션 할 수 있는 프려젼스 정보들을 Media Feature Tag를 이용하여 SIP 등록하는 과정과, 룰러가 대상 프레젼스 정보에 대한 퍼블리케이션 룰을 해당 EPA에게 보내는 과정과,

   상기 EPA가 등록한 Media Feature Tag 정보에 따라 대상 프레젼스 정보에 대한 퍼블리케이션 룰을 대상 프레젼스 정보의 퍼블리케이션을 담당하는 EPA로 라우팅하는 과정과,

   상기 EPA가 상기 퍼블리케이션 룰을 전달 받는 과정과,

   상기 EPA가 이러한 퍼블리케이션 룰에 따라 대상 프레젼스 정보에 대한 ESC(Event State Compositor)로의 퍼블리케이션을 수행하는 과정과,

   상기 룰러가 상기 퍼블리케이션 룰에 대한 업 데이트 또는 취소를 통해 상기 퍼블리케이션 룰에 대한 변경을 요청하는 과정과,

   상기 EPA가 상기 퍼블리케이션 룰의 변경 요청을 전달 받는 과정과,

   상기 EPA가 변경된 퍼블리케이션 룰에 따라 ESC로의 퍼블리케이션을 수행하는 과정과,

   상기 룰러가 대상 프레젼스 정보에 대한 이벤트 패키지(event package)를 사용하여 EPA로 퍼블리케이션 룰에 대한 동기화를 요청하는 과정과,

   상기 EPA가 상기 퍼블리케이션 룰에 대한 동기화에 대한 응답 메시지를 상기 룰러로 전송하는 과정과,

   상기 EPA는 퍼블리케이션 룰이 업 데이트되면 상기 업 데이트 된 퍼블리케이션 룰을 상기 룰러에게 알리는 과정을 포함하여 이루어진 것을 특징으로 하는 프레젼스 서비스 제공을 위한 방법.

Images