GSMA RCS Architecture Quick Review

GSMA RCS(Rich Communication Suite) 표준은 RCS r3.0까지 OMA SIMPLE IM의 Architecture를 기반으로 진행되어오다가 RCS r4.0 이후부터는 OMA CPM의 Architecture를 도입하고 있다. 하지만, OMA CPM의 Architecture 역시 결국은 OMA SIMPLE IM의 Architecture의 연장선상에 있기 때문에 RCS r4.0 이전과 이후의 차이가 크다고 볼 수는 없다. 다만, OMA CPM을 도입하고 있는 RCS r4.0 이후의 Architecture에서는 기존 OMA SIMPLE IM을 구성하는 Component에 네트웍 기반으로 대화내역을 저장하고 멀티디바이스간 동기화를 해주는 Message Storage와 SMS/MMS 및 SIP 메세지를 서로 변환해주는 Legacy Interworking Function이 추가된 형상이라고 보면 되겠다. 이 밖에 표준규격에서는 표시되어 있지 않으나, 아래 그림에서는 HTTP(S)기반의 Configuration Provisioning Server와 멀티디바이스의 Service Capability Discovery를 위한 OAS(OPTIONS AS), 그리고 GSMA IR.84기반의 Video Sharing Server를 별도로 표시하였다.

Provisioning Server
서비스에 필요한 각종 Configuration을 단말로 전송하는 노드로 OMA DM 또는 OMA CP에 해당한다. GSMA RCS에서는 기존 기술의 복잡성을 낮추기 위해, HTTP(S) 기반의 Configuration Server를 따로 정의하고 있기도 하다. Provisioning Server는 configuration provisioning을 위한 단말 연동 외에 가입자 정보를 교환하기 위해 사업자의 BSS(Business Support System)와 연동하거나, 네트웍의 가입자 정보를 관리하는 특정NE(Network Entity)와 직/간접적으로 연동할 수 있다. Provisioning Server가 Optional인 이유는 사업자가 RCS Client를 VoLTE 서비스와 묶어 제공하는 경우, provisioning server는 RCS 밖의 다른 NE로 위치할 가능성 또한 있기 때문이다.

Presence Server
OMA에서 정의한 SIMPLE Presence 1.1에 기반하며, 사용자간 service capability를 공유하거나 Social Presence Information을 공유하기 위해 사용한다. 사용자의 Social Presence Information은 portrait icon, favorite link, free text, availability, willingness등을 포함하며, RCS5로 오면서 geoloation이 포함되었다. RCS에서는 사용자의 정보를 공유하기 위해 anonymous fetch와 list subscription 기능이 사용되고 있다.

XDMS
RCS 사용자의 프로필 정보와 각종 그룹 정보를 저장/관리하는 노드로 OMA XDM 1.0과 2,0 Architecture에 기반한다. RCS Client는 IMS Core에 접속하고 Service Capability 과정이 끝나면, XDMS에 연결하여 Directory Service를 제공받는다. 이를 통해 XDMS에 저장되어 있는 사용자의 모든 xml문서를 확인하고 필요한 경우 새로 생성하거나 업데이트 한다. XDMS는 단말과 직접 XCAP으로 연동하고 Presence Server를 통해 필요한 xml 문서를 교환한다. XDMS는 내부적으로 Shared XDMS와 Presence XDMS, Aggregation Proxy로 구성되며 Cross Network Proxy를 통해 타망과 연동한다.

Messaging Server: Messaging Server는 OMA SIMPLE IM 1.0 또는 CPM 1.0의 Architecture에 기반한다. 내부적으로 PF(Participating Function)와 CF(Controlling Function)로 구성되어 있다. PF는 단말과 정합 하는 서브시스템으로 IP기반 채팅 및 파일전송, Standalone Messaging과 관련된 모든 호처리 및 미디어처리를 담당한다. CF는 conference focus 기능을 하는 서브 시스템으로 그룹 서비스 관련 모든 호처리 및 미디어 처리를 담당한다. RCS의 모든 호처리는 SIP를 사용하며 미디어 처리는 MSRP를 통해 이루어진다. 다만, RCS r5.x 이후 부터 HTTP 기반 파일 전송 기능이 추가되었다. 또한 Messaging Server는 Legacy Messaging Service 연동을 위한 Interworking decision의 역할을 수행하고 RCS 메세지를 Legacy Messaging Service로 연결하기 위해 IWF와 유기적으로 연동한다. Messaging Server를 통해 교환된 사용자의 모든 대화이력은 네트웍 상의 Message Storage에 저장된다.

Message Storage
Message Storage는 사용자가 주고받는 모든 메세지를 저장하고, 사용자가 복수 단말을 가지는 경우 해당 단말들간 대화이력을 동기화한다. 사용자는 Message Storage에 원하는 directory를 만들어 컨텐츠를 관리할 수 있다. Message Storage는 IMAPv4 인터페이스를 가지며, Message Storage를 통해 대화이력을 관리하는 모든 노드는 IMAPv4 Client로 동작한다. RCS에서는 RCS Client와 Messaging Server가 이에 해당한다.

Video Sharing Server
Video Sharing 서비스의 경우 RCSe에는 IR.74기반으로 제공되었으나, RCSr5.0이후부터는 IR.84에 기반하고 있다. GSMA IR.74에서는 Video Sharing 서비스가 음성 서비스에 의존성을 가진다. 즉, 음성 세션이 있는 경우에만 Video Sharing 서비스가 활성화되고 음성 서비스가 종료되면 Video Sharing 서비스도 함께 종료된다. 그러나, IR.84로 오면서 사용자는 음성세션의 존재와 상관없이 독립적으로 Video Sharing 서비스를 제공할 수 있게 되었다. 이러한 이유로 RCS r5.0 이후부터는 Video Sharing 서버가 독립된 노드로 추가되었다. Video Sharing 서버는 IMS 응용 서비스로 IMS Core와 ISC로 연동하며 다른 RCS 서비스와 연동이슈가 없기 때문에 RCS 밖의 3rd-party 서비스 노드로 위치할 수도 있다.

IWF
Interworking Function은 RCS 메세지와 Legacy Messaging Service(i.e., SMS, MMS) 간 연동을 담당하는 노드로 OMA CPM 1.0 Architecture에 기반하고 있다. IWF는 내부적으로 ISF(Interworking Selection Function)와 SMS-IWF, MMS-IWF 서브시스템으로 구성된다. ISF는 수신된 RCS 메세지를 메세지의 크기와 컨텐츠 타입에 따라 SMS로 맵핑할지 MMS로 맵핑할 지를 결정한다. IWF는 SMS 연동을 위해 네트웍의 SM-SC와 직접 연동하거나 또는 IMS Core에 위치한 IP-SM-GW를 연동할 수 있으나 통상 IP-SM-GW와 연동하는 경우가 많아 보인다. IWF가 사업자의 SM-SC와 연동하는 경우 SMPP를 사용하고 IP-SM-GW와 연동하는 경우 SIP를 사용한다. 또한 미디어 처리를 위해 MSRP를 사용한다. OMA CPM의 경우 Email 연동을 포함하고 있는데 RCS에서 이 부분은 제외되었다.

OAS
OPTIONS-AS는 멀티디바이스의 Capability Discovery를 수행하며 SIP OPTIONS 처리를 담당한다. RCS Client는 주기적 또는 사용자의 메세지 전송 요청에 따라 해당 contact에 대한 service capability discovery를 수행하는데, 이때 contact가 RCS 가입자가 아닌 경우 SIP OPTIONS 방식을 사용하게 된다. 이 상황에서 착신자가 멀티디바이스를 가지는 경우 OAS는 각 착신 contact에 대한 SIP OPTIONS의 forking을 수행하게 되고 이후 각 트랜젝션에 대한 응답을 통합하여 발신 사용자의 RCS Client에게 전송한다.


RCS5.x Architecture는 RCSe의 Architecture 연장선 상에 있다. 기존 RCSe 서비스를 제공하는 사업자는 RCS 5.x로 진화하기 위해 몇 개의 노드를 추가하고 기존 RCSe 노드의 기능을 업데이트 함으로써 보다 진보된 형태의 RCS 서비스를 제공할 수 있다. RCS의 기능을 구현하기 위해 기존 OMA의 기술을 채택함에 따라 불필요한 복잡성이 증가할 수 있으므로, 실제 구현하는 과정에서는 복잡한 부분을 좀 더 단순한 proprietary 기술로 대체할 수 있어야 하겠다. Presence와 XDMS간의 연동이라던가 CF와 PF의 연관관계등이 여기에 해당하는데, 이 부분들은 RCS 외부에 직접적으로 노출되는 기능이 아니기 때문에 System Integration 관점에서 어느 정도 유연한 구현이 가능할 것으로 보인다.

Red Mouse

메세징 서비스 표준 기술의 진화

지난 2011년 4월, GSMA가 조인이라는 서비스명으로 RCSe 표준을 처음 만들었을 당시, 전세계의 많은 이통사들은 이를 기존의 OTT와 대항할 수 있는 대안이 될 수 있을거라 기대했다. 그동안 많은 OTT 서비스들이 통신사가 제공하는 데이타망을 이용해 통신사들의 주 수익원이었던 메세징과 음성서비스를 무료로 제공하면서 통신사들의 주 수익원이었던 메세징과 음성서비스 가입자를 빼앗아 가고 있는 상황에서 통신사들의 입장에서는 다른 대안을 찾기가 힘들었던 것이 사실이다.

한국에서는 SKT, KT, LG+가 지난 2012년 말 처음으로 상용 서비스를 시작했고 비슷한 시기에 유럽에서는 2013년 초까지 독일과 스페인에서 Dutch Telecom, Vodafone, Orange과 같은 사업자가 서비스를 시작했다. 그로부터 1년 6개월이 지나고 있는 지금, 라인, 카카오톡, What's app과 같은 기존 OTT사업자들은 글로벌 시장에서 더더욱 그 영역을 넓혀가고 있는 반면, 사용자 증가율이 지지부진한 조인서비스의 경우, 많은 통신사들이 서비스의 제공을 주저하고 있는 상황이다. 이미 서비스를 제공하고 있는 통신사들도 서비스를 진화/발전시키기 위한 추가적인 에코서비스에 투자를 하지 않고 있는 모양새다. 

본 글에서는 OMA와 GSMA를 중심으로 이루어지고 있는 메세징 기술 표준의 진화내용을 간략하게 나마 기술하고자 한다.

메세징 서비스 표준 진화

1. IP 기반 메세징 기술의 등장과 통합 메세징 서비스로의 진화
가장 처음 RCS 기술의 토대가 되었던 SIMPLE IM은 2000년대 초/중반 OMA에서 표준화가 이루어졌다. SIMPLE IM은 순수한 IP기반의 메세징 서비스로 사용자간 1-1 및 그룹채팅 기능을 SIP기반으로 제공한다. SIMPLE IM은 이후 2005년 이후부터 CPM(Converged IP Messaging)으로 진화하는데, CPM은 SIMPLE IM이 제공하는 IP기반 그룹채팅에 SMS와 MMS, Email과 같은 기존 레가시 메세징 서비스를 통합하고 있다. CPM의 개념은 메세징 서비스의 종류에 상관없이 사용자들에게 통합된 커뮤니케이션 환경을 제공하는 데 있다.

이러한 사용자경험의 통합은 사실은 PC환경을 중심으로 먼저 시장에서 이미 받아들여지고 있었다. 그 당시 한 시대를 풍미했던 ICQ, AOL, MSN, NateOn등이 대표적인 선두주자로 기억된다. 이들 서비스들은 PC기반의 메신저에서 채팅은 물론, Presence 정보 공유, SMS/MMS 전송, 파일 전송, 대화이력 보기와 같은 서비스들을 이미 제공하고 있었다. CPM과 같은 통합메세징 기술에 대한 표준화 작업은 이러한 메신저 서비스의 시장에서의 성공을 바탕으로 이들 서비스의 개념을 표준 모바일 기술에 접목시키고자 했던 통신사들의 노력으로 읽혀진다.


2. OTT vs Operator
2000년대 후반 아이폰을 필두로 스마트폰이 시장에 본격적으로 출시되기 시작하면서 다양한 형태의 OTT서비스가 나오기 시작했다. 초기부터 메세징 서비스 시장을 선점하여 지금까지 한국의 OTT 시장을 독점하고 있는 카카오톡이나 일본에서 시작하여 지금은 전세계적으로 3억 5천만의 가입자를 보유하고 있는 NHN 재팬의 라인서비스, 북미와 유럽에서 상당한 인기를 끌고 있고 지금은 페이스북에 합병된 What's App등이 그들이다. 이들 OTT서비스의 영향으로 기존 이동통신사의 주요 수익원이었던 SMS/MMS와 같은 메세징 서비스들이 타격을 입기 시작하면서, 글로벌 이통사들은 GSMA에 모여 이동통신사 중심의 메신저 서비스 즉, RCS(Rich Communication Service)를 만들기로 결정했다. 서비스에 필요한 요구사항은 GSMA의 Rich Communication Suite 프로젝트 그룹을 통해 정의되었고, OMA SIMPLE IM은 이 요구사항을 수용하기 위한 기술적 토대가 되었다. 이후, RCS는 지속적인 업데이트를 통해 RCS r4.0까지 진화했다. (RCS r1.0에서 r4.0까지의 주요 기능에 대해서는 여기 참조)


3. 조인(Joyn )의 탄생

RCS는 r4.0까지 표준이 진화하면서 다양한 서비스 기능들이 정의되었으나, 상용서비스로 제공하기에는 그 기능이 너무 많고 복잡하였다. 그래서인지, 실제로 시장에 나오는 RCS 서비스는 없었고 그 와중에 OTT 서비스는 지속적으로 성장하고 있었다. 결국 이통사 진영은 GSMA에 모여 Time-To-Market에 맞는 RCS 서비스를 조인이라는 브랜드로 제공하기로 하고, 기존 RCS 버전 가운데 RCS r2.0 기술을 기반으로 RCSe라는 새로운 표준을 정의한다. RCSe에는 Time-to-market 을 고려하여 가장 핵심적이면서 빠르게 구현이 가능한 서비스 및 기술들이 포함되었는데 그 주요 내용은 다음과 같다.

• HTTP-basd Configuration Provisioning : 서비스에 필요한 다양한 Configuration parameter를 단말에게 전송하는 기능으로 기존 OMA-DM이나 OMA-CP 비해 무척 단순하게 구현이 가능한 게 특징이다. 아직까지는 secondary device를 고려하지 않고 있기 때문에 PS망에 접속 가능한 primary device에 대한 provisioning service만이 가능하다.

• Service Capability Discovery : 단말은 configuration provisioning 절차를 통해 획득한 configuration 값을 기반으로 IMS Core에 접속한다. Service Capability Discovery는 IMS 등록 이후, 단말이 주소록 상의 모든 contact을 대상으로 해당 contact이 RCS 사용자인지의 여부를 확인하는 과정을 의미한다. 최초 수행되는 Service Capability Discovery는 각각의 contact에 대해 SIP OPTIONS를 이용해 service capability를 교환한다. 이후 RCS 사용자로 확인된 contact들의 그룹(i.e., RCS 그룹)에 대해서는 list subscription기능을 이용하여 service capability를 확인한다. 

• IP Messaging(1-1 Chat, Group Chat) : 1-1 또는 Ad-hoc 그룹과 IP기반 대화를 할 수 있는 기능이다.

• Store and Forward : 단말이 메세지를 받을 수 없는 상태에 있는 경우 메세지를 일정시간 동안 네트웍상의 RCS 시스템에 저장한다. 이후 단말이 네트웍(i.e., IMS)에 등록되었다는 이벤트(i.e., 3rd-party registration)를 수신하면 저장되었던 메세지를 착신단말로 전송한다. 

• 1-1 File Transfer: 사용자는 주소록의 RCS사용자에게 임의의 형태의 파일을 전송할 수 있으며, 파일전송이 완료되면 세션은 자동으로 해제된다.

• Social Presence Information(Optional): RCS 사용자간 상태정보를 공유하다. 여기서의 Social Presence Information은 사용자의 favorite url, portrait icon, free text, availability를 포함한다.

• Contents Sharing: 음성 통화중에 비디오 및 이미지를 실시간으로 공유한다. Image Sharing과 Video Sharing은 각각 GSMA IR.79와 IR.74에 기반하고 있다. 현 단계에서의 Contents Sharing은 사용자간 음성통화 세션에 의존성을 가진다. 즉, 음성통화 세션이 있는 경우에만 Contents Sharing 서비스를 사용할 수 있고, 음성통화 세션이 종료되는 경우 Contents Sharing 서비스도 함께 종료된다. 

4. RCS에서 CPM 채택
GSMA RCS 표준 가운데, RCS r3까지는 OMA SIMPLE IM의 기술과 Architecture를 그대로 따르고 있으나, 이후 RCS r4 부터는 Message Storage나 Legacy Interworking Function과 같은 OMA CPM의 Architecture를 도입하고 있다. Message Storage 는 네트웍에 위치하여 사용자의 대화내역을 저장/관리해주는 노드로 사용자의 대화내역을 동기화하는 기능을 가진다. 사용자가 멀티디바이스 환경인 경우, 해당 멀티디바이스간 대화내역 동기화를 통해 사용자는 통합된 커뮤니케이션 환경을 제공받을 수 있다. Legacy Interworking Function은 RCS와 SMS/MMS 메세지를 서로 변환하는 기능을 가진다. 이로써, 사용자는 상대방이 RCS 사용자인지의 여부와 관계없이 RCS client를 이용해 누구에게나 RCS 메세지를 전송할 수 있다. 해당 RCS 메세지를 legacy messaging service로 연동할지는 네트웍에 위치한 RCS 시스템에서 결정한다.

5. RCS 5.x 로의 통합
GSMA에서는 기존의 RCS와 RCSe라는 두 개의 트랙으로 진행되던 표준을 다시금 RCS r5로 통합하고 있으며 이후 RCS는 RCS r5.1 v4.0까지 진행되고 있다. 그러므로, GSMA RCS r5.1은 지금까지 나온 모든 메세징 기술을 모두 집대성하고 있다고 볼 수 있다. 다음은 기존 RCSe 대비 RCS r5.x에 추가된 주요 기능들을 간략히 기술한다.

• Configuration provisioning over non-PS: Non-PS 네트웍(e.g., Wi-Fi)을 통해 접속하는 RCS Client에 대한 configuration provisioning을 지원한다. 사용자가 primary device를 wi-fi로 접속하거나 LTE 또는 CS망 접속 capability를 가지지 않는 secondary device(e.g., PC, Wi-Fi only Tablet)가 wi-fi로 접속하는 경우에 해당한다.

• Standalone Messaging: 기존 1-1/Group Chat이 세션 기반의 양방향 메세징 서비스라면 Standalone Messaging은 단방향 메세징 서비스이다. 전자가 기존의 메신저와 같은 사용자 경험을 주었다면, 후자는 기존의 SMS/MMS와 동일한 사용자 경험을 준다는 측면에서 Chat과 Standalone messaging은 다르다. Standalone Messaging은 메세지 크기에 따라 다시 pager mode와 large mode로 구분되는데, 1,300 byte 이하의 메세지는 pager mode(i.e., SIP MESSAGE)로, 1,300 byte 를 초과하는 메세지는 large mode(i.e., SIP INVITE)로 전송된다. Large mode message delivery가 SIP INVITE를 기반으로 미디어 세션을 생성하고 미디어의 방향이 단방향이기 때문에 구현적인 면에서 파일전송과 동일한 것 처럼 보이지만, Large mode 메세지의 경우 순수한 파일전송이라기 보다 Long text 메세지 또는 첨부파일 메세지의 형태로 전송된다는 측면에서 사용자 경험의 차이가 있다. 기존의 MMS와 파일전송에 대한 사용자 경험이 다른 것과 같은 이치다.

• Support of multimedia within the IP Chat Session: 사용자는 채팅세션에서 멀티미디어 메세지를 전송할 있다. 사업자는 채팅세션 안에서의 교환되는 멀티미디어 콘텐츠의 크기를 제한할 수 있고, 이 제약사항에 걸리는 경우 해당 콘텐츠는 파일전송을 이용하여 별도의 세션으로 전송된다. 

• Full/Basic store and forward in a Group Chat: 그룹채팅에 초대를 받고 해당 그룹에 늦게 입장을 한 경우에도 사용자는 이전에 그룹내에서 오갔던 대화내역을 모두 받아볼 수 있다(Full Store and Forward). 그룹세션에 참여하고 있는 사용자가 네트웍 연결이 끊기거나 하는 이유로 의도치 않게 그룹세션으로 부터 잠시 이탈한 이후 다시 참여하게 되는 경우, 사용자는 그동안의 모든 그룹 대화 내역을 받아볼 수 있다(Basic Store and Forward). 사용자가 그룹세션에 rejoin을 하려는 시점에 해당 그룹이 이미 존재하지 않는 경우라도 아직 해당 대화내역에 대한 유효시간이 만료되지 않은 경우 사용자 단말로 그룹의 대화내역이 store and forward된다. 다만, 사용자가 명시적으로 해당 그룹 세션을 이탈한 경우는 이에 해당하지 않는다.

• IMDN in a Group Chat: 그룹 대화방에서 메세지를 전송한 각 참여자는 몇 명이 자신이 전송한 메세지를  확인했는지를 확인할 수 있다.

• Group Session Rejoin: 그룹 대화에 참여중인 사용자는 네트웍 연결 불안 또는 밧데리 부족등과 같은 이유로 해당 그룹세션에서 의도치 않게 이탈할 수 있다. 사용자의 명시적인 이탈이 아닌 의도치 않은 이탈로 판단되는 경우 RCS 시스템은 해당 사용자가 다시 그룹 대화에 참여할 때 까지 종단점 역할을 수행하고, 해당 사용자가 그룹 대화에 참여하는 경우 그동안의 그룹 대화 내역을 사용자 단말로 전송한다. RCS Client는 이러한 의도치 않은 이탈 이후, 해당 그룹 세션에 다시 참여(rejoin)할 수 있기 위해 단말은 해당 그룹 세션의 Group Session Id를 일정시간동안 유지하고 있어야 한다.

• Group Session Restart: 그룹 세션 내부의 inactivity timer 만료로 해당 그룹 세션이 해제 되더라도 그룹의 대화쓰레드는 사용자의 단말에서 확인할 수 있으며, 사용자는 해당 그룹 대화 쓰레드안에서 메세지를 전송함으로써 해당 그룹 세션을 다시 재개할 수 있다. 

• File Transfer thumbnail preview: 파일전송 요청 시(SIP INVITE), 전송될 파일의 thumbnail을 착신측으로 전송한다. 착신자는 해당 파일의 크기와 파일타입 정보와 함께 thumbnail을 확인하고 파일전송 요청을 수락할 지의 여부를 결정할 수 있다.

• HTTP-based File Transfer: 파일을 HTTP를 이용해 전송할 수 있다. 파일전송을 위해 MSRP를 사용할 지 HTTP를 사용할지는 Operator의 정책에 따라 달라지며 사용자 경험에는 영향을 주지 않는다.

• File Transfer pause and resume : 파일전송 과정에서 어떠한 이유로든 파일전송이 완료되지 못한 경우 발신자나 착신자는 해당 파일전송을 재개할 수 있다.

• File Transfer store and forward(1-1, Group): 착신자가 파일을 수신할 수 없는 경우, 해당 파일은 네트웍의 RCS 시스템에 일정 시간동안 저장되어있다가 착신단말이 다시 네트웍에 접속하는 경우 전송된다.

• Enriched Social Presence Information : 사용자간 교환되는 Social Presence Information에 위치 정보(geoloation)가 포함된다. 사용자는 Social Presence Information을 교환할 지를 요청/수락하는 것과는 별개로 위치 정보를 공개할 지의 여부를 따로 선택할 수 있다.

• VIP contact : 사용자는 Social Presence Information을 공유하는 contact 가운데 복수 개의 VIP contact을 선택할 수 있다. VIP contact은 일반 contact과는 달리, 해당 contact의 Social Presence Information에 변경이 발생하면 해당 변경 내용이 즉시 통보된다.

• Network based Personal Black List :사용자의 blacklist를 네트웍의 RCS 시스템에서 관리한다. 메세지의 발신자 또는 착신자에 blacklist 가 포함되는 경우 해당 메세지는 필터링 된다.

• Geolocation Sharing Push/Pull : 사용자간 위치정보를 제공 또는 요청할 수 있는 기능으로, 파일전송 방법을 이용하여 위치정보를 전송한다. 위치정보를 획득하는 방법은 단말의 GPS 기능을 이용하거나 또는 통신망 사업자의 네트웍 인프라를 이용할 수 있다. 

• Contents Sharing(Image Sharing, Video Sharing) : RCSe 까지는 Contents Sharing기능이 음성세션에 의존하고 있었으나, RCS r5로 오면서 음성 서비스와 분리되었다. 즉, 사용자가 음성통화를 사용하고 있는지의 여부와 관계없이 Contents Sharing을 독립적으로 사용할 수 있음을 의미한다. 

• Voice and Video over IP: RCS Client를 탑재한 단말은 VoLTE와 ViLTE 또는 CS와 함께 RCS IP Voice/Video 기능을 지원한다.

• Network based message Storage: 사용자의 모든 대화내역을 네트웍에 저장한다. 이렇게 저장된 대화내역은 사용자의 멀티디바이스에 모두 동기화되어 사용자에게 통합된 커뮤니케이션 환경을 제공한다.

• Legacy Interworking Function: RCS 메세지와 SMS/MMS 메세지간 변환을 해주는 기능으로 RCS 사용자와 non-RCS  사용자간 메세지 교환을 가능하게 한다. 

6. SIMPLE 2.0
GSMA에서 OMA의 SIMPLE IM 1.0을 기반으로 RCS와 RCSe를 시작했지만, 이후 RCS와 RCSe는 각각의 독립된 track으로 진행되면서 RCSe는 기존 SIMPLE IM이 포함하고 있지 않은 새로운 기능들을 포함하게 되었다. OMA에서는 이러한 추가된 기능과 관련된 기술적 내용들을 추가하여 SIMPLE IM 2.0을 표준화 하고 있다. OMA SIMPLE IM 2.0에서 추가된 새로운 기능은 다음과 같다.

• Store and forward(deferred) delivery
• Display Notification

7. CPM 2.0 

GSMA에서는 RCS r4.0부터 OMA CPM의 Architecture를 도입하고 있다. RCS r4.0은 이후 RCSe 1.2.1의 기능을 수용하면서 RCS r5.x으로 업데이트 되었다. 이 과정에서 RCS r5.x는 기존 OMA CPM v1.0에서 명시되지 않은 몇 가지 기능들을 포함하게 되었다. OMA에서는 이러한 기능들을 새롭게 수용하고 기존 CPM v1.0에서 구체적으로 기술되지 않은 기능 항목들을 좀 더 보완하는 형태로 CPM v2,0을 표준화하고 있다. CPM v2.0에 추가된 주요 내용들은 다음과 같다.

• Store and Forward in a Group Session
• Support of Closed Group, Long Lived Group
• Support of live recording of chat messages
• Interworking over NNI with SIMPLE IM v2.0
• File Transfer while having ongoing CPM Session
• Store and Forward for File Transfer
• File Transfer pause and resume
• Support of Maximum File size policy
• Support of thumbnail preview in File Transfer

맺음말

조인으로 대표되는 GSMA RCS 기술이 기존에 시장에서 큰 호응을 얻고 있는 OTT서비스와 비교하여 기능적 측면에서 별다른 차별화를 하고 있지 못한 것이 사실이다. 어쩌면 CPM 2.0 또는 RCS r5.1까지 정의하고 있는 기능들은 지금까지 메세징 분야에서 생각할 수 있는 거의 '모든 기능'이 아닐까 싶기도 하다. 스마트폰의 출시와 더불어 초기 시장을 장악하면서 규모의 가입자 유치에 성공하고, 그 플랫폼을 기반으로 eCommerce, Game, SNS, MobileAds 등과 같은 에코 시스템을 자유자재로 만들어가고 있는 OTT에 비해 전세계 이통사들이 머리를 맞대고 만든 조인의 성적은 초라하기만 하다.

그러나, 최근 유럽의 몇몇 이동통신사를 중심으로 조인서비스가 탑재된 단말기가 출시되기도 하고, 조인 서비스를 제공하는 통신사의 수가 조금씩이나마 증가하고 있는 것을 보면 조인의 앞날이 아주 어두운 것만은 아닌듯도 하다. 당장에는 소위 잘 나가는 OTT서비스와의 제휴를 통해 약간의 수익을 나눌수는 있겠지만, 그것이 궁극적인 문제해결책이 아님은 이통사들도 잘 알고 있을 것 같다.


올해는 어디선가 조인의 성공스토리를 들어볼 수 있을런지 궁금하다.

Red Mouse