푸시 투 토크 오버 셀룰러 서비스 방법 및 장치 document_id A220623107628

워키토키형(walkie-talkie type) 서비스는, 서로 간에 간단한 메시지를 신속하게 통신하기를 원하는 사용자에게 오랫동안 인기가 있어 왔다. 종래에는, 이와 같은 서비스는 2-웨이 휴대용 라디오(two-way portable radio)에 의해 제공되어 왔고, 이 휴대용 라디오는 라디오 스펙트럼의 전용 부분을 이용하지만, 사용자가 유사한 단말기를 이용하고, 휴대용 라디오(portable radio)의 비교적 짧은 동작 범위의 범위 내에 있는 사전 선택된 사용자의 소 그룹과 통신하도록만 한다. 더욱 최근에, 이들 서비스는 기존의 셀룰러 전화 기반 구조상에서 피기백(piggy-back)하는 미국에 소개되었다. 그러나, 이들 서비스는 사실상 사유물(proprietary)이었고, 사용자가 여러 오퍼레이터 네트워크 간에 통신하지 못하게 하였다. 워키토키형 서비스의 사용을 광범하게 할 시도 시에, Open Mobile Alliance (www.openmobilealliance.org)로서 공지된 산업 분류(industry grouping)는, 셀룰러 네트워크를 통해 제공되는 워키토키 서비스에 대한 인터네트워크 운영성(internetwork operability)을 허용하는 적절한 프로토콜을 표준화를 목표로 확립되었다. 여러 표준에 의해 확립된 서비스는 푸시 투 토크 오버 셀룰러(PoC)로서 공지되어 있다. PoC는 관련된 음성 데이터가 패킷 교환 액세스 네트워크를 통해 전송될 것을 제안한다. GSM 및 UMTS의 경우에, 이것은 범용 패킷 무선 서비스 (GPRS) 또는 3G 액세스 네트워크일 것이다. 다른 네트워크 구조에서, 유사한 패킷 교환 액세스 네트워크는 토크 데이터를 전송하기 위해 이용될 것이다. 푸시 투 토크 서비스는 또한, 이것이 바람직한 선택이 아닐지라도, 회선 교환 액세스 네트워크를 통해 제공될 수 있다. 푸시 투 토크 오버 셀룰러(PoC) 시스템은 통상적으로, 셀룰러 네트워크로의 차세대 데이터 서비스, 특히 실시간 멀티미디어 서비스의 도입을 용이하게 하도록 제3 세대 프로젝트 파트너쉽에 의해 표준화되는 IP 멀티미디어 서브 시스템(IP Multimedia Subsystem: IMS)를 이용하는 GSM/GPRS/3G 네트워크상에서 구현된다. IMS는, 멀티미디어 IP 기반 세션의 설정 및 제어를 위해 Internet Engineering Task Force (IETF)에 의해 규정된 세션 개시 프로토콜(Session Initiation Protocol :SIP)에 의존한다. PoC 서버는 IMS 내에 위치되거나, 거기에 부착되어, PoC 세션(Session)들의 설정 및 제어를 위한 기능성을 실시한다. 기존의 푸시 투 토크 (PTT) 시스템은 통상적으로 제어 메커니즘을 이용하여, 한 사용자에게 말할 권리를 승인하지만, 통신 시의 다른 사용자는 이와 같은 권리가 거부되어, 청취 모드에 있다. 이와 같은 제어 메커니즘은 통상적으로 발언권 제어(floor control), 송화자 조정(talker arbitration), 토크 버스트 제어(talk burst control) 등으로 지칭된다. 예컨대, Open Mobile Alliance는 현재 Talk Burst Control Protocol(TBCP)을 포함하는 Push-To-Talk over Cellular (PoC) 시스템의 사양에서 작용한다. 사용자 대신에 말할 권리를 요구하기 위해, 단말기(PoC 클라이언트)는 통상적으로 요구 메시지를 제어기 (PoC 서버)로 송신한다. 제어기는 통상적으로 이 요구의 승인 또는 거부에 응답한다. 제어기는 통상적으로 요구를 승인할 시에 허용된 통화 타이머를 개시함으로써 사용자가 통화하는 시간을 통상적으로 제한하고, 일부 메커니즘을 이용하여, 통상적으로 취소 메시지를 사용자의 단말기로 송신하거나 간단히 사용자의 미디어를 전송하지 않음으로써 사용자를 인터럽트한다. 제어기에 의해 인터럽트되는 사용자는 통상적으로, 어떤 방식으로, 예컨대, 어떤 시간 주기 동안에 사용자에게 말할 권리를 승인하지 않음으로써 제어기에 의해 벌칙을 받는다(penalised). OMA PoC의 다음 버전 (여기서, "PoC 2"이라 칭하고, 이전의 버전은 "PoC 1"이라 칭함)은 OMA에서 전개한다(evolve). PoC 2에서 새로운 기능의 일부는 PoC 세션에서 화상(picture), 비디오 등의 송신을 허용하는 새로운 미디어 유형을 포함하는 것이다. 그러나, 최종 사용자 또는 클라이언트는 단지 모든 사용 가능한 미디어의 서브세트를 처리할 수 있다(선택할 수 있다). 이러한 관점에서, 미디어 배링(media barring)을 위한 기능을 포함하기 위한 요구 조건이 있을 것이다. 다음의 인용문은 OMA PoC 2 Requirement Document [OMA-RD-PoC-V2_0-20050902-D Push to Talk Over Cellular 2 Requirements, Draft Version 2.0 - 02. September 2005]: "In addition to what is specified in PoC 1.0 the incoming PoC Media Barring feature is needed when the receiving PoC User without interfering to the conversion and media sharing within the rest group"에서 추출된다. 또한, OMA PoC 2 Requirement Document로부터: "The PoC Client MAY support separate incoming media barring for each media type"; "The PoC Client May supprot different accept and reject rules for each media type"; "The PoC Service Infrastructure SHALL support separate in-coming PoC Media barring for each media type"; "The PoC Service Infrastructure SHALL use the manual answer mode as the default answer mode for the PoC Sessions when video is the media(The PoC User can configure the answer mode as he wishes)"; "The PoC Service Infrastructure SHALL use the automatic answer mode as the default answer mode for the PoC Sessions with only messaging media or when adding messaging to the on-going PoC Session"; "The PoC Service Infrastructure SHALL use the answer mode according to the Answer Mode Setting the same way as PoC1 specified"; 및 "The PoC Service Infrastructure SHALL use different accept and reject rules for each media type, if configured by the PoC Client"가 추출된다. PoC 1은 Media Barring을 위한 기능을 포함하지 않는다; 이는 PoC 2에서 새롭게 제안된 기능이다. PoC 2는 오디오/토크 버스트만이 가능한 PoC1과 비교되는 PoC 세션의 비디오, 문자 메시지 등과 같은 새로운 미디어 타입과 통신을 강화시킬 것이다. PoC 2 세션은 예컨대, 비디오와 동시에 오디오/토크 버스트를 사용할 수 있다. 최종 사용자의 관점으로부터, 그/그녀가 PoC 세션에서 사용되는 여러 미디어를 제한하기를 원하는 상황이 있을 수 있다. 예를 들어, 사용자는 비디오 미디어가 아니라 오디오/토크 버스트 미디어만을 수용하기를 원할 수 있다. 이러한 이유는 비디오가 사용에 적합하지 않거나, 제한된 대역폭의 범위에 있는 환경 또는 상황이라는 것이거나, 낮은 배터리 레벨을 갖는 것 및 비디오 디스플레이가 매우 많은 파워 드레인(power drain)일 수 있다는 것을 인식하는 것을 포함한다. 발신 사용자의 세션에 제공되는 미디어를 배링하도록 선택하는 것은 임의의 유형의 미디어를 송신하지 않는다고 선택하는 송신자보다 수신자(PoC 호출의 착신 사용자인)이다. PoC(및 일반적으로 IMS)는 SIP 시그널링이 사용되는 제어 평면(control plane) 및 페이로드(음성, 비디오 등)가 RTP, MSRP 등과 같은 여러 프로토콜을 사용하여 트랜스포트되는 미디어 평면으로 분리된다. PoC 세션(또는 임의의 다른 SIP 세션)을 설정할 때, 미디어가 그 세션에 대해 사용될 것이라는 정보가 멀티미디어 세션에 대한 세션 설명 프로토콜(Session Description Protocol: SDP)[RFC 2327]에서 트랜스포트되는데, 이는 SIP 메시지의 일부이다. 이는 송신자 및 수신자로부터 미디어 스트림을 정렬하는데 사용된다. 송신자는 세션에서 사용하기를 원하는 각각의 미디어 유형에 대한 정보를 송신하며, 수신자는 제공된 미디어의 전체 또는 서브 세트에 응답할 것이다. 기본적인 동작은 발신 및 착신 클라이언트가 공동으로 할 수 있는 캐퍼빌리티를 결정하는 것이다. 예를 들어, 발신 클라이언트가 양호한 컬러 스크린이 있는 카메라를 가질 수 있으면, 비디오 호출이 가능하지만, 비디오 세션을 시작할 필요가 없는 경우에, 수신 단말기가 스크린이 없는 로우-엔드(low-end) 단말기일 수 있다. 그러나 동일한 기능은 그/그녀가 다른 사용자와 설정하기를 원하는 통신의 유형을 결정하는 최종 사용자로 리프팅(lift)될 수 있다. 수신자의 클라이언트가 각각의 인커밍 세션에 대해서 SDP에서 어떤 제공된 미디어가 세션에 대해 허용할 수 있거나 허용할 것인지 응답하는 것이 일반적인 경우이다. 여기에 대해서 몇몇 제한이 있다: 첫번째로, 모바일 환경에서, 발신자에 의해 제공되는 어떠한 미디어도 수신자에 의해 허용될 수 없다면, 공중 인터페이스를 통해 낭비된 라운드트립(roundtrip)이 있을 수 있다. 두번째로, 미래에, 미디어 배링의 개념이 호출하는 사람에 따라 여러 미디어 배링을 제공할 수 있게 확장될 수 있고(예컨대, "나는 직장 동료에 대한 비디오 미디어를 허용하는 것이 아니라 가족에 대해서 허용한다(I do not allow video media for my work colleagues but I do for my family)"), 그래서 각각의 클라이언트는 모든 액세스 규칙의 트랙을 유지할 필요가 있다. 이는 일반적으로 네트워크에 의해 처리되는 것이다. 세번째로, PoC에서, 자동 응답에 대한 특징이 있는데, 여기서, PoC 세션은 자동으로 응답받는 것이며, 사용자는 세션 설정 및 유용성을 가속화하기 위해서 정확하게 응답하지 않는다. PoC 2 비디오 미디어에 대해서, 개인적인 이유로 자동 응답을 결코 사용하지 않는 것이 제안된다. 이는 비디오를 처리하기를 원하지 않을지라도, 비디오를 포함하는 여러 세션이 사용자로부터 수동 응답을 필요로 할 것이라는 것을 암시한다. 예는 수신자가 AutoAnswer TRUE 및 VideoMedia = FALSE를 설정하는 것이며; 이러한 설정을 갖는 수신자가 오디오 및 비디오 둘 다를 포함하는 PoC 세션으로 초대를 획득한다면, 세션의 미디어 비디오는 AutoAnswer가 무효화되기 때문에 AutoAnswer 특징이 사용될 수 없다. 하나 이상의 상기 이슈를 다루는 것이 바람직하다. 미디어 배링의 한 옵션은 클라이언트가 처리하기 위해 선택하는 미디어를 설정하는 각각의 PoC 클라이언트에 대해서 PoC 서버의 파라미터를 설정하는 것이고, 그래서 PoC 서버는 미디어 평면 상에서 희망하지 않는 미디어를 배링할 것이다. 이러한 해결책으로, PoC에 대한 제어 평면은 사용자가 처리하기를 희망하지 않는 미디어에 대한 필요하지 않은 미디어 파라미터(SDP)를 또한 포함할 것이다. 또한, 이는 미디어 배링이 이미 제어 평면에 사용되는 시그널링과 함께 PoC 서버에서 설정되었다는 것에 관한 수단일 필요가 있음에 따라 PoC 클라이언트를 구현할 때 어려움이 있을 것이다. 다수의 클라이언트를 사용할 때, 이들 모두는 클라이언트들 간에 정합될 필요가 있을 것이다.