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

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

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기반으로 진화하면서 과도기적으로 또는 항상적으로 수용해 가야 하는 특징이라고 보여진다.