"Dalam konteks hubungan antara SMS dan penyedia konten, ada dua cara yang digunakan untuk menyampaikan pesan, yaitu Pull dan Push. Dalam skenario Pull pengguna akan mengirim keycode tertentu kemudian sistem milik penyedia konten akan merespon dengan mengirimkan konten yang diminta. Sedangkan pada skenario Push penyedia konten akan melakukan broadcast konten ke kumpulan nomor yang terdaftar.
Kebanyakan penyedia konten akan mem-broadcast konten mereka begitu saja tanpa memiliki mekanisme untuk mengontrol proses, status pengiriman, serta tingkat kesuksesan pengiriman itu sendiri. Berkaitan dengan hal tersebut maka skripsi ini dibuat yaitu untuk merancang bangun suatu sistem yang mempunyai kemampuan untuk mengendalikan proses push/broadcast, sehingga saat kondisi jaringan di sisi operator sedang sibuk broadcast dapat dihentikan sementara untuk dapat dilanjutkan kemudian saat kondisi memungkinkan.
Dari hasil skripsi ini tergambar bahwa tingkat keberhasilan proses broadcast (push) ditentukan oleh beberapa kondisi, diantaranya adalah cara broadcast serta waktu saat broadcast dilakukan. Dua hal ini adalah parameter yang bisa dimonitor dan dikendalikan. Dari hasil pengujian dan analisa didapat bahwa proses push tanpa delay (cara broadcast dilakukan, waktu idle antara dua proses pengiriman yang berurutan) yang dilakukan pada peak-hour (waktu saat broadcast dilakukan) hanya memiliki success-push-rate rata-rata sebesar 37%, sedangkan jika cara yang sama dilakukan diluar peak-hour maka success-push-rate akan meningkat menjadi rata-rata 96%. Jika cara broadcast diubah dengan menambahkan delay 1 detik saja, maka success-push-rate akan meningkat menjadi 100%, dan hasil ini tidak terpengaruh oleh waktu saat broadcast dilakukan, saat peak-hour atau diluar peak-hour.
In relationship between SMS and content provider, there is two ways that related to how a content delivered to end user, Pull and Push. Pull process is initiated by end-user as they send specific-and-predefined keycode to content provider system, the system will reply back with requested information. In Push scenario, system will initiate the process to broadcast a content to several registered number.
Most of content providers are directly broadcast their contents as it is without having a mechanism that could monitor the process itself. In that context this paper come up with the idea to design and implement the system with such capability. So during broadcast contents when network condition going unpredictably-high traffic the system can hold the push process temporarily and resume the process later, when the network traffic in more acceptable condition.
Result from this paper give some quantitive figure that shows that the level of succesfulness of broadcast/push process is tightly-related with several conditions, two of them are how the push process executed and when push process executed. These are two parameters that can be monitored and controlled. From some testing and data analysis it revealed that a push process without a delay (idle time between two consecutives send message, related to how push executed) during a peak-hour (related to when the push executed) suggested averagely 37% in success-push-rate, but when the same way of push is executed during a non peak-hour time then the success-push-rate positively increase to averagely 96%. If we change the way of push process is being executed by adding 1 second delay, the success-push-rate would stay at 100% regardless when the push is executed, during peak-hour or not."
