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.
84 trang |
Chia sẻ: lylyngoc | Lượt xem: 2514 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu 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, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
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;
}
}
Các file đính kèm theo tài liệu này:
- roip_hut_phan_2__3549.pdf