Cấu Trúc Thông Tin Bổ Sung Của Transport_Protocol_Label (Truyền Qua Oc)[8]

Bảng 4.4: Cấu trúc thông tin bổ sung của transport_protocol_label (truyền qua OC)[8]

selector_bytes()

Truyền qua OC

Số

bit

Giải thích

remote_connection

1


reserved

7


If(remote_connection=1) { origial_network_id ts_id

service_id

}


16

16

16

Tùy chọn, tham chiếu đến dòng thành phần mang OC từ mạng/dòng truyền/kênh khác.

component_tag

8

Tham chiếu đến dòng thành phần thông qua nhãn nhận diện được gán trong mô tả stream_identifier trong PMT của dòng

thành phần mang OC.

Có thể bạn quan tâm!

Xem toàn bộ 89 trang tài liệu này.

Bảng 4.5: Cấu trúc thông tin bổ sung của transport_protocol_label (truyền qua băng rộng)[8]

selector_bytes()

Truyền qua băng rộng

Số

bit

Giải thích

For (i=0;i<N;i++) {



url_base_length url_base_bytes()

8

8

Địa chỉ gốc của ứng dụng, có dạng “http://” và kết thúc bằng “/”.

For (j=0;j<M, j++) {


Các địa chỉ mở rộng của ứng dụng

url_extension_length

8

url_extension_bytes()


}


}



Chú ý: Nhiều khai báo giao thức truyền băng rộng có thể gán cùng nhãn để xác định nhiều địa chỉ URL hơn cho ứng dụng.

Khai báo giao thức truyền:

Mỗi ứng dụng phải tham chiếu ít nhất một mô tả giao thức thông qua nhãn nhận diện để xác định giao thức truyền thực sự. Tùy vào đầu thu hỗ trợ, một ứng

dụng có thể sử dụng kết hợp nhiều giao thức. Trường hợp này xem như phương án dự phòng và thứ tự giao thức tham chiếu chính là thứ tự ưu tiên. Đầu thu sẽ chọn giao thức dựa vào các yếu tố khác nhau. Có thể do thiết lập người dùng trong đầu thu, hay dựa vào chất lượng truyền của mỗi giao thức tại từng thời điểm.

Việc xác định giao thức truyền cho mỗi ứng dụng được thực hiện trong bộ mô tả application_descriptor đặt trong vòng lặp trong của từng ứng dụng. Mô tả có cấu trúc như trong bảng 4.6 sau:

Bảng 4.6: Cấu trúc bộ mô tả application_descriptor[8]



Số bit

Giải thích

application_descriptor {



descriptor_tag

8

Nhận diện loại mô tả, có trị 0x0

descriptor_length

8

Chiều dài phần phía sau (byte)

application_profile_length

8

Vòng lặp mô tả các profile của chuẩn cần để thực thi ứng dụng. Ứng dụng cần profile cơ bản có bộ giá trị (0,1,1,1).

for( i=0;i<N;i++) {


application_profile Version.major Version.minor

Version.micro

16

8

8

8

}



service_bound_flag

1

Cho biết ứng dụng có liên hệ với kênh

chương trình hay không.

Visibility

2

Ứng dụng được nhìn thấy đối với các hàm

API truy xuất danh sách ứng dụng không.

Reserved

5


application_priority

8

Mức ưu tiên ứng dụng, giá trị lớn hơn cho mức ưu tiên cao hơn. Trường hợp có nhiều ứng dụng có cùng application_id trong kênh, ứng dụng có độ ưu tiên cao hơn sẽ được chọn thực thi. Hoặc trong trường hợp

tài nguyên hệ thống giới hạn, đầu thu sẽ ưu




tiên ứng dụng có mức ưu tiên cao hơn.

for( i=0;i<N;i++) { transport_protocol_label

}


8

Xác định phương thức truyền ứng dụng thông qua nhãn giao thức đã được gán trong bộ mô tả

transport_protocol_descriptor.

Xác định điểm (trang) bắt đầu ứng dụng:

Sử dụng bộ mô tả simple_application_location_descriptor, đặt trong vòng lặp mô tả trong của mỗi ứng dụng. Cú pháp được thể hiện trong bảng số bảng 4.7 như sau:

Bảng 4.7: Cấu trúc bộ mô tả simple_application_location_descriptor[8]


Cú Pháp

Số

bit

Giải thích

simple_application_location_descriptor

{



descriptor_tag

8

Nhận diện loại mô tả , có trị 0x15

descriptor_length

8

Chiều dài phần phía sau (byte)

initial_path_bytes()


Đường dẫn chỉ đến trang khởi tạo

ứng dụng

}



Giả sử ứng dụng được tổ chức thành 2 thư mục con main và image. Trang khởi tạo là index.html lưu trong thư mục main. Như vậy, nếu ứng dụng truyền qua OC bắt đầu tại thư mục gốc của ứng dụng, thì initial_path_bytes sẽ có trị “main/index.html”. Còn nếu truyền qua kênh ngược, url_base_bytes có trị “http://<domain>/địa chỉ gốc của ứng dụng” và initial_path_bytes sẽ có trị “main/index.html”. Nếu đặt toàn bộ ứng dụng trong thư mục con khác có tên “application” chẳng hạn, thì initial_path_bytes sẽ là “application/main/index.html”. Báo hiệu ứng dụng qua kết nối băng rộng:

Thông tin báo hiệu ứng dụng thường được truyền trong dòng quảng bá trong các section AIT như mô tả chi tiết ở trên. Bên cạnh đó, HbbTV cũng cho phép cung cấp thông tin báo hiệu ứng dụng thông qua kết nối băng rộng. Báo hiệu theo cách này chỉ dùng cho các ứng dụng độc lập quảng bá.

Một nhóm các ứng dụng độc lập quảng bá được liệt kê trong file có định dạng

*.xml ait, cũng gồm những thông tin báo hiệu tương tự trong AIT. Trong trường hợp này, một số thông tin chỉ có giá trị giới hạn như dùng giao thức truyền HTTP (protocol_id = 0x3), thông tin kiểm soát trạng thái ứng dụng là AUTOSTART hoặc PRESENT. Việc xác định địa chỉ tham chiếu đến file báo hiệu được thực thiện thông qua thủ tục tạo ứng dụng (application.createApplication) trong một ứng dụng liên quan quảng bá đang chạy.

4.4.2 Khai báo dòng con AIT

Không giống một số bảng SI truyền trong các gói có mã nhận diện PID cố định, AIT và OC được truyền trong dòng thành phần riêng và phải được khai báo trong PMT như các dòng thành phần khác của kênh. Khai báo bổ sung dòng thành phần trong PMT là công việc bắt buộc giúp đầu thu kiểm soát toàn bộ cấu trúc dòng truyền. Mỗi khai báo mang các thông tin quan trọng như loại dữ liệu trong dòng (stream_type), mã nhận diện các gói thuộc dòng (elementary_PID) và một số thông tin chi tiết khác ứng với từng loại dòng được đặt trong vòng lặp mô tả theo sau. Dòng mang AIT: có stream_type = 0x05, sử dụng mô tả application_signalling gồm hai thông tin chính: loại ứng dụng AIT khai báo (application_type) và phiên bản AIT (AIT_version_number). Khi phát hiện có phiên bản mới, đầu thu sẽ truy xuất AIT theo phiên bản mới này, cú pháp mô tả như sau:

Bảng 4.8: Cấu trúc bộ mô tả application_signalling_descripor [8]


Cú pháp

Số

bit

Giải thích

application_signalling_descriptor {



descriptor_tag

8

Nhận diện loại mô tả , có trị 0x6F

descriptor_length

8

Chiều dài phần phía sau (byte)

For( i =0;i<N;i++) {



reserved

1


application_type

15

Xác định loại ứng dụng được báo hiệu trong

AIT, ứng dụng HbbTV có trị 0x10

reserved

3


AIT_version_number

5

Phiên bản AIT hiện tại

}



}



Dòng mang OC: có stream_type = 0xB, sử dụng các mô tả gồm:

Cú Pháp

Số

bit

Giải thích

data_broadcast_id_descriptor {



descriptor_tag

8

Nhận diện loại mô tả , có trị 0x66

descriptor_length

8

Chiều dài phần phía sau (byte)

data_broadcast_id

8

Nhận diện loại dữ liệu trong OC, có trị

0x123 cho OC mang ứng dụng HbbTV.

}



Data_broadcast_id_descriptor: xác định loại ứng dụng trong dòng mang OC Bảng 4.9: Cấu trúc bộ mô tả data_broadcast_id_descriptor [8]


Stream_identifier_descriptor: gán nhãn nhận diện dòng thành phần, dùng để tham chiếu trong OC

Bảng 4.10: Cấu trúc bộ mô tả stream_identifier_descriptor [8]



Số

bit

Giải thích

stream_identifier_descriptor {



descriptor_tag

8

Nhận diện loại mô tả, có trị 0x52

descriptor_length

8

Chiều dài phần phía sau (byte)

component_tag

8

Gán nhãn nhận diện dòng thành phần

}




Carousel_identifier_descriptor: định danh carousel mang ứng dụng


Bảng 4.11: Cấu trúc bộ mô tả carousel_identifier_descriptor [8]



Số

bit

Giải thích

carousel_identifer_descriptor{



descriptor_tag

8

Nhận diện loại mô tả, có trị 0x13

descriptor_length

8

Chiều dài (byte) phần phía sau

carousel_id

8

Mã nhận diện carousel

}



4.4.3 Truyền ứng dụng

Ứng dụng lai ghép sẽ được truyền đến đầu thu theo giao thức truyền được khai báo trong trong AIT. Ứng dụng có thể sử dụng cả hai phương thức. Nếu truyền qua dòng truyền MPEG2, ứng dụng được đóng gói theo giao thức OC. Đây là một giao thức phức tạp, không được đề cập trong báo cáo này.

Trong trường hợp ứng dụng có sử dụng dòng thông tin đồng bộ, bắt buộc phần thông tin này phải truyền qua dòng MPEG2.

4.5 Đồng bộ ứng dụng HbbTV

4.5.1 Định nghĩa sự kiện

Khái niệm sự kiện (event) được DSM - CC đưa ra để dùng trong trường hợp cần đồng bộ giữa chương trình quảng bá và ứng dụng tương tác. Có thể xem sự kiện là một tín hiệu đặc biệt được đưa vào dòng truyền quảng bá để báo cho đầu thu thực hiện một số tác vụ cụ thể tại thời điểm xác định. Các báo hiệu được mang trong dòng thành phần riêng, và không nhất thiết phải truyền liên tục. Mỗi sự kiện khi báo hiệu có thể bao gồm dữ liệu kèm theo. Có thể tạo nhiều tín hiệu khác nhau cho từng mục đích khác nhau. Nhiều sự kiện có thể truyền song song trong dòng truyền, giữa chúng được phân biệt bằng mã nhận diện riêng.

Đối tượng streamevent trong OC:

Về cơ bản, DSM-CC OC đóng gói file, thư mục ứng dụng và truyền chúng theo cơ chế lặp mà đầu thu có thể dễ dàng nhận được từng thành phần dữ liệu riêng. OC bao gồm 3 đối tượng chính: ServiceGatewayMessage (cấu trúc thư mục gốc), DirectoryMessage (cấu trúc các thư mục con) và FileMessage (dữ liệu file). Ngoài ra, OC còn hỗ trợ đối tượng StreamEventMessage. Đây là đối tượng đặc biệt không lưu bất kỳ dữ liệu nào thuộc ứng dụng. Nó dùng để định nghĩa các sự kiện có trong dòng truyền, cũng như cách tham chiếu đến dòng thành phần tương ứng mang thông tin kích hoạt sự kiện. Thông tin mô tả cho mỗi sự kiện bao gồm mã nhận diện, tên sự kiện và tham chiếu dòng con được mô trả trong hình 4.3.


Hình 4 3 Mô hình phát lặp dữ liệu theo giao thức OC Chuẩn DSMCC OC vốn rất 1


Hình 4.3: Mô hình phát lặp dữ liệu theo giao thức OC

Chuẩn DSMCC OC vốn rất phức tạp, bao gồm các cấu trúc dữ liệu đan xen, nhiều cấu trúc quan trọng trong chuẩn đã được đề cập chi tiết trong đề tài trước đây. Cấu trúc chi tiết của đối tượng StreamEventMessage được mô tả sau đây:

Bảng 4.12: Cấu trúc đối tượng BIOP::StreamEventMessage [8]


Cú pháp

Số byte

Diễn giải

BIOP::StreamEventMessage(){



Magic

4

Báo hiệu bắt đầu đối tượng, có trị

“BIOP”

Biop::version

2

Phiên bản đối tượng, trị “1.0”

Byte_order

1

Thứ tự mã hóa byte, mặc định 0

message_type

1

Loại đối tượng, trị 0 (đối tượng tải)

message_size

4

Kích thước đối tượng (từ sau trường này)

objectKey_length

1

Chiều dài objectKey_data, tối đa 4 byte

objectKey_data


Chỉ danh đối tượng

objectKind_length

1

Chiều dài objectKind_data, tối đa 4 byte

objectKind_data

4

Loại đối tượng StreamEvent, có trị “ste ”

objectInfo_length

2

Thông tin thêm

DSM::Event_EventList_T(){




eventNames_count



Liệt kê tên của những sự kiện dòng

for (eventNames_count) {


eventName_len


eventName_data


}


}


messageBody_len


Tham chiếu các dòng con mang thông tin

kích hoạt sự kiện

taps_count


for (taps_count) {



id


Nhận diện loại tham chiếu dòng con, trị 0

use

1

Mục đích sử dụng dòng con được tham chiếu. Trường hợp này sẽ tham chiếu đến dòng kích hoạt sự kiện (xem phần sau) có

trị 0xD (STR_EVENT_USE)

association_tag


Nhãn nhận diện dòng con (được gán

trong PMT)

selector_len

2

Thông tin thêm, không được dùng

}



eventIds_count

2

Danh sách mã sự kiện, đồng nhất với danh sách tên sự kiện trong EventList

for (eventIds_count) {

1

eventId


}



}



File định dạng xml

Như vậy nếu ứng dụng được truyền qua băng rộng nhưng có định nghĩa sự kiện, thì dòng truyền phải gồm các cấu trúc dữ liên quan cho một OC chứa định nghĩa này. Tuy nhiên, ứng dụng truyền qua băng rộng cũng có thể tải kèm file định nghĩa ở dạng *.xml. File gồm những thông tin tương đương với đối tượng StreamEventMessage trong OC, file xml được định nghĩa theo lược đồ sau:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!--W3C Schema generated by XMLSpy v2006 sp2 U (http://www.altova.com)-->

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchemaxmlns:dsmcc="urn:dvb:mis:dsmcc:2009"

..... Xem trang tiếp theo?
⇦ Trang trước - Trang tiếp theo ⇨

Ngày đăng: 18/02/2023