2014년 3월 22일 토요일

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

댓글 없음:

댓글 쓰기