4.4.1 Báo hiệu ứng dụng, dịch vụ
Báo hiệu trong dòng quảng bá
Cấu trúc thông tin báo hiệu:
Thiết bị thu luôn theo dõi dòng truyền để biết danh sách ứng dụng, dịch vụ đang được cung cấp. Giống như chuẩn MHP, thông tin này được truyền trong AIT (Application Information Table). Khi người dùng chọn kênh hoặc một phiên bản AIT mới được truyền, đầu thu tự động cập nhật AIT kiểm soát việc bắt đầu hoặc dừng của các ứng dụng. Mỗi kênh cần khai báo ứng dụng phải kèm theo bảng con AIT, liệt kê tất cả các ứng dụng trong kênh. AIT được tổ chức theo cấu trúc section và được đóng gói và truyền giống như các bảng SI khác, AIT có cấu trúc như bảng 4.1 như sau:
45 Bảng 4.1: Cấu trúc AIT [8] Cú pháp Chiều dài (bit) Diễn giải Application_Information_section() {
table_id 8 Mã nhận diện bảng AIT,
0x74 section_syntax_indicator reserved section_length 1 3 12 application_type 16 Ứng dụng HbbTV có trị 0x10 Reserved 2
version_number 5 Theo dõi cập nhật thông
tin báo hiệu current_next_indicator section_number last_section_number reserved 1 8 8 4 common_descs_len descriptors 12 8 Vòng lặp mô tả chung cho các ứng dụng trong AIT này. reserved application_loop_len 4 12 for (i=0;i<N;i++){ org_id app_id app_control_code reserved app_descs_loop_len for(j=0;j<N;j++){ descriptor() } } 32 16 8 4 12 Chỉ danh ứng dụng, có miền giá trị do DVB định nghĩa. Mã kiểm soát ứng dụng (xem bảng 4.2) Vòng lặp mô tả riêng của mỗi ứng dụng .
CRC_32 }
46
Bảng 4.2: Giá trị mã kiểm soát ứng dụng [8]
Control Code Giá trị Diễn giải
AUTOSTART 1 Ứng dụng tự động chạy khi chọn kênh.
PRESENT 2 Ứng dụng được phép chạy (nhưng không tự động) trong khi kênh được chọn.
DESTROY 3 Ứng dụng bị buộc kết thúc. Không thể chạy lại. KILL 4 Ứng dụng sẽ sớm bị dừng. Không thể chạy lại. PERFETCH 5 Ứng dụng được lưu tạm trong đầu thu nếu có thể.
Ứng dụng sẽ không tự bắt đầu.
REMOTE 6 Ứng dụng không thuộc dòng truyền hiện tại.
DISABLE 7 Ứng dụng không thể chạy.
Mô tả giao thức truyền ứng dụng:
Trong môi trường lai ghép HbbTV, ứng dụng có thể được truyền theo hai phương thức: qua dòng truyền quảng bá dùng giao thức OC, hay qua kết nối băng rộng dùng giao thức HTTP. Giao thức truyền phải được mô tả trong transport_protocol_descriptor. Mô tả có thể đặt trong vòng lặp mô tả chung hay vòng lặp mô tả riêng của từng ứng dụng. Mỗi mô tả được gán nhãn nhận diện để được tham chiếu sử dụng. Cấu trúc chi tiết bộ mô tả như được thể hiện trong bảng 4.3, bảng 4.4, bảng 4.5 dưới đây:
Bảng 4.3: Cấu trúc bộ mô tả transport_protocol_descriptor [8]
Cú pháp Số bit
Giải thích
transport_protocol_descriptor {
descriptor_tag 8 Nhận diện loại mô tả , có trị 0x2 descriptor_length 8 Chiều dài (byte) phần phía sau protocol_id 16 Xác định giao thức truyền:
0x0001: truyền qua OC
0x0003: truyền qua băng rộng transport_protocol_label 8 Gán nhãn nhận diện giao thức
selector_bytes() Thông tin chi tiết ứng với từng giao thức, xem bên dưới.
47
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.
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
48
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
49
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á.
50
*.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
}
51
Dòng mang OC: có stream_type = 0xB, sử dụng các mô tả gồm:
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]
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. }
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
52
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 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.
53
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
54 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://
55 targetNamespace="urn:dvb:mis:dsmcc:2009" elementFormDefault="qualified" attributeFormDefault="qualified"> <xs:complexType name="DsmccType"> <xs:sequence> <xs:element name="dsmcc_object" type="dsmcc:DsmccObjectType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:element name="dsmcc" type="dsmcc:DsmccType"/> <xs:complexType name="DsmccObjectType"> <xs:sequence> <xs:element name="stream_event" type="dsmcc:StreamEventType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>
<xs:attribute name="component_tag" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="StreamEventType">
<xs:attribute name="stream_event_id" type="xs:string" use="required"/>
<xs:attribute name="stream_event_name" type="xs:string" use="required"/>
</xs:complexType> </xs:schema>
4.5.2 Kích hoạt sự kiện
Khi phía phát muốn gửi bất kỳ báo hiệu nào đến người dùng, thông tin kích hoạt sự kiện sẽ được chèn vào dòng truyền MPEG2. Dòng thông tin đặc biệt này chính là dòng thành phần được định nghĩa tham chiếu trong đối tượng
56
StreamEventMessage ở trên. Thông tin kích hoạt sự kiện cho biết sự kiện nào đang được kích hoạt thông qua mã nhận diện sự kiện và dữ liệu kèm theo nếu có. Thông tin được truyền theo cấu trúc section, như sau:
Bảng 4.13: Cấu trúc DSMCC_section [9]
Cú Pháp Số bit
Giải thích
DSMCC_section() {
table_id 8 0x3D, cấu trúc mang thông tin mô tả dòng (Stream Descriptors)
section_syntax_indicator 1 1
private_indicator 1 0
reserved 2
dsmcc_section_length 12 Chiều dài phần phía sau (byte)
table_id_extension 16 Mã sự kiện được kích hoạt (event_id)
reserved 2
version_number 5 Báo kích hoạt sự kiện cho đầu thu thông qua cập nhật phiên bản
current_next_indicator 1 1
section_number 8
last_section_number 8 StreamEventDescriptor() { 8
descriptorTag 8 0x1A: Stream Event descriptor
descriptorLength 8
eventId 16 Mã nhận diện sự kiện
reserved 31
eventNPT 33 bỏ qua (=0)
privateDataByte() }
dữ liệu kèm theo sự kiện, đầu thu không phân tích dữ liệu này, ứng dụng sẽ thực hiện khi cần.
CRC_32 32
}
Việc tách riêng định nghĩa sự kiện với dòng báo hiệu sự kiện giúp dễ dàng sử dụng lại các sự kiện được định nghĩa. Các dòng báo hiệu sự kiện có thể mang những sự kiện có cùng eventId, thậm chí các sự kiện trong đó được báo hiệu tại những thời điểm khác nhau kèm theo dữ liệu khác nhau. Điều này cho phép một
57
ứng dụng sử dụng một eventId cho nhiều sự kiện có đặc tính giống nhau. Chẳng hạn trong một trận đấu, có thể sử dụng một eventId để báo hiệu mỗi khi bàn thắng được ghi, một eventId khác báo hiệu đá phạt trực tiếp, và một eventId khác nữa báo kết thúc trận đấu. Như vậy trong thời gian trận đấu diễn ra, ứng dụng chỉ cần quan tâm đến 3 nhóm sự kiện này. Trong một số trường hợp, báo hiệu sự kiện không có dữ liệu kèm theo.
Khai báo dòng sự kiện
Cũng như mọi dòng thành phần khác, để đầu thu có thể nhận diện, dòng thành phần mang thông tin kích hoạt sự kiện phải được khai báo trong PMT của kênh xác định. Thông tin khai báo theo cấu trúc sau:
Bảng 4.14: Cấu trúc khai báo loại dòng thành phần [10]