Proteksi mobile content dengan OMA DRM

Kebutuhan proteksi terhadap content

Mobile content seperti musik, video, games, wallpaper, saat ini telah menjadi barang yang hampir selalu ada di setiap ponsel. Mobile content yang ada dalam ponsel biasanya didapatkan pengguna dengan cara transfer dari suatu media misalnya CD ke dalam ponsel atau dengan membeli (download) dari content provider.

Bisnis mobile content yang berkembang pesat dan mahalnya harga content mendorong adanya pembajakan. Pembajakan pada mobile content biasanya terjadi dengan cara menduplikasikan content dari satu ponsel ke ponsel lain. Untuk menghindari pembajakan maka diperlukan adanya mekanisme proteksi terhadap content.

Dengan adanya mekanisme proteksi terhadap content maka pencipta, pemilik atau penjual content akan dapat melindungi contentnya dan memperoleh keuntungan yang lebih besar. Mekanisme untuk melindungi hak pada suatu content biasa disebut manajemen hak digital atau Digital Right Management (DRM).

Mekanisme proteksi tidak hanya memproteksi content hanya dari penduplikasian content saja. Lebih dari itu dengan proteksi yang ada sekarang telah dapat membatasi pengguna (user) untuk menjalankan atau melihat content. Dengan standar proteksi OMA DRM, pemilik content dapat membatasi akses terhadap content seperti misalnya hanya dapat dilihat beberapa kali saja atau content dapat memiliki waktu kadaluarsa.

Elemen-elemen dan mekanisme DRM
Elemen yang telibat dalam mekanisme DRM diantaranya:

• DRM content adalah content atau objek media yang diproteksi atau didefinisikan haknya.
• Right object adalah suatu hak tertentu
• Right issuer adalah subjek yang mendefinisikan hak-hak subscriber pada suatu DRM content. Right issuer biasanya adalah penyedia konten (content provider) atau operator telekomunikasi (carrier)
• DRM agent adalah aplikasi di sisi pengguna misalnya ponsel yang memastikan hak-hak objek media tidak terlanggar.
  

Secara garis besar mekanisme DRM yang umum dapat digambarkan sebagai berikut:

     [Right issuer]
           |  
           |          ,----------------------.
      mendefinisikan  |                      |    ,--------------------------.
           |          | [Objek media/Konten] |    | Download server/         |    ,----------------.
           |          |                      |--->| Content Managemen System |--->| DRM Agent/User |                            
           +------------>[Hak-hak (Rights)]  |    | (CMS)                    |    `----------------'
                      |                      |    `--------------------------'
                      `----------------------'

1. Right issuer mendifinisikan hak-hak suau konten untuk kemudian diasosiasikan dengan konten dengan cara tertentu
2. Kemudian konten beserta metadata yang mendefinikan hak dari konten tersebut dipublikasikan pada sebuah download server
3. Pengguna kemudian dapat mengambil kontent dari download server. DRM agent memastikan bahwa metadata yang mendefinisikan hak dari konten juga ter-download dan membatasi hak yang bisa pengguna lakukan pada konten tersebut.
4. Setiap kali pengguna akan melakukan sesuatu pada kontent misalnya mengirimkan lewat bluetooth atau MMS, DRM agent akan mengecek pada metadata hak apakah aksi dari pengguna diperbolehkan atau tidak.
   

OMA DRM

OMA DRM adalah standar industri yang digunakan luas untuk keperluan proteksi content. OMA DRM merupakan spesifikasi untuk digital right management khususnya konten untuk perangkat bergerak (mobile content). Digital right management adalah manajemen proteksi hak pada suatu content digital sehingga pendistribusian dan penggunaannya dapat terkontrol.

OMA DRM dibuat oleh Open Mobile Alliance (OMA) yang merupakan aliansi dari beberapa perusahaan. Spesifikasi DRM, pertama kali yang dibuat OMA adalah versi 1.0 yang terdiri dari tiga dokumen spesifikasi teknis yaitu

1. Dokumen spesifikasi DRM, merupakan dokumen utama yang menjelaskan bagaimana DRM berkerja dan astitektur sistem secara keseluruhan.
2. Dokumen 'DRM Content Format' (DCF) yang berisi penjelasan format content dari suatu objek konten terenkripsi yang diproteksi oleh DRM serta metadatanya, fungsionalitas hak-hak terhadap content.
   

OMA DRM versi 1.0 mendefiniskan 3 metode

1. OMA forward-lock

Mekanisme ini adalah yang paling sederhana untuk memproteksi konten. Dengan forward-lock, konten yang telah ada di suatu perangkat tidak dapat ditransfer ke perangkat yang lain. Pendistribusian kontent dengan forward-lock ditandai dengan MIME type "application/vnd.oma.drm.message", dibawah ini contoh HTTP reponse dari download server ketika mengirimkan content dengan OMA forward-lock.

HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.message; boundary=boundary-XXX
Content-Length: 574

--boundary-XXX
Content-Type: image/jpeg
Content-Transfer-Encoding: binary

[File gambar.jpg disini]
--boundary-XXX--

2. Combined delivery

Mekanisme ini mirip dengan forward-lock, akan tetapi hak-hak akses lain dapat ditambahkan selain pelarangan tranfer ke perangkat lain. Contoh hak akses lain misalnya content hanya dapat dimainkan (play) sekali dan hanya dapat digunakan dalam waktu satu minggu. Pengiriman konten dengan mekanisme ini ditandai dengan MIME type "application/vnd.oma.drm.message". Selain konten, pengiriman ini juga mengirimkan metadata berformat teks XMLyang menspesifikasikan hak-hak pada content.


HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.message; boundary=boundary-XXX
Content-Length: 893

--boundary-XXX
Content-type: application/vnd.oma.drm.rights+xml
Content-Transfer-Encoding: binary

<o-ex:rights
xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#/">
<o-ex:context>
<o-dd:version>1.0</o-dd:version>
</o-ex:context>
<o-ex:agreement>
<o-ex:asset>
<o-ex:context>
<o-dd:uid>cid:gambar.jpg</o-dd:uid>
</o-ex:context>
</o-ex:asset>
<o-ex:permission>
<o-dd:display>
<o-ex:constraint>
<o-dd:count>3</o-dd:count>
</o-ex:constraint>
</o-dd:display>
</o-ex:permission>
</o-ex:agreement>
</o-ex:rights>

--boundary-XXX
Content-type: image/jpeg
Content-ID: <gambar.jpg>
Content-Transfer-Encoding: binary

[File gambar.jpg disini]
--boundary-XXX--


3. Separate delivery

Mekanisme ini menambahkan proteksi keamanan pada konten dengan cara mengenkripsi content. Hak-hak yang ada pada content didefinisikan pada file terpisah dan dikirim terpisah. Dengan adanya cara ini memungkinkan konten untuk diditribusikan ke peringkat lain yang tidak memiliki lisensi (right object) kemudian perangkat tersebut dapat meminta lisensi untuk dapat melihat preview atau membelinya. Mekanisme distribusi tersebut sangat menguntungkan pemilik content karena pemilik konten dapat mendistribusikan ke orang lain untuk kemudian orang lain memebeli atau mendistribusikannya lagi. Proses distribusi dari satu pengguna ke pengguna lain seperti itu disebut superdistribution.

Kontent yang dikirim dengan mekanisme separate delivery harus berupa DRM content format (DCF) yaitu konten yang dienkripsi sesuai dokumen spesifikasi DRM Content Format yang termasuk dalam spesifikasi OMA DRM. Dengan format ini, konten dapat dengan bebas ditransfer ke siapa saja lewat jalur yang tidak aman tetapi untuk menakses konten sesorang memerlukan Content Encryption Key (CEK) yang bisa didapatkan dari Right issuer. Contoh pengiriman content DCF lewat HTTP:

HTTP/1.1 200 OK
Content-type: application/vnd.oma.drm.content;
Content-Length: 1234
X-Oma-Drm-Separate-Delivery: 12

[DRM content dalam format DCF]

Pada contoh diatas, header "X-Oma-Drm-Separate-Delivery" menunjukan berapa lama (dalam detik), DRM agent harus telah mendapatkan right object yang didefinisikan dalam WAP push.

Right object yang menyertai kontent dikirim terpisah dengan menggunakan WAP-push setelah konten selesai didownload. WAP-push yang dikirim berisi right object dalam format REL (Rights Expression Language) yang juga ada dalam bundel spesifikasi OMA DRM. REL ditulis dalam bentuk XML dan dikirimkan lewat WAP-push bentuk WAP binary XML (WBXML). Contoh PAP dari WAP-push yang dikirim sebagai berikut:


<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 1.0//EN"\n "http://www.wapforum.org/DTD/pap_1.0.dtd" >
<pap>
<push-message push-id="Content123456789123456789"
source-reference="VASProviderABC"
progress-notes-requested="false">
<address address-value="WAPPUSH=62123456789/TYPE=PLMN@ppg"/>
<quality-of-service priority="low" delivery-method="notspecified"/>
</push-message>
</pap>
--multipart-boundary
Content-Type: application/vnd.oma.drm.rights+wbxml
X-Wap-Application-Id: x-wap-application:drm.ua

[Right object format REL]
--multipart-boundary--


OMA DRM versi 2

OMA DRM versi 2 juga terdiri dari 3 dokumen spesifikasi teksnis. Perbedaan utama OMA DRM 1.0 dengan OMA DRM 2.0 adalah adanya perbaikan atau penambahan pada funsionalitas dan keamanan (security). Perbaikan pada sistem keamanan dicapai dengan penyediaan mekanisme otorisasi bilateral antara pihak yang mendefinisikan hak (rights issuer) dengan perangkat.

Penambahan fungsionalitas pada versi 2 misalnya adanya fungsi preview (test-drive), mekanisme berbagi content dalam suatu komunitas atau domain, kemampuan perangkat yang tidak terkoneksi untuk dapat menkonsumsi DRM content dan kemampuan untuk memproteksi konten streaming dengan mengunakan format PDCF (Packetize DCF). Pada DRM versi 2 juga diperkenalkan Rights Object Acquisition Protocol (ROAP) yang merupakan protokol antara Rights issuer dengan DRM agent.

Spesifikasi OMA

Memahami standar, spesifikasi, aturan atau regulasi sangat penting dalam mempelajari telekomunikasi. Di sini saya akan mebahas satu persatu bagaimana proses spesifikasi atau standarisasi dibuat, terutama proses rilis (release) atau versioning dari dokumen yang dipublikasikan. Hal ini penting agar kita selalu mengacu pada versi dokumen yang benar. Mengacu pada dokumen yang berbeda versi bisa berakibat fatal.

OMA (Open Mobile Alliance) memiliki beberapa jenis dokumen yaitu:

• Requirement Document
• Technical specification/material yang berjenis
  
• Enabler Release
• Reference Release
• Test specification dan Validation Plan Document

Yang paling penting untuk dijadikan referensi adalah dokumen Enabler release.

Dokumen spesifikasi yang dikeluarkan OMA memiliki format versioning seperti standar software "x.y.z" misalnya OMA MMS versi 1.1, versi 1.2 atau versi 1.3.

Setiap dokumen OMA melewati dua fase rilis yaitu

• Phase 1 (Candidate release). Semua spesifikasi OMA yang dipublikasikan, awalnya berada pada phase ini yaitu approved dan bisa diimplementasikan pada produk atau solusi untuk dapat dilakukan interoperability test.
  
  
• Phase 2 (Approved Release) yaitu release yang telah melewati komentar publik serta validari interoperability.
  

Penjelasan ini bersumber pada halaman OMA release program, di halaman tersebut juga bisa diliat semua versi dan posisi phase untuk seriap versi dari semua set spesifikasi (Enabler).

Mobile CMS

CMS (Content Management System) identik dengan system yang digunakan untuk mengelola kontent web yang biasanya berupa halaman html (teks & gambar).

Operator telekomunikasi atau content provider saat ini biasanya memiliki apa yang disebut Mobile Content Management System, yaitu CMS untuk mengelola konten perangkat bergerak yang dijual kepada pelanggannya. Konten yang dimaksud misalnya:

- Gambar atau Wallpaper
- Nada dering (ringtone)
- Kontent teks seperti berita, ramalan, pesan bijak
- Nokia smart messaging (Operator logo, gambar, ringtone)
- Games
- Rekaman video (recorded)
- Live video/TV
- Audio/video ring back tone (Nada sambung pribadi)
- Multimedia presentation (SMIL)
- Theme

Karena banyaknya jenis konten yang disediakan maka CMS ini lebih kompleks dari CMS biasa.

Apa yang spesifik atau yang membedakan antara CMS untuk sebuah website dengan CMS untuk mobile content? Dibawah ini adalah daftar karakteristik atau fitur yang dimiliki Mobile-CMS tapi biasanya tidak terdapat pada web-CMS:

• Jenis kontennya lebih beragam
• Konten dijual, berarti memiliki harga dan melibatkan proses pembayaran (charging) sehingga memerlukan integrasi dengan billing system
• Konten tidak diperuntukan untuk semua jenis perangkat sehingga perlu manajemen perangkat agar dipastikan pelanggan yang membeli konten dapat menikmati konten yang dibelinya.
• Akses untuk mendapatkan kontent beragam misalnya melalui situs WAP/WEB, SMS, USSD, IVR, STK
• Kanal pengiriman (delivery channel) beragam bisa lewat SMS, MMS, wap push
• Karena dua poin diatas, biasanya mobile-CMS juga berfungsi sebagai content delivery system (CDS) yang berfungsi untuk mengirimkan konten lewat beragam layanan.
  
• Perlu integrasi dengan network elemen lain seperti SMSC, MMSC untuk pengiriman konten
• Karena dijual jadi kadang perlu dilengkapi dengan fitur promosi misalnya diskon, broadcast, content bundling, quiz, limited time frame free, recommended contents (top contents), pin based draw (pengundian), syembara untuk membuat dan mengirimkan kontent
• Perlu integrasi dengan streaming server untuk dapat mengirimkan konten seperti video, online TV
  
• Perlu adanya modul untuk customer care
• Reporting atua statisktik yang diperlukan yang lebih kompleks
• Perlu adanya database pelanggan termasuk didalamnya mungkin data jenis/tipe perangkat atau ponsel yang digunakan pelanggan
• Karena konten tidak gratis dan rawan pembajakan maka diperlukan proteksi (DRM) terhadap konten dari pengkopian ilegal
• Konten biasanya berasal dari beberapa content provider sehingga diperlukan mekanisme pembagian keuntungan (revenue sharing)
• Perlu deskripsi yang jelas untuk setiap konten karena pelanggan tidak dapat langung menikmati konten. Fitur preview biasanya diperlukan untuk memperjelas seperti apa konten yang bisa didapatkan oleh pembelinya.
• Adanya layanan berlangganan (Subcription) dengan pengiriman terjadwal (scheduled/automatic delivery)
  

Provisioning

Jika Anda bekerja di bidang telekomunikasi terutama yang berhubungan dengan system yang memiliki data pelanggan (subscriber) tentu akan mendengar istilah subscriber provisioning. Kalau saya lihat di kamus bahasa Inggris, provisioning berarti "the activity of supplying or providing something."

Istilah provisioning sering digunakan sebagai istilah teknis yang menunjukan proses penyediaan suatu layanan. Dalam hal subscriber provisioning, penyedian service biasanya dicapai dengan penyedian data subscriber pada sebuah system sehingga subscriber dapat menggunakan layanan yang disediakan oleh sistem tersebut. Jadi provisioning berhubungan penyediaan sesuatu sebagai persiapan agar suatu sistem atau layanan dapat digunakan.

Istilah provisioning dalam telekomunikasi, tidak hanya berkaitan dengan subscriber, tetapi bisa entitas lain misalnya service, produk, content provider, perangkat bergerak (ponsel), konten yang dapat digunakan oleh pelanggan di ponselnya dan lain-lain.

Karena banyak sekali layanan yang dapat diberikan suatu operator telekomunikasi, maka biasanya suatu layanan memiliki standar proses provisioning atau proses provisioning yang umum sehingga memudahkan operator telekomunikasi dan juga pelanggannya. Misalnya layanan GPRS, yang proses provisioningnya biasanya menggunakan OTA (Over-the-air) yaitu operator mengirimkan setting untuk GPRS ke ponsel pelanggan untuk kemudian bisa disimpan sehigga layanan GPRS bisa langsung digunakan.

Proses provisioning dapat berupa

• general provisioning yaitu membuat layanan tersedia untuk semua pelanggan oleh penyedia layanan tanpa perlu menunggu
  
• pre-arranged provisioning yaitu membuat layanan tersedia untuk seorang pelanggan (individual) jika kondisi tertentu terpenuhi misalnya layanan diminta oleh pelanggan.
  

Proses provisioning pelanggan dan service yang paling dasar di operator telekomunikasi adalah provisioning di network elements yaitu HLR dan IN. Sebelum sebuah sim card dijual dan bisa dipergunakan, data pelanggan seperti IMSI, MSIDN, dan konfigurasi layanan dasar seperti panggilan telepon (voice call), SMS, GPRS dan lain-lain perlu di-provision di kedua network elemen tersebut. Proses yang dilakukan biasanya secara masal karena nomor yang akan dijual banyak dan tidak ada data spesifik pelanggan.

Baca juga artikel tentang provisioning di Wikipedia

Convergent Billing

Istilah corvergent billing atau converged billing sering digunakan sebagai istilah dalam tekomunikasi saat ini terutama pada bidang telekomunikasi nirkabel (wireless). Istilah ini menjadi tren marketing sehingga maksud sebenarnya menjadi bias.

Convergent menurut saya dapat diterjemahkan menjadi memusat atau memfokus. Dalam bahasa inggris istilah ini dijelaskan sebagai "tending to come together from different directions." Jadi secara harfiah convergent billing bisa diartikan billing terpusat.

Entah bagaimana sejarahnya kata convergent ini jadi begitu populer tapi yang jelas kalau kita lihat sekarang, hampir semua billing system yang digunakan saat ini adalah sistem yang terpusat artinya hanya sebuah billing sistem yang digunakan untuk melayani semua layanan (service) baik itu layanan suara (voice), data,SMS, GPRS, VAS content dan lain-lain. Istilah convergent billing juga sering digunakan untuk menunjukan bahwa proses billing untuk layanan pelanggan prabayar dan pascabayar dilakukan pada satu system.

Convergent billing berarti billing yang berfokus pada customer dalam hal ini pelanggan layanan telekomunikasi dan bukan berfokus pada masing-masing layanan yang diberikan. Ini berarti setiap customer memiliki sebuah data pembayaran yang komprehensif dalam satu sistem sehingga memudahkan customer care dalam melayani pelanggannya. Biasanya convergent billing system memiliki antar muka untuk customer care yang menjadi alat utama saat melayani keluhan pelanggan dan bahkan produk billing system ini biasanya dilengkapi dengan customer relationship management (CRM).

Pendaftaran layanan (service provisioning) untuk customer akan menjadi lebih mudah dengan adanya convergent billing, yaitu dengan memiliki sebuah (single point) service provisioning pada billing system untuk semua service. Hal ini dapat dicapai dengan mendaftarkan pelanggan pada semua elemen service sehingga pada dasarnya setiap pelanggan dapat menggunakan layanan yang tersedia pada operator tetapi penggunaan layanan dikontrol secara realtime ketika data tagihan (charging record) dikirim ke billing system. Cara ini dapat dilakukan dengan asumsi bahwa convergent billing system adalah biling system modern yang menangani customer prabayar dan customer pascabayar dengan cara yang sama yaitu realtime charging. Single point service provisioning juga baik dilakukan jika aspek negatif diabaikan seperti pembebanan jaringan dan begitu besarnya lisensi dari produk suatu service element karena harus menyimpan semua data pelanggan sejak awal.

Keuntungan lain dengan adanya convergent billing adalah fleksibilitas pendefinisian mekanisme pembayaran. Operator dapat dengan fleksibel melakukan kalkulasi harga pada setiap layanan atau kalkulasi yang melibatkan beberapa layanan. Hal ini penting bagi operator untuk dapat bersaing dengan melukan promosi atau diskon pada layanan yang diberikannya.

Secara teknis pemusatan pada satu sistem billing berarti integrasi antara beberapa elemen layanan (service element) menuju sebuah elemen yang berujung pada sistem billing. Karena service element seperti MSC, SGSN/GGSN, SMSC, MMSC dan lain-lain memiliki format rekaman tagihan dan juga protokol tersendiri untuk mengirimkannya ke billing system maka convergent billing system harus mampu beradaptasi terhadap semua perbedaan tersebut. Jika fitur adaptasi tidak dimiliki billing system, maka paling tidak adaptasi harus dilakukan pada elemen lain di depan billing system.

Biasaya billing system tidak memiliki antar muka untuk dapat melayani semua elemen dan operator tidak mau mengeluarkan effort yang banyak dengan membuat lapisan adaptasi pada setiap elemen. Oleh karena itu, dalam arsitektur convergent billing biasanya ada elemen lain yang disebut mediation device atau charging gateway yang berfungsi untuk mengadaptasi baik data tagihan maupun protokol antara service element dengan billing system. Arsitektur dan aliran data tagihan digambarkan dibawah ini

                          ,-------------.          ,----------------.
 service element -------->|             |          |                |
                   +----->|  Mediation  |=========>| Billing system |
 service element --' +--->|             |          |                |
                     |    `-------------'          `----------------'
 service element ----'      

• 
  Beberapa produsen produk convergent billing system yang digunakan oleh operator di Indonesia diantaranya adalah:
  
  Amdocs dipakai Excelcomindo
• Convergys, produknya bernama IRB atau Geneva dipakai Telkomsel, Indosat, HCPT Indonesia
• Comverse, dipakai NTS, mobile8
• Redknee, dipakai Bakrie Telecom

Regulasi telekomunikasi

Teknologi tidak terlepas dari bisnis dan bisnis tidak terlepas dari regulasi. Pada teknologi telekomunikasi regulasi dapat meliputi beberapa aspek misalnya standarisasi teknis, pengalokasian spektrum frekuensi dan lain-lain.

Di Indonesia regulasi telekomunikasi diurus oleh sebuah badan bernama BRTI (Badan Regulasi Telekomunikasi Indonesia). Badan ini dibentuk pemerintah jadi pada intinya regulasi telekomukasi Indonesia masih diatur oleh pemerintah oleh karena itu regulasi di Indonesia bukan hanya menjadi masalah bisnis dan teknis tapi bisa menyangkut politis.

Badan yang berperan pada regulasi telekomunikasi:

• Departemen Komunikasi dan Informatika (DEPKOMIMFO)
• Direktorat Jendral Pos dan Telekomunikasi (DIRJEN POSTEL) - web DIRJEN POSTEL di DEPKOMINFO
  
• Badan Regulasi Telekomunikasi Indonesia (BRTI)

Dokumen-dokumen yang berkaitan dengan regulasi telekomunikasi seperti peraturan pemerintah (PP), keputusan menteri, dan lain-lain dapat dilihat di website tersebut.

Proses Penerimaan MMS

Dibawah ini saya jelaskan bagaimana proses suatu MMS diterima pada sebuah ponsel dari jaringan operator.

MMSC sebagai elemen yang menerima MMS dari subscriber akan mengirimkan notifikasi (MMS notification) kepada ponsel tujuan. Notifikasi MMS yang memberitahukan ponsel bahwa subscriber mendapat kiriman MMS diterima ponsel dalam bentuk WAP-push yang dikirim lewat SMS bearer. WAP-push indikator tersebut memiliki header content type yang berisi "application/vnd.wap.mms-message" dan header X-Wap-Application-Id yang berisi "x-wap-application:mms.ua". Dari header tersebut ponsel tau bahwa WAP push tersebut adalah MMS notification indicator dan harus diproses oleh MMS agent. MMS agent kemudian memproses notification tersebut yaitu meresponse untuk memberitahu MMSC bahwa notification indicator telah diterima kemudian melakukan request (WSP/HTPP GET) ke MMSC untuk mendownload content dari MMS.

Sebuah MMS notification indicator membawa informasi diantaranya:

• Nomor versi MMS
• Alamat pengirim MMS
• Subject dari MMS
• Deliveri report status yang menunjukan pengirim membutuhkan staus delivery report atau tidak
• MMS message class, yang menunjukan prioritas pengiriman
• Ukuran MMS
• Waktu kadaluarsa (expiry) dari MMS
• Lokasi MMS content yaitu alamat untuk mengambil isi dari MMS
  

Informasi tersebut dispesifikasikan pada dokumen spesifikasi OMA yang berjudul "Multimedia Messaging Service Encapsulation Protocol" dan juga spesifikasi 3GPP TS 23.140 (Multimedia Messaging Service (MMS); Functional description) pada bagian yang membahas tentang MM1 interface. MM1 interface adalah interface yang menhubungkan antara MMSC dengan ponsel.

Dalam spesifikasi OMA, notifikasi MMS disebut M-Notification.ind dan serponsenya disebut M-NotifyResp.ind. Sedangkan pada MM1 interface, notifikasi MMS disebut MM1_notification.REQ dan responnya disebut MM1_notification.RES

Sebuah ponsel biasanya memiliki setting untuk penerimaan MMS yaitu

- Cara penerimaan yang menentukan apakah MMS client/agent akan otomatis mengambil MMS content setelah mendapat MMS notifikasi
- APN (Access Point Name) yang merupakan setting GPRS bearer agar MMS content dapat dikirim dari ponsel ke MMSC atau diambil dari MMSC

Pada kasus pengambilan MMS langsung (otomatis) proses pengambilan digambarkan sbb:

ponsel                                     MMS Proxy-Relay (MMSC)
------                                     ----------------------
  |                                                 |
  |<-- M-Notification.ind / MM1_notification.REQ ---| 
  |                                                 |
  |--- M-NotifyResp.ind / MM1_notification.RES ---->|
  |                                                 |
  |----- MM1_retrieve.REQ (WAP/HTTP GET) ---------->|
  |                                                 |
  |<---- MM1_retrieve.RES / M-retrieve.conf --------|
  |                                                 |
  |-- M-NotifyResp.ind / MM1_acknowledgement.REQ -->|
  |                                                 |
  |                                                 |
  |                                                 |

Mengenal IN (Intelligent Network)

IN adalah istilah yang biasa digunakan dalam dunia telekomunikasi untuk mendeskripsikan suatu fungsionalitas dalam jaringan telekomunikasi yang bersifat intelligent.
Intelligent disini dapat berarti terkontrol walaupun tidak bersifat 'pintar' seperti istilah intelligent control yang digunakan di dunia kontrol industri.

Arsitektur IN pada jaringan sentral (core network) telekomunikasi memisahkan antara fungsi switching dan pengaturan logic. Dalam jaringan sentral GSM atau CDMA, IN biasanya diasosiasikan dengan sebuah elemen yang mengatur jalannya end user service seperti call control, SMS, GPRS, USSD dan lain-lain. Elemen tersebut biasanya adalah sebuah mesin (server) yang berdiri sendiri yang dihubungkan dengan MSC (Mobile Switching Center). Operator menggunakan elemen IN untuk mendefinisikan setiap logika pengontrolan dari sebuah service.

Sebelum MSC memproses sebuah service digunakan oleh user, misalnya layanan pemanggilan (call), MSC akan menghubungi elemen IN untuk menayakan bagaimana service itu akan ditangani. Elemen IN kemudian akan menganilis service berdasarkan logic yang telah didefinisikan, kemudian memberikan hasil eksekusi logic tersebut ke MSC. Contoh hasil eksekusi misalnya "lanjutkan pemanggilan" atau "putuskan pemanggilan" (reject call) atau "lanjutkan pemanggilan dan beritahu IN untuk keputusan berikutnya setiap satu menit".

Dengan adanya IN maka service yang diberikan oleh operator menjadi beragam karena adanya fasilitas analisa untuk pengambilan keputusan pada jalannya suatu service.
IN juga membuat operator mudah untuk mengubah suatu logic service. Hal ini sangat berguna bagi operator untuk melakukan suatu promosi.

Contoh promosi yang bisa diimplementasikan pada IN adalah close user group (CUG) untuk pemanggilan yaitu fasilitas yang mengatur logic untuk sebuah kelompok nomor. Promosi ini biasa disebut "friend and family" dimana anda dapat mendefinisikan beberapa nomor-nomor teman atau keluarga anda sehingga setiap anda melakukan panggilan pada nomor tersebut anda mendapatkan potongan harga. Beberapa fasilitas seperti CUG, call forwarding dan lain-lain telah distandarisasi atau didefinisikan dalam suatu arsitektur network misalnya dalam standar GSM yaitu CAMEL (Customized Application for Mobile network Enhanched Logic) atau dalam standar CDMAOne/CDMA200/IS yaitu WIN (Wireless Intelligent Network) atau standar ITU yaitu CS (Capability Set).

Karena fungsinya sebagai pengontrol, maka elemen IN biasa disebut Service Control Point (SCP) dan fungsinya biasa disebut Service Control Function (SCF).
Selain SCF beberapa fungsi lainnya diantaranya adalah:

• Service Data Function (SDF)
  SDF menyimpan data Subscriber dan network yang diperlukan oleh SCF pada eksekusi service.
• Service Resource Function (SRF)
  SRF menyediakan specialized resources yang dibutuhkan ketika eksekusi service pada SCF misalnya penerima digit, yang melakukan play announcement, dan lain-lain.
• Service Management Function (SMF)
  SMF memberikan fungsi provision, deployment dan support
  
• Service Management Access Function (SMAC)
  SMAC merupakan fungsi interface bagi user untuk mengakses SMF
• Service Creation Environtment Function (SCEF)
  SCEF memberikan fungsionalitas untuk mendefiniskan, menbuat (develop) dan melakukan test suatu service.

Sejarah IN

Sebelum adanya konsep IN, sebuah telecommunication switching (exchange) melakukan semua proses yang diperlukan dalam memberikan layanan terhadap pengguna telekomunikasi. Fungsi call-processing, service data dan service logic terdapat pada switch sehingga sering disebut monolithic platform.

Konsep IN pertama kali diperkenalkan oleh Telcordia (atau Bellcore) yaitu advanced intelligent networks (AIN) pada tahun 1980. Pada awalnya Bellcore membuat konsep AIN untuk mempermudah pengelolaan dan deployment dari suatu service baru di sebuah oprerator cabang yang berada di daerah dengan cara membuat suatu elemen pengontrol (service control logic) yang terpusat. Telcordia mengawali IN dengan versi pertamanya yaitu IN/1 kemudian dalam beberapa tahun merilis seri spesifikasi yaitu AIN 0, AIN 0.1, AIN 0.2

Spesifikasi AIN 0.1:

• TR-NWT-001284, Advanced Intelligent Network (AIN) 0.1 Switching Systems Generic Requirements
• TR-NWT-001285, Advanced Intelligent Network (AIN) 0.1 Switch-Service Control Point (SCP Application Protocol Interface Generic Requirements)

Spesifikasi AIN 0.2:

• GR-1298-CORE, AINGR: Switching Systems
• GR-1299-CORE, AINGR: Switch-service Control Point (SCP)/Adjunct

Sekitar tahun 1990, setelah Telcordia mempublikasikan AIN 0.1, Organisasi internasional ITU kemudian membuat standar IN dengan yang berbasis pada AIN. Pada tahun 1993, akhirnya ITU mempublikasikan standard IN pada dokumen seri ITU Q.1200 dan sampai saat ini standar tersebut menjadi dasar hampir semua teknologi IN sekarang.

Standard IN yang dispesifikasikan ITU selalu diperbarui terus menerus sehingga dibuatlah versi yang menunjukan sebuah rilis yaitu yang disebut capability set (CS). Setiap CS mendefinisikan sebuah himpunan fitur-fitur dimana sebuah service baru dapat dibuat.

Sejak pertama kali standar IN dibuat, ITU telah merilis beberapa capability set yaitu

• Tahun 1992, capability set yang pertama CS-1
• Tahun 1995, CS-1 direvisi menjadi CS-1 R atau CS-1+
• Tahun 1997, dirilis CS-2
• Tahun 1999, dirilis CS-3
• Tahun 2001, dirilis CS-4

Standard untuk masing-masing CS tersebut adalah

• Q.12x0 Structure of IN CS-x
• Q.12x1 Introduction to IN CS-x
• Q.12x2 IN Service Plane Architecture for CS-x (not for CS-1)
• Q.12x3 IN Global Functional Plane Architecture for CS-x
• Q.12x4 IN Distributed Functional Plane Architecture for CS-x
• Q.12x5 IN Physical Plane Architecture for CS-x
• Q.12x8 IN Interface Recommendations for CS-x
• Q.12x9 IN User Guide for CS-x

dengan x menunjukan angka rilis CS yaitu 1,2,3,4 dan seterusnya.

Model Konsep IN

Dalam jaringan telekomunikasi yang berbasis CCS, switching sering disebut sebagai SSP (Service Control Point) dan elemen IN disebut SCP (Service Control Point). Hubungan SSP dan SCP dapat digambarkan sebagai berikut:

                          -------query------->
                      SSP                      SCP
                          <----response------- 

Fungsi utama SCP adalah sebagai Service Control Function (SCF). Selain SCF beberapa fungsi lainnya diantaranya adalah:

• Service Data Function (SDF)
  SDF menyimpan data Subscriber dan network yang diperlukan oleh SCF pada eksekusi service.
• Service Resource Function (SRF)
  SRF menyediakan specialized resources yang dibutuhkan ketika eksekusi service pada SCF misalnya penerima digit, yang melakukan play announcement, dan lain-lain.
• Service Management Function
  SMF memberikan fungsi provision, deployment dan support
• Service Management Access Function (SMAC)
  SMAC merupakan fungsi interface bagi user untuk mengakses SMF
• Service Creation Environtment Function (SCEF)
  SCEF memberikan fungsionalitas untuk mendefiniskan, menbuat (develop) dan melakukan test suatu service.

Fungsi-fungsi diatas didefinisikan pada IN Conceptual Model (INCM) yang didefinisikan pada standar ITU (CCITT Recommendation Q.1201). INCM merupakan suatu basis untuk standarisasi dan petunjuk (guidelines) desain untuk arsitektur sebuah IN. INCM menjelaskan konsep IN dalam 4 bidang (planes) yaitu:

• Service plane
• Global functional plane
• Distributed functional plane
• Physical plane

INCM dijelaskan pada standar-standar berikut:

• Q.1200 General Series IN Recommendations Structure
• Q.1201 Principles of the IN Architecture
• Q.1202 IN Service Plane Architecture
• Q.1203 IN Global Functional Plane Architecture
• Q.1204 IN Distributed Functional Plane Architecture
• Q.1205 IN Physical Plane Architecture
• Q.1208 General Aspects of the IN Application Protocol
• Q.1290 Glossary of Terms Used in the Definition of IN

Realisasi IN

Karena jaringan telokomunikasi dari mulai adanya IN hingga saat ini berbasis CCS atau SS7 maka realisasi IN pada jaringan telekomunikasi juga menggunakan protokol SS7. Telcordia mespesifikasikan IN/1 dan AIN sebagai protokol antara SSP dan SCP, sedangkan ITU dan ETSi membuat protokol INAP.

Gambar dibawah ini menunjukan posisi protokol IN tersebut dalam stack SS7

| INAP | IN/1 | AIN |
+-------------------+
|        TCAP       |
+-------------------+
|        SCCP       |
+-------------------+
|    MTP Layer 3    |
+-------------------+
|    MTP Layer 2    |
+-------------------+
|    MTP Layer 1    |
+-------------------+

INAP yang dispesifikasikan oleh ETSI menggunakan standar ITU TCAP, sedangkan AIN menggunakan ANSI TCAP.

ETSI INAP

Dengan adanya standar IN dalam arsitektur maupun protokol maka diharapkan implementasi IN dalam jaringan telekomunikasi yang terdiri dari berbagai elemen dari manufaktur yang berbeda menjadi lebih mudah. Kenyataannya hal itu tidak terjadi, banyak bagian dari spesifikasi yang diinterpretasikan berbeda karena tidak mendetailnya spesifikasi yang dibuat ITU-T. Oleh sebab itu, ETSI membuat standar INAP yang berbasis dari ITU-T INAP.

Untuk dapat diimplementasikan di mobile network yaitu GSM, ETSI membuat spesifikasi yang memperluas ETSI INAP yaitu CAMEL. Relasi rilis INAP dan CAMEL diperlihatkan pada gambar dibawah

ITU-T CS-1  --->  ITU-T CS-2  ---> ITU-T CS-3 ---> ITU-T CS-4
     :              :                :
     :              :                :
CORE INAP 1 --->  CORE INAP 2 --->  CORE INAP 3
    \ \______________  \_____________   \____________       
     \               \               \               \
      \               \               \               \
      CAMEL 1  --->  CAMEL 2  --->  CAMEL 3  --->   CAMEL 4