Thursday, October 04, 2007

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 -->|
| |
| |
| |

Monday, October 01, 2007

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

Friday, September 28, 2007

WAP push

-== WAP push ==-

Mungkin kita pernah tiba-tiba mendapatkan pesan singkat seperti SMS berisi link (URL) dan dengan atau tanpa pesan pada ponsel. Pesan itu menunggu konfirmasi dari Anda untuk menerima (accept) atau menolak (cancel), kemudian ketika kita memilih untuk menerima, munculah halaman dengan informasi yang lebih banyak berupa halaman WAP atua mungkin secara otomatis mendownload content.

Kedua jenis kejadian tersebut bisa terjadi dengan adanya WAP push. Push berarti kita disodori oleh informasi tanpa harus meminta informasi tersebut. Disebut WAP push karena informasinya kemudian dapat diakses dengan WAP (Wireless Access Protocol).

WAP push banyak digunakan oleh operator atau content provider untuk mengirimkan content-nya ke subscriber. Hal ini dikarenakan pesan wap push yang dapat berinteraksi langung dengan browser di ponsel sehingga memudahkan pengguna untuk mendownload content untuk kemudian disimpan atau diinstal di ponsel.

WAP push pat digunakan misalnya untuk:

  • Informasi untuk pengiriman mobile content seperti ringtone, gambar atau wallpaper, screensaver, java games, dll
  • Informasi alert misalnya berita harga saham, skor suatu pertandingan bola, dll.
  • Wireless email yaitu alert ketika ada email baru dan memberikan link ke email baru tersebut
  • Notifaksi MMS

Wap push juga dapat digunakan oleh operator telepon selular untuk mengetahui jenis ponsel yang digunakan oleh subscriber-nya.

Jenis wap push yang paling banyak digunakan adalah wap push seperti yang telah dijelaskan diatas yatitu Service Indication (SI).


WAP push merupakan bagian dari spesifikasi WAP 1.2 yang dibuat oleh sebuah organisasi bernama WAP Forum yang sekarang bergabung dalam OMA. Dibawah ini tabel nama dokumen yang menspesifikasikan WAP push

  • Push Architectural Overview - WAP-250-PushArchOverview-20010703-a
  • Push OTA Protocol Specification - WAP-235-PushOTA-20010425-a
  • Push OTA Protocol SIN - WAP-235_100-PushOTA-20011008-a
  • Push OTA Protocol SIN - WAP-235_101-PushOTA-20020612-a
  • Push Access Protocol Specification - WAP-247-PAP-20010429-a
  • Push Access Protocol SIN - WAP-247_100-PAP-20011010-a
  • Push Proxy Gateway Service Specification - WAP-249-PPGService-20010713-a
  • Push Proxy Gateway Service SIN - WAP-249_102-PPGService-20011009-a
  • Push Message Specification - WAP-251-PushMessage-20010322-a
  • WAP Service Indication Specification - WAP-167-ServiceInd-20010731-a
  • WAP Service Indication SIN - WAP-167_103-ServiceInd-20010926-a
  • WAP Service Loading Specification - WAP-168-ServiceLoad-20010731-a
  • WAP Service Loading SIN - WAP-168_103-ServiceLoad-20010816-a
  • WAP Cache Operation Specification - WAP-175-CacheOp-20010731-a
  • WAP Cache Operation SIN - WAP-175_102-CacheOp-20010816-a

Dokumen-dokumen tersebut dapat didownload di sini.


-== Arsitektur dari WAP Push ==-

Elemen-elemen dari arsitektur WAP push adalah

  • PI (Push Initiator) biasanya adalah aplikasi tertentu yang membuat isi (content) dari WAP push yang akan dikirimkan melalui PPG.
  • PPG (Push Proxy Gateway) berfungsi menerima message dari PI untuk kemudian dikirimkan ke mobile station (MS) lewat SMSC, MSC atau SGSN.

Arsitektur yang umum dapat digambarkan sebagai berikut:

ponsel <--- MSC/SGSN <--- SMSC <--- PPG <--- PI

Gambar arsitektur diatas dapat disederhanakan seperti yang digambarkan pada dokumen spesifikasi WP push yaitu

ponsel <--- PPG <--- PI

Untuk berkomunikasi dengan PPG digunakan protokol Push Access Protocol (PAP) yang berbasis protokol HTTP, tetapi ini bukan satu-satunya cara. Beberapa vendor biasanya menyatukan fungsi PPG dengan produk SMSC atau WAP gateway. Cara lain pengiriman WAP push adalah menggunakan protokol SMPP langsung ke SMSC. Pengiriman wap push dari PPG ke ponsel sebenarnya dapat menggunakan SMS, USSD, circuit switch atau packet switch (GPRS) dan disebut push over-the-air (OTA) ptotocol.

-== Jenis-jenis WAP push ==-

WAP push dapat digunakan untuk mengirimkan segala macam tipe content atau MIME media type, tetapi ada 3 jenis push content yang standar, yaitu
  1. SI (Service Indication), pesan singkat muncul pada selpon dan mengunggu konfirmasi user untuk men-download content. Data yang dikirim dari PI melalui PAP akan terdiri dari link dan pesan.
  2. SL (Sevice Loading). content secara otomatis langsung di-download tanpa interaksi dengan user. content. Data yang dikirim dari PI melalui PAP hanya terdiri dari link ke content.
  3. CO (Cache Operation), perintah untuk menghapus (invalidate) objek content yang ada di WAP client cache.
-== Push Access Protocol (PAP) ==-

PAP adalah standar yang digunakan untuk komunikasi PI dengan PPG. PAP didesain menggunakan XML dan dikirimkan menggunakan protokol HTTP. PAP 1.0 mendukung beberapa operasi yaitu:

  • Push Submission ( PI -> PPG ).
    Untuk mengirimkan wap push (content) misalnya SI, SL atau CO.
  • Result Notification ( PPG -> PI )
    Notifikasi yang dikirim PPG jika ada perubahan status pada wap push yang telah dikirimkan PI.
  • Push Cancellation ( PI -> PPG)
    Untuk membatalkan wap push yang dikirimkan PI. Pembatalan ini dapat dilakukan bila wap push belum dikirim ke ponsel oleh PPG.
  • Push Replacement ( PI -> PPG)
    Untuk membatalkan wap push yang dikirimkan PI. Pembatalan ini dapat dilakukan bila wap push belum dikirim ke ponsel oleh PPG.
  • Status Query (PI -> PPG)
    Untuk mengetahui status wap push yang telah dikirimkan PI.
  • Clients Capabilities Query (PI -> PPG)
    Untuk mengirimkan wap push yang nerupakan perintah kepada ponsel untuk mengirimkan informasi kapabilitas ponsel.

Sebuah pengiriman SI atau SL dalam HTTP direpresentasikan dalam sebuah multipart document, oleh karena itu content-type HTTP harus menggunakan multipart/related.

Teks yang dikirimkan dari PI ke PPG terdiri dari tiga entitas:

  1. Control entity yang bersifat mandatory (harus ada), merupakan bagian yang berisi identifikasi ponsel target dan intruksi pengiriman
  2. Content entity merupakan isi yang akan ditampilkan pada MS
  3. Optional capabilities entity

Contoh WAP push SI yang dikirim PI menggunakan PAP:

POST /PAPService.do HTTP/1.1
Host: localhost
Content-Type: multipart/related; boundary=asdlfkjiurwghasf; type="application/xml"

--asdlfkjiurwghasf
Content-Type: application/xml



<pap>
<push-message id="123456@telcoloyo.com">
</push-message></pap><address value="WAPPUSH=+6281000000001/TYPE=PLMN@ppg.telcoloyo.com">



--asdlfkjiurwghasf
Content-Type: text/vnd.wap.si



<si>
<indication id="123@siid.emailku.co.id" href="http://www.emailku.co.id/wml/pap/message.wml">
You've got new Mail!
</indication>
</si>
--asdlfkjiurwghasf
Content-Type: application/xml

<!-- Bagian ketiga: (optional) berisi Client Capabilities -->
--asdlfkjiurwghasf--

Contoh wap push result notification

<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 1.0//EN" "http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap product-name="Nokia Push Proxy Gateway">
<resultnotification-message
push-id="zoo1091175019881:0"
message-state="delivered"
code="1000"
desc="Push Successful"
sender-address="123.123.123.123"
sender-name="a" received-time="2004-07-30T08:06:46Z"
event-time="2004-07-30T08:06:46Z">
<address address-value="WAPPUSH=+3584544101930/TYPE=PLMN@null"/>
<quality-of-service delivery-method="unconfirmed"/>
</resultnotification-message>
</pap>



-== Pengiriman ke telepon selular ==-

PPG mengirimkan content menggunakan Push Over-the-air (Push OTA), dengan transport protokolnya adalah HTTP/WSP.

Pada kasus wap push SL dimana subscriber mendapatkan content langsung tanpa aksi dari subscriber, maka WAP session
antara ponsel dengan operator network harus terjadi dahulu sebelum content bisa dikirimkan.

Jika tidak ada koneksi (WAP session) antara MS dan PPG, maka dikirimkan Session Initiation Request (SIR) (misalnya menggunakan SMS).
SIR dienkapsulasi pada WDP package, untuk kemudian dikirim lewat SMSC. Setelah adanya koneksi barulah content dikirim oleh PPG.

Thursday, September 27, 2007

WAP push lewat SMPP

Awalnya saya bingung dimana saya bisa dapat spesifikasi yang menjelaskan bagaimana WAP push bisa dikirim lewat SMPP (SMS PDU) seperti yang biasa dilakukan oleh Content Provider (CP) untuk mengimkan WAP push ke ponsel lewat operator. Sebelum saya tau spesifikasinya, saya mengerti bagaimana harus mengkontruksi SMS PDU agar menjadi WAP push. Pada dasarnya beberapa parameter datagram header pada SMS PDU perlu diset yaitu:

ESM class diset 0x04 (SM_UDH_GSM)
Data coding diset 0x0F5

Sedangkan body message diisi dengan binary XML dari WAP push Service Indication (SI).

Setelah beberapa lama mencari, barulah saya tau bahwa semua proses tersebut dijelaskan dalam spesifikasi WAP dari WAP forum.
Ternyata semuanya ada di "WAP 2.0 conformance release" yang juga menspesifikasikan WAP push.

WAP 2.0 conformance release memiliki banyak dokumen spesifikasi yang membuat saya malas membacanya. Waktu memperlajari WAP push saya hanya membaca bagian Push functional area, ternyata WAP push terkait dengan functional area lain yaitu spesifikasi-spesifikasi seperti:

- Wireless Session Protocol (WSP) Specification
- Wireless Datagram Protocol (WDP) Specification
- Wireless Binary XML (WBXML) Content Format Specification

Di halaman sebuah forum ini dinjelaskan secara garis besar bagaimana WAP push dikirimkan lewat SMS, sehingga saya tau spesifikasi mana yang menjelaskan tentang WAP push lewat SMPP.
Dengan membaca spesifikasi-spesifikasi tersebut, saya tau kalau WAP push sebenarnya bisa dikirimkan lewat bearer bermacam-macam yaitu SMS, USSD, circuit switch, packet switch (GPRS).

Friday, September 07, 2007

Proyek MVI

Agak bingung pertama kali denger proyek MVI, singkatan apa MVI itu? Ternyata MVI adalah kependekan dari Multi Vendor Integration.

Dari namanya kita bisa tebak proyek seperti apa MVI itu. Pada dasarnya di industri telko banyak operator yang membeli equiptments dan atau solusi dari banyak vendor. Jaringan yang dibangung operator mulai dari radio network, core network dan lain-lain biasanya dipilih dari beberapa supplier untuk mendapatkan yang terbaik. Jaringan multi-vendor seperti itu dapat membuat masalah interoperability, performance maupun keterlambatan project rollout, oleh karena itu solusi MVI menjadi bisnis baru bagi vendor telekomunikasi.

Proyek MVI berarti proyek sistem integrasi yang ditujuannya adalah bagaimana semua sistem dapat saling terintegrasi dan berinteraksi dengan benar dan opmimal. Project MVI pada akhirnya harus memastikan semua komponen network berjalan secara end-to-end karena itu didalamnya termasuk pekerjaan analisis, desain atau re-desain, audit, consulting/advising, testing. Sesuai namanya project ini meliatkan banyak vendor sehingga tantangannya tidak hanya masalah teknis tapi biasanya lebih besar tantangan non-teknisnya.

Followers