Một phương pháp đảm bảo chất lượng cho dịch vụ truyền thông đa hướng thời gian thực qua mạng IP

trong phạm vi từ 0,5 đến 4,5 với giá trị gần mức 4,5 biểu hiện chất lượng tín hiệu phát thanh nhận được là rất tốt và giá trị gần mức 0,5 biểu hiện chất lượng tín hiệu phát thanh nhận được là rất tồi. PESQ là thuật toán đo đạc từ đầu cuối đến đầu cuối kết hợp, yêu cầu tín hiệu tham chiếu, nên chỉ có thể tiên đoán được chất lượng tín hiệu phát thanh thu nhận theo một chiều. Do đó, việc đo đạc độ trễ không thể tiếp cận khi chỉ sử dụng thuật toán PESQ. Hình 3. 7: Cấu trúc thực hiện thuật toán PESQ 3.3.2.2 Đánh giá chất lượng theo mô hình E-model Mô hình E-model [3] không yêu cầu tín hiệu tham chiếu, thích hợp cho theo dõi chất lượng lưu lượng trực tuyến. Việc đánh giá chất lượng của thuật toán PESQ được thực hiện sau tiến trình giải mã, E-model thông thường được thiết lập sau bộ đệm tái tạo và trước các kỹ thuật che giấu/sửa lỗi. Do đó, độ chính xác của E-model có thể không cao khi tỷ lệ tổn thất gói tăng. Ngoài ra, các công thức của E-model đánh giá tỷ lệ tổn thất cho các phương thức mã hóa/giải mã khác nhau dựa trên kết quả nhiều đánh giá khách quan do đó khó thực hiện. E-model sử dụng thang tỷ lệ ảnh hưởng R để thể hiện chất lượng tín hiệu phát thanh. Hệ số R có thể được xác định như sau: 0 s d eR R I I I A= − − − + ( 3. 6 ) Trong đó: Ro: là giá trị tối ưu (theo [3] giá trị mặc định của Ro được thiết lập là 93,2) Nguồn tín hiệu phát thanh Truyền dẫn tín hiệu phát thanh qua mạng IP Đánh giá chất lượng theo PESQ Giá trị hệ số PESQ - 34 - Ie: là hệ số ảnh hưởng của thiết bị và mô tả cho ảnh hưởng cho tính phi tuyến của bộ mã hóa/giải mã và độ tổn thất. Id: thể hiện ảnh hưởng của trễ. Is: thể hiển yếu tố ảnh hưởng tổng hợp của vấn đề đồng bộ tín hiệu. A: hệ số kỳ vọng cho phép bù các yếu tố ảnh hưởng khi tồn tại các yếu tố thuận lợi trong việc truy nhập của người dùng Nếu bỏ qua các ảnh hưởng khác, hệ số R có thể được xác định đơn giản hóa như sau: 0 d eR R I I= − − ( 3. 7 ) • Xác định chất lượng dựa trên hệ số đánh giá đường truyền R Hệ số đánh giá truyền tải R có giá trị trong khoảng 0 đến 100, trong đó R = 0 thể hiện chất lượng rất tồi và R = 100 thể hiện chất lượng thu nhận rất tốt. Mô hình E-model cung cấp ước đoán thống kê của phép đo chất lượng. Tỷ lệ phần trăm cho đánh giá chất lượng tốt GOB hoặc chất lượng kém POW, theo [3] được tính toán từ hệ số đánh giá truyền tải R thông qua xác định trung bình hàm sai lỗi Gaussian và được xác định cụ thể như sau: E x dt tx ( ) – – = ∞ ∫12 2 2 π e ( 3. 8 ) Công thức đánh giá chất lượng của GOB và POW được xác định tương ứng như sau: GOB E R= ⎛⎝⎜ ⎞ ⎠⎟100 60 16 – % ( 3. 9 ) POW E R= ⎛⎝⎜ ⎞ ⎠⎟100 45 16 – % ( 3. 10 ) Hệ số đánh giá chất lượng MOS theo tháng điểm 1-5 được xác định từ hệ số đánh giá truyền tải R theo công thức sau: - 35 - Với R < 0: MOS = 1 ( 5. 11 ) Với 0 < R < 100: MOS = + + − − ⋅ −1 0 035 60 100 7 10 6. ( )( )R R R R ( 3. 12 ) Với R > 100: MOS = 4 5. ( 3. 13 ) Theo công thức (4-3b), nếu giá trị R nhỏ hơn 6,5 tương đương với giá trị MOS nhỏ hơn 1 kéo theo giá trị R thường hạn chế trong khoảng 6.5 ~ 100. Giá trị ánh xạ giữa hệ số R, hệ số MOS và phân cấp chất lượng tín hiệu phát thanh được thể hiện trong hình 3.6. 3.3.2.3 Đánh giá chất lượng theo tỷ số tín hiệu trên tạp âm SNR Tỷ số tín hiệu trên tạp âm SNR là một trong những tham số được sử dụng để đánh giá chất lượng tín hiệu nói chung và tín hiệu phát thanh nói riêng tại đầu thu [57]. Tỷ số tín hiệu trên tạp âm SNR (Signal to Noise Ratio ) Giả sử tín hiệu nguồn biến theo thời gian được thể hiện là [ ]tnx m trong đó m là chỉ số mẫu tín hiệu trong khung đang xét và x là độ lớn mẫu tương ứng với giá trị của tín hiệu có ích phát từ nguồn. Giả thiết tín hiệu thu nhận bị thay đổi so với tín hiệu nguồn do chịu ảnh hưởng của hệ thống truyền dẫn được thể hiện là [ ]rnx m Năng lượng tín hiệu ES(n) của khung n gồm M mẫu tín hiệu được xác định như sau: 2 1 ( ) [ ] M t s n m E n x m = = ∑ ( 3. 14 ) Tương ứng năng lượng nhiễu tổng cộng EN(n) của khung n gồm M mẫu tín hiệu được xác định theo biểu thức sau: - 36 - 2 1 ( ) ( [ ] [ ]) M r t N n n m E n x m x m = = −∑ ( 3. 15 ) Khi đó, tỷ số SNR được xác định như sau: 2 1 1 1 10 10 2 1 1 1 ( ) [ ] 10.log 10.log ( ) ( [ ] [ ]) N N M t S n n n m N N M r t N n n n n m E n x m SNR E n x m x m = = = = = = ⎛ ⎞ ⎛ ⎞⎜ ⎟ ⎜ ⎟⎜ ⎟ ⎜ ⎟= =⎜ ⎟ ⎜ ⎟−⎜ ⎟ ⎜ ⎟⎝ ⎠ ⎝ ⎠ ∑ ∑∑ ∑ ∑∑ ( 3. 16 ) Với chỉ số m biến đổi trong phạm vi số mẫu của một khung và chỉ số n biến đổi theo tham số chu kỳ đo đạc tương ứng với N khung tín hiệu. Tỷ số tín hiệu trên tạp âm phân đoạn - SSNR ( Segmentation Signal to Noise Ratio ) Để tăng độ chính xác của thông số đo đạc SNR truyền thống, và tăng cường khả năng đánh giá chất lượng tín hiệu có đặc tính biến đổi động như tín hiệu tiếng nói. Giả thiết năng lượng tín hiệu ES(n) của khung n gồm M mẫu tín hiệu được xác định theo (3. 14) Năng lượng nhiễu tổng hợp EN(n) của khung n gồm M mẫu tín hiệu được xác định theo biểu thức sau: 2 2 1 1 ( ) ( [ ]) ( [ ]) M M r t N n n m m E n x m x m = = = −∑ ∑ ( 3. 17 ) Khi đó, tỷ số tín hiệu trên tạp âm phân đoạn SSNR được xác định như sau: - 37 - 2 1 10 10 2 21 1 1 1 [ ] ( )10.log 10.log ( ) ( [ ]) ( [ ]) M t nN N S m M m M r tn nN n n m m x m E nSSNR E n x m x m = = = = = = ⎛ ⎞⎜ ⎟⎛ ⎞ ⎜ ⎟= =⎜ ⎟ ⎜ ⎟⎝ ⎠ −⎜ ⎟⎝ ⎠ ∑∑ ∑∑ ∑ ( 3. 18 ) Như vậy, khác với SNR tính toán trên cơ sở toàn bộ số mẫu của chu kỳ đánh giá, SSNR tính toán dự trên cơ sở khung tín hiệu. Điều này cho phép đánh giá sai lệch tín hiệu đích so với tín hiệu nguồn một cách chính xác đồng thời cho phép khả năng tính toán và điều khiển trực tuyến theo thời gian thực. 3.4 Giải pháp đảm bảo chất lượng truyền tải tín hiệu phát thanh qua mạng IP. 3.4.1 Đặt vấn đề. Hầu hết các nghiên cứu gần đây nhằm đảm bảo chất lượng tín hiệu tiếng nói / âm thanh truyền tải qua mạng IP theo thời gian thực đều tập trung vào giải quyết theo hai hướng: Thứ nhất là trên cơ sở dành sẵn tài nguyên mạng theo giao thức RSVP (Resource Reservation Protocol) [34]. Thứ hai là theo hướng xử lý tối ưu lịch trình tái tạo tín hiệu tại bộ đệm tái tạo [5][6][7][9]. Tuy nhiên, chất lượng dịch vụ truyền tải tín hiệu phát thanh qua mạng IP phụ thuộc chặt chẽ vào các tham số nguồn phát và các tham số mạng. Tham số nguồn bao gồm các thông số chuyển đổi nguồn tín hiệu tương tự sang số và thông số độ dài gói tin. Trên cơ sở đó, luận án tập trung nghiên cứu vấn đề thích ứng nguồn với tình trạng mạng nhằm đảm bảo chất lượng tín hiệu tại đầu thu. 3.4.2 Thiết lập thông số nguồn. Tín hiệu phát thanh nguồn có dạng tương tự nằm trong dải âm tần cần được số hóa và đóng gói theo chuẩn giao thức RTP trước khi truyền qua mạng IP đến phía thu. Các thông số chuyển đổi nguồn tín hiệu được thể hiện trên bảng 3.3 - 38 - Bảng 3.3: Các thông số chuyển đổi nguồn tín hiệu phát thanh STT Thông số Giá trị 1. Tần số lấy mẫu [ sampling_rate ] 8000 Hz, 11025 Hz, 22050 Hz, 44100 Hz 2. Số bit mã hóa / một mẫu [ sample_size ] 8 bits / mẫu ; 16 bits / mẫu 3. Số kênh [ channels ] 1 kênh ( mono ) ; 2 kênh ( stereo ) 4. Khuôn dạng mẫu tín hiệu. [ format ] AFMT_U8; AFMT_S8 ; AFMT_S16_LE ; AFMT_S16_BE ; AFMT_U16_LE ; AFMT_U16_BE ; Cùng với các tham số chuyển đổi nguồn tín hiệu, thông số độ dài tải tin có ý nghĩa quan trọng trong việc xác định lịch trình phát các gói tin RTP vào mạng. Độ dài gói tin có thể được xác định bằng số thể hiện Bytes mà tải tin mang trong mỗi gói tin hoặc thời gian tương ứng. Chu kỳ phát gói tin phụ thuộc chặt chẽ vào thông số chuyển đổi nguồn tín hiệu và thông số độ dài gói tin thể hiện qua biểu thức sau: *8 * * *1000szt w ch fs ∆ = [ms] Trong đó: t∆ : Chu kỳ phát phát gói tin [ms] sz: Độ dài tải tin [ Bytes ] fs : Tần số lấy mẫu [ Hz] w: Số bít mã hóa cho một mẫu tín hiệu [bits] ch: số kênh mã hóa - 39 - Hình 3. 8: Mô hình thiết lập thông số nguồn Ngoài các tham số bắt buộc trên, vấn đề tổn thất gói tin tại đầu thu được cải thiện thông qua hệ số phát lặp gói tin tại đầu phát k. Một số kết quả khảo sát về tổn thất gói tin được trình bày trong phần phụ lục của luận án. Các thông số nguồn [ fs w, ch, sz, k ] được thiết lập giá trị khởi tạo trước khi tiến trình phát dữ liệu được thực hiện theo mô hình thể hiện trên hình 3.8. Sau khi khối số hóa tín hiệu được thiết lập thông số, nguồn tín hiệu phát thanh tương tự sẽ được chuyển đổi thành dạng số và lưu vào bộ đệm của thiết bị chuyển đổi âm thanh. Dựa vào thông số độ dài tải tin, dữ liệu đã số hóa sẽ được chương trình đọc ra từ bộ đệm của thiết bị âm thanh và chuyển đến khối mã hóa, kế tiếp là khối tạo gói RTP và chuyển đến lưu giữa tạm thời tại bộ đệm phát. Các gói tin RTP được gửi vào mạng theo lịch trình phát với hệ số phát lặp xác định và được điều khiển bởi bộ tạo lịch trình phát căn cứ vào số liệu nhận từ khối điều khiển thông số nguồn. - 40 - 3.4.1 Giải pháp đảm bảo chất lượng tín hiệu tại đầu thu Việc đánh giá chất lượng tín hiệu thu theo tỷ số tín hiệu trên tạo âm SNR truyền thống bị ràng buộc bởi tín hiệu tham chiếu và yêu cầu xác định toàn bộ số mẫu tín hiệu đo đạc do đó không cho phép đánh giá chất lượng tín hiệu thu theo thời gian thực. Phương thức đánh giá theo tỷ số SSNR tính toán dựa trên cơ sở khung tín hiệu, cho phép khả năng tính toán và điều khiển theo thời gian thực. Trên cơ sở đó, thuật toán đánh giá chất lượng đề xuất dựa trên tỷ số SSNR được thể hiện trên hình 3.9 và hình 3.12 với mô hình thực hiện tương ứng trên hình 3.10 và hình 3.13. Mức năng lượng của khung tín hiệu nguồn được truyền đến đầu thu qua gói tin RTP (hình 3.9). Tại đầu thu, tỷ số SSNR được tính toán dựa trên tín hiệu phát thanh nhận được và mức năng lượng khung tín hiệu nguồn tách từ gói RTP. Kết quả đo đạc được phản hồi về khối điều khiển thông số nguồn tại đầu phát theo chu kỳ đánh giá xác định qua gói tin RTCP (hình 3.10). Căn cứ giá trị SSNR phản hồi, trị số các tham số nguồn được điều khiển theo mô hình thể hiện trên hình 3.8. - 41 - Hình 3. 9: Thuật toán xác định tổng mức năng lượng tín hiệu nguồn tại phía phát Theo hình 3.10, tín hiệu nguồn sau khối số hóa tín hiệu sẽ được tính toán giá trị tổng mức năng lượng tín hiệu qua và so sánh ngưỡng phát hiện tín hiệu phát thanh tích cực tại khối RECAD. Tín hiệu từ khối RECAD điều khiển việc tạo gói tin eRTP có cấu trúc như gói tin RTP tuân theo khuyến nghị RFC3550 nhưng có bổ sung thành phần trường TESF (hình 3.11). Trường TESF mang - 42 - thông tin giá trị tổng mức năng lượng tín hiệu với vai trò tín hiệu tham chiếu nguồn nhằm xác định tỷ số tín hiệu trên tạp âm phân đoạn SSRN xác định theo công thức (3.19) tại phía thu qua đó đánh giá chất lượng tín hiệu tại đầu thu theo thời gian thực xác định theo thuật toán trên hình 3.9. Hình 3. 10: Mô hình thực hiện thuật toán xác định tổng mức năng lượng tín hiệu nguồn tại phía phát Hình 3. 11: Cấu trúc gói tin eRTP Theo mô hình thể hiện trên hình 3.13, căn cứ vào giá trị SRRN, tín hiệu điều khiển được phản hồi từ bên thu về bên phát. Qua đó, bên phát điều khiển thông số nguồn bao gồm nguồn số hóa tín hiệu phát thanh và độ dài tải tin của gói eRTP theo thời gian thực. - 43 - Hình 3. 12: Thuật toán xác định tổng năng lượng tín hiệu phân đoạn tại phía thu - 44 - Hình 3. 13: Mô hình xác định tổng mức năng lượng phân đoạn tại phía thu 3.4.2 Cấu hình thực nghiệm và kết quả. Các thành phần của hệ thống RoIP thể hiện trên hình 3.14 được xây dựng trên nền hệ điều hành Linux sử dụng công cụ lập trình Qt gồm 03 module chính: - Chương trình iVoVStation ( hình 3.15 a) : thực hiện nhận chuyển đổi tín hiệu phát thanh, mã hóa, đóng gói RTP và phát các gói tin từ bộ đệm phát theo lịch trình xác định. - Chương trình iVoVReceiver (hình 3.15 b): thực hiện nhận các gói tin mang tín hiệu phát thanh từ mạng theo chế độ đa hướng hoặc đơn hướng. Thực hiện đo đạc tín thông số mạng thông qua xử lý thông tin tiêu đề, tái tái tín phát thanh thích ứnh với tình trạng mạng và tạo thông tin phản hồi về bên phát. - Chương trình iVovGateway (hình 2.11 & hình 2.12): thực hiện việc phản hồi gói tin về địa chỉ nguồn ( Echo mode ) hoặc chuyển tiếp gói tin tới địa chỉ đa hướng hoặc đơn hướng xác định. Ngoài ra iVoVGateway còn được tích hợp chức năng phỏng tạo tham số QoS qua mạng IP như đã đề cập ở chương 2. - 45 - Hình 3. 14: Mô hình triển khai thực nghiệm hệ thống RoIP đề xuất. - 46 - Quá trình thực nghiệm được tiến hành theo 2 cấu hình thể hiện trên hình 3.16 và hình 3.17 sử dụng kết nối ánh xạ địa chỉ cổng hoặc thông qua mạng riêng ảo như trình bày trong phần phụ lục của luận án. - Cấu hình 1: Truyền tin 1 chiều giữa Đại học Bách Khoa Hà Nội và Đại học Ryukyu - Okinawa, Nhật Bản (hình 3.16) + Với cấu hình 1 chiều : chương trình phát iVoVStation cài đặt trên máy galileo kết nối vào mạng COMNET-LAN -> đường truy nhập ADSL -> Internet - > Ryukyu Uni. Network -> iVoVReceiver::plato.iip.ie.ac.jp - Cấu hình 2: Truyền tin 2 chiều giữa Đại học Bách Khoa Hà Nội và Đại học Ryukyu - Okinawa, Nhật Bản (hình 3.17) + Với cấu hình 2 chiều: chương trình phát iVoVStation::galileo -> đường truy nhập ADSL -> Internet - > Ryukyu Uni. Network -> iVoVGateway :: Echo Mode cài đặt trên máy plato.iip.ie.ac.jp -> Ryukyu Uni. Network -> Internet - >đường truy nhập ADSL -> được iVoVGateway chuyển đổi giao thức và chuyển tiếp tín hiệu đến các máy trạm iVoVReceiver ( ::ptolemy, ::apollo, :: vaio75 ) kết nối vào mạng COMNET-LAN theo chuẩn WLAN IEEE 802.11 kết hợp với Ethernet truyền thổng theo chuẩn 803.3. Kết quả thực nghiệm cho thấy trong cả hai trường hợp thông số trễ mạng biến thiên ngẫu nhiên theo thời gian kèm theo các đột biến trễ có chu kỳ (hình 3.18) hoặc không có chu kỳ (hình 3.20), hệ thống RoIP đều cho tín hiệu tốt tại đầu thu. Khi các thông số chuyển đổi nguồn tín hiệu để ở mức tối thiểu tần số lấy mẫu 8000Hz mã hóa 8 bits/mẫu và sử dụng 1 kênh với độ dài gói tin biến đổi từ 160 Bytes đến 512 Bytes, đầu thu sử dụng bộ đệm tái tạo cố định, ảnh hưởng của các yếu tố mạng đến chất lượng tín hiệu thu không đáng kể. Khi các thông số chuyển đổi nguồn tín hiệu tăng lên tần số lấy mẫu 44.1 KHz, 2 kênh và mã hóa 16 bits/mẫu, đầu thu sử dụng bộ đệm tái tạo thích ứng và cơ chế đảm bảo chất lượng đề xuất được áp dụng cho kết quả kết quả cải thiện rõ rệt với độ dài tải tin biến thiên từ đến 10 khung dữ liệu mã hóa ứng với dữ liệu nguồn là 1600 Bytes đến 3200 Bytes. - 47 - Hình 3. 15: Chương trình phát (a)-thu (b) tín hiệu phát thanh qua mạng IP b a - 48 - Hình 3. 16: Mô hình thực nghiệm 1 chiều giữa Đại học Bách Khoa Hà Nội và Đại học Ryukyu - Okinawa, Nhật bản - 49 - Hình 3. 17: Mô hình thực nghiệm 2 chiều giữa Đại học Bách Khoa Hà Nội và Đại học Ryukyu - Okinawa, Nhật bản - 50 - Hình 3. 18: Tham số trễ mạng đo thực tế phân bố theo thời gian - đột biến trễ có chu kỳ [ thời điểm đo: 21:37:46 giờ ngày 14-12-2005 ] - 51 - Hình 3. 19: Tham số trễ mạng đo thực tế phân bố theo trị số - đột biến trễ có chu kỳ [ thời điểm đo: 21:37:46 giờ ngày 14-12-2005 ] - 52 - Hình 3. 20: Tham số trễ mạng đo thực tế phân bố theo thời gian - đột biến trễ không có chu kỳ [ thời điểm đo: 20:57:29 giờ ngày 16-12-2005 ] - 53 - Hình 3. 21: Tham số trễ mạng đo thực tế phân bố theo trị số - đột biến trễ không có chu kỳ [ thời điểm đo: 20:57:29 giờ ngày 16-12-2005 ] - 54 - Bên cạnh đó, kết quả thay đổi hệ số phát lặp gói tin cũng cho kết quả cải thiện chất lượng tín hiệu tại đầu thu, đặc biệt trong trường hợp tỷ lệ tổn thất gói tin lớn như thể hiện qua kết quả thực nghiệm trên các bảng 3.4 và trong phần phụ lục với các kết nối thực hiện qua khâu phỏng tạo sử dụng số liệu thu thập từ trước. Bảng 3.4: Kết quả đo đạc tham số chất lượng tại đầu thu khi thay đổi hệ số phát lặp gói tin tại đầu phát qua kết nối giữa Đại học Bách Khoa Hà Nội và ĐH Ruykyus. Hệ số phát lặp gói tin Số gói tin phát ra Số gói tin thu được Số gói tin tổn thất Tỷ lệ tổn thất gói tin [%] Trễ mạng nhỏ nhất [ms] Trễ mạng lớn nhất [ms] Trễ mạng trung bình [ms] 1 601 585 16 2,66 200 299 228,04 2 601 594 7 1,16 200 296 221,00 3 601 599 2 0,33 201 300 219,79 3.5 Kết luận chương 3 Đánh giá chất lượng tín hiệu phát thanh theo phương pháp chủ quan có thể thu nhận trực tiếp mức độ chất lượng từ các ý kiến cá nhân tham giá đánh giá chất lượng tín hiệu tại đầu thu. Tuy nhiên, phương thức này không hiệu quả để đánh giá theo dõi và tiên đoán lưu lượng qua mạng IP thực tế. So với các hạn chế của đánh giá chủ quan, phương pháp đo đạc khách quan có thể khắc phục và đạt được độ chính xác cao trong đánh giá chất lượng RoIP. Thuật toán và mô hình thực hiện đánh giá chất lượng theo thời gian thực được đề xuất trên cơ sở tham số tỷ số tín hiệu trên tạp âm phân đoạn. Căn cứ vào thuật toán đánh giá chất lượng theo thời gian thực, phương pháp đảm bảo chất lượng dịch vụ sử dụng cơ chế điều khiển tham số nguồn thích ứng với tình trạng hệ thống được đề xuất và áp dụng cho hệ thống RoIP. Hệ thống RoIP được tiến hành thực nghiệm thành công theo cấu hình kết nối giữa Đại học Bách Khoa Hà Nội và Đại học Ryukyu - Okinawa, Nhật Bản. - 55 - KẾT LUẬN CỦA LUẬN ÁN Sự hạn chế về chất lượng dịch vụ của các mạng IP hiện nay là thách thức chủ yếu cho các ứng dụng thông tin đa phương tiện thời gian thực. Trễ mạng, tổn thất gói và biến động trễ mạng là các yếu tố chính gây ảnh hưởng đến chất lượng truyền thông. Các vấn đề ảnh hưởng đến chất lượng có thể xem xét theo 3 hướng đó là xử lý tín hiệu nguồn, truyền tải và xử lý tín hiệu tại đầu thu. Các đóng góp của luận án bao gồm: 1. Đề xuất sử dụng tỷ số tín hiệu trên tạp âm phân đoạn SSNR để đánh giá chất lượng tín hiệu tại đầu thu theo thời gian thực qua mạng IP và đã được kiểm nghiệm qua thực tế. 2. Đề xuất và thực hiện phương pháp điều chỉnh thông số nguồn thích ứng với tình trạng mạng trên cơ sở thuật toán đánh giá chất lượng tín hiệu tại đầu thu qua tỷ số SSNR để đảm bảo chất lượng tín hiệu phát thanh truyền tải qua mạng IP theo thời gian thực. 3. Đề xuất và đã xây dựng công cụ phỏng tạo tham số mạng IP hỗ trợ truyền thông đa hướng/đơn hướng ở lớp ứng dụng. Công cụ cho kết quả phỏng tạo chính xác tham số QoS bao gồm trễ mạng và tổn thất gói tin truyền tải qua mạng IP. 4. Đã xây dựng và triển khai thành công mô hình hệ thống RoIP thực hiện cơ chế đảm bảo chất lượng thông qua thích ứng thông số nguồn với tình trạng mạng IP giữa Đại học Bách Khoa Hà Nội và Đại học Ruykyu - Okinawa, Nhật Bản. Hệ thống có tính khả thi và có khả năng tùy biến để triển khai phù hợp các ứng dụng đặc thù và với chi phí thấp. - 56 - HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI Nghiên cứu phương thức phối ghép hệ thống đề xuất với hệ thống sẵn có của mạng phát thanh Đài tiếng nói Việt Nam và tự động hóa quá trình cập nhật và thực hiện chương trình phát thanh. Mở rộng mô hình hệ thống và cơ chế đảm bảo chất lượng dịch vụ đề xuất với nguồn tín hiệu truyền hình tiến tới xây dựng hệ thống tích hợp đa phương tiện qua môi trường IP. Mở rộng khả năng truy nhập vào hệ thống RoIP đề xuất từ thiết bị đầu cuối của mạng di động. - XVI - DANH MỤC CÔNG TRÌNH CỦA TÁC GIẢ [1]. Phạm Minh Hà, Đỗ Trọng Tuấn, Ứng dụng giao thức RTP trong truyền thông đa hướng tiếng nói thời gian thực qua mạng IP, tạp chí Khoa học & Công nghệ các Trường Đại học Kỹ thuật, số 50, trang 102-105, năm 2005. [2]. Đỗ Trọng Tuấn, Nguyễn Hữu Thanh, Ứng dụng công cụ NS trong mô phỏng mạng viễn thông, tạp chí Bưu chính Viễn thông & Công nghệ thông tin, số 253, trang 42- 43, năm 2005. [3]. Đỗ Trọng Tuấn, Phạm Minh Hà, Mô hình phỏng tạo tổn thất gói tin trong truyền thông đa hướng tín hiệu phát thanh thời gian thực qua mạng IP, nội san Khoa học Kỹ thuật Truyền hình, số 2-2005, trang 37- 40, năm 2005. [4]. Đỗ Trọng Tuấn, Nguyễn Hữu Thanh, Mạng WLAN theo chuẩn IEEE 802.11, tạp chí Bưu chính Viễn thông & Công nghệ thông tin, số 263, trang 42- 43, năm 2005. [5]. Phạm Minh Hà, Đỗ Trọng Tuấn, Một phương pháp đảm bảo chất lượng tín hiệu phát thanh truyền tải qua mạng IP theo thời gian thực, tạp chí Khoa học & Công nghệ các Trường Đại học Kỹ thuật, số 57, trang 76-79, năm 2006. - XVII - TÀI LIỆU THAM KHẢO [1] ITU-T Recommendation G.114. Technical report, International Telecommunication Union , 1993. [2] ITU-T Recommendation G.113, Transmission impairments due to speech processing, 2001. [3] ITU-T Recommendation G.107. The E-model, A Computational Model for Use in Transmission Planning, 2000. [4] ITU-T Recommendation P.862. Perceptual Evaluation of Speech Quality (PESQ), An Objective Method for End-to-end Speech Quality Assessment of Narrowband Telephone Networks and Speech Codecs. [5] Grenville Armitage, Quality of Service in IP Networks: Foundations for a Multi- Service Internet, Lucent Technology, 2000 [6] Ramjee, R., Kurose, J., Towsley, D. & Schulzrinne, H. (1994) Adaptive Playout Mechanism for Packetised Audio Application in Wide-area Networks. IEEE, Toronto, Canada [7] Moon, S. B., Kurose, J. & Towsley, D. (1998) Packet Audio Playout Delay Adjustment: Performance Bounds and Algorithms. Acm Multimedia Systems. [8] Markopoulou, A. P., Tobagi, F. A. & Karam, M. J. (2002) Assessment of VoIP Quality over Internet Backbones. Proc. Of IEEE Infocom [9] Liang, Y. J., Farber, N. & Girod, B. (2001) Adaptive Playout Scheduling Using Time-Scale Modification in Packet Voice Communications. Stanford University, Stanford, CA 94305 [10] Y.J. Liang, N. Farber, and B. Girod, Adaptive playout scheduling and loss concealment for voice communication over IP networks, IEEE Transactions on Multimedia, 2003. [11] Jiang, W. & Schulzrinne, H. QoS Measurement of Internet Real-Time Multimedia Services. Technical Report, CUCS-015-99, Columbia University. [12] Macedonia, M. R., Brutzman, D. P., "MBone Provides Audio and Video Across the Internet," IEEE Computer, ftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.html. [13] Kevin C. Almeroth, The Evolution of Multicast: From the MBone to Inter- DomainMulticast to Internet2 Deployment, [14] Cole, R. G. & Rosenbluth, J. H. (2001) Voice over IP Performance Monitoring. Journal on Computer Communications Review. [15] Fujimoto, K., Ata, S. & Murata, M. Adaptive Playout Buffer Algorithm for Enhancing Perceived Quality of Streaming Application. IEEE Globecom, 2002. [16] Sun, L. F. & Ifeachor E. C. Prediction of perceived Convestional Speech Quality and Effects of Playout Buffer Algorithms. IEEE, ICC 03, Anchorage, USA, May 2003 - XVIII - [17] Mills, D. Internet Delay Experiments. ARPANET Working Group Requests for Comment, RFC 889, 1983. [18] F. Liu, J. W. Kim, and C. C. J. Kuo, Adaptive delay concealment for Internet voice applications with packet-based time-scale modification, Proc. IEEE Int. Conf. on Acoustics, Speech, Signal Processing (Utah, USA), 2001. [19] Marco Roccetti, Vittorio Ghini, Designed and Experimental Evaluation of an Adaptive Playout Delay Control Mechanism for Packetized Audio for Use over the Internet, Multimedia Tools and Application, 14, 23-53, 2001 [20] Athina P. Markopoulou, Fouad A. Tobagi, and Mansour J. Karam, Assessing the Quality of Voice Communications OverInternet Backbones, IEEE/ACM Transactions on netwoiking, 2003. [21] RFC3550: RTP: A Transport Protocol for Real-Time Applications [22] RFC3551: RTP Profile for Audio and Video Conferences [23] Rosenboerg, J., Qiu, L. & Schulzrinne, H. Integrating Packet FEC into Adaptive Voice Playout Buffer Algorithms on the Internet. IEEE Infocom 2000. [24] Jiang, W. & Schulzrinne, H. QoS Measurement of Internet Real-Time Multimedia Services. Technical Report, CUCS-015-99, Columbia University. [25] Jiang, W. & Schulzrinne, H. Analysis of on-off Patterns in RoIP and their Effect on Voice Traffic Aggregation. Proc, of ICCCN 2000. [26] Behrouz A Forouzan,Sophia Fegan, TCP/IP Protocol Suite, GrawHill 2000 [27] W.Richchard Stevent, Gary R.Wright , TCP/IP Illustrated, volume 1,2,3 [28] Perkins, C., Hodson, O. & Hardman, V. A Survey of Packet Loss Recovery Techniques for Streaming Audio. IEEE Network, Sept./Oct. 1998. [29] Y.J. Liang, N. F¨arber, and B. Girod, Adaptive playout scheduling using timescale modification in packet voice communications, in Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP-01), Salt Lake City, UT, May 2001, vol. 3, pp. 1445–8. [30] Douglas E.Comer, Internetworking with TCP/IP, vol 1, Prentice Hall, 2000 [31] Brian "Beej" Hall , Beej's Guide to Network Programming. Using Interet Sockets -2001; [32] Neill Wilkison, John Wiley & Sons, Next Generation Network Services: Technology and Strategies, 2002. [33] Christophe Diot. Brian Neil Levine. Bryan Lyles. Hassan Kassem, Doug Balensiefen, Deployment Issues for the IP Multicast Service and Architecture, - XIX - [34] L. Zhang, RSVP: A new resource reservation protocol, IEEE Network Magazine, Vol.7, pp. 8-18, 1993 [35] Fujimoto, K., Ata, S. & Murata, M. Adaptive Playout Buffer Algorithm for Enhancing Perceived Quality of Streaming Application. IEEE Globecom, 2002. [36] Sun, L. F. & Ifeachor E. C. Prediction of perceived Convestional Speech Quality and Effects of Playout Buffer Algorithms. IEEE, ICC 03, Anchorage, USA, May 2003 [37] Markopoulou, A. P., Tobagi, F. A. & Karam, M. J. Assessment of VoIP Quality over Internet Backbones. Proc. Of IEEE Infocom, 2002 [38] Liang, Y. J., Farber, N. & Girod, B. Adaptive Playout Scheduling Using Time- Scale Modification in Packet Voice Communications. Stanford University, Stanford, CA 94305 , 2001. [39] Ram Jadageesan, Packet Loss Model, Cisco System Inc, TR-41.3.3/99 [40] Jean-Chrisostome Bolot, Characterizing The End-To-End Behavior Of The Internet: Measurements, Analysis, And Applications, [41] Cole, R. G. & Rosenbluth, J. H. (2001) Voice over IP Performance Monitoring. Journal on Computer Communications Review, vol. 31, no.2. [42] S. Deering, Host Extensions for IP Multicasting - RFC 1112, [43] Jean-Chrisostome Bolot & Andres Vega Garcia, Control mechanisms for packet audio in the Internet, [44] Mills, D. Internet Delay Experiments. RFC 889, 1983. [45 ] Bob Melander, Mats Bjorkman, Trace-Driven Network Path Emulation, SITI/Ericson Project, [46] Maya Yajnik, Sue Moon, Jim Kurose and Don Towsley , Measurement and Modelling of the Temporal Dependence in Packet Loss, 0-7803-5420-6/99/ IEEE [47] Rosenboerg, J., Qiu, L. & Schulzrinne, H. Integrating Packet FEC into Adaptive Voice Playout Buffer Algorithms on the Internet. IEEE Infocom 2000. [48] Bolot, J. C. (1993) End-to-end Packet Delay and Loss Behaviour in the Internet. Proc. 1993 ACM SIGCOMM Conf. pp.289-298. [49] Jean-Chrisostome Bolot, End-to-End Packet Delay and Loss Behavior in the Internet , [50] Jiang, W. & Schulzrinne, H. Analysis of on-off Patterns in VoIP and their Effect on Voice Traffic Aggregation. Proc, of ICCCN 2000. [51] Cisco, Multicast Deployment Made Easy, ftp.uth.gr/Mbone/guides/Multicast_Deployment_Made_Easy.pdf [52] Perkins, Hodson and Hardman, A Survey of Packet Loss Recovery Techniques for Streaming Audio. IEEE Network, 1998. - XX - [53] Y.J. Liang, N. Farber, and B. Girod, Adaptive playout scheduling using timescale modification in packet voice communications, Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP-01), Salt Lake City, UT, May 2001, vol. 3, pp. 1445–8. [54] Y.J. Liang, N. Farber, and B. Girod, Adaptive playout scheduling and loss concealment for voice communication over IP networks, IEEE Transactions on Multimedia, 2003. [55] D.J. Goodman, G.B. Lockhart, O.J. Wasem, and W.-C. Wong, Waveform substitution techniques for recovering missing speech segments in packet voice communications, IEEE Transactions on Acoustics, Speech, and Signal Processing, vol. 34, no. 6, pp. 1440–1448, Dec. 1986. [56] P.A. Chou and Z. Miao, Rate-distortion optimized streaming of packetized media, IEEE Transactions on Multimedia, 2001. ˜pachou. [57] Wai C. Chu, Speech Coding Algorithms -- Foundation and Evolution of Standardized Coders, Mobile Media Laboratory, California, 2003 [58] Internet 2005 Summary Final.pdf, [59] Thomas Williams & Colin Kelley, gnuplot, [60] xiph open source community, [61] The Network Simulator, [62] Nistnet homepage, [63] Dummynet homepage, [64] Christian Scherpe, Bernd E. WolfingerModel, Ingo Salzmann, Based Network Emulation to Study the Behavior and Quality ß Real-Time Application, DS-RT’03 proceeding, IEEE. [65] Jingping Bi, Qi Wu, Zhongcheng Li, Packet Delay and Packet Loss in the Internet, ISCC’02, IEEE. [66] Chu-Sing Yang, Yih-Ching Su and Chen -Wei Lee, The Analysis of Packet Loss Prediction for Gilbert-Model with Loss Rate Uplink, ICDCSW’03, IEEE. [67] Vincenzo Marziale, Andrea Vitaletti, University of Rome , A Framework for Internet QoS Requirements Definition and Evaluation: an experimental approach,. [68] Stephen J.Solari, Digital Video and Audio Compression,McGraw-Hill, 1997 [69] Arman Danesh and Michel Jang , Mastering Linux, SYBEX 2001 [70] Open Sound System, [71] data_traces, pinhu@plymouth.ac.uk [72] Virtual Private Network, - i - PHỤ LỤC Phụ lục 1: Các phương thức kết nối các thành phần của hệ thống RoIP thực nghiệm qua mạng diện rộng. Phụ lục 2: Một số kết quả so sánh giữa số liệu thu thập và đo đạc qua mô hình phỏng tạo tham số mạng Phụ lục 3: Một số kết quả đo đạc tham số chất lượng tại đầu thu khi thay đổi hệ số phát lặp gói tin tại đầu phát Phụ lục 4: Một số kết quả thống kê xác xuất xảy ra tổn thất của các gói tin liên tiếp . Phụ lục 5: Mã nguồn thực hiện thuận toán phát hiện khoảng tín hiệu tích cực / khoảng lặng tại bên phát. Phụ lục 6: Mã nguồn thực hiện mã hóa tín hiệu phát thanh. Phụ lục 7: Mã nguồn thực hiện giải mã tín hiệu phát thanh. Phụ lục 8: Mã nguồn thực hiện thuật toán thu dữ liệu từ thiết bị âm thanh và lưu vào bộ đệm phía phát. Phụ lục 9: Mã nguồn module tạo lịch trình gửi dữ liệu vào mạng. Phụ lục 10: Mã nguồn thực hiện thuật toán thu nhận dữ liệu từ mạng và lưu vào bộ đệm phía thu. Phụ lục 11: Mã nguồn thực hiện thuật toán ước đoán trễ mạng và biến động trễ trung bình của gói tin phục vụ quá trình tái tạo tín hiệu thích ứng. - ii - Phụ lục 1: Phương thức kết nối các thành phần của hệ thống RoIP thực nghiệm qua mạng diện rộng. a. Sử dụng phương thức chuyển đổi địa chỉ mạng NAT ( Network Address Translation) a. Sử dụng kết nối qua mạng riêng ảo VPN ( Virtual Private Network) [72] - iii - Phụ lục 2: Một số kết quả so sánh giữa số liệu thu thập và đo đạc qua mô hình phỏng tạo tham số mạng. a. Kết quả trễ mạng đo đạc qua kết nối giữa ĐHBK Hà Nội và ĐH Ryukyus b. Kết quả trễ mạng phỏng tạo theo phương không trực tuyến với sử dụng file số liệu đo đạc qua kết nối giữa ĐHBK Hà Nội và ĐH Ryukyus - iv - a. Kết quả trễ mạng đo đạc qua kết nối giữa ĐHBK Hà Nội và Thăng Long - Từ liêm Hà Nội b. Kết quả trễ mạng phỏng tạo theo phương không trực tuyến với sử dụng file số liệu đo đạc qua kết nối giữa ĐHBK Hà Nội và Thăng Long - Từ liêm Hà Nội - v - a. Kết quả trễ mạng đo đạc qua kết nối giữa Đại học Viễn thông Bắc Kinh Trung Quốc và Đại học Plymouth - Anh Quốc [71] b. Kết quả trễ mạng phỏng tạo theo phương không trực tuyến với sử dụng file số liệu đo đạc qua kết nối giữa ĐH Viễn thông Bắc Kinh Trung Quốc và Đại học Plymouth - Anh Quốc - vi - a. Kết quả trễ mạng đo đạc qua kết nối giữa Đại học Plymouth - Anh Quốc và Đại học Viễn thông Bắc Kinh Trung Quốc [71] b. Kết quả trễ mạng phỏng tạo theo phương không trực tuyến với sử dụng file số liệu đo đạc qua kết nối giữa Đại học Plymouth - Anh Quốc và Đại học Viễn thông Bắc Kinh Trung Quốc - vii - Phụ lục 3: Một số kết quả đo đạc tham số chất lượng tại đầu thu khi thay đổi hệ số phát lặp gói tin tại đầu phát. a. Kết nối giữa ĐHBK Hà Nội và Thăng Long - Từ liêm Hà Nội. Hệ số phát lặp gói tin Số gói tin phát ra Số gói tin thu được Số gói tổn thất Tỷ lệ tổn thất gói tin Trễ mạng nhỏ nhất Trễ mạng lớn nhất Trễ mạng trung bình 1 346 334 12 3,47 % 69 76 71,09 2 346 335 11 3,18 % 68 80 71,32 3 346 339 7 2,02 % 68 79 71,30 b. Kết nối qua chương trình phỏng tạo mạng sử dụng số lieụe đo đạc giữa Đại học Plymouth - Anh Quốc và Đại học Viễn thông Bắc Kinh Trung Quốc [71] Hệ số phát lặp gói tin Số gói tin phát ra Số gói tin thu được Số gói tổn thất Tỷ lệ tổn thất gói tin Trễ mạng nhỏ nhất [ms] Trễ mạng lớn nhất [ms] Trễ mạng trung bình 1 1000 878 122 12,00 % 122,54 832,19 271.58 2 926 871 55 5,94 % 122,00 832,00 253,77 3 443 419 24 5,42 % 122,00 799,00 262,70 - viii - Phụ lục 4: Một số kết quả thống kê xác xuất xảy ra tổn thất của các gói tin liên tiếp . a. Kết nối giữa ĐH Viễn thông Bắc Kinh Trung Quốc và ĐH Plymouth - Anh Quốc [71] Tổng số gói tin tổn thất :: 5 / 1000 [packets] ~ 0.5 [%] Số gói tin tổn thất đơn = 3 ~ 60.00 [%] Số gói tin tổn thất 2 lần liên tiếp = 1 ~ 40.00 [%] b. Kết nối giữa ĐH Plymouth - Anh Quốc và ĐH Viễn thông Bắc Kinh Trung Quốc [71] Tổng số gói tin tổn thất :: 122 / 1000 [packets] ~ 12.2 [%] Số gói tin tổn thất đơn = 31 ~ 25.41 [%] Số gói tin tổn thất 2 lần liên tiếp = 12 ~ 19.67 [%] Số gói tin tổn thất 3 lần liên tiếp = 8 ~ 19.67 [%] Số gói tin tổn thất 4 lần liên tiếp = 3 ~ 9.84 [%] Số gói tin tổn thất 5 lần liên tiếp = 1 ~ 4.10 [%] Số gói tin tổn thất 6 lần liên tiếp = 2 ~ 9.84 [%] Số gói tin tổn thất 7 lần liên tiếp = 2 ~ 11.48 [%] c. Kết nối giữa ĐHBK Hà Nội và ĐH Okinawa - Nhật Bản Tổng số gói tin tổn thất :: 16 / 601 [packets] ~ 2.66223 [%] Số gói tin tổn thất đơn = 16 ~ 100.00 [%] d. Kết nối giữa ĐHBK Hà Nội và ĐH Okinawa - Nhật Bản Tổng số gói tin tổn thất :: 159 / 1008 [packets] ~ 15.7738 [%] Số gói tin tổn thất đơn = 116 ~ 72.96 [%] Số gói tin tổn thất 2 lần liên tiếp = 17 ~ 21.38 [%] Số gói tin tổn thất 3 lần liên tiếp = 3 ~ 5.66 [%] e. Kết nối giữa ĐHBK Hà Nội và Thăng Long, Từ Liêm - Hà Nội Tổng số gói tin tổn thất :: 12 / 346 [packets] ~ 3.46821 [%] Số gói tin tổn thất đơn = 12 ~ 100.00 [%] - ix - Phụ lục 5: Mã nguồn thực hiện thuận toán phát hiện khoảng tín hiệu tích cực / khoảng lặng tại bên phát. Thuật toán thực hiện xác định gói tin cần truyền mang tín hiệu tích cực hay khoảng lặng của tín hiệu phát thanh dự trên việc tính toán năng lượng và so sánh ngưỡng. Quá trình phát hiện mức tín hiệu tích cực được thực hiện bằng cách gọi hàm: double SoundDevice:: silenceDetect ( char *inputData, int inputSize ) Trong đó : inputData: khối dữ liệu vào mang tín hiệu phát thanh nguồn, inputSize : kích thước khối dữ liệu dữ liệu đầu vào bộ mã hóa. Trước hết, chương trình xác định số mẫu tính hiệu trong một gói tin từ khối dữ liệu đầu vào input Data. Tính toán năng lượng từng mẫu tín hiệu và lưu vào biến totalEnergy. Cuối cùng, mức năng lượng tín hiệu trung bình everageEnergy của các mẫu trong gói tin được xác định. Giá trị biến everageEnergy được so sánh với ngưỡng năng lượng tín hiệu phát thanh tích cực activeSignalTheshold. Hàm trả về kết quả 0 nếu là khoảng lặng của tín hiệu và giá trị mức năng lượng trung bình của mẫu tín hiệu trong gói tin nếu là khoảng tín hiệu tích cực. Mã nguồn chương trình: #define energy (x) pow (x ,2 ) double SoundDevice::silenceDetect ( char *inputData, int inputSize ) { double averageEnergy = 0; int numberSample = size *8 / bitPerSample; for ( int i = 0 ; i < numberSample ; i++ ) { if (bitPerSample ==8) { averageEnergy += energy (* ( data + i ) ); } else if ( bitPerSample ==16 ) { averageEnergy += energy ( * (short * ) ( data + i*2 ) ); } } printf ("%d :: %0.3f\n", seq, averageEnergy/numberSample); // seq: thứ tự gói tin - x - return (averageEnergy / numberSample ); } a. Giao diện chương trình xử lý số liệu khoảng tích cực / khoảng lặng của tín hiệu b. Minh họa khoảng tích cực / khoảng lặng của tín hiệu phát thanh Phụ lục 6: Mã nguồn thực hiện mã hóa tín hiệu phát thanh. Quá trình mã hóa tín hiệu được thực hiện bằng cách gọi hàm: int encodeData ( char * inputData, int inputSize, char * outputData ); Trong đó : inputData: khối dữ liệu vào mang tín hiệu phát thanh nguồn, inputSize : kích thước khối dữ liệu dữ liệu đầu vào bộ mã hóa. outputData : khối dữ liệu đã được mã hóa. - xi - Hàm mã hóa tín hiệu encodeData trả về dung lượng của khối dữ liệu đã được mã hóa. Khối dữ liệu vào được chia thành các khung dữ liệu có dung lượng 160 Bytes. Mỗi khung dữ liệu được mã hóa dựa trên thuật toán nén tín hiệu sử dụng thư viện . Tùy thuộc vào mức chất lượng mà độ dài khung dữ liệu đã mã hóa có kích thước khác nhau. Các khung dữ liệu sau khi mã hóa được ghép lại thành khối dữ liệu đã được mã hóa outputData và dung lượng của khối dữ liệu này sẽ được trả về. Mã nguồn chương trình: # define FRAME_SIZE 160 int SpeexCodec::encodeData ( char* inputData , int inputSize, char *outputData ) { int outputSize = 0; int nbBytes = 0; int numberFrame = inputsize / ( FRAME_SIZE * sizeof ( short ) ); char *cbits = ( char * ) malloc ( 200 ); float *input = ( float * ) malloc ( FRAME_SIZE * sizeof ( float ) ); short * buffer16 = ( short * ) inputData; for ( int i = 0 ; i < numberFrame ; i++ ) { // thực hiện mã hóa tín hiệu speex_bits_reset ( &bits ); for ( int j = 0 ; j < FRAME_SIZE ; j ++ ) *( input + j ) = * ( buffer16 + j + i * FRAME_SIZE ); speex_encode ( state, input, &bits); nbBytes = speex_bits_write ( &bits, cbits, 200 ); memcpy ( outputdata + i * nbBytes , cbits , nbBytes ); outputSize += nbBytes; } - xii - return outputSize; } Phụ lục 7: Mã nguồn thực hiện giải mã tín hiệu phát thanh. Quá trình giải mã tín hiệu được thực hiện bằng cách gọi hàm: int decodeData ( char * inputData, int inputSize , int nbBytes , char * outputData ); Trong đó : inputData: khối dữ liệu vào mang tín hiệu phát thanh đã được mã hóa, inputSize : kích thước khối dữ liệu dữ liệu đầu vào bộ giải mã. nbBytes : số Byte tương ứng với mức chất lượng nén là tham số cung cấp cho bộ giải nén phục vụ giải mã dữ liệu tương ứng với mức chất lượng đã mã hóa. outputData : khối dữ liệu đã được giải mã. Hàm mã hóa tín hiệu decodeData trả về dung lượng của khối dữ liệu đã được giải mã. Khối dữ liệu đầu vào được chia nhỏ thành các khung dữ liệu đã mã hóa có kích thước nbBytes. Các khung này được giải nén thành các khung ban đầu dữ liệu mang tín hiệu phát thanh nguồn có kích thước FRAM_SIZE (160 bytes) dựa trên thuật toán giải nén sử dụng thư viện trong . Các khung dữ liệu sau khi giải mã được ghép lại thành khối dữ liệu outputData phục vụ tái tạo tín hiệu phát thanh và dung lượng của khối dữ liệu này sẽ được trả về. Mã nguồn chương trình: int SpeexCodec::decodeData ( char* inputData,int inputSize, int nbBytes, char* outputData ) { int numberFrame = inputSize / nbBytes; int outputSize = 0; float *output = ( float * ) malloc ( FRAME_SIZE * sizeof ( float ) ); - xiii - short *data = ( short * ) malloc (FRAME_SIZE * sizeof ( short ) ); for ( int i = 0 ; i < numberFrame ; i ++ ) { // thực hiện giải mã tín hiệu speex_bits_read_from ( &bits , inputData + i * nbBytes , nbBytes ); speex_decode ( state, &bits, output ); for ( int j = 0 ; j < FRAME_SIZE ; j ++ ) * ( data + j ) = * ( output + j ); memcpy ( outputData + i * FRAME_SIZE * sizeof ( short ) , ( char * ) data , FRAME_SIZE * sizeof ( short ) ); outputsize += FRAME_SIZE * sizeof ( short ) ; } return outputSize; } Phụ lục 8: Mã nguồn thực hiện thuật toán thu dữ liệu từ thiết bị âm thanh và lưu vào bộ đệm phía phát. Dữ liệu nguồn mang tín hiệu phát thanh đã được số hóa đọc từ bộ đệm của thiết bị âm thanh được lưu vào bộ nhớ trung gian soundBuffer theo độ dài gói tin packetLength được thiết lập trước. Kế tiếp, thuật toán xác định mức năng lượng tín hiệu phát thanh tích cực được thực hiện. Kết quả trả về sẽ quyết định gói tin có được lưu vào bộ đệm phát trong trường hợp mang tín hiệu tích cực hay bị loại bỏ trong trường hợp mang tín hiệu khoảng lặng. Dữ liệu trước khi lưu vào bộ đệm phát sẽ được mã hóa theo loại tải tin xác lập trước. Các phần tử mang dữ liệu lưu trong bộ đệm phát sẽ được gửi vào mạng theo điều khiển của bộ điều khiển lịch trình phát. Mã nguồn chương trình: void SoundDevice::capture( ) - xiv - { // cấp phát bộ đệm lưu dữ liệu nguồn char* soundBuffer = ( char * ) malloc ( packetLength); int seqNumber = 0; int totalSilencePacket = 0 ; int nbBytes = speexEncode->getEncodedByte ( qualityLevel ); int outputSize = len * nbBytes / FRAME_SIZE * sizeof ( short ) ; char * speexData = ( char * ) malloc ( outputSize ); stopTxProccess = FALSE; openSoundDevice( O_RDONLY); txBuffer->clear(); while ( ! stopTxProccess ) { if ( totalSilencePacket == SILENCE_PACKET_NUMBER) { for ( int i = SILENCE_PACKET_NUMBER - 1 ; i > 0 ; i--) { if ( txBuffer->count() >= i ) { txBuffer->remove ( txBuffer->count() - i ); totalSilencePacket = 1; } else { totalSilencePacket = txBuffer->count(); } } - xv - } // Đọc dữ liệu từ bộ đệm của thiết bị âm thanh và lưu vào bộ đệm trung gian int size = read ( sound_fd, soundBuffer, packetLength); sound_item_t * item = new sound_item_t; item->seqNumber = seqNumber; item->mark = silenceDetect (soundBuffer, size); if ( item->mark == 0) // tăng số biến đếm các gói tin liên tiếp mang tín hiệu không tích cực totalSilencePacket ++ ; else // Gói tin bắt đầu chu kỳ tín hiệu phát thanh tích cực, thiết lập lại biến đếm số gói tin mang tín hiệu khoảng lặng totalSilencePacket = 0 ; switch ( codecType ) { case PCM: item->length = size; item->data = ( char * ) malloc ( item->length ); memcpy ( item->data, soundBuffer, size ); break; case SPEEX : item->length = speexEncode->encodeData ( soundBuffer, size, speexData); item->data = ( char * ) malloc ( item->length ); memcpy ( item->data , speexData, item->length); break; } - xvi - // Đưa gói dữ liệu vào bộ đệm phát txBuffer->append ( item ); seqNumber ++ ; } closeSoundDevice ( ); } Phụ lục 9: Mã nguồn module tạo lịch trình gửi dữ liệu vào mạng. void VoVBuffer::txTimerExpired() { if ( ( txBuffer->count( ) txFlag ) { txBufferProgressBar->setProgress( txBuffer->count( ) ); return; } else capturer->txFlag = TRUE; if ( txBuffer->isEmpty( ) && !capturer->txFlag ) { txTimer->stop(); stateInfor->info(); return; } if ( txBuffer->isEmpty( ) && capturer->txFlag ) { return; } else { rtp_header_t * rtpHeader = new rtp_header_t; rtpHeader ->seqNumber = txBuffer->at(0)->seqNumber; rtpHeader ->length = txBuffer->at(0)->length; rtpHeader ->timeStamp = QTime::currentTime ( Qt::UTC ); - xvii - int headerSize = sizeof (rtp_header_t ); int packetSize = headerSize + txBuffer->at(0)->length; if ( ( txBuffer->at(0)->mark != 0) { switch ( codecType ) { case PCM : rtpHeader->payloadType = PCM; break; case SPEEX: rtpHeader->payloadType = SPEEX; } } else rtpHeader->payloadType = SILENCE; char * rtpPacket = (char * ) malloc ( packetSize); memcpy (rtpPacket , rtpHeader , headerSize ); memcpy (rtpPacket+headerSize, txBuffer->at(0)->data, txBuffer->at(0)->length); sendDataToNetwork ( rtpPacket, packetSize); delete rtpHeader; free ( rtpPacket ); txBuffer->removeFirst(); } Phụ lục 10: Mã nguồn thực hiện thuật toán thu nhận dữ liệu từ mạng và lưu vào bộ đệm phía thu. Module chương trình thực hiện thao tác đọc dữ liệu từ socket, tách dữ liệu mang tín hiệu phát thanh lưu vào bộ đệm tại tạo, xử lý thông tin điều khiển, giải mã tín hiệu và tính toán thời điểm tái tạo tín hiệu phát thanh của mỗi gói tin. Mã nguồn chương trình: # define alpha 0.998002 - xviii - void PlayoutBuffer::receiveData ( char * data, int size) { rtp_header_t * rtpHeader = new rtp_header_t; rtpHeader = (rtp_header_t * ) data; int inputSize; inputSize = rtpHeader ->length; char * inputData = ( char * ) malloc ( inputSize ); int nbBytes = speexDecode->getEncodedByte ( qualityLevel ); int outputSize = inputSize * FRAME_SIZE * sizeof ( short ) / nbBytes; char* outputData = ( char * ) malloc ( outputSize); QTime rxTime = QTime::currentTime ( Qt::UTC ); long rxTime = timeConversion ( rxTime ); long txTime = timeConversion (rtpHeader->txTime); int currentNetworkDelay = rxTime - txTime; memcpy ( inputData , data + sizeof ( rtpHeader ), inputSize); if ( rtpHeader->payloadType == SILENCE ) { startTalkSpurt = FALSE; return; } else { sound_item_t *item = new sound_item_t; item->seqNumber = rtpHeader->seqNumber; switch ( rtpHeader->payloadType ) { case PCM : - xix - item->length = inputSize; item->data = ( char * ) malloc ( item->length ); memcpy ( item->data , inputData , inputSize ); break; case SPEEX : item->length = speexDecode->decodeData ( inputData , inputSize, nbBytes , outputData); item->data = ( char * ) malloc ( item->length); memcpy ( item->data , outputData, item->length ); break; } if ( startTalkSpurt ) { // bắt đầu một chu kỳ tín hiệu phát thanh tích cực mới. if ( !startFlag ) { // bắt đầu nhận dữ liệu, khởi tạo đồng hồ tạo lịch trình tái tạo tín hiệu. previousPlayoutTime = rxTime; playoutTime = ( int ) ( txTime + currentAvarageDelay + 4 * currentDelayVariation ); item->interval = playoutTime - previousPlayoutTime; previousPlayoutTime = playoutTime; pushDataToPlayoutBuffer ( item ); if ( algorithmType == SPIKE_DET ) { beforePreviousNetworkDelay = currentNetworkDelay; previousNetworkDelay = currentNetworkDelay; - xx - delayMode = NORMAL; } playoutTimer->start ( item->interval, TRUE ); startFlag = TRUE ; } else { // Thiết lập thời điểm tái tạo tín hiệu của gói đầu tiên của chu kỳ tín hiệu phát thanh tích cực mới . playoutTime = ( int ) ( txTime + curentAverageDelay + 4 * currentDelayVariation ); item->interval = playoutTime - previousPlayoutTime; previousPlayoutTime = playoutTime; // Đưa dữ liệu vào bộ đệm tái tạo pushDataToPlayoutBuffer ( item ); // Ước đoán trễ mạng. networkDelayEstimation ( currentNetworkDelay ); } startTalkspurt = TRUE; } else { // Tái tạo tín hiệu từ các gói tin trong cùng chu kỳ tín hiệu tích cực. playoutTime = previousPlayoutTime + packetTimeLength; // Thiết lập thời điểm tái tạo tín hiệu. item->interval = playoutTime - previousPlayoutTime; previousPlayoutTime = playoutTime; // Đưa dữ liệu vào bộ đệm tái tạo pushDataToPlayoutBuffer ( item ); // Ước đoán trễ mạng. - xxi - networkDelayEstimation ( currentNetworkDelay ); } } } Phụ lục 11: Mã nguồn thực hiện thuật toán ước đoán trễ mạng và biến động trễ trung bình của gói tin phục vụ quá trình tái tạo tín hiệu thích ứng Trễ mạng ước đoán được xác định thông qua hàm: void PlayoutBuffer::networkDelayEstimation ( int currentNetworkDelay); Căn cứ vào trễ mạng của gói tin hiện tại currentNetworkDelay [ms]. Thuật toán hàm trung bình mũ EXP_AVG và thuật toán SPIKE_DETECT được sử dụng để tính toán trễ mạng trung bình currentAverageDelay và biến động trễ mạng trung bình currentDelayVariation. Các thông số trên được sử dụng phục vụ việc tạo lịch trình tái tạo tín hiệu phát thanh thích ứng theo tình trạng trễ mạng. Mã nguồn chương trình: # define spike_factor 0.875 void PlayoutBuffer::networkDelayEstimation ( int currentNetworkDelay) { swicth ( algorithmType ) { case EXP_AVG: currentAverageDelay = alpha * previousAverageDelay + ( 1 - alpha ) * currentNetworkDelay ; currentDelayVariation = alpha * previousDelayVariation + ( 1 - alpha ) * abs ( currentAverageDelay - currentNetworkDelay ); break; case SPIKE_DET: if (delayMode == NORMAL ) { - xxii - if ( abs ( currentNetworkDelay - previousNetworkDelay ) > abs ( 2 * currentDelayVariation ) + 800 ) { // đột biến trễ bắt đầu xuất hiện var = 0; delayMode = SPIKE; } } else { // mode:: SPIKE var = var / 2 + abs ( 2 * currentNetworkDelay - previousNetworkDelay - beforePreviousNetworkDelay ) / 8; if ( var <= 63 ) { delayMode = NORMAL; beforePreviousNetworkDelay = previousNetworkDelay; previousNetworkDelay = networkDelay; return; } } if ( delayMode == NORMAL ) { currentAverageDelay = (1 - spike_factor) * currentNetworkDelay + spike_factor * previousAverageDelay; } else - xxiii - { // delayMode:: SPIKE currentAverageDelay = previousAverageDelay + ( currentNetworkDelay - previousNetworkDelay); } currentDelayVariation = spike_factor * previousDelayVariation + (1 - spike_factor) * abs (curentNetworkDelay - current AverageDelay); beforePreviousNetworkDelay = previousNetworkDelay; previousNetworkDelay = currentNetworkDelay; break; } }