레이블이 CAB인 게시물을 표시합니다. 모든 게시물 표시
레이블이 CAB인 게시물을 표시합니다. 모든 게시물 표시

2011년 12월 13일 화요일

GSMA RCS V1에서 V4. 기능별 진화

RCS는 사용자가 보다 효율적으로 개인화된 멀티미디어 커뮤니케이션 서비스를 사용할 수 있도록 하기 위한 서비스 규격으로 2008년부터 GSMA에서 RCE(Rich Communication Ecosystem)의 일환으로 그 표준 작업이 이루어지고 있다. 현재까지 Release4 까지 작업이 완료되어 있다.

RCS-e는 사용자에게 인스턴트 메세지, 비디오, 채팅, 파일 전송 서비스를 제공하는 커뮤니케이션 서비스로 2011년 2월 MWC에서 유럽의 이동 통신사인 Deutsche Telecom, Orange, Telecom Italia, Telefonica, Vodafone이 모여 규격화를 진행하기로 결의한 이후 현재까지 v1.2까지 나와있다. RCS-e 는 기존 RCS Release2를 기반으로 하고 있으며 이동 통신사 간의 상호 연동성과 eco system, time to market을 고려하면서 보다 단순한 사용자 경험을 종단 사용자에게 제공할 수 있는 방향으로 표준화되고 있다.

본 포스팅에서는 서비스 기능과 기술 측면에서 RCS-e 규격의 기반이 되고 있는 RCS 규격의 각각의 기능이 어떻게 변화되고 있는지에 관해 살펴보고자 한다. 각 기능에 대해 자세히 살펴보기 전에 다음 그림은 RCS의 각 기능들이 Release1에서 Release4로 가면서 어떻게 진화하고 있는지에 대한 맥락을 보여준다.


그림에서 RCS의 대부분의 기능은 이미 RCS R1에서 정의하고 있음을 볼 수 있다. 이후에 각각의 기능들이 복수단말 환경과 LTE 환경을 고려하면서 점차적으로 진화하며, RCS Release1에서 정의되지 않았던 새로운 기능들이 조금씩 생겨나고 있다. 커뮤니케이션 서비스가 제공되는 환경에 대한 변화를 고려하면 각 기능들의 진화방향에 대해 조금은 이해하기 편할 수도 있겠다. 다음은 각 기능들의 변화에 대한 세부적인 내용을 기술한다.

1. Configuration Provisioning
RCS 단말이 사용자에게 RCS 서비스를 제공하기 위해 필요한 형상 데이타는 서비스 초기화 과정에서 사용자의 개입 없이 자동으로 사용자의 단말로 전송된다. 형상 데이타를 전송하기 위해 RCS에서는 OMA DM기술에 정의된 절차를 따른다. 사용자가 RCS단말을 켰을 때 RCS Client는 이러한 형상 데이타를 기반으로 네트웍에 대한 단말 등록을 포함하여 사용자가 RCS 서비스를 이용할 수 있는 환경을 구성한다. 대부분의 형상 데이타는 서비스 제공자에 의해서만 수정이 가능하나 정책에 따라 일부의 형상 데이타를 사용자가 관리할 수도 있다. RCS Release1에서 정의한 사용자의 RCS 단말로 전송되는 형상 데이타는 다음과 같다.
  • IMS Core/SIP setting
  • XDMS/Presence/NAB/IM/File Transfer Settings
  • Device Management server access settings
  • RCS parameters(e.g., maximum size for File Transfer)
  • BA device parameters(e.g., MSISDN)
RCS Release3에서는 RCS Release1에서 정의한 형상 데이타에 네트웍 진화에 따라 그리고 보다 풍부한 사용자 경험을 제공하기 위해 다음의 형상 데이타가 추가로 정의되었다.
  • Contents Sharing(i.e., same network file storage platform and settings)
  • Personalized Invitation(i.e., maximum text size for invitation)
  • URL Label(<200)
  • Geo-localization(i.e., minimum periodic update)
  • Geo-location declarative text(i.e., maximum text size<200)
  • IMS as primary device(i.e., BA Client)
  • Expiration and minimum duration between location information update

R1
R2
R3
R4
RCS configurations
Provisioning Mechanism
-
Additional RCS configurations
-

사용자의 정보를 외부와 공유하고 커뮤니케이션 플랫폼을 기반으로 하는 부가적인 서비스가 점차 증가함에 따라 서비스 제공자의 입장에서 또는 사용자에 입장에서 제어할 수 있어야 하는 기능들도 증가하게 될 것이다. 위치기반 서비스를 위한 위치정보가 Release3에서 포함되었듯이, N-screen이나 클라우드와 같은 통신 환경을 반영하기 위한 형상 데이타가 향후 추가될 수 있을 것으로 생각된다. 

2. EAB(Enhanced Address Book) & NAB(Network Address Book)
EAB는 기존 단말 주소록의 진화된 형태의 주소록으로서 contact의 기본 연락 정보외에 contact의 service capability(i.e., video call, image/video sharing, file transfer, chat)와 social presence information(i.e., Availability, portrait icon, free text, favorite link, Timestamp)과 같은 부가 정보를 제공한다. 사용자는 NAB로 EAB의 내용을 백업하거나 동기화할 수 있다. RCS Release1에서 정의한 주소록 관련 주요 기능은 다음과 같다.
  • contact의 service capability 정보 제공
  • Social Presence Information 관리 및 Social Presence Information교환을 위한 상호 인증(i.e., Accept, Ignore, Block, Not answer) 기능
  • Black list
  • 내부 주소록 및 외부 리소스에 대한 yellow/white page 검색
  • NAB연동을 통한 주소록 백업 및 동기화
  • Inbox/Outbox/Call log에 대한 통합 뷰 제공
NAB를 통해 복수 단말의 주소록을 백업하고 동기화 했던 RCS Release1의 기능은 RCS Release2에서 각 기능에 대한 세부 사항이 구체화 되었다. 다음은 RCS Release2에 추가된 NAB의 주요 기능을 나열한다.
  • NAB와 EAB간의 동기화에 의한 변경 로그 관리
  • NAB의 주소록 관리(i.e., contact 추가, 삭제, 변경)
  • Hard Delete/Soft Delete 
  • 사용자 ID 기반 service capability 및 social presence information 제공  

R1
R2
Service Capability/Social Presence 
Information
Black list
Yellow/White page 검색
AB backup & synchronization
Unified view(Inbox/Outbox/Call log)
Support of multiple devices(Converged Environment)
Change log
AB management(add, delete, modify)
Hard delete/Soft delete


사용자의 단말이 모바일 단말과 PC, 테블릿등으로 다양해지고 있고 서로 다른 단말에서 커뮤니케이션 서비스를 다양한 형태로 이용할 수 있는 가능성이 증가함에 따라 통합된 커뮤니케이션 환경에 대한 중요성이 부각되고 있다. 초기 단순한 데이타 스토리지의 역할만을 수행했던 네트웍 기반 주소록은 향후 SNS와 같은 부가적인 서비스를 추가해가면서 진화할 것으로 예상된다. OMA에서 표준화 작업중인 통합주소록, CAB(Converged Address Book)이 그 대표적인 예라 하겠다. OMA CAB은 SNS의 대표적인 특성인 사용자 간 오픈 그래프를 생성하고 데이타를 공유하는 등의 기능을 포함하고 있다.

3. Social Presence Information
Social Presence Information은 RCS 사용자의 상태 정보로서 사용자의 mood, activity, status등이 포함되며, RCS 사용자는 자신의 Social Presence Information을 변경할 수 있다. RCS 사용자는 Social Presence Relationship을 맺고 있는 contact의 Social Presence Information을 EAB에서 확인할 수 있다. RCS에서 정의하고 있는 Social Presence Information은 다음과 같다.
  • Availability: 커뮤니케이션에 대한 사용자의 willingness
  • Portrait icon: 사용자의 사진 또는 아바타
  • Free text: 테스트 기반 모드와 이모티콘
  • Favorite Link: 사용자의 홈페이지(e.g., mobile blog)
  • TimeStamp: 마지막 갱신 시간

RCS 사용자 간의 Social Presence Relationship은 페이스북의 'Friends'와 같은 개념으로 서로 간의 상호인증 절차를 거쳐 성립된다. Social Presence Relationship 요청 메세지를 수신한 RCS 사용자는 해당 요청을 Accept/Ignore/Block/Not answer 가운데 하나를 선택하여 처리할 수 있다. 두 RCS 사용자가 서로의 Social Presence Information을 확인할 수 있기 위해서는 착신 RCS 사용자가 Social Presence Relationship요청메세지를 수락(Accept)해야 한다. 한편, Social Presence Relationship을 맺고 있는 RCS 사용자는 그 관계를 해제할 수 있는데, 이렇게 Social Presence Relationship 관계가 해제된 두 RCS 사용자 간에는 더 이상 Social Presence Information을 조회할 수 없다. RCS 사용자가 자신의 EAB에서 Social Presence Relationship을 맺고 있는 상대 RCS 사용자를 삭제하는 경우에도 동일하게 처리된다.

RCS Release2에서 BA 단말을 포함한 복수 단말이 지원됨에 따라 RCS 사용자의 Social Presence Information을 확인하고자 할 때 복수 단말간의 서로 다를 수 있는 Social Presence Information값을 통합하여 고려해야 한다. 예를 들어, Chat service가 사용자의 모바일 단말(primary)에서는 지원되지 않고 BA 단말(secondary)에서만 지원되는 경우 해당 RCS 사용자의 service capability는 Chat service를 지원하는 것으로 표현되어야 한다. 이는 사용자의 Social Presence Information이 사용자의 각 단말 별로 정의되는 것이 아닌 사용자 ID 기준으로 정의됨을 의미한다.

한편 Social Presence Information처리와 관련하여 RCS 사용자의 복수단말 가운데 어느 하나의 단말에서 수행한 작업의 결과는 해당 사용자의 다른 단말에도 동일하게 적용되어야 한다. 예를 들어, RCS 사용자가 임의의 다른 RCS 사용자로부터 Social Presence Information에 대한 Subscription 요청 메시지를 수신하고 이를 처리한 경우나 RCS 사용자가 다른 RCS 사용자에게 Social Presence Information 에 대한 Subscription 요청 메시지를 전송하고 그 결과로 수신한 Notification을 처리하는 경우가 이에 해당한다. 즉, RCS 사용자가 복수 단말을 가진 경우 어느 한 단말에서의 요청 처리 결과가 다른 단말에도 반영될 수 있어야 사용자는 서로 다른 단말에서 동일한 RCS 서비스를 제공받을 수 있는 것이다. 이와 동일한 맥락에서, 복수단말을 가진 RCS 사용자가 어느 한 단말에서 자신의 Social Presence Information을 변경한 경우에도 동일한 변경내용이 다른 단말에도 적용되어야 한다. 이때, 단말이 꺼져 있는 경우와 같은 예외상황에 대응하기 위해 RCS Client는 내부적으로 RCS 리스트를 관리해야 하며 이 리스트는 RCS 서버의 값과 항상 동기화가 되어있어야 한다. RCS 리스트는 사용자의 Social Presence Information의 변화를 통보 받아야 하는 대상, 즉 Social Presence Relationship을 맺고 있는 RCS 사용자의 리스트를 의미한다.

RCS Release2에서 사용자의 Permanent Presence State (i.e., Portrait icon, Free text, Favorite link, willingness)는 단말과 Presence XDMS간 연동에 의해 publication되고 service capability의 경우 직접 SIP PUBLISH를 이용해 전송하게 된다.

RCS Release2까지 RCS 사용자가 Social Presence Information에 대한 초대 메시지 전송 시, 해당 메시지를 수신한 착신 RCS Client의 EAB에 발신 RCS 사용자의 ID가 존재하지 않는 경우 발신 사용자의 MSISDN을 화면에 보여주었다. RCS Release3에서는 발신 사용자의 MSISDN이 직접 노출되는 사용자 경험을 개선하고자 발신 RCS 사용자가 Nickname을 설정할 수 있도록 하였으며, 이 경우 동일한 상황(i.e., 착신 RCS 사용자의 EAB에 발신 RCS 사용자의 contact이 존재하지 않는 경우)에서 착신 RCS Client의 화면에는 발신 사용자의 Nickname이 보여지게 된다. 또한, RCS Release3에서는 기존의 text와 기호의 나열로 표현되었던 URL대신 ‘user friendly’ label을 사용할 수 있도록 하는 기능이 추가되었다.

이밖에, RCS Release3에서는 기존에 Social Presence Information의 일부로 제공되었던 service capability가 독립된 정보로 분리되었다. 이는, 기존에 Social Presence Relationship을 맺어야만 확인할 수 있었던 contact의 service capability를 그러한 관계와 상관없이 확인할 수 있게 되었음을 의미한다. 단말에 표시되어지는 contact의 service capability를 조회하여 RCS사용자는 누구와 Social Presence Relationship을 맺을 지를 선택할 수 있다.

RCS Release3에서 사용자는 자신의 위치정보를 다른 RCS 사용자와 공유할 수 있게 되었다. RCS 사용자의 위치정보는 수동으로 텍스트를 입력하거나 또는 지도상에 표기되어 보여질 수 있고 자동으로 일정 주기마다 갱신될 수도 있다. 또한, RCS 사용자는 특정 contact와의 위치정보 공유기능을 차단할 수 있다.


R1
R2
R3
R4
Social Presence information
Social Presence Relationship
Service Capability
Support of multiple devices(including BA)

Nickname
‘user friendly’ label
Service capability split
Geo-location sharing

-

Social Presence Information은 규격에 언급된 내용외에도 서비스 제공자가 제공하는 부가서비스에 따라 매우 유연하게 사용할 수 있을 것으로 보인다. 이는 RCS 커뮤니케이션 플랫폼이 그 상위에 다양한 비즈니스 모델의 부가서비스를 수용할 수 있는 구조로 진화할 수 있고 경우에 따라 RCS Client 레벨에서 필요한 정보를 제어할 수 있음을 의미한다. 소셜 플랫폼이 사용자들간의 정보를 흘려보내주는 기반이 된다는 사실을 상기하면 향후 Social Presence Information의 확장은 당연한 변화가 될 것이다.

4. 파일 전송
파일전송을 위한 세션은 통화 세션이나 채팅 세션과는 독립적으로 동작한다. 통화 중이나 세션 중에 사용자는 파일을 전송할 수 있으며 파일 전송요청을 수신한 RCS 사용자는 해당 파일의 전송을 수락/거부할 수 있다. RCS 에서의 파일전송은 Ad-hoc 그룹을 포함할 수 있고 각 contact에 대해 한번에 하나의 파일만을 전송할 수 있도록 되어 있다. 또한, 서비스 제공자는 전송될 수 있는 파일의 크기를 제한할 수 있다. 파일전송 기술은 OMA SIMPLE IM v1.0에 정의된 절차에 따른다. 

5. Contents Sharing(Video/Image Sharing)
RCS 서비스는 Video Sharing 및 Image Sharing 기능을 제공한다. RCS Release 1에서의 Video Sharing과 Image Sharing은 각각 IR.74와 IR.79에 의해 정의되며 Video/Image Sharing을 위한 세션이 모두 음성 통화 세션에 종속된다. 즉, 음성 통화 중 Video/Image Sharing 요청을 할 수는 있으나 그 반대는 불가능하다. 음성 통화와 Video/Image Sharing을 동시에 사용하고 있을때 Video/Image Sharing 의 종료가 음성 통화에 영향을 미치지는 않으나 음성 통화를 종료하는 경우 사용 중이던 Video/Image Sharing 서비스는 종료된다.


Video/Image Sharing기능은 RCS Release2에서도 RCS Release1에서와 마찬가지로 음성 통화 세션에 대한 의존성을 가진다. 다만, RCS Release2의 경우, SIP 망에서 제공하는 고유의 forking 기능에 의한 복수단말 지원이 가능해진다. 이는 사용자가 실제로 음성통화에 사용하는 모바일 단말과 Video/Image와 같은 컨텐츠를 수신하는 단말(e.g., PC)을 달리 할 수 있음을 의미한다.

RCS Release3에서의 Video Sharing은 IR.84에 의해 구현됨으로써 RCS Release2까지 있었던 Video Sharing 세션의 음성통화 세션에 대한 의존성을 제거했다. 이는 사용자가 Video Sharing 서비스를 음성통화와는 무관하게 독립적으로 사용할 수 있게 됨을 의미한다. 그러나, RCS R3단말은 이전 버전의 RCS 단말에 대한 역호환성을 제공할 수 있어야 한다. 즉, 상대편 사용자가 RCS R1이나 RCS R2 단말 사용자인 경우, IR.74에 정의된 형태의 Video Sharing 서비스를 제공할 수 있어야 한다. 이밖에 RCS R3 Video Sharing은 다음과 같은 기능을 제공한다.
  • Video Sharing 지연 처리(deferred delivery): URL이나 MMS의 형태로 전송
  • 사용자의 컨텐츠 서버에 저장된 video clip을 음성통화와 함께 전송

RCS Release4에 들어와 RCS가 LTE를 지원하게 되면서 좀 더 넓은 대역을 기반으로 고화질의 Video Sharing이 가능하게 되었다. 고화질의 컨텐츠 전송 외에 Image sharing 서비스는 사용자에게 Image를 조작할 수 있는 기능을 제공하고 그 결과가 실시간으로 각 종단 단말의 화면에 반영될 수 있는 기능을 제공하고 있다(Synchronization of real-time interaction). 즉, Image Sharing 서비스 사용자는 화면상의 image를 확대/축소/스크롤하거나 image위에 임의의 그림을 그릴 수 있고 이 결과가 상대편 종단 사용자에게 실시간으로 전송됨으로써 상대편도 동일한 화면을 볼 수 있게 되는 것을 의미한다. 한편, RCS Release4에서의 video sharing은 동영상 멈춤, 재개 기능이 추가되었다. Video sharing 사용자는 단말에서 재생중인 동영상을 임의로 멈추거나 재개할 수 있으며 이러한 동작으로 인한 결과는 상대편 사용자에게 실시간으로 전송되어 상대편 역시 동일한 화면을 공유하게 된다(Synchronized pause and resume). 


R1
R2
R3
R4
IR.74
IR.79
Support of multiple 
devices
IR.84(remove voice call dependency)
Deferred video 
sharing
High-resolution video sharing
Synchronization of real-time interaction
Synchronized pause and resume


RCS에 기반한 모든 서비스가 반드시 Video/Image Sharing 기능을 제공할 것으로 보이지는 않는다. 그러나, 이 기능은 향후 RCS 서비스를 기반으로 그 위에 탑재될 부가서비스에 대한 가능성을 보여주는 것이라는 정도로 의미를 부여하는 게 맞지 않을까 생각된다.

6. Enhanced Messaging
RCS 메세징 서비스는 MSISDN 기반의 서비스로 IP기반의 메세징 뿐 아니라 MMS와 SMS, Video/Voice Call, Contact Share를 모두 하나의 통합된 환경으로 제공한다. 사용자는 SMS/MMS를 동일한 UI를 통해 작성할 수 있으며(Unified Composer) 해당 내용의 길이와 미디어 타입에 따라 메세지가 SMS로 전송될 지 MMS로 전송될 지를 RCS Client가 판단하여 전송한다. 또한, RCS메세징은 대화형 기반의 서비스로서 사용자와 주고받은 모든 대화는 대화 참여자의 ID(i.e., MSISDN) 기반으로 하나의 대화 채널로 통합(Threaded View)된다.

RCS 채팅은 RCS 단말간에만 지원되며 'near real time'메세지 전송을 보장한다. RCS 채팅은 1-1과 그룹채팅을 모두 지원한다. 그룹 채팅은 ad-hoc 형태로 시작하거나 1-1 대화 세션의 확장일 수 있다. 또한, 상대 RCS 사용자가 RCS 채팅 메세지를 수신할 수 없는 경우 해당 메세지를 다른 형태의 커뮤니케이션 서비스(i.e., SMS, MMS)를 통해 전송할 수 있다. 한편, 그룹 채팅 생성자는 또 다른 참여자를 초대할 수 있으며 그룹 채팅에 참여중인 참여자는 현재 참여하고 있는 참여자의 정보를 확인하거나 참여자의 입장/퇴장에 관한 정보(Participation Information)를 실시간으로 통보 받을 수 있다. 서비스 제공자는 그룹 채팅 서비스를 활성화 하거나 비활성화 할 수 있으며 채팅 세션에서 일정 시간동안 데이타 교환이 발생하지 않는 경우 세션을 자동으로 종료하도록 시간을 설정할 수 있다. RCS 채팅을 위한 기술적 정의 및 절차는 OMA SIMPLE IM v1.0을 기반으로 하고 있다.

RCS Release2에서는 Broadband Access 단말(i.e., PC)에서 SMS를 전송할 수 있는 기능이 추가되었다. 단, BA단말의 경우 SMS 전송 외에 SMS 수신, MMS 발/수신 기능은 제공되지 않는다. 또한, BA 단말에서 전송된 SMS내역은 단말의 Threaded View에 반영되지 않는다. RCS Release2에서는 RCS 채팅요청에 대한 명시적인 수락/거부 기능은 제공되지 않는다. 즉, 사용자는 EAB에서 선택한 contact에게 전송된 메세지는 착신자에게 별도의 수락/거부를 질의하는 절차없이 착신자에게 전송된다. 대신, 착신자가 해당 메세지에 대한 응답 메세지를 전송하는 경우 이를 수락으로 간주하여 해당 채팅 세션을 생성하는 절차를 수행한다.

RCS Release3에서는 BA Client가 primary client의 기능을 수행할 수 있도록 하였다. Primary 단말로 설정된 BA Client는 SMS, MMS를 수/발신 할 수 있으며 이들 각각에 대한 수신확인처리가 가능하다. 그룹 메세징인 경우 요청 메세지 전송 시 함께 전송되는 다른 참여자의 정보를 각 착신자가 확인할 수 있어야 한다. 다음 그림은 메세징 서비스에 관한 RCS R3의 network deployment를 도시한다.


RCS R3 Client는 SMS/MMS 발착신을 위해 RCS 서버에서 별도의 기능을 제공하지 않고  SMS-C 및 MMS-C와 직접 연동하여 전송한다. 이는 RCS Client가 EAB에 저장되어 있는 contact의 RCS 가입자 인지의 여부를 기반으로 Legacy Messaging Service를 이용할 지 RCS 메세징 서비스를 이용할 지 결정함을 의미한다. Primary client가 BA Client인 경우, BA Client를 통해 SMS를 발/수신하기 위해서는 3GPP IP-SM-GW[TS23.204, TS24.341]를 사용한다. IP-SM-GW는 SMS 메세지와 IP메세지간 메세지 변환 기능을 수행한다. BA Client를 통해 MMS를 전송하는 경우 3GPP의 [TS23.140]에 정의된 절차를 따른다.

RCS Release4에서의 메세징 서비스는 기존의 SMS/MMS가 가지고 있던 서비스적 한계를 모두 제거하면서 SMS/MMS 사용자에게도 IP메세징 서비스와 동일한 사용자 경험을 주고자 하였다. 또한, Message Storage를 제공함으로써 사용자의 복수단말에서 발/수신되는 모든 대화이력을 통합된 환경에서 제공하고 있다. RCS Release4에서의 text messaging은 모바일 단말과 BA Client를 모두 지원하며 기존 text messaging(SMS)이 가졌던 메세지 길이의 제한을 가지지 않는다. 이 경우, RCS R4 단말과 이전 버전의 단말간 text messaging 교환을 위해서 IP-SM-GW는 RCS R4단말에서 전송된 text message를 chunked message로 나누어 전송 한다. RCS R4 메세징 사용자는 그룹 contact에게 text message를 전송할 수 있다. Group text message를 수신한 사용자는 이에 대한 응답을 그룹의 모든 수신자에게 전송할 수 있다.

RCS Release4에서 새롭게 소개된 Network-based Message Storage는 사용자가 발/수신한 멀티미디어 메세지를 저장한다. 메세지 저장 시 별도의 메타 데이타를 생성해야 하며, 이 메타 데이타는 사용자가 자신의 Message Storage의 내용을 조회하거나 단말로 다운받기 위해 사용된다. 또한, 사용자는 Message Storage의 폴더체계를 원하는 형태로 관리할 수 있다. Message Storage에 저장된 메세지는 사용자의 복수 단말에 동일하게 적용될 수 있으며, 이를 통해 복수 단말을 가진 RCS 사용자에게 일관된 대화이력 뷰를 제공할 수 있다.

RCS Release4에서는 non-RCS 사용자(e.g., SMS/MMS 사용자)가 Chat 세션에 참여할 수 있다. 서비스 제공자의 정책에 따라 non-RCS 사용자는 명시적인 초대를 받고 정해진 형태의 응답 메세지를 전송함으로써 Chat 세션 요청을 수락/거부할 수 있거나 또는 자동으로 Chat 세션에 참여할 수 있다. Chat 세션에 참여한 non-RCS 사용자는 다른 RCS 사용자와 마찬가지로 모든 메세지와 참여자 정보 및 이벤트를 받아 볼 수 있으며, non-RCS 사용자의 메세지 또한 Chat 세션의 참여자 모두에게 전송된다. non-RCS 사용자는 서비스 제공자의 정책에 의해 규정된 형태의 메세지를 전송함으로써 해당 Chat 세션을 종료할 수 있다.

RCS Release4에서의 주요 커뮤니케이션 기술은 OMA CPM에 기반하며 다음은 RCS Chat 서비스를 위한 개념도를 예시한다.




R1
R2
R3
R4
Support of Legacy
Messaging
Unified Composer
Threaded View
IP-based Chat
1-1/Ad-hoc Group Chat
IM Pager/Large Mode
BA Client included(only to send SMS)
No Accept/Reject from a recipient
IP-SM-GW interworking
BA Client being primary device
BA Client being able to send/recv SMS/MMS

Large text messaging
Group text messaging
Message Storage
Support of unified view across multiple devices.
Non-RCS incorporation into RCS Chat session.

RCS의 Enhanced Messaging 기능은 초기 OMA SIMPLE IM 1.0 기술에 기반하고 있으나, RCS Release4로 오면서 OMA CPM 1.0 기술을 부분적으로 채택하고 있다. OMA CPM은 SIMPLE IM의 기능을 그대로 수용하면서 Legacy Messaging Service를 통합하여 제공하고 있다.

7. 복수 단말 환경
RCS Release1에서 모바일 단말을 중심으로 제공되는 서비스는 RCS Release2로 오면서 기존의 모바일 단말 외에 Broadband Access Client에 대한 지원도 가능하게 되었다. 이에 따라 RCS 사용자는 각 단말에서 Communication, EAB, Social Presence Information등과 같은 서비스 측면에서 동일한 서비스 환경을 제공받을 수 있게 되었따. 복수 단말 가운데 CS 접근 능력을 가지는 모바일 단말이 primary 단말이 되며 BA Client느느 secondary 단말로 동작한다. 또한, RCS 사용자의 모든 단말은 primary 단말이 가지는 하나의 MSISDN으로 묶인다.

RCS Release3으로 오면서 BA Client를 primary 단말로 선택하는 것이 가능해졌다. 이는 BA Client에서도 SMS/MMS의 발/수신을 할 수 있게 되었음을 의미한다. 이 서비스는 단말이 CS(Circuit Switched)망의 SMS-C/MMS-C를 직접 연동하거나 IMS의 IP-SM-GW와 연동함으로써 가능하다. 그러나, 이 경우 종단점이 각각 BA Client와 모바일 단말인 경우 메세지 전송 방향(또는 사용하는 메세징 서비스 종류)에 따라 네트웍 상의 루트가 상이하기 때문에(IP-SM-GW 또는 RCS-IM), 대화 내역에서 동일한 contact 대한 발/수신 대화내역의 통합이 어렵다는 단점이 있다. 이는 EAB 에서 contact의 RCS 가입 여부에 따라 RCS 서비스를 이용할 지 SMS/MMS를 사용할 지를 결정하기 때문에 발생하는 단점이기도 하다.

RCS Release4로 오면서 기존의 RCS 플랫폼에서 OMA CPM IWF를 채택함에 따라 RCS 단말은 RCS 서비스와의 단일한 인터페이스의 구현이 가능해졌다. 이에 따라 RCS Release4에서는 IP 메세지 및 Legacy 메세지의 구분 없이 통합된 대화내역의 관리가 가능해졌으며 또 한편으로 Network-based Message Storage가 제공됨에 따라 서로 다른 복수 단말간 통합된 커뮤니케이션 관리가 가능해졌다.

R1
R2
R3
R4
-
BA Client as a 
secondary
BA Client as a 
primary
-


커뮤니케이션 서비스를 제공하는 데 있어서의 복수 단말 환경은 향후 N-screen 단말 및 서비스의 증가와 함께 다양한 형태로 진화할 수 있을 것으로 생각된다.

8. Network Value Added Service(NVAS)
RCS Release3에서는 서비스 제공자가 Network Value Added Service를 RCS 사용자에게 제공할 수 있도록 한다. NVAS의 목적은 RCS 사용자에게 보다 풍부한 사용자 경험을 제공하기 위한 것으로 구체적으로 어떤 서비스를 제공할 지는 각 서비스 제공자가 정하도록 되어 있다. 다만, RCS Release3에서는 Contents Sharing과 Chat 서비스에서의 media processing을 통한 풍부한 사용자 경험을 제공하는 것만을 언급하고 있다.

R1
R2
R3
R4
-
-
Contents Sharing 
enriched by Media 
Processing
Chat enriched by 
Media Sharing
-


RCS 서비스가 결국은 개방형 커뮤니케이션 플랫폼으로 진화할 것임을 고려할 때 다양한 비즈니스 모델을 가진 3rd-party 서비스를 어떻게 수용할 지에 대한 고려는 향후 더욱 구체화될 것으로 보여진다. 

9. Synchronization
사용자의 주소록(EAB)은 네트웍 주소록(NAB)을 통해 백업되고 동기화 된다. RCS Relese2 이후부터 제공되는 복수 단말에서의 주소록 동기화 역시 NAB 의 동기화 기능을 이용해 제공되며, RCS 사용자는 동기화 기능을 이용해 서로 다른 복수 단말간 통합된 주소록 환경을 제공받는다. 주소록 동기화 기술은 OMA DS 1.2.1에 기반한다. 디음은 NAB의 동기화 Architecture를 도시한다.


RCS Release4에서는 동기화의 대상을 캘린더와 To do list와 같은 비주소록 컨텐츠를 포함하는 PIM으로 확장할 수 있도록 하였다. RCS 사용자는 서비스 초기화 시점에 EAB를 비롯한 컨텐츠의 동기화 기능을 이용할 지의 여부를 결정한다. 동기화 기능을 사용할 경우 사용자는 동기화 주기를 비롯한 세부적인 사항을 설정할 수 있는 방법을 제공받는다. 사용자가 초기화 시점에서 동기화 기능을 선택하지 않은 경우, RCS Client는 RCS 사용자가 단말의 PIM 데이타를 조작할 때마다 RCS Service Subscription Reminder(SSR)을 기동하여 사용자로 하여금 동기화 기능을 사용하도록 유도할 수 있다. RCS 서비스에서 동기화가 가능한 PIM 데이타는 RCS "Resource Subscription" Managed Object에 포함되며 이와 관련한 기술은 OMA DS MO에 정의되어 있다.

R1
R2
R3
R4
NAB synchronization
-
-
PIM synchronization





10. Roaming
RCS Release4에서는 Roaming 상황에서 사용자와 서비스 제공자가 PIM과 메세지 전송 기능을 제어할 수 있는 기능을 제공한다. PIM의 동기화와 관련하여 RCS Client는 사용자에게 해당 기능을 사용할 지에 대한 확인을 받아야 한다. RCS사용자는 해당 기능을 단말에서 disable시킬 수 있어야 하고 사용자가 해당 기능을 사용하는 경우 과금관련 필요한 정보를 제공할 수 있어야 한다. 메세지 전송 기능과 관련하여 RCS 사용자는 해당 메세지의 헤더 정보와 함께 Notification을 수신할 수 있고, 해당 메세지의 착신 여부를 사용자가 선택할 수 있다.

R1
R2
R3
R4
-
-
-
User confirmation to 
services in Roaming 
situation




결론
GSMA RCS 서비스 규격은 사용자에게 커뮤니케이션 기능을 통합된 환경에서 제공할 수 있기 위한 서비스적인 측면과 향후 가입자 기반의 오픈 플랫폼으로 진화할 수 있는 비즈니스 모델 측면에서 표준화가 이루어지고 있다. 실제로 시장에서 많은 이동 통신사들이 실제로 구현하는 서비스는 RCS-e 기반 서비스이지만 향후 RCS-e 규격이 진화하는 방향을 가늠하는 데에 지금까지 논의되어 왔던 RCS 1,2,3,4가 많은 참고가 될 것으로 보인다. 표준규격으로 바라보는 향후 커뮤니케이션 서비스의 진화 방향에 대해서는 다른 포스팅에서 다루고자 한다.


Reference
[1] GSMA RCS "R1_030_140211_rcs_rel_1_func_descp", Functional description, R1.
[2] GSMA RCS "R1_031_140211_tech_real_v2", Technical realization, R1.
[3] GSMA RCS "rcs_rel2_func_descp_2", Functional description, R2.
[4] GSMA RCS "rcs_rel2_tech_real_2", Technical realization, R2.
[5] GSMA RCS "rcs_rel3R3_020_14rcs_rel3_func_descp_v2", Functional description, R3.
[6] GSMA RCS "rcs_rel3_tech_real2", Technical realization, R3.
[7] GSMA RCS "rcs_rel4_functional_description_v1", Functional description, R4.
[8] GSMA RCS "rcs_rel4_technical_realization_v1", Technical realization, R4.


-- Red Mouse



2011년 11월 14일 월요일

OMA CAB 정기회의: 2011년 11월 6일-11일

지난 11월 7일부터 5일간 중국 북경에서 OMA(Open Mobile Alliance) 정기회의가 개최되었다. 이번 정기회의에는 이통사와 솔루션 업체, 단말 제조업체를 포함하여 전 세계 51개 업체에서 184명이 참여하였다. 이번 포스팅은 OMA 분과 가운데 COM(Communication) WG 내의 CAB(Converged Address Book) SWG(Sub WG)의 동향과 이슈에 대해서 정리해 보고자 한다.

현재 CAB 분과에서는 기존의 CAB 1.0 architecture 기반위에 최근에 시장에서 이슈가 되고 있는 몇가지 기능들을 추가하여 표준화가 이루어지고 있는 CAB 1.1과 CAB 1.0의 요구사항과 함께 CAB 1.1과 마찬가지로 몇 가지 기능들을 추가하면서 architecture 관점에서 다르게 접근하고 있는 S-CAB으로 나뉘어 표준화가 진행되고 있다. 한편, 기존 CAB 1.0에 대한 Maintenance는 이 두 개의 WI(Work Item)과는 별개의 SWG으로 구분되어 진행되고 있다.

S-CAB 1.0 


지난 주에 있었던 S-CAB SWG 정기회의에서는 주소록 데이타의 merge process에 대한 기술적 이슈가 제기되었다. CAB 1.0과는 달리 CAB 1.1과 S-CAB 1.0에서는 외부의 3rd-party 서비스와 SNS에 대한 연동기능이 추가되어 CAB 사용자는 CAB 서비스에 존재하는 프로파일 정보(PCC)를 외부 노드로 전송(Export)하거나 외부 노드에 존재하는 자신의 프로파일정보를 CAB으로 받아올(Import) 수 있게 되었다. 이러한 데이타의 교환은 사용자의 프로파일정보에 국한되지 않고 사용자 주소록 상의 contact information으로 그 대상이 확장될 수 있다. 이러한 연동 과정을 통해, 외부 노드로 부터 유입된 데이타가 사용자의 주소록에 이미 저장되어 있는 데이타와 중복될 수 있는 가능성이 존재한다. 예를 들어, contact information에  10개의 필드가 존재하는 경우 인입된 데이타와 주소록에 이미 저장되어 있는 데이타의 10개의 필드값이 모두 일치하지 않는 한, 시스템의 입장에서 이 두 데이타가 동일한 사람임을 자동으로 인지할 수 없으므로, 사용자의 CAB 주소록에는 동일한 contact의 서로 다른 두 값이 서로 다른 레코드로 존재하는 것이다.

이는 곧 기술적으로는 외부의 갱신된 XML 데이타의 내용과 CAB 에 저장된 사용자의 데이타의 불일치가 발생하는 경우 사용자가 이를 인지하고 UI 상호작용을 통해 유효한 데이타를 선택할 수 있는 절차가 있어야 함을 의미한다. 동시에 사용자에 의해 'confirmed' 된 데이타나 'updated'된 내용을 별도로 표시함으로써 CAB Client가 이를 인지할 수 있도록 해야 한다. 이와 같은 내용을 반영하기 위해 곧 Contact Card 관련 XML schema에 대한 변경작업이 있을 것이라 예상된다.

주소록 데이타의 Merge-Update에 관련된 이슈는 아직 CAB 1.1에서는 제기되지 않았으나, CAB 1.1이 S-CAB 1.0 과 거의 동일한 요구사항을 가지고 있으므로 조만간 CAB 1.1에서도 유사한 논의가 있을 것이라 생각된다.

CAB 1.1

Subscription Invitation
CAB 1.1에서의 가장 큰 이슈는 다음의 요구사항에 대한 해결책을 모색하는 과정에서 발생되었다.

CAB-SUBS-002: The CAB Enabler SHALL allow a CAB User to invite other CAB users to subscribe to his/her Published Contact Card information based on service provider's policy.

즉, 이 기능은 Subscription Invitation 기능으로서 CAB 사용자가 다른 CAB 사용자로 하여금 자신의 PCC를 Subscription하도록 '초대'하는 기능으로써, 요청 메세지의 전달 방향 측면에서 Contact Subscription과 개념적인 측면에서 매우 다르다. 트위터로 표현하자면, Contact Subscription은 다른 사용자를 'follow'하는 것이고, Subscription Invitation은 다른 사용자로 하여금 나를 'follow'하도록 초대하는 기능이라 할 수 있겠다.

삼성의 경우 이 요구사항을 구현하기 위해 위해 기존 CAB 1.0에서 이미 정의되었던 절차인 Contact Subscription 절차를 재사용(SIP SUBSCRIBE사용)하자는 제안서를 제출했으나, Contact Subscription과 Subscription Invitation은 그 개념이 정반대인 관계로 SIP SUBSCRIBE를 사용하는 것이 적절하지 못한 재사용이라는 이유로 기각되었다. 또한, SIP SUBSCRIBE 자체로 Contact Subscription과 Subscription Invitation을 구분하기가 모호하다는 점도 지적되었다.



이와는 다른 솔루션으로 RIM에서 제출한 다른 제안서에서는 CAB 1.0의 Contact Added 절차와 매우 유사한 절차(SIP MESSAGE 사용)를 제안하고 분과 내에서 광범위하게 동의를 얻었으나 결국 삼성의 반대로 채택이 무산되고, 두 개의 솔루션을 놓고 e-Vote를 가지기로 하였다.



분과내에서 실행한 straw poll의 결과가 참여한 업체들간의 RIM의 솔루션이 5:1로 우세했던 것으로 미루어, 2주 후에 있을 e-Vote에서는 후자가 채택될 것으로 예상된다.

Direct Interface

CAB 1.1의 Client 와 Server간 새로운 Interface(CAB-2)가 제안되었다. 이는 CAB XDMS내의 Feature Handler App Usage를 사용하여 Client 와 Server간 Operation을 전송하는 것과는 별개로 Feature Handler내에 정의되어 있는 Operation을 HTTP를 이용해 Client와 Server간 직접 전달하자는 내용을제안한다. 이에 해당하는 Operation으로는 Contact Share, Import non-CAB AB data, Import External Profile이 있다.



개인적으로는 CAB 이 XDMS에 너무 의존적으로 설계되어 있어 매우 빈번하게 발생할 것으로 예상되는 Document 의 Read/Write process에 의해 시스템의 효율성이 떨어질 것을 우려하고 있기때문에 CAB-2 인터페이스의 제안은 타당해 보였다. 그러나, 삼성에서 동일한 기능을 위한 두 개의 인터페이스는를 정의하는 것에 대해 강한 반대의사를 표명하여 채택되지는 못했다. 이에 관한 기술적인 논의는 Open issue로 남게 되어 향후 계속 논의가 이루어질 것으로 보인다.

지금까지 지난 주에 CAB 분과(CAB 1.1, S-CAB 1.0)에서 있었던 주요 기술적 이슈에 대해서 알아봤다. CAB 1.1은 원래의 일정이 지연되어 5개월 정도 TP(Technical Plenary)에 slip request를 하였고 이에 따라 릴리즈 패키지 승인 목표 날짜가 내년 9월로 연기되었다.

이번 정기 미팅에 참여한 업체는 CAB 분과와 S-CAB분과를 포함하여 다음과 같다.
  • Operator: China Mobile, Orange, Forapolis, Telefonica SA
  • Solution Vendor: Ericsson, Alcatel-Lucent, Hansol, ZTE, Huawei, NEC
  • Handset: LGE, RIM, Samsung

다음 OMA 정기회의는 2012년 2월 8일부터 일주일간 하와이에서 개최될 예정이다.


-- Red Mouse

2011년 11월 4일 금요일

OMA CAB(Converged Address Book) 소개


기존의 단말 주소록은 사용자 입장에서 단말에 저장되어 있고 다른 사람과 공유되거나 노출될 가능성이 거의 없는 폐쇄된 정보였다. 다만, 단말을 분실하거나 또는 단말을 교체하는 경우를 고려하여 네트웍 어딘가에 백업이라는 개념으로 주소록 정보를 저장해 놓고 나중에 다운로드하는 형태의 서비스는 제공되고 있었다. 대다수의 이동통신사와 많은 WSP(Web Service Provider)는 사용자가 자신의 주소록을 웹 서비스 계정에 백업하고 웹상에서 직접 편집하여 다시 동기화 시키는 등의 서비스를 제공해 왔다. 그 가운데서 Plaxo 같은 서비스는 일찌감치 사용자의 주소록 그 자체를 타겟팅하여 사용자가 자신의 주소록을 쉽게 백업하고 편집할 수 있게 해주는 웹 서비스를 제공해 왔다.

최근 들어 iPad와 Galaxy Tab을 비롯한 다양한 형태의 테블릿들이 쏟아지면서 한 개 이상의 단말을 사용하게 되는 사용자가 차츰 생겨나기 시작했고 테블릿이 문자나 전화통화와 같은 커뮤니케이션 용도로도 사용될 수 있게 됨에 따라 사용자 사이에 멀티디바이스 환경이 차츰 자연스러운 현상으로 자리잡아가게 되었다. 그리고 아직은 초기시장이고 그 개념을 잡아가고 있는 스마트 TV의 등장은 이러한 현상을 가속화 시키게 될 것이다. 애플의 경우 자사에서 제공하는 iCloud 기능을 이용해 사용자가 소유한 iPhone, Mac, iPad와 같은 자사의 제품들 간의 데이타를 포함한 환경이 동일할 수 있도록 동기화 기능을 제공하고 있다.

멀티디바이스에 대한 사용자의 요구와는 별도로 다양한 형태의 소셜서비스의 등장과 함께 '공유'라는 개념이 새삼스럽게 사용자들간의 공감을 얻고 있다. 사람과 사람간의 개인정보를 공유하고 경우에 따라 주소록 정보 까지도 공유할 수 있다는 것에 대한 저항감이 점차 감소하게 되는 것이다. 페이스북이나 트위터 같은 대표적인 소셜 서비스는 내가 친구를 맺거나 팔로우하는 상대방의 프로필 정보를 상대방이 공유한 정도 만큼 조회할 수 있다. 또한, 사용자 간에 컨텐츠를 공유할 수 있게 되고 그동안 매우 사적인 영역이라고 간주되어 왔던 위치정보까지도 사용자 스스로 공개하기도 한다. 국내에서 2000만의 사용자를 거느리고 있는 카카오톡은 다른 카카오톡 사용자에게 나의 주소록에 등록되어 있는 누군가를 추천할 수 있는 기능을 제공한다.

앞으로 단말주소록은 공유(소셜)와 멀티디바이스라는 서비스 진화에 있어서의 큰 패러다임을 반영하면서 진화하게 될 것이다. 지난 2009-2010년 시기에 우후죽순 처럼 시장에 나오기 시작했던 소셜 주소록 어플리케이션 들은 이러한 움직임을 반영한다. 당시 대부분의 소셜 주소록은 기존의 단말 주소록을 중심으로 페이스북이나 트위터를 연동하여 페이스북 친구와 트위터 팔로워등을 통합하려하거나 그 가운데 삼성의 소셜허브와 같은 서비스는 페이스북이나 트위터의 타임라인을 직접 모바일 단말로 끌어서 사용자에게 보여주려는 시도를 보여왔다. 이유야 어찌됐건 아쉽게도 그들 가운데 뚜렷하게 시장을 장악한 소셜 주소록 서비스는 아직은 없어보인다. 하지만, 페이스북이 웹을 기반으로 하나의 플랫품이 되어 가고 있듯이 모바일 기반의 개인화 플랫폼에 대한 니즈는 여전히 살아있다고 믿고 있다. 단말 주소록은 사용자가 모바일 단말 상에서 실행하는 모든 커뮤니케이션의 시발점으로 모바일 단말에서 개인화된 플랫폼으로 진화할 수 있는 가장 큰 잠재력을 가지고 있기 때문이다.

이러한 관점에서 대략 2007년부터 지금까지 진행되고 있는 OMA(Open Mobile Alliance)의 CAB(Converged Address Book) 표준을 간과할 수는 없을 것 같다. OMA CAB은 1.0을 마무리하고 현재는 CAB 1.1과 S-CAB(Simplified CAB) 1.0에 대한 표준화를 진행하고 있다. S-CAB 1.0은 CAB 1.1과 동일한 요구사항을 가지고 있으나 다른 architecture를 이용해 표준화를 구현중에 있다.

이번 포스팅은 이 가운데 OMA CAB1.0의 주요 기능과 CAB 1.1에서 새롭게 포함된 주요 기능들을 기술해 보고자 한다. 참고로, 각각의 기능들에 이해를 돕고자 필요한 경우 페이스북의 유사한 기능과 비교하여 기술하였다.


1. PCC(Personal Contact Card) 및 Contact View: 접근권한 관리
OMA CAB은 PCC(Personal Contact Card)라는 개념을 제공한다. PCC는 페이스북으로 하면 개인 프로파일 정보로서 대략 다음과 같이 구성된다.
  • 성명/별명
  • 주소정보
  • 위치정보
  • 연락정보: 전화번호, SIP URI
  • 생일, 기념일
  • 성별
  • 언어
  • 홈페이지
  • 취미, 관심사
  • 경력정보
  • 기타

CAB 사용자는 누구나 자신의 PCC를 작성할 수 있고 또한 외부에 공개할 수 있다. PCC를 외부에 공개할 때는 Contact View라는 개념의 filter를 쓰게 되는데 이는 사용자가 자신의 PCC의 어떤 정보를 얼만큼 누구에게 공개할 것인가라는 것을 결정할 수 있게 해준다. 곧 페이스북의 프라이버시 정책에 해당하는 것으로 네가지 경우의 수(Friends, Friends of Friends, Public, My Own)만을 제공하는 페이스북 보다는 훨씬 더 많은 경우의 수를 만들어 낼 수 있다는 것이 특징이다. PCC의 개념을 도시하면 다음과 같다.



Contact View 라는 filter를 거쳐 다른 CAB 사용자에게 공개된 PCC를 Published Contact Card라 한다. 즉, Published Contact Card는 맞춤형 명함 같은 것이라 생각해도 무방하겠다.

2. Contact Subscription : 개인 프로필 공유
CAB 사용자는 다른 CAB 사용자의 PCC를 조회(Subscription)할 것을 요청할 수 있다. PCC 조회 요청은 상대 CAB 사용자가 이를 수락하거나 거부함(reactive authorization)으로써 완성된다. PCC 조회 요청을 수신한 사용자는 상대방이 자신의 PCC를 열람할 때 노출할 정보의 양을 Contact View라는 프라이버시 정책을 이용해 제어한다.



이러한 과정은 페이스북에서 친구를 맺는 과정과 동일하다. 친구를 맺은 두 사용자는 서로의 프로필 정보를 조회할 수 있으며, 어느 누군가의 프로필 정보가 변경되면 해당 사용자와 친구를 맺고 있는 다른 사용자에게 그 변경 사실이 통보된다. CAB에서 이렇게 통보된 정보는 수신자의 사용자 환경 설정에 따라 수신자의 단말에 자동으로 또는 수동으로 저장된다. 상대 CAB 사용자의 변경된 프로필 정보가 자동으로 적용되도록 설정을 한 CAB 사용자라면 해당 CAB 사용자의 주소록에서 '친구' 관계를 맺고 있는 다른 CAB 사용자의 프로필 정보는 항상 최신정보라고 할 수 있다. 이 기능은 기존 단말 주소록에서 일일이 사용자가 주소록 정보를 입력하고 저장했던 방식에 비해 매우 사용자에게 유용한 기능이 될 것이라고 생각된다. 예를 들어, 더이상 사용자는 자신의 단말 주소록에 있는 상대방의 전화번호를 수동으로 입력하거나 해당 정보가 오래되어 아직도 유효한 지에 관한 걱정을 하지 않아도 될 것이기 때문이다.

3. CAB capability 정보
CAB 사용자의 단말 주소록에 저장되어 있는 특정 대상이 CAB 사용자가 되었을 때, 이 사실이 CAB 사용자에게 통보될 수 있어야 한다. 이는 CAB 사용자가 자신의 단말 주소록 상의 리스트에서 CAB 사용자와 일반 사용자를 구분할 수 있음을 의미한다. 이는 CAB 사용자가 단말 주소록의 특정 상대방에게 CAB 서비스에서 제공하는 기능을 사용할 수 있는지의 여부를 알수 있게 해주는 것이기도 하다.

4. 복수 단말 지원(동기화)
CAB은 네트웍에 존재하는 사용자의 주소록으로서 CAB 사용자는 언제나 자신의 단말 주소록을 네트웍에 업로드하고 다운로드할 수 있다. 이는 사용자가 복수 단말을 가지는 경우, 해당 복수 단말간의 동일한 주소록 환경을 구현할 수 있음을 의미한다. 각 단말의 CAB 클라이언트와 CAB 서버간의 주소록 동기화는 사용자의 설정에 따라 주기적으로 자동 또는 수동으로 수행된다.



5. PCC 또는 주소록 공유(PCC or Contact Share)
CAB 사용자는 자신의 PCC나 자신의 단말 주소록 상의 특정 상대방정보를 다른 CAB 사용자와 공유할 수 있다. 단말 주소록의 특정 대상의 정보를 공유하는 기능은 기존 피처폰에서 SMS/MMS를 통해 제공하던 서비스와 동일하다. PCC 공유의 경우 마치 명함을 교환하는 것과 같은 맥락으로 이해를 할 수 있다. 대신, CAB 사용자는 자신의 공유할 PCC 정보를 제한하고 상대방에 따라 공개 여부를 설정할 수 있다는 것이 일반적인 '명함교환'과 다른 점이다. PCC 공유 기능은 단순한 일회성 정보 제공이라는 측면에서 PCC 조회 요청과는 구분된다.

6. 사용자 검색(Contact Search)
CAB 사용자는 동일한 CAB 서비스 도메인뿐만 아니라 외부 서비스에서도 사용자를 검색할 수 있으며 검색된 대상을 자신의 CAB 주소록에 저장할 수 있다.

7. 주소록 Import/Export
이는 오래전부터 제공되던 통상적인 주소록 백업 서비스에서 Outlook을 연동하거나 파일형태의 주소록 정보를 읽어들인다거나 하는 것과 동일한 기능이라고 볼 수 있다. 사용자는 이렇게 검색된 대상을 CAB 주소록에 저장할 수 있다.


8. CAB 1.1 추가 기능
2010년부터 시작된 CAB 1,1에 대한 표준화가 진행중에 있다. 현재까지 요구사항 단계가 완료되었으며 아키텍쳐와 기술표준(AD, TS) 작업을 동시에 진행중에 있다. 오는 12월부터는 이들 산출물에 대한 일관성 검토(Consistency Review)가 진행될 예정이다. 다음은 이미 완료된 CAB 1.1 요구사항에서 새로 추가된 기능들을 나열한다.
  • 연동 포맷 확장 : vCard이외의 포맷으로 구성된 주소록 Import/export
  • 다른 CAB 사용자가 자신을 단말 주소록에 포함시킨 경우 이 사실을 통보
  • 단말의 CAB 주소록 관리
  • CAB 주소록에서 삭제된 정보 복원
  • 마지막 적용된 명령에 대한 복원(roll-back)
  • Favorite Contact 관리 및 멀티디바이스 적용
  • 대화 이력 동기화(자동 또는 수동)
  • 특정 contact와 연관된 대화 이력 및 최근 activity 정보 조회
  • CAB 사용자의 non-CAB 서비스에 저장되어 있는 컨텐츠 관련 정보 관리
  • 분실단말에 대한 접근 권한 인증
  • 자신의 PCC에 대한 조회요청을 할 수 있도록 상대 CAB 사용자 초대
  • 다른 CAB 사용자로부터의 PCC 조회 요청(PCC Subscription) 자동 수락/거부
  • 3rd-party 서비스로부터(에 대한) PCC 정보 회득 또는 제공
  • 3rd-party 서비스에 저장되어 있는 CAB 사용자 자신의 PCC에 대한 조회 요청(PCC Subscription)
  • 단말 주소록에 있는 상대방(contact)의 social network 정보 조회
  • 단말 주소록에 등록할 새로운 CAB 사용자 추천
  • 단말 주소록에 저장되어 있는 CAB 사용자간의 관계 정의(강제적 정의일 수도 있고 사용자에 의한 정의일 수도 있음)
  • 단말 주소록에 저장되어 있는 CAB 사용자 간의 관계 조회
  • 단말 주소록에 저장되어 있는 CAB 사용자의 social network에서의 활동 내역 조회
  • CAB 사용자에 대한 서비스 추천
  • CAB 사용자에 대한 Mutual connection 정보 제공
  • 단말 주소록에 등록되어 있는 CAB 사용자에 대한 공개 컨텐츠 공유

CAB 1.1에 새롭게 추가된 많은 기능들은 현재 시장에서 이슈가 되고 있는 소셜 네트웍 서비스의 특징을 그대로 반영한다. 예를 들어, 페이스북의 친구추천, 서비스 추천, 페이스북 사용자와의 관계(Mutual Friends) 조회, Feeds를 통하 컨텐츠 공유, 상대방의 정보 조회, Activity 공유등과 같은 유사한 기능들이 다수 포함되어 있다.


주소록인 CAB 표준은 단순한 주소록을 넘어 소셜 네트웍 서비스로 진화하고 있다. CAB 서비스를 단말 어플리케이션으로 제공되기엔 제공하는 기능들이 너무 많아 모든 기능을 제공하기 위해서는 어쩌면 웹서비스를 함께 포함해야하지 않을까 하는 생각마저 든다. 그리고 이러한 표준을 시장에 어떠한 모습으로 풀어낼 것인가가 이동통신 서비스에서 어쩌면 향후 1-2년의 과제가 되지 않을까 생각해본다.


-- Red Mouse