Two-sided Telecom Business Model

Bukan hal baru sebenarnya bahwa operator telekomunikasi saat ini berusaha mendapatkan keuntungan (revenue) tidak hanya dari pelanggannya saja. Operator mulai mengembangkan sayap untuk mendapatkan keuntungan dari value-added service seperti penjualan konten, membuat wap portal dengan memasan iklan sehingga dapat memperoleh keuntungan dari agensi iklan dan cara-cara lainnya.

Sebagian contoh tersebut memberikan gambaran bahwa terdapat peluang lain untuk mendapatkan keuntungan yang tidak langsung dari pelanggan (end-user). Hal inilah yang diusung oleh Telco 2.0 Initiative dengan istilah Two-sided Telecom Business Model (Lagi-lagi buzzword). Presentasi (slide) ini cukup bagus untuk mengerti latar belakang serta konsep Two-sided Telecom Business Model.

Gambar dibawah ini menrepresentasikan bagaimana konsep model bisnis ini.

OSS/BSS (Pengenalan)

OSS/BSS (Operation and Business Support Sistem) atau sering juga ditulis O/BSS adalah sistem atau platform yang melingkupi masalah operasional dan bisnis (non-teknis) yang mendukung berjalannya suatu jaringan dan layanan dari operator telekomunikasi.

Dalam pandangan saya yang masih terbatas dalam hal OSS/BSS ini, saya melihat bahwa OSS merupakan sistem pendukung operasional yang bersifat teknis misalnya untuk memonitor, mengelola dan memanajemen resource atau elemen yang ada dalam jaringan telekomunikasi. Sedangkan BSS merupakan sistem yang bersifat pendukung bisnis misalnya managemen pelanggan (customer), billing system, CRM, call center, datawarehouse, business intelligent, reporting/settlement dan lain-lain.

Sebagai bacaan awal agar lebih memahami lingkupan dari O/BSS anda bisa baca artikel di wikipedia tentang OSS dan BSS.

Cakupan OSS adalah (disingkat FCAPS):

• Fault Management
• Configuration Management
• Accounting Management
• Performance Management
• Security Management

Sedangkan cakupan BSS:

• Product Management
• Customer Management
• Revenue Management
• Order Management

Memang terlihat cakupan dari OSS/BSS ini sangat luas implementasinya pun bisa melibatkan banyak produk dan protokol untuk integrasi antar produk atau elemen.

Lalu untuk memahami gambaran besar tentang OSS/BSS kita mulai dari mana?

Seperti telah kita ketahui perkembangan teknologi pada dunia telekomunikasi banyak didorong oleh standar sehingga arah untuk mempelajari OSS/BSS sebaiknya dimulai dari standarisasi.

Standarisasi OSS/BSS yang paling sukses adalah Open Systems Interconnection (OSI) Systems Management Overview (SMO) dari ISO yang kemudian diadopsi oleh ITU-T sebagai Telecommunications Management Network (TMN), serta TOM (Telecom Operations Map) yang dibuat oleh TeleManagement Forum (TM Forum) yang juga diadopsi oleh ITU-T.

Dokumen yang baik dibaca untuk awal adalah ITU-T Recommendation diantaranya:

• M.3010 Telecommunications Management Network (TMN)
• M.3400 TMN management functions

• M.3050 Enhanced Telecommunications Operations Map (eTOM) - Supplements
• M.3050.0 Enhanced Telecom Operations Map (eTOM) - Introduction
• M.3050.1 Enhanced Telecom Operations Map (eTOM) - The business process framework
• M.3050.2 Enhanced Telecom Operations Map (eTOM) - Process decompositions and descriptions
• M.3050.3 Enhanced Telecom Operations Map (eTOM) - Representative process flows
• M.3050.4 Enhanced Telecom Operations Map (eTOM) - B2B integration: Using B2B inter-enterprise integration with the eTOM

Untuk link dokumen yang lebih up-to-date, ikuti link pada halaman ITU-T Recommendation M series

WAP Push lewat protokol SMPP

Seperti sudah dijelaskan di posting sebelumnya dan sebelumnya, WAP push biasanya dikirimkan dalam bentunk XML ke PPG (Push Proxy Gateway) dengan menggunakan prokol PAP (Push Application Protocol). Contoh sebuah body message pada PAP untuk mengirimkan WAP push ke ponsel adalah seperti ini:

          
   <si>                                                                                             
   <indication href="http://cp.com/dl/javagames.php">
     Klik untuk download konten                                                                          
   </indication>                                                                                  
   </si>                                                                                            

Kita perlu ingat juga bahwa WAP push didesain agar "bearer independent" artinya dapat dikirimkan dari jaringan operator ke ponsel lewat bearer apapun yaitu SMS, USSD, circuit switch atau packet switch (GPRS). WAP push paling sering dikirimkan lewat bearer SMS dengan cara mengirimkan ke SMSC menggunakan protokol SMPP. Lalu bagaimana WAP push dapat dikirimkan lewat SMPP?

WAP push dikirimkan menggunakan submit_sm request ke SMSC, ada beberapa parameter yang harus diset pada submit_sm yaitu ESM_CLASS, DATA_CODING dan message (payload). Nilai untuk ESM_CLASS dan DATA_CODING adalah sebagai berikut

ESM_CLASS = 0x40
DATA_CODING = 0xF5

Sedangkan parameter message yang biasa kita isi teks dari SMS harus kita isi dengan kode WAP push XML yang disederhanakan dengan cara dibuat dalam bentuk biner. Hal ini dilakukan agar data menjadi lebih kecil. Penjelasan yang lebih detail dapat dibaca dari spesifikasi WBXML (WAP Binary XML) yaitu standar representasi XML dalam bentuk biner. WBXML dispesifikasikan oleh WAP Forum atau Open Mobile Alliance.

Sekarang coba kita encode XML diatas menjadi kode hexa WAP push. Setiap tag XML maupun atribut memiliki kode tertentu, sedangkan untuk teks yang merupakan nilai dari element atau attribute kita ubah menjadi string hexa dengan diawali dengan kode 03 yang berarti awal dari sebuah string ASCII dan diakhiri dengan 00.

Bagian XML                                        Kode hexa
------------------------------------------------  -----------------------------------------------------------
<si>                                               45
<indication                                        C6
href='http://                                      0C
Tanda awal untuk string ASCII                      03
cp.com/dl/javagames.php                            63702E636F6D2F646C2F6A61766167616D65732E706870
Tanda akhir string                                 00
> (Penutup tag indication)                         01
Tanda awal untuk string ASCII                      03    
Klik untuk download konten                        4B6C696B20756E74756B20646F776E6C6F6164206B6F6E74656E74
Tanda akhir string                                 00
</indication>                                      01
</si>                                              01

Jadi sekerang kita telah memiliki kode hexa dari XML WAP push yaitu 45C60C0363702E636F6D2F646C2F6A61766167616D65732E7068700001034B6C696B20756E74756B20646F776E6C6F6164206B6F6E74656E74000101


Sebelum memasukan kode tersebut dalam payload message di submit_sm request, kita memerlukan bagian UDH (User Data Header) sebagai berikut

 Header parameter                                                          Value
------------------------------------------------------------------------- ---------
UDH lenght                                                                06
                                                                          0504
Destination port                                                          0B84
Source port                                                               23F0
                                                                              
Transaction ID: Push ID                                                   DC
PDU Type: Push                                                            06
Headers lenght: 1                                                         01
Content type: application/vnd.wap.sic (0x80 | 0x2E)                       AE                                                                                                                                                                       

Version: 1.2                                                              02
Public identifier: -//WAPFORUM//DTD SI 1.0//EN (Service Indication 1.0)   05
Character Set: utf-8                                                      6A
String table: 0 bytes                                                     00

Sekarang kita telah memiliki header yaitu 0605040B8423F0DC0601AE02056A00,header ini harus disimpan selum kode binary XML dari message.

Contoh lengkap bagaimana membuat WAP push dengan menggunakan Java SMPP library atau library versi aslinya dari Logica, saya tulis dibawah ini:

// Create submit_sm request
SubmitSM request = new SubmitSM();

// Set binary message specific params
request.setEsmClass((byte)(Data.SM_UDH_GSM)); //0x40
request.setDataCoding((byte)0x0f5);
...

// Create hexa code for WAP push
String hexMessage = "0605040B8423F0DC0601AE02056A0045C60C03"                           
      + byteArrayToHexString("cp.com/dl/javagames.php".getBytes()).toUpperCase()
      + "000103"                                                                      
      + byteArrayToHexString("Klik untuk download konten".getBytes()).toUpperCase()   
      + "000101";                                                                     

// Set WAP push as short message data                                                                                        
request.setShortMessageData(hexToByteArray(hexMessage));

//Send submit_sm request to SMSC
session.submit(request);         

Kode diatas menggunakan dua method utilitas byteArrayToHexString syaitu untuk mengubah string byte array menjadi hexadesimal byte yang direpresentasikan dalam string dan method hexToByteArray yang melakukan hal kebalikannya.

Kedua method tersebut saya tuliskan dibawah

public static String byteArrayToHexString(byte[] b) {
                                             
  int    len = b.length;                     
  char[] s   = new char[len * 2]; // + 2 ];  
  //s[0] = '\'';                             
  int j = 0;                                 
  for (int i = 0; i < len; i++) {            
      int c = ((int) b[i]) & 0xff;           
                                                           
      s[j++] = (char) HEXBYTES[c >> 4 & 0xf];
      s[j++] = (char) HEXBYTES[c & 0xf];     
  }                                          
                                             
  //s[j] = '\'';                             
                                             
  return new String(s);                      
}

public static byte[] hexToByteArray(String s) throws IOException {     
                                                                     
  int    l    = s.length() / 2;                                      
  byte[] data = new byte[l];                                         
  int    j    = 0;                                                   
                                                                     
  if (s.length() % 2 != 0) {                                         
      throw new IOException(                                         
          "hexadecimal string with odd number of characters");    //NOI18N
  }                                                                  
                                                                     
  for (int i = 0; i < l; i++) {                                      
      char c = s.charAt(j++);                                        
      int  n, b;                                                     
                                                                     
      n = HEXINDEX.indexOf(c);                                       
                                                                     
      if (n == -1) {                                                 
          throw new IOException(                                     
              "hexadecimal string contains non hex character");    //NOI18N
      }                                                              
                                                                     
      b       = (n & 0xf) << 4;                                      
      c       = s.charAt(j++);                                       
      n       = HEXINDEX.indexOf(c);                                 
      b       += (n & 0xf);                                          
      data[i] = (byte) b;                                            
  }                                                                  
                                                                     
  return data;                                                       
}                                                                                                                             

Jika kita lihat secara keseluruhan paket (PDU) dari sebuah submit_sm untuk WAP push adalah seperti contoh berikut ini:

Mobile Content Delivery Solution

Saya sudah membicarakan mengenai Mobile CMS di posting sebelumnya. Di posting ini saya akan membahas tentang Mobile Content Delivery Solution (MCDS) yaitu sebuah konsep solusi untuk operator telekomunikasi yang mempermudah management konten dan pengiriman konten ke pelanggan (subscriber). MCDS bisa dibilang sama dengan mobile CMS karena sebuah MCDS merupakan sistem end-to-end untuk content management dan delivery.

Sebuah MCDS biasanya memiliki fitur-fitur berikut ini:

Modul Content Discovery/Delivery yang terintegrasi dengan elemen yang berfungsi sebagai delivery/discovery channel seperti
- Web/WAP portal
- SMS
- WAP push
- USSD
- IVR


Modul Content Management yang berfungsi sebagai tempat penyimpanan kontent (content storing), menyimpan metadata/informasi kontent, pengkategorisasian kontent, content lifecycle management termasuk submission dan workflow untuk persetujuan (approval) serta pengelolaan digital-right (DRM).

Modul Content Promotion atau Campaign Management yang memberikan kemudahan untuk melakukan promosi misalnya
hadiah (gift), undian (coupons), broadcast, paket, sponsored promotion, up-sell, cross-sell dan lain-lain.

Modul 3rd Party Content Provider Management yang memberikan kemudahan untuk mengelola konten yang berasal dari provider konten yang berlainan dengan skema bagi-hasil yang berbeda.

Modul Profile/Device management yang berfungsi sebagai tempat menyimpan informasi pelanggan serta jenis perangkat yang digunakan sehingga kontent dapat dikirimkan ke pengguna yang tepat sasaran.

Modul Reporting yang memberikan laporan-laporan yang dibutuhkan baik sebagai alat analisis atau rekonsiliasi antara operator dan content provider.

Berkembangnya bisnis konten mendorong vendor-vendor telekomunikasi untuk memberikan solusi/produk MCDS. Beberapa contoh produk MCDS diantaranya

• Solusi dari BEA-MobileAware-EMCDocumentum,
• Ericsson memiliki produk dari hasil akuisisi Drutt Corporation
  
• Nokia Siemens Networks menggunakan prooduk dari 3rd party yaitu XIAM + Hydra yang tergabung dalam TheSDPAlliance.org
• Sun Microsystem juga memiliku Sun Java System Content Delivery Server
• Solusi dari HP yang menggunakan produk-produk 3rd party
  

CAMEL

Sebelum membaca posting/artikel ini, anda mungkin tertarik untuk membaca posting sebelumnya tentang Intelligent Network (IN).

CAMEL (Customized Application for Mobile network Enhanched Logic) adalah suatu fitur dalam jaringan telekomunikasi operator yang merupakan alat bantu dalam penyediaan layanan (operator spesific service). CAMEL merupakan standar untuk inteligent network (IN) pada jaringan GSM yang dibuat oleh ETSI (European Telecommunications Standards Institute).

Dengan adanya CAMEL, pengguna ponsel sebagai end-user akan dapat menggunakan layanan yang sama pada jaringan pada operator lain (roaming) dengan menggunakan nomor telepon yang sama dan mendapatkan tagihan hanya dari operator asal (home operator).

Pada dokumen spesifikasi CAMEL kita dapat lihat arsitektur yang dibutuhkan pada jaringan operator agak mendukung CAMEL. Dibawah ini adalah gambar arsitektur CAMEL Phase 2.




Arsitektur diatas menggambarkan entitas fungsional (functional entities) yang terlibat dalam CAMEL. Entitas tersebut dijelaskan dibawah ini

• gsmSCF (GSM Service Control Function) adalah entitas fungsional yang berisi CAMEL service logic yang mengatur suatu layanan. Entitas ini bisa diasosiasikan dengan fungsi intelegent network (IN) dalam jaringan operator)
  
  
• gsmSRF (GSM Specialised Resource Function) adalah entitas fungsional yang menyimpan dan memberikan resource yang dibutuhkan oleh gsmSCF. Resource ini misalnya berupa file audio yang merupakan tone atau announcement ketika sebuah panggilan tidak dapat dilakukan. gsmSCF mengatur atau memberikan perintah kepada MSC untuk mejalankan (play) resource yang berada pada gsmSRF sehingga kita dapat mendengarkan pesan seperti "maaf, untuk sementara nomer ini tidak dapat dihubungi" ketika sebuah nomor yang dipanggil tidak dapat dihubungi. Fungsi ini biasanya sudah termasuk pada sebuah produk server IN dan biasanya disebut Voice Response Units (VRUs).
  
  gsmSRF ditambahkan pada arsitektur CAMEL sejak CAMEL phase 2.
  
  
• gsmSSF (GSM Service Switching Function) adalah entitas fungsional yang berada dalam MSC/GMSC yang membuat MSC/GMSC dapat berinteraksi dengan gsmSCF atau server IN ketika sebuah layanan sedang digunakan oleh pengguna.
  

Dalam arsitektur tersebut kita dapat melihat juga protokol yang digunakan antar entitas yaitu

• MAP (Mobile Application Part) yang digunakan untuk menghubungkan MSC/GMSC dengan HLR, gsmSCF dengan MSC atau HLR, dan MSC/VLR dengan HLR
• CAP (CAMEL Application Part) yang digunakan untuk MSC/GMSC/gsmSSF dengan gsmSCF, gsmSCF dengan gsmSRF
  

Protokol tersebut adalah protokol SS7 yang biasanya dilewatkan pada jaringan TDM ataupun IP. Dalam jaringan SS7, gsmSSF berada pada SSP (Service Switching Point) sedangkan gsmSCF dan gsmSRF berada pada SCP (Service Control Point).


Versi CAMEL

Spesifikasi CAMEL terus berkembang dengan penambahan fitur-fitur baru. Ada beberapa versi CAMEL yang dirilis oleh ETSI/3GPP hingga saat ini. Versi CAMEL tersebut biasa disebut phase yaitu

• CAMEL phase 1 1996
• CAMEL phase 2 1997 dan 1998
• CAMEL phase 3 1999
• CAMEL phase 4,Enhancement for GPRS

Isi (fitur-fitur) dari tiap phase dapat dilihat di dokumen N2-030543. CAMEL phase 1 pertama kali diimplementasikan pada sebuah jaringan operator pada tahun 2000.

Dokumen Spesifikasi CAMEL

CAMEL didefinisikan dalam 3 stage yaitu

• Stage 1 (requirements) dispesifikasikan pada GSM 02.78 / 3GPP TS 22.078
  
• Stage 2 (functions, conceptual data flow) dispesifikasikan pada GSM 03.78 / 3GPP TS 23.078
  
• Stage 3 (protocol) - CAMEL Application Part (CAP) GSM 09.78 / 3GPP TS 29.078
  

Coba baca entri di FAQ ini sebagai guide soal spesifikasi CAMEL.

Konsep-konsep Penting

Dalam memahami cara kerja CAMEL, ada beberapa konsep penting yang perlu diketahui diantaranya:

1. Detection Point (DP)
Jika sebuah proses pemanggilan (call) yang kita lihat disisi MSC/SSP kita gambarkan, maka akan ada beberapa titik proses yaitu:
- call diterima oleh MSC
- call diteruskan ke nomor yang dipanggil
- call diterima oleh nomor yang dipanggil
- terjadi pecakapan
- call diputus

Pada proses kejadian call tersebut terdapat beberapa titik kejadian (event) yang dapat dideteksi oleh SSP. Titik kejadian yang terdeteksi pada proses pemanggilan tersebut disebut DP dan digunakan oleh SSP untuk memberitahu (notify) gsmSCF. gsmSCF kemudian akan memberikan intrsuksi bagaimana call tersebut harus ditangani misalnya call harus diputus karena pemanggil tidak memiliki pulsa (balance) yang cukup.

2. CAMEL Subscriber Information (CSI)
Seorang pelanggan disebut CAMEL subscriber jika dia memiliki satu atau lebih CAMEL Subscription Information (CSI) yang berrada di Home PLMN, biasanya di HLR. CSI dapat diaplikasikan pada tiap pelanggan artinya masing-masing pelanggan dapat memiliki CSI yang berbeda.

CSI merupakan informasi profil dari pelanggan sehingga gsmSCF dapat memberikan layanan sesuai dengan profil pelanggan. CSI akan diminta oleh MSC/VLR atau SGSN dari HLR ketika pelanggan terkoneksi (Location Update) pada jaringan operator.

Beberapa macam CSI adalah:

• O-CSI (Originating)
• T-CSI (Terminating)
• U-CSI (USSD)
• UG-CSI (USSD General)
• SS-CSI (Suplementary Srvice)
• TIF-CSI (Translation Information Flag)
• M-CSI (Mobility Management)
• MG-CSI (mobility Management for GPRS)
• MO-SMS-CSI (Originating Short Message Service)
• MT-SMS-CSI Terminated Short Message Service)
• GPRS-CSI
• VT-CSI (VMSC Terminating)

Masing-masing CSI diatas memiliki parameter-parameter yang dispesifikasikan pada dokumen spesifikasi CAMEL.

3. Basic Call State Model (BSCM)

BSCM biasanya digambarkan dalam sebuah diagaram yang merupakan model dari aktifitas pada MSC/VLR atau GMSC dalam menangani dan mengelola jalur komunikasi pelanggan. Ada dua macam BSCM yaitu Originating BSCM (o-BSCM) yang menggambarkan model panggilan call dan Terminating BSCM (T-BSCM) yang menggambarkan model penerimaan call. Dalam BSCM kita dapat melihat proses dan event atau DP yang dapat terjadi.

Dalam dokumen spesifikasi, proses-proses seperti SMS, USSD dan lain-lain biasanya juga digambarkan functional entities yang terlibat, state model, prosedur serta dijelaskan interface dan information flow.


4. CAMEL Application Part (CAP)
CAP merupakan implementasi dari fungsionalitas yang ada dalam CAMEL. CAP adalah protokol yang digunakan pada interface gsmSSF dengan gsmSCF atau gsmSCF dengan gsmSRF. Protokol ini dilewatkan pada jaringan SS7 (TDM) ataupun jaringan packet (IP/SIGTRAN).

Sebelum CAMEL, jaringan GSM menggunakan INAP (Intelligent Network Application Part). Karena keterbatasan INAP misalnya tidak mendukung mobility management karena INAP dibuat untuk jaringan kabel (Fixed line). CAMEL/CAP merupakan ekstensi dari Core INAP yang dikeluarkan ETSI.

SIGTRAN Pada Jaringan UMTS

Teknologi transport untuk semua traffic seperti suara, paket data, dan signaling mengarah ke penggunakan IP. SIGTRAN (Signaling Transport) adalah sebuah standar untuk membawa SS7 signaling lewat sebuah jaringan IP. SIGTRAN dibuat oleh sebuah Working Group di IETF.

SIGTRAN didesain agar SS7 yang tadinya menggunakan jaringan TDM dan ATM kini dapat dilewatkan pada jaringan IP (berbasis packet) dengan tetap mempertahankan karakteristik awalnya yaitu realible, memiliki mekanisme redundancy jika ada sambungan yang putus (link failure), loss dan delay yang kecil, aman terhadap serangan DoS (Denial of Service). Karakteristik tersebut tidak dapat dicapai dengan penggunaan protokol TCP ataupun UDP sehingga diimplementasikan dengan protokol baru yaitu SCTP (Stream Control Transmission Protocol) yang dispesifikasikan pada RFC 4166.


Spesifikasi SIGTRAN. terdiri dari beberapa dokumen. Status setiap spesifikasi (RFC) sigtran yang dikeluarkan IETF dapat dilihat disini.

Implementasi SS7 menggunakan sigtran dapat dilakukan dengan beberapa cara. Dibawah ini saya gambarkan perbandingan antara SS7 stack tradisional dengan beberapa opsi implementasi sigtran.

                  |
                  |
+---------------+  |   +------------+  +------------+  +------------+  +------------+
|  MAP/CAP/etc  |  |   | MAP/CAP/etc|  | MAP/CAP/etc|  | MAP/CAP/etc|  | MAP/CAP/etc|
|---------------|  |   |------------|  |------------|  |------------|  |------------|   
|    TCAP       |  |   |    TCAP    |  |    TCAP    |  |    TCAP    |  |    TCAP    |
|---------------|  |   |------------|  |------------|  |------------|  |------------|
|    SCCP       |  |   |            |  |    SCCP    |  |    SCCP    |  |    SCCP    |
|---------------|  |   |            |  |------------|  |------------|  |------------|
|    MTP 3      |  |   |    SUA     |  |            |  |    MTP3    |  |    MTP3    |
|---------------|  |   |            |  |    M3UA    |  |------------|  |------------|
|               |  |   |            |  |            |  |    M2UA    |  |    M2PA    |
|    MTP 2      |  |   |------------|  |------------|  |------------|  |------------|
|               |  |   |    SCTP    |  |    SCTP    |  |    SCTP    |  |    SCTP    |
|---------------|  |   |------------|  |------------|  |------------|  |------------|
|    MTP 1      |  |   |     IP     |  |     IP     |  |     IP     |  |     IP     |
+---------------+  |   +------------+  +------------+  +------------+  +------------+
                  |         (1)            (2)             (3)              (4)
                  |
  SS7 stack       |             Implementasi SS7 menggunakan SIGTRAN      
                  |

IETF menspesifikasikan SUA, M3UA, M2UA dan M2PA sebagai protokol pengguna SCTP dan bersama-sama SCTP memberikan fungsionalitas sebagai transport layer seperti MTP2.

SIGTRAN Pada Jaringan UMTS

Sigtran sudah diadopsi sebgai protokol yang digunakan pada core network jaringan UMTS oleh 3GPP sejak Release 4, lihat 3GPP TS 29.202 "SS7 Signalling Transport in Core Network". 3GPP memilih SCCP/M3UA sebagai satu-satunya standar untuk transport protokol SS7 lewat IP di core network. M3UA digunakan pada Mc interface antara MSC dan MGW yang dijelaskan pada 3GPP TS 29.205 dan 3GPP TS 29.232. M3UA juga dapat digunakan sebagai alternatif protokol untuk RANAP (3GPP TS 25.412) dan RNSAP (3GPP TS 25.422).

Ada kemungkinan nantinya M2PA juga akan diadopsi oleh 3GPP karena berdasarkan 3GPP TR (Techincal Report) 29.801 "Feasibility study of using M2PA in 3GPP networks" diusulkan M2PA untuk juga digunakan sebagai IP based signalling networks pada interface B yaitu interface antara Signaling Gateway (SG) dengan SG lain.

Dokumen 3GPP TR 19.801 bisa dijadikan referensi yang baik untuk perbandingan protokol M2PA dan M3UA.