ABSTRAK

Aplikasi video dalam skenario Internet of Things (IoT) multihop nirkabel dapat memperoleh manfaat dari strategi perutean multijalur untuk memenuhi persyaratan kualitas layanan (QoS) yang seringkali ketat. Akan tetapi, dinamika jaringan dasar dan persyaratan layanan video memerlukan jaringan perutean multijalur yang dapat beradaptasi secara dinamis terhadap kondisi yang berubah. Dalam makalah ini, kami menyajikan arsitektur perutean multijalur nirkabel yang mampu beradaptasi dengan berbagai kondisi topologi jaringan dan karakteristik lalu lintas video dengan menemukan jalur baru secara dinamis, sehingga menghasilkan kualitas pengalaman pengguna akhir yang lebih baik. Selain itu, kami memberikan gambaran umum tentang lanskap aplikasi video nirkabel IoT dan taksonomi mekanisme pemilihan rute terkini untuk perutean multijalur.

1 Pendahuluan
Dalam beberapa tahun terakhir, kemajuan dalam teknologi kamera Protokol Internet (IP) dan jaringan komunikasi nirkabel telah memungkinkan berbagai macam aplikasi video Internet of Things (IoT) di berbagai bidang seperti kota pintar, otomasi industri, pemantauan lingkungan, dan perawatan kesehatan [ 1 ]. Di kota pintar, khususnya di bidang keselamatan publik, berbagai aplikasi video IoT telah digunakan untuk pengawasan ruang publik, jalan raya, tempat parkir, dan transportasi umum [ 2 ]. Dalam skenario ini, video diambil dan dikirimkan melalui jaringan nirkabel multihop.

Mengingat volume dan persyaratan QoS yang tinggi, aplikasi video IoT mungkin mengalami kemacetan dan penundaan jaringan karena keterbatasan bandwidth dan kehilangan paket, yang berdampak buruk pada kualitas media yang dikirimkan [ 3 ], terutama dalam kasus aplikasi waktu nyata [ 4 ].

Perutean multijalur, sebuah teknik yang menggunakan beberapa jalur antara sumber dan tujuannya untuk mengirimkan lalu lintas, telah terbukti menyediakan persyaratan QoS yang memadai untuk aplikasi video dengan mendistribusikan lalu lintas melalui beberapa jalur, yang menghasilkan kehilangan paket dan latensi ujung ke ujung yang lebih rendah [ 5 ].

Protokol routing multipath dengan kinerja terbaik yang ditemukan dalam literatur menggunakan mekanisme pemilihan rute berdasarkan pandangan global topologi jaringan [ 6 ]. Namun, kondisi jaringan biasanya berubah secara dinamis, terutama dalam skenario IoT, yang mengharuskan informasi topologi jaringan terus diperbarui.

Bahasa Indonesia: Dalam karya ini, kami mengusulkan arsitektur perutean multipath yang secara khusus ditujukan pada aplikasi transmisi video IoT yang, selain mekanisme pemilihan multipath yang efisien, juga mencakup monitor topologi. Monitor topologi yang diusulkan memungkinkan setiap node untuk mempertahankan tampilan lengkap dari topologi jaringan melalui pemantauan dan penyebaran status tautannya, mirip dengan apa yang diterapkan oleh protokol perutean status tautan proaktif. Tujuannya adalah untuk memungkinkan mekanisme pemilihan multipath untuk secara otomatis membuat rute baru untuk aliran video jika ada perubahan signifikan dalam kualitas tautan seperti yang dilaporkan oleh node yang berpartisipasi. Kami mengevaluasi arsitektur perutean multipath kami dan monitor topologinya yang beroperasi dengan dua mekanisme pemilihan multipath: FITPATH ​​[ 6 ] dan QSOpt [ 7 ].

Perlu dicatat bahwa untuk menjaga informasi topologi terus diperbarui, transmisi pesan kontrol berkala diperlukan. Pesan-pesan tersebut bersaing untuk penggunaan saluran dengan aliran video dan dapat menyebabkan efek buruk pada kualitas pengalaman pengguna (QoE). Karena lalu lintas kontrol tidak dipertimbangkan dalam [ 6 ] atau [ 7 ], pekerjaan ini juga bertujuan untuk mengevaluasi, di bawah kondisi jaringan yang lebih realistis, dampak aliran kontrol pada kinerja jaringan dan QoE pengguna. Kami selanjutnya mencatat bahwa, sementara evaluasi kami berpusat pada jaringan IEEE 802.11, solusi yang kami usulkan cukup generik untuk mendukung teknologi lain, asalkan karakteristik khusus mereka ditangkap oleh mekanisme pemilihan rute.

Sisa dari makalah ini disusun sebagai berikut: Bagian 2 menjelaskan skenario aplikasi transmisi video multipath nirkabel yang umum. Di Bagian 3 , arsitektur terdesentralisasi diusulkan, dengan taksonomi mekanisme pemilihan multipath yang berbeda, rincian monitor topologi, dan tantangan implementasi tertentu. Metodologi evaluasi dan hasil disajikan di Bagian 4 dan 5. Akhirnya, Bagian 6 berisi pertimbangan akhir, yang merangkum kontribusi serta pekerjaan di masa mendatang.

2 Skenario Aplikasi
Salah satu aplikasi video IoT yang paling umum di kota pintar adalah keamanan dan pengawasan ruang luar atau dalam ruangan untuk mengontrol akses ke suatu area dan mendeteksi pengunjung yang tidak berwenang, di antara tujuan lainnya [ 8 ]. Pusat-pusat perkotaan besar telah mengadopsi jaringan kamera untuk membantu mengelola transportasi umum, lalu lintas, kondisi jalan, dan parkir [ 9 ]. Video dari beberapa kamera dapat dianalisis secara real time atau offline menggunakan teknik visi komputer untuk memberikan informasi berharga mengenai jam sibuk, lalu lintas dan kondisi/insiden jalan, rute, dan banyak lagi [ 10 ].

Skenario aplikasi yang dipertimbangkan dalam karya ini adalah sistem pemantauan video area perkotaan, seperti yang diilustrasikan dalam Gambar 1a . Kami berasumsi bahwa node jaringan adalah sumber video itu sendiri (kamera). Perhatikan bahwa persyaratan jaringan bervariasi dengan persyaratan khusus aplikasi. Misalnya, manajemen lalu lintas hanya memerlukan keandalan yang cukup untuk mendapatkan detail untuk membedakan kontur kendaraan dari lingkungan sekitar dan melacak pergerakannya. Di sisi lain, aplikasi pelacakan orang memerlukan throughput jaringan yang tinggi karena bergantung pada video definisi tinggi untuk memungkinkan mengidentifikasi dan melacak fitur wajah [ 8 ].

GAMBAR 1

Node jaringan biasanya dipasang di tiang-tiang jalan [ 9 ]. Seperti di semua lingkungan perkotaan, komunikasi nirkabel di kota pintar dapat mengalami kendala besar (seperti gedung), kebisingan, dan gangguan. Dengan demikian, kinerja sistem juga sangat bergantung pada distribusi node kamera, serta faktor-faktor lain yang disebutkan di atas.

Gambar 1b menunjukkan bagaimana sumber video dapat mengirimkan beberapa aliran video melalui jalur yang berbeda. Sepanjang makalah ini, kami akan menunjukkan himpunan semua sumber video pada topologi sebagaiSKami selanjutnya berasumsi bahwa setiap kamera juga dapat bertindak sebagai node perantara, yang meneruskan lalu lintas yang berasal dari kamera lain. Setiap sumber SE dapat menghasilkan serangkaian aliran video Fs = Fs2 , Di mana o< i < |Fs| Setiap aliran yang ditransmisikan Fs memiliki bit rate tertentu, ditentukan oleh sumbernya, sesuai dengan resolusi video dan encoder yang digunakan, dan menggunakan jalur yang dipilih Ps dari daftar P kemungkinan jalur untuk mencapai tujuan. Di setiap simpul tujuan, dekoder video bertanggung jawab untuk menyinkronkan dan menggabungkan aliran yang diterima untuk rendering video. Dalam skenario ini, simpul tujuan adalah stasiun pengawasan, tempat video diamati oleh operator secara real time. Menurut permintaan aplikasi yang ditetapkan, beberapa sumber dapat secara bersamaan mentransfer aliran ke satu atau lebih penerima.

Berbeda dengan encoder media konvensional yang menghasilkan satu bitstream tunggal, pekerjaan ini mengasumsikan penggunaan video yang dapat diskalakan. Pengodean berlapis (LC) dan pengodean deskripsi berganda (MDC) adalah encoder yang dapat diskalakan yang secara tradisional digunakan dalam transmisi video multipath [ 11 ], karena mereka mengodekan sumber menjadi dua atau lebih substream dengan bitrate berbeda yang dapat ditransmisikan melalui jalur yang dipilih. Dengan demikian, untuk memaksimalkan QoE pengguna, mekanisme pemilihan multipath harus mempertimbangkan bitrate dari setiap aliran yang bersaing untuk menyeimbangkan beban yang ditawarkan dan meminimalkan penundaan dan kehilangan paket.

3 Arsitektur Routing Multipath Adaptif
Dalam aplikasi video IoT Smart Cities, node biasanya stasioner dan ditenagai oleh sumber energi berkelanjutan. Meskipun perubahan topologi yang sering terjadi karena mobilitas node tidak diharapkan dan keterbatasan energi tidak perlu dipertimbangkan, variasi kualitas dan stabilitas tautan nirkabel yang umum terjadi dalam jaringan nirkabel biasanya menyebabkan perubahan topologi yang sering terjadi.

Dalam skenario di mana perubahan topologi perlu dipertimbangkan, informasi tentang kondisi jaringan dapat diperoleh dengan berbagai cara, tergantung pada apakah bidang kontrol jaringan tersentralisasi atau terdesentralisasi. Di bawah kontrol terpusat, satu solusi yang mungkin melibatkan penggunaan pengontrol jaringan yang ditentukan perangkat lunak (SDN) [ 12 ] yang membuat keputusan perutean dibantu oleh mekanisme pemilihan jalur berdasarkan persyaratan lalu lintas dan informasi topologi jaringan yang diperbarui. Informasi topologi diterima oleh pengontrol SDN secara langsung dari setiap node. Pengontrol kemudian memperbarui tabel perutean node penerusan sehingga mereka mengirimkan aliran sesuai dengan jalur yang dipilih.

Dalam karya ini, kami memilih arsitektur terdesentralisasi di mana node jaringan IoT berkolaborasi dalam proses pemilihan multijalur dan meneruskan lalu lintas video melalui jalur yang dipilih. Kami menjelaskan arsitektur terdesentralisasi yang diusulkan secara terperinci di bawah ini.

3.1 Bidang Kontrol Jaringan Terdesentralisasi
Gambar 2 mengilustrasikan arsitektur perutean multijalur adaptif yang diusulkan, di mana simpul tujuan (berwarna abu-abu) mewakili stasiun pengawasan dan simpul sumber (berwarna hitam), kamera video. Setiap simpul jaringan menjalankan aplikasi video, modul pemilihan multijalur, dan monitor topologi. Dua komponen terakhir dari arsitektur tersebut, yaitu pemilihan multijalur dan monitor topologi dijelaskan secara rinci di Bagian 3.2 dan 3.3 , masing-masing.

GAMBAR 2

Gambar 3 menunjukkan diagram alur yang merangkum bagaimana transmisi video dilakukan sesuai dengan arsitektur terdesentralisasi kami (Gambar 2 ) sebagai berikut:

• Semua node secara proaktif melakukan transmisi berkala pesan penemuan topologi, yang memungkinkan setiap node mengidentifikasi tetangganya dan biaya tautan masing-masing. Informasi ini disebarkan ke semua node lain untuk memastikan mereka memiliki pandangan global terkini tentang topologi jaringan.
• Ketika stasiun pengawasan menghasilkan permintaan video dari sumber video:
• Aplikasi video dan monitor topologi dari stasiun pengawasan memberi tahu pemilih multijalurnya tentang persyaratan aliran video dan topologi yang diperbarui.
• Pemilih multijalur kemudian memilih rute terbaik untuk aliran.
• Stasiun pengawasan mengirimkan pesan permintaan ke masing-masing sumber video yang relevan, dalam arah yang berlawanan dengan jalur terbaik yang dipilih untuk masing-masing sumber. Kecepatan penyandian video yang diperlukan dan daftar lengkap dan berurutan dari node yang harus dilalui setiap paket aliran video untuk diteruskan disediakan di header pesan permintaan.
• Saat permintaan mencapai sumber yang diminta, video dikodekan sesuai dengan kecepatan yang dibutuhkan dan paket aliran ditransmisikan melalui jalur yang dipilih. Untuk menjamin penggunaan jalur yang dipilih, kami menggunakan perutean sumber, yaitu, informasi jalur lengkap ke simpul tujuan disertakan dalam tajuk setiap paket, sehingga menghindari perulangan perutean dan dengan mudah memungkinkan jalur yang berbeda digunakan untuk aliran yang berbeda yang dihasilkan oleh sumber yang sama.
• Karena data yang dikumpulkan oleh proses pemantauan topologi diperbarui secara berkala, pemicu dapat ditetapkan untuk mencari solusi jalur baru, seperti kegagalan tautan atau ketersediaan tautan baru dalam jaringan. Bergantung pada layanan video, persyaratan aliran juga dapat berubah secara dinamis; misalnya, resolusi kamera dapat diubah atau dapat dinonaktifkan atau diaktifkan.
• Jika tidak ada perubahan pada topologi atau persyaratan video, transmisi akan dilanjutkan menggunakan jalur yang telah ditetapkan sebelumnya.
• Jika tidak, jalur baru akan dipilih.

GAMBAR 3

3.2 Mekanisme Seleksi Multijalur
Sejumlah mekanisme pemilihan multipath untuk transmisi video nirkabel telah diusulkan [ 4 – 6 ]. Kebanyakan dari mekanisme tersebut menggunakan metrik routing tradisional, seperti delay dan hop count, yang belum tentu merupakan pilihan terbaik untuk memilih jalur optimal guna mengirimkan beberapa aliran video secara bersamaan [ 6 ]. Kebanyakan mekanisme menganalisis tautan dan jalur secara individual, sehingga meningkatkan kemungkinan dua atau lebih jalur berbagi tautan, sehingga mengakibatkan interferensi aliran.

Perutean jalur terpisah merupakan alternatif yang diadopsi dalam beberapa proposal untuk menghindari interferensi antar aliran [ 13 , 14 ]. Rute ini memberikan kinerja dan keandalan yang lebih baik, tetapi jalur terpisah mungkin tidak tersedia untuk semua aliran. Pendekatan berbasis posisi memfasilitasi distribusi jalur tetapi memerlukan informasi tentang lokasi geografis node, yang mungkin tidak selalu tersedia atau mungkin memiliki akurasi terbatas, misalnya, di daerah perkotaan atau lingkungan dalam ruangan [ 15 , 16 ].

Pendekatan berbasis heuristik yang memperhitungkan interferensi aliran dari berbagai sumber biasanya mengabaikan efek pengkodean video, yang dapat menghasilkan aliran dengan bitrate berbeda [ 6 , 7 ]. Dalam karya ini, kami fokus pada jenis pendekatan ini, khususnya pada FITPATH ​​dan QSOpt, yang menuntut arsitektur untuk memantau dan memperoleh pandangan global dari topologi yang berfungsi sebagai masukan untuk heuristik.

Tabel 1 merangkum berbagai mekanisme pemilihan multipath untuk transmisi video nirkabel. Mekanisme-mekanisme tersebut diklasifikasikan berdasarkan penemuan rute, pendekatan algoritma, dan metrik perutean, yang dijelaskan secara lebih rinci di bawah ini.

TABEL 1. Pendekatan terkini pemilihan multijalur.

Mekanisme transmisi video yang tahan kesalahan (ERVT) [ 17 ] menerapkan versi yang diperluas dari protokol perutean AOMDV [ 20 ] di mana dua jalur terpisah terbaik menurut metrik jumlah hop minimum dipilih untuk setiap sumber, sementara yang lain dianggap sebagai jalur cadangan. Pendekatan ini mengasumsikan keberadaan jalur dengan node terpisah untuk setiap sumber. Namun, asumsi ini tidak selalu benar, terutama untuk skenario dengan beberapa sumber video.

Cross-layer multipath routing (CLMR) [ 18 ] juga didasarkan pada protokol reaktif yang dimulai dengan membanjiri permintaan rute untuk mendapatkan total biaya untuk setiap jalur. Ini bertujuan untuk meningkatkan QoS dan meminimalkan konsumsi energi dengan mengukur biaya jalur dengan bobot parameter untuk mengendalikan pentingnya penundaan, rasio pengiriman paket, dan metrik energi. Namun, parameter ini didefinisikan secara offline dan dikonfigurasi secara statis yang membuat metode ini tidak cocok untuk layanan video dinamis.

Protokol routing streaming video real-time (RTVP) [ 19 ] mengusulkan pendekatan pemilihan jalur berdasarkan struktur geografis dalam bentuk korona , di mana jaringan dibagi menjadi beberapa wilayah, korona, dibatasi oleh serangkaian keliling dengan radius tertentu yang berpusat di simpul tujuan. Setiap simpul diberi tingkat korona menurut posisinya di wilayah ini. Jadi, jalur dipilih dengan meneruskan paket hop-by-hop dari sumber yang memiliki tingkat korona tinggi ke simpul tujuan, yang memiliki tingkat korona nol, dengan tujuan menghindari simpul yang berbagi jalur yang sama. Pendekatan ini memperhitungkan mobilitas simpul karena tingkat korona menyesuaikan diri menurut posisi simpul, tetapi, tergantung pada struktur korona, pendekatan ini mungkin memilih jalur panjang dengan jumlah hop yang tinggi.

Perencanaan transmisi multimedia multipath berorientasi QoS (Q-MMTP) [ 16 ] mengusulkan mekanisme pemilihan multipath menggunakan model matematika Spline untuk memperkirakan serangkaian posisi ideal untuk node. Hasilnya, ia menghasilkan serangkaian interpolasi antara posisi sumber dan tujuan. Dengan demikian, jalur dipilih sesuai dengan jarak antara node dan posisi ideal. Meskipun Q-MMTP menyediakan keseimbangan beban yang memadai untuk beberapa aliran, ia tidak mendukung beberapa sumber dan strateginya bergantung pada posisi geografis node.

3.2.1 QSOpt
Algoritma perutean suboptimal yang mendukung QoE (QSOpt) [ 7 ] merumuskan masalah pemilihan multipath menggunakan pemrograman linier integer campuran dan mengimplementasikan heuristik untuk menemukan solusi yang mencoba memaksimalkan QoE. Untuk mengevaluasi QoE, fungsi diskrit diusulkan untuk menentukan pemetaan antara kehilangan paket dan metrik QoE. Sementara algoritma terpusat memberikan solusi yang layak untuk meningkatkan pemanfaatan sumber daya serta QoE, model QSOpt tidak dapat diskalakan dan membutuhkan sumber daya komputasi yang signifikan karena jumlah aliran meningkat. Ia juga mengasumsikan laju transmisi yang identik untuk semua aliran, terlepas dari karakteristik pengkodean video, yang memengaruhi tingkat interferensi dan akibatnya kemampuannya untuk menemukan solusi yang baik, ketika sumber menggunakan bitrate video yang beragam.

Untuk memperkirakan kehilangan paket, QSOpt membahas pengukuran packet error rate (PER) dalam jaringan mesh nirkabel menggunakan pesan probe proaktif, yang dikirimkan secara berkala untuk memeriksa status tautan dan node yang berdekatan dalam jaringan. Meskipun studi ini menyajikan berbagai metode untuk memperkirakan PER dengan akurasi tinggi, studi ini mengasumsikan bahwa nilai PER diperoleh sebelum metode pemilihan dilakukan dan tidak diperbarui selama transmisi aliran video.

3.2.2 JALUR KESESUAIAN
FITPATH ​​[ 6 ] adalah mekanisme yang berdasarkan metaheuristik pencarian lokal berulang (ILS) [ 21 ] yang memilih jalur untuk setiap aliran video yang dihasilkan dari beberapa sumber. Komponen utama FITPATH ​​ditunjukkan pada Gambar 4 . FITPATH ​​memerlukan dua jenis informasi masukan: (i) topologi jaringan, yang terdiri dari tautan yang tersedia dan biayanya masing-masing, dihitung dengan metrik jumlah transmisi yang diharapkan (ETX) [ 22 ], dan (ii) persyaratan aliran video, yang terdiri dari pengenal sumber dan penerima akhir masing-masing, serta bitrate target encoder untuk setiap aliran video.

GAMBAR 4

Singkatnya, FITPATH ​​menghasilkan, untuk setiap aliran, satu set jalur kandidat dengan biaya ETX terendah berdasarkan algoritma Yen [ 23 ]. Selanjutnya, komponen ILS menerapkan algoritma pencarian iteratifnya dan mengevaluasi setiap solusi di antara jalur kandidat menggunakan penaksir kinerja yang sadar multimedia (MAPE) [ 24 ], penaksir kinerja jaringan berdasarkan simulasi deterministik yang menyediakan estimasi waktu nyata dari throughput, penundaan, dan kehilangan paket, dengan mempertimbangkan interferensi antar aliran. Dengan demikian, FITPATH ​​membuat keputusan perutean yang menyediakan throughput yang lebih tinggi untuk aliran video heterogen, yaitu aliran dengan laju bit berbeda yang ditransmisikan secara bersamaan.

Dalam [ 6 ] dan [ 24 ], kinerja FITPATH ​​dievaluasi dibandingkan dengan mekanisme yang disajikan di atas. Di antara ini, FITPATH ​​dan QSOpt menonjol, masing-masing, mencapai metrik QoE pengguna terbaik dan terbaik kedua di sebagian besar skenario yang dievaluasi dalam [ 6 ] dan [ 24 ]. Meskipun FITPATH ​​dan QSOpt berasumsi bahwa tampilan topologi jaringan saat ini diperoleh secara proaktif oleh node yang bertanggung jawab untuk pemilihan rute, penting untuk menyoroti bahwa dalam percobaan studi yang diterbitkan dalam [ 6 ] dan [ 7 ], setelah jalur dipilih berdasarkan topologi awal, hanya aliran video yang ditransmisikan, tanpa adanya aliran kontrol topologi. Namun, dalam skenario yang realistis, aliran kontrol harus ditransmisikan bersama dengan aliran video untuk menjaga topologi terus diperbarui. Ini akan memungkinkan perubahan rute untuk secara otomatis ditetapkan oleh mekanisme pemilihan multipath jika terjadi perubahan signifikan dalam topologi, seperti penurunan kualitas, kerusakan tautan, atau kegagalan pada node perantara.

Karena kedua penyeleksi multijalur, FITPATH ​​dan QSOpt, mempertimbangkan interferensi antara aliran dalam solusinya, jika ada permintaan video dari lebih dari satu stasiun pengawasan, persyaratan video dari setiap stasiun pengawasan harus dipertimbangkan oleh stasiun lainnya. Untuk tujuan ini, persyaratan video dapat disebarkan dengan cara yang mirip dengan mekanisme penyebaran topologi, yang disajikan secara rinci di Bagian 3.3 .

3.3 Pemantau Topologi
Pemantauan topologi yang disajikan dalam karya ini didasarkan pada protokol routing status tautan (OLSR) yang dioptimalkan [ 25 ], tetapi tanpa menggunakan teknik relai multititik (MPR). Prosesnya dilakukan dalam tiga tahap: (i) menemukan node tetangga (yaitu, yang dapat dijangkau melalui tautan langsung) dan menghitung biaya tautan masing-masing, (ii) menyebarkan informasi lokal ke node lain dalam jaringan, dan (iii) memantau kondisi topologi yang dapat menyebabkan penurunan kualitas tautan.

Penemuan tetangga dilakukan oleh setiap node dengan menyiarkan paket HELLO secara berkala. Saat sebuah node menerima paket HELLO, node tersebut mengidentifikasi node asal dan mengenalinya sebagai tetangga. Biaya tautan diimplementasikan dengan metrik ETX, yang digunakan oleh FITPATH ​​dan QSOpt untuk pemilihan jalur.

Untuk mendapatkan ETX dari sebuah link, ketika sebuah node menerima paket HELLO, maka node tersebut akan memperbarui jendela geser dari hasil paket terakhir.
HELLO dari tetangga tersebut. Berdasarkan hal tersebut, simpul penerima menghitung kualitas tautan (LQ) sebagai persentase paket HELLO yang berhasil diterima dari tetangga tersebut dalam jendela geser. Untuk mendeteksi penerimaan atau kehilangan paket HELLO, simpul penerima memantau nomor urut HELLO. Pada gilirannya, LQ terkini untuk setiap tetangga yang diketahui saat ini ditambahkan ke paket HELLO yang dikirimkan oleh setiap simpul. Ketika simpul tetangga menerima HELLO tersebut, simpul tersebut mencari entri masing-masing, membaca nilai LQ, dan memperlakukannya sebagai kualitas tautan tetangga (NLQ). Oleh karena itu, proses tersebut konvergen ke setiap simpul yang mengetahui persentase jendela geser dari HELLO yang berhasil diterima di setiap arah (LQ dan NLQ) dari tautan yang dibuat dengan setiap tetangganya.

Saat informasi lokal dipelajari, node menyebarkan pandangan mereka tentang lingkungan mereka sendiri ke node lain melalui paket kontrol topologi (TC) periodik. Saat paket TC diterima oleh node, node menyimpan informasi dalam struktur data topologi global, dan pesan tersebut kemudian dikirim ulang dalam bentuk siaran, yang secara efektif menghasilkan banjir pada setiap TC. Untuk menghindari kelebihan beban jaringan, node melacak nomor urut paket TC yang telah mereka teruskan, yang mengendalikan banjir. Dengan demikian, node hanya menyimpan dan mengirim ulang informasi paket TC jika nomor urut paket yang diterima lebih besar daripada nomor urut yang disimpan sebelumnya untuk node sumber masing-masing.

Jika node tertentu gagal, node tetangganya akan berhenti menerima paket HELLO dan akibatnya akan berhenti memperbarui jendela geser LQ masing-masing, yang mengakibatkan informasi terhenti. Untuk mengatasinya, ambang batasNdari kehilangan paket HELLO berturut-turut diadopsi untuk pembaruan jendela geser. Jika tidak ada HELLO yang diterima dari tetangga tertentu dalam periode yang setara dengan transmisiNPaket HELLO, sebuah node akan menganggap tetangganya telah gagal dan mengecualikan jendela geser yang sesuai dari tampilan topologi lokal.

Ambang batas yang serupaMKehilangan paket TC berturut-turut didefinisikan untuk pembaruan topologi global. Dalam kasus ini, jika sebuah node tidak menerima paket TC dari sumber tertentu selama periode yang setara dengan transmisiMpaket TC yang berurutan, sumbernya akan dianggap gagal dan node akan mengecualikan sumber tersebut dari tampilan topologi globalnya.

Tabel 2 menyajikan parameter yang dapat dikonfigurasi dari protokol pemantauan topologi, deskripsinya, dan nilai yang digunakan dalam evaluasi kami.

TABEL 2. Parameter protokol monitor topologi.

Nilai-nilai ini adalah tipikal untuk protokol proaktif, seperti OLSR [ 25 ], dan dipilih karena kesesuaiannya dalam topologi yang dipertimbangkan dalam studi ini, bukan untuk mengoptimalkan solusi yang diusulkan. Fokus di sini adalah pada mencerminkan konfigurasi yang selaras dengan pengaturan operasional yang realistis. Pekerjaan di masa mendatang mungkin fokus pada mempelajari potensi untuk mengoptimalkan nilai-nilai ini, khususnya mengenai penyesuaian interval paket untuk mengurangi overhead. Namun, perubahan tersebut akan memerlukan analisis terperinci untuk mengevaluasi dampaknya pada kinerja dan stabilitas perutean dalam skenario dinamis.

4 Metodologi Evaluasi
Arsitektur yang diusulkan diimplementasikan dalam simulator jaringan NS-3 [ 26 ]. Eksperimen kami dilakukan pada server khusus dengan prosesor Intel i7-860 2,8 GHz dan RAM 32 GB. Skenario aplikasi memodelkan sistem pengawasan video yang diimplementasikan di daerah perkotaan, di mana sumber video secara bersamaan mengirimkan aliran ke satu stasiun pengawasan.

Pada setiap simulasi, 59 node ditempatkan secara acak dalam jarak 300 m
Wilayah 300 m, terpisah satu sama lain dengan jarak minimal 5 m, dengan jangkauan transmisi 100 m. Selain itu, simpul tujuan ditetapkan di titik puncak wilayah, pada koordinat (300, 300) dalam meter, dengan total 60 simpul. Simpul tambahan, yang sesuai dengan sumber pembangkit video, diposisikan di antara sepuluh koordinat berikut dalam meter: (0, 0), (0, 50), (0, 100), (0, 150), (0, 200), (50, 0), (100, 0), (150, 0), (200, 0), dan (50, 50). Standar IEEE 802.11g dengan laju transmisi lapisan tautan tetap sebesar 18 Mb/s diadopsi pada lapisan MAC (Medium Access Control). Pada lapisan fisik, model propagasi Cost231 [ 27 ] pada 2,4 GHz digunakan untuk mereplikasi kondisi lingkungan perkotaan. Parameter ini sama dengan yang digunakan dalam penelitian oleh [ 6 ] untuk FITPATH ​​dan QSOpt.

Kerangka kerja Evalvid [ 28 ] digunakan untuk menghasilkan lalu lintas video yang realistis untuk simulasi. Ini menghasilkan lalu lintas yang sesuai dengan klip video tertentu dan mencakup alat untuk mendekode dan mengukur kualitas video yang dikirimkan ke penerima. Berbagai rangkaian video yang berisi adegan dengan tingkat gerakan yang berbeda digunakan untuk mereproduksi keragaman lalu lintas video di lingkungan yang kompleks, seperti kota pintar. Untuk itu, percobaan menggunakan klip video yang umum digunakan, tersedia untuk umum, yang dikenal sebagai “Hall Monitor” dan “Coastguard” [ 29 ], yang mewakili adegan dengan tingkat kompleksitas gerakan yang berbeda: rendah dan tinggi, masing-masing. Klip video dikonversi ke format H.264 dengan kecepatan 30 bingkai per detik. Kami bereksperimen dengan beban yang ditawarkan berbeda untuk setiap tingkat gerakan adegan video. Beban yang ditawarkan didefinisikan sebagai jumlah bitrate dari semua aliran yang ditransmisikan secara bersamaan, dengan mempertimbangkan kecepatan rata-rata yang digunakan sebagai target untuk enkoder video. Secara khusus, percobaan kami terdiri dari beban yang ditawarkan yang bervariasi dari 1 hingga 4 Mb/s.

Lalu lintas video dihasilkan menggunakan kombinasi lima laju penyandian video target yang berbeda: 256 kb/s, 512 kb/s, 1 Mb/s, dan 1,5 Mb/s, untuk merepresentasikan berbagai tingkat resolusi video. Di sumber video, aliran diarahkan sesuai dengan strategi yang ditetapkan oleh masing-masing mekanisme pemilihan multijalur yang dievaluasi (FITPATH ​​dan QSOpt) menggunakan teknik penyandian video LC atau MDC. Buffer pemutaran 1000 ms digunakan untuk mengurangi potensi paket yang tidak berurutan; paket dengan penundaan yang melebihi 1000 ms dibuang di dekoder. Dalam semua simulasi, mekanisme pemilihan multijalur diinisialisasi pada 400 detik dari awal simulasi, menggunakan tampilan topologi yang dihitung hingga saat itu. Nilai yang ditetapkan untuk parameter monitor topologi tercantum dalam Tabel 2 .

Parameter jaringan dan aplikasi yang digunakan dalam simulasi tercantum dalam Tabel 3. Parameter ini dipilih untuk mencerminkan kondisi penyebaran yang realistis, mensimulasikan kepadatan dan posisi kamera yang umumnya diperlukan untuk pemantauan perkotaan yang efektif. Secara khusus, wilayah yang disimulasikan mewakili area yang setara dengan sekitar 3×3 blok kota, dengan sekitar 8 kamera yang didistribusikan di sepanjang setiap jalan.

TABEL 3. Parameter simulasi.

4.1 Metrik Evaluasi
Kami mengevaluasi overhead yang terkait dengan pemantauan topologi yang diusulkan dalam hal kinerja jaringan dan QoE pengguna. Kinerja jaringan dievaluasi menggunakan statistik throughput, kehilangan paket, penundaan ujung ke ujung, dan pemanfaatan jaringan. Throughput dihitung sebagai rasio antara jumlah paket yang dikirim ke tujuan dan durasi aliran. Penundaan ujung ke ujung adalah interval waktu antara saat paket ditransmisikan oleh node sumber dan saat paket tersebut dikirimkan ke tujuan, dirata-ratakan dari semua paket yang dikirimkan. Kehilangan paket dihitung sebagai persentase paket yang ditransmisikan yang tidak dikirimkan ke tujuan, dan pemanfaatan jaringan didasarkan pada hunian antrean node yang dirata-ratakan selama waktu simulasi—khususnya, kami melaporkan hunian antrean rata-rata tertinggi di antara semua node.

Kualitas video yang diterima dievaluasi menggunakan ukuran indeks kesamaan struktural (SSIM) dan rasio sinyal terhadap derau puncak (PSNR). Kedua metrik tersebut telah digunakan secara luas untuk mengukur QoE pengguna [ 30 ]. SSIM mengukur distorsi struktural video. Ini menggabungkan luminansi, kontras, dan kesamaan struktural bingkai untuk membandingkan bingkai yang dikirim (mungkin terdistorsi) dengan yang asli. Nilai SSIM berkisar dari 0 hingga 1, di mana 1 berarti kualitas maksimum. PSNR, diukur dalam dB, dihitung sebagai kesalahan bingkai demi bingkai antara video asli dan yang dikirim. Nilai PSNR cenderung meningkat seiring dengan peningkatan kualitas video. Selain itu, kami mengevaluasi kehilangan bingkai video, dihitung sebagai persentase bingkai yang dikirim yang tidak didekodekan di tujuan karena penundaan atau kehilangan paket. Lebih jauh lagi, kami menganalisis gambar bingkai video yang diterima untuk menunjukkan dampak nyata pada persepsi pengguna.

5 Hasil Eksperimen
Dua percobaan dilakukan dengan tujuan (i) mengevaluasi dampak pesan kontrol pada kinerja jaringan dan kualitas video dan (ii) menganalisis evolusi kualitas video yang diterima, melalui contoh, dalam konteks mengoptimalkan solusi multipath dan mengubah topologi jika terjadi kegagalan tautan.

5.1 Dampak Pesan Kontrol Topologi pada Kinerja Jaringan
Eksperimen kinerja jaringan membandingkan transmisi video FITPATH ​​dan QSOpt dengan dan tanpa paket kontrol (wHTC dan woHTC) pada skenario adegan dengan gerakan tinggi dan rendah. Kami mengamati perbedaan signifikan dalam throughput, kehilangan paket, dan penundaan pada berbagai tingkat beban yang ditawarkan. Perbedaan ini dapat dijelaskan oleh beban tambahan yang dibebankan paket kontrol pada jaringan, yang menyebabkan peningkatan kemacetan dan penurunan kinerja, terutama dalam kondisi adegan dengan gerakan tinggi.

Gambar 5 dan Gambar 6 menunjukkan kinerja jaringan untuk adegan dengan gerakan rendah menggunakan pengodean video MDC dan adegan dengan gerakan tinggi menggunakan pengodean video LC. Sementara dampak paket kontrol khususnya terlihat dalam adegan video dengan gerakan tinggi, di mana adegan berubah dengan cepat dan jaringan mengalami lalu lintas yang tidak beraturan, dampak pesan kontrol topologi juga signifikan dalam adegan dengan gerakan rendah. Perhatikan bahwa FITPATH ​​dan QSOpt dipengaruhi oleh lalu lintas yang dihasilkan oleh pesan kontrol.

GAMBAR 5

GAMBAR 6

Baik dalam adegan dengan gerakan tinggi maupun rendah, lalu lintas yang dihasilkan oleh paket kontrol mengurangi throughput. Ini menunjukkan bahwa paket kontrol mengonsumsi sebagian dari bandwidth yang tersedia yang cukup tinggi untuk memengaruhi aliran video. Perbedaan throughput menjadi lebih jelas dalam skenario dengan beban yang ditawarkan lebih tinggi. Kehilangan paket juga lebih tinggi dengan paket kontrol dalam skenario gerakan tinggi maupun rendah dan, seperti yang diharapkan, lalu lintas kontrol tambahan berkontribusi pada peningkatan pemanfaatan jaringan. Karena jaringan menjadi lebih padat dengan paket kontrol, kemungkinan kehilangan paket video meningkat, yang disebabkan oleh volume lalu lintas data yang tinggi yang terkait dengan beban yang lebih tinggi yang ditawarkan. Peningkatan penundaan juga dapat dijelaskan oleh tingkat kemacetan yang lebih tinggi yang disebabkan oleh paket kontrol, yang mengakibatkan waktu tunggu antrean yang lebih lama dan lebih banyak perebutan untuk penggunaan media nirkabel bersama.

5.2 Dampak Pesan Kontrol Topologi pada Kualitas Video

Kami mengevaluasi kualitas transmisi video untuk adegan dengan gerakan tinggi dan rendah pada berbagai tingkat beban yang ditawarkan, menurut rute yang dipilih oleh FIPATH dan QSOpt dengan dan tanpa paket kontrol (wHTC dan woHTC). 1 Gambar 7 dan 8 menunjukkan hasil untuk adegan dengan gerakan tinggi dan rendah, masing-masing. Seperti yang diharapkan, ketiga metrik kualitas video yang dievaluasi—SSIM, PSNR, dan Frame Loss—menunjukkan penurunan saat bitrate dan kompleksitas gerakan meningkat. Baik FITPATH ​​maupun QSOpt mengungkapkan penurunan kualitas yang signifikan dalam skenario gerakan tinggi.

GAMBAR 7

GAMBAR 8

Namun, hasil tersebut juga menunjukkan bahwa kualitas video yang diterima menurun tidak hanya dengan peningkatan beban yang ditawarkan dan mobilitas adegan dalam video, tetapi juga dengan persaingan pesan kontrol, terlepas dari mekanisme pemilihan jalur yang digunakan (FITPATH ​​atau QSOpt). Hal ini khususnya terlihat untuk eksperimen dengan beban yang ditawarkan sebesar 2 Mb/s: tanpa lalu lintas kontrol, kehilangan bingkai video relatif rendah baik dalam adegan dengan gerakan rendah maupun tinggi (yaitu, di bawah 10%); ketika lalu lintas kontrol ditambahkan, kehilangan meningkat dalam kedua skenario (sekitar 30% untuk adegan dengan gerakan rendah dan 35% untuk adegan dengan gerakan tinggi), yang menyebabkan penurunan signifikan dalam SSIM maupun PSNR.

Peningkatan dalam kehilangan bingkai ini juga terjadi dalam simulasi dengan beban yang ditawarkan sebesar 1 dan 4 Mb/s, tetapi tidak terlalu kentara. Untuk beban 1 Mb/s, pemanfaatan jaringan relatif rendah (lihat Gambar 5 ) dan jaringan masih memiliki kapasitas yang cukup untuk mempertahankan lalu lintas kontrol yang ditambahkan. Sebaliknya, untuk beban 4 Mb/s, pemanfaatan jaringan sudah jauh lebih tinggi, bahkan tanpa lalu lintas kontrol, yang menunjukkan bahwa jaringan tidak mampu mengatasi lalu lintas video sendirian. Untuk beban 2 Mb/s, jaringan mendekati titik jenuh dan, oleh karena itu, menambahkan lalu lintas kontrol menyebabkan penurunan yang jauh lebih substansial pada kinerja yang dirasakan. Untuk pemandangan mobilitas tinggi yang lebih menuntut, penurunan itu menghasilkan kualitas video yang cukup buruk untuk beban yang ditawarkan sebesar 2 Mb/s.

Akhirnya, kami menganalisis penurunan kualitas visual yang disebabkan oleh paket kontrol, dengan fokus pada adegan dengan gerakan tinggi dan gerakan rendah. Gambar 9 mengilustrasikan dampak penurunan tersebut pada bingkai yang dipilih dari setiap adegan. Untuk video dengan gerakan tinggi, perubahan adegan yang cepat dan peningkatan lalu lintas data memperburuk efek kehilangan dan penundaan paket, yang menyebabkan penurunan kualitas bingkai yang lebih nyata. Pemirsa mengalami tingkat penurunan bingkai dan artefak yang lebih tinggi, yang mengurangi pengalaman menonton secara keseluruhan. Sebaliknya, video dengan gerakan rendah, meskipun masih terpengaruh oleh paket kontrol, menunjukkan penurunan yang tidak terlalu parah. Adegan yang relatif stabil dan kecepatan data yang lebih rendah mengurangi beberapa efek buruk, menghasilkan lebih sedikit penurunan bingkai dan kualitas keseluruhan yang lebih baik dibandingkan dengan video dengan gerakan tinggi. Eksperimen ini menggarisbawahi pengaruh penting paket kontrol pada kualitas video, khususnya dalam adegan dinamis dengan gerakan tinggi, di mana menjaga kualitas lebih menantang.

GAMBAR 9

5.3 Kinerja QoE dan Evolusi ETX dalam Routing Dinamis
Transmisi video dilakukan secara simultan oleh dua sumber, masing-masing dikodekan pada 512 kb/s dan terletak pada koordinat (0, 50) dan (50, 0). Dari setiap sumber, 9000 bingkai klip video ditransmisikan menggunakan pengodean video LC dan buffer pemutaran 1000 ms. Topologi dihitung hingga 400 detik, setelah itu transmisi dilanjutkan sepanjang solusi jalur awal yang dihasilkan oleh FITPATH. Setelah batas waktu eksekusi heuristik 60 detik, solusi akhir diturunkan, dan mulai 460 detik seterusnya, lalu lintas aliran video dirutekan melalui solusi baru ini. Jalur yang dihasilkan oleh FITPATH ​​untuk topologi 60 simpul ditunjukkan pada Gambar 10. Dapat diamati bahwa, tidak seperti solusi akhir, yang mempertimbangkan interferensi antaraliran, solusi awal tidak memperhitungkan interferensi ini dan secara konsisten menghasilkan jalur yang sama (yang memiliki ETX terpendek) untuk semua aliran yang ditransmisikan oleh sumber yang sama.

GAMBAR 10

Gambar 11a mengilustrasikan QoE rata-rata, diukur dalam SSIM, untuk bingkai video yang dikirimkan selama 30 detik terakhir. Pada 460 detik, QoE rata-rata video yang dikirimkan oleh sumber 2 melalui solusi awal adalah 0,93, sedangkan QoE rata-rata video yang dikirimkan oleh sumber 2 melalui solusi akhir, pada 490 dan 520 detik, adalah 0,94, yang menunjukkan peningkatan sebesar 1% dibandingkan dengan solusi sebelumnya. Sebaliknya, QoE rata-rata video yang dikirimkan oleh sumber 1 tetap stabil pada 0,94 untuk solusi awal dan akhir. Pada 540 detik, simpul 11 ​​mengalami kegagalan, yang menyebabkan penurunan signifikan pada QoE video yang dikirimkan oleh sumber 1. Kegagalan ini diidentifikasi oleh monitor topologi pada 575 detik, karena batas waktu untuk memperbarui informasi topologi melalui pesan TC telah tercapai. Setelah perubahan topologi, mekanisme pemilihan jalur memulai pencarian solusi baru dan segera membangun kembali perutean menggunakan solusi awal yang baru. Gambar 12 menunjukkan solusi baru setelah perubahan topologi karena kegagalan simpul 11. Perhatikan bahwa dalam solusi awal pasca-kegagalan, semua jalur yang dihasilkan menggunakan tautan16-> 0Namun, dalam solusi pasca-kegagalan akhir, aliran video dari sumber 2 sepenuhnya terpisah dari aliran yang berasal dari sumber 1, karena interferensi antara aliran telah diperhitungkan selama pengoptimalan rute.

GAMBAR 11

GAMBAR 12

Pada Gambar 11a , dapat diamati bahwa QoE rata-rata dari video yang ditransmisikan oleh sumber 2 melalui solusi pasca-kegagalan awal pada 640 detik adalah 0,91. Sebaliknya, QoE rata-rata dari video yang ditransmisikan oleh sumber 2 melalui solusi pasca-kegagalan akhir pada 670 dan 700 detik adalah 0,94, yang menunjukkan peningkatan 3% dibandingkan solusi sebelumnya. Sementara itu, QoE rata-rata dari video yang ditransmisikan oleh sumber 1 tetap konsisten pada 0,94 untuk solusi awal dan akhir setelah kegagalan.

Evolusi metrik perutean ETX dari waktu ke waktu ditunjukkan pada Gambar 11b . Dapat dilihat bahwa, meskipun aliran dari sumber 2 meningkat saat rute beralih dari solusi awal ke solusi akhir (baik sebelum dan sesudah kegagalan), tren kenaikan ETX ini tidak menyebabkan penurunan QoE video yang diterima. Sebaliknya, QoE membaik dengan transmisi yang dilakukan melalui solusi jalur yang dioptimalkan oleh FITPATH. Sementara kegagalan node 11 berdampak negatif pada QoE video yang dikirimkan oleh sumber 1 selama interval antara terjadinya kegagalan dan pendeteksiannya oleh monitor topologi, perlu dicatat bahwa setelah pembentukan jalur baru, peningkatan ETX yang terkait dengan rute baru tidak berdampak buruk pada QoE video yang diterima.

Gambar 13 mengilustrasikan evolusi ETX dari waktu ke waktu untuk rute yang sama, tetapi dalam contoh ini, hanya memperhitungkan aliran kontrol. Karena tidak ada aliran video yang ada pada rute ini, nilai ETX cenderung tetap stabil untuk setiap rute.

GAMBAR 13

Seperti yang ditunjukkan pada Gambar 11b , ada kecenderungan ETX meningkat pada setiap rute karena transmisi aliran video. Peningkatan ETX ini dapat memengaruhi penentuan jalur baru jika mekanisme pemilihan jalur dipanggil. Awalnya, tautan tersebut secara eksklusif dikenakan lalu lintas kontrol, yang menghasilkan nilai ETX yang lebih rendah yang mendukung pemilihannya. Namun, dengan peningkatan ETX berikutnya, tautan ini dapat diabaikan oleh mekanisme pemilihan jalur saat mengidentifikasi rute baru. Eksperimen ini disajikan dengan cara didaktik, namun, berbagai skenario kegagalan lainnya juga disimulasikan, menghasilkan perilaku yang analog dengan yang diamati dalam eksperimen awal. Ini menggambarkan kemampuan arsitektur untuk beradaptasi dengan kegagalan dan memulihkan QoE pengguna secara efektif.

5.4 Diskusi
Protokol tradisional seperti OLSR [ 25 ] dan AODV [ 20 ] menyediakan kerangka kerja yang andal untuk memelihara topologi jaringan, tetapi tidak menyediakan dukungan untuk mekanisme pemilihan jalur yang difokuskan pada QoE pengguna. Literatur yang ada tentang pemilihan multipath untuk aplikasi video, yang dirinci dalam Bagian 3.2 , terutama berfokus pada pengembangan mekanisme pemilihan jalur tingkat lanjut [ 31 ]. Mekanisme tersebut berfokus pada model throughput dan QoE, yang menunjukkan kemajuan dalam menangani beberapa sumber dan interferensi aliran. Meskipun studi ini meningkatkan QoE, studi ini umumnya mengabaikan pemantauan topologi dan dinamika jaringan. Arsitektur dan monitor topologi yang disajikan dalam karya-karya ini tidak menyediakan informasi terperinci dan tepat waktu yang dibutuhkan untuk algoritma pemilihan jalur yang dioptimalkan. Proposal kami menyajikan pendekatan terintegrasi di mana protokol pemantauan topologi disesuaikan untuk pemilihan rute, yang lebih memenuhi tuntutan aplikasi spesifik transmisi video.

Merangkum temuan utama dari setiap percobaan yang dilakukan dalam studi ini, hasilnya menunjukkan (i) dampak pesan kontrol: Pesan kontrol diperlukan untuk mempertahankan tampilan topologi dalam lingkungan yang dinamis, meskipun penting, berdampak pada QoE. (ii) Kemampuan beradaptasi terhadap perubahan jaringan: Arsitektur yang diusulkan menunjukkan kemampuan beradaptasi terhadap perubahan jaringan, menyesuaikan jalur untuk mempertahankan QoE meskipun terjadi peningkatan ETX selama transmisi video. (iii) Efektivitas mekanisme pemilihan jalur: Mekanisme pemilihan jalur FITPATH ​​dan QSOpt dengan informasi topologi yang memadai, dapat mengidentifikasi jalur yang menyeimbangkan kebutuhan kapasitas dan interferensi aliran. Kami berpendapat bahwa mekanisme tersebut harus memperhitungkan permintaan lalu lintas kontrol untuk meningkatkan QoE selama pemilihan jalur.

6 Kesimpulan dan Pekerjaan Masa Depan
Makalah ini memperkenalkan arsitektur jaringan nirkabel terdesentralisasi yang memungkinkan pengujian fungsionalitas mekanisme pemilihan multijalur untuk video IoT dalam skenario yang lebih realistis, yang memerlukan pandangan menyeluruh terhadap topologi. Arsitektur ini dapat memberikan dukungan dinamis untuk perutean dalam menghadapi perubahan signifikan dalam topologi, variasi dalam persyaratan video, dan pengoptimalan rute melalui mekanisme pemilihan jalur.

Percobaan kami menunjukkan dampak paket kontrol pada kinerja jaringan dan kualitas video, terutama dalam skenario adegan dengan gerakan tinggi, karena kualitas video menurun seiring dengan peningkatan bitrate dan kompleksitas gerakan. Hasilnya juga menunjukkan bahwa bahkan dengan nilai ETX yang lebih tinggi selama transmisi video, arsitektur yang diusulkan secara efektif beradaptasi dengan perubahan jaringan sambil mempertahankan QoE, yang menunjukkan pentingnya pemantauan topologi untuk transisi perutean dinamis.

Mekanisme yang dievaluasi, FITPATH ​​dan QSOpt, menerima permintaan lalu lintas aliran video sebagai masukan dan mencoba mengalokasikan jalur yang mampu menyediakan kapasitas yang cukup untuk mengatasinya—bahkan dengan mempertimbangkan tingkat interferensi yang akan disebabkan oleh setiap aliran pada aliran lainnya. Namun, dalam hasil dengan lalu lintas kontrol, paket HELLO dan TC merupakan permintaan lalu lintas tambahan yang tidak diketahui oleh algoritme pemilihan jalur, yang mungkin menjelaskan penurunan tajam dalam kualitas video. Dengan demikian, strategi yang mungkin untuk mengurangi kerugian QoE yang disebabkan oleh aliran kontrol yang ditambahkan adalah dengan memberi tahu algoritme pemilihan jalur tentang laju aliran ini, selain laju aliran video. Dalam hal itu, semua aliran—video dan kontrol—dapat dipertimbangkan dalam proses pemilihan rute dan, jika ada serangkaian rute yang dapat mengatasi permintaan agregat itu, mudah-mudahan, algoritme pemilihan jalur akan dapat menemukannya.

Pekerjaan selanjutnya akan difokuskan pada pengajuan arsitektur kontrol terpusat berbasis SDN dan pelaksanaan pengujian ekstensif mekanisme pemilihan multijalur dalam skenario perutean dinamis. Skenario ini akan mencakup kondisi seperti kegagalan node, integrasi node baru ke dalam jaringan, dan layanan video adaptif, termasuk perubahan dalam resolusi video dan status aktivasi kamera. Selain itu, mereproduksi evaluasi ini pada tempat pengujian yang sebenarnya akan memberikan wawasan lebih jauh tentang kinerja dan skalabilitas arsitektur yang diajukan, sehingga menawarkan penilaian yang lebih realistis tentang efektivitasnya dalam penerapan praktis.

Ucapan Terima Kasih
Biaya Pemrosesan Artikel untuk publikasi penelitian ini didanai oleh Coordenação de Aperfeiçoamento de Pessoal de Nível Superior – Brasil (CAPES) (pengidentifikasi ROR: 00x0ma614).