GSMA RCS 5.2 주요 기능 요약

지난 2012년 말 몇몇 유럽국가와 한국에서 시작한 조인(Joyn)서비스는 GSMA에서 정의한 RCS(Rich Communication Suite) 기술을 사용하고 있으며, 여러 개의 버전 가운데 가장 초기 버전인 RCSe 1.2 기반하고 있다. 이후 GSMA는 IP기반 통합 커뮤니케이션 서비스를 지향하며 지속적으로 기술규격을 진화시켜 오고 있다. RCSe가 IP Chat 이라는 가장 초기 형태의 IP 기반 서비스에 무게중심을 두고 있다면, 이후에 나온 RCS 5.x는 IP Chat을 중심으로 SMS/MMS를 통합하고, CS기반의 음성/영상 통화기능과 IP기반의 음성/영상 통화 기능을 통합하고 있다. 또한 RCS는 통합된 UX/UI를 제공함으로써, 서로 다른 형태의 서비스에 대한 사용자 경험의 융합을 꾀하고 있다. 이동 통신사들은 RCS를 통해 단기적으로는 예전부터 제공해 오던 CS기반의 음성 및 메세징 커뮤니케이션 서비스를 IP기반으로 확장하고, 나아가 그 위에 다양한 컨텐츠와 3rd-party 서비스를 수용함으로써 신규 수익을 창출할 수 있는 기반을 마련할 수 있기를 기대하고 있다.

지난 5월에 GSMA에서 발행한 RCS 5.2는 기존 RCS 5.1에서 기술되었던 내용 가운데 명확하지 않았던 부분을 좀 더 구체적으로 기술함과 동시에 몇몇 새로운 기능들이 추가되었다. 이번 포스팅에서는 RCS 5.2에서 달라진 내용들을 간략하게 추려 보고자 한다.

1. 네트웍 기반 메세지 스토리지(Network based Message Storage)

네트웍 기반 메세지 스토리지는 RCS 4.0 이후 OMA CPM의 Architecture를 채택하면서부터 제공되어오고 있는 컴포넌트로 사용자의 모든 대화 내역을 네트웍에 저장하고, 메세지 스토리지와 단말간 저장되어 있는 대화내역에 대한 동기화 기능을 제공한다. 이번 RCS 5.2에서는 대화내역 동기화 가운데서도 레가시 메세지 동기화 관련 내용이 대폭 보강되었다.

일반적인 경우라면, RCS 가입자가 아닌 일반 사용자에게 전송되는 RCS 메세지는 SMS/MMS로 변환되어 레가시 네트웍으로 연동되고 착신자로 부터 전송되는 모든 SMS/MMS는 RCS 메세지로 변환되어 시스템으로 유입된다. 이 때 대화내역이 메세지 스토리지에 저장되는 시점은 RCS 메세지가 다른 형태의 메세지로 변환되기 전이거나 다른 형태의 메세지가 RCS 메세지로 변환된 후 이므로, 저장되는 메세지데이타는 사용자 메세지(payload)와 함께 Contribution-ID, Conversation-ID, IMDN-Message-ID와 같은 SIP 헤더값들을 포함하고 있다. RCS에서는 사용자 메세지를 저장하기 위한 메세지 스토리지 내의 루트 폴더로 "RCSMessageStore"를 정해 놓고 있다. 사용자의 모든 메세지를 저장하기 위한 하위 폴더는 모두 이 루트 폴더아래에 생성되며, 사용자가 임의로 삭제/변경할 수 없도록 되어 있다. RCS 5.2에서는 특히 SMS/MMS 로 변환되었거나 또는 SMS/MMS로 부터 변환된 RCS 메세지를 저장하는 경우, 해당 메세지가 SMS인지 MMS인지에 대한 기록을 남기기 위해 message-context 파라미터를 정의하고 있다.

- message-context: "pager-message" | "multimedia-message"

그러나, 어떠한 이유에서건 RCS 서비스를 사용할 수 없는 경우 사용자는 SMS/MMS를 이용하게 되는데, 이 경우 메세지는 네트웍상의 메세지 스토리지에 저장되지 못하고 사용자의 단말에만 저장된다. 사용자 단말의 SMS/MMS 클라이언트가 이미 RCS 클라이언트에 통합되어 있음을 가정하면  해당 메세지들은 나중에 RCS의 메세지 스토리지와 동기화가 이루어져야 하는 대상이다. 단말에 저장되어 있는 SMS/MMS 메세지는 RCS 메세지가 아니므로, 메세지 스토리지와의 대화내역 동기화 시 중복성 여부를 체크(correlation check)할 수 있는 데이타 즉, Conversation-ID나 Contribution-ID와 같은 내용들을 가지고 있지 않다. 이러한 이유로, RCS 5.2에서는 각각 SMS와 MMS에 대한 중복성 체크를 위해 해당 메세지 저장 시 다음과 같은 정보를 저장하도록 하고 있다.

- message-context

- RCS-SMS-Context: SMS payload 140 byte

- Message-ID: MMS 메세지를 정의하는 ID

위의 파라미터를 이용하여, SMS/MMS의 동기화 시 SMS는 From/To 값과 함께 RCS-SMS-Context를 비교하고 MMS는 Message-ID를 비교하여 중복성 여부를 판단한다. 메세지 동기화 시 중복성 여부를 체크할 지의 여부는 SMS, MMS 에 대해 각각 provisioning configuration인 SMS MESSAGE STORE와 MMS MESSAGE STORE를 통해 결정된다. 동기화가 완료된 메세지는 저장된 폴더명과 함께 UID, UIDVALIDITY 값의 조합에 의해 유일하게 정의된다.

2. 파일 스토리지(Common File Store)

파일 스토리지는 파일 전송에 의해 전송된 파일을 저장하는 컴포넌트로 RCS 5.2에서 새롭게 도입되었다. HTTP 기반의 파일전송에서 사용되는 컨넨츠 서버(Contents Server)와 함께 파일 스토리지 역시 파일에 대한 "indirect dleivery"를 위해 사용된다. 즉, 발신자가 파일을 스토리지에 업로드 하고 그 location url을 착신자에게 전송하면, 착신자는 해당 location url을 통해 실제 파일을 다운로드 받는 방식이다. 파일 스토리지가 컨텐츠 서버와 다른 점은 파일의 Permanent 저장을 목적으로 하고 있다는 점과 저장된 파일의 단말에 대한 동기화 기능을 제공한다는 점이다. 파일 전송 메세지 전체를 저장하기 위해 파일 스토리지는 메세지 스토리지와 함께 조합을 이루어야 한다. 즉, 파일 전송을 위한 시그널 메세지는 메세지 스토리지에 저장되고 그 payload에 해당하는 파일은 파일 스토리지에 저장되는 식이다.

이 외에 RCS 5.2는 File Localization Function을 제공한다. File Localization Function은 발신 네트웍의 파일 스토리지에 저장되어 있는 파일을 파일 다운로드 요청자(i.e., 착신자)의 Home Network에 있는 파일 스토리지로 가져와 저장하는 역할을 수행한다. 이를 위해서는 발신자가 전송하는 location url을 착신 메세징 서버에서 적절하게 변경해 줄 수 있어야 한다. 착신 메세징 서버는 원래 발신자의 파일 스토리지 또는 컨텐츠 서버에 저장되어 있는 특정 파일의 위치를 가리키는 location url이 착신 네트웍의 File Localization Function을 가리키도록 변경한다. 이에 따라 File Localization Function은 착신자의 파일 다운로드 요청에 의해 트리거링 된다.

3. 음성 녹음 메세지

RCS 5.2는 음성녹음 메세지를 새롭게 정의하고 있다. 발신자는 음성을 녹음하여 착신자에게 전송할 수 있다. 녹음되는 음성파일의 최대 길이는 provisioning configuration인 MAX RRAM DURATION에 의해 제한된다. 발신자의 음성 녹음 메세지의 전송 절차는 일반적인 파일전송과 동일하다. 다만, 이 경우, 파일 전송의 경우와는 달리 해당 음성 녹음 메세지의 시간 및 날짜, 길이등이 함께 전송된다. 음성 녹음 메세지의 전송절차가 파일전송과 동일하므로, 이 기능은 파일전송이 가지는 다음의 기능들을 그대로 사용할 수 있다.

- MSRP 또는 HTTP 기반의 파일전송(i.e., DEFAULT FT MECH값에 따라 결정)

- Store and Forward

- Auto Acceptance

- IMDN notifciations

4. RCS Extensions

RCS Extension은 RCS Client 기반 위에서 자유롭게 정의될 수 있는 부가 서비스를 의미한다. RCS 5.2에서 새롭게 정의된 이 기능은 해당 규격에서 다음과 같이 정의하고 있다.

이 기능을 이용해 오퍼레이터는 자사 상황에 맞는 특정 형태의 서비스를 자유롭게 정의하여 RCS Client 위에 탑재할 수 있다. 이렇게 탑재된 RCS Extension은 RCS의 infrastructure의 모든 또는 일부 기능을 사용하여 다른 RCS client 또는 특정 RCS Extension과 통신할 수 있다. RCS 5.2는 RCS Extension을 수용하기 위한 ICSI, IARI 및 feature tag를 따로 정의한다. 또한 오퍼레이터는 RCS Extension의 사용 여부를 ALLOW RCS EXTENSION을 이용해 허용/제한(enabler/disable)하거나 EXTENSIONS MAX MSRP SIZE를 이용해 RCS Extension에 의한 MSRP의 길이를 제한할 수도 있다. RCS Extension을 허용/제한하는 방법으로는 EUCR을 이용한 System Request가 사용될 수도 있다.

5. 전송 메세지 취소 기능(Message Revocation)

RCS 5.2는 전송메세지에 대한 취소기능을 추가했다. 메세지 취소 기능은 아직 착신이 완료되지 않은 RCS 메세지를 발신 RCS 클라이언트나 발신 메세징 서버에서 취소할 수 있는 기능이다. 이는 사용자의 의지에 의해서 취소되는 기능이 아닌, 오퍼레이터의 정책에 의해서 일정 시간 후에 자동으로 취소되는 기능이다. CHAT REVOKE TIMER는 발신 클라이언트가 메세지 전송 후 delivery notification을 수신하기까지의 최대시간으로 provisioning 시 단말로 전송된다. 해당 타이머가 만료되면 발신 클라이언트는 자동으로 취소 메세지를 전송하게 되며 메세지 전송 취소가 성공적으로 완료되면 발신 클라이언트는 해당 메세지를 SMS등으로 전송할 수 있다. CHAT REVOKE TIMER 값이 0인 경우, 메세지 전송 취소 기능은 비활성화(disable)된다. 

메세지 전송 취소는 착신 메세징 서버에서만 제어할 수 있다. 메세지 전송 취소 메세지를 수신한 착신 메세징 서버는 내부적으로 해당 메세지를 삭제한다. 메세지 전송 취소는 메세지의 전송이 완료되지 않은 상황에서만 가능하므로 다음의 경우 메세지 전송 취소요청은 실패한다.

- 착신 메세지가 SMS/MMS 로 interwokring 된 경우

- 착신 메세지에 대한 delivery notification을 착신 메세징 서버에서 이미 수신한 경우

- 착신 메세지가 착신자의 메세지 스토리지에 저장이 된 경우.

마치며.

RCS 5.2에 새로 추가된 기능 가운데 RCS Extension 은 최근 통신사의 니즈를 그대로 반영하고 있다. RCS가 상용서비스로 세상에 모습을 드러낸 지 1년 6개월이 지나고 있는 지금, 사용자들에게 그렇게 많은 반향을 일으키지 못하고 있고 초기 단계부터 RCSe 버전에 기반해 서비스를 제공하던 몇몇 오퍼레이터들의 시도도 사실상 실패로 끝나고 있기 때문이다. 무엇보다도 오퍼레이터들은 조인 서비스의 수익성에 대한 고민이 깊다. 아직까지 성공적인 조인서비스의 사례를 전세계적으로 찾아볼 수 없을 뿐더러 여러 글로벌 OTT 서비스들이 이미 통신산업의 신진세력이 되어 가고 있는 지금, 많은 오퍼레이터들이 RCS의 경쟁력에 대해 신뢰를 하고 있지 못하다. 이런 가운데, RCS Extension은 오퍼레이터로서 각자의 상황에 맞는 형태의 부가서비스를 마음껏 올릴 수 있도록 하는 길을 열어주고 있다. 오퍼레이터는 RCS의 기술과 RCS infrastructure를 이용하면서 자기만의 OTT와 같은 서비스를 가질 수 있으며 동시에 globally interoperable한 통신망을 통해 시장을 키워 나갈 수 있다. 물론, 이러한 달콤한 시나리오는 해당 서비스 또는 feature가 충분히 매력적임을 전제로 하지만 말이다.

파일 스토리지는 조금 특별한 의미를 가진다. OMA CPM 표준화 당시 메세지 스토리지와 파일 스토리지를 분리하기 위한, NSN과 Acision을 중심으로 한 몇몇 회사의 강력한 시도가 있었으나 다른 참여 회사들의 반대로 결국은 유야무야 되었다. 그 파일 스토리지가 다시 GSMA RCS에서 되살아 난 셈이다. 파일스토리지의 의미는 장기적으로 사용자의 컨텐츠를 모아 공유할 수 있는 서비스를 제공할 수 있는 토대를 만드는 것에 있어 보인다. 한국의 경우 다음의 마이피플이 이와 비슷한 시도를 했던 것으로 기억한다. 이를 테면 클라이드에 각 사용자들의 컨텐츠를 모으고, 그 콘텐츠들을 서로 공유하는 형태의 부가서비스를 생각해 볼 수 있다. 이미 3rd-party 사업자들 사이에서 많이 시도되고 있는 서비스이긴 하지만, 어쨌든 파일 스토리지를 통해 조인 서비스가 클라우드 기반 컨텐츠 서비스와 연계할 수 있는 가능성을 열어 놓은 것이 아닐까 하는 생각이다.

마지막으로 RCS 5.2에서는 메세지 스토리지에서 단말에 저장되어 있는 SMS/MMS를 동기화할 수 있는 기능을 보다 구체적으로 기술하고 있다. 미루어 짐작컨데, GSMA RCS에서 서로 다른 형태의 커뮤니케이션 서비스를 통합하고자 하는 노력이 지속적으로 이루어지고 있는 것으로 보인다. GSMA는 RCS blackbird에서 Integrated UX/UI를 통해 사용자 경험의 통합을 유도했고, RCS 5.x로 오면서 OMA CPM architectur를 도입함으로써 레가시 메세징 서비스의 기술적인 통합을 이루어냈다. RCS 5.2에서는 메세지 스토리지에서 레가시 메시지 동기화 알고리즘을 구체적으로 제공함으로써, 기존 메세징 서비스와 RCS의 통합을 보다 완전하게 하고 있다. 

Red Mouse 

GSMA RCS Blackbird 주요 기능

GSMA RCS Blackbird(이하 RCS BB)는 시기적으로는 RCS 5.1 이후에 등장했으나 서비스 기능 측면에서 RCSe와 RCS 5.1의 중간 버전에 해당한다. RCSe가 단순히 IP기반 채팅에 무게를 두고 있고, RCS 5.1이 다양한 커뮤니케이션 서비스(e.g., 음성,영상,메세징)를 네트웍 기반에서 모두 융합하고 있는 서비스라면, RCS BB는 단말 UX/UI를 기반으로 해당 서비스들을 사용자 경험 측면에서 통합하고 있는 서비스라고 할 수 있다. RCS BB에서 정의하는 Converged Inbox나 Integrated Messaging과 같은 UX/UI 관련 내용들은 기존 IP Chat 기능과 Legacy Messaging Service, IP Voice Call/IP Video Call 기능을 동일한 UX/UI Context 상에서 제공함으로써 통합된 사용자 경험을 제공하기 위한 방법이다. RCS BB에서의 Voice over Wi-Fi call 이나 IP Video Call은 모두 best effort network 상에서 제공될 수 있도록 정의되고 있으나, 이후 RCS 5.x에서는 VoLTE를 통합한다. 또한, RCS BB에서는 RCSe의 IMS Core 레벨의 forking과는 구별하여 서비스 레벨의 forking을 제공함으로써 사용자의 멀티디바이스 환경 지원에 관한 기술을 구체화 하고 있다.

본 글에서는 GSMA RCS BB에서 정의하고 있는 기능들을 RCSe 및 RCS 5.1의 기능과 비교하여 정리한다. 각 항목에는 RCSe를 기준으로 RCS BB에 새롭게 추가된 기능만 기술되었다.

1. Configuration Provisioning

Provisioning over non-PS
RCS BB에는 PS를 통해서 네트웍에 접근하는 단말과 함께 Wi-Fi와 같은 non-PS를 통해 접근하는 단말에 대한 configuration provisioning을 제공한다. 단말이 Wi-Fi와 같은 non-PS를 통해 접근하는 경우는 사용자의 primary device가 기동 할 때 어떠한 이유로든 PS 접속이 원활하지 않거나 또는 사용자가 secondary device를 사용하는 경우에 해당한다. RCS configuration provisioning에서는 단말 인증방법에 대해 구체적으로 기술하지 않고 있고, 사업자에 따라 IMSI(International Mobile Subscriber ID) 기반 인증 또는 단말의 source IP기반 인증과 같은, 망 상황에 따른 다양한 방법이 사용되고 있다. 

하지만, 단말이 Wi-Fi를 통해 접근하는 경우 기존의 방법으로는 한계가 있다. 이를 테면, 단말이 네트웍 접근 단계에서 DHCP(Dynamic Host Configuration Protocol) 기반으로 private IP를 할당 받았다던지, 단말이 SIM(Subscriber Identity Module) Card가 없는 secondary device인 경우에 해당한다. Private IP는 사업자 네트웍에서 인증할 수 있는 방법이 없으므로 결국 MSISDN(Mobile Station International Directory Number)에 기반한 인증이 필요하다.

따라서, 이 경우 RCS에서는 OTP(One Time Passcode)기반의 인증을 수행할 것을 권고하고 있다. 이는 일반적인 3rd-party 어플리케이션들이 사용자를 인증하는 방법이기도 하다. OTP 기반 인증은 configuration server에서 생성한 OTP를 SMS로 단말까지 전송하고, 단말의 RCS Client의 초기화 단계에서 해당 OTP를 입력함으로써 사용자를 인증하는 방법을 의미한다.

SMS based authentication(OTP)
Configuration Server에서 생성된 OTP를 단말로 전송하는 방식으로는 일반적으로 SMS가 사용된다. 이는 대부분의 OTT 서비스들이 채택하고 있는 방식이기도 하다. OTP를 포함한 SMS를 단말로 전송하기 위해서는 사용자 단말의 MSISDN이 필요하므로, 단말 클라이언트는 어플리케이션 셋업 절차에서 UX/UI를 통해 해당 정보를 사용자에게 요구할 수 있다. RCS 표준에서는 OTP에 대한 사용자의 개입을 최소화하기 위해 OTP를 포함하는 SMS가 SMS 클라이언트가 아닌, 단말내의 RCS 클라이언트로 직접 전달될 수 있도록 MAP 포맷을 정의하고 있다. RCS 서비스는 opt-out 서비스 이므로, 원칙적으로는 단말에서 configuration provisioning 요청 시 SIM Card의 MSISDN을 읽어 HTTP GET 에 포함시킬 수 있어야 한다. 만일 MSISDN이 없다면, IMSI로 부터 MSISDN을 추출할 수 있어야 한다. User Interaction이 없이 자동으로 가입절차를 밟을 수 있기 위해서다. 그러나, 사업자에 따라, 국가에 따라 이러한 요구사항이 모두 만족되지 않을 수 있기 때문에, 결국 이 경우 사용자로부터 MSISDN을 입력받을 수 있어야 한다. 

NOTE

RCS에서는 OTP 전송을 위해 SMS외에 EUCR을 이용하는 방법도 정의하고 있으나 이 기능은 RCS 5.1부터 지원하도록 되어있다.

Network Initiated Provisioning

네트웍의 configuration server가 RCS 클라이언트로 하여금 configuration provisioning을 요청하도록 트리거링하는 기능을 의미한다. RCS에서 언급되고 있는, Network initiated provisioning이 필요한 경우는 다음과 같다.

• RCS 서비스 관련 설정이 변경된 경우
• RCS 어플리케이션의 버전이 변경된 경우
• 단말에서 비활성화 되어있던 RCS client를 활성화 시키려 하는 경우.

RCS 클라이언트를 트리거링하기 위해 RCS 시스템은 정해진 포맷의 SMS 메세지 또는 EUCR을 단말로 전송한다. Configuration provisioning을 위한 메세지(i.e., SMS 또는 EUCR)를 수신한 단말은 IMS네트웍으로부터 de-registration 후 configuration provisioning 절차를 수행한다. 

User Messages Using EUCR(End User Confirmation Request)

사업자에 따라 사용자의 RCS 서비스 가입 시 서비스 약관등에 대한 사용자의 동의가 필요하거나 서비스 관련 공지사항을 사용자에게 전송해야 하는 경우가 있다. 이 기능은 RCSe에서는 자세히 다루어지지  않고 있으나 RCS BB로 오면서 좀 더 구체적으로 기술되었다. EUCR은 RCS BB 이후 버전부터 configuration provisioning을 위한 OTP나 사용자 메세지를 전송하기 위한 방법으로 폭넓게 사용되고 있다. 사용자 메세지는 독립적인 SIP MESSAGE로 전송될 수 도 있고, 단말이 configuration provisioning 절차에서 수신하게 되는 HTTP 200 OK에 configuration parameter와 함께 body에 포함되어 전송될 수도 있다. 서비스 로직에 따라 RCS 클라이언트는 수신된 EUCR을 확인하고 해당 메세지를 단말 화면상에 팝업시켜 사용자의 입력을 받을 지 seamless하게 내부적으로 처리할 지를 판단할 수 있어야 한다. 

RCS BB Configuration management

RCS BB는 RCS 5.1에 정의된 configuration parameter를 그대로 사용한다. 다만, RCS 5.1 보다 기능 제약이 많으므로, 이와 관련된 일부 configuration parameter의 값은 상수로 설정된다. 

2. Service Capability Discovery

OPTIONS-AS for SIP OPTIONS based discovery
기존 RCSe에서의 SIP OPTIONS기반 service capability discovery 에서는 발/착신 RCS 클라이언트가 IMS Core를 통해 SIP OPTIOS를 교환하는 방식이었다. 이 방법에서는 사용자가 복수단말을 가지는 경우를 지원하지 않는다. IMS Core 기반의 forking 방식에서는 사용자의 각 단말의 service capability를 취합하는 기능이 없기 때문이다. RCS 에서는 복수단말을 가지는 사용자의 각 RCS 클라이언트의 service capability를 취합할 수 있도록 서비스 레벨의 forking 방식을 사용할 것을 권고하고 있고 이를 위한 네트웍 Component를 Options-AS라 정의하고 있다. RCS에서 정의하는 Options-AS는 발신단말이 전송한 SIP OPTIONS를 착신자의 각 단말로 forking하고, 착신자의 각 단말로부터 수신되는 각 service capability를 취합하여 발신단말로 전송한다. SIP OPTIONS를 수신한 각 단말은 단말 자체의 device capability외에 네트웍 상태나 사용자 설정정보(i.e., user preference)와 같은 요소들을 고려할 수 있어야 한다.

NOTE RCS BB에서는 service capability discovery에 대한 복수단말 지원기능을 Optional로 정의하고 있다.

Capability Exchange Optimization

RCS 클라이언트에서 Service Capability Discovery를 수행하는 시점은 다음과 같다.

- 최초 수행: 단말 기동 시 단말 주소록의 모든 contact에 대한 수행

- 주기적 수행: 주소록의 contact에 대한 polling period기반의 주기적 수행

- 실시간 수행: 사용자가 채팅/파일전송/위치정보 공유/비디오 공유등의 서비스 요청 시 수행

- New User Discovery: 주소록에 새로운 contact추가 되는 경우 RCS 클라이언트는 해당 contact이 RCS 사용자인지를 알기 위해 SIP OPTIONS based Service Discovery를 수행.

RCS에서는 SIP OPTIONS기반 service capability discovery가 유발할 수 있는 대량의 트래픽을 적절히 제어할 것을 권고하고 있다. 예를 들어, RCS BB에서는 1-1 chat에서 MESSAGING CAPABILITIES VALIDITY 파라미터를 이용해 클라이언트에서 획득한 contact의 service capability의 유효시간을 정의하고, 해당 유효시간 안에 있는 contact에 대해서는 service capability discovery를 수행하지 않는 방식을 제안한다. 예를 들어, 사용자가 임의의 contact에게 chat을 시도하고 클라이언트가 알고 있는 해당 contact의 capability가 유효시간안에 있는 경우, 해당 contact에 대한 service capability discovery는 수행되지 않는 식이다. 

그러나 RCS 규격에 언급된 방식도 특정 상황, 예를 들어, 특정 지역의 네트웍이 일시적으로 접속이 불가능했다가 다시 재개 됨에 따라 거의 동시에 다수의 단말들이 네트웍에 접속하여 service capability discovery를 수행하는 상황을 통제할 수는 없다. 따라서, 서로 다른 RCS 클라이언트간 트래픽이 겹치는 것을 최소화하고 대량의 트래픽으로 부터 네트웍을 보호하기 위한 구현관점의 적절한 알고리즘이 RCS 클라이언트와 서버에 모두 필요하다.

NOTE
RCS BB에서는 RCSe에서 Optional로 정의되었던 Presence 기능이 제외되었다. Presence 기능은 이후 RCS 5.1에서 다시 도입된다.

3. 1-1 Chat

RCS BB에서의 1-1 Chat은 RCSe와 마찬가지로 SIMPLE IM에 기반하며 멀티디바이스 관련 고려사항을 빼고는 RCSe의 방식을 그대로 따른다.멀티디바이스를 가진 착신자에게 전송된 RCS 메세지는 착신자의 각 단말에게 전송된다. 착신자가 어느 한 단말로부터 응답(200 OK)을 하는 경우 해당 착신자의 다른 단말로 전송된 SIP INVITE는 취소(SIP CANCEL)된다. 발신자가 멀티디바이스를 가진 경우, IMDN은 발신자가 RCS 메세지를 전송한 해당 단말로 전송되어야 한다. RCS에서는 RCS 메세지에 대한 forking을 RCS 시스템에서 수행하는 서비스 레벨에서 하도록 기술하고 있다. RCS 시스템은 착신자의 복수단말 가운데 1-1 Chat 기능을 제공하는 특정 단말을 구분하고 forking을 수행할 수 있어야 한다. 

4. Group Chat

Handling of involuntary leaving

RCS BB에서의 RCS 시스템은 참여자의 involuntary leaving을 감지할 수 있어야 한다. 이는 RCS 시스템이 착신자로 부터 명시적인 SIP BYE를 수신하지 않은 경우에 해당한다. RCS 시스템(PF)은 참여자의 voluntary/in-voluntary leaving을 감지함으로써 해당 참여자를 그룹 세션에서 제외할 지 또는 해당 참여자에게 store and forward 서비스를 제공할 지를 결정할 수 있어야 한다. 그룹 대화에 참여하고 있는 참여자의 involuntary leaving을 감지하는 기준은 RCS 시스템 및 IMS Core의 정책에 따른다. RCS 클라이언트가 store and forward 기능을 지원하지 않는 경우 RCS 시스템(PF)은 involuntary leaving 감지 시 해당 참여자 대신 그룹 세션내에서 SIP BYE를 전송해 해당 세션을 종료하고 해당 참여자에 대한 더 이상의 메세지를 수신하지 않는다. 그러나, RCS 클라이언트가 store and forward를 지원하는 경우 RCS 시스템(PF)은 사용자 대신 종단점의 역할을 수행할 수 있어야 한다. 

Store and forwad in a group session(basic, full)

그룹 대화에 참여하고 있는 사용자가 메세지를 수신할 수 없는 상태인 경우 해당 메세지를 임시로 RCS 시스템에 저장하고 이후 착신자가 다시 메세지를 수신할 수 있는 상태가 되면 저장된 메세지를 전송한다. 이 기능은 기존 RCSe에서 1-1 Chat에만 적용되었던 store and forward 기술을 Group chat으로 확장한 것이다. 

NOTE  RCS BB에서는 기술적 측면에서 그룹대화에서의 full/basic stored and forward 기능을 지원하지 않는 것으로 명시하고 있다. 그러나, 사용자 경험 측면에서 그룹 대화 참여자는 일시적인 네트웍 상태 불안등의 이유로 그룹 세션으로 부터 이탈했다가 다시 참여하게 된 경우(re-joining)라도 그동안 자신에게 온 메세지를 모두 받아볼 수 있도록 하고 있다. 이렇게 사용자 경험측면의 기술과 기술적 측면에서의 기술사항이 다른 것은 1-1 Chat에서의 store and forward 기능을 그대로 그룹 세션에 적용하고자 하는는 것으로 이해되지만(i.e., PF에 의한 store and forward), 본 글에서는 RCS 5.1의 그룹 대화에서의 store and forward 기능을 사실상 채택한 것이라 간주하고 본 기능을 RCS BB의 범위에 포함시켰다.

(1) Basic store and forward

그룹 대화에 참여하고 있는 참여자가 involuntary leaving으로 메세지를 수신할 수 없고 해당 사용자가 그룹 세션에서의 store and forward 기능을 지원하는 경우 RCS 시스템(PF)은 해당 참여자를 대신하여 종단점 역할을 수행한다. 이를 위해 사용자의 단말은 service capability discovery 단계에서 basic store and forward 기능 지원여부를 명시해야 한다. 착신자를 대신하여 RCS 시스템에 저장된 메세지가 얼마나 오랫동안 저장되어 있어야 하는 지는 시스템의 로컬 정책에 따른다. 이후, 착신자가 다시 서비스에 접속한 경우, 해당 그룹 세션의 종료여부와 무관하게 RCS 시스템은 저장되었던 메세지를 착신 단말로 전송한다. 

(2) Full store and forward

그룹 대화 요청에 대한 착신자의 수락이 늦어지고 해당 착신자가 full store and forward를 지원하는 경우 RCS 시스템(PF)은 해당 참여자를 대신하여 종단점 역할을 수행한다. 이는 RCS 시스템은 착신자가 늦게라도 그룹 대화에 참여할 것을 가정하여 착신단말 대신 200 OK를 보내고 대화에 참여함을 의미한다. 이후 착신자가 대화에 참여(i.e., 200 OK 수신)하면 그동안 저장되었던 메세지를 해당 단말로 전송한다. 해당 메세지를 얼마나 오랫동안 RCS 시스템에 저장하고 있을지는 시스템의 로컬 정책 또는 사업자 정책에 따른다. 만일 착신자가 명시적으로 그룹 세션 요청을 거절한 경우(603 Decline), RCS 시스템은 해당 사용자에 대한 그룹 세션내의 저장된 메세지를 모두 폐기한다.

NOTE

그룹 대화에서의 store and forward를 위한 메세지 저장 기간과 참여자에게 전송된 SIP INVITE 타이머,  involuntary leaving 감지 정책, 그룹 세션이 종료될 때까지 참여 수락을 하지 않은(무응답) 착신자에 대한 처리등은 구현 관점에서 고려되어야 한다.

Restart the group session(Long Lived Group)

그룹세션이 종료된 후, 사용자는 RCS 클라이언트에 저장되어 있는 대화내역(conversation history thread)을 통해 해당 그룹 세션을 재개할 수 있다. 이를 위해 참여자는 RCS 클라이언트의 해당 대화내역에서 새로운 메세지(e.g., 채팅, 파일전송, 위치정보 공유, 비디오 공유등)를 전송한다. RCS 시스템은 종료된 그룹 세션의 정보(e.g., conference uri, 참여자 정보, 그룹 속성 및 정책 등)를 일정기간 유지하고 있어, 참여자로부터 종료된 그룹 세션에 대한 SIP INVITE를 수신하면 해당 그룹세션을 다시 생성할 수 있어야 한다. RCS 에서는 RCS 시스템에서 종료된 그룹 세션 정보를 저장하고 있는 기간을 최소 1개월로 권고하고 있고 이 기간은 사업자가 변경할 수 있어야 한다.

NOTE 사용자가 그룹 대화 재개를 요청하는 시점이 너무 늦었거나(i.e., CF에서 해당 그룹 세션의 Session Identity를 삭제) 또는 그룹 대화를 재개할 권한을 가지지 않은 경우 RCS 시스템은 실패응답을 전송할 수 있다.  

Re-joining the group session

그룹 대화 참여자는 네트웍의 불안 또는 단말 자체의 문제와 같은 예상치 못한 이유로 본인의 의사와는 무관하게 그룹 세션으로 부터 이탈될 수 있다(involuntary leaving). 이후 해당 문제가 해결되면 참여자는 해당 그룹 세션에 다시 참여할 수 있다. 이를 위해 RCS 클라이언트는 그룹 세션의 session identity를 일정기간 저장하고 있어야 한다. 참여자의 involuntary leaving을 감지한 RCS 시스템(PF)은 해당 RCS 클라이언트가 basic store and forward 기능을 지원하는 경우 해당 클라이언트 대신 종단점의 역할을 수행하고, 이후 RCS 클라이언트가 해당 그룹 세션에 re-joining 하는 경우 저장된 메세지를 전송한다. 만일, 해당 RCS 클라이언트가 store and forward 기능을 지원하지 않는 경우 RCS 시스템에서 착신 단말 대신 SIP BYE를 전송하고 그룹대화를 종료한다. 한편, 그룹대화 참여자가 명시적으로 해당 그룹 세션을 이탈한 경우(i.e., SIP BYE 전송), 해당 참여자의 이름이 그룹 세션의 참여자 명단에서 삭제되므로 현재 참여중인 사용자로부터 별도의 초대를 받지 않는 이상 re-joining은 불가능하다.

IMDN Delivery & aggregation

기존 RCSe의 IMDN 기능이 1-1 Chat에서만 지원되고 있던 것을 확장하여, RCS BB에서는 그룹 세션에서의 delivery notification을 지원하도록 하고 있다. 만일 착신 RCS 클라이언트가 그룹 세션에서의 IMDN을 지원하지 않는 경우 RCS 시스템(PF)은 착신단말을 대신하여 delivery notification을 전송할 수 있어야 한다.

NOTE 그룹 세션에서의 displayed notification은 RCS 5.x부터 지원한다.

Multiple devices

RCS BB에서의 그룹 대화 서비스는 사용자 경험의 일관성을 위해 primary device 에서만 가능하다. 이는 사용자가 멀티디바이스 환경에서 그룹 세션에 대해 서로 다른 단말로 re-joining 또는 re-start를 수행하는 경우 사용자의 서비스 경험 일관성에 영향을 줄 수 있기 때문이다.

Group Session Policy

RCSe에서는 그룹 대화 생성자가 해당 그룹 세션을 이탈하는 경우 그룹 세션이 종료되었으나, RCS BB에서는 그룹 대화 생성자의 이탈 여부가 그룹 세션의 종료에 영향을 주지 않는다. RCS BB에서는 해당 그룹 세션에 한 명 밖에 남지 않거나 그룹 세션에서 일정 시간동안 대화가 이루어지지 않는 경우 해당 그룹 세션은 자동으로 종료된다. 이밖에 사업자는 사용자에게 다양한 형태의 그룹 세션 정책을 제공할 수 있다.

Auto Accept

RCS 클라이언트는 provisioning 받은 IM SESSION AUTO ACCEPT GROUP CHAT 파라미터를 통해 그룹 대화 요청을 자동으로 수락할 지를 설정할 수 있다. RCS BB에서는 해당 파라미터의 값을 1로 설정하여 그룹 대화 요청을 항상 수락할 수 있도록 하고 있다. 다만, 사용자가 멀티디바이스 환경에 있는 경우 RCS BB에서의 그룹 대화 자동 수락 기능은 primary device로 제한된다. Secondary device 에서 그룹 세션 자동 수락 기능은 지원되지 않는다. 

NOTE RCS BB에서는 네트웍 기반 메세지 스토리지가 제공되지 않으므로 멀티디바이스에서의 대화내역에 일관성이 보장되지 않는다. 그룹 대화 기능 및 Auto Accept 기능들이  primary device로 제한되는 것은 이 때문이다.

5. File Transfer

RCS BB에서의 파일전송 서비스는 기존 RCSe의 MSRP기반 파일전송 방식외에 HTTP 기반 파일전송 방식을 지원하고 있다. RCS BB에서의 HTTP 기반 파일 전송방식에서는 Thumbnail Preview, Pause and Resume, Group File Transfer, Store and forward와 같은 다양한 부가적 기능들을 지원하고 있다. MSRP 방식에서의 부가 기능에 대한 지원은 RCS 5.x 이후부터 정의된다.

HTTP based File Transfer

RCS BB에서는 기존 RCSe에서의 MSRP기반의 파일전송 외에 HTTP 기반의 파일전송을 지원한다. HTTP 기반 파일전송에서 발신단말은 파일 및 thumbnail을 네트웍상의 컨텐츠 서버에 저장한 후, 저장된 컨텐츠의 location url를 xml 형태로 메세지에 실어 착신측으로 전송한다. 즉, Indirect Delivery 방식이다. 발신 클라이언트는 xml을 착신측으로 전송하기 위해 Chat Invitation (e.g., SIP INVITE) 또는 Standalone Messaging 을 전송할 수 있다. 파일 전송 요청 메세지를 수신한 착신자는 해당 파일전송을 수락 또는 거부할 수 있다. 착신자가 해당 파일 전송 요청을 수락한 경우, 착신 클라이언트는 수신된 xml에 포함된 파일의 location url로 부터 해당 파일을 다운로드 한다.

NOTE RCS BB에서는 기존 RCSe에서의 MSRP 기반 파일전송을 그대로 사용할 수 있지만, 파일 전송을 위한 기본 메카니즘으로는 HTTP 방식을 채택하고 있다.

Group File Transfer(HTTP)

RCS BB에서는 그룹 타겟에 대한 파일전송을 지원한다. 그룹 타겟에 대한 파일전송은 기존 그룹 대화 세션내에서 이루어질 수도 있고, 독립적인 그룹 파일전송의 형태로 수행될 수도 있다.  RCS BB에서는 그룹 세션 내에서 멀티미디어 전송이 지원되지 않는다. 따라서, 참여자가 전송하는 멀티미디어는 파일 전송 메카니즘을 통해 전송되며, 파일 전송을 위한 별도의 세션이 생성된다. RCS 클라이언트는 서로 다른 세션을 통해 전송된 컨텐츠는 동일한 대화 내역 컨텍스트에 표현할 수 있어야 한다.

Store and forward(HTTP)

RCS BB에서는 1-1 및 그룹에 대한 파일전송의 store and forward 기능을 지원한다. 컨텐츠 서버에 저장되어 있는 파일은 저장 만료 시간 종료 후 폐기된다.

Thumbnail preview(HTTP)

착신자는 파일 전송 요청을 수락하기 전에 해당 파일의 thumbnail을 확인할 수 있다. 이를위해 발신자는 전송 파일의 thumbnail을 파일 컨텐츠와 동일하게 컨텐츠 서버에 저장하고 해당 thumbnail의 location url을 파일의 location url과 함께 전송할 수 있어야 한다. 

Pause and Resume(HTTP)

발신자가 파일을 컨텐츠 서버에 업로드하는 과정 또는 착신자가 컨텐츠 서버로부터 파일을 다운로드하는 과정에서 사용자의 요청 또는 네트웍 불안정 상태에 의해 파일전송이 중단될 수 있다. 전송이 중단된 파일 정보는 일정 기간동안 단말에서 유지되고 있으며 이후 발신자 또는 착신자가 해당 파일전송을 재개하는 경우 마지막 종료 지점부터 파일전송이 재개된다. 직전 중단된 파일 전송의 마지막 지점을 찾을 수 없는 경우 파일 전송은 처음부터 다시 수행될 수 있다. 네트웍 불안정 또는 여타의 이유로 파일 전송이 반복해서 중단될 수 있는데, 이 경우 RCS 시스템에서는 서비스 정책에 따라 최대 파일 전송 시도 횟수를 제한할 수 있다.

IMDN Delivery

MSRP 기반 파일전송의 경우 파일 전송 자체가 스트리밍 형태로 이루어지므로 종단간 파일 전송의 종료 여부 및 성공/실패 여부를 알 수 있다. 따라서, 별도의 display notification은 필요하지 않다. 그러나, HTTP 기반 파일 전송의 경우 파일 전송이 네트웍 상의 컨텐츠 서버를 통한 Indirect Delivery 방식이므로, 별도의 delivery notification과 display notification이 모두 지원되어야 한다. 착신 클라이언트는 발신자로부터 파일의 location url이 포함된 메세지를 받은 후 delivery notification을 전송한다. Display notification은 착신 클라이언트에 의해 파일 다운로드가 성공적으로 이루어진 후에 전송된다. 파일 전송이 채팅 컨텍스트 내에서 이루어지는 경우, RCS 클라이언트는 채팅 관련 IMDN과 파일전송 IMDN을 통합하어 전송할 수 있어야 한다.

Auto Acceptance

사용자는 단말에서 파일전송에 대한 자동수락 기능을 설정할 수 있다. 사용자가 파일 전송 자동 수락을 허용한 경우, RCS 클라이언트는 파일전송 요청에 대해 별도의 착신자 수락과정을 거치지 않는다. 단말에서의 파일 전송 자동 수락기능은 전송되는 파일의 크기가 configuration provisioning 에 의해 설정된 최대 파일 크기를 넘어서지 않는 경우에 한한다. 파일 전송 자동 수락기능은 멀티디바이스 환경에서는 지원되지 않는다.

Support of multiple devices

사용자가 멀티디바이스를 가지는 경우, 각 단말에서 제공하는 파일전송 기능은 모두 동일해야 한다. 즉, 사용자의 어느 한 단말이 HTTP 기반 파일전송 기능을 지원하지 않는 경우, 사용자의 다른 단말에서도 HTTP 기반 파일전송 기능은 off되어야 한다. 사용자의 primary device에서 HTTP 기반 파일전송을 지원하는 경우에만, 사용자의 secondary device에서 동일한 기능이 제공될 수 있다. 사용자의 primary device에서 RCS BB를 제공하는 경우 다른 단말에서 제공되는 legacy RCS 서비스(i.e., Joyn Hotfix)는 모두 off 되어야 한다. 네트웍의 configuration sever는 멀티디바이스를 가진 사용자의 각 단말의 RCS 클라이언트를 제어할 수 있어야 한다.

6. Geolocation

RCS 사용자는 서로 위치 정보를 교환할 수 있다. 단말의 위치 정보는 단말에 내장되어 있는 GPS 기능또는 MNO의 위치 서비스 인프라에 의해 획득될 수 있다. 그러나, 후자의 경우 GPS 기능이 없는 legacy device에 해당하는 것이므로, 스마트폰의 보급률이 높은 요즈음 고려할 필요는 없어 보인다. RCS에서 사용자간 위치정보를 교환하기 위한 방법으로 파일 전송 기술을 준용하고 있다. RCS 사용자는 자신의 위치 정보를 주소록상의 다른 RCS contact에서 전송할 수도 있고(push), 주소록의  RCS contact에게 위치 정보를 요청(pull)할 수도 있다. 획득된 상대방의 위치 정보는 RCS 클라이언트에서 제공하는 지도위에 표시(shows on the map)될 수 있다. RCS BB에서는 geolocation push 만 지원하고 geolocation pull 기능은 RCS 5.x부터 제공된다. 

사용자가 멀티디바이스 환경인 경우, geolocation push 요청은 RCS BB를 지원하는 사용자의 primary device에서만 수신될 수 있다. Geolocation Push 요청 메세지 전송 시 RCS 시스템은 착신단말의 service capability를 고려해야 한다.

RCS 사용자의 위치정보를 교환하는 방법은 geolocation push/pull 외에 social presence information의 location information을 활용하는 방법도 있으나, 이 기능은 RCS 5.x 부터 지원된다.

7. Contents Sharing

RCS BB에서의 Conents Sharging은 RCSe의 방식을 그대로 이어받는다. 다만, RCS BB에서는 RCSe와 비교하여 사용자 경험 및 UX/UI와 관련하여 보다 자세하게 가이드하고 있다.

RCS 사용자는 음성통화 상대방과 이미지 또는 비디오를 공유할 수 있다. 이미지 공유는 RCSe와 마찬가지로 GSMA IR.79에 기반하고 있으며 기술적으로는 파일전송 방식을 따른다. 비디오 공유는 음성 통화 상대방과 비디오 스트리밍을 교환하는 기능을 의미하며 기술적으로는 RCSe와 마찬가지로 GSMA IR.74에 기반한다. 비디오 공유는 종단 사용자간 양방향 스트리밍이 가능한데 이 때 각 방향으로의 비디오 스트리밍 세션은 서로 분리되어야 한다. GSMA IR.74기반 비디오 공유 서비스가 음성 통화 서비스와 동시에 이루어지므로 간섭을 피하기 위해 음성 데이타는 전송되지 않는다. 

RCS BB에서의 컨텐츠 공유서비스는 음성 통화 세션에 의존성을 가지기 때문에 멀티디바이스를 지원하지 않는다. 사용자는 음성 통화가 이루어지고 있는 단말에서만 비디오 공유 서비스를 진행할 수 있다.비디오 공유 서비스가 이루어지는 가운데, 음성 통화가 Call On Hold, Multiparty Call, Call Forwarding 로 전환되는 경우 해당 비디오 스트리밍 세션은 종료된다.

NOTE 비디오 공유 서비스 기술은 이후 GSMA IR.84에서 음성 통화 세션에 의존하지 않는 독립된 서비스로 정의된다. GSMA IR.84 방식은 이후 RCS 5.x에서 채택되고 있다.

8. Integrated Messaging

RCS BB에서는 RCS 5.x와는 달리 네트웍 기반의 Legacy Message Interworking 기능을 제공하지 않지만 UX/UI를 이용하여 사용자 경험 측면에서 통합한다. 이들을 통합하기 위해 RCS BB는 두 가지 방법을 제시하고 있다.

(1) Converged Inbox UX/UI

RCS메세지 및 SMS/MMS를 모두 RCS 클라이언트에서 관리하되 SMS/MMS thread와 RCS thread는 분리된다. 대화 내역 창의 분리된 thread 를 통해 RCS 사용자는 메세지 전송 시 SMS/MMS를 사용할 지 RCS를 사용할 지를 결정할 수 있어야 한다.

(2) Integrated Messaging UX/UI

RCS 메세지와 SMS/MMS가 모두 하나의 thread에서 관리된다. 사용자는 메세지 전송 시 RCS 메세지를 전송할 지 SMS/MMS 를 전송할 지를 분리하여 결정할 필요가 없다. RCS 클라이언트는 사용자의 메세지 전송 요청에 대해 RCS 메세지로 전송할 지 SMS/MMS로 전송할 지를 contact의 service capability를 기반으로 결정할 수 있어야 한다. RCS BB에서는 native RCS 클라이언트에 대해 Integrated Messaging 방식을 따르도록 하고 있다. 사용자가 멀티디바이스를 가지는 경우 SMS/MMS는 SIM Card가 있는  primary device에서만 발/수신이 가능하므로 RCS와 SMS/MMS를 번갈아 사용하는 경우 사용자의 secondary device에서는 사용자 대화내역의 일관성이 보장되지 않을 수 있다. 

NOTE RCS 5.x에서는 네트웍 기반의 legacy messaging interworking 기능(i.e., IWF)과 네트웍 기반 메세지 스토리지 기능이 제공되므로, 멀티디바이스 환경에서 사용자 경험의 일관성이 제공된다.

9. IP Voice Call(Voice over Wi-Fi)

RCS BB에서는 best effort network을 통한 Voice over Wi-Fi Call을 지원한다. RCS 사용자는 Wi-Fi 를 이용하여 주소록의 contact에게 음성통화를 시도할 수 있다. 착신자가 CS 또는 VoLTE 네트웍에 있는 경우 Wi-Fi Voie Call은 사업자 네트웍의 VoIP break-out 기능을 통해 착신자에게 전달될 수 있어야 한다. 반대로, 발신자가 CS 또는 VoLTE 호로 발신을 한 경우라도 RCS 사용자는 해당 호를 Wi-Fi Voice call로 수신(i.e., VoIP break-in)할 수 있어야 한다. RCS BB의 Voice over Wi-Fi Call이 best-effort network을 통해 이루어지지만, 주어진 네트웍 bandwidth 내에서 최적의 음성품질을 제공할 수 있어야 한다. 

이 밖에, RCS BB에서 제공하는 최소한의 음성 부가서비스는 다음과 같다.

• Caller ID
• Communication On Hold
• Communication Waiting

NOTE RCS BB에서는 아직 단말에서 제공하는 CS 및 VoLTE 기능이 RCS클라이언트와 통합되지 않고 있다. 

10. IP Video Call

RCS BB에서의 IP Video Call은 종단간 best effort network을 통해 이루어진다. IP Video Call은 종단 사용자가 모두 IP Video Call을 지원하는 경우에만 사용이 가능하다. IP Voice Call 과 마찬가지로 IP Video Call 도 best effort network을 통해 이루어지지만, 네트웍 bandwidth가 허용하는 범위안에서 최적화된 비디오 품질을 제공할 수 있어야 한다. RCS 사용자는 UX/UI 에서 제공되는 기능을 통해 주소록의 contact에게 직접 IP Video Call을 시도하거나 또는 IP Voice Call 에서 IP Video Call로 전환할 수도 있다. IP Video Call  사용자는 비디오 통화 중 자신의 비디오 스트리밍을 제거할 수도 있다. 

IP Video Call에서 제공가능 한 부가서비스는 IP Voice Call과 동일하다.

• Caller ID
• Communication on Hold
• Communication Waiting

마치며

GSMA의 RCS Blackbird 는 현재 v3.0까지 정의되어 있다. RCS Blackbird는 RCS 5.x 보다 서비스 측면에서 많은 제약을 가지고 있지만, 제공되는 기능에 한해서는 RCS 5.x 에서 정의된 기술을 상당부분 수용하고 있다. RCS blackbird 규격이 정의된 시점이 RCS 5.1 이후인 점과 그럼에도 불구하고 서비스 측면에서 RCSe와 RCS 5.1의 중간 버전에 해당 됨을 감안하면  GSMA 에서 활동하고 있는 사업자들 간에 time to market에 대한 고민이 많았음을 짐작해 볼 수 있다. GSMA에서 제공하는 RCS서비스에 대한 accreditation program 역시 현재로서는 RCS blackbird 까지만 제공되고 RCS 5.x에 대한 accreditation program은 아직 마련되어 있지 않다.

RCS blackbird에서는 RCS 5.x의 기능을 기술적으로 수용하고 있지는 않지만, 대신 사용자 경험 측면에서 서로 다른 서비스(i.e., IP Chat, SMS/MMS, IP Voice, IP Video)를 통합하고자 하는 노력이 엿보인다. RCS 서비스 역시 서로 다른 서비스 silo를 동일한 사용자 경험으로 통합하고자 하는 큰 흐름에 동참하고 있고, 이러한 흐름은 이미 라인이나 카카오톡, 그 이전의 PC기반의 수많은 메신저 서비스들이 주도하고 있던 흐름과 무관하지 않다.

최근 북미와 유럽의 대표적인 OTT 서비스인 What's app이 페이스북에 인수되고, 한국의 카카오톡과 다음 커뮤니케이션즈라고 하는 거대 포털이 힘을 합치고 있는 시장의 흐름을 보면서, 그리고 태생부터 이미 네이버라는 또 다른 거대 포털과는 뗼 수 없는 관계였던 4억 가입자를 보유한 라인을 보면서, 커뮤니케이션 서비스 시장의 경쟁 상황이 결코 녹록하지 않음을 확인하게 된다. 인프라 측면에서 보나, 보유 가입자 측면에서 봤을 때 조인이라는 브랜드로 대표되는 RCS 서비스가 결코 그들보다 못하지 않은 것으로 보이지만, 그럼에도 불구하고 초기 RCSe 기술기반의 조인 서비스가 실패로 끝나고 있는 점은 많은 것을 시사한다. 이런 점에서 컨텐츠의 중요성과 생태계의 중요성은 아무리 강조해도 지나치지 않을 것이다. 

그동안 네트웍 서비스 및 기술에 역량을 집중했던 통신 사업자가 이후 커뮤니케이션 서비스에서 헤게모니를 놓치지 않기 위해서는 OTT 사업자가 보여주고 있는 패러다임의 변화를 배울 필요가 있다. 여기서의 패러다임의 의미는 서비스와 사용자에 대한 사업자의 마인드셋(mindset)을 포함한다. 이와 더불어, 사용자 입장에서 봤을 때, 조인 서비스가 사용자 가운데 자리를 잡지 못한 큰 이유중의 하나는 서비스 안정성을 제공하지 못했기 때문인 것으로 풀이된다. 이미 서비스 안정화를 이룬 기존 OTT서비스에 비해, 조인 서비스는 아직 UX/UI 측면의 불완전성이 많고 메세지 전달 역시 불안정하다. 이는 조인 서비스의 근간을 이루고 있는 Access 및 IMS 네트웍, 서로 다른 사업자간 연동기능의 복잡성에도 어느 정도 원인이 있지 않을까 한다. RCS 서비스는 서비스 오류를 줄이고 SMS/MMS와 같은 수준의 안정적 서비스를 제공하는 것을 최우선 과제로 삼아야 한다. OTT서비스 사용자들도 서비스가 불안하다 싶으면 바로 SMS/MMS를 이용하는 것 처럼, 적어도 조인이 통신사들이 제공하고 있는 레가시 메세징 서비스의 안정성과 그에 대한 높은 신뢰도를 물려 받을 수 있어야 생태계든 컨텐츠든, 그 다음을 도모할 수 있는 것이다.

최근 국내 사업자들이 TTA 에 모여 다시 RCS 5.x에 대한 논의를 시작한다고 한다. 모쪼록 사용자에게 좀 더 한발자국 다가설 수 있는 RCS 서비스를 위한 논의가 되기를 기대해 본다.


Blackbird 4.0
이 글을 쓴 후 2014년 10월 RCS Blackbird PDD v4.0이 나왔다. GSMA는 Time to market을 고려해 기존 v3.0의 일부 기능을 삭제하기로 한 것으로 보인다. 그 삭제된 기능들은 다음과 같다.

- Converged Messaging
- Geoloation Push
- vCard
- Wi-Fi Voice
- RCS IP Voice Call

Wi-Fi Voice 를 뺀 것은 것은 개인적으로는 실망스러운 부분이다. 몇가지 기능을 제외함으로써 time-to-market을 만족할 수 있을지는 모르나, 어쩌면 RCS는 그나마 있던 가지고 있던 중요한 서비스 차별점 하나를 포기한 것이 아닐지. RCS가 원래 맞추었어야 하는 time-to-market은 어차피 지나버린지 오래다. 하지만, 라인, 카카오톡과 같은 메시징 시장을 지배하고 있는 대부분의 메신저는 이미 무료 Wi-Fi Voice를 제공하는 터라, RCS 사업자 입장에서는 규격과는 상관없이 이 부분을 고려하게 되지 않을까 싶다.

Red Mouse

GSMA RCS Configuration Provisioning (1): Network Architecture

RCS Configuration Provisioning 서비스는 RCS 서비스에 필요한 데이타를 단말로 전송하는 절차로, 단말은 네트웍 상의 Configuration Server를 통해 내려받은 파라미터를 이용하여 RCS  서비스에 접속한다. 단말이 내려받은 Configuration 데이타는 서비스 제어를 위한 파라미터외에 IMS 네트웍 접속을 위해 필요한 네트웍 노드의 주소값이나 인증파라미터를 포함하고 있다.

단말이 네트웍으로부터 서비스 파라미터를 내려받을 수 있기 위해 OMA에서는 DM(Device Management)이나 CP(Client Provisioning)와 같은 기술규격을 이미 표준화해 놓고 있다. 하지만 이러한 기존의 기술들은 다소 복잡하여 GSMA RCS에서는 이들 외에 좀 더 가볍고 단순한 configuration provisioning 기술을 정의하고 있는데, 그것이 HTTP(S) 기반의 configuration provisioning이다.

Configuration Server의 네트웍 구성은 configuration server를 중심으로 BSS, Backend Infrasturcture, SM-SC, RCS AS 그리고 UE로 이루어진다. 실제 규격에서는 UE 인터페이스(IF-1)와 IMS Core 인터페이스(IF-2) 그리고 SM-SC 인터페이스(IF-3)만 다루어지고 있으나, 실제 configuration server를 네트웍에 설치하게 되는 경우 그림과 같이 다양한 인터페이스를 고려해야 한다.

IF-1: Ut Inteface
Configuration Server에서 단말로 configuration data를 전송하는 인터페이스로 HTTP(S)를 사용한다. RCSe에서는 단말에서 먼저 서버로 configuration provisioning을 요청하는 절차만 정의되어 있었는데, RCS BlackBird와 RCS 5.x로 오면서 네트웍에서 단말로 notification을 전송하여 단말로 하여금 provisioning을 하도록 triggering을 하는 절차(i.e., Network Initiated Configuration)가 정의되었다. Configuration Server가 단말을 인증하는 방식에 따라 달라질 수 있겠지만, 만일 Configuration Server가 단말을 source IP 기반으로 인증을 한다면 단말과 Configuration Server 사이에 NAT와 같은 주소변환 노드는 없어야 한다. Configuration Server에서 수신되는 메세지의 source IP 주소가 바뀔 수 있기 때문이다. 이 밖에, 단말과의 연동 데이타는 TLS를 이용해 보호되어야 한다.

IF-2: IMS Interface
서비스 약관 동의와 같이 사용자 상호작용이 필요하거나 사용자에게 서비스 공지사항등을 전송하기 위해 Configuration Server는 EUCR(User Confirmation Request) 메세지를 IMS 네트웍을 통해 사용자에게 전송한다. 이 밖에, 규격에는 정의되어 있지 않으나, Configuration Server는 단말 인증을 위한 OTP(One Time Passcode)를 SMS로 전송하기 위해 IMS 네트웍의 IP-SM-GW [3GPP TS 23.204]를 이용할 수 있다. 사업자 망의 SM-SC를 직접 연동하는 대신, IP-SM-GW를 연동하는 방식은 네트웍 비용 및 상태에 따라 고려해 볼 만한 방법이다. 

IF-3: SM-SC interface
RCS 표준에서는 Configuration server가 OTP를 단말로 전송하기 위해 SM-SC를 연동하도록 하고 있으며 이를 위해 SM-SC연동을 위한 MAP 포맷을 정의하고 있다. 일반적으로, SM-SC는 사업자 네트웍에 있는 핵심 장비이기 때문에 사업자 입장에서는 3rd-party 서버가 직접 해당 장비에 접근할 수 있도록 허용 하기란 쉽지 않다.  또한, SM-SC 연동을 위한 프로토콜은 사업자마다 조금씩 다를 수 있고 같은 프로토콜이라도 사업자마다 조금씩 변형하는 경우도 있기 때문에, 실제 SM-SC연동 기능을 탑재하는 경우 별도의 정합 이슈가 발생할 수 있다.

IF-4: BSS(Business Support System)

BSS는 사업자의 가입자 청약 시스템으로, 사용자의 서비스 가입/탈퇴/회원정보 수정등의 역할을 수행하는 네트웍 노드이다. 사용자의 서비스 가입/탈퇴에 따라 해당 사용자의 정보가 BSS를 통해 생성/삭제되고 관리된다. 사용자 정보의 생성/삭제/변경이 발생하는 경우, BSS는 사업자 망의 HSS와 같은 가입자 정보 관리 노드로 해당 사용자 정보를 provisioning하며 이를 service provisioning이라 한다.

RCS Configuration Server는 단말로부터 configuration provisioning 요청을 수신했을 때 해당 단말에 대한 인증을 수행해야 하는데, 이를 위해서 RCS Configuration Server는 HSS와 마찬가지로 가입자 정보를 BSS로 부터 provisioning 받아야 한다. RCS 서비스에서 BSS에 의한 service provisioning이 발생하는 경우는 RCS Client가 embedded client인 경우에 해당한다.

IF-5: Backend Infrastructure interface

RCS Client가 downloadable client로 제공되는 경우, 즉 사용자가 앱스토어로부터 어플리케이션을 다운로드 받고 실행하는 경우, RCS Client는 configuration provisioning을 위해 Configuration Server에 접속한다. RCS Client의 접속이 최초 접속인 경우, Configuration Server는 해당 사용자에 대한 서비스 가입 절차를 수행한다. Configuration Server는 해당 사용자에 대한 가입절차의 일부로 사용자와 단말에 대한 인증을 수행 하고, 인증이 성공적으로 이루어지는 경우 사용자 정보를 사업자 망의 가입자 관리 노드로 전달하게 된다. 이때 사용자 정보가 전달되는 노드는 사업자에 따라 다를 수 있겠지만, RCS가 IMS 기반 서비스임을 고려하면 HSS가 포함될 가능성이 있다. 사업자가 가입자 정보를 관리하는 별도의 네트웍 노드를 가지고 있는 경우, Configuration Server는 해당 노드로 가입자 정보를 전달할 수 있어야 한다.

IF-6: RCS interface

본 인터페이스는 RCS 서비스를 구성하는 IM, Presence, XDMS와 같은 enabler들 간에 RCS configuration parameter를 공유하기 위한 인터페이스로, 규격에 따로 정의되어 있지는 않다. GSMA RCS 표준은 RCS Client를 제어하거나 Enriched RCS 서비스를 제공하기 위해 매우 많은 configuration 파라미터를 정의하고 있는데, 이 가운데 트래픽 제어, 컨텐츠의 길이 또는 크기, 채팅 세션 갯수 제한등과 관련된 파라미터들은 안정적인 RCS 서비스 제공을 위해 필요하며 주로 단말에 의해 일차적으로 참조되고 적용된다. 그러나, 단말 어플리케이션이 다양한 단말제조사와 어플리케이션 제작사에 의해 만들어지고 있음을 고려하면 규격을 충실히 따르지 않거나 또는 여타의 이유로 예상하지 못했던 동작을 하는 RCS Client가 있을 수 있다. 이러한 비정상 동작 단말로 부터 네트웍 상의 RCS 시스템을 보호하기 위해, RCS의 configuration 파라미터를 RCS enabler에서도 참조하고 적용하는 것이 필요하다. 


맺음말
RCS Configuration Server가 RCS 서비스를 위해 정의되긴 했지만 configuration provisioning을 통한 서비스 제공 방식은 대부분의 서비스에서 대동소이할 것으로 생각된다. 이는 RCS Configuration Server가 비단 RCS 뿐만이 아닌 여타 서비스를 위한 범용 Configuration Server로도 사용될 수 있음을 의미한다. 결국, 어떤 데이타를, 언제, 어떤 방식으로 단말로 provisioning할 것인가의 문제이기 때문에 단말의 어느 어플리케이션이든 고유한 ID로 정의될 수 있고, 해당 서비스에 대한 Provisioning 데이타 문서를 Configuration Server에서 관리할 수만 있으면 RCS Configuration Server가 범용으로 사용되는 데에 문제는 없어 보인다. 더군다나, 기존 OMA DM이나 CP에 비해 매우 단순하고 오랫동안 안정화된 HTTP에 기반하고 있으므로, 상대적으로 적은 자원으로 보다 빠르게 서비스 구축이 가능할 것으로 보인다.

Red Mouse 

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