Rich Communication Suite (RCS)

Ketika melihat terminologi Rich Communication Suite (RCS) di sebuah halaman website tetang spesifikasi produk IMS saya sudah bisa menebak apa maksud dari RCS. Dalam pikiran saya saat pertama membaca istilah RCS adalah komunikasi multimedia. Ya, tertanya memang tidak jauh dari itu pengertiannya.

Istilah RCS sendiri sebenarnya diawali dari sebuah initiative atau konsorsium dari beberapa provider komunikasi dan vendor produk telekomunikasi pada Februari 2008. Press rilisnya bisa dilihat disini. Tujuan konsorsium tersebut adalah membuat fitur-fitur atau layanan komunikasi yang lebih kaya (rich communication) yang dapat saling beroperasi antar provider (interoperability) dengan berbasis pada standar yang ada. Selain itu juga bertujuan untuk memberikan petunjuk (guideline) untuk implementasi dan melakukan test layanan tersebut.

Awalnya fitur utama RCS didefinisikan sbb:

• Enhanced Phonebook, with service capabilities and presence enhanced contacts information
• Enhanced Messaging, which enables a large variety of messaging options including chat and messaging history
  
• Enriched Call, which enables multimedia content sharing during a voice call

Pada bulan September 2008 kemudian GSMA mengambil alih initiative tersebut dengan lebih banyak superter. Kemudian GSMA membuat dokumen spesifikasi RCS. Informasi tentang RCS dari GSMA dapat dilihat di halaman introduction, bisa dilihat di halaman tersebut, fitur lain dari RCS adalah

• Broadband access client and support for a multi-device environment so user access to services and applications will be possible from both mobile and fixed terminals (PCs)

Berdasarkan dokumen RCS release 3, group fitur RCS adalah:

• Social presence information enhancements
  
• Enhanced messaging
  
• Network value added services (NVAS)
  
• Content sharing enhancement
• Broadband access (BA) enhancement

Dalam menspesifikasikan RCS, GSMA mengadopsi spesifikasi dari organisasi lain yang sudah ada seperti dari 3rd 3GPP, Open Mobile Alliance (OMA), Telecommunication Technology Committee RCS group (TTC RCSS).

Jadi intinya layanan RCS bukanlah sebuah layanan baru, tapi layanan yang sebenarnya sudah ada dan biasa kita gunakan lewat Internet. Seperti halnya kita saat ini menggunakan Yahoo! Messanger dimana kita bisa berkomunikasi dengan chat/teks, voice, video call dan juta saling bertukar gambar atau file. Layanan seperti itu diadopsi dalam komunikasi bergerak dimana jaringan telekomunikasi sudah menyatu dengan jaringan Internet dengan adanya IMS dengan mengedepankan interoperability dengan standar teknis yang terbuka.

RCS pada dasarnya akan dapat berjalan juga pada jaringan 3G dengan menggunakan jaringan CS dan PS, tapi tentu saja untuk beberapa layanan seperti video atau image share mungkin tidak dapat dilakukan.

Berikut gambaran arsitektur RCS yang disederhanakan yang memperlihatkan hubungan antara dua provider RCS.

Gambar diambil dari dokumen spesifikasi RCS R3 Technical Realization
[Klik gambar untuk memperbesar]

Keterangan gambar:

• CS/PS GW adalah gateway yang digunakan untuk menjembatani antara CS voice dengan PS Voice (MMTel).
• IPX = IP Packet Exchange
• VS AS = Video Sharing Application Server
• IMS = IP Multimedia Subsystem
• XDMS = XML Data Management Server
• DM = Data Management
• DS = Data Synchronization
• IM = Instant Messaging Server
• Presence = Presence Server

Bisa kita lihat RCS tidak terlalu special tapi menjadi special karena istilah tersebut sebuah istilah 'jualan' (marketing) sehingga menjadi populer. Yang menjadi penting adalah interoperability atau interworking sehingga layanan dapat berjalan dari berbagai jaringan akses (2G, 3G, LTE, Broadband) dan dengan menggunakan berbagai perangkat.

Telecom Service Broker

Tulisan dari LightReading berjudul "Telecom Service Broker" ini menarik untuk dibaca. Dalam artikel itu kita akan tau apa, bagaimana dan siapa yang membuat produk "telecom service broker."

Konsep telecom service broker memang sama dengan service broker yang ada di dunia IT atau Service Oriented Architecture (SOA) saat ini. Tapi perlu diingat kata pertama dalam judul itu (Telecom) membuat konteksnya agak lain.

Istilah service broker di area provider telekomunikasi ini mulai menjadi berita ketika beberapa produsen produk ini membentuk Service Broker Forum bulan Maret 2009 oleh Aepona, AppTrigger, Convergin, jNetX dan OpenCloud.

Pada dasarnya elemen telecom service broker dibuat untuk memberikan kemampuan pada operator telekomunikasi untuk melakukan konektifitas antar aplikasi, interaksi antar layanan, network orchestration dengan menggunakan standar 3GPP.

Telecom service broker juga mengadupsi konsep elemen Service Capability Interaction Manager (SCIM) dalam jaringan IMS. Perlu diketahui awalnya SCIM adalah konsep yang belum didefinisikan dengan jelas tapi sudah dituliskan pada standar IMS di 3GGP R7. Studi tentang service broker oleh 3GPP bisa dilihat di TR 23.810 Study on Architecture Impacts of Service Brokering yang merupakan bagian dari 3GPP R8.

Pada website Service Borker Forum, dijelaskan paling tidak fungsi utama dari service broker adalah

• SCIM
• IM-SSF
• IN-IN Trigger Management
• Protocol/Call Flow Management
• Subscriber Data Management Interaction

Gambar berikut memperlihatkan posisi service broker seperti definisi yang dijerlaskan Service Broker Forum:

"A network element that efficiently manages service interaction and service composition and resides between the service layer and the converging network and is traditionally decoupled from the core switch and the service execution or service creation environment"

Gambar diambil dari Service Broker Webinar slide presentation

Seperti ditulis di artikel LightReading, :

"service-broker functionality has long existed in mobile networks, but that many operators were not translating this need into a defined product category"

Jadi konsep telecom service broker sejak lama dan sudah mulai diimplementasikan seiring dengan berkembangnya Parlay-X, IMS/SCIM, SDP, Next Generation IN, Telco 2.0, OneAPI dan API-API lain yang mengekspos jaringan/layanan operator telekomunikasi ke "dunia luar" (IT world/3rd parties/Internet). Dan saya pede untuk mengatakan kalo ini sebenarnya adalah strategi marketing vendor-vendor telekomunikasi yang punya produk tersebut untuk dapat menjual (atau istilah sopannya mengedukasi para customer dalam hal ini operator telekomunikasi).

Saya tidak yakin kalo operator-operator di Indonesia dalam waktu dekat akan migrasi ke MIS atau SIP dari tradisional signaling (SS7), jadi yang relevan buat operator-operator di Indonesia adalah telecom service broker yang mengekspos legacy system (seperti MSC, legacy IN, SMSC, HLR, dll) ke "dunia luar". Di beberapa operator juga banyak lebih memilih untuk mulai menggunakan SIGTRAN (SS7 over IP) dibanging migrasi menggunakan SIP.

Jadi dalam kasus telecom service broker ini yang akan jadi preferred choice di Indonesia adalah yang bisa mengekspos legacy system.

OSS/J

OSS/J awalnya merupakan grup perusahaan-perusahaan yang berusaha membuat implementasi dari OSS/BSS dengan menggunakan Java sebagai teknologinya dan arsiteturnya mengacu pada NGOSS (Next Generation Operations Support System).

OSS/J dibentuk tahun 2003 dengan menggunakan Java Community Process (JCP) untuk membuat standar API yang dispesifikasikan pada dokumen JSR (Java Specification Request). Tahun 2006, OSS/J mulai bergabung dengan organisasi TMForum dan tahun 2008 mulai masuk dalam satu payung dalam TMForum Interface Program.

OSS/J API ini dibuat dengan beberapa teknologi untuk integrasi yang disebut integration profiles, yaitu Java RMI/IIOP, XML/JMS, dan Web Services.

Integration Profiles

[Gambar diambil dari dokumen OSSJ Design Guidelines]

Core API dari OOS/J ini didesain sesuai Core Business Entities (CBE) yang diadopsi dari Shared Information Data (SID) model yang dibuat oleh TMForum.

Awalnya API yang dibuat adalah sebagai berikut:

1. Common API v1.0
2. Inventory v1.0
3. Trouble Ticket v1.0

Kemudian berkembang menjadi beberapa API sebagai berikut:

1. Common API (JSR 144)
2. Service Activation v1.1(JSR 89)
3. Quality of Service v1.0 (JSR 90)
4. Trouble Ticket (JSR 91)
5. IP Billing (JSR 130)
6. Inventory API (JSR 142)

Hingga saat ini beberapa perubahan terlah terjadi yaitu

- Service Activation API diganti menjadi Order Management API.

- Billing Mediation atau IP Billing API dan Quality of Service API sudah tidak dikelola lagi.

- Bagian dari QoS API yaitu fault management dibuat terpisah menjadi Fault Management API.

Saat ini OSS/J API dikembangkan dengan prinsip SOA (Service Oriented Architecture) dengan spesifikasi sebagai berikut:

1. Common API v1.5 (JSR 144)
2. Order Management v1.0 (JSR 246)
3. Trouble Ticket v1.2 (JSR 91)
4. Inventory v1.2 (JSR 142)
5. Fault Management v1.0 (JSR 263)
6. Discovery v1.0 (JSR 254)

Dokumen spesifikasi tersebut bisa di-download disini (website TMForum) atau disini (website JSR).

TMForum juga mengembangan implementasi OSS/J yang gratis dan open source dan memberikan list beberapa produk yang sudah mengimplementasikan standar OSS/J.

VoLTE: VOLGA vs OneVoice Initiative

Agak telat berita ini saya tulis disini, tapi masih cukup segar, belum lama ini GSMA merilis berita bahwa mereka mengadopsi One Voice sebagai teknologi Voice over LTE (VoLTE).

Seperti pada tulisan sebelumnya, cukup mengherankan kenapa ada inisiatif One Voice ini, padahal sudah ada VoLGA dan juga IMS. Tapi cukup jelas bagaimana posisi VoLGA terhadap One Voice ini seperti yang dilansir oleh VoLGA Forum bahwa operator telekomunikasi berhak menentukan bagaimana evolusi jaringannya dan

"VoLGA is an excellent solution for voice and SMS over LTE for operators who decide to take an interim approach prior to IMS-based voice and messaging services"

Dan saya percaya untuk kondisi Indonesia, VoLGA masih lebih cocok sebagai jalur yang perlu ditempuh --untuk menuju LTE-- oleh para operator telekomunikasi kita yang masih menggunakan jaringan berbasis circuit switch dan enggan untuk berevolusi ke IMS.

TOGAF 9

Belum lama ini, 4 Februari 2010 telah dirilis TOGAF versi 9.

TOGAF merupakan singkatan The Open Group Architecture Framework yaitu framework maupun metodologi untuk arsitektur IT atau sering disebut Enterprise Architecture (EA). Bisa dikatakan TOGAF merupakan acuan (guide) untuk merancang atau membangun sebuah EA.

Dokumen TOGAF versi 9 bisa diunduh dari website The Open Group setelah melakukan registrasi.

Lagi lagi API untuk Telekomunikasi: OneAPI

Seperti sudah dijelaskan sebelumnya, usaha untuk membuat API atau interface yang membuka layanan dari operator atau provider telekomunikasi telah dilakukan beberapa organisasi, salah satunya adalah OneAPI yang diusing oleh GSM Assosiation, sebuah organisasi atau asosiasi internasional yang beranggotakan operator/provider telekomunikasi GSM dan vendor telekomunikasi.

Awalnya proyek OneAPI ini dinamai 3rd party access, yang dari namanya sudah jelas tujuannya adalah membuat API untuk memberikan akses kepada pihak ketiga ke layanan atau network yang dimiliki operator telekomunikasi.

Saya tidak akan membahas terlalu jauh tentang OneAPI karena API ini belum lama muncul, belum mature dan informasi atau dokumentasinya pun masih sangat minim.

Proyek pilot secara komersialnya baru dilakukan bulan lalu (Februari 2010), sedangkan spesifikasi dan dokumentasinya baru akan dirilis bulan Maret 2010. Saat ini API ini baru menspesifikasikan fungsi-fungsi untuk Messaging (SMS and MMS), Location, Payments dengan tekonologi Web Service dan RESTful. Spesifikasi OneAPI ini kemungkinan akan dikeluarkan oleh OMA.

Rencananya, OneAPI versi 2 akan memasukan fungsi-fungsi berikut:

• Data Connection profile
• QoS Quality of Service
• Remaining Credits Look-Up
• SMS triggering via UDH
• In-app billing

Lebih lanjut tentang OneAPI ini bisa dilihat di portal atau di library.

OneAPI: The first standard telecom RESTful API?

Saya sendiri bertanya-tanya mengapa dibuat standar baru dengan teknologi REST? Yang jelas REST ini lebih sederhana dibanding SOAP dan juga mudah karena menggunakan protokol HTTP.

Dan yang pasti beberapa vendor memang sudah mulai menggunakan REST sebagai interface untuk solusi SDP. Coba anda baca artikel "Who Makes What: RESTful Service Delivery Platforms". Bisa jadi RESTful API akan semakin banyak digunakan menggantikan SOAP seiring dengan makin populernya konsep Telco 2.0.

JAIN API

JAIN adalah komunitas di JCP (Java Community Process) yang berinisiatif membuat standar API untuk keperluan pembuatan layanan (service) teleponi baik itu layanan yang berbasis suara maupun data.

Nama awal JAIN adalah Java APIs for Intelligent Network karena tujuan awalnya JAIN adalah membuat API untuk layanan Intelligent Network (IN), tetapi kemudian berkembang cakupannya menjadi API untuk semua service di jaringan telekomunikasi sehingga namanya diubah menjadi Java APIs for Integrated Networks.

Dibuatnya API untuk mengekspos layanan teleponi ini dilatarbelakangi oleh trend konvergensi dunia telekomunikasi dan dunia IT/Internet (layanan data). Dunia telekomunikasi selama ini dilandasi oleh protokol yang berbeda dengan yang digunakan di dunia IT yaitu protokol TCP/IP tapi serkarang mulai berkembang pemakaikan protokol TCP/IP di jaringan telekomunikasi. Untuk dapat memberikan layanan-layanan baru yang mudah dan cepat dibuat perlu suatu interface atau API.

Selain JAIN, inisiatif untuk membuat interface atau API juga dilakukan organisasi atau komunitas lain misalnya OSA/ParlayX yang dibuat Parlay Group, OneAPI [link portal] yang dibuat oleh GSM Association & Aepona.

Berikut adalah beberapa spesifikasi yang sudah dibuat oleh JAIN yang bisa juga dilihat disini atau disini:

1. Java Application Interfaces for Communications:

- JAIN SIP 1.1

- SIP API for J2ME 1.0

- JAIN MGCP 1.0

- JAIN MEGACO

- JAIN Session Description Protocol (SDP)

- JAIN ENUM [lihat RFC2916]

- JAIN TCAP 1.1

- JAIN INAP 1.0

- JAIN Java Call Ccontrol (JCC) 1.1

- JAIN Java Coordination and Transaction (JCAT)

- Java Payment API (JPay)

- JAIN Presence

- JAIN Instant Messaging

- JAIN SIMPLE Instant Messaging

- JAIN SIMPLE Presence

- JAIN SIP Lite

- JAIN Service Creation Environment (SCE) SCML

- JAIN Service Creation Environment (SCE)

- Java - Server API for Mobile Services (SAMS): Messaging

2. Java Application Containers for Communications:

- JAIN Service Logic Execution Environment (JSLEE)

- SIP Servlets 1.0

Cukup banyak spesifikasi interface yang sudah dibuat oleh JAIN. Tapi perkembangan market penggunaan JAIN API maupun API sejenis di operator telekomunikasi saat ini saya kira masih rendah.

Operator telekomunikasi tidak perlu lagi WAP Gateway?

Produk-produk WAP Gateway atau WEB proxy yang digunakan operator telekomunikasi biasanya memiliki fitur penting yaitu

• kompresi, sehingga trafik ke internet menjadi semakin efektif (kecil)
• adaptasi kontent atau tampilan, yang membuat tampilan di mobile device menjadi sesuai dengan kapabilitasmobile device tersebut atau aplikasi web/wap browser-nya.

Tapi dengan adanya beberapa perusahaan yang memberikan layanan gratis untuk fungsi tersebut, fitur tersebut menjadi tidak penting buat sebuah WAP Gateway atau WEB Proxy.

Sebagai contoh misalnya Google, perusahaan ini memberikan layanan adaptasi tampilan. Coba saja search pada google dari browser handphone anda dan klik hasil pencariannya, Google akan menubah tampilannya, jika halamannya panjang maka halaman akan dipotong dalam beberapa halaman.

Contoh lain yang mirip adalah Opera Mini yang memiliki strategi bisnis yang bagus yaitu bekerja sama dengan operator untuk memberikan layanan browsing yang lebih efisien dan murah tapi mereka (Opera) juga dapat untung.

Gambar dari Opera.com

Dengan menggunakan aplikasi browser Opera Mini, aktifitas browsing tidak lagi langsung mengakses web server yang dituju, tetapi akses koneksi akan dilewatkan ke Opera Mini Server yang bertugas untuk melakukan optimasi seperti kompresi dan adaptasi konten. Jadi Opera Mini Server berfungsi sebagai proxy atau gateway default untuk aplikasi browser Opera Mini.

Mekanisme tersebut membuat akses internet menjadi optimal dan efisien baik dari sisi pengguna (pelanggan) maupun dari sisi operator telekomunikasi. Oleh sebab itu bisnis ini bisa dilirik oleh operator.

Berikut link yang menjelaskan pemaparan teknologi Opera Mini.