GSMA RCS-e v1.1

전 세계의 다양한 이동 통신사업자와 글로벌 단말 제조업체 및 솔루션 업체들이 참여하고 있는 국제 표준화 단체인 GSMA에서는 지난 2008년부터 RCE(RIch Communication Ecosystem)라는 프로젝트를 통해 이동 통신의 고유영역인 통신서비스에 대한 표준을 만들어 오고 있다. 현재까지 제정된 RCS release 4 까지의 산출물은 OMA와 같은 다른 국제 표준 단체에 의해 이미 제정된 관련 기술들을 채택하고 조합하는 방식으로 이루어지고 있으며, 각 릴리즈 버전별로 지속적인 업그레이드가 이루어지고 있다.

그러나, 최근 몇 년간의 스마트폰의 보급과 함께 봇물처럼 쏟아지고 있는 mVoIP를 포함한 통신서비스를 제공하는 제3의 응용 서비스들은 이동통신사들로 하여금 Time to market에 대한 니즈를 가속화 시켰으며 이에 대한 대응으로 GSMA RCE에서도 기존의 RCS 릴리즈와는 별개로 time to market을 고려한 RCS-e 규격을 제정하게 되었다.

본 포스팅은 지난 2011년 4월에 발행된 RCS-e v1.1 규격을 정리한다.

1. 개요

RCS-e 규격의 정식명칭은 RCS-e Advanced Communications로서 주요 기능 및 범위는 RCS R2를 기반으로 하고 있다. 그러나 RCS R2의 모든 기능을 포괄하는 것은 아니며, time to market과 이동통신 사업자간의 상호운영성을 고려하여 몇몇 기능들은 수정되었고 RCS R2에는 없던 기능들도 다소 포함되었다. 그 개념도는 다음과 같다.

위 그림에서 보여주듯, RCS-e의 주요 서비스는 메세징, 파일전송, 이미지 및 비디오 공유 서비스로 구성된다. 소셜 프로파일 정보 관련 서비스는 Optional로 제공되도록 하고 있으며, RCS R2와 비교하여 추가되거나 변경된 기능은 다음과 같다.

• Store and Forward
• "displayed" Message Disposition
• local black list
• Conversation History
• User Alias
• Multiple Devices
• Message Identification within SIP INVITE
• Auto-acceptance of store and forward IM Server PUSH of stored notifications
• IMDN

2. 초기화 절차

RCS-e 서비스의 절차는 서비스 및 형상 데이타 전송(Configuration Provisioning), 등록(Registration), 단말 및 사용자 정보 확인(Capability Discovery)으로 크게 세 단계로 나눌 수 있다. 사용자가 RCS-e 서비스를 사용할 수 있기 위해서는 IMS망과 RCS-e 클라이언트에 해당 사용자가 서비스에 접근하는 데 필요한 데이타가 이미 등록되어 있음을 전제로 한다. 즉, RCS-e 서버는 단말의 최초 등록을 감지하고 서비스에 필요한 데이타를 RCS-e 클라이언트와 IMS망의 필요한 Entity에 내려줄 수 있어야 한다. 이 절차는 백그라운드로 동작하여 사용자는 인지하지 못해야 한다. 한편, 등록절차는 다시 최초 등록(First time registration)과 일반 등록(Normal registration) 절차로 구분된다. 최초 등록은 주소록 상의 각 contact가 RCS-e 사용자인지를 확인하는 절차을 동반한다는 측면에서 일반등록과 구분된다.

다음은 이러한 절차를 보여주며, 각 절차에 대한 자세한 내용은 다음 하위절에서 설명한다.

2-1. 등록 절차

등록절차는 단말에 설치된 RCS-e 클라이언트가 기동하면서 RCS-e 네트웍(i.e., IMS)에 접속하는 과정을 의미한다. 세부적인 절차는 MNO마다 다를 수 있어 구체적인 제한을 두고 있지 않으나 그 인증방식에 대해서는 다음의 세 가지 형태를 지원할 것을 권고하고 있다.

• SSO/GIBA(SIngle Sign On/GPRS-IMS-Bundled Authentication)[TS33.203 Annex T]
• IMS/AKA (IMS/Authentication Key Agreement)[RFC3310]
• Digest(user/password)

재등록 절차는 통상적인 SIP 등록 절차와 동일하게 처리된다[RFC3261]. 단, 꼭 필요한 경우 이외의 재등록 절차는 생략된다.

등록절차를 완료한 RCS-e 클라이언트가 Presence 메카니즘을 지원하는 경우, 자신의 communication capability 정보를 프레즌스 서버에 등록하는 절차를 수행한다. 이 과정은 Presentity가 자신의 상태를 Publication하는 통상적인 프레즌스 절차를 따르며, 그 흐름도는 다음과 같다.

2-2. 서비스 및 형상 데이타 전송

RCS-e 서비스를 제공하는 망은 RCS-e 클라이언트의 최초 접속을 인지할 수 있어야 하며 어느 Entity가 어떻게 인지하는 지에 관한 내용은 RCS-e v1.1에는 언급되어 있지 않으므로, 각 망 사업자의 구현이슈로 간주된다. RCS-e 클라이언트를 탑재한 단말의 접속을 인지한 망은 서비스 제공을 위해 필요한 망 내의 entity 및 단말로 서비스 및 형상 데이타를 전송한다. 사용자 경험을 위해 이 절차는 사용자에게 노출되지 않아야 한다.

RCS-e v1.1에서 정의한 서비스 및 형상 데이타는 다음과 같다.

서비스 및 형상 데이타를 전송하는 방식은 통상 OMA DS(Data Synch)나 OMA CP(Contents Provisioning) 방법을 사용할 수 있으나 RCS-e 에서는 별도의 configuration server를 두고 HTTP(S)를 이용해 전송하는 방식도 사용할 수 있음을 배제하지 않고 있다. 즉, Time To Market을 고려하여 망 상황에 따라 접근하기 쉬운 방법을 선택할 수 있도록 되어 있다.

단말의 SIM 카드의 교체나 단말의 리셋이 실행되는 경우 형상 데이타를 안전하게 백업할 수 있어야 한다. 이는 원래의 SIM 카드가 다시 사용되는 경우 해당 SIM카드에 저장되어 있는 Identity에 대한 형상 데이타를 다시 사용할 수 있도록 하기 위해서이다.

본 절차는 단말의 IMS Identity(i.e., TEL-URI, SIP-URI)가 변경되지 않는 이상 반복되지 않는다.

2-3. 단말 및 사용자 정보 확인

RCS-e 클라이언트는 최초 등록시 주소록에 등록되어 있는 각 contact에 대해 RCS-e 사용자 여부 및 각 contact의 device capability를 확인한다. 이를 위해 단말간 SIP OPTIONS 가 사용된다. RCS-e 에서는 device capability를 위해 각 service feature에 대한 별도의 feature tag를 다음과 같이 정의하고 있다.

NOTE  실제 서비스 흐름(i.e., SIP INVITE)에서 IM/Chat과 FIle Transfer의 경우 +g.oma.sip-im을 공통으로 사용할 수도 있으나 이를 구분하고자 하는 경우 위에 정의된 feature tag가 사용될 수 있다.

위 표에서도 알 수 있듯이, RCS-e 클라이언트의 주요 기능은 메세징(IM/Chat), 파일전송, 이미지 및 비디오 공유라고 할 수 있다. 또한, 선택적으로 소셜 프레즌스 정보 교환 기능이 제공될 수 있다. 각 기능에 대한 세부 내용은 다음 장에 기술하기로 한다. 다음은 RCS-e 클라이언트의 capability를 결정할 수 있는 몇 가지 경우의 수를 나열한다.

• MNO가 특정 서비스를 지원하지 않거나 허용하지 않는 경우
• 단말의 HW가 저사양인 경우
• 단말의 상태가 특정 서비스를 임시로 수용할 수 없는 경우(e.g., 용량초과)
• 망 연결 상태 또는 연결된 망의 capability
• IM/Chat 서비스는 조건과 관계 없이 제공된다.

이와 더불어, RCS-e 에서는 Store and Forward 기능을 지원한다. Store and Forward는 착신단말이 메세지를 수신할 수 없는 경우 메세지를 임시로 서버에 저장했다가(deferred) 향후 착신 단말이 등록되었을 때 이를 감지하고 착신시켜주는 메카니즘을 말한다.

3. 세부 기능
3-1.  단말 정보 획득(Device Capability Discovery)

단말 정보 획득 기능은 주소록에 있는 각 contact의 단말 정보를 획득하는 기능으로써 다음과 같은 상황에서 수행된다.

• 최초 등록시 주소록의 각 contact에 대한 등록상태와 default capabilities를 획득
• 주소록 변경시
• 주소록에 새로운 contact이 추가된 경우
• contact의 primary MSISDN이 변경되거나 새로운 MSISDN이 추가된 경우
• 실시간 확인
• 특정 contact와 communication하기 위해 해당 contact의 가용한 RCS-e service capability 확인(e.g., call, IM/Chat)이 필요한 경우.
• Voice call, IM, File transfer 수행 도중 상대방의 가용한 communication capability 변경 시.
• Communication event(e.g., text, email, call, IM, etc) 발생 시.
• POLLING PERIOD에 정의된 주기에 따라 주소록에서 communication capability가 획인이 안된 contact을 대상으로 수행

NOTE  이미 communication capability discovery 절차가 수행된 지 얼마 안된 경우엔 생략 가능하다.

단말 정보 획득 절차

단말 정보를 획득하는 방법은 단말의 Capability에 따라 다음과 같다.

1) SIP OPTIONS
2) Presence 

1)의 경우 watcher가 되는 단말은 주소록의 모든 contact에 대해 각각 SIP OPTIONS를 교환한다. 2)의 경우 Presence 메카니즘을 재사용하므로 watcher와 Presence Server의 RLS간에 한번의 트랜젝션으로 복수 contact의 device capability를 확인할 수 있다. 다만, 후자의 경우, 각 contact가 Presence capability가 있음을 알아야 하므로, 각 contact에 대해 최소한 한 번은 1)의 방법을 사용해야 한다. 

최초  SIP OPTIONS를 통해 획득한 contact의 feature tag가 "Capability discovery via Presence"를 지원하는 경우, 이후 부터 해당 contact에 대한 capability discovery는 presence를 통해 수행된다. 또한, 자신의 device capability 정보를 공개하는 presentity가 되는 단말은 anonymous subscription을 지원해야 한다. 이에 대한 흐름도는 다음과 같다.

Presence를 지원하는 contact의 목록은 watcher 사용자의 XDMS에 저장된다.

NOTE  단말이 Anonymous subscription을 지원해야 하는 이유는 RCS-e에 명시되지는 않았으나, Presentity 단말의 입장에서 상대방이 해당 단말의 주소록에 등록되지 않은 contact일 수도 있기 때문일 것으로 판단된다.

RCS-e 사용자 확인

SIP OPTIONS의 응답으로 RCS-e IM service feature tag를 수신한 경우 해당 contact이 RCS-e 사용자 인것으로 간주한다. 실패 응답의 경우는 다음과 같이 처리한다.

• 480 Temporarily Unavailable - 변화 없음
• 408 Request TImeout - 변화 없음
• 404 Not Found - non-RCS-e 사용자

Capability Polling

주소록에 있는 contact에 대한 device capability정보는 상황에 따라 주기적으로 또는 실시간으로 획득되는데, 다음은 주기적으로 획득되는 경우에 해당한다.

• non-RCS-e 사용자
• RCS-e 사용자이나 capability 정보가 없는 경우
• Capability 정보 유효시간 만료

3-2.  메세징(IM/Chat)

RCS-e에서는 Pager Mode 메세징을 지원하지 않는 대신, 해당 기능을 세션 기능과 통합시킨 것이 특징이다. 즉, RCS-e 클라이언트는 세션 기반 메세징(IM/Chat)을 전송하기 위해 SIP INVITE를 착신측으로 전송하게 되는데, 이때 SIP INVITE 내에 CPIM body를 포함해 보내고자 하는 메세지를 실어 보내게 된다. 즉, 발신자 입장에서는 대화창을 열어 메세지를 입력하고 'send'를 누르는 순간에 SIP INVITE가 첫번째 메세지(payload)와 함께 전송되는 것이다. 착신단말의 입장에서는 SIP INVITE를 수신하는 순간 발신측으로 부터 전송된 첫번째 메세지를 확인하게 된다. 착신자가 수신된 메세지의 팝업을 터치하는 순간 대화창이 열리며, 이와 동시에 발신측으로는 200 OK가 전송되어 IM/Chat을 할 수 있는 세션이 열리게 된다. 그러므로 착신자가 무응답인 상태에서 발신자가 계속 메세지를 보내게 되면 SIP INVITE가 그만큼 여러개 전송되는 셈이다. 종단간 세션이 맺어진 후의 메세지는 MSRP를 통해 전송된다. 다음은 이에 대한 흐름도를 도시한다.

IMDN 전송

RCS-e에서는 'delivered'와 'displayed' notification을 지원한다. RCS-e에서는 SIP INVITE가 payload를 포함하고 있으므로 이에 대한 delivered notification이 전송되어야 하며, 이를 위해 SIP MESSAGE를 사용한다. 세션이 수립된 상태에서 delivered notification이 전송되는 경우 MSRP SEND를 사용한다. 반면에 Displayed notification은 착신자가 메세지 확인을 위해 화면상의 팝업을 터치하여 대화창을 열었음을 의미하므로 MSRP 세션이 성립된 후에만 전송된다. 따라서, displayed notification 전송은 항상 MSRP SEND를 사용한다.

세션 확장

사용자는 1-1 IM/Chat을 Group IM/Chat으로 확장할 수 있다. 이때, 세션확장을 요청하는 단말은 세션에 참여할 각 contact가 이 기능을 지원하는지를 SIP OPTIONS를 통해 확인한다. UI 관점에서 원래 세션에 참여했던 참여자는 세션의 확장과 관계없이 동일한 대화창을 사용할 수 있어야 한다.

그룹 IM/Chat

RCS-e 단말에게는 서비스 초기화 시 conference factory uri 값이 provisioning된다. 사용자는 단말의 RCS-e 주소록에서 Ad-hoc 형태로 그룹 IM/Chat 세션을 생성할 수 있고 RCS-e 클라이언트는 SIP INVITE 전송 시 저장된 conference factory uri값을 사용한다. 그룹 IM/Chat 세션을 생성하는 과정에서 별도의 capability discovery 절차는 생략되며, IMDN도 전송되지 않는다. 이후 각 착신자의 수락/거부 과정을 거쳐 그룹세션이 생성되면 각 RCS-e 클라이언트는 conference event package를 서버에 요청하여 참여자의 정보를 확인할 수 있다. 그룹 IM/Chat 요청은 store and forward 되지 않는다. 그룹 IM/Chat 서비스는 RCS-e 클라이언트가 초기화 과정에서 conference factory의 uri를 provisioning 받아야 하므로 RCS-e 사용자가 아닌 경우 참여할 수 없다.

그룹 세션에 참여한 각 참여자는 다른 참여자를 초대할 수도 있고 해당 세션을 종료할 수 있다. 그룹 세션은 서비스 정책에 따라 최소인원을 만족하지 않는 상태에 도달하면 해당 세션이 종료된다.

3-3.  지연 메세지 처리(Store and Forward)

착신 단말이 메세지를 수신할 수 없는 경우 해당 메세지는 RCS-e 서버에 임시로 저장되고, 향후에 해당 단말이 서비스에 접속하면 저장된 메세지를 꺼내어 착신시키는 절차를 의미한다.

Store and Forward 기능은 서버는 Optional이고 단말은 mandatory이므로, configuration provisioning 단계에서 본 기능을 단말에서 지원해야 하는 지를 클라이언트에게 알려준다.

Store and forward 기능은 원칙적으로 착신측 RCS-e 서버가 처리하도록 정의한다. 그러나, 착신 RCS-e 서버가 해당 서비스를 지원할 수 없는 경우, 발신측 RCS-e 서버가 이를 처리할 수 있어야 한다. 또한, Store and forward 기능은 사용자 메세지 뿐만이 아니라, IMDN에도 동일하게 적용된다.

메세지가 store and forward로 착신되는 경우 RCS-e 서버는 P-Asserted-Identity 헤더에 store and forward feature tag("standfw@operator.com")를 설정하여 전송하고, store and forward 메세지를 수신한 단말은 사용자와의 interaction없이 자동으로 이 메세지를 수락할 수 있어야 한다.

3-4.  복수 단말 처리(Multiple devices)

사용자의 복수단말 처리를 위해 GRUU 메카니즘을 이용한다. 단말에서 GRUU를 획득하는 절차는 IMS에 정의된 절차를 그대로 따른다.

사용자가 한 개 이상의 단말을 등록한 경우 RCS-e 서버는 이를 처리할 수 있어야 한다. 복수 단말에게 전송된 IM/Chat 메세지(SIP INVITE)는 [RFC3261]에 정의된 통상적인 절차에 따라 IMS망에서 forking하고 궁극적으로 하나의 착신단말과 세션을 맺는다.

SIP INVITE에 대한 IMDN 전송 시 발신측이 복수 단말인 경우 해당 INVITE 메세지를 전송한 특정 단말에게만 IMDN 전송될 수 있어야 한다. 착신측이 복수 단말인 경우 발신측으로는 한 개 이상의 IMDN이 전송될 수 있는데, 이를 수신하는 단말은 최초 수신된 IMDN이외의 IMDN은 무시한다.

마지막으로 SIP OPTIONS 처리 시 착신측이 복수단말인 경우라 하더라도 발신측으로는 한 개의 200 OK만 전송되어야 하므로 SIP OPTIONS를 처리하는 중간 노드에서 복수단말로부터 수신되는 여러 개의 200 OK를 하나로 취합하여 전송하는 기능이 요구된다.

Device Switching

RCS-e 서비스에서는 복수단말을 가진 사용자가 서비스 도중 단말을 교체할 수 있는 기능을 제공한다.

착신자의 active 단말이 어떠한 이유로 de-active되어 RCS-e 서버가 메세지를 전송할 수 없는 경우, RCS-e 서버는 착신자의 등록된 다른 단말로 SIP INVITE를 전송하여 세션을 맺은 후 아직 전송되지 못했던 나머지 메세지를 전송한다.

사용자가 IM/Chat 도중 단말을 바꿔 메세지를 발신하는 경우, RCS-e 서버는 이를 감지하여 해당 사용자의 기존 단말과는 세션을 종료하고 새로운 단말과의 세션을 맺어 서비스를 지속한다. 단, 기존 단말에게 전송될 IMDN이 남아 있는 경우 IMDN 전송을 모두 마무리한 후 세션을 종료할 수 있어야 한다.

3-5. 파일 전송(FIle Transfer)

RCS-e의 파일전송은 RCS R2의 기술을 그대로 적용한다. UI/UX 관점에서 파일전송은 채팅창과 통합되어 제공되지만 세션은 독립적으로 동작한다. 파일전송은 일방향 전송이므로 착신측이 파일전송에 대한 응답 메세지(payload)를 전송하지 않는 한 IM/Chat 세션은 열리지 않는다.

파일전송 요청시 해당 파일의 크기와 타입을 착신자가 알 수 있어야 한다. 착신자는 주어진 정보를 참고로 해당 요청을 수락/거부 할 수 있다.

다음은 파일전송이 오류가 발생하는 경우를 나열한다.

• 사용자의 명시적 취소
• 망과의 연결 단절
• 단말의 저장 공간 부족
• 단말에서의 service capability 미지원

3-6. 비디오/이미지 공유(Video/Image Share)

RCS-e 단말은 서비스 초기화 과정에서 상대 contact이 Video/Image Share 기능을 가지는 지를 확인할 수 있다. VIdeo/Image Share의 미디어는 단방향으로 전송되며 기존 세션과는 독립된 별개의 세션을 사용된다. 스트림은 각각 RTP와 MSRP를 사용하며 H.264/MPEG-4 Part 10/AVC(Advanced Video Coding)을 지원한다. RCS-e의 Video/Image Share는 [IR.74]와의 역호환성을 지원하며 동시에 LTE를 지원한다. 다만, LTE에서 어떻게 Video Share를 구현할 것인지에 대한 내용은 아직 논의중이다. RCS-e에서의 Video/Image Share는 1-1 CS call 상태에서만 사용이 가능하며 1-1 CS call이 multiparty call로 전환하는 경우 SIP OPTIONS를 이용해 capability 정보를 갱신하고 Video/Image Share 서비스를 더 이상 사용할 수 없음을 사용자에게 알린 후 서비스를 종료한다. 그 밖에 CS call 상태에서 통화 중 대기로 전환하는 경우 Video/Image Share 서비스를 사용할 수 없게 된다. 이를 정리하면 Video/Image Share 서비스가 동작하기 위한 조건은 다음과 같다.

• 종단간 active CS call 세션이 존재
• CS call은 다자간 통화나 통화 중 대기 상태가 아님.
• Call forward나 Call Divert 상황이 아님.

3-7. 기타

RCS-e서비스는 추가적으로 이모티콘이나 스팸필터 기능을 지원할 수 있다.

4.  정리

여기서는 지금까지 본문에서 다뤄진 RCS-e 표준의 내용들을 기반으로 그 특징들을 간략하게 정리하고자 한다.

페이저 메세징과 세션 메세징의 통합

RCS-e 의 가장 큰 변화는 기존 IM에서 별개로 제공하던 pager mode 와 session mode 메세징을 하나로 통합했다는 것이다. 이는 사용자 경험측면에서 사용자가 상대방에게 SMS/MMS를 전송할 지 채팅을 요청할 지를 구분하지 않도록 하겠다는 것과 같은 맥락이라고 생각된다. 사용자의 행동은 '메세지 전송 요청'인 것 뿐이라는 것이다. 일면 국내에서 서비스되고 있는 카카오톡 서비스가 떠오른다. 지금까지 카카오톡 서비스는 페이저 메세징을 구현하고 사용자의 UI를 세션기반으로 제공하여 사용자 관점에서 사실상 페이저와 세션의 구분없는 통합된 형태의 메세징 서비스를 제공하고 있다.

(이러한 변화에 대한 개인의 의견은 별도의 포스팅에서 언급하려고 한다)

메세지 전송성공률 극대화

RCS-e 에서는 store and forward 및 multiple device 지원 기능을 통해 발신자를 떠난 메세지가 반드시 착신자에게로 전송될 수 있도록 하고 있다. 망이나 서비스의 중간 노드의 오류로 메세지가 유실되는 상황이 아니라면 착신자가 해당 발신자를 block 하지 않는 한 메세지는 반드시 전송될 것이다. 사실, 이 기능은 OMA의 SIMPLE IM이나 OMA CPM에서도 'deferred message'의 형태로 제공되는 기능이긴 하지만, RCS-e 의 경우 다른 Enabler와는 달리 의도적이든 비의도적이든 착신자로 하여금 사용자 설정을 이용하여 착신 메세지 처리 방법을 다양하게 할 수 있는 옵션을 제공하고 있지 않기 떄문에 착신자에게 전송된 메세지는 지극히 예외적인 상황을 제외하고는 모두 전송될 것으로 보인다.

부가 서비스 제공

RCS-e에서는 비디오 및 이미지 공유 서비스, 이모티콘 전송 등과 같은 부가 서비스를 제공한다. 사용자들이 비디오 및 이미지 공유와 같은 서비스에 얼마나 열광할 지는 모르겠지만 어쨌든 기존의 단순한 테스트 기반의 커뮤니케이션에 나름의 임팩트를 주고 싶었는지도 모르겠다.

복수 단말 지원

사용자의 복수단말 지원기능은 OMA CPM에도 있는 기능이나 RCS-e에서는 이를 매우 단순하게 접근하였다. OMA CPM에서 사용자가 복수 단말을 하나 하나 제어할 수 있도록 하는 여러가지 옵션들을 사용자 설정을 통해 제공했다면 RCS-e에서는 복수단말을 제어하는 IMS의 고유기능을 그대로 이용하고 있다. 다만, SIP OPTIONS 처리라든지 IMDN 처리 같은 측면에서 어느정도 사용자 경험을 고려한 것으로 보인다. Device switching 기능이 들어가 있는 것이 눈에 띄는데 이 기능은 기존에 Nateon이나 MSN 이 동시에 두 개의 단말에서 메신저에 로그인 하는 기능을 막아놓았던 것과 같은 동일한 기능이라고 보여진다. 서로 다른 단말간의 seemless한 서비스 연속성을 제공하는 것은 아니라는 것이다.

현재 이동통신 3사에서는 오는 2012년 상반기까지 RCS-e v1.1 기준의 메세징 서비스를 제공하고자 자체적으로 준비하고 있다. TTA에서는 이동통신 3사를 중심으로 RCS 실무반(PG7035)을 꾸려 이동 통신 3사간의 연동 규격을 제정하고 있다. 현재까지 0.9버전까지 만들어졌으며 향후 올해 말이나 2012년 1Q쯤 IOT를 거쳐 1.0 버전을 내 놓을 계획이다.

내년에 출시될 이동통신 3사의 RCS-e 클라이언트도 iMessage 처럼 단말에 native app 형태로 제공된다고 하니 내년 이맘때쯤 통신시장이 향후 어떻게 전개되어 있을지 궁금해진다.

-- Red Mouse

IMS Service Identification : ICSI 와 IARI

다음은 IMS기반의 응용서비스를 지칭하는 Identification인 ICSI(IMS Communication Service Identification)와 IARI(IMS Application Reference Identification)에 대해 기술한다.


1. IMS Communication Service Identification(ICSI)

ICSI는 IMS 응용서비스를 지칭하는 값을 갖는다. ICSI의 값은 서비스 제공자의 정책에 따라 단말로 provisioning될 수 있다. 단말은 ICSI를 사용하도록 되어 있는 IMS 서비스에 접속하는 경우, 이미 알고 있는 ICSI값을 Accept-Contact 헤더에 삽입하여 IMS망으로 전송한다. S-CSCF는 단말로부터 수신된 ICSI의 값을 사용자의 iFC와 비교하여 인증하고 해당 메시지가 적절한 응용서비스로 라우팅될 수 있도록 한다. ICSI는 마치 TCP/IP의 포트와 같은 개념으로서 IMS망에서 메시지를 특정 응용서비스로 라우팅할 때 사용된다. 따라서, ICSI는 Globally Unique한 값을 가져야 한다. 이러한 규칙은 단말에서도 동일하게 적용된다. 단말로 유입된 SIP 메시지는 해당 메시지의 ICSI값에 따라 단말에 설치되어 있는 특정 응용 어플리케이션으로 라우팅된다. 이 값은 단말과 IMS망, AS에서 동일한 값을 가져야 한다.

다음은 ICSI관련 주요 요구사항을 기술한다.

• ICSI는 종단점(UE 또는 AS)에 의해 REGISTER 또는 INVITE에 설정된다.
• S-CSCF는 ICSI에 의해 유일하게 정의된 하나의 IMS 응용 서비스를 선택할 수 있어야 한다.
• UE는 수신된 메시지의 ICSI에 의해 유일하게 정의된 하나의 IMS 응용 서비스를 선택할 수 있어야 한다.
• 서비스 제공자의 정책에 따라 ICSI는 online/offline 과금에 사용될 수 있어야 한다.
• ICSI는 사용자의 권한을 인증하는 데에 사용될 수 있어야 한다.
• 동일한 PUI(Public User Identifier)를 가지는 복수단말의 경우, 적절한 단말로 메시지를 라우팅하기 위해 ICSI 값이 고려될 수 있어야 한다.

ICSI는 서비스 제공자의 정책에 따라 사용될 수도 아닐 수도 있다. 따라서, ICSI의 유무가 서비스를 제공하는 데에 장애가 되어서는 안된다. ICSI가 없는 경우, S-CSCF는 서비스 제공자의 정책에 따라 해당 메시지를 지정된 유일한 IMS응용 서비스로 라우팅 할 수 있어야 한다.

Syntax

• Contact 또는 Accept-Contact 

        +g.3gpp.icsi-ref = ="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”

•  P-Preferred-Service 또는 P-Asserted-Service

urn:urn-7:3gpp-service.ims.icsi.mmtel

2. IMS Application Reference Identification

IARI는 IMS 기반 communication service상위에서 communication service 기능을 재사용하여 제3의 특정 서비스를 제공하는 IMS기반 응용서비스를 가리킨다. IMS Application Reference는 해당 응용서비스의 특정 서비스를 제공함에 있어 SIP의 communication 관련 기능을 재사용한다.

  

다음은 IMS기반의 communication service 와 응용 서비스(application reference)의 개념을 도시한다.

FIg 1. IMS applications on top of an IMS communication service[TS23.228]

Syntax

P-Preferred-Service 또는 P-Asserted-Service 또는 Contact에 사용

+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.game-v1”

References

[1] 3GPP TS 24.229, “IP Multimedia Call control based on SIP and SDP”

[2] 3GPP TS 23.228, “IP Multimedia Service(IMS); Stage2”

[3] OMA-TS-CPM-Conv_Func-V1_0, “CPM Conversation Function”

--END

2%부족한 모바일 주소록의 소셜화

본 글은 현재 여러 경로를 통해 제공되고 있는 몇 가지 소셜 주소록의 특징을 살펴 봄으로써 모바일 단말에서 주소록이 어떻게 진화하고 있는지를 알아보고자 한다.

피플링

피플링은 지난 8월 SKT에서 출시한 안드로이드 기반의 소셜 주소록으로, T스토어에서 현재 51,370 다운로드를 기록하고 있다. 기존 모바일 주소록의 Contact list에 Twitter의 Following list와 와 Facebook의 Friends list를 불러와 추가할 수 있는 기능을 제공한다. 사용자는 이렇게 불러들인 해당 contact의 SNS에서의 time line 또는 Wall page의 내용을   주소록에서 확인할 수 있다. 또한, 웹기반의 SNS에서 널리하고 있는 것 처럼 SNS로부터 획득하였으나 현재 사용자의 주소록에는 추가되지 못한 contact를 추천하는 서비스를 제공한다.

피플링에서 특이할 점은 대화이력을 보여주는 UI를 화면상단에 시간순으로 배열하고 있다는 점이다. 이에 대해 느끼는 바는 사용자마다 좀  다를 수 있겠으나, 본인처럼 메세지나 통화가 뜸한 사용자에게는 한참을 왼쪽으로 스크롤해야 하는 번거로움을 감수해야 한다. 반면에, 메세지나 통화를 자주 사용하는 사용자에게는 자신의 대화이력을 시간에 따라 그래픽하게 확인해 볼 수 있는 장점이 될 수도 있을 것 같다.

유세이

유세이는 주소록 통합 관리를 위해 KTH에서 내놓은 아이폰용 주소록으로 앱스토어에서 다운로드할 수 있다. 유세이 단말앱은 Gmail, Naver, Paran, Daum과 같은 이메일 및 포털에 있는 사용자의 주소록 정보를 끌어와 통합시키는 기능을 제공한다. 유세이는 단말앱외에 웹기반 서비스도 제공하고 있는데, 사용자는 단말앱의 contact list를 네트웍의 웹서버에 백업하고  동기화 할 수 있다. 어쩌면 현재로선 소셜 주소록이라기 보다 단순한 통합주소록이라고 보는 게 맞을 수 있겠으나, 향후 SNS와 연동함으로써 소셜 주소록으로 진화하리라는 개연성은 충분히 있어보인다.

이밖에 유세이에서는 주소록 기능외에 사용자간의 메세지를 전송할 수 있는 기능도 제공하고 있다. 유세이를 통한 메세지의 전송은 무료로 제공되는데, 단순 텍스트만이 아닌 파일이나 그림과 같은 멀티미디어 전송을 지원한다.

Social Hub

삼성은 지난 6월 소셜허브라는 이름의 소셜주소록을 탑재한 안드로이드기반의 갤럭시S와 바다기반의 웨이브폰을 해외에서 출시했다. 그리고, 지난 10월 11일 국내에서는 처음으로 소셜허브를 장착한 안드로이드 2.2(프로요)기반의 갤럭시K를 출시한다고 발표했다.

Bloter.net의 주민영님이 소개한 바와 같이, 소셜허브는 외부의 다양한 SNS를 단말에 통합함으로써 단말 주소록을 소셜화하고 있다. 또한, 소셜허브의 프리미엄 서비스를 위한 푸쉬 서버를 소셜허브를 장착한 삼성단말을 제공하는 모든 이통사의 네트웍에 설치함으로써 부가수익을 창출하려는 의도를 가지고 있는 것으로 보인다.

소셜허브는 Facebook, Twitter와 같은 여러 SNS 및 이메일을 제공하는 포털과의 연동을 통해 획득한 contact list를 단말의 주소록에 통합한다. 이렇게 통합된 각 contact의 정보와 SNS 활동은 주소록을 통해 직접 확인할 수 있으며, 주소록에서 해당 contact의 SNS 또는 이메일 계정으로 메세지를 전송할 수 있는 기능을 제공한다. 소셜허브는 부가적으로로 통합캘린더 기능을 제공하는 데, 외부의 SNS 및 이메일 포탈로 부터 수집된 일정정보를 통합적으로 관리할 수 있다.(갤럭시S 소셜허브 관련 유튜브 동영상 참조)

Asurion

미국 회사인 Asurion Mobile은 작년에 이미 모바일 주소록에 SNS연동을 접목한 소셜 주소록을 출시해 놓고 있다. 해당 앱을 앱스토어에서는 찾을 수 없는 것으로 봐서 현재로서는 안드로이드 마켓에서만 다운받을 수 있는 것으로 보인다.

Asurion Mobile에서 출시한 Asurion Address Book은 Facebook과 Twitter 이외에도 매우 많은 다양한 SNS 연동을 지원한다. 사용자는 지인관계 정보를 해당 SNS로부터 가져와 모바일 주소록으로 통합시킬 수 있으며, 통합된 contact의 SNS활동을 소셜 주소록에서 확인할 수 있다. 물론, 소셜주소록에서 해당 SNS로 메세지를 전송하거나 게시물을 올리는 것도 가능하다. (Asurion Address book 유튜브 동영상 참조)

마이피플

마이피플은 다음 커뮤니케이션즈에서 출시한 주소록 기반 메신저로 안드로이드용 및 아이폰용으로 모두 제공된다.

사용자는 단말에 있던 원래 주소록의 contact list와 다음의 주소록을 통합하여 관리하고, 마이피플 앱의 주소록을 다음의 주소록에 백업하거나 동기화시킬 수 있다.

이상에서 살펴본 바와 같이 모바일 단말이 세상에 첫 발을 디딘 후로 늘 함께 해 왔던 모바일 주소록은 소셜이라는 바람을 타고 다음 단계로의 진화를 준비하고 있다. 이러한 진화를 위해 주소록에 추가되는 기능들을 크게 Communication, SNS연동, 동기화로 구분할 수 있을 것으로 보인다. 각 기능별로 위에 소개된 각 서비스를 구분해 보면 다음과 같다.

	통신기능	SNS연동	동기화	비고
Peopling (SKT)	지원 (Messaging & Call)	지원	미지원	SNS연동을 통한 단말주소록의 확장
Usay (KT)	지원 (Messaging & Call)	미지원	지원	단말 주소록 백업 및 동기화
Social Hub (Samsung)	지원 (Messaging & Call)	지원	미지원	SNS연동을 통한 단말주소록의 확장
Asurion (Asurion Moble)	지원 (Messaging & Call)	지원	미지원	SNS연동을 통한 단말주소록의 확장
MyPeople (Daum)	지원 (Messaging & Call & IM)	미지원	지원	사이트 주소록에 기반한 메세징

결론적으로 얘기하면, 이통사, 단말제조사, 포털로 구분되는 모바일 시장의 Player들은 자기 나름대로 모바일 주소록의 진화를 꾀하고 있다. Facebook이나 Twitter를 비롯한 많은 웹 기반 서비스들이 웹 도메인에서 소셜 서비스의 중훙기를 만들어가고 있듯이, 모바일 서비스를 제공하던 이통사나 단말 제조사는 기존의 모바일 주소록에 소셜특성을 부가함으로써 또 다른 도메인에서의 소셜 플랫폼을 만들어 가고 있다. 결과적으로 두 개의 큰 흐름이 어딘가에서 만나 수렴하겠지만, 적어도 모바일 단말 쪽에서는 아직 지배적인 승자는 보이는 것 같지는 않다. 소셜 주소록은 그 자체로서 어떤 수익을 기대할 수 있기보다는 그 기반위에 올라설 수 있는 3rd-party 서비스들이 무궁무진 하기 때문에, 소셜 주소록의 강자가 되는 것은 어쩌면 그 이상의 의미가 있을지도 모르겠다. 그것은 모바일 주소록에 수록되는 정보가 웹에 수록되는 개인정보보다 훨씬 신뢰도가 높고 다양할 수 있기 때문이기도 하다.

그러나, 현재까지 출시된 소셜 주소록을 볼 때 나타나는 한계점은 다음과 같다.

1. 차별화 부족

트윗덱으로 대표되는 SNS Gateway 성격을 가지는 기존의 앱들과 비교했을 때 지금의 소셜주소록이 차별화가 크지 않다는 점이다. 소셜 주소록이 결국은 모바일 주소록 + SNS Gateway이기만 하다면, 기존에 트윗덱 같은 편리한 앱을 사용하던 사용자가 소셜 주소록으로 이전하기 위한 교체비용을 기꺼이 감수할 것 같지가 않다. 단순한 기능적 통합만으로는 앱에 대한 사용자의 복잡한 인식을 모두 담아내지 못할 것으로 보인다.

2. 사용자 경험에 대한 이해

이미 여러 블로거들이 언급한 바 있지만, 모바일 주소록에 저장되어 있는 contact list와 SNS에서 following하거나 Friends관계에 있는 contact 들과는 그 의미가 다르다. 전자는 적어도 한 번 이상 사용자와 직접적으로 접촉이 있었던 지인들로서 Tightly Coupled 의 관계라고 볼 수 있는 반면 후자는 언제든 그 관계가 끊어져도 별로 이상하거나 아쉽지 않은 Loosely Coupled 관계라는 것이다. 이 두 상반된 관계의 contact를 어떻게 소셜 주소록이라는 한 공간에 잘 MIxing하는 가 하는 것이 매우 중요한 관건이라 하겠다.

3. UX/UI의 중요성

소셜주소록은 기존의 다소 단순했던 모바일 주소록을 소셜화함으로써 더욱 복잡한 기능을 제공해야 한다. 사용자는 어떤 형태의 주소록을 이용하든 기존의 주소록이 가지는 단순 명확함과 편리함등을 결코 포기하고 싶지 않을 것이다. 따라서 기존 주소록 만큼이나 단순하고 편리하고 빠르게 contact 정보에 접근할 수 있도록, 소셜 주소록의 복잡한 기능을 어떻게 디자인하는 가가 또 하나의 매우 큰 과제일 것이다.

4. 앱의 정체성

마지막으로, 앱의 정체성을 들 수 있다. 주소록인가? 메신저인가? 아니면 SNS Gateway인가? 사용자들에게 메신저나 SNS Gateway로 오인되면, 그 순간 해당 소셜 주소록은 기존에 이미 많이 나와있는 우수한 메신저와 SNS gateway App들과 같은 One of them이 되는 것이다. 메신저나 SNS Gateway 보다 소셜주소록으로서의 정체성을 가지는 것이 더 성공확률이 높은 것은 아직 시장을 지배하는 서비스가 없는 초기시장이라는 점 때문이다. 이러한 이점을 극대화 하기 위해서 사용자에게 어떠한 정체성을 가지고 다가가는가 하는 것이 매우 중요한 고민거리일 것이다.

이상으로 모바일 단말에서의 소셜 주소록에 대한 내용을 나름대로 살펴봤다. 조만간 위에 언급된 한계점을 잘 극복하고 모바일 기기에도 잘 어울리는 소셜 플랫폼이 나올 수 있기를 기대해 본다.

통합메세징(CPM: Converged IP Messaging) 표준화

지난 2006년 6월에 OMA(Open Mobile Alliance)의 Work Group가운데 Communication관련 Enabler들을 다루고 있는 COM 그룹의 표준화 Work Item으로 채택되어 시작되었던 CPM Enabler가 2010년 8월말로 공식 종료되었다. 표준화에 참여한 주요 회사로는 Nokia, NSN, Ericsson, Samsung, LGE, Alcatel-Lucent, Acision, Hansol, Orange등이 있다.


본 고에서는 표준화 작업이 완료된 CPM의 주요 특징에 대해서 알아보고 CPM이 가지는 기술적 요소들에 대해 정리해 보고자 한다.


1. 개념
CPM은 기존의 SMS, MMS, Email, IM과 같이 각각의 silo에서 생성되고 진화되어 오던 메세징 서비스들이 All-IP망에서 어떻게 진화하게 될 것인가에 대한 고민에서 출발한다. All-IP망에서의 메세징 서비스는 사실상 SMS, MMS, Email, IM같은 기존의 메세징 서비스가 더이상 존재하지 않는 하나의 단일화된 메세징 서비스로 통합될 것이다.

이에 따라 이전 메세징 서비스에 대한 사용자 경험이, SMS/MMS/Email등 전송될 메세징 서비스의 종류를 선택함으로써 이루어지는 형태였다면  CPM 에서는 특정 contact에 대한 communication을 시도하는 것으로 단순화 될 것이다. All-IP기반의 CPM은 기존의 메세징 서비스들이 가지고 있던 모든 특징을 흡수하고 기존 메세징 서비스 단말에 대한 역호환성을 보장하는 형태로 표준화가 이루어졌다.

CPM은 그 자체로서 메세징 서비스를 제공하는 주체인 동시에 메세징을 필요로 하는 3rd party Application에게 메세징 기능을 제공해주는 플랫폼의 개념을 가진다. 

예를 들어, Game Service에서 CPM이 제공하는 Interface를 이용해 Game Service를 이용중인 사용자 간의 Communication기능을 제공한다거나 음악이나 영화 스트리밍을 이용하고 있는 사용자 들이 해당 음악 또는 영화에 대한 의견을 나눌 수 있도록 communication path를 열어주는 등의 서비스가 가능한 것이다.

2. 기능

2-1. 멀티미디어 지원

CPM은 모든 형태의 멀티미디어를 지원한다. 즉, 기존의 SMS, MMS, Email, SIMPLE IM에서 제공하던 discrete media(예:text, image, video clip, audio clip, binary등)와 continuous media(예:video streaming, audio streaming등)의 전송을 지원한다. 

2-2. Non-CPM Interworking

CPM은 기존 서비스 들에 대한 역호환성을 제공한다. 즉, 기존의 SMS, MMS, Email 메세지를 IP기반의 CPM 사용자가 받아보거나 전송할 수 있게 함으로써, CPM 서비스에 가입하지 않은 일반 메세징 서비스 사용자와도 communication이 가능하도록 한다.

2-3. Multiple Devices(다중 단말) 지원

CPM은 한 개 이상의 서로 다른 capability를 가지고 있는 사용자의 단말을 지원한다. 각 단말은 하나의 CPM 사용자 주소에 맵핑되고 사용자는 device capability나 communication capability에 따라 어떤 단말로 어떤 형태의 메세지를 전송받을 지 미리 설정 할 수 있다.

2-4. Multiple User Preferences Profile

CPM 사용자는 한 개 이상의 user preference set을 정의(예: office, meeting, do-not-disturb, home 등)함으로써 상황에 맞는 개인화된 communication 환경을 구성할 수 있다. 

2-5. Network-based Storage

CPM은 사용자에게 네트웍 기반의 스토리지를 제공한다. 네트웍 기반 스토리지는 사용자에게 수신된 메세지 및 미디어를 백업 또는 저장할 수 있는 기능을 제공한다. 또한, CPM 사용자는 네트웍 기반 스토리지에 저장된 미디어를 다른  CPM사용자와 공유하거나 Foward 할 수 있다. 

2-6. Standalone Messaging

Standalone Message는 discrete media를 포함하는 메세지를 의미한다. Standalone Messaging에서는 discrete media를 포함한 메세지의 크기가 1300byte보다 작은 경우는 Pager Mode로, 이보다 큰 경우는 Large Message Mode로 메세지가 전송된다. Standalone Messaging에서는 사용자의 User preference에 따라 Disposition Notification(예: 전송확인, 읽기확인)을 교환할 수 있다.

2-7. Session Mode Messaging

Session Mode Messaging은 종단간 미디어 계층에서의 세션이 맺어진 상태에서 이루어지는 communication을 의미한다. 세션이 맺어진 상태에서 이루어지는 communication은 별도의 Disposition Notification이 존재하지 않는다. Session Mode Messaging은 크게 1-1과 Group Session으로 구분된다. Group 세션에서는 한 명이상의 사용자간에 교환되는 미디어의 분배가 이루어지며, 사용자의 초대 및 퇴장 관련 호처리 기능이 포함된다. 또한, Group 세션에 참여하고 있는 참여자는 Group 관련 참여자 정보를 받아볼 수 있다.

2-8. File Transfer

파일전송 기능은 기존 SIMPLE IM에서와 동일하게 이루어진다. 발신자가 원하는 파일을 선택하여 착신측으로 전송을 하면 착신측의 수락여부에 따라 파일의 전송여부가 결정된다. 파일전송이 완료되면 파일전송을 위한 세션은 자동 종료된다.

2-9. Recording

CPM 사용자는 수신되는 모든 메세지 및 미디어를 네트웍 기반의 스토리지에 저장할 수 있다. Message Delivery의 일부 기능으로서의 'Storing'의 경우 수신되는 메세지 및 미디어를 단말에 착신하는 대신에 네트웍 기반 스토리지에 저장하도록 하는 사용자의 설정에 의해 이루어지고 따라서, 이 경우 메세지가 착신되었다고 간주되지만, 반면에 Recording의 경우 실제로 단말에 착신이 이루어진 메세지 및 미디어를 네트웍 기반 저장소에 저장한다.

3. 아키텍쳐

그림에서 보는 바와 같이 CPM Enabler는 CPM Partcipating Function, CPM Controlling Function, Interworking Selection Function, Inteworking Funciton, Message Storage Server 그리고 CPM Client 및 Message Storage Client로 구성된다. 이들 각 Component에 대한 간략한 설명은 다음과 같다.

• Message Storage Client: CPM Message Storage와 연동하여 단말과 Storage간의 메세지 동기화, 메세지 조회 및 관리를 수행한다.
• CPM Client: CPM Participating Function과 연동하며 사용자의 다양한 설정에 따라 메세지를 송수신한다. 
• CPM Participating Function: CPM Client와 직접 연동하여 메세지를 송수신한다. Multiple  CPM Client를 관리하고, User Preference를 참조하여 착신자에게 메세지를 전송한다. 그룹세션인 경우 CPM Controlling Function과 연동한다.
• CPM Controlling Function: CPM Group 세션을 담당한다. Signal 및 Media를 그룹세션 참여자에게 분배하는 conference focus의 역할을 수행한다.
• Message Storage Server: 네트웍 기반의 메세지 저장소로서 발수신 메세지 관리 및 CPM 단말과의 동기화 기능을 제공한다.
• Interworking Selection Function: Legacy Messaging Service로 라우팅 되는 메세지에 대해 특정 Legacy Messaging Service(i.e., SMS, MMS, Email)를 user preference 및 operator policy에 따라 결정하고 해당 Inteworking Function으로 메세지를 라우팅한다.
• Interworking Function: CPM메세지를 각 Legacy Messaging 서비스로 라우팅한다. 이를 위해 프로토콜 변환 기능등을 수행한다.

CPM Enabler를 구성하는 각 component간의 signaling은 SIP에 기반하며, discrete media 및 continuous media 전송을 위해 MSRP와 RTP/RTCP를 지원한다. 또한, 외부의 XDMS Enabler로부터 User preference 및 Operator policy를 끌어오기 위해 XCAP을 사용하며 Message Storage Client 및 Server간에는 IMAPv4를 사용한다.

4. 사용자 설정(User Preference)

CPM Participating Function은 user preference에 기반한 communication을 수행해야 한다. CPM 서비스를 위해 사용된 User preference는 SIMPLE IM의 그것에 비해 다소 복잡해진 면은 있으나, 반면에 다양한 형태의 메세징 환경을 제공할 수 있도록 표준화가 진행되었다. CPM System Description Document에 정의된 user preference는 다음과 같다.

• General request handling
• Do not disturb : 착신자가 Do-not-disturb로 설정해 놓은 경우 해당 사용자에게는 어떠한 Message나 Notification이 전송될 수 없다.

• Message  Handling
• Reject Message based on black list: 착신자가 설정한 blacklist에 해당하는 사용자로부터 메세지 전송시 해당 메세지는 전송되지 않는다.
• Handling of Messages

• Defer: 착신 단말이 메세지를 착신할 수 없는 상태인 경우 해당 메세지는 시스템의 temporary queue에 저장된다. 이후 CPM Client가 다시 메세지를 받을 수 있는 상황이 되면 저장되었던 메세지가 전송된다.
• Deliver to Message Storage: Defer와 동일하나 메세지를 네트웍 기반 스토리지에 저장한다.
• Forward: 수신된 메세지를 착신 단말로 착신하는 대신 착신자가 설정해 놓은 제 3의 단말로 해당 메세지를 Forwarding한다.
• Delivery using Non-CPM Communication Service: 착신자가 메세지를 CPM이 아닌 SMS,MMS 또는 Email로 착신하기를 원한다면 해당 메세지를 CPM Client가 아닌 해당 사용자의 SMS Client, MMS Client 또는 Email Client로 전송해야 한다.
• Deliver by providing a link to stored media instead of the media itself: 메세지에 미디어가 첨부되어 있는 경우, 해당 메세지를 모두 보내는 대신 미디어를 네트웍 기반 스토리지에 저장하고 저장된 각 미디어에 대한 link를 전송한다. 향후 착신자가 해당 미디어를 복원하고자 하는 경우, Message Storage Client를 통해 다운로드 될 수 있다.
• Handling of expired Deferred CPM Messages
• Discard: deferred message가 아직 단말로 착신되지 않은 상태에서 그 유효 시간이 만료된 경우 해당 메세지를 폐기처분한다.
• Delivery to Message Storage Server: deferred message가 아직 단말로 착신되지 않은 상태에서 그 유효시간이 만료된 경우 해당 메세지를  Message Storage Server에 저장한다.
• Session Handling
• Automatically accept/reject specific types of media during a session : 특정 조건(예: 발신자, 미디어타입 등)을 만족하는 세션에 대한 요청이 수신된 경우 착신자의 동의를 구하지 않고 자동으로 수락/거부 한다.
• handling of session invitation when CPM user not available, reject/interworking: 특정조건을 만족하는 세션에 대한 요청이 수신되고 착신단말이 메세지를 착신할 수 없는 상태인 경우 해당 메세지에 대해 거부/non-CPM inteworking 을 수행한다.
• Recording handling
• Automatically record/not record: 착신 메세지, 세션, 대화내용을 녹음한다.
• Multi-Device handling
• Delivery message or notification to all or subset of user's devices: 착신 메세지나 notification을 CPM 사용자의  등록된 모든 단말기나 일부 단말기로 전송한다.
• Deliver session invitation to all or a subset of user's devices: Session 요청 메세지를 CPM 사용자의 모든 등록된 단말기나 일부 단말기로 전송한다.
• Deliver based on active user Preference Profile, message size, content type: 활성화되어 있는 UPP나 메세지의 크기, 컨텐츠 종류에 따라 해당 메세지를 특정단말로 전송할 지의 여부를 결정한다.
• Non-CPM Interworking
• 연동할 특정 Non-CPM 서비스(i.e., SMS, MMS, Email)를 선택하기 위해 ISF는 XDMS로터 획득한 User Preference를 참조하여, 미디어 타입, 메세지크기에 따라 이를 결정한다.

5. 맺음말

CPM Enabler는 지난 2006년 6월에 표준화 작업이 시작되어 지난 8월 종료를 했으니, v1.0 표준화 완료까지 장장 4년이란 시간이 걸린 셈이다. 그렇게 표준화를 하는 과정에서, 당시 Work Item이 나왔을 때까지만 해도 초기시장이었던 통합메세징 시장이 어느덧 지금에는 모든 메세징 관련 서비스들의 당연한 Feature로 자리잡고 있을 만큼 보편화 된 듯 하다. 그런 점에서 CPM 표준의 완성 시점이 time to market을 맞추지 못했다는 지적에 대해 자유롭지는 못할 듯 싶다. 하지만, 글로벌 이통사들이 4G 네트웍을 점차 구축해 나가고 많은 솔루션 벤더들이 4G관련 솔루션들을 쏟아내고 있는 지금 All-IP에 기반을 두고 있는 CPM 표준이 가지는 의미는 주목할 만하다. 특히, CPM 표준에서 정의하고 있는 Non-CPM Interworking, Multiple Device지원, Multiple User Preference Profile, Multiple Streaming과 같은 기능은 앞으로 메시징 시장이 All-IP기반으로 진화하면서 과도기적으로 또는 항상적으로 수용해 가야 하는 특징이라고 보여진다. 

LTE에서의 IMS Telephony 부가서비스

GSMA 는 IR.92에서 IMS UE와 IMS TAS가 지원해야 할 부가서비스를 명시하고 있다. 다음은 해당 문서에서 명시하고 있는 부가서비스의 종류와 그 각각에 대해 기술한다.

	부가서비스	내용	규격
1	XCAP	부가 서비스를 위한 단말 설정 파라미터 설정	TS24.263
2	Ad-hoc Multi Party Conference	그룹 통화 및 3자 통화	TS24.605 TS24.147 RFC4575
3	Communication Waiting	통화 중 대기	TS24.615
4	Message Waiting Indication(MWI)	부재중 메시지 수신 알림	RFC24.606 RFC3842
5	Originating Identification Restriction(OIR)	발신자 번호 제한	TS24.607
6	Terminating Identification Restriction(TIR)	착신자 번호 제한	TS24.608
7	Communication Diversion(CDIV)	호 전환	TS24.604
8	Communication Barring(CB)	호 금지	TS24.611

1.     XCAP 지원

UE는 부가서비스와의 연동구간(Ut)에서 부가서비스 관련 단말 파라미터를 설정할 수 있도록 XCAP을 지원해야 한다.

2.     Ad-hoc Multi Party Conference

UE는 다자간 통화를 위한 기능을 제공해야 한다. 다자간 통화를 위한 세부기능은 다음과 같다.

•       그룹 통화 생성/삭제/관리

•       그룹 초대/탈퇴

•       그룹 정보 및 이벤트 조회

•       발언권 관리

•       그룹 정책 관리

•       미디어 처리

3.     Communication Waitng

착신자가 통화중인 상태에서 호가 도착한 경우 UE는 이를 착신자에게 알리고, 착신자의 응답을 기다릴 수 있다. 만일 TAS에서 사용자의 상태를 알 수 있는 충분한 정보를 가지고 있다면, 사용자의 설정에 따라 발신자에게 호대기 상태임을 알릴 수 있다.

4.     Messaging Waitng Indication(MWI)

이는 Deferred Message 처리를 위한 서비스로서, UE가 메시지를 착신할 수 없는 상태에 있어 착신되지 못하고 서버에 저장되어 있는 메시지들을 UE가 메시지를 착신할 수 있는 상태로 천이했을 때 전송해주는 기능을 제공한다. 이를 위해 Subscription/Notification 메커니즘을 이용해 UE는 저장되어 있는 각 메시지들에 대한 정보를 받아 올 수 있고, 사용자의 요청에 따라 해당 메시지들을 단말로 착신한다.

5.     Originating Identificaiton Restriction(OIR)

발신자가 익명을 요청할 경우 인증과정을 거쳐 이를 처리할 수 있는 서비스를 제공한다. 발신자가 익명을 요청하더라도  발신자의 실제 주소값은 P-Asserted-Identity 헤더에 설정되어야 하며, 이 값은 trusted network안에서는 항상 존재한다. 착신단말은 발신자가 익명을 요청한 경우, 발신자의 실제 주소값인 P-Asserted-Identity를 착신자에게 노출하지 않아야 한다.

6.     Terminating Identification Restriction(TIR)

착신자가 익명을 요청할 경우 인증과정을 거쳐 이를 처리할 수 있는 서비스를 제공한다. 착신자가 익명을 요청하기 위해서는 SIP INVITE에 대한 응답 전송 시 P-Preferred-Identity에 사용자가 원하는 Nickname을 설정할 수 있다. P-CSCF는 To헤더의 값을 P-Preferred-Identity의 값으로 설정하고 P-Assereted-Identity는 To헤더에 있던 실제 주소값으로 설정한다.

7.     Communication Diversion(CDIV)

착신호를 제 3의 UE로 forwarding하는 서비스의 집합을 의미한다. Communication Service는 사용자가 설정한 조건을 기반으로 제 3의 UE 또는 사용자에게 해당 호를 Forwarding할 수 있다. 다 음은 호를 Forwarding할 수 있는 조건과 그 동작을 기술한다.

Type	Conditions	Descriptions	Comment
CFU	Unconditional	착신 주소 기준 무조건 착신전환	GSMA requested
CFB	Busy	통화중	GSMA requested
CFNR	No Answer	무응답	GSMA requested
CFNL	Not registered	네트웍 미접속	GSMA requested
CD	N/A	제 3자에게 호 전환
CFNRc	Not reachable	메시지 전송불가	GSMA requested
CDIVN	After Call forwarding	착신자에게 호전환 통보
Others	Presence status	상태
	Media	미디어	GSMA requested
	Caller identity or lack of identity	발신주소
	Time of the call	시간

* CFU: Communication Forwarding Unconditioinal

* CFB: Communication Forwarding Busy

* CFNR: Communication Forwarding No Reply

* CFNL: Communication Forwarding No Logged-in

* CD: Communication Deflection

* CFNRc: Communication diversion on mobile subscriber not reachable

* CDIVN: Communication Diversion Notification

8.     Communication Barring(CB)

사용자는 User preference 설정을 통해 착신호 또는 발신호를 선택적으로 금지할 수 있다. 이는 크게 Incoming Communication Barring(ICB), Outgoing Communication Barrging(OCB), Anonymous Communication Barring(ACB)로 구분할 수 있고, 각각 수신호, 발신호, 익명호에 대한 호 금지를 의미한다. TAS는 호시도를 위한 SIP INVITE 수신 시, 착신사용자의 User preference를 확인하여 메시지를 착신할 지 여부를 결정한다.

3GPP [TS24.611]은 CB 서비스를 위해 설정할 수 있는 조건을 다음과 같이 정의하고 있다.

•   Presence-status: 착신사용자의 상태값

•   Cp:identity: 발신자의 ID

< ?xml version="1.0" encoding="UTF-8"? >    < ruleset xmlns="urn:ietf:params:xml:ns:common-policy" >        < rule id="f3g44r1" >            < conditions >                < identity >                    < one id="sip:alice@example.com"/ >                    < one id="tel:+1-212-555-1234" / >                    < one id="mailto:bob@example.net" / >                < /identity >            < /conditions >            < actions/ >            < transformations/ >        < /rule >    < /ruleset >

•   Anonymous: 익명 발신자

•   Cp: validity : 특정 시간대

•   Media: 특정 미디어

•   Communication-delivered: 호가 전환된 경우

•   Roaming: 로밍 호인 경우(P-Visisted-Network-ID, P-Access-Network-Info)

•   Ocp:external-list : user id가 외부에 저장되어 있는 경우

•   Ocp:other-entity : 다른 조건에서 설정되었던 ID를 제외한 다른 모든 identity.

•   International : request-URI가 tel uri이거나 SIP uri이고, 발신지가 home network이 아닌 경우

•   International-exHC: International의 조건을 만족하고, 착신네트웍이 착신자의 home network이 아닌 경우.

•   Rule-deactivated: Rule을 비활성화 하기 위해 사용.

사용자는 위의 한 개 또는 그 이상의 조건을 사용하여, 특정 착신호를 금지할 수 있다.

< Red Mouse >