전 세계의 다양한 이동 통신사업자와 글로벌 단말 제조업체 및 솔루션 업체들이 참여하고 있는 국제 표준화 단체인 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 규격을 정리한다.

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

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

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 사용자인지를 확인하는 절차을 동반한다는 측면에서 일반등록과 구분된다.

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

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

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

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

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)가 변경되지 않는 이상 반복되지 않는다.

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를 결정할 수 있는 몇 가지 경우의 수를 나열한다.

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

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

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

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

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

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

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를 통해 전송된다. 다음은 이에 대한 흐름도를 도시한다.

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 관점에서 원래 세션에 참여했던 참여자는 세션의 확장과 관계없이 동일한 대화창을 사용할 수 있어야 한다.

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 사용자가 아닌 경우 참여할 수 없다.

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

착신 단말이 메세지를 수신할 수 없는 경우 해당 메세지는 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없이 자동으로 이 메세지를 수락할 수 있어야 한다.

사용자의 복수단말 처리를 위해 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를 하나로 취합하여 전송하는 기능이 요구된다.

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

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

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

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

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

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

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 서비스가 동작하기 위한 조건은 다음과 같다.

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

여기서는 지금까지 본문에서 다뤄진 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 형태로 제공된다고 하니 내년 이맘때쯤 통신시장이 향후 어떻게 전개되어 있을지 궁금해진다.