Tiêu chuẩn quốc gia TCVN 11819:2017 về Khối truy nhập có điều kiện dùng trong truyền hình kỹ thuật số

• Số hiệu: TCVN11819:2017
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2017

E {K} (M)	Mã hóa bản tin 'M' sử dụng khóa 'K'
D {K} (M)	Giải mã bản tin 'M' sử dụng khóa 'K'
P	Khóa công khai
Q	Khóa riêng
DQ	Khóa riêng thiết bị
DP	Khóa công khai thiết bị
A {K} (M)	Xác thực của bản tin 'M' với khóa 'K'
V {K} (M)	Kiểm tra bản tin 'M' với khóa 'K'
AÅB	Toán tử XOR của 'A' và 'B'
A I B	Toán tử OR của 'A' và 'B'
A II B	Toán tử AND của 'A' và 'B'
0x...	Tiền tố này chỉ thị có một giá trị thập lục phân theo sau.
0b...	Tiền tố này chỉ thị có một giá trị nhị phân theo sau.
3.3  Chữ viết tắt
Theo mục đích của tiêu chuẩn này, các chữ viết tắt sau đây được áp dụng:
AES	Advanced Encryption Standard	Tiêu chuẩn mã hóa tiên tiến
APDU	Application Protocol Data Unit	Đơn vị dữ liệu giao thức ứng dụng
API	Application Programming Interface	Giao diện lập trình ứng dụng
APS	Analogue Protection System	Hệ thống bảo vệ tương tự
ASN.1	Abstract Cú pháp Notation One	Ký hiệu cú pháp trừu tượng 1
AV	Audio Video	Âm thanh và hình ảnh
BAT	Bouquet Association Table	Bảng liên kết nhóm dịch vụ
bslbf	Bit serial leftmost bit first	Bit tận cùng bên trái nối tiếp bit đầu
BSM	Basic Service Mode	Chế độ dịch vụ cơ bản
CA	Conditional Access	Truy nhập có điều kiện
CAM	Conditional Access Module	Mô-đun truy nhập có điều kiện
CAS	Conditional Access System	Hệ thống truy nhập có điều kiện
CBC	Cipher Block Chaining	Thuật toán mã hóa khối chuỗi
CC	Content Control	Kiểm soát nội dung
CCK	Content Control Key	Mã khóa kiểm soát nội dung
Cl	Common Interface	Giao diện chung
CICAM	Common Interface Conditional Access Module	Mô-đun truy nhập có điều kiện giao diện chung
CICAM_ID	CICAM's unique identification number	Số nhận dạng duy nhất của CICAM
CRL	Certificate Revocation List	Danh sách thu hồi giấy chứng nhận
CWL	Certificate White List	Danh sách trắng giấy chứng nhận
DES	Data Encryption Standard	Tiêu chuẩn mã hóa dữ liệu
DH	Diffie-Hellman	Diffie-Hellman
DOT	Digital Only Token	Bit nhận biết sử dụng nén đối với nội dung số
DSM-CC	Digital Storage Media - Command and Control	Phương tiện lưu trữ kỹ thuật số - điều khiển và kiểm soát
DTV	Digital Television	Thiết bị truyền hình kỹ thuật số
DVB	Digital Video Broadcast	Truyền hình kỹ thuật số
ECB	Electronic Code Book	Sách mã điện tử
ECM	Entitlement Control Message	Bản tin kiểm soát quyền
EIT	Event Information Table	Bảng thông tin sự kiện
EMI	Encryption Mode Indicator	Chỉ số chế độ mã hóa
EMM	Entitlement Management Message	Bản tin quản lý quyền
Eq.	Equation	Công thức
FQDN	Fully Qualified Domain Name	Tên miền đạt tiêu chuẩn
FTA	Free-To-Air	Truyền hình miễn phí
Host	Host	Máy chủ/ Thiết bị chủ/ chính
HOST_ID	Host device unique identification number	Số nhận dạng duy nhất thiết bị máy chủ
ICT	Image Constraint Token	Bit nhận biết nén hình ảnh
IV	Initialisation Véc-tơ	Véc-tơ khởi tạo
Key	Key	Mã khóa/ Khóa.
LSB	Least Significant Bit	Bit ít quan trọng nhất
MAC	Message Authentication Code	Mã xác thực bản tin
mjdutc	Modified Julian Date UTC	UTC theo ngày Julian sửa đổi
MMI	Man Machine Interface	Giao diện người máy
MHEG	Multimedia and Hypermedia Experts Group	Nhóm nghiên cứu đa phương tiện và siêu phương tiện
MPEG	Motion Pictures Experts Group	(Chuẩn) Nhóm nghiên cứu hình ảnh động/ MPEG
NIT	Network Information Table	Bảng thông tin mạng
PCMCIA	PC Memory Card International Association	(Chuẩn giao diện) Hiệp hội thẻ nhớ máy tính quốc tế/ PCMCIA
PIN	Personal Identification Number	Số nhận dạng cá nhân
PMT	Programme Map Table	Bảng sắp xếp chương trình
PPV	Pay-Per-View	Trả phí khi xem
PKI	Public Key Infrastructure	Hạ tầng khóa công khai
PSI	Program Specific Information	Thông tin cụ thể chương trình
RCT	Redistribution Control Token	Mã kiểm soát phân phối lại
RFC	Request For Comment	(Chuẩn) Đề nghị bình luận/ RFC
ROT	Root Of Trust (i.e. Trust Authority)	Nguồn gốc tin cậy (tức là Tổ chức tin cậy)
RSA	Rivest Shamir Adleman public key cryptographic algorithm	Thuật toán mã hóa mã khóa công khai Rivest Shamir Adleman
RSD	Revocation Signalling Data	Dữ liệu thông báo thu hồi
RSM	Registered Service Mode	Chế độ đăng ký dịch vụ
SAC	Secure Authenticated Channel	Kênh xác thực an toàn
SAK	SAC Authentication Key	Mã khóa xác thực SAC
SDT	Service Descriptor Table	Bảng nhãn mô tả dịch vụ
SEK	SAC Encryption Key	Mã khóa mã hóa SAC
SHA	Secure Hash Algorithm	Thuật toán băm an toàn
SIV	SAC Initialisation Véc-tơ	Vec tơ khởi tạo SAC
SOCRL	Service Operator Certificate Revocation List	Danh sách thu hồi giấy chứng nhận của nhà điều hành dịch vụ
SOCWL	Service Operator Certificate White List	Danh sách trắng giấy chứng nhận của nhà điều hành dịch vụ
SOPKC	Service Operator Public Key Certificate	Giấy chứng nhận mã khóa công khai của nhà điều hành dịch vụ
SMS	Short Message Service (mobile phone)	Dịch vụ nhắn tin ngắn (điện thoại di động)
SRM	System Renewability Message	Bản tin làm mới lại hệ thống
SSAC	Single Source Authenticity Check	Kiểm tra xác thực nguồn gốc đơn
SSU	System Software Update	Cập nhật phần mềm hệ thống
TLF	Tag Length Format	Định dạng độ dài thẻ
TS	Transport Stream	Dòng truyền tải
TSC	Transport Scrambling Control	Kiểm soát xáo trộn truyền tải
UCK	URI Confirmation Key	Mã khóa xác nhận URI
uimsbf	Unsigned integer most significant bit first	Số nguyên không dấu bit quan trọng nhất đầu tiên
URI	Usage Rules Information	Thông tin các quy tắc sử dụng
UTC	Coordinated Universal Time	Giờ phối hợp quốc tế
VOD	Video On Demand	Truyền hình theo yêu cầu

4  Tổng quan hệ thống

4.1  Giới thiệu

Hệ thống kiểm soát nội dung được mô tả trong tiêu chuẩn này nhằm hỗ trợ một liên kết an toàn dành cho các gói tin dòng truyền tải giữa một CICAM và một máy chủ. Hệ thống kiểm soát nội dung này xác định phần mở rộng đối với chuẩn DVB-CI để bổ sung các tính năng và bản tin giao thức trên cả hai thiết bị để bảo vệ nội dung được lựa chọn khỏi việc bị sao chép.

Nếu nội dung (nội dung xáo trộn CA hoặc nội dung rõ ràng) được người sử dụng lựa chọn không phải bảo vệ (tức là không có thông tin bảo vệ sao chép trong dòng truyền tải liên quan đến nội dung này) thì cả hai thiết bị nên tuân thủ chuẩn DVB-CI EN 50221 [7] & TS 101 699 [8].

Tổng quan về hệ thống được mô tả trong hình 4.1. Nội dung giá trị cao có thể được bảo vệ từ thiết bị đầu cuối đến máy chủ bởi hệ thống CA. Tuy nhiên, khi nội dung đã được giải điều chế và việc xáo trộn của hệ thống CA đã được gỡ bỏ thì nội dung dễ bị sao chép khi nó được truyền qua giao diện chung. Đây là công việc của hệ thống kiểm soát nội dung được quy định trong tiêu chuẩn này để bảo vệ nội dung AV khi nội dung được truyền qua giao diện chung và đến các giao diện AV bên ngoài.

Hình 4.1 - Tổng quan hệ thống

4.2  Các thành phần của hệ thống kiểm soát nội dung

Theo mục đích của tiêu chuẩn này, hệ thống kiểm soát nội dung bao gồm các thành phần sau (xem hình 4.1):

...

...

...

• CICAM

• Thiết bị đầu cuối (Head-end)

Việc bảo vệ phương tiện trước khi hệ thống CA gây hiệu ứng xáo trộn không được xem xét trong tiêu chuẩn này. Tương tự như vậy, ngoài việc truyền thông tin các quy tắc sử dụng (URI), những gì xảy ra với phương tiện sau khi trả lại máy chủ và được giải mã không được xem xét trong tiêu chuẩn này.

Ba thành phần nói trên được mô tả ngắn gọn trong các phần sau:

4.2.1  Máy chủ

Trong phạm vi của tiêu chuẩn này, máy chủ là một thiết bị điện tử tiêu dùng được sử dụng để thu và điều khiển các phương tiện truyền hình kỹ thuật số. Thiết bị này phải có một hoặc nhiều khe cắm giao diện chung dành cho CICAM.

Thông thường, máy chủ có một bộ dò kênh có dạng nào đó, bộ giải điều chế, bộ giải ghép kênh (Demux) và các bộ giải mã phương tiện. Chúng là những điều kiện tiên quyết cho việc thu truyền hình kỹ thuật số. Đối với nội dung miễn phí, chúng là tất cả những gì cần thiết để thu và giải mã nội dung kỹ thuật số, đối với nội dung được một hệ thống CA bảo vệ thì máy chủ phải có một CICAM.

DVB CICAM tuân thủ chuẩn EN 50221 [7] không có hệ thống kiểm soát nội dung để bảo vệ nội dung đã được giải xáo trộn. Nội dung đã gỡ bỏ sự bảo vệ của hệ thống CA được truyền đến máy chủ không được bảo vệ. Máy chủ tuân thủ tiêu chuẩn này có thể phối hợp với CICAM để cung cấp một hệ thống kiểm soát nội dung an toàn để bảo vệ nội dung có giá trị cao đã được CA giải xáo trộn.

Máy chủ có thể xác định xem CICAM ghép vào giao diện chỉ tuân thủ chuẩn EN 50221 [7] hay CICAM tuân thủ thêm tiêu chuẩn này. Máy chủ phải hoạt động với cả CICAM Cl Plus và EN 50221 [7] như được nêu trong Bảng 4.1. Nội dung truyền hình miễn phí không bị Cl Plus ngăn cản.

...

...

...

Máy chủ

Cl

Cl Plus

CICAM

Cl

Hành vi Cl mặc định được mô tả trong EN 50.221

Việc ngăn chặn của máy chủ có thể tùy chọn bảo vệ nội dung được kiểm soát khi được thông báo trong dòng truyền tải truyền hình.

...

...

...

Nội dung được Cl CAM giải mã không được mã hóa lại trên giao diện chung.

Cl Plus

Một số nội dung được kiểm soát có thể tùy chọn được giải xáo trộn và truyền đến máy chủ dưới sự kiểm soát của hệ thống CA.

Nội dung được Cl Plus CICAM giải mã không được mã hóa lại trên giao diện chung.

Nội dung được kiểm soát không được hiển thị trừ khi CICAM và máy chủ đã xác thực và máy chủ hỗ trợ các thuật toán mã hóa được Cl Plus quy định và được CICAM yêu cầu.

Nội dung được kiểm soát được CICAM giải mã được mã hóa lại trên giao diện chung tùy theo giá trị EMI trong URI.

Máy chủ bao gồm một bộ công cụ mã hóa và các tính năng cho phép nó kiểm tra xem CICAM được ghép có là một CICAM được xác thực và tin cậy.

4.2.2  CICAM

CICAM bao gồm đầu cuối hệ thống CA của người sử dụng. Nó bao gồm một bộ giải mã CA, giao diện thẻ thông minh tùy chọn và phần mềm để cho phép các mã khóa giải mã được tính toán bằng cách sử dụng dữ liệu từ các dòng thu được.

...

...

...

Ngoài hệ thống bảo vệ cung cấp CA, CICAM bao gồm các công cụ mã hóa và các tính năng cho phép nó xác thực độ tin cậy của máy chủ mà nó đã được ghép vào. Nếu CICAM xác thực máy chủ, nó giải xáo trộn một dịch vụ truyền hình và áp dụng mã hóa kiểm soát nội dung đối với nội dung này.

4.2.3  Thiết bị đầu cuối (Head-end)

Thiết bị đầu cuối là nơi hệ thống CA xáo trộn nội dung bằng cách sử dụng bộ mã hóa hệ thống CA. Thiết bị đầu cuối cũng đưa vào dòng truyền tải các thông tin cụ thể CA khác cho phép CICAM giải xáo trộn nội dung này và quản lý các truy nhập và quyền của thuê bao.

4.3  Nguyên tắc hoạt động chung

Hệ thống kiểm soát nội dung CICAM bao gồm ba thành phần hoạt động sau đây:

• Xác thực máy chủ; dựa trên việc trao đổi giấy chứng nhận máy chủ và CICAM. Mỗi thiết bị kiểm tra giấy chứng nhận của thiết bị kia bằng cách sử dụng các kỹ thuật kiểm tra đóng dấu. Host ID được CICAM (BSM) hoặc Thiết bị đầu cuối (RSM) kiểm tra với một danh sách thu hồi và thực hiện hành động thu hồi thích hợp đối với các thiết bị bị nghi ngờ.

• Kiểm soát nội dung; việc xáo trộn trong kiểm soát nội dung của CICAM đối với nội dung yêu cầu việc truyền được bảo vệ từ CICAM đến máy chủ.

• An toàn nội dung; truyền an toàn các quy tắc sử dụng nội dung từ hệ thống CA đến máy chủ để cho phép việc áp dụng các hạn chế phù hợp đối với các kết nối đầu ra bất kỳ.

Trước tiên, CICAM giải xáo trộn CA đối với nội dung và sau đó xáo trộn lại nội dung “giá trị cao” bằng cách sử dụng CCK trước khi truyền đến máy chủ. Một quá trình giải xáo trộn trong kiểm soát nội dung tương tự xảy ra trong máy chủ.

...

...

...

Hệ thống kiểm soát nội dung yêu cầu xác thực máy chủ và CICAM trước khi kiểm soát nội dung yêu cầu CICAM giải xáo trộn bất kỳ nội dung đã được xáo trộn CA. CICAM yêu cầu giấy chứng nhận của máy chủ và máy chủ cung cấp nó. Máy chủ yêu cầu giấy chứng nhận của CICAM và CICAM cung cấp nó.

Việc xác thực được dựa trên:

• CICAM có thể kiểm tra đóng dấu của giấy chứng nhận thiết bị của máy chủ có chứa Host ID.

• Máy chủ có thể kiểm tra đóng dấu của giấy chứng nhận của CICAM có chứa CICAM ID.

• CICAM và máy chủ chứng minh chúng giữ mã khóa riêng liên kết cặp với mã khóa công khai được nhúng trong giấy chứng nhận bằng cách tạo một mã khóa phiên DH và gửi nó cho thiết bị kia để kiểm tra đóng dấu.

• CICAM và máy chủ chứng minh rằng chúng có thể tạo mã khóa xác thực.

4.5  Trao đổi mã khóa và mã hóa nội dung

Cơ chế kiểm soát nội dung bao gồm bốn giai đoạn:

• Thiết lập

...

...

...

• Mã hóa nội dung.

• Mã hóa nội dung tùy thuộc vào các giá trị URI được truyền một cách an toàn bởi cơ chế kiểm soát nội dung.

Tiêu chuẩn này mở rộng sự kiểm soát nội dung với:

• Kiểm soát của cha mẹ (quản lý mã PIN)

• Quyền liên kết với ghi lại được truyền một cách an toàn bởi cơ chế kiểm soát nội dung.

• URI phiên bản 2 mở rộng giới hạn lưu giữ

CICAM và máy chủ (Host) cả hai đều chứa các thuật toán dành cho đàm phán mã khóa Diffie-Helman (DH), thuật toán băm SHA-256, DES và AES. CICAM và máy chủ cũng giữ các mã khóa riêng và mã khóa công khai tương ứng.

4.6  MMI nâng cao

Cl Plus giới thiệu một công cụ trình bày tiêu chuẩn vào hồ sơ Cl để trình bày văn bản và hình ảnh trên màn hình máy chủ mà không cần yêu cầu phải có phần mở rộng hơn nào đối với MMI ứng dụng. Công cụ trình bày cho phép CICAM trình bày thông tin với cái nhìn và cảm nhận theo quy định của các nhà điều hành dịch vụ chứ không phải bị hạn chế đối với MMI cấp cao của các nhà sản xuất.

...

...

...

Việc hỗ trợ MMI ứng dụng cho “trình duyệt Cl Plus” được mô tả trong điều 12 đối với một máy chủ là bắt buộc. Các yêu cầu tài nguyên MMI cấp cao hiện có được mô tả trong điều 13.

4.7  Các mở rộng của Cl Plus

Cl Plus giới thiệu một số cải tiến các tài nguyên DVB-CI hiện có, ngoài một số tài nguyên mới được mô tả trong điều 14, bao gồm:

• Cung cấp các kết nối đường truyền tốc độ thấp qua IP có thể được sử dụng để hỗ trợ các chức năng truy nhập có điều kiện.

• Nâng cấp phần mềm CAM tạo điều kiện cho việc nâng cấp phần mềm của CICAM phối hợp với máy chủ, chuẩn hoá tương tác giữa CICAM và Host. Hỗ trợ máy chủ nâng cấp phần mềm là bắt buộc.

Các yêu cầu an toàn Cl Plus và các mở rộng Cl Plus yêu cầu truyền nhanh hơn qua liên kết Cl được xử lý trong Phụ lục G. Làm rõ các trường hợp sử dụng DVB-CI được quy định tại Phụ lục E.

4.7.1  Các mở rộng của Cl Plus 1.3

Cl Plus 1.3 giới thiệu một số cải tiến các tài nguyên trong Cl Plus 1.2 và DVB-CI và thêm vào một số tài nguyên mới được mô tả trong điều 14, bao gồm:

• Các mở rộng đối với tài nguyên đường truyền tốc độ thấp mà loại bỏ một số hạn chế của phiên bản trước đó để cải thiện thông lượng. Tài nguyên đường truyền tốc độ thấp là bắt buộc đối với tất cả các máy chủ có hỗ trợ kết nối IP.

...

...

...

• Điều khiển máy chủ phiên bản 2 thêm các lệnh mới cho CICAM để điều chỉnh máy chủ đến một dịch vụ không thuộc bảng sắp xếp kênh của máy chủ. Dịch vụ được lựa chọn này được dựa trên mô tả vật lý của dòng truyền tải có mang dịch vụ này và nhận dạng của dịch vụ này.

5  Tổng quan kiểm soát nội dung

Mục đích chính của tiêu chuẩn này là để bảo vệ nội dung nhận được, sau khi bất kỳ hệ thống CA xáo trộn đã được gỡ bỏ, khi nội dung truyền qua giao diện chung đến máy chủ. Điều này được thực hiện bằng:

• Xác thực lẫn nhau giữa CICAM và máy chủ.

• Kiểm tra máy chủ và CICAM.

• Tính toán mã khóa mã hóa.

• Truyền tải sử dụng một kênh xác thực an toàn.

Các thủ tục này được mô tả chi tiết trong tiêu chuẩn này.

5.1  Kiến trúc

...

...

...

Hình 5.1- Sơ đồ chỉ ra phạm vi của các cơ chế bảo vệ

Hình 5.1 cho thấy hệ thống đầu cuối đến đầu cuối và chỉ ra phạm vi của bảo vệ CA và hệ thống kiểm soát nội dung được mô tả trong tiêu chuẩn này. Tiêu chuẩn này đề cập đến giao diện giữa CICAM và máy chủ được bảo vệ bởi hệ thống kiểm soát nội dung. Kiểm soát nội dung hoạt động với sự hỗ trợ của hệ thống CA và một bộ công cụ mã hóa để bảo vệ cho phương tiện đến máy chủ. Máy chủ, sử dụng một bộ các công cụ mã hóa tương tự, loại bỏ việc bảo vệ này và đưa nội dung đến các bộ giải mã của máy chủ.

5.2  Tổng quan về hành vi giao diện

Các hành vi khởi tạo khi bật điện lên được mô tả trong tài liệu EN 50221 [7].

Tài nguyên CC, được định nghĩa trong tiêu chuẩn này, được sử dụng để bảo vệ nội dung a) khi nội dung được truyền từ CICAM sang máy chủ và b) Nếu và khi nội dung được đưa đến giao diện bên ngoài của máy chủ. Nhiều bước tham gia vào quá trình này. Các thành phần hệ thống này sử dụng tài nguyên CC để bắt đầu một quá trình xác thực lẫn nhau. Khi CICAM và máy chủ đã cùng xác nhận rằng chúng đang liên lạc với thành phần Cl Plus hợp pháp thì một kênh xác thực an toàn (SAC) được khởi tạo. SAC được sử dụng để truyền các bản tin chuyển được xác thực và mã hóa. Các thành phần hệ thống này thiết lập một mã khóa xáo trộn/giải xáo trộn CC chung và trao đổi thông tin các quy tắc sử dụng và giấy phép tùy chọn. Quá trình này được giải thích trong hình 5.2, trong bảng 5.1 đề cập đến các mục trong tiêu chuẩn này cung cấp các cơ chế chi tiết.

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/khối hóa.

Hình 5.2 - Hành vi giao diện cấp cao

...

...

...

Bảng 5.1 - Hành vi giao diện cấp cao

TT

Mô tả

Tham chiếu đến

Bước # 1 Khởi tạo xác thực - kiểm tra giấy chứng nhận và trao đổi mã khóa DH

1

CICAM kích hoạt quá trình xác thực.

CICAM khởi tạo quá trình xác thực khi không có mã khóa xác thực từ liên kết thành công trước. Quá trình xác thực này được giới thiệu trong điều 5.9. Tham chiếu đến mục tham chiếu ở cột bên để biết thông tin chi tiết đầy đủ.

Điều 6

...

...

...

Máy chủ tham gia quá trình xác thực tương hỗ.

Máy chủ kiểm tra dữ liệu giao thức nhận được để xác định xem nó được bắt nguồn từ một CICAM hợp lệ và tham gia quá trình xác thực tương hỗ.

Điều 6

Bước # 2 Khởi tạo xác thực - Xác minh khóa xác thực

3

CICAM yêu cầu sự xác thực khóa máy chủ

Điều 6

4

Các CICAM yêu cầu khóa xác thực (AKH) từ máy chủ, để xác định rằng cả CICAM và Máy chủ đã tính toán với cùng một khóa. Máy chủ phản hồi yêu cầu này với khóa xác thực đã được chính nó tính toán.

...

...

...

5

Thiết lập SAC.

Điều 7

6

Sau khi xác thực thành công CICAM và máy chủ bắt đầu trao đổi dữ liệu và tính mã khóa mã hóa (SEK) và xác thực (SAK) của các bản tin được truyền qua SAC. Dựa vào việc thiết lập các mã khóa SEK và SAK, CICAM phải đồng bộ với máy chủ để bắt đầu sử dụng các mã khóa mới trong khoảng thời gian chờ được xác định trước. SAC được thiết lập bằng cách sử dụng các mã khóa này.

Bước # 4 Khởi tạo - Thiết lập mã khóa CC

7

Thiết lập mã khóa CC.

Điều 8

...

...

...

Sau khi xác thực thành công, CICAM có thể bắt đầu tính mã khóa CC. Sau khi khởi tạo thành công SAC, CICAM có thể thông báo cho máy chủ để tính mã khóa CC. Dựa vào việc thiết lập mã khóa CC, CICAM phải đồng bộ với máy chủ để bắt đầu tính mã khóa CC mới trong thời gian chờ được xác định trước. Bộ (giải) xáo trộn được khởi tạo bằng cách sử dụng mã khóa CC. Chú ý rằng bước này có thể được thực hiện lặp lại dựa vào việc thiết lập thời gian sống lớn nhất của mã khóa này.

Bước # 5 Khởi tạo - Truyền và sử dụng kiểm soát sao chép nội dung

9

CICAM khởi tạo việc truyền URI info và giấy phép tùy chọn.

CICAM truyền URI và giấy phép tùy chọn phù hợp với những giới hạn kiểm soát sao chép hiện tại đối với dịch vụ được lựa chọn đến máy chủ. Chú ý rằng bước này có thể được thực hiện lặp lại trong một sự kiện chương trình dựa vào việc thiết lập thực của URI. Xem CHÚ THÍCH 2.

Điều 5.7.4

10

Máy chủ áp dụng các thiết lập của URI, kết hợp việc ghi lại giấy phép và máy chủ xác nhận

...

...

...

11

Sau khi nhận thông tin URI, máy chủ phải trả lời CICAM trong thời gian chờ được xác định trước và sau đó áp dụng các giới hạn kiểm soát sao chép đối với các giao diện bên ngoài như được quy định trong [6]

CHÚ THÍCH:

1. Tham chiếu các đến các điều tham chiếu ở cột bên để biết thông tin chi tiết đầy đủ.

2. Phiên bản URI được sử dụng phải được thương lượng trước xem 5.7.5.1

5.3  Phân cấp mã khóa

Một hệ thống phân cấp mã khóa được sử dụng để thực hiện bảo vệ nội dung và kiểm soát sao chép được thể hiện trong hình 5.3.

...

...

...

Bảng 5.2 - Mã khóa so với các giấy chứng nhận

Mã khóa

Mô tả

Được lưu trữ hoặc thay đổi

Được lưu trữ nội bộ hoặc trao đổi

Root cert

Giấy chứng nhận gốc

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ (không thể thay thế)

...

...

...

Giấy chứng nhận thương hiệu

được lưu trữ (hằng số giấy phép)

được trao đổi (không thể thay thế)

Device cert

Giấy chứng nhận thiết bị

được lưu trữ (hằng số giấy phép)

được trao đổi (không thể thay thế)

pmg_seed

Với mỗi nhân của nhà sản xuất dành cho PRNG

...

...

...

được lưu trữ nội bộ (không thể thay thế)

DH_p

Mô đun chính Diffie-Hellman

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

DH_g

Mô đun bộ tạo Diffie-Hellman

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

...

...

...

Hằng số Diffie-Hellman Sophie Germain

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

MDQ

Mã khóa riêng của mô đun

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ (không thể thay thế)

MDP

Mã khóa công khai của mô đun

...

...

...

được trao đổi

HDQ

Mã khóa riêng của máy chủ

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ (không thể thay thế)

HDP

Mã khóa công khai của máy chủ

được lưu trữ

được trao đổi

...

...

...

Diffie-Hellman nonce (mũ x)

được thay đổi

được lưu trữ nội bộ

DHY

Diffie-Hellman nonce (mũ y)

được thay đổi

được lưu trữ nội bộ

DHPM

Mã khóa công khai Diffie-Hellman của mô đun

...

...

...

được trao đổi

DHPH

Mã khóa công khai Diffie-Hellman của máy chủ

được thay đổi

được trao đổi

DHSK

Mã khóa mật Diffie-Hellman

được lưu trữ

được lưu trữ nội bộ

...

...

...

Mã khóa xác thực của mô đun

được lưu trữ (trên mô đun)

được lưu trữ nội bộ

AKH

Mã khóa xác thực của máy chủ

được lưu trữ (trên máy chủ)

được trao đổi (được bảo vệ)

Ns_Module

Nonce SAC của mô đun

...

...

...

được trao đổi

Ns_Host

Nonce SAC của máy chủ

được thay đổi

được trao đổi

SEK

Mã khóa mã hóa SAC

được thay đổi

được lưu trữ nội bộ

...

...

...

Mã khóa xác thực SAC

được thay đổi

được lưu trữ nội bộ

SIV

Vec tơ khởi tạo SAC

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

Kp

Tiền thân của mã khóa

...

...

...

được trao đổi (được bảo vệ)

CCK

Mã khóa kiểm soát nội dung

được thay đổi

được lưu trữ nội bộ

CIV

Vec tơ khởi tạo CC

được thay đổi

được lưu trữ nội bộ

...

...

...

Có một cặp mã khóa công khai và riêng được xác định dành cho CICAM và dành cho máy chủ. CICAM có một mã khóa riêng thiết bị (MDQ) và mã khóa công khai thiết bị tương ứng (MDP) được nhúng trong giấy chứng nhận thiết bị của CICAM. Máy chủ tương tự cũng chứa HDQ và HDP. Có một chuỗi chứng nhận duy nhất cho cả CICAM và máy chủ. Có hằng số được sử dụng trong tính toán, chẳng hạn như DH_p và DH_g đối với quá trình xác thực Diffie-Hellman.

Dữ liệu trên lớp chứng nhận (như mã khóa, nhân, giấy chứng nhận và các hằng số như đề cập trong bảng 5.2) được tham gia vào các hoạt động trên lớp chứng nhận. Lớp chứng nhận chứa các thông số không được thay thế. Tiêu chuẩn này không chỉ rõ cơ chế chính xác được sử dụng để bảo vệ các thông số của lớp chứng nhận này, điều này nằm ngoài phạm vi của tiêu chuẩn này.

5.3.2  Các mã khóa trên lớp xác thực

Mã khóa công khai thiết bị, từ giấy chứng nhận thiết bị, và mã khóa riêng thiết bị có liên quan đến hai hoạt động (Không thể hiện trong hình 5.3):

1) Bảo vệ việc trao đổi thông số trong quá trình xác thực. Việc xác thực dựa trên Diffie-Hellman, yêu cầu CICAM và máy chủ trao đổi các thông số phải được bảo vệ chống lại việc làm thay đổi từ một nguồn độc hại. Tham khảo điều 6.1.2 để biết chi tiết.

2) Kiểm tra chuỗi chứng nhận. Chuỗi chứng nhận chứa thông tin được sử dụng trong các bước tiếp theo trong phân cấp mã khóa. Các giấy chứng nhận thu được phải được hai bên xác nhận, tham khảo điều 9.4 và điều 9 để biết chi tiết.

Các mã khóa thu được từ lớp xác thực là mã khóa mật Diffie-Hellman (DHSK) và mã khóa xác thực (AKM dành cho CICAM và AKH dành cho máy chủ). CICAM yêu cầu mã khóa xác thực này được máy chủ sử dụng. Tham khảo điều 6 để biết chi tiết.

DHSK và AKM hoặc AKH được lớp xác thực bảo vệ và quản lý. Các lớp khác (chẳng hạn như lớp SAC và lớp kiểm soát nội dung) đôi khi có thể yêu cầu các mã khóa này để tính các thông số mật không ổn định của chúng. Lớp xác thực truyền các mã khóa được yêu cầu nhưng lớp sử dụng không được duy trì hoặc lưu trữ chúng.

5.3.3  Các mã khóa trên lớp SAC

...

...

...

Hình 5.4 - Các mã khóa trên lớp SAC

5.3.4  Các mã khóa trên lớp kiểm soát nội dung (CC)

Lớp CC sử dụng các mã khóa để xáo trộn nội dung AV trước khi nó được truyền từ CICAM đến máy chủ. Mã khóa kiểm soát nội dung, CCK, (và nếu cần CIV) được sử dụng để xáo trộn AV. Về phía nhận được, máy chủ sử dụng các mã khóa được tính toán tương tự để giải mã nội dung AV. CCK (và nếu cần CIV) được tính toán một cách độc lập ở CICAM và máy chủ. CCK (và nếu cần CIV) đều là thông số mật không ổn định, ngắn hạn. Tham khảo điều 8 để biết chi tiết.

Hình 5.5 - Các mã khóa trên lớp CC

5.4  Triển khai mô-đun

CICAM có thể được triển khai trong chế độ dịch vụ cơ bản (BSM) hoặc chế độ đăng ký dịch vụ (RSM). Chế độ dịch vụ cơ bản là bắt buộc, chế độ đăng ký dịch vụ là tùy chọn và tuân thủ SCTE41 [5]. SCTE41 quy định ba giai đoạn xác thực:

1) Kiểm tra giấy chứng nhận & trao đổi mã khóa DH

...

...

...

3) Báo cáo trả về thiết bị đầu cuối

Cả hai dịch vụ chế độ hỗ trợ giai đoạn xác thực 1 và 2. Chỉ có chế độ đăng ký dịch vụ hỗ trợ giai đoạn xác thực thứ ba: Báo cáo trả về thiết vị đầu cuối (xem Bảng 5.3)

Bảng 5.3  - Các giai đoạn xác thực được hỗ trợ đối với mỗi chế độ dịch vụ

Chế độ

Kiểm tra giấy chứng nhận & Trao đổi mã khóa DH

Kiểm tra mã khóa xác thực

Báo cáo trả về Thiết bị đầu cuối

Chế độ dịch vụ cơ bản

●

...

...

...

6

Chế độ đăng ký dịch vụ

●

●

●

Trong chế độ dịch vụ cơ bản và đăng ký dịch vụ, CICAM có thể hoạt động ở hai trạng thái:

• Hoạt động hạn chế; chế độ tương thích EN 50221 [7]. Không có dịch vụ yêu cầu bảo vệ Cl Plus được giải xáo trộn CA.

• Hoạt động toàn phần; chế độ tương thích Cl Plus. Tất cả dịch vụ được Cl Plus bảo vệ được xáo trộn lại theo Cl Plus.

Hai điều tiếp theo giải thích cả hai chế độ một cách chi tiết hơn, điều thứ ba mô tả cách CICAM và máy chủ xử lý lỗi.

...

...

...

Chế độ dịch vụ cơ bản xác định hoạt động của CICAM trong một môi trường truyền hình (tức là không có kênh thông tin hai chiều trực tuyến). CICAM không hoạt động ngay lập tức khi được ghép vào thiết bị máy chủ và nguồn điện đã được bật; trước đó các giao thức sau đây phải được thực hiện:

• Xác thực lại khi bật nguồn điện (xem điều 6.3)

• Kiểm tra giấy chứng nhận & trao đổi mã khóa DH (xem điều 6.2)

• Kiểm tra mã khóa xác thực (xem điều 6.3)

• Thiết lập kênh xác thực an toàn (SAC) (xem điều 7)

• Thiết lập mã khóa kiểm soát nội dung (CC) (xem điều 8)

Hình 5.6 - Quá trình xác thực trong chế độ dịch vụ cơ bản.

Hình 5.6 đưa ra một cái nhìn tổng quan về quá trình xác thực trong chế độ dịch vụ cơ bản. Khi bật nguồn điện, trước tiên CICAM xác định xem thiết bị máy chủ có tương thích Cl Plus. Máy chủ tương thích Cl Plus thông báo tài nguyên CC trong giao thức quản lý tài nguyên lúc khởi tạo, xem điều 12.3 và EN 50221 [7] điều 8.4.1.1 (2). Trong trường hợp, thiết bị máy chủ không tương thích một lỗi mô tả (xem Hình 5.10) được đưa ra bằng cách sử dụng MMI cấp cao hoặc MMI ứng dụng (3) và CICAM ở chế độ hoạt động hạn chế (10) (tức là tương thích EN 50.221). Khi thiết bị máy chủ tương thích Cl Plus máy chủ sẽ kiểm tra xem có thẻ xác thực lại khi bật nguồn điện (4). Xác thực lại khi bật nguồn điện là có thể khi CICAM trước đó đã liên kết thành công với thiết bị máy chủ này. Khi có liên kết thành công thì kiểm tra giấy chứng nhận và trao đổi mã khóa DH (5) và kiểm tra mã khóa xác thực (6) có thể được bỏ qua, và CICAM có thể bắt đầu ngay lập tức với thiết lập SAC (7). Sau khi thiết lập SAC thì thiết lập mã khóa CC (8). Với SAC và mã khóa CC được thiết lập, CICAM ở chế độ hoạt động hoàn toàn (9).

...

...

...

Các mã khóa CC được sử dụng để mã hóa của các dịch vụ được Cl Plus CICAM bảo vệ và giải mã các dịch vụ được Cl Plus thiết bị máy chủ bảo vệ. Thiết bị máy chủ suy ra mã khóa CC từ việc trao đổi mã khóa DH; không có mã khóa CC được truyền từ CICAM đến thiết bị máy chủ. Hình 5.7 đưa ra tổng quan của quá trình thiết lập mã khóa CC và SAC, ở bước (3) và (5) khi mã khóa được làm mới ở bước (2) và (4) được yêu cầu. Nếu vì một lý do SAC hoặc mã khóa CC không được làm mới lại (6) và (7) thì CICAM trở lại trạng thái hoạt động hạn chế (8) nếu không trạng thái của nó vẫn là hoạt động hoàn toàn (1).

Hình 5.7 - Quá trình làm mới lại SAC và mã khóa CC

Chế độ dịch vụ cơ bản hỗ trợ việc thu hồi thiết bị máy chủ bằng một Danh sách thu hồi giấy chứng nhận (CRL) do Thiết bị đầu cuối truyền đến CICAM sử dụng một băng truyền dữ liệu DSM-CC. Trong trường hợp của một thiết bị máy chủ bị thu hồi, CICAM thông báo cho người sử dụng rằng thiết bị máy chủ của họ trong danh sách đen sử dụng tính năng thông báo lỗi chung (xem điều 5.4.3).

Ngoài CRL, chế độ dịch vụ cơ bản hỗ trợ một Danh sách trắng giấy chứng nhận (CWL) cho phép các nhà điều hành dịch vụ trở lại trạng thái thu hồi trước đó của một thiết bị máy chủ duy nhất. Xem điều 5.5 để biết chi tiết về cơ chế thu hồi Cl Plus.

5.4.2. Triển khai trong chế độ đăng ký dịch vụ

Chế độ đăng ký dịch vụ là một phần mở rộng của Chế độ dịch vụ cơ bản và được thiết kế cho các mạng có khả năng giao tiếp thông tin hai chiều từ CICAM tới mạng hệ thống quản lý thuê bao. Để thực thi Chế độ đăng ký dịch vụ, CICAM có thể sử dụng High-Level hoặc ứng dụng MMI để đưa ra hướng dẫn và dữ liệu đăng ký đến người dùng nhằm giao tiếp tới mạng hệ thống quản lý thuê bao.

Các hoạt động của Chế độ đăng ký dịch vụ được xác định bởi nhà khai thác dịch vụ và nằm ngoài phạm vi của tiêu chuẩn này.

5.4.3. Báo cáo lỗi tổng quát

...

...

...

Trường hợp CICAM hỗ trợ Chế độ đăng ký dịch vụ, nhà cung cấp CA hay nhà khai thác dịch vụ có thể xác định một liên kết giữa hành động và các mã lỗi. Các nhà cung cấp CA hoặc nhà khai thác dịch vụ phải xác định mã hành động đã được hỗ trợ trong Chế độ đăng ký dịch vụ và không thuộc phạm vi của tiêu chuẩn này.

Ví dụ: Mã yêu cầu hành động được liên kết với mã lỗi “invalid Host certificate”, Phụ lục F.1 xác định tình trạng lỗi này là Mã lỗi số 16 (Error Code 16), nhà cung cấp CA hoặc nhà khai thác dịch vụ có thể liên kết lỗi này tới bất kỳ Mã yêu cầu hành động nào. Kết quả là Bản tin Thông báo sẽ cung cấp thông tin cho khách hàng cùng với hướng dẫn liên hệ số điện thoại hỗ trợ.

5.5. Giới thiệu phương pháp thu hồi (tham khảo)

Tiêu chuẩn này quy định một phương pháp thu hồi để xử lý đối với thiết bị máy chủ bị nghi ngờ về an toàn. Tiêu chuẩn này phân biệt ba cơ chế thu hồi:

1) Ngăn chặn dịch vụ của máy chủ

2) Thu hồi bằng CAS

3) Thu hồi máy chủ

Ngăn chặn dịch vụ của máy chủ được mô tả chi tiết trong điều 10. Thu hồi bằng CAS được một CAS cụ thể quy định và do đó nằm ngoài phạm vi tiêu chuẩn này. Phần còn lại của điều này mô tả cơ chế thu hồi máy chủ, chuẩn giấy cấp phép Cl Plus quy định các yêu cầu để thực hiện thu hồi máy chủ.

5.5.1. Thu hồi máy chủ

...

...

...

• Danh sách thu hồi giấy chứng nhận nhà điều hành dịch vụ (SOCRL)

• Danh sách trắng giấy chứng nhận nhà điều hành dịch vụ (SOCWL)

Một SOCRL được Nguồn gốc tin cậy tạo ra theo yêu cầu của một nhà điều hành dịch vụ đặc biệt dành cho hoạt động này. Thu hồi luôn luôn gắn liền với một nhà điều hành dịch vụ cụ thể. Một thiết bị máy chủ có thể bị thu hồi đối với một nhà điều hành dịch vụ mà vẫn hoạt động với những nhà điều hành dịch vụ khác. Thu hồi thiết bị máy chủ chỉ áp dụng đối với các dịch vụ được các nhà điều hành dịch vụ được Cl Plus bảo vệ (ví dụ như nội dung HD cao cấp) yêu cầu nhưng cho phép các dịch vụ khác (ví dụ: nội dung giá trị thấp được CA bảo vệ CA) vẫn có thể truy nhập đến máy chủ. Các đầu vào trong SOCWL bỏ một thu hồi được quy định trong SOCRL.

Để đảm bảo thu nhận một SOCRL bởi CICAM, SOCRL nên là một phần của mỗi dòng truyền tải (TS) mang các dịch vụ thuộc nhà điều hành dịch vụ. Trường hợp TS có các dịch vụ thuộc hai hoặc nhiều nhà điều hành dịch vụ thì một SOCRL cho mỗi nhà điều hành dịch vụ phải được thêm vào TS.

Các quy tắc chính xác để thu hồi một thiết bị được Chuẩn cấp giấy phép Cl Plus quy định, do đó nằm ngoài phạm vi tiêu chuẩn này, xem Chuẩn cấp giấy phép Cl Plus [33].

Mô hình tin cậy để thu hồi quy định hai phần từ: 1) CICAM và 2) thiết bị máy chủ. Thiết bị máy chủ là mục tiêu của việc thu hồi và được xem là không đáng tin cậy. Các mối đe dọa sau đây được xem xét:

1) Phát lại; thiết bị máy chủ có thể phát lại một SOCRL không chứa nhận dạng của nó.

2) Ngăn chặn; thiết bị máy chủ có thể ngăn chặn SOCRL tiếp cận CICAM.

3) Giả mạo; thiết bị máy chủ có thể thay đổi hoặc loại bỏ một đầu vào SOCRL có chứa nhận dạng của nó.

...

...

...

5.5.2. Mức độ thu hồi

Tiêu chuẩn này hỗ trợ các mức thu hồi:

1) Thiết bị máy chủ duy nhất

2) Dải các thiết bị máy chủ

3) Thiết bị máy chủ có một mô hình-kiểu cụ thể

4) Thiết bị máy chủ có một thương hiệu cụ thể

Một nhà điều hành dịch vụ có thể sử dụng một mức bất kỳ khi yêu cầu thu hồi máy chủ. SOCWL chỉ hỗ trợ thiết bị máy chủ duy nhất được bỏ thu hồi từ một dải bị thu hồi. Tính năng này có thể được sử dụng để kiểm tra thiết bị riêng lẻ trong một dải thiết bị bị thu hồi.

5.5.3. Dữ liệu thông báo thu hồi

Thông tin dữ liệu thông báo thu hồi (RSD) chỉ ra tính sẵn có của một SOCRL (và SOCWL) trong mạng. RSD phải mang:

...

...

...

2) thông tin tải SOCRL và/hoặc SOCWL; chứa thông tin mà CICAM yêu cầu tìm SOCRL và SOCWL trong dòng truyền tải. Nếu không có thông tin tải được quy định thì nhà điều hành dịch vụ không truyền một SOCRL và/hoặc SOCWL.

3) số phiên bản SOCRL và/hoặc SOCWL mới nhất; các số phiên bản SOCRL và SOCWL mới nhất hiện đang được truyền.

4) thời gian chờ truyền SOCRL và SOCWL; quy định thời gian truyền SOCRL và SOCWL. SOCRL và SOCWL phải được thu trước khi hết khoảng thời gian chờ nếu không CICAM trở thành hoạt động hạn chế.

RSD được bảo vệ chống lại phát lại, ngăn chặn và giả mạo. Mỗi CICAM có khả năng phát hiện RSD trên mạng. CAS phải cung cấp CICAM khả năng đóng hoặc mở chức năng phát hiện RSD, nhưng cơ chế chính xác này nằm ngoài phạm vi tiêu chuẩn này và tùy thuộc CAS cụ thể. Nếu nhà khai thác dịch vụ mở chức năng phát hiện RSD, RSD phải có trên mạng và RSD phải được truyền lặp đi lặp lại. Các yêu cầu và định dạng chính xác của RSD được quy định trong Chuẩn cấp giấy phép Cl Plus [37].

CICAM phải đảm bảo rằng nó có các phiên bản mới nhất của RSD, SOCRL và SOCWL.

5.5.4. Thời gian chờ truyền

Chu kỳ thời gian của RSD nên ngắn hơn so với thời gian chờ truyền của nó ra để đảm bảo việc thu. Việc tải SOCRL có thời gian chờ truyền và giá trị này được RSD truyền.

5.5.5. Quá trình tải SOCRL và SOCWL

Việc tải (sử dụng một băng truyền) của SOCRL và SOCWL được thực hiện theo hình 5.8 có tính chất tham khảo và không loại trừ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau.

...

...

...

• Tải RSD (2). CICAM thu được RSD của nhà điều hành dịch vụ.

• Thời gian chờ tải RSD (3). Trong thời gian chờ truyền RSD, thiết bị máy chủ tạm thời bị thu hồi (18). Khi tải về hoàn thành thành công, CICAM xác định xem một SOCRL hay SOCRL và SOCWL nên được tải về.

• Tải SOPKC (4). CICAM tải SOPKC.

• SOPKC không có sẵn (5). Nếu SOPKC không có sẵn hoặc không hợp lệ thì máy chủ tạm thời bị thu hồi (20).

• RSD hợp lệ (6). Bằng cách sử dụng SOPKC, CICAM xác định rằng RSD này là hợp lệ. Xem Chuẩn giấy cấp phép Cl Plus [33] để biết thêm chi tiết.

• Tải SOCRL (7). CICAM so sánh số phiên bản SOCRL trong RSD với số phiên bản của SOCRL được lưu trữ trước đó. Trường hợp RSD này có phiên bản mới hơn, SOCRL này phải được tải về, tương tự đối với SOCWL. Vị trí của băng truyền dữ liệu có chứa SOCRL và SOCWL được lưu trong RSD.

• SOCRL tải time-out (8). Trong thời gian chờ truyền SOCRL máy chủ tạm thời bị thu hồi (18). Khi quá trình tải về hoàn thành, CICAM xử lý SOCRL (7).

• Xử lý SOCRL (9). Khi việc tải về SOCRL đã hoàn thành thành công, CICAM kiểm tra đóng dấu kỹ thuật số của SOCRL. SOCRL này có thể được nhà điều hành dịch vụ hoặc Nguồn gốc tin cậy đóng dấu. Số phiên bản của SOCRL và số phiên bản được quy định tại RSD được kiểm tra so sánh.

...

...

...

• SOCRL hồ tải về S. ViL hồ tải về SOCRL và SOCWL thành thành công, CICAM kiểm tra đóng dấu kỹ thuật số của SOCRL. SOCRL này có thể được nhà điều hành dịch vụ hoặc Nguồn gốc tin cậy đóng dấu. Số ph

• SOCWL được thông báo trong RSD (11). Nếu không có SOCWL được thông báo trong RSD thì CICAM tiến hành kiểm tra xem máy chủ có trong SOCRL (16).

• Tải SOCWL (12). Nếu một SOCWL được thông báo trong RSD thì nó được tải về.

• Xử lý SOCWL (13). Khi SOCWL đã được tải về thành công, CICAM kiểm tra đóng dấu kỹ thuật số của SOCWL. SOCWL này chỉ có thể được nhà điều hành dịch vụ đóng dấu. Nó cũng kiểm tra xem:

○ Nếu ‘số phiên bản’ thuộc SOCWL bằng ‘số phiên bản’ thuộc RSD.

○ Nếu ‘số phiên bản CRL’ thuộc SOCWL bằng ‘số phiên bản’ thuộc SOCRL.

• SOCWL hợp lệ (14). Các điều kiện sau đây phải được đáp ứng để xác nhận SOCWL:

○ Đóng dấu kỹ thuật số SOCWL trong SOCWL được xác thực

○ ‘Số phiên bản’ thuộc SOCWL bằng ‘số phiên bản’ thuộc RSD

...

...

...

○ Nếu không, máy chủ tạm thời bị thu hồi (20).

• Thiết bị máy chủ trong SOCWL (15). Trường hợp máy chủ hiện đang liên kết với CICAM được liệt kê trong SOCWL thì các dịch vụ được Cl Plus bảo vệ phải bị bỏ thu hồi (17), nếu không thì kiểm tra SOCRL (16)

• Thiết bị máy chủ trong SOCRL (16). Trường hợp máy chủ hiện đang liên kết với CICAM được liệt kê trong SOCRL thì máy chủ phải bị thu hồi (18), nếu không thiết bị máy chủ không bị thu hồi (17).

• Bỏ thu hồi: CICAM hoạt động hoàn toàn (17). Máy chủ được liên kết với CICAM không bị thu hồi, nó hoặc là trong SOCWL hoặc không được liệt kê trong SOCRL. Bất kỳ thu hồi (tạm thời) hiện có bị loại bỏ.

• Thu hồi: CICAM hoạt động hạn chế (18). Máy chủ được liên kết với CICAM bị thu hồi; tất cả các dịch vụ được Cl Plus bảo vệ vẫn được CA xáo trộn cho đến khi một SOCRL thu được không chứa một đầu vào nào dành cho máy chủ. Trạng thái thu hồi này loại bỏ bất kỳ trạng thái thu hồi tạm thời.

• Thiết bị máy chủ bị thu hồi được cập nhật trong lịch sử liên kết (19). CICAM duy trì một danh sách trong bộ nhớ không thay đổi được của máy chủ đã được liên kết thành công với CICAM. Danh sách này phải được cập nhật:

○ Trường hợp máy chủ trong SOCWL thì đầu vào của nó trong lịch sử liên kết phải được cập nhật bằng cách loại bỏ cờ thu hồi dành cho nhà điều hành dịch vụ hiện tại.

○ Trường hợp máy chủ trong SOCRL thì đầu vào của nó trong lịch sử liên kết phải được cập nhật bằng cách thiết lập cờ thu hồi dành cho nhà điều hành dịch vụ hiện tại.

○ Mỗi máy chủ trong lịch sử liên kết đối với nhà điều hành dịch vụ hiện tại phải được kiểm tra SOCRL (và SOCWL) và cờ thu hồi được điều chỉnh thích hợp.

...

...

...

5.5.6. Từ chối dịch vụ

Quá trình thu hồi này được CICAM dựa trên việc từ chối dịch vụ và được thực hiện theo hình 5.9 có tính chất tham khảo và không loại trừ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau.

Hình 5.9 - Sơ đồ thu hồi bằng cách từ chối dịch vụ

• B- Sơ đ. Sau khi CICAM và máy chủ từ chối dịch vụ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau. tạm thời thu hồi máy chủ bằng cách t

• L Sau kh d Sau k. Ngay khi CICAM và máy chủ từ chối dịch vụ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau. tạm thời thu hồi máy chủ bằng cách trở thành hoạt động hạn chế. Bất kỳ thu hồi (3).

• Dịch vụ được Cl Plus bảo vệ. CICAM xác định bằng giá trị EMI xem dịch vụ được lựa chọn này là được Cl Plus bảo vệ. Nếu yêu cầu được Cl Plus bảo vệ thì CICAM kiểm tra xem máy chủ không bị thu hồi (4) nếu không dịch vụ được CA bảo vệ có thể được giải xáo trộn (5).

• Thiết bị máy chủ bị thu hồi. CICAM sử dụng lịch sử liên kết để kiểm tra xem máy chủ mà nó liên kết có cờ bị thu hồi (tạm thời). Nếu máy chủ liên kết bị thu hồi thì dịch vụ được CA bảo vệ không được giải xáo trộn nếu không thì dịch vụ được giải xáo trộn (6).

• Dịch vụ được CA giải xáo trộn. Dịch vụ được lựa chọn này được CA giải xáo trộn nhưng không được Cl Plus xáo trộn lại. Dịch vụ không được bảo vệ này được truyền tới máy chủ (7).

...

...

...

• Đầu ra đến thiết bị máy chủ. CICAM có thể truyền dịch vụ được lựa chọn này đến máy chủ liên kết để sử dụng. Dịch vụ này không được mã hóa (bảo vệ CA bị loại bỏ) hoặc được mã hóa (bảo vệ CA bị loại bỏ nhưng bảo vệ Cl Plus được thêm vào).

5.6. Xáo trộn (Giải xáo trộn) nội dung

5.6.1. Xáo trộn mức dòng truyền tải

Để bảo vệ nội dung có giá trị cao, nhà cung cấp dịch vụ có thể lựa chọn để “xáo trộn” (mã hóa) nội dung của các dòng thành phần của dịch vụ. Thiết bị thu sử dụng bộ giải xáo trộn để “giải xáo trộn” (giải mã) các dòng thành phần này để chúng có thể được sử dụng. Bộ giải xáo trộn xác định khi nào để giải mã bằng cách xem xét các bit thuộc Kiểm soát xáo trộn truyền (TSC) trong gói tin TS theo quy định tại Bảng 5.4

Bảng 5.4 - Định nghĩa các bit kiểm soát xáo trộn truyền (TSC)

Các bit kiểm soát xáo trộn truyền

Mô tả

Diễn giải

00

...

...

...

Yêu cầu hỗ trợ

01

Xáo trộn bằng mã khóa nội dung DEFAULT

Không được CICAM và máy chủ hỗ trợ

10

Xáo trộn bằng mã khóa nội dung EVEN

Yêu cầu hỗ trợ

11

Xáo trộn bằng mã khóa nội dung ODD

...

...

...

CHÚ THÍCH: Các giới hạn xáo trộn mức TS tuân theo ISO 13818-1 [13].

Hình 5.10 - Quan hệ giữa các thanh ghi của bộ giải xáo trộn và TS

CHÚ THÍCH :

1. Tham chiếu điều 5.7.5 để biết thông tin chi tiết về giao thức làm mới URI.

2. Tham chiếu điều 8.1 để biết thông tin chi tiết về giao thức làm mới mã khóa kiểm soát nội dung.

3. Tham chiếu điều 11.3.1 để biết thông tin chi tiết về các APDU. DĐam ch kho chiếu điều 11.3.1 đ

4. Đối với khoảng thời gian sống của mã khóa, CICAM sẽ xáo trộn lại tất cả các ES dưới sự kiểm soát CC bằng CCK và IV (trong trường hợp lựa chọn AES) giống nhau

...

...

...

Các bộ giải xáo trộn mã khóa kép sử dụng hai thanh ghi để lưu trữ hai mã khóa: thanh ghi đầu tiên có thể chứa mã khóa mà bộ giải xáo trộn hiện đang sử dụng. Trong khoảng thời gian mã khóa đầu tiên này, mã khóa thứ hai có thể được cập nhật với một mã khóa mới dành cho khoảng thời gian mã khóa tiếp theo. Để phân biệt các thanh ghi, các thanh ghi được quy định là thanh ghi mã khóa chẵn và lẻ. Bit TSC trong gói tin TS chỉ ra bộ giải xáo trộn sử dụng thanh ghi mã khóa chẵn hoặc lẻ để giải xáo trộn gói tin TS và chuyển sang thanh ghi tương ứng khi cần thiết. Xem hình 5.10 để biết chi tiết.

Việc làm mới mã khóa chẵn/lẻ được CICAM thông báo trong dữ liệu yêu cầu APDU, máy chủ biết trước thanh ghi của bộ giải xáo trộn nào mà nó phải lưu trữ mã khóa kiểm soát nội dung (CCK) mà CICAM điều khiển nó bắt đầu tính toán. Để xác định xem máy chủ đã thực sự tính toán mã khóa CC và nạp nó vào thanh ghi được yêu cầu (chẵn hoặc lẻ), CICAM và máy chủ đồng bộ với nhau; CICAM khởi tạo một yêu cầu đồng bộ APDU mà máy chủ phải xác nhận. Nếu bộ đếm thời gian làm mới mã khóa hết hạn CICAM phải bắt đầu sử dụng mã khóa CC mới (CCK) và sửa đổi các bit TSC trong phần mào đầu của gói tin TS. Ngay sau khi CICAM thay đổi giá trị TSC, máy chủ phải phát hiện sự thay đổi và chuyển sang thanh ghi mã khóa thay thế. Giao thức URI truyền giá trị URI đến máy chủ. URI chỉ ra những hạn chế của nội dung. Xem hình 5.11 để biết chi tiết.

5.6.1.1. Xáo trộn mức PES

Trường hợp nhà cung cấp dịch vụ sử dụng xáo trộn mức PES đối với các dòng thành phần, tức là các bit PES_scrambling_control của PES_packet là khác không thì bất kỳ việc xáo trộn lại của CICAM phải được áp dụng lại ở mức dòng truyền tải và trường PES_scrambling_control phải được thiết lập là ‘Not Scrambled’.

5.6.2. Định nghĩa bộ xáo trộn/bộ giải xáo trộn

5.6.2.1. Các quy tắc xáo trộn

Tiêu chuẩn này định nghĩa hai bộ xáo trộn dành cho bảo vệ đầu ra dòng TS là DES và AES. Bảng 5.5 mô tả các khả năng bắt buộc của máy chủ và CICAM.

Bảng 5.5: Các khả năng của CICAM và Máy chủ

Tùy chọn bộ xáo trộn

...

...

...

Máy chủ

DES-56-ECB

Bắt buộc

Bắt buộc đối với cả máy chủ SD và HD

AES-128-CBC

Tùy chọn

Chỉ bắt buộc đối với máy chủ HD

Định nghĩa của máy chủ SD và HD dành cho các mục đích của tiêu chuẩn này được quy định tại Phụ lục D.

Máy chủ và CICAM thương lượng các khả năng xáo trộn trong quá trình trao đổi giấy chứng nhận. Mỗi thiết bị xác định khả năng xáo trộn thiết bị kia, xem 9.3.9.5. Cả hai thiết bị phải quyết định sử dụng mã hóa nào (xem Bảng 5.6).

...

...

...

Bảng 5.6: Các quy tắc lựa chọn xáo trộn Cipher

Mô đun

Máy chủ

Thực hiện

Diễn giải

Không

Không

Dừng CC và đưa ra TS đối với nội dung rõ ràng

"Không" đối với máy chủ hoặc mô đun

...

...

...

DES

Xáo trộn lại TS đầu ra sử dụng DES.

DES

AES

Xáo trộn lại TS đầu ra sử dụng DES.

AES

DES

...

...

...

Xem CHÚ THÍCH 3

AES

AES

Xáo trộn lại TS đầu ra sử dụng AES.

CHÚ THÍCH

1. Chủ sở hữu nội dung này có thể chấp nhận sử dụng DES hoặc AES, điều này có nghĩa là nhà cung cấp có thể lựa chọn công nghệ để sử dụng các CICAM được DES hoặc AES cho phép.

2. TS đầu ra được xác định trong EN 50221 [7]

3. Hệ thống CA có thể quyết định xem DES là không phù hợp và lựa chọn để không giải xáo trộn nội dung này.

...

...

...

• Các gói TS của dòng truyền tải thành phần của chương trình được lựa chọn mà rõ ràng về phía mạng không được kiểm soát nội dung Cl Plus xáo trộn và phải vẫn là rõ ràng.

• Nội dung đã được hệ thống CA của mạng giải xáo trộn và kiểm soát nội dung Cl Plus cho biết thông qua một URI mang EMI có giá trị là 0x00 không được kiểm soát nội dung Cl Plus xáo trộn lại. Trong trường hợp này các gói tin TS của dòng thành phần thuộc vào chương tình được lựa chọn đã được xáo trộn trên mạng được truyền đến máy chủ một cách rõ ràng.

• Nội dung đã được hệ thống CA của mạng giải xáo trộn và kiểm soát nội dung Cl Plus cho biết thông qua một URI mang EMI có giá trị khác 0x00 được kiểm soát nội dung Cl Plus xáo trộn lại. Trong trường hợp này các gói tin TS của dòng thành phần thuộc vào chương trình được lựa chọn đã được xáo trộn trên mạng được truyền đến máy chủ được kiểm soát nội dung Cl Plus xáo trộn lại.

• Kiểm soát nội dung Cl Plus phải luôn luôn sử dụng các mã hóa xáo trộn giống nhau đối với tất cả các loại nội dung (âm thanh, video hoặc một số thành phần khác của chương trình được lựa chọn) và sử dụng mã hóa cao nhất đã được thương lượng.

• CICAM chỉ được giải xáo trộn và có thể xáo trộn lại, các dòng thành phần đã được thông báo để giải xáo trộn trong CA_PMT theo EN 50221 [7], điều 8.4.3.4.

• CICAM không bắt buộc phải truyền nội dung trên một kênh được mã hóa DES. Tức là nó tùy theo quyết định của nhà khai thác dịch vụ xem có cung cấp nội dung giá trị cao HD (hoặc SD) qua DES và có thể chỉ lựa chọn để cung cấp nội dung đến các thiết bị AES, vô hiệu một cách hiệu quả các thiết bị chỉ có DES đối với các dịch vụ đó.

Ngoài các quy tắc được quy định tại Bảng 5.9, áp dụng các quy tắc xáo trộn của SCTE41 [5], điều 7.1.1. Trong trường hợp xung đột các quy tắc trên được ưu tiên. (Ví dụ như ngoài việc sử dụng DES AES được cho phép và quy định.)

5.6.2.2. Xáo trộn TS với DES

Tải của các gói tin TS có thể được mã hóa bằng DES-56 trong chế độ ECB với các khối dư để lại rõ ràng. Bộ xáo trộn và bộ giải xáo trộn DES tuân thủ SCTE41 [5], Phụ lục B.

...

...

...

5.6.2.3. Xáo trộn TS với AES

Tải của các gói tin TS có thể được mã hóa bằng AES-128 trong chế độ CBC với mã khóa CC và thay đổi IV mỗi khoảng thời gian duy trì mã khóa và các khối dư để lại rõ ràng. Tham khảo FIPS 197[4] đối với mã hóa AES-128 và tham khảo ấn phẩm đặc biệt 800-38A của NIST [25] để sử dụng AES-128 trong chế độ CBC.

Mã hóa nội dung dựa trên ATSC A/70A [26], Phụ lục D.3. Phần sau đây mô tả bộ xáo trộn và bộ giải xáo trộn AES dành cho tiêu chuẩn này.

Hình 5.12 chỉ ra định dạng cấp cao của một gói TS (xem ISO 13818-1 [13]).

Hình 5.12 - Gói tin TS

Các gói tin TS bao gồm một mào đầu (màu xám) và trường Tải. Tùy thuộc vào kích thước của Trường thích ứng, độ dài của phần Tải có giá trị từ 0 đến 184 byte. Chỉ phần Tải được xáo trộn. Phần Tải thì được phân mảnh thành các khối 128 bit (16 byte) và chuyển qua cơ chế xáo trộn AES như mô tả dưới đây.

5.6.2.3.1. Xáo trộn

Chức năng mã hóa thường định nghĩa b là văn bản rõ ràng và phiên bản được xáo trộn của nó là s. Chức năng mã hóa AES được trình bày bằng s = E_AES-128-CBC {CCK} (b), trong đó mã khóa kiểm soát nội dung (CCK, được quy định trong điều 8.1.4) được sử dụng để mã hóa/xáo trộn một khối nhị phân b có chiều dài bằng 128 bit (16 byte). Việc mã hóa xử lý b thành một khối có cùng kích thước, s.

...

...

...

s(m)=E_AES-128-CBC {CCK}[b(m)Ås(m-1)]                                                                     Eq.5.1

Trong đó:

• CCK là mã khóa kiểm soát nội dung

• b (m) đại diện cho khối 128 bit thứ m trong chuỗi, trong đó m = 2..n. Mã hóa khối b(m) hiện tại yêu cầu biết văn bản mã hóa s(m-1) (tức là đầu ra của khối được xáo trộn trước đó).

Chú ý rằng phương trình (5.1) không làm việc đối với m = 1. Đối với khối đầu tiên (tức là m = 1), dữ liệu đối với s(0) không có. Vì vậy việc xác định một Véc-tơ khởi tạo (IV), được sử dụng để tính toán khối xáo trộn đầu tiên s(0) bằng phương trình sau đây là cần thiết:

s(1)=E_AES-128-CBC {CCK}[b(1)ÅIV]                                                                             Eq.5.2

Trong đó:

• CCK là mã khóa kiểm soát nội dung và IV (CIV) là một véc-tơ khởi tạo, theo quy định tại điều 8.1.4.

Véc-tơ thích hợp IV phải được sử dụng khi bắt đầu gói tin tải. Tải dữ liệu của một gói tin TS dài tối đa 184 byte, số khối tối đa để mã hóa bằng AES-128-CBC là 11 (vì khối dư vẫn là rõ ràng 184 * 8/128 được làm tròn thành 11).

...

...

...

5.6.2.3.2. Khơn độc và kết thúc.

Giả sử rằng một gói tin TS nào đó có thể được chia thành M khối: { b (1), b (2),...,. b (M)}, thường xảy ra là kích thước của khối cuối cùng nhỏ hơn 128 bit. Trong trường hợp này, b (M) theo định nghĩa là một khối ngắn cuối cùng. Xem hình 5.13 để biết chi tiết.

Hình 5.13 - Xáo trộn dữ liệu và khối ngắn cuối cùng.

5.6.2.3.3. Kh Xáo trộn dữ liệu

Trường hợp thứ hai, khối ngắn đơn độc, xảy ra khi gói tin TS được mã hóa chỉ có một khối b (1) và kích thước của nó nhỏ hơn 128 bit. Xem hình 5.14 để biết chi tiết.

Hình 5.14 - "Xáo trộn" khối ngắn đơn độc

5.6.2.3.4. Gi"Xáo trộn"

...

...

...

Khi khối được giải mã lớn hơn 128 bit thì nội dung được giải mã bằng cách sử dụng AES-128 trong chế độ CBC sử dụng công thức sau đây:

b(m ) = E _{AES - 128 - CBC} {CCK} [s(m)] Å s(m-1)                                                            Eq.5.3

Trong đó:

• CCK là mã khóa kiểm soát nội dung.

• s (m) đại diện cho khối 128 bit thứ m trong chuỗi, trong đó m = 2..n. Giải mã khối s(m) hiện tại yêu cầu biết văn bản mã hóa s(m-1) (tức là khối được giải xáo trộn trước đó).

Phương trình 5.3 không làm việc đối với m = 1. Để khởi tạo, công thức sau được sử dụng:

b(1)=D_AES-128-CBC {CCK} [s(1)] Å IV                                                                        Eq . 5.4

Trong đó:

• CCK là mã khóa kiểm soát nội dung và IV (CIV) là một véc-tơ khởi tạo được quy định tại điều 8.1.4.

...

...

...

Hình 5.15 - Giải xáo trộn dữ liệu và khối ngắn cuối cùng.

Hình 5.16 - "Giải xáo trộn" khối ngắn đơn độc

5.7. Thực hiện kiểm soát sao chép nội dung

5.7.1. Định nghĩa URI

Nhà cung cấp nội dung và nhà phân phối nội dung quy định các giá trị thông tin các quy tắc sử dụng (URI) đối với mỗi chương trình (ví dụ như dịch vụ hoặc sự kiện) ngoại tuyến. Hệ thống CA cung cấp URI một cách an toàn từ thiết bị đầu cuối của mạng đến CICAM. CICAM truyền URI đến máy chủ sử dụng giao thức SAC. Máy chủ sử dụng URI để kiểm soát việc tạo ra bản sao, mã hóa kiểm soát sao chép đối với đầu ra tương tự, kích hoạt hình ảnh bị hạn chế và để thiết lập các thông số kiểm soát sao chép đối với các đầu ra của máy chủ.

5.7.2. URI liên kết với nội dung

Hệ thống CA phải liên kết URI với nội dung một cách an toàn, tức là một dịch vụ/sự kiện MPEG cụ thể. URI được liên kết với dịch vụ được lựa chọn thông qua số chương trình MPEG2 16-bit được quy định tại chuẩn ISO 13818-1 [13].

Tất cả các PID thuộc về một chương trình (như đã nêu trong PMT) chỉ có liên kết với một URI.

...

...

...

5.7.3. Truyền URI - từ Thiết bị đầu cuối đến CICAM

URI có thể được truyền từ thiết bị đầu cuối DVB đến CICAM theo những cách không được tiết lộ. Một ví dụ là để truyền thông tin URI thực và thông tin số chương trình trong một bản tin EMM hoặc ECM được hệ thống CA của mạng bảo vệ. Cơ chế truyền chính xác được sử dụng để truyền dữ liệu URI từ thiết bị đầu cuối đến CICAM nằm ngoài phạm vi tiêu chuẩn này.

5.7.4. Truyền URI - từ CICAM đến máy chủ

Khi CICAM thu được dữ liệu URI thì dữ liệu này phải được truyền từ CICAM đến máy chủ thông qua định dạng bản tin URI. Định dạng bản tin URI được mô tả trong điều 5.7.5.2.

CICAM chuyển URI đến máy chủ dưới các điều kiện hoạt động khác nhau bằng cách sử dụng phương pháp sau đây:

• Khi xem nội dung trực tiếp, sử dụng phương thức truyền URI và giao thức thừa nhận (Xem phần 11.3.3.6)

• Khi ghi lại nội dung với EMI = 1,1, sử dụng giao thức Trao đổi Giấy phép (Xem phần 11.3.4.1)

• Khi chơi lại nội dung đã ghi mà trong đó có một giấy phép, sử dụng giao thức Trao đổi Giấy phép chơi lại (Xem phần 11.3.4.2)

Một Cl Plus CICAM sẽ không gửi truyền URI trừ khi nó đã được lựa chọn bởi các máy chủ cho việc giải xáo trộn các dịch vụ hiện tại.

...

...

...

Bảng 5.7: Giá trị mặc định cho Cl Plus URI phiên bản 1

Trường

Giá trị khởi tạo mặc định

protocol version

0x01

emi_copy_control_info

0b11

aps_copy_control_info

0b00

...

...

...

0b0

rct_copy_control_info

0b0

rl_copy_control_info

0b000000

Các bit dự phòng

0b0

Bảng 5.8: Giá trị mặc định cho Cl Plus URI phiên bản 2

Trường

...

...

...

protocol version

0x02

emi_copy_control_info

0b11

aps_copy_control_info

0b00

ict_copy_control_info

0b0

rct_copy_control_info

...

...

...

dot_copy_control_info

0b0

rl_copy_control_info

0b00000000

Các bit dự phòng

0b0

Sau khi thiết lập URI mặc định ban đầu này, máy chủ phải bắt đầu bộ đếm thời gian 10 giây. Nếu máy chủ chưa hoàn thành thành công giao thức truyền URI khi bộ đếm thời gian đạt đến mười (10) giây, máy chủ phải thay đổi các giá trị URI sang giá trị lỗi giống như giá trị mặc định ban đầu, ngoại trừ bit ICT được thiết lập là 0b1: trong trường hợp đó, máy chủ phải áp dụng nén hình ảnh nếu bit ICT đã được thiết lập là một. URI sau thời gian chờ được gọi là URI mặc định cuối cùng.

Một thiết bị tuân thủ Cl Plus phải hỗ trợ URI phiên bản 0x01 và 0x02 và có thể bỏ qua các phiên bản URI khác. Bất kỳ phiên bản URI tương lai phải kết hợp các bit EMI và APS được định nghĩa trong phiên bản 0x01.

Các phiên bản URI tương lai không được ghi đè lên các bít hiện có trong phiên bản URI 0x01. Điều này có nghĩa rằng các phiên bản URI tương lai có thể thêm những hạn chế nội dung bổ sung mà thiết bị trong tương lai có thể hỗ trợ, miễn là những hạn chế nội dung không làm các khả năng giới hạn ít hơn. Các thiết lập của các bit EMI, APS và ICT phải luôn luôn được giữ nguyên.

...

...

...

5.7.5. Giao thức làm mới URI

Bản tin URI được truyền từ CICAM đến máy chủ được SAC bảo vệ (xem điều 7). CICAM và máy chủ phải cùng nhau thực hiện các bước dưới đây một lần đối với từng lần truyền URI. Bất kỳ sự thất bại của các bước được mô tả dưới đây cũng dẫn đến việc truyền URI thất bại. Nếu giao thức không được hoàn thành thành công trước khi thời gian chờ hết hạn một giây thì CICAM phải vô hiệu việc CA giải xáo trộn và máy chủ phải thiết lập URI sang giá trị URI mặc định cho đến khi giao thức làm mới URI hoàn thành thành công.

CICAM phải gửi một URI đến máy chủ chỉ sau khi CICAM và máy chủ đã được liên kết thành công và thương lượng một mã khóa kiểm soát nội dung chung (CCK). CICAM phải bắt đầu việc truyền URI đến máy chủ trên dịch vụ được CA kiểm soát ngay sau khi:

• Máy chủ gửi một ca_pmt mới đến CICAM, hoặc

• Số chương trình thay đổi trên một 'kênh' được dò kênh, hoặc

• bất kỳ thay đổi trong các bit URI trong một chương trình, hoặc

• bất kỳ thay đổi trong các giá trị ID của gói tin MPEG (PID) mà CICAM đang giải xáo trộn. Quá trình chính xác được giải thích trong hình 5.17.

CHÚ THÍCH

...

...

...

2. Các bước 1 và 2 được trình bày nhưng nằm ngoài phạm vi của tiêu chuẩn này.

3. Tham chiếu hình 5.15 để biết tổng quan về giao thức làm mới URI và giao thức làm mới CCK.

Hình 5.17 - Giao thức làm mới URI (tham khảo)

Quá trình này được mô tả trong bảng 5.9:

Bảng 5.9: Hành vi giao thức URI (quy định)

TT

Mô tả

Tham chiếu đến

1

...

...

...

URI được kết hợp với nội dung này (dịch vụ hoặc sự kiện DVB). Quá trình chính xác; bao gồm các giá trị URI thay thế nằm ngoài phạm vi tiêu chuẩn này.

2

Cung cấp URI ví dụ trong EMM (nằm ngoài phạm vi tiêu chuẩn này).

Việc cung cấp URI thường được hệ thống CA bảo vệ giữ sự kết hợp giữa URI và số chương trình. Quá trình cung cấp chính xác này nằm ngoài phạm vi tiêu chuẩn này.

3

CICAM tạo bản tin URI.

CICAM tính uri_confirm để xác thực xác nhận của máy chủ đã nhận được (CHÚ THÍCH 5), vì:

...

...

...

trong đó:

• UCK = SHA₂₅₆ (SAK)

Giá trị uri_confirm được lưu trữ nội bộ để so sánh trong bước 8.

CICAM phải tạo một cc_sac_data_req APDU dành cho bản tin URI này, bao gồm:

• uri_message,

• program_number

Điều 5.7.5.1

4

CICAM khởi tạo thời gian chờ 1 giây.

...

...

...

Hình 5.11

5

CICAM truyền bản tin SAC với tải URI

CICAM truyền một bản tin SAC với tải từ bước 3 và truyền bản tin này đến máy chủ. (CHÚ THÍCH 2).

Điều 7.3 và 11.3.1

6

Máy chủ kiểm tra bản tin.

Sau khi máy chủ kiểm tra bản tin SAC xem có đúng không thì máy chủ lấy giá trị URI và số chương trình.

...

...

...

Máy chủ truyền bản tin SAC với xác nhận URI

Máy chủ kiểm tra xem nó có hỗ trợ phiên bản URI mà CICAM yêu cầu. Máy chủ xác nhận việc cung cấp URI bằng cc_sac_data_cnf APDU, bao gồm

• uri_confirm

và sử dụng SAC đề truyền bản tin này đến CICAM. (CHÚ THÍCH 2)

Máy chủ tính uri_confimn theo cách giống như CICAM trong bước 3 ở trên. Không trả lời sẽ dẫn đến không có hệ thống bảo vệ sao chép và thiết lập URI về giá trị mặc định (CHÚ THÍCH 3 & 4).

Điều 7.3 và 11.3.1

8

CICAM kiểm tra xác nhận của máy chủ.

CICAM so sánh uri_confirm nhận được từ máy chủ với giá trị được tính trong bước 3 ở trên.

...

...

...

9

Sử dụng các thiết lập kiểm soát sao chép

Máy chủ phải kiểm soát các đầu ra của nó dựa vào URI hợp lệ ngay lập tức.

CHÚ THÍCH:

1. Nếu các bước trên không được hoàn thành trước khi hết thời gian chờ 1 giây thì CICAM phải không cho phép giải xáo trộn CA nội dung được bảo vệ sao chép (tức là EMI ≠ 0x0) đối với chương trình MPEG kết hợp cho tới khi giao thức cung cấp URI hoàn thành thành công. Khi giao thức này hoàn thành thì CICAM phải chờ 1 giây trước khi giao thức URI này được khởi tạo lại.

2. Xem điều 7.2 để biết cách dữ liệu của giao thức URI này được đóng gói vào bản tin SAC.

3. Máy chủ phải áp dụng các thiết lập URI mặc định. Các giá trị URI mặc định được quy định trong điều 5.7.4.

...

...

...

5. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

5.7.5.1. Giao thức tuân theo danh sách hợp lệ S

Hình 5.18 - Giao thức thương lượng phiên bản URl

Thương lượng phiên bản URI được thực hiện một lần sau khi khởi tạo (lại) SAC. CICAM gửi một bản tin tới máy chủ yêu cầu các phiên bản URI nó có khả năng hỗ trợ. Máy chủ trả lời bằng một bitmask của các phiên bản URI mà nó hỗ trợ. Tham khảo điều 11.3.3.7.

CICAM phải xác định các tổ hợp phù hợp của các phiên bản URI được cả CICAM và máy chủ hỗ trợ. CICAM quyết định phiên bản URI nào sử dụng, quá trình chính xác này nằm ngoài phạm vi tiêu chuẩn này.

Nếu không tìm thấy tổ hợp phù hợp của các URI phiên bản nào ngoài phiên bản mặc định, hệ thống phải sử dụng phiên bản URI mặc định.

5.7.5.2. Nếu không tìm thấy tổ hợp

Cú pháp bản tin URI phiên bản 1 được quy định tại Bảng 5.10, cú pháp phiên bản 2 được thể hiện trong Bảng 5.11.

...

...

...

Trường

Độ dài

Kiểu

uri_message() {

     protocol_version

8

uimsbf

...

...

...

2

uimsbf

     emi_copy_control_info

2

uimsbf

     ict_copy_control_info

1

uimsbf

     rct_copy_control_info

...

...

...

uimsbf

     reserved for future use

4

uimsbf

     r1_copy_control_info

6

uimsbf

     reserved for future use

40

...

...

...

}

Bảng 5.11: Cú pháp bản tin URI phiên bản 1

Trường

Độ dài

Kiểu

uri_message() {

...

...

...

     protocol_version

8

uimsbf

     aps_copy_control_info

2

uimsbf

     emi_copy_control_info

2

uimsbf

...

...

...

1

uimsbf

     if (emi_copy_control_info == 00) {

     rct_copy_control_info

     }

     else {

1

...

...

...

          reserved = 0

     }

1

uimsbf

     reserved for future use

...

...

...

uimsbf

     if (emi_copy_control_info == 11) {

1

     dot_copy_control_info rl_copy_control_info

     }

     else {

8

uimsbf

...

...

...

          reserved = 0x00

9

uimsbf

     }

...

...

...

40

uimsbf

}

5.7.5.3. Mã hóa và ngtrol_info rl_copy_contr

protocol_version: tham số này chỉ ra phiên bản của định nghĩa URI và được định nghĩa trong Bảng 5.12:

Bảng 5.12: Giá trị cho phép của protocol_version

Nội dung

...

...

...

Diễn giải

0x00

Forbidden

không được sử dụng trong tiêu chuẩn này

0x01

Giao thức URI phiên bản 1

Bản quy định kỹ thuật phiên bản 1.2

0x02

Giao thức URI phiên bản 2

...

...

...

0x03-0xFF

Dự phòng

CHÚ THÍCH: Thiết bị tuân theo tiêu chuẩn này phải nhận biết được giá trị 0x02 và bỏ qua các bản tin URI có giá trị protocol_version không được hỗ trợ.

aps_copy_control_info: tham số này mô tả các bit của hệ thống bảo vệ tương tự (APS) trong đó xác định các thiết lập bảo vệ sao chép tương tự được sử dụng trên đầu ra tương tự, như được giải thích trong Bảng 5.13:

Bảng 5.13: Giá trị cho phép của aps_copy_control

Nội dung

Giá trị nhị phân

Diễn giải

...

...

...

00

Tắt mã hóa bảo vệ sao chép

0x1

01

Bật quá trình AGC, tắt chia tách cụm

0x2

10

Bật quá trình AGC, bật chia tách cụm 2 đường

0x3

...

...

...

Bật quá trình AGC, bật chia tách cụm 4 đường

emi_copy_control_info: tham số này mô tả các bit chỉ số chế độ mã hóa (EMI). Hệ thống Cl Plus phải sử dụng các bit EMI để thực hiện các quyền kiểm soát sao chép đối với các đầu ra kỹ thuật số và tương tự như được giải thích ở Bảng 5.14:

Bảng 5.14: Giá trị cho phép của emi_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x0

00

Việc sao chép không bị cấm

...

...

...

01

Việc sao chép thêm không được cho phép

0x2

10

Việc sao chép được cho phép

0x3

11

Việc sao chép bị cấm

ict_copy_control_info: tham số này mô tả bit ICT. Máy chủ phải sử dụng bit ICT để kiểm soát chất lượng hình ảnh bị nén đối với các đầu ra thành phần tương tự HD được giải thích trong Bảng 5.15.

...

...

...

Nội dung

Giá trị nhị phân

Diễn giải

0x0

0

Không sử dụng nén hình ảnh

0x1

1

Yêu cầu nén hình ảnh

...

...

...

Bảng 5.16: Giá trị cho phép của rct_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x0

0

Không sử dụng kiểm soát phân phối lại. Giá trị mặc định.

0x1

1

...

...

...

dot_copy_control_info: tham số này mô tả bit DOT. Máy chủ phải sử dụng bit DOT để kiểm soát các đầu ra video tương tự như được giải thích trong Bảng 5.17. Khi các bit EMI là (1,1) CICAM có thể thiết lập bit dot_copy_control_info một giá trị khác không (0) để ngăn cấm máy chủ đưa ra nội dung video tương tự.

Bảng 5.17: Giá trị cho phép của dot_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x0

0

Không sử dụng nén đối với nội dung số (mặc định)

0x1

...

...

...

Chỉ sử dụng nén đối với nội dung số; cấm đưa ra trên các đầu ra video tương tự.

rl_copy_control_info: trường này mô tả giới hạn duy trì việc ghi chép và/hoặc thời gian chuyển nội dung từ thời gian mà nó được giữ lại. Hình 5.19 chỉ ra cách áp dụng giới hạn duy trì này. Các bit rl_copy_control_info mặc định trong bản tin URI phải luôn luôn được lấp đầy bằng giá trị giới hạn duy trì mặc định (0x00) trừ khi các bit EMI được thiết lập giá trị là một, một (1,1). Khi EMI là (1,1) CICAM có thể thiết lập các bit rl_copy_control_info một giá trị khác không 0x00 (zero) để ghi đè giới hạn duy trì mặc định 90 phút này, các giá trị khác có thể thông báo một giới hạn duy trì tính theo giờ hoặc ngày. Khi EMI là (1,1) và CICAM đã không nhận được thông tin từ mạng thì giá trị rl_copy_control_infovalue mặc định trong bản tin URI được làm đầy bằng giá trị giới hạn duy trì mặc định 0x00.

Hình 5.19 - Ví dụ về giới hạn thời gian duy trì 90 phút

Bảng 5.18 - Các giá trị URI phiên bản 1 cho phép đối với rl_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x00

...

...

...

Áp dụng giá trị giới hạn duy trì mặc định 90 phút

0x01

000001

Áp dụng giá trị giới hạn duy trì 6 giờ

0x02

000010

Áp dụng giá trị giới hạn duy trì 12 giờ

0x03-0x3F

000011-111111

...

...

...

Bảng 5.19 - Các giá trị URI phiên bản 2 cho phép đối với rl_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x00

00000000

Áp dụng giá trị giới hạn duy trì mặc định 90 phút

0x01

00000001

...

...

...

0x02

00000010

Áp dụng giá trị giới hạn duy trì 12 giờ

0x03-0xFE

00000011-11111110

Áp dụng giá trị giới hạn duy trì là bội số 1 đến 252 lần của 24 giờ tùy theo giá trị nhị phân

0xFF

11111111

Thời gian duy trì không bị giới hạn

...

...

...

Ví dụ:

rl_copy_control_info của mạng = 0xf0 (238 ngày)

Máy chủ có URIv2 rl_copy_control_info = 0xf0 (238 ngày)

Máy chủ có URIv1 rl_copy_control_info = 0x3f (61 ngày)

5.8. Các chế độ hoạt động

Máy chủ và CICAM đáp ứng tiêu chuẩn này phải hoàn toàn tương thích với giao diện chung được quy định tại EN 50221 [7] và TS 101 699 [8]. Một DVB CICAM được ghép vào một máy chủ Cl Plus phải hoạt động bình thường. Máy chủ phải nhận ra rằng Cl là DVB Cl và sử dụng các tài nguyên của DVB Cl. Nếu Cl Plus CAM được ghép vào một máy chủ DVB Cl, máy chủ phải nhận ra máy chủ là một thiết bị DVB Cl hợp lệ và hoạt động bình thường. Bảng 5.21 mô tả các chế độ hoạt động khác nhau của CICAM và máy chủ.

Bảng 5.20: Các chế độ hoạt động của CICAM và Máy chủ

Máy chủ

CICAM

...

...

...

EMI>0

EMI=0

Cl Plus

DVB Cl

DVB Cl (CHÚ THÍCH 1)

DVB Cl

DVB Cl

Cl Plus

...

...

...

Không giải xáo trộn (CHÚ THÍCH 2)

DVB Cl (CHÚ THÍCH 4)

Cl Plus

Cl Plus

Đã xác thực

Giải xáo trộn + CC (CHÚ THÍCH 4)

Giải xáo trộn

Cl Plus

Cl Plus

...

...

...

Không giải xáo trộn

DVB Cl (CHÚ THÍCH 4)

Cl Plus

Cl Plus

CCK không thành công

Không giải xáo trộn

DVB Cl (CHÚ THÍCH 4)

Cl Plus

Cl Plus

...

...

...

Không giải xáo trộn

Không giải xáo trộn

Cl Plus

Cl Plus

Máy chủ bị hủy bỏ

CICAM Pass-through (CHÚ THÍCH 3)

CICAM Pass-through (CHÚ THÍCH 3)

Cl Plus

Cl Plus

...

...

...

Không giải xáo trộn

Không giải xáo trộn

CHÚ THÍCH:

1. Chỉ khi nhãn mô tả Cl Plus không có trong SDT_Actual.

2. CICAM phải phát hiện EMI >0 và không được giải xáo trộn.

3. Nội dung được truyền qua CICAM không bị thay đổi.

4. Nhà điều hành dịch vụ và CAS có thể lựa chọn dựa vào các điều kiện kiểm soát nội dung để giải xáo trộn nội dung sang thiết bị DVB Cl

5.8.1. Máy chủ hoạt động với nhiều CICAM

Một máy chủ tuân thủ Cl Plus có thể hỗ trợ tối đa 5 khe Cl Plus. Mỗi khe có thể ghép một DVB CICAM hoặc một Cl Plus CAM. Tất cả các kết hợp là được cho phép. Có thể có thêm khe cắm bổ sung chỉ hỗ trợ DVB CI.

...

...

...

Hình 5.20 - Truyền nối tiếp TS qua các CICAM

Máy chủ và CICAM đơn sẽ phải giải xáo trộn một dịch vụ và có khả năng tái xáo trộn nó tùy theo đặc điểm kỹ thuật này. Một tình huống khi mà hai hay nhiều mô đun giải xáo trộn một dịch vụ khác của TS có thể được tùy chọn thực hiện bởi máy chủ và CICAM.

Khi một CICAM được cắm vào, máy chủ bắt đầu giao tiếp với CICAM như mô tả trong EN 50.221 [7]. CICAM mở phiên cần thiết cho hoạt động của nó. Máy chủ nhớ số thứ tự của khe cắm tương ứng cho mỗi phiên mở cửa. Khi có nhiều hơn một CICAM có mặt trong quá trình khởi của máy chủ, máy chủ có thể khởi tạo các CICAMs từng cái một, tức là nó có thể trì hoãn khởi tạo CICAM tiếp theo cho đến khi CICAM trước đó là hoàn thành.

Lúc khởi động, một CICAM đầu tiên thực hiện việc xác minh khóa xác thực của máy chủ (AKH). Nếu thành công, Giao thức xác thực hoàn toàn có thể được bỏ qua. Điều 6.3 giải thích thủ tục này. Khi một CICAM cố gắng mở một phiên đến một tài nguyên, máy chủ có thể bận vì nhiều lý do. Một CICAM phải chấp nhận một phản hồi "tài nguyên bận" khi nó cố gắng mở một phiên.

Một Cl Plus CAM không được gửi URI trừ khi nó đã được máy chủ lựa chọn cho giải xáo trộn dịch vụ hiện tại.

Các CICAM phải hỗ trợ các máy chủ có nhiều khe cắm dùng chung địa chỉ, dữ liệu và các đường điều khiển. Mỗi CICAM phải kiểm tra chân Cho phép thẻ số 1 (CE1 #) trước khi sử dụng bất kỳ tín hiệu nào trên bus dùng chung.

Khi một mô-đun yêu cầu tính toán lại mã khóa CC trong khi máy chủ đang chạy một tính toán lại mã khóa CC đối với một mô-đun khác thì máy chủ có thể chỉ ra rằng nó đang bận.

Khi một CICAM gặp dữ liệu của TS mà không hiểu được thì nó phải chuyển tiếp không làm thay đổi TS này.

...

...

...

5.8.2.1. Giới thiệu

Phần này định nghĩa cách một CICAM duy nhất với nhiều hệ thống CA và nhiều bộ đọc thẻ thông minh phải hoạt động theo các yêu cầu Cl Plus.

5.8.2.2. Giấy chứng nhận thiết bị CICAM

CICAM chỉ được có một Giấy chứng nhận thiết bị; Giấy chứng nhận này không phụ thuộc vào số lượng các hệ thống CA được CICAM hỗ trợ.

5.8.2.3. Làm mới CCK

CCK độc lập với hệ thống CA; Hệ thống CA có trách nhiệm kiểm soát việc làm mới CCK. Khi khởi tạo CICAM, CCK này được tạo ra như được quy định tại điều 8.1.4.

Chỉ có một hệ thống CA được hoạt động tại một thời điểm, chỉ có hệ thống CA đang hoạt động kiểm soát lệnh làm mới CCK. Việc làm mới CCK được quy định tại điều 8.1.2.

5.8.2.4. Thu hồi máy chủ

Thu hồi máy chủ chỉ được hệ thống CA đang hoạt động thực hiện.

...

...

...

Tiêu chuẩn này yêu cầu xác thực lẫn nhau giữa máy chủ và CICAM. Trước khi CICAM có thể bắt đầu giải xáo trộn nội dung được CA bảo vệ, máy chủ và CICAM phải thông qua một thủ tục xác thực, đó là hoàn thành thành công các nội dung sau:

• CICAM yêu cầu và máy chủ cung cấp chuỗi của giấy chứng nhận của nó. CICAM kiểm tra đóng dấu của giấy chứng nhận thiết bị máy chủ có chứa HOST_ID và CICAM kiểm tra đóng dấu giấy chứng nhận thương hiệu của máy chủ.

• Máy chủ yêu cầu và CICAM cung cấp chuỗi của giấy chứng nhận của nó. Máy chủ kiểm tra đóng dấu của giấy chứng nhận thiết bị CICAM có chứa CICAM_ID và máy chủ kiểm tra đóng dấu của giấy chứng nhận thương hiệu của CICAM.

• CICAM và máy chủ chứng minh chúng có mã khóa riêng tương ứng với mã khóa công khai được nhúng trong giấy chứng nhận bằng cách đóng dấu một mã khóa công khai DH, cùng với dữ liệu giao thức khác, và gửi nó đến thiết bị kia để xác nhận đóng dấu.

• Nhà cung cấp dịch vụ kiểm tra xem HOST_ID và CICAM_ID được lấy từ các giấy chứng nhận có được bao gồm trong SOCRL không khi trong chế độ đăng ký dịch vụ, xem điều 5.4.2.

• CICAM và máy chủ chứng minh rằng họ có thể đưa ra được mã khóa xác thực.

Quá trình này được mô tả chi tiết trong điều 6.

Tùy chọn, CICAM có thể nhận được bản tin xác nhận từ nhà điều hành dịch vụ, liệt kê các ID của thiết bị từ bản tin RMR trong chế độ đăng ký dịch vụ. Hệ thống CA phải cung cấp bản tin này một cách an toàn.

Khi nhận được bản tin này, máy chủ và CICAM có thể tiếp tục quá trình xác thực miễn là cả hai điều kiện sau đây là hợp lệ:

...

...

...

• CICAM_ID được xác nhận phù hợp với CICAM_ID trong giấy chứng nhận thiết bị CICAM X.509 được xác thực.

Việc thực hiện của hệ thống CA đối với việc này nằm ngoài phạm vi của tiêu chuẩn này.

Cơ chế xác thực lẫn nhau dựa trên Diffie-Helman (DH). Xem PKCS # 3 [31] để biết chi tiết về DH. Giao thức xác thực Cl Plus sử dụng một giao thức thông qua 3, được áp dụng cho thuật toán DH chuẩn để thỏa thuận mã khóa. Diễn giải đơn giản của giao thức thông qua 3 của DH được đưa ra trong hình 5.21.

Hình 5.21: Quy trình thông qua 3 của Diffie-Hellman

Lưu ý rằng cả hai phía đều tính toán một mã khóa riêng DH. Mỗi phía tính toán mã khóa bắt đầu với một cặp giá trị riêng khác nhau (ví dụ như x và y) và đưa ra cùng một mã khóa mật giống nhau (mã khóa riêng DH).

Một số phương pháp được thực hiện để bảo vệ các thông số DH này khi truyền giữa CICAM và máy chủ:

• CICAM bắt đầu trao đổi bằng cách gửi một nonce đến máy chủ. Nonce này được một giao thức hoàn toàn truyền và được sử dụng trong các đóng dấu để trao đổi tham số trong giao thức này.

• CICAM và máy chủ phải trao đổi lẫn nhau các giấy chứng nhận thiết bị và thương hiệu được lưu trong chúng do ROT tạo ra. Máy chủ phải kiểm tra đóng dấu của giấy chứng nhận thiết bị CICAM.

...

...

...

Xem điều 6 để biết chi tiết về các cơ chế xác thực hợp lệ.

5.10. Trao đổi giấy phép nội dung

Khi một mục của nội dung được ghi lại có URI với EMI = "1,1", CICAM có thể cung cấp cho một giấy phép tại thời điểm ghi lại. Máy chủ phải kết hợp giấy phép này với mục của nội dung để lấy thời gian ghi lại. Nếu có giấy phép dành cho một mục của nội dung thì giấy phép này có thể được CICAM kiểm tra khi nội dung này được phát lại để xác định xem máy chủ vẫn có quyền được sử dụng nội dung. Việc kiểm tra giấy phép nội dung này yêu cầu CICAM và máy chủ truyền các giấy phép cho nhau qua giao diện chung một cách an toàn. Khi ghi lại thì giấy phép được CICAM cung cấp chứa dữ liệu cụ thể CAS được máy chủ lưu và được kết hợp với nội dung được ghi lại. Khi phát lại nội dung được ghi lại thì giấy phép được kết hợp này được truyền lại cho CICAM đã tạo ra giấy phép mà không có bất kỳ sự thay đổi. CICAM kiểm tra giấy phép này và trả về trạng thái phát lại cùng với một giấy phép mới và phát lại URI thay thế giấy phép nội dung hiện có. Máy chủ được yêu cầu trả lại giấy phép cho CICAM đã cấp giấy phép này, máy chủ sử dụng CICAM_ID để xác định CICAM được sử dụng để ghi lại và sau đó phát lại.

Các giấy phép luôn luôn được trao đổi thông qua SAC sử dụng cc_sac_data_req và cc_sac_data_cnf APDU, xem điều 11.3.1.3 và 11.3.1.4.

5.10.1. Giao thức khởi tạo ghi lại

Máy chủ thông báo bắt đầu ghi lại một dịch vụ được CA bảo vệ CA cho CICAM bằng giao thức khởi tạo ghi lại sử dụng SAC, xem điều 11.3.4.4 để biết chi tiết giao thức. Việc trao đổi này thông báo cho CICAM chế độ hoạt động hiện tại của máy chủ và tùy chọn cho phép máy chủ cung cấp CICAM PIN. CICAM có thể lưu trữ CICAM PIN dành cho ghi lại tự động hoặc tạm dừng. CICAM PIN chỉ phải được sử dụng để cho phép ghi lại không bị gián đoạn khi một sự kiện cha mẹ kiểm soát trong tương lai có thể xảy ra. CICAM PIN không được sử dụng để thực hiện việc kiểm soát của cha mẹ đối với việc phát lại và xem trực tiếp mà người sử dụng phải được yêu cầu nhập CICAM PIN bằng MMI.

Máy chủ có thể thiết lập giao thức Khởi tạo ghi lại trên một dịch vụ FTA với giả định rằng dịch vụ có thể chuyển thành dịch vụ được CA bảo vệ sau. Các CICAM không nên đợi một giao thức khởi tạo ghi lại khác tại bất kỳ trao đổi nào trong tương lai giữa FTA và CA được bảo vệ.

5.10.2. Trao đổi giấy phép nội dung đối với việc ghi lại

Nếu giấy phép được yêu cầu có liên kết với một mục của nội dung thì khi bắt đầu ghi lại, CICAM gửi cho máy chủ một giấy phép bằng cách sử dụng SAC. Quá trình trao đổi giấy phép này sử dụng giao thức SAC trao đổi giấy phép từ CICAM đến máy chủ, xem điều 11.3.4.1 để biết cụ thể hơn.

...

...

...

Máy chủ có thể xác định trạng thái hiện tại của một giấy phép nội dung liên kết với việc ghi lại bằng cách sử dụng giao thức SAC kiểm tra giấy phép, xem điều 11.3.4.3. Máy chủ phải gửi bản tin này đến CICAM đã cấp giấy phép này. Giao thức kiểm tra giấy phép chỉ cung cấp thông tin của máy chủ mà không được sử dụng để đánh giá quyền phát lại.

CICAM trả lời giấy phép kiểm tra bằng thông tin trạng thái của giấy phép này. Thông tin trạng thái này cung cấp thông tin về tình trạng sẵn có của nội dung và có thể được sử dụng khi hiển thị một thư mục ghi lại. Thông tin trạng thái này bao gồm một trường 8-bit play_count có chứa số lượt phát còn lại mà người sử dụng được hưởng.

5.10.4. Trao đổi giấy phép nội dung phát lại

Khi phát lại nội dung có giấy phép liên kết thì máy chủ phải gửi giấy phép này đến CICAM ghi lại nội dung gốc này để đánh giá. Giấy phép này được gửi đến CICAM một cách an toàn trên SAC sử dụng giao thức giấy phép phát lại, xem điều 11.3.4.2. CICAM này xử lý giấy phép này để thiết lập nếu nó vẫn có quyền để phát lại nội dung này. Một giấy phép mới và URI được trả lại cho máy chủ để thay thế bản gốc trong trường hợp thông tin đã thay đổi, ví dụ như play_count. Việc trao đổi giấy phép trên giao thức phát lại được thực hiện song song trong khi đang phát lại nội dung để đảm bảo rằng việc bắt đầu phát lại không bị trì hoãn. Nếu trả lời của giấy phép phát lại không là OK, hoặc trả lời kéo dài hơn 10 giây thì phát lại phải bị dừng lại.

URI mà đính kèm với giấy phép trong Giao thức trao đổi giấy phép nội dung phát lại sẽ được áp dụng ngay lập tức.

5.10.5. Giấy phép nội dung và quá trình chế độ tạm dừng (Timeshift)

Máy chủ không cần phải lưu trữ hoặc trao đổi các giấy phép nội dung khi ghi đệm nội dung cho chế độ tạm dừng, ví dụ như tạm dừng tường thuật trực tiếp (90 phút duy trì). Tuy nhiên, nếu máy chủ sau đó thay đổi các nội dung đã ghi đệm vào một bản ghi, nó phải kết hợp các giấy phép nhận được với các mục nội dung cho toàn bộ thời gian của bản ghi.

LƯU Ý: Điều này có nghĩa rằng trong quá trình chế độ tạm dừng diễn ra, cho phép chuyển đổi các bộ đệm chế độ tạm dừng vào một bản ghi thì sau đó tất cả các giấy phép nội dung đã nhận được trong khoảng thời gian nội dung lưu đệm phải được giữ lại cho đến khi nội dung đệm không còn chuyển đổi thành một bản ghi.

5.10.6. Thỏa thuận dừng ghi (Protocol Record Stop Protocol)

...

...

...

5.11. Kiểm soát của cha mẹ

Đối với dịch vụ FTA, việc xác định độ tuổi phù hợp với nội dung chương trình có thể được thực hiện thông qua nhận diện mô tả của cha mẹ khi sử dụng DVB. Máy chủ có thể tùy chọn cung cấp một cơ chế để:

• Thiết lập việc đánh giá độ tuổi tối đa đối với nội dung có yêu cầu nhập mã PIN trước khi xem.

• Việc nhập mã PIN sẽ cho phép có các ngoại lệ đối với giới hạn này. Theo mục đích của tiêu chuẩn này, PIN này sẽ được gọi là PIN của máy chủ.

Đối với dịch vụ được CA bảo vệ, việc đánh giá độ tuổi có thể được gửi qua hệ thống CA hoặc trong dòng truyền tải bằng cách sử dụng nhãn DVB parental_rating_descriptor. Đối với các dịch vụ được CA bảo vệ, việc đưa ra kiểm soát của cha mẹ nằm ngoài phạm vi tiêu chuẩn này và được CAS và/hoặc CICAM xác định. CICAM có thể cung cấp một menu chương trình để thiết lập mã PIN cho phép một ngoại lệ. Theo mục đích của tiêu chuẩn này, mã PIN này được gọi là CICAM PIN. Phương pháp chính xác được sử dụng để cung cấp việc đánh giá độ tuổi trong trường hợp này nằm ngoài phạm vi của tiêu chuẩn này.

Tiêu chuẩn này bổ sung thêm các tính năng đối với tài nguyên kiểm soát nội dung để cho phép hai hệ thống kiểm soát của cha mẹ tiềm năng này được xử lý như một hệ thống nhằm thuận tiện cho người sử dụng. Việc kiểm soát của cha mẹ đối với dịch vụ được CA bảo vệ được xử lý như bình thường tùy thuộc vào các khả năng của CICAM PIN. CICAM có thể thông báo cho máy chủ đánh giá độ tuổi tối thiểu mà máy chủ bắt đầu để xử lý việc quản lý mã PIN, cho phép máy chủ phát huy việc kiểm soát của cha mẹ khi việc đánh giá của máy chủ được thiết lập để một mức độ thấp hơn so với việc đánh giá này của CICAM. Đối với các dịch vụ FTA khi máy chủ xác định rằng nội dung hiện tại có một đánh giá độ tuổi vượt quá ngưỡng tuổi của người sử dụng thì máy chủ có thể chuyển việc kiểm soát nhập mã PIN sang CICAM bằng một bản tin cc_PIN_MMI_req () có chứa mã PIN FTA của máy chủ (phụ thuộc vào các khả năng của CICAM PIN được thông báo). Sau đó, CICAM tạo ra một MMI hướng dẫn người sử dụng nhập mã PIN. CICAM so sánh PIN được nhập với CICAM PIN và mã PIN của máy chủ được truyền trong bản tin và nếu người sử dụng nhập mã PIN phù hợp với một trong hai mã PIN trên thì nội dung được phép xem.

Trong quá trình xem bình thường, người sử dụng có thể được yêu cầu nhập mã PIN để tiếp tục xem một dịch vụ hoặc sự kiện. Điều này có thể xảy ra khi lựa chọn dịch vụ hoặc lúc bắt đầu xem một sự kiện mới. Trong quá trình xem sự kiện bình thường, người xem sẽ nhập mã PIN chính xác và tiếp tục theo dõi các dịch vụ hoặc sự kiện. Video và âm thanh không được có cho đến khi nhập đúng mã PIN.

Trong quá trình ghi lại hoặc đang tạm dừng nội dung được CA bảo vệ, các hành vi nói trên sẽ gây ra các khoảng thời gian trống không thể chấp nhận khi nội dung này không được giải xáo trộn để ghi lại và do đó không thể xem được trong quá trình phát lại. Tiêu chuẩn này quy định một cơ chế theo đó máy chủ truyền PIN của nó trong cc_Record_Start () APDU mà CICAM nên lưu trữ trong trường hợp nó được yêu cầu trong quá trình ghi lại. Để đảm bảo rằng cơ chế này không được lạm dụng CICAM phải xóa tất cả các mã PIN được lưu trữ khi đến phần cuối của việc ghi lại này.

Trong phạm vi của tiêu chuẩn này, mã PIN của máy chủ và CICAM được giả định là số chữ số từ 0 đến 9 và sẽ không quá 8 chữ số.

...

...

...

Máy chủ phải tuân theo các quy tắc kiểm soát của cha mẹ được định nghĩa trong Thỏa thuận cấp phép tạm thời thiết bị Cl Plus [6].

5.11.1. Các khả năng của CICAM PIN

Tài nguyên kiểm soát nội dung mã PIN cung cấp các tính năng cho phép CICAM quản lý PIN với nhiều mức. CICAM thông báo các khả năng của nó để trả lời yêu cầu từ máy chủ về các khả năng. CICAM có thể đề nghị không quản lý mã PIN đối với tất cả hoặc có thể thông báo khả năng xử lý việc quản lý mã PIN đối với nội dung được CA kiểm soát, khả năng xử lý việc quản lý mã PIN đối với cả nội dung FTA và được CA kiểm soát.

Các APDU của các khả năng cc_PIN, xem điều 11.3.2.1, cho phép máy chủ xác định cách các sự kiện và các dịch vụ chương trình được kiểm soát của cha mẹ đối với mã PIN bất kỳ quản lý. Tài nguyên này được tất cả các thiết bị máy chủ phân tích và thực hiện.

Các khả năng của mã PIN được gửi đến máy chủ sử dụng cc_PIN_capabilities_reply () APDU. APDU này được gửi để trả lời một cc_PIN_capabilities_req () từ máy chủ. cc_PIN_capabilities_reply () APDU cũng được gửi đến máy chủ bất cứ khi nào các khả năng của mã PIN thay đổi kể cả khi đánh giá độ tuổi hiệu quả mà CAM bắt đầu quản lý mã PIN bị thay đổi trong CICAM này.

APDU của các khả năng của mã PIN chứa thông tin cho phép CICAM thông báo cho máy chủ cách mã PIN bất kỳ đang được xử lý để đảm bảo rằng máy chủ không can thiệp vào hoạt động này. APDU này chứa thời gian và ngày thay đổi cuối cùng của mã PIN cho phép máy chủ xác định nếu có ghi lại được lập lịch yêu cầu một mã PIN mới.

Khả năng của CICAM PIN được trình bày trong các phần sau.

5.11.1.1. Không có khả năng của CICAM PIN

CICAM không thực hiện bất kỳ đánh giá của cha mẹ đối với bất kỳ dịch vụ (FTA và CAS). Máy chủ có thể tùy chọn cung cấp một cơ chế để thay thế cha mẹ để đánh giá theo quyết định của bất kỳ thiết lập đánh giá của cha mẹ của người sử dụng. Máy chủ cung cấp một giao diện người sử dụng bản địa để nhập PIN.

...

...

...

CICAM không thực hiện bất kỳ quản lý đánh giá đối với các dịch vụ FTA. CICAM thực hiện quản lý mã PIN CAS và phải sử dụng một bản tin MMI cao cấp hoặc ứng dụng để có được mã PIN từ người sử dụng. Máy chủ có thể tùy chọn làm cha mẹ để đánh giá đối với các dịch vụ FTA theo quyết định của người sử dụng để thiết lập một đánh giá của cha mẹ và các dịch vụ CA nếu các thiết lập đánh giá của cha mẹ trong máy chủ là thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM PIN, trong trường hợp này, máy chủ cung cấp một giao diện người sử dụng bản địa để nhập PIN.

5.11.1.3. Các khả năng của CICAM PIN dành cho các dịch vụ CA và FTA

Máy chủ có thể yêu cầu CICAM hiển thị một màn hình MMI dành cho các dịch vụ FTA và các dịch vụ CA có thiết lập đánh giá của cha mẹ trong máy chủ thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM. Máy chủ không cần cung cấp một giao diện người sử dụng bản địa để nhập PIN và có thể sử dụng CICAM để thực hiện nhập PIN. CICAM phải được kiểm soát hiển thị PIN MMI, PIN MMI chỉ hiển thị khi có yêu cầu một cách rõ ràng của máy chủ đối với các dịch vụ FTA. CICAM xác nhận mã PIN được nhập là đúng với mã CICAM PIN hoặc mã PIN của máy chủ được gửi trong cc_PIN_MMI_req () trước khi trở về trạng thái trong cc_PIN_reply (). CICAM thực hiện việc quản lý CAS PIN và phải sử dụng một bản tin MMI cao cấp hoặc ứng dụng để có được mã PIN từ người sử dụng.

5.11.1.4. Các khả năng của CICAM PIN chỉ dành cho các dịch vụ CA (mã PIN được lưu trữ)

CICAM không thực hiện bất kỳ quản lý đánh giá đối với các dịch vụ FTA. CICAM thực hiện quản lý mã CAS PIN và phải sử dụng MMI cấp cao hoặc ứng dụng để có được mã PIN từ người sử dụng. Máy chủ có thể tùy chọn thực hiện đánh giá của cha mẹ, theo quyết định của người sử dụng thiết lập một đánh giá của cha mẹ dành cho cả các dịch vụ FTA và các dịch vụ CA khi thiết lập đánh giá của cha mẹ trong máy chủ là thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM PIN, trong trường hợp này máy chủ cung cấp một màn hình hiển thị bản địa để nhập PIN.

CICAM có thể cung cấp một khả năng yêu cầu mã PIN dành cho ghi lại và máy chủ phải lưu trữ nó trong trường hợp nó được yêu cầu trong quá trình ghi lại. Yêu cầu mã PIN này không được ngăn chặn nội dung không yêu cầu PIN đang được xem, tức là, đối với nội dung không yêu cầu PIN thì một yêu cầu mã PIN có thể nhanh chóng được hiển thị sau thời gian chờ hoặc bị người sử dụng hủy bỏ.

Máy chủ có thể sử dụng bản tin bắt đầu ghi lại để cung cấp cho CICAM mã CICAM PIN. Trong trường hợp này CICAM không được yêu cầu người sử dụng nhập mã PIN để cho phép việc ghi lại không bị gián đoạn.

5.11.1.5. Các khả năng của CICAM PIN dành cho các dịch vụ CA và FTA (mã PIN được lưu giữ)

Máy chủ có thể yêu cầu CICAM hiển thị một màn hình MMI dành cho các dịch vụ FTA và các dịch vụ CA có thiết lập đánh giá của cha mẹ trong máy chủ thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM. Máy chủ không cần cung cấp một giao diện bản địa để nhập PIN mà sử dụng CICAM MMI. CICAM không được hiển thị PIN MMI một cách bừa bãi trừ khi có yêu cầu một cách rõ ràng của máy chủ đối với các dịch vụ FTA. CICAM xác nhận mã PIN được nhập là chính xác sau khi so sánh với CICAM PIN và/hoặc mã PIN của máy chủ được gửi trong cc_PIN_MMI_req () trước khi trở về trạng thái trong cc_PIN_reply (). CICAM thực hiện việc quản lý CAS PIN và phải sử dụng bản tin MMI cấp cao hoặc ứng dụng để có được mã PIN từ người sử dụng.

...

...

...

Khi chuyển đến chế độ tạm dừng hay chế độ xem và lưu đệm, nếu mã PIN được cache đã được nhập không chính xác (thông qua khởi tạo ghi) thì mã PIN đang xem phải được thay thế bằng PIN đã cache.

5.11.2. Mã CICAM PIN

CICAM có thể cung cấp việc quản lý mã PIN và mức đánh giá độ tuổi để cung cấp việc truy nhập được cha mẹ kiểm soát đối với nội dung. CAS có thể có được yêu cầu đối với một mã PIN trực tiếp từ hệ thống CAS (ví dụ ECM) hoặc bằng các sử dụng thông tin SI trong dòng truyền tải như nhãn DVB parental_rating_descriptor.

Hình 5.22: Biểu đồ trình tự ghi lại tự động

Trong một chế độ ghi lại tự động, việc nhập mã PIN có thể được yêu cầu và cc_PIN_cmd () được sử dụng để truyền mã PIN cho CICAM tại thời điểm người sử dụng đăng ký một sự kiện ghi lại để xác nhận mã PIN là đúng. cc_PIN_cmd () được sử dụng dành cho ghi lại tự động hoặc tạm dừng. CICAM phải xác nhận mã PIN bằng cách sử dụng một cc_PIN_reply (). Mã PIN được gửi trong cc_PIN_cmd () phải không được lưu trữ hoặc sử dụng cho việc ghi không giám sát hoặc chế độ tạm dừng bởi CICAM, thay vào đó CICAM chỉ được sử dụng PIN đã được cung cấp trong Giao thức khởi tạo ghi.

Để bắt đầu ghi lại, một mã PIN có thể được yêu cầu để khởi tạo CICAM giải xáo trộn, trong trường hợp này bản tin SAC bắt đầu ghi lại có thể được sử dụng để truyền mã PIN cho CICAM mà không có tương tác với người sử dụng. CICAM phải cung cấp mã PIN cho CAS nếu PIN được yêu cầu để giải xáo trộn chương trình được ghi lại và xác nhận mã PIN bằng cách sử dụng cc_PIN_event () có chứa đánh giá độ tuổi trưởng thành đối với các người sử dụng trong quá trình phát lại. Nếu đánh giá của cha mẹ dành cho chương trình thay đổi thì không được yêu cầu máy chủ gửi lại PIN và CICAM cung cấp mã PIN này cho CAS và gửi một cc_PIN_event () được cập nhật đến máy chủ.

Để dừng việc ghi lại trong chế độ ghi lại tự động, máy chủ gửi một bản tin dừng ghi lại, CICAM dừng việc giải xáo trộn nội dung nếu mã PIN này được yêu cầu và yêu cầu mã PIN từ người sử dụng trước khi bắt đầu việc giải xáo trộn lại nội dung này.

Trong khi phát lại, Hình 5.22 chỉ ra rằng CICAM nhận được một cc_PIN_playback () APDU khi máy chủ nhận được một "pin_event" trong quá trình ghi lại. Tùy thuộc vào các yêu cầu của nhà điều hành hoặc pháp luật địa phương, CICAM xác định xem việc kiểm soát của cha mẹ nên được thực thi. Trong trường hợp đó mà CICAM quyết định việc kiểm soát của cha mẹ không phải được thực thi thì CICAM trực tiếp gửi cc_PIN_reply APDU (mã PIN chính xác). Máy chủ làm trống đối với AV trong giai đoạn giữa nhận được "pin_event" trong quá trình ghi lại và nhận được cc_PlN_reply () APDU từ CICAM, điều này có thể gây ra nhấp nháy. Có thể tránh hiện tượng nhấp nháy bằng cách lập lịch đối với cc_PIN_playback () APDU sớm một hoặc nhiều giây để cho phép CICAM đủ thời gian gửi cc_PIN_reply () APDU trước khi gặp phải "pin_event" thực trong quá trình ghi lại. Nếu gặp phải "pin_event" trong quá trình ghi lại trước khi máy chủ nhận được cc_PIN_reply () APDU thì máy chủ phải làm trống đối với AV cho đến khi cc_PIN_reply () APDU được nhận với mã PIN chính xác.

...

...

...

Hình 5.23: Biểu đồ trình tự chế độ tạm dừng

Khi phát lại, máy chủ phải gửi cc_PIN_playback () APDU với đánh giá độ tuổi được CICAM cung cấp trên cc_PIN_event () khi việc ghi lại đã được thực hiện đối với CICAM đã gửi cc_PIN_event () này. CAS kiểm tra việc đánh giá và yêu cầu một MMI cấp cao hoặc áp dụng để có được thông tin của PIN này, nếu được yêu cầu, trước khi trả lại một cc_PIN_reply () đến máy chủ. CICAM trả lời máy chủ bằng một cc_PIN_reply () để xác nhận xem máy chủ có thể tiếp tục phát lại nội dung được ghi lại.

Hình 5.23 chỉ ra rằng trong qua trình xem nội dung truyền hình trực tiếp, máy chủ nhận được một cc_PIN_event () APDU sau đó nó làm trống đối với AV. Việc máy chủ chủ động làm trống đối với AV khi trường trạng thái PINcode trong cc_PIN_event () APDU là "0x04" (việc làm trống Video là không bắt buộc) là không cần thiết đối với máy chủ. “PIN_event” vẫn phải được lưu trữ với nội dung được liên kết để có thể thực thi việc kiểm soát của cha mẹ trong quá trình phát lại.

Nếu máy chủ dừng ghi, nó sẽ gửi một bản tin dừng ghi. CICAM phải ngừng sử dụng mã PIN đã được lưu trữ để giải xáo trộn nội dung. Nếu PIN người xem đã nhập trước đó là chính xác thì nó sẽ được sử dụng để người xem có thể xem các nội dung mà không bị gián đoạn. Nếu PIN mà người xem đã nhập trước đó là không chính xác thì CICAM phải thi hành chế độ kiểm soát của cha mẹ thích hợp.

5.11.3. Mã PIN của máy chủ

Mã PIN của máy chủ là mã PIN riêng thường được chỉ có máy chủ và người sử dụng thiết bị đầu cuối quản lý. Tài nguyên kiểm soát nội dung cho phép mã CICAM PIN được máy chủ sử dụng để trình bày nội dung FTA được đánh giá độ tuổi.

Trên một dịch vụ FTA, máy chủ xác định xem đánh giá độ tuổi trưởng thành của dịch vụ này có cao hơn so với đánh giá được người sử dụng thiết lập thì máy chủ gửi cc_PIN_MMI_req () với mã PIN của máy chủ đến CICAM để sử dụng một bản tin MMI cao cấp hay ứng dụng để có được mã PIN từ người sử dụng. CICAM xác nhận mã PIN được nhập này giống mã CICAM PIN hoặc mã PIN được gửi trong cc_PIN_MMI_req () trước khi trả lại cc_PIN_reply (). Hình 5.24 được cung cấp để tham khảo:

Hình 5.24 - PIN dành cho FTA

...

...

...

cc_PIN_event () APDU được CICAM gửi để thông báo cho máy chủ rằng một mã PIN được yêu cầu để giải xáo trộn chương trình được ghi lại và cung cấp đánh giá của cha mẹ để sử dụng trong quá trình phát lại và ngày mà nó đã thay đổi. Nếu đánh giá của cha mẹ đối với chương trình thay đổi thì không bắt buộc máy chủ phải gửi lại PIN mà CICAM cung cấp mã PIN này cho CAS và gửi một cc_PIN_event() được cập nhật.

5.11.5. Chuyển đánh giá của cha mẹ sang CICAM

cc_PIN_playback APDU, xem điều 11.3.2.5, được gửi đến CICAM khi gặp phải một cc_PIN_event () khi bắt đầu phát lại và khi đánh giá của cha mẹ đối với nội dung thay đổi, ví dụ như vượt qua các ranh giới của sự kiện. APDU này được sử dụng để truyền đánh giá của cha mẹ hiện tại đến CICAM để nó có thể quản lý các mã PIN.

Khi cố gắng phát lại và CICAM là không có hoặc không trả lời thì máy chủ phải tiếp tục vô hiệu đầu ra đối với nội dung được cha mẹ kiểm soát cho đến lúc mà CICAM lại có mặt trong máy chủ và có thể xử lý yêu cầu phát lại mã PIN.

5.11.6  Lưu trữ mã PIN

Máy chủ có thể cung cấp khả năng lưu trữ một mã PIN để sử dụng như một bộ phận của bản tin khởi tạo ghi, vì vậy CICAM vẫn có thể tiếp tục giải xáo trộn nội dung khi gặp phải sự kiểm soát đánh giá của cha mẹ. Máy chủ sẽ chỉ sử dụng mã PIN đã lưu này cho quá trình ghi hoặc để xác nhận mã PIN cho một sự kiện trong tương lai.

Máy chủ không được tiết lộ mã PIN đã được lưu trữ cho người dùng dưới mọi hình thức, ví dụ thông qua giao diện người dùng gốc hoặc qua menu.

5.12. Ghi và phát lại

Phần này trình bày các yêu cầu về lưu trữ ghi lại và phát lại sau đó của một máy chủ ghi lại nội dung được Cl Plus bảo vệ bằng cách sử dụng tài nguyên kiểm soát nội dung. Luôn luôn yêu cầu máy chủ giữ nguyên các thông số thiết lập của URI, các thông báo kiểm soát của cha mẹ (PIN) và giấy phép nội dung.

...

...

...

Máy chủ không tổng hợp các giấy phép hoặc các mã PIN. Việc bảo vệ quyền kiểm soát nội dung của các giấy phép, các URI và các mã PIN phải được áp dụng từ vị trí trong dòng truyền tải đã được việc bảo vệ này áp dụng trong quá trình ghi lại đến vị trí được bảo vệ tiếp theo trong quá trình ghi lại hoặc phần cuối của dòng truyền tải. Phạm vi của mỗi thành phần bảo vệ nội dung được quy định như sau:

• URI mở rộng từ vị trí được thông báo đến vị trí được URI thông báo tiếp theo, hoặc phần cuối của ghi lại, theo hướng tiến.

• Giấy phép mở rộng từ vị trí được thông báo đến vị trí được giấy phép hoặc URI tiếp theo thông báo, hoặc phần cuối của ghi lại, theo hướng tiến.

• PIN mở rộng từ vị trí được thông báo đến vị trí được mã PIN tiếp theo thông báo, hoặc phần cuối của ghi lại, theo hướng tiến.

• Bất kỳ chuyển đổi được trình bày ở trên có thể xảy ra bất cứ lúc nào trong quá trình ghi lại như trong hình 5.25 đã mô tả quá trình ghi lại theo thời gian mà không phải là theo sự kiện.

• Trong hình 5.25, nội dung được bảo vệ như sau, trong đó URI # n là một thay đổi trong URI, License # n là giấy phép nội dung và mã PIN # n là một sự kiện kiểm soát của cha mẹ nơi đánh giá của cha mẹ đã thay đổi và không hiển thị các mã PIN khác nhau. Theo mục đích của ví dụ này thì chúng ta giả thiết rằng việc ghi lại này bao gồm ba sự kiện, chúng ta thường sẽ kiểm tra mỗi sự kiện riêng được ghi lại.

• Sự kiện # 1: là nội dung được giấy phép bảo vệ bằng giấy phép # 1 và URI # 1 có điều khiển của cha mẹ PIN # 1 với thời gian chờ một phút để chuyển sang ghi lại.

• Sự kiện # 2: là nội dung không được giấy phép bảo vệ và có URI # 2, có kiểm soát của cha mẹ PIN # 2 đang có hiệu lực.

• Sự kiện # 3: là nội dung được giấy phép bảo vệ bằng giấy phép # 2 và URI # 3 và có kiểm soát của cha mẹ PIN # 2 đang có hiệu lực.

...

...

...

Hình 5.25 - Ví dụ về trình tự ghi lại

5.12.1. Phiên phát lại

Khi phát lại nội dung được ghi lại, máy chủ phải bao gồm một phiên. Khi xem một nội dung được ghi lại thì phiên này phải được mở, phiên này không được đóng cho đến khi việc phát lại dừng, việc tạm dừng không làm đóng phiên. Một phiên có thể được đóng tự động khi giới hạn thời gian lưu giữ nội dung chấm dứt, lúc này nội dung được giới hạn thời gian lưu giữ bảo vệ bị loại bỏ.

Các giấy phép được sử dụng, thường được gặp phải, trong quá trình phát lại. Việc sử dụng của một giấy phép yêu cầu một trao đổi giấy phép với CICAM và giấy phép và URI liên kết với ghi lại được trao đổi với một giấy phép và URI mới được liên kết với ghi bằng cách thay thế mỗi giá trị được lưu trữ hiện tại. Giấy phép chỉ được sử dụng trong trường hợp phát lại, không phụ thuộc vào việc di chuyển hướng của người sử dụng giữa các giấy phép khác nhau đã được sử dụng trong phiên hiện tại.

Chuyển đổi đánh giá của cha mẹ (PIN) trong quá trình ghi lại yêu cầu máy chủ loại bỏ tất cả các thành phần có thể hiển thị của nội dung được ghi lại (video thì trống, âm thanh thì câm, vô hiệu hóa phụ đề, v.v..) cho đến khi thu được một mã PIN hợp lệ từ CICAM, thông qua người sử dụng, khi nội dung này có thể được khôi phục. Phải thực hiện trao đổi PIN với CICAM khi gặp phải bất kỳ sự kiện PIN trong ghi lại ở cả hai hướng tiến hoặc lùi khi nội dung này được hiển thị. CICAM (nhà điều hành dịch vụ) có thể làm giảm sự tương tác của người sử dụng trong trường hợp phát lại khi mã PIN hợp lệ đã được nhập và mọi yêu cầu mã PIN từ máy chủ không cần sự tương tác của người sử dụng miễn là đánh giá của cha mẹ bằng việc nhập mã PIN đầu tiên là đủ, hoạt động chính xác của CICAM được nhà điều hành dịch vụ và các quy định quốc gia quy định.

Di chuyển theo hướng tiến và lùi trong quá trình ghi lại yêu cầu máy chủ giữ nguyên tất cả thông số giới hạn của giấy phép, URI và PIN tại mỗi điểm chuyển đổi trong quá trình ghi lại. Khi di chuyển theo lùi thì yêu cầu máy chủ sử dụng lại các thông số giới hạn khi gặp phải một sự kiện giới hạn trong quá trình ghi lại, điều này yêu cầu máy chủ để tìm ra loại chuyển đổi trước đó và áp dụng phù hợp thông số giới hạn này.

URI được trả về từ một trao đổi giấy phép của CICAM có thể làm thay đổi giấy phép và URI được ghi lại hiện tại và phải được liên kết với nội dung này ở cùng một vị trí như ban đầu, làm thay thế giấy phép và URI hiện tại. URI mới phải được sử dụng ngay lập tức đối với việc phát lại. URI mới có thể làm thay đổi giới hạn thời gian lưu giữ đã được áp dụng một cách tương tự trong quá trình ghi lại, xem xét độ dài của nội dung này khi xem với một thời gian phát lại bình thường. Ví dụ như xem xét một chương trình 2 giờ (120 phút) có thay đổi giới hạn lưu giữ từ 30 ngày sang 90 phút. Ở ngay thời điểm mà URI được thay đổi thì các byte đầu tiên của nội dung được ghi lại này tại chuyển đổi URI có giới hạn thời gian lưu trữ mới là 90 phút, byte cuối cùng của sự kiện được ghi lại 120 phút có giới hạn thời gian lưu trữ là 120 + 90 hoặc 210 phút. Một URI tồn tại mà không có một giấy phép không được trình bày lại cho CICAM khi phát lại và không được thay thế trong quá trình ghi lại.

Trường hợp ghi lại có nhiều URI với các giá trị giới hạn lưu giữ khác nhau thì yêu cầu máy chủ quản lý các giới hạn lưu giữ của từng vùng URI theo Thỏa thuận giấy phép Cl Plus [6]. Máy chủ có thể xử lý mỗi giới hạn lưu giữ của vùng URI hoặc áp dụng giới hạn lưu trữ hạn chế nhất đối với toàn bộ nội dung. Trong mỗi trường hợp, máy chủ không được vượt quá giới hạn lưu giữ đã thông báo đối với bất kỳ vùng URI. Phương pháp chính xác mà máy chủ quản lý các thời gian lưu khác nhau trong một nội dung ghi lại là cụ thể nhưng trong mọi trường hợp phải được quản lý theo Thỏa thuận giấy phép Cl Plus [6].

...

...

...

5.13. Cung cấp SRM

CICAM có thể nhận các tập tin dữ liệu SRM, theo quy định tại [34]. Các tập tin dữ liệu SRM thực hiện chức năng danh sách đen đối với HDCP [34]. Các tập tin dữ liệu SRM này được áp dụng cho chức năng HDCP của máy chủ, tùy thuộc vào máy chủ triển khai một đầu ra HDCP trong chế độ nguồn hoặc lặp lại.

Việc thực hiện chức năng HDCP trong máy chủ Cl Plus phải phù hợp với Đặc tả về giấy phép Cl Plus [33]. Máy chủ Cl Plus yêu cầu các tập tin SRM phải chấp nhận những tập tin này nếu CICAM khởi tạo việc truyền các tập tin SRM đó.

5.13.1. Giao thức truyền tập tin dữ liệu

Phần này mô tả một giao thức bắt buộc để truyền các tập tin dữ liệu SRM từ CICAM đến máy chủ. Trách nhiệm của Cl Plus là truyền các tập tin dữ liệu SRM một cách an toàn. Việc áp dụng chính xác các tập tin SRM là một phần của chức năng HDCP và nằm ngoài phạm vi của tiêu chuẩn này.

5.13.1.1. Tổng quan bản tin và khởi tạo

Quá trình này được trình bày trong hình 5.26:

Hình 5.26 - Cung cấp các tập tin dữ liệu SRM

...

...

...

TT

Mô tả

Tham chiếu đến

1

Gán SRM đúng (nằm ngoài phạm vi tiêu chuẩn này).

SRM đúng được gán cho tổ hợp máy chủ CICAM. Quá trình chính xác này nằm ngoài phạm vi tiêu chuẩn này.

2

Cung cấp SRM (nằm ngoài phạm vi tiêu chuẩn này).

...

...

...

3

CICAM tạo bản tin.

CICAM tính datafile_confirm để xác thực xác nhận của máy chủ đã nhận được (CHÚ THÍCH 3):

datafile_confirm □□□SHA₂₅₆ (datafile ǁ UCK)

trong đó:

• datafile là tập tin SRM,

• UCK = SHA₂₅₆ (SAK).

Giá trị datafile_confirm được lưu trữ nội bộ để so sánh trong bước 8.

...

...

...

• tập tin dữ liệu SRM (datatype_id = srm_data).

điều 11.3.5

4

CICAM khởi tạo thời gian chờ 10 giây.

CICAM khởi tạo thời gian chờ 10 giây để thủ tục truyền dữ liệu SRM phải hoàn thành. (CHÚ THÍCH 1)

5

CICAM truyền bản tin SAC với tải tập tin dữ liệu SRM.

CICAM truyền bản tin SAC với tải từ bước 3 và truyền bản tin này đến máy chủ. (CHÚ THÍCH 2).

...

...

...

6

Máy chủ kiểm tra bản tin

Sau khi máy chủ kiểm tra bản tin là đúng thì máy chủ tách lấy tập tin dữ liệu SRM. Máy chủ có thể truyền tập tin dữ liệu SRM đến một chức năng sử dụng nào đó nằm ngoài phạm vi tiêu chuẩn này (trong trường hợp HDCP).

điều 7.4

7

Máy chủ truyền bản tin SAC với xác nhận của tập tin dữ liệu SRM.

Máy chủ tính datafile_confirm theo cách giống như CICAM đã tính trong bước 3.

Máy chủ xác nhận việc cung cấp tập tin dữ liệu SRM bằng cc_sac_data_cnf APDU, bao gồm

• datafile_confirm (datatype_id = datatransfer_confirm)

...

...

...

và sử dụng SAC để truyền bản tin này đến CICAM. (CHÚ THÍCH 2)

Trả lời không thành công dẫn đến việc truyền tập tin dữ liệu này không thành công (CHÚ THÍCH 1).

điều 7.3, 11.3.1 and 11.3.5

8

Kiểm tra xác nhận của máy chủ.

CICAM so sánh datafile_confirm nhận được từ máy chủ với giá trị được tính trong bước 3 ở trên.

Việc không tương đương dẫn đến việc truyền tập tin dữ liệu này không thành công và có thể được CICAM theo dõi. (CHÚ THÍCH 1)

9

...

...

...

Việc áp dụng tập tin dữ liệu SRM nằm ngoài phạm vi tiêu chuẩn này.

CHÚ THÍCH:

1. Nếu các bước trên không được hoàn thành trước khi hết thời gian chờ 10 giây thì CICAM phải xem là việc truyền tập tin dữ liệu này không thành công. Các hành vi tiếp theo của CICAM nằm ngoài phạm vi tiêu chuẩn này.

2. Tham chiếu điều 7.2 để biết cách dữ liệu SRM được đóng gói vào bản tin SAC.

3. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

5.13.2. Các điều kiện truyền dữ liệu

CICAM sẽ bắt đầu khởi tạo việc truyền tập tin dữ liệu lần đầu tiên khi nó phát hiện một tập tin dữ liệu SRM. Trong trường hợp máy chủ không yêu cầu tập tin này, nó có thể thông báo điều này trong bản tin xác nhận và CICAM phải tránh gửi các tập tin dữ liệu SRM sau đó. Trong mọi trường hợp máy chủ phải trả lời bằng một xác nhận để xóa bản tin. Khi máy chủ thông báo rằng nó đã nhận được tập tin dữ liệu SRM này thì CICAM phải tránh gửi các tập tin giống nhau nhiều lần.

Hình 5.27 trình bày hoạt động truyền tập tin dữ liệu của CICAM.

...

...

...

CHÚ THÍCH: thời gian chờ được quy định là 10 giây.

Hình 5.27 - Tổng quan các điều kiện cung cấp tập tin dữ liệu phía CICAM

6. Cơ chế xác thực

6.1. Đăng ký và liên kết CICAM

Việc đăng ký và liên kết CICAM được thực hiện theo ba bước:

• Kiểm tra giấy chứng nhận & trao đổi mã khóa DH.

• Kiểm tra mã khóa xác thực.

• Tùy chọn thông báo trả về nhà điều hành dịch vụ (chỉ đối với chế độ đăng ký dịch vụ).

Các bước này được mô tả trong các phần sau.

...

...

...

Máy chủ và CICAM bắt đầu giao thức xác thực bằng cách trao đổi chuỗi chứng nhận của máy chủ, chuỗi chứng nhận của CICAM, dữ liệu được đóng dấu và mã khóa công khai Diffie-Hellman. Trước khi việc xác thực hoàn thành, CICAM chỉ có quyền đối với các chương trình có dữ liệu EMI được thiết lập giá trị là 00 (cho phép sao chép).

CICAM kiểm tra các đóng dấu được chứa trong chuỗi chứng nhận của máy chủ và đóng dấu trên mã khóa công khai Diffie- Hellman. Đây là một giao thức xác thực lẫn nhau và máy chủ phải kiểm tra đóng dấu được chứa trong chuỗi chứng nhận của CICAM cùng với đóng dấu trên mã khóa công khai Diffie- Hellman. DHPH được máy chủ bảo vệ bằng một đóng dấu có liên quan đến HDQ của máy chủ. Phía CICAM kiểm tra DHPH đã nhận với HDP của máy chủ mà nó có được từ giấy chứng nhận thiết bị máy chủ. DHPM được bảo vệ theo một cách tương tự bằng cách sử dụng MDQ để đóng dấu và MDP để kiểm tra.

Nếu chuỗi chứng nhận của máy chủ kiểm tra cùng với đóng dấu trên mã khóa công khai Diffie-Hellman, HOST_ID thu được từ giấy chứng nhận thiết bị máy chủ. Tương tự, nếu chuỗi chứng nhận của CICAM kiểm tra cùng với đóng dấu trên mã khóa công khai Diffie-Hellman, CICAM_ID thu được từ giấy chứng nhận thiết bị CICAM.

Nếu việc kiểm tra giấy chứng nhận hoặc đóng dấu không thành công thì CICAM không được loại bỏ mạng CA (tức là không được giải mã mạng CA từ TS đến) ngay cả khi thuê bao được quyền để nhận dịch vụ này. CICAM hiển thị một bản tin lỗi bằng cách sử dụng tài nguyên MMI trên máy chủ, xem điều 5.4.3 để biết chi tiết về các bản tin lỗi và EN 50221 [7], điều 8.6 về giải thích tài nguyên MMI. Nếu máy chủ tạm thời không thể trả lời yêu cầu từ một tương tác MMI thì CICAM thử lại cho đến khi máy chủ rỗi.

6.1.2. Kiểm tra mã khóa xác thực

CICAM và máy chủ lấy được mã khóa xác thực dài hạn từ việc trao đổi dữ liệu giữa CICAM và máy chủ trong giai đoạn đầu tiên của quá trình xác thực. Mã khóa xác thực được tính từ mã khóa riêng DH cùng với dữ liệu duy nhất từ liên kết cụ thể này, HOST_ID và CICAM_ID (xem điều 6.2.3.4 để biết chi tiết).

CICAM gửi một bản tin yêu cầu đến máy chủ để yêu cầu mã khóa xác thực được lấy từ máy chủ. Máy chủ trả lời bằng một bản tin xác nhận chứa mã khóa xác thực được yêu cầu. Sau khi nhận, CICAM so sánh mã khóa xác thực nhận được với một mã khóa mà nó đã lưu trữ trước đó. Nếu so sánh của CICAM thành công, máy chủ đã chứng minh được rằng nó có mã khóa xác thực tương tự và CICAM chấp nhận rằng máy chủ là hợp pháp để cho phép truyền. Cả hai bên đều lưu trữ mã khóa xác thực này trong bộ nhớ ổn định để nó có sẵn để tính toán mã khóa dành cho SAC và CC. Tham khảo điều 7 (SAC) và điều 8 (Mã khóa kiểm soát nội dung) để biết chi tiết.

Nếu một mã khóa xác thực phù hợp không nhận được trong vòng 5 giây tính từ bản tin yêu cầu thì CICAM không được loại bỏ mạng CA (tức là không được giải mã TS đến), ngay cả khi thuê bao được quyền để nhận dịch vụ này.

6.1.3. Báo cáo trả về nhà điều hành dịch vụ

...

...

...

Khi ở chế độ đăng ký dịch vụ, CICAM yêu cầu thiết bị đầu cuối xác nhận CICAM_ID và HOST_ID. Quá trình xác nhận CC của CICAM yêu cầu hệ thống CA kiểm tra xem HOST_ID hoặc CICAM_ID có được liệt kê trong các SOCRL. Cơ chế chính xác này được mô tả trong điều 5.5.

6.1.4. Hoạt động hệ thống CC

Hình 6.1 trình bày cách xác thực 3 bước được tích hợp thành hoạt động CC chung. Nội dung này có tính tham khảo và những cách khác là có thể. Quá trình xác thực 3 bước này là bắt buộc.

Hệ thống kiểm soát nội dung của CICAM (CC) được trình bày trong hình 6.1 bao gồm các bước cơ bản sau đây:

1) Tài nguyên CC phải được máy chủ cung cấp và các mô-đun cung cấp một tài nguyên CC phải bị quản lý tài nguyên của máy chủ bỏ qua. Máy chủ phải hỗ trợ một phiên dành cho tài nguyên CC đối với mỗi khe Cl. Trong quá trình kiểm tra hồ sơ (xem Hình 6.1 và Hình 6.2), máy chủ phải thông báo rằng một tài nguyên kiểm soát nội dung có sẵn. Nếu tài nguyên không được thông báo thì điều này gây ra lỗi của hệ thống kiểm soát nội dung và hệ thống phải tiếp tục với bước (13).

2) Một phiên dành cho tài nguyên kiểm soát nội dung được CICAM mở, điều 11.3. Nếu một phiên hợp lệ không được mở thành công thì hệ thống kiểm soát nội dung phải được xem là thất bại. CICAM phải gửi APDU cc_open_req đến máy chủ. Máy chủ phải trả lời bằng một cc_open_cnf APDU trong vòng 5 giây (xem điều 6.2.1).

Nếu không trả lời yêu cầu này trong vòng 5 giây thì gây ra một lỗi và hệ thống phải tiếp tục ở bước (25).

cc_system_id_bitmaskin trong trả lời của phải bao gồm CC phiên bản 1, xem điều 11.3.1.2. Nếu cc_system_id_bitmaskdoes không được bao gồm CC phiên bản 1 hệ thống phải tiếp tục với bước (24).

3) CICAM kiểm tra xem có một mã khoá xác thực được lưu trữ trong bộ nhớ ổn định. Nếu CICAM chứa một mã khóa xác thực hợp lệ (AKM) thì nó phải yêu cầu máy chủ để gửi mã khóa xác thực của nó (AKH). Nếu CICAM không có AKM hợp lệ thì CICAM và máy chủ phải tiếp tục với bước (6).

...

...

...

5) CICAM phải so sánh AKM được lưu trữ của nó với AKH nhận được. Nếu mã khóa xác thực này phù hợp thì việc xác thực trước đó đã được hoàn thành thành công và các giấy chứng nhận được xem là hợp lệ. Mã khóa mật DH (DHSK) và các mã khóa xác thực (AKM/AKH) được tính trên cả hai phía sau đó được lưu giữ, mã khóa dành cho SAC (SAK và SEK) và mã khóa kiểm soát nội dung (CCK) được tạo (tạo lại) một cách độc lập và được đồng bộ cả hai phía. Sau đó hệ thống phải tiếp tục với bước (15). Nếu các mã khóa xác thực không phù hợp thì hệ thống được yêu cầu xác thực và phải tiếp tục với bước (8). Lưu ý rằng máy chủ có nhiều mô-đun và nhiều khe được quy định tại điều 6.3.

6) CICAM kích hoạt khởi tạo giao thức DH và trao đổi giấy chứng nhận, giao thức xác thực dựa trên DH chính xác được mô tả trong hình 6.2 bước (1).

Hình 6.1 - Tổng quan CICAM và máy chủ trong hoạt động CC

7) Nếu giao thức DH được hoàn thành thành công, hệ thống này phải tiếp tục với bước (8). Bất cứ lỗi trong việc hoàn thành của giao thức DH gây ra lỗi của hệ thống kiểm soát nội dung và hệ thống phải tiếp tục với bước (11).

8) CICAM phải yêu cầu máy chủ xác nhận mã khóa xác thực của nó (AKH) trong vòng 5 giây.

9) CICAM phải so sánh mã khóa xác thực AKM của nó với AKH nhận được. Nếu chúng không bằng nhau, điều này gây ra một lỗi của hệ thống kiểm soát nội dung (xem điều 6.1.1) và hệ thống phải tiếp tục với bước (20). Nếu chúng bằng nhau thì CICAM và máy chủ kết thúc hoạt động Diffie- Hellman hoàn thành thành công và phải lưu trữ các mã khóa xác thực này (DHSK và AKM/AKH) vào bộ nhớ ổn định.

10) Hệ thống này hoạt động hoàn toàn để xử lý nội dung được mã hóa CA và rõ ràng miễn là người sử dụng có các quyền cần thiết và sau khi tính toán thành công SAC (xem điều 7) và các mã khóa CC (xem điều 8), máy chủ sẽ có thể hiển thị nội dung.

11) CICAM phải thiết lập trạng thái xác nhận là không thành công.

...

...

...

6.2. Giao thức xác thực

Điều 6.2.1 trình bày các bản tin của giao thức xác thực được trao đổi qua các giao diện bên ngoài. Điều 6.2.2 trình bày các điều kiện xác thực. Điều 6.2.3 trình bày các tính toán mã khóa và kiểm tra địa phương của giao thức xác thực.

CICAM không nên cố xác thực cho đến thời điểm mà cả CICAM và máy chủ đảm bảo rằng các giấy chứng nhận có thể được xác nhận. Ví dụ điều này có thể được thực hiện bằng cách sử dụng tài nguyên ngày và thời gian, xem EN 50221 [7], điều 8.5.2.

6.2.1. Tổng quan bản tin và khởi tạo

Xác thực được thực hiện theo ba bước:

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/ khối hóa. Lưu đồ này cũng cho rằng CICAM không lưu giữ một AKM hợp lệ.

Hình 6.2 - Biểu đồ trình tự trao đổi xác thực

Quá trình này được xác định trong Bảng 6.1:

...

...

...

TT

Mô tả

Tham chiếu đến

1

CICAM phải mở một phiên dành cho tài nguyên kiểm soát nội dung

điều 11.3

2

Máy chủ phải xác nhận bằng một trả lời. Việc mở một phiên hợp lệ không thành công dẫn đến hệ thống kiểm soát nội dung không thành công

điều 11.3

...

...

...

CICAM phải gửi cc_open_req APDU đến máy chủ.

điều 11.3.1.1

4

Máy chủ phải xác nhận bằng cc_open_cnf APDU, bao gồm:

• cc_system_id_bitmask

điều 11.3.1.2

5

CICAM phải gửi cc_data_req APDU đến máy chủ, bao gồm:

• nonce (tức là auth_nonce).

...

...

...

điều 11.3.3.2

6

Máy chủ phải xác nhận bằng cc_data_cnf APDU, bao gồm:

• Mã khóa công khai DH của máy chủ (DHPH, tham chiếu điều 6.2.3.2),

• Đóng dấu A (tham chiếu đến điều 6.2.3),

• Giấy chứng nhận thương hiệu của máy chủ (Host_BrandCert, tham chiếu đến điều 9.2),

• Giấy chứng nhận thiết bị của máy chủ (Host_DevCert, tham chiếu đến điều 9.2).

Việc trả lời không thành công bằng cc_data_cnf dẫn đến hệ thống kiểm soát nội dung không thành công; Điều này có thể xảy ra khi máy chủ không kiểm tra dữ liệu nhận được của CICAM (CHÚ THÍCH 2).

điều 11.3.3.2

...

...

...

CICAM phải theo dõi bằng cc_data_req APDU, bao gồm:

• Mã khóa công khai DH của CICAM (DHPM, tham chiếu đến điều 6.2.3.2),

• Đóng dấu B (tham chiếu đến điều 6.2.3),

• Giấy chứng nhận thương hiệu của CICAM (CICAM_BrandCert, tham chiếu đến điều 9.2),

• Giấy chứng nhận thiết bị của CICAM (CICAM_DevCert, tham chiếu đến điều 9.2).

• Các yêu cầu đối với các datatype ID được máy chủ cung cấp được liệt kê trong điều tham chiếu đến trong cột bên.

Việc trả lời không thành công bằng cc_data_req dẫn đến hệ thống kiểm soát nội dung không thành công; Điều này có thể xảy ra khi CICAM không kiểm tra dữ liệu nhận được của máy chủ (CHÚ THÍCH 2).

điều 11.3.3.2

8

...

...

...

• Trạng thái của máy chủ.

Việc trả lời không thành công bằng cc_data_cnf dẫn đến hệ thống kiểm soát nội dung không thành công; Điều này có thể xảy ra khi máy chủ không kiểm tra dữ liệu nhận được của CICAM (CHÚ THÍCH 2).

điều 11.3.3.2

9

CICAM phải gửi cc_data_req APDU đến máy chủ để yêu cầu mã khóa xác thực của máy chủ (AKH, tham chiếu đến điều 6.2.3.4), bao gồm:

• Yêu cầu đối với datatype ID của AKH (được quy định trong điều H.1).

điều 11.3.3.3

10

Máy chủ phải xác nhận bằng cc_data_cnf APDU, bao gồm:

...

...

...

Trả lời không thành công trong thời gian 5 giây bằng cc_data_cnf dẫn đến hệ thống kiểm soát nội dung không thành công (CHÚ THÍCH 2).

điều 11.3.3.3

11

CICAM phải so sánh AKH này với AKM mới được tính. Nếu chúng không giống nhau thì dẫn đến hệ thống kiểm soát nội dung không thành công (CHÚ THÍCH 2).

12

Trong chế độ đăng ký dịch vụ, CICAM có thể khởi tạo một tương tác đăng ký.

điều 5.5

14

...

...

...

16

Nhà điều hành dịch vụ có thể kiểm tra xem các ID của thiết bị không bị SOCRL thu hồi. Nhà điều hành dịch vụ có thể áp dụng các phương pháp khác để xác định xem các ID của thiết bị được báo cáo có tin cậy ví dụ kiểm tra xác thực v.v... Cơ chế chính xác được sử dụng này nằm ngoài phạm vi tiêu chuẩn này, nhưng nếu sử dụng SOCRL thì nó phải tuân thủ điều 5.5.

17

Dựa vào quyết định của nhà điều hành dịch vụ, tổ hợp CICAM/máy chủ có thể được sử dụng hoặc bị thu hồi bằng một cách bất kỳ nào ví dụ một bản tin riêng được hệ thống CA mạng bảo vệ.

CHÚ THÍCH

1. Tham chiếu phụ lục H để biết tổng quan các thông số liên quan.

...

...

...

6.2.2. Các điều kiện xác thực

Các giới hạn sau đây được định nghĩa trong phần này:

Bảng 6.2 - Trao đổi xác thực

Giới hạn

Mô tả

Quy định

Nonce retry

Số lần lớn nhất CICAM cố thử tạo một nonce (mã dùng 1 lần) hợp lệ

3

...

...

...

Lưu ý: Tham khảo Bảng 6.3 để biết chi tiết về các tính toán và Bảng 6.1 để biết chi tiết về việc trao đổi bản tin.

1) Tài nguyên CC và phiên phải được mở trước khi CICAM bắt đầu thủ tục xác thực này.

2) CICAM khởi tạo một giao thức nonce "auth_nonce".

3) auth_nonce phải có một độ dài hợp lệ được liệt kê trong Phụ lục H, Bảng H.1. Nếu đây không phải là trường hợp mà CICAM cố thử cho đến khi nó đạt đến giá trị Nonce retry giới hạn (xem Bảng 6.2). Nếu đạt giới hạn cố thử thì việc xác thực thất bại và CICAM tiếp tục với bước 23.

4) CICAM gửi auth_nonce đến máy chủ và yêu cầu dữ liệu trả về trong bản tin xác nhận.

5) CICAM chờ đợi cho đến khi nó nhận được xác nhận từ máy chủ chứa các thông số được yêu cầu.

6) CICAM kiểm tra xem các giấy chứng nhận nhận được từ máy chủ có hợp lệ bằng cách kiểm tra SSAC. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

7) CICAM kiểm tra xem đóng dấu A nhận được từ máy chủ có hợp lệ bằng cách kiểm tra SSAC. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

8) CICAM kiểm tra xem mã khóa DHPH nhận được từ máy chủ có hợp lệ bằng cách kiểm tra độ dài theo Phụ lục H, Bảng H.1 và giá trị theo kiểm tra kiểm soát trong điều 6.2.3.2. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

...

...

...

10) CICAM tính một mã khóa công khai DH DHPM.

11) CICAM kiểm tra xem mã khóa DHPM được tính toán có hợp lệ bằng cách kiểm tra độ dài theo Phụ lục H, Bảng H.1 và giá trị theo kiểm tra kiểm soát trong điều 6.2.3.2. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

12) CICAM tạo ra một đóng dấu duy nhất B đối với dữ liệu được trao đổi với máy chủ.

13) CICAM gửi dữ liệu giao thức đến máy chủ với yêu cầu nhận được trạng thái của máy chủ.

14) CICAM chờ đợi cho đến khi nhận được xác nhận từ máy chủ với trạng thái của nó.

15) CICAM kiểm tra xem trạng thái của máy chủ là OK. Nếu không OK, việc xác thực thất bại và CICAM tiếp tục với bước 25.

16) CICAM tính các mã khóa DHSK và AKM.

17) CICAM kiểm tra xem DHSK và AKM có hợp lệ theo điều 6.2.3.3 và 6.2.3.4. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

18) CICAM yêu cầu mã khóa AKH của máy chủ.

...

...

...

20) CICAM kiểm tra xem trả lời này có chứa một mã khóa AKH hợp lệ. Nếu mã khóa có tất cả các số là không thì AKH được xem là không hợp lệ và việc xác thực không thành công, CICAM tiếp tục với bước 23.

21) CICAM kiểm tra AKH đã nhận được từ máy chủ có phù hợp với AKM của CICAM. Nếu không phù hợp, việc xác thực thất bại và CICAM tiếp tục với bước 23.

22) CICAM hoàn thành việc xác thực thành công.

23) CICAM có thể khởi tạo một xác thực thất bại tương tác MMI.

24) Xác thực thất bại.

CHÚ THÍCH: Giới hạn số lần cố thử được quy định trong bảng 6.2

Hình 6.3: Tổng quan các điều kiện xác thực phía CICAM.

...

...

...

Các điều kiện xác thực của máy chủ được thể hiện trong hình 6.4 được mô tả dưới đây:

Lưu ý: Tham khảo Bảng 6.2 để biết chi tiết về các tính toán và Hình 6.2 để biết chi tiết về việc trao đổi bản tin.

1) Phiên và tài nguyên CC được mở thành công.

2) Máy chủ nhận được nonce từ CICAM.

3) Máy chủ kiểm tra xem nonce nhận được có hợp lệ như được liệt kê trong Phụ lục H, Bảng H.1. Nonce này được sử dụng trong suốt giao thức xác thực.

4) Máy chủ tạo ra một nonce ngẫu nhiên DHX để sử dụng trong các tính toán DH.

5) Máy chủ tính một mã khóa công khai DH DHPH.

6) Máy chủ kiểm tra xem mã khóa DHPH được tính có hợp lệ bằng cách kiểm tra độ theo Phụ lục H, Bảng H.1 và giá trị theo kiểm tra kiểm soát trong điều 6.2.3.2.

7) Máy chủ tạo một đóng dấu A duy nhất đối với dữ liệu được trao đổi với CICAM.

...

...

...

9) Máy chủ chờ đợi trả lời từ CICAM chứa các thông số được yêu cầu để hoàn thành việc xác thực.

10) Máy chủ thiết lập trạng thái của máy chủ là lỗi.

11) Máy chủ kiểm tra giấy chứng nhận nhận được từ CICAM xem có hợp lệ bằng cách kiểm tra SSAC.

12) Máy chủ kiểm tra xem đóng dấu B nhận được từ CICAM có hợp lệ bằng cách kiểm tra SSAC.

13) Máy chủ kiểm tra xem mã khóa DHPM nhận được từ CICAM có hợp lệ bằng cách kiểm tra độ dài theo Bảng H.1 và giá trị theo kiểm tra kiểm soát trong điều 6.2.3.2.

14) Máy chủ gửi một xác nhận với trạng thái địa phương.

15) Máy chủ thiết lập trạng thái máy chủ là ok.

16) Máy chủ gửi xác nhận trạng thái địa phương.

17) Máy chủ tính các mã khóa DHSK và AKH.

...

...

...

19) Các mã khóa hợp lệ phải có nghĩa là việc xác thực máy chủ là thành công nhưng chưa hoàn thành.

20) Các mã khóa không hợp lệ hoặc có bất kỳ lỗi nào khác trong giao thức xác thực phải có nghĩa là việc xác thực đã thất bại.

21) Máy chủ nhận được yêu cầu từ CICAM thông báo mã khóa AKH của máy chủ.

22) Máy chủ phải xác nhận với giá trị của AKH. Một mã khóa AKH không hợp lệ có tất cả các số là không. Lưu ý rằng CICAM có thể cố thử, lặp lại bước 21 cho đến bước 22.

23) Việc xác thực hoàn thành.

6.2.3. Các tính toán mã khóa xác thực

Nếu một mã khóa xác thực không phù hợp (xem điều 6.1.2) hệ thống thực hiện một phiên xác thực được mô tả trong hình 6.5.

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/ khối hóa.

...

...

...

Quá trình này được quy định trong Bảng 6.3:

Bảng 6.3 - Tính toán mã khóa xác thực

TT

Mô tả

Tham chiếu đến

0

Khi bắt đầu máy chủ thực hiện kiểm tra xem các thông số DH có hợp lệ.

điều 6.2.3.1

1

...

...

...

Phụ lục A

2

CICAM phải gửi auth_nonce đến máy chủ bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.2.2

3

Máy chủ phải kiểm tra xem thông số auth_nonce nhận được có kích thước đúng không (256 bit).

Phụ lục A

4

Máy chủ phải tạo một giá trị ngẫu nhiên dành cho số mũ x DH. Giá trị x (DHX) phải được một PRNG phù hợp tạo ra.

...

...

...

5

Máy chủ phải tính mã khóa công khai DH của máy chủ (DHPH).

điều 6.2.3.2

6

Máy chủ phải tạo đóng dấu A trên auth_nonce and DHPH này, sao cho:

message_A = (version ǁ msg_label ǁ auth_nonce ǁ DHPH)

signature_A = RSASSA-PSS-SIGN(HDQ, message _ A)

trong đó:

• RSASSA-PSS phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2.

...

...

...

• version = 0x01 và msg_label = 0x2.

• Auth_nonce giống giá trị nhận được trong bước 3.

Phụ lục I

7

Máy chủ phải gửi đóng dấu A và mã khóa DHPH, cùng với giấy chứng nhận thương hiệu của máy chủ và giấy chứng nhận thiết bị của máy chủ đến CICAM.

điều 11.3.3.2

8

CICAM phải kiểm tra các thông số nhận được sau:

a) CICAM phải kiểm tra đóng dấu trên các giấy chứng nhận.

...

...

...

message_ A = (version ǁ msg_ label ǁ auth_ nonce ǁ DHPH)

RSASSA- PSS - VERIFY(HDP, message_ A, signature_ A) = TRUE

trong đó:

• RSASSA-PSS phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2.

• HDP là mã khóa riêng của thiết bị nhận được trong bước 7.

• version = 0x01 và msg_label = 0x2.

• Auth_nonce giống giá trị được tạo ra trong bước 1.

• DHPH giống giá trị nhận được trong bước 7.

• TRUE có nghĩa là ‘đóng dấu hợp lệ’

...

...

...

1 <DHPH <DH_p and DHPH^DH-q mod DH_p = 1

điều 9.4

9

CICAM phải tạo ra một giá trị ngẫu nhiên dành cho số mũ y DH. Giá trị y (DHY) phải được một PRNG phù hợp tạo ra.

Phụ lục A

10

CICAM phải tính mã khóa công khai DH của CICAM (DHPM).

điều 6.2.3.2

11

...

...

...

message _ B = (versionǁ msg _ label ǁ auth _ nonce ǁ DHPH ǁ DHPM) signature_ B = RSASSA - PSS - SIGN(MDQ, message _ B) trong đó:

Phụ lục I

• RSASSA-PSS phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2

• MDQ là mã khóa riêng của thiết bị được quy định trong điều 5.3.

• version = 0x01 và msg_label = 0x3.

• Auth_nonce giống giá trị được tạo ra trong bước 1.

điều 5.3

12

...

...

...

điều 11.3.3.2

13

Máy chủ phải kiểm tra các thông số nhận được sau:

a) Máy chủ phải kiểm tra đóng dấu trên các giấy chứng nhận.

b) Máy chủ phải kiểm tra đóng dấu B, sao cho:

message _ B = (versionǁ msg _ label ǁ auth _ nonce ǁ DHPH ǁ DHPM)

RSASSA - PSS - VERIFY(MDP, message _ B, signature_ B) = TRUE

trong đó:

• RSA phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2.

...

...

...

• Version = 0x01 và msg_label = 0x3.

• Auth_nonce giáng giá trị nhận được trong bước 3.

• DHPH giống giá trị được tạo ra trong bước 5.

• DHPM giống giá trị nhận được trong bước 10.

• TRUE có nghĩa là ‘đóng dấu hợp lệ’

c) Máy chủ phải kiểm tra để: 1 < DHPM < DH _ p và DHPM ^DH-q mod DH _ p=1

d) Máy chủ phải xác nhận nhãn nhận dạng thương hiện của CICAM có trong giấy chứng nhận và là một số nguyên trong dài từ 1 đến 65535

điều 9.4

14

...

...

...

điều 11.3.3.2

15

CICAM phải tính và lưu trữ mã khóa DHSK.

điều 6.2.3.3

CICAM phải tính và lưu trữ mã khóa AKM.

điều 6.2.3.4

16

Máy chủ phải tính và lưu trữ mã khóa DHSK.

...

...

...

Máy chủ phải tính và lưu trữ mã khóa AKH.

điều 6.2.3.4

17

CICAM phải bắt đầu việc kiểm tra xác thực (bước 2 trong quá trình xác thực) bằng cách gửi một yêu cầu mã khóa xác thực hiện tại AKH đến máy chủ bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.3.3

18

Máy chủ xác nhận yêu cầu từ bước 17 và gửi AKH đến CICAM bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.3.3

...

...

...

CICAM phải kiểm tra xem AKH nhận được từ máy chủ có giống AKM được CICAM tính. Việc không giống nhau sẽ dẫn đến giao thức xác thực không thành công (CHÚ THÍCH 3).

Ghi chú:

1: Tham chiếu phụ lục H để biết tổng quan các thông số liên quan.

2: RSA được sử dụng để xác thực và kiểm tra SSAC như được trình bày trong phụ lục I. Các trường dữ liệu trong đóng dấu được nối bằng cách sử dụng định dạng độ dài thẻ được trình bày trong phụ lục J.

3: Hệ thống kiểm soát nội dung không thành công được quy định trong điều 6.1 và hình 6.1.

Tham chiếu đến điều 5.4.3 và phụ lục F để biết thông tin chi tiết của cơ chế báo cáo lỗi chung.

6.2.3.1. Các thông số Diffie Helman

Các thông số Diffie Helman và yêu cầu của chúng không được định nghĩa trong tiêu chuẩn này và có thể được tìm thấy trong Đặc tả về giấy phép Cl Plus [33].

...

...

...

Các mã khóa công khai Diffie Helman (DHPH và DHPM) là không ổn định và phải bị xóa sau khi hoàn thành giao thức xác thực.

Máy chủ phải tính toán mã khóa công khai Diffie Hellman của nó như sau:

DHPH=DH _public_Key_Host =g^x mod p                                                        Eq.6.1

CICAM phải tính toán mã khóa công khai Diffie Hellman của nó như sau:

DHPM=DH_public_Key_Module = g^ymod p                                                      Eq.6.2

Trong đó:

• Số mũ x (DHX) và số mũ y (DHY) là ngẫu nhiên và được một PRNG tạo ra theo quy định tại Phụ lục A. Các số mũ DHX và DHY phải được giữ bí mật và địa phương và phải bị xóa sau khi hoàn thành giao thức xác thực. Giá trị của g và p được quy định trong Đặc tả về giấy phép Cl Plus [33]. Sau khi tính toán của một mã khóa công khai DH, phải thực hiện các kiểm tra sau đây:

• kiểm tra xem 1 < DH_ public_key < DH_p ʌ DH_ public_key^DH-^q mod DH_p = 1.

Chú ý: tham khảo Phụ lục H để biết tổng quan về các thông số liên quan.

...

...

...

Mã khóa mật Diffie Helman (DHSK) phải được lưu trữ trong bộ nhớ ổn định. Mã khóa này phải được tính như sau:

DHSK = DH_private_Key_Host = (DHPM)^x mod DH_p = (DHPH)^y mod DH_p = DH_ private _Key_Module Eq.6.3

6.2.3.4. Tính mã khóa xác thực (AKH và AKM)

Mã khóa xác thực AKH/AKM phải được sử dụng để tính toán mã khóa SAC (xem điều 7.1.3) và mã khóa kiểm soát nội dung (CCK) (xem điều 8.1.4). Việc tạo mã khóa xác thực chỉ xảy ra một lần (mỗi cặp máy chủ- CICAM) khi CICAM và máy chủ được kết nối lần đầu. Các mã khóa xác thực thu được (AKM dành cho CICAM và AKH dành cho máy chủ) phải được lưu trữ trong bộ nhớ ổn định. Các mã khóa này phải được tính như sau:

AKM ≡ AKH = SHA₂₅₆ (CICAM_ID ǁ Host_ID ǁ DHSK )                                Eq.6.4

Các thông số đầu vào phải tuân theo Bảng 6.4.

Bảng 6.4 - Các thông số đầu vào trong tính toán mã khóa

Mã khóa hoặc biến số

Kích thước (bit)

...

...

...

Tham chiếu đến

DHSK

2048

Mã khóa mật DH đầy đủ từ quá trình xác thực.

điều 6.2.3.3

HOST_ID

64

Được ROT tạo ra và được bao gồm trong giấy chứng nhận X.509 của máy chủ.

điều 9.3.6

...

...

...

64

Được ROT tạo ra và được bao gồm trong giấy chứng nhận X.509 của CICAM.

điều 9.3.6

CHÚ THÍCH:

1. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

2. Tham chiếu phụ lục H để biết tổng quan các thông số liên quan.

6.3. Xác thực lại khi bật nguồn điện

Sau khi thiết lập phiên CC, CICAM và máy chủ thực hiện giao thức kiểm tra mã khóa xác thực để kiểm tra xem có tồn tại liên kết giữa hai thiết bị này và việc xác thực lại là không cần thiết.

Các trường hợp xác thực có chứa dữ liệu được yêu cầu để kiểm tra mã khóa xác thực và khởi tạo với xác thực chưa đầy đủ, bao gồm:

...

...

...

• DHSK

• CICAM ID/máy chủ ID

• ID thương hiệu của CICAM được sử dụng để ngăn chặn dịch vụ của máy chủ

• Thuật toán xáo trộn được thương lượng trong quá trình liên kết này

Máy chủ phải lưu trữ 5 trường hợp xác thực này. CICAM phải hỗ trợ ít nhất một trường hợp xác thực và có thể hỗ trợ nhiều trường hợp xác thực khác.

Nếu CICAM có một trường hợp xác thực hợp lệ, nó yêu cầu AKH từ máy chủ và kiểm tra xem AKH nhận được có phù hợp với AKM trong trường hợp xác thực của nó. Nếu không phù hợp, CICAM phải cố thử cho đến khi phù hợp hoặc đã được thực hiện tối đa 5 lần thử. Máy chủ trải qua trường hợp xác thực của nó và gửi lại các AKH tương ứng. Khi có phù hợp, xác thực nhanh được hoàn thành và máy chủ và CICAM tiếp tục với việc thiết lập SAC. Khi máy chủ không có một trường hợp xác thực hợp lệ, nó trả lời với giá trị AKH có tất cả các số là không. Khi nhận được AKH không hợp lệ này CICAM dừng việc cố thử và bắt đầu giao thức xác thực.

Việc thực hiện trên CICAM và máy chủ nên cố gắng giảm thiểu tối đa các trường hợp này khi có yêu cầu xác thực đầy đủ.

7. Kênh được xác thực an toàn

Cl SAC mã hóa và giải mã dữ liệu như các APDU thành các bản tin SAC. Một biểu đồ cấp cao theo ngữ cảnh được thể hiện trong hình 7.1:

...

...

...

CHÚ THÍCH: Cl SAC có thể gửi và nhận các bản tin cả hai chiều.

Hình 7.1 - Tổng quan theo ngữ cảnh của CI SAC

Hình 7.2 được cung cấp để tham khảo:

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/ khối hóa.

Hình 7.2 - Biểu đồ trình tự Cl SAC

Quá trình này được quy định trong Bảng 7.1:

Bảng 7.1 - Tổng quan theo ngữ cảnh của Cl SAC

TT

...

...

...

Tham chiếu đến

1

Giao thức xác thực.

điều 6.2

2

CICAM và máy chủ phải hoàn thành thành công giao thức xác thực tương hỗ này.

3

Khởi tạo SAC.

...

...

...

..

6

SAC phải được khởi tạo trên CICAM và máy chủ. Điều này liên quan đến việc lấy thông tin mã khóa và thiết lập (lại) trạng thái SAC ban đầu.

7

Yêu cầu đồng bộ SAC và xác nhận đồng bộ SAC.

điều 7.1.1

8

Nếu CICAM đã khởi tạo đúng Cl SAC, CICAM phải gửi một APDU để đồng bộ với máy chủ. Sau khi xác nhận thành công, cả hai phía có thể bắt đầu sử dụng SAC này.

...

...

...

9

Tạo và truyền bản tin SAC.

điều 7.3

..

15

Bản tin SAC được tạo ra dành cho tải bằng cách thêm phần mào đầu bản tin,

16

...

...

...

...

Nhận và kiểm tra bản tin SAC.

Khi nhận được bản tin SAC, nó phải được kiểm tra và nếu hợp lệ, tải của nó có thể được xử lý tiếp.

điều 7.4

CHÚ THÍCH:

1. Cl SAC có thể gửi và nhận các bản tin cả hai chiều.

2. Tham chiếu đến điều 7.5 để biết cách SAC được ghép trong kiến trúc Cl Plus.

3. Tham chiếu các bảng 11.28 và 11.30 để biết tổng quan các bản tin được trao đổi qua SAC.

7.1. Hoạt động Cl SAC

7.1.1. Khởi tạo SAC

...

...

...

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/ khối hóa.

Hình 7.3 - Biểu đồ trình tự tính toán mã khóa SAC

Quá trình này được quy định trong Bảng 7.2:

Bảng 7.2 - Tính toán mã khóa SAC

TT

Mô tả

Tham chiếu đến

1

...

...

...

điều 7.1.2

2

CICAM phải tạo nonce được sử dụng trong việc tính thông tin mã khóa SAC.

điều 7.1.3

3

CICAM phải gửi cc_data_req APDU đến máy chủ, bao gồm các thông số sau:

điều 11.3.3.5

• nonce Ns_module.

...

...

...

4

Máy chủ phải tạo nonce được sử dụng trong việc tính thông tin mã khóa SAC

Điều 7.1.3

5

Máy chủ phải xác nhận đã nhận được cc_data_request APDU từ CICAM bằng cách gửi cc_data_cnf APDU đến CICAM, bao gồm các thông số sau:

• nonce Ns_Host.

• HOST_ID, được lấy từ giấy chứng nhận thiết bị của máy chủ.

Không trả lời bằng cc_data_cnf dẫn đến hệ thống kiểm soát sao chép không thành công.

...

...

...

6

CICAM phải kiểm tra xem HOST_ID nhận được có bằng HOST_ID được lưu trữ trước đó (xem CHÚ THÍCH 2). Nếu chúng giống nhau thì CICAM có thể bắt đầu tính SAK và SEK và thiết lập (lại) trạng thái SAC.

điều 7.1.3

7

Máy chủ phải kiểm tra xem CICAM_ID nhận được có bằng CICAM_ID được lưu trữ trước đó (xem CHÚ THÍCH 2). Nếu chúng giống nhau thì máy chủ có thể bắt đầu tính SAK và SEK và phải thiết lập (lại) trạng thái SAC.

điều 7.1.3

8

CICAM phải gửi cc_sync_req APDU đến máy chủ, chỉ ra SAK mới.

Khi CICAM đã khởi tạo bộ xáo trộn, CICAM phải gửi yêu cầu đồng bộ đến máy chủ, chỉ ra rằng CICAM đã sẵn sàng bắt đầu sử dụng SAC này.

...

...

...

9

Máy chủ phải xác nhận bằng a cc_sync_cnf APDU đến CICAM chỉ ra rằng nó đã sẵn sàng bắt đầu sử dụng SAC này.

Không trả lời bằng cc_sync_cnf dẫn đến hệ thống kiểm soát sao chép không thành công. Xem CHÚ THÍCH 3

điều 11.3.3.5

CHÚ THÍCH:

1. Tham chiếu phụ lục F để biết tổng quan các thông số liên quan trong giao thức này.

2. HOST_ID / CICAM_ID được lưu trữ trước đó trong 'Authentication Context'. Tham chiếu đến điều 6.3

3. Tham chiếu đến điều 5.4.3 và phụ lục F để biết thông tin chi tiết về cơ chế báo cáo lỗi chung.

7.1.2. Các điều kiện mã khóa (lại) SAC

...

...

...

• Khi khởi động lại; khi khởi động (lại) được hoàn thành thành công và có một AKM hợp lệ được lưu trữ trong bộ nhớ.

• Khi ghép (lại) một CICAM; khi một CICAM được ghép lại vào một máy chủ và có một AKM hợp lệ được lưu trữ trong bộ nhớ.

• Khi xác thực (lại); khi không có AKM hợp lệ được lưu trữ trong bộ nhớ, phiên xác thực này được khởi tạo (lại), dẫn đến việc hoàn thành thành công (tức là AKM hợp lệ) của phiên xác thực (lại) tiếp theo.

• Khi bộ đếm bản tin quá tải.

Hình 7.4 giải thích hoạt động CICAM dành cho việc làm mới mã khóa SAC.

CHÚ THÍCH: Giới hạn số lần cố thử là 3 và được áp dụng đối với các lần không thành công tiếp theo của giao thức SAC trong bước 6.

Hình 7.4 - Lưu đồ - phiên làm mới mã khóa SAC của CICAM

Hình 7.5 giải thích hoạt động của máy chủ dành cho việc làm mới mã khóa SAC.

...

...

...

Hình 7.5 - Lưu đồ - phiên làm mới mã khóa SAC của máy chủ

7.1.3. Tính toán mã khóa SAC

SAC yêu cầu hai mã khóa để hoạt động: mã khóa xác thực SAC (SAK) và mã khóa mã hóa SAC (SEK). Việc tính toán SAK và SEK thực hiện theo hai bước:

• Tính toán nhân mã khóa.

• Đưa ra mã khóa SEK và SAK.

Các bước này được quy định như sau:

Bước 1: tính toán nhân mã khóa.

Nhân mã khóa Ks dài 256 bit và phải được sử dụng để tính toán mã khóa Km. Quá trình tính toán Ks phải được thực hiện trên máy chủ và CICAM.

Nhân mã khóa Ks phải được tính toán trên máy chủ như sau:

...

...

...

Nhân mã khóa Ks phải được tính toán trên CICAM như sau:

Ks_CICAM = SHA₂₅₆ (DHSK ǁ AKM ǁ Ns_host ǁ Ns_module)                            Eq.7.2

Trong đó:

• Ks _CICAM = Ks _host

• Các thông số đầu vào được quy định tại Bảng 7.3:

Bảng 7.3 - Các thông số đầu vào trong tính toán mã khóa

Mã khóa hoặc biến số

Kích thước (bit)

Diễn giải

...

...

...

DHSK

128

Các bit LSB của mã khóa mật DH từ quá trình xác thực. Xem CHÚ THÍCH 3

điều 6.2.3.3

AKH/AKM

256

Các mã khóa xác thực từ quá trình xác thực.

điều 6.2.3.4

Ns_Host

...

...

...

Nonce 64 bit ngẫu nhiên được máy chủ tạo và được máy chủ truyền đến CICAM.

Phụ lục A

Ns_module

64

Nonce 64 bit ngẫu nhiên được CICAM tạo và được CICAM truyền đến máy chủ.

Phụ lục A

CHÚ THÍCH:

1. Đầu váo được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

2. Các yêu cầu đối với bộ tạo số ngẫu nhiên của Ns_Host và Ns_module được trình bày trong phụ lục A

...

...

...

Bước 2: tính toán mã khóa.

Mã khóa Km dài 256 bit và phải được sử dụng để đưa ra SEK và SAK. Mã khóa Km phải được tính như sau:

SEK,SAK = f-SAC(Ks)                                                                             Eq.7.3

Lưu ý: Hàm f-SAC không được định nghĩa trong tiêu chuẩn này và được lấy từ Đặc tả về giấy phép Cl Plus [33].

7.1.4. Các mã lỗi SAC và thiết lập (lại) trạng thái SAC

Các điều kiện mã khóa lại SAC được giải thích trong Hình 7.6.

Hình 7.6 - Xử lý trạng thái SAC.

7.2. Định dạng của bản tin SAC

...

...

...

CHÚ THÍCH: SAC được xác thực trước tiên và sau đó được mã hóa.

Hình 7.7 - Thành phần bản tin SAC

Cú pháp bản tin SAC chi tiết được định nghĩa trong Bảng 7.4.

Bảng 7.4 - Cú pháp bản tin SAC

Trường

Số bit

Kiểu

message() {

...

...

...

message_counter

    /* Mào đầu bản tin bắt đầu ở đây */

32

uimsbf

    protocol_version

4

uimsbf

    authentication_cipher_flag

...

...

...

uimsbf

    payload_encryption_flag

1

bslbf

    encryption_cipher_flag

3

uimsbf

    reserved for future use

5

...

...

...

    length_payload

    /* Mào đầu bản tin kết thúc ở đây */

    /* Phần thân bản tin bắt đầu ở đây */

16

uimsbf

    if (payload_encryption_flag == MSG_FLAG_TRUE) {

    encrypted_payload

...

...

...

length_payload *8 + 128

bslbf

    payload

length_payload * 8

bslbfk

    authentication

    }

    /* Phần thân bản tin kết thúc ở đây */

}

...

...

...

bslbf

7.2.1. Các hằng số

Bản tin này quy định các hằng số được định nghĩa trong Bảng 7.5.

Bảng 7.5 - Các hằng số trong bản tin SAC

Tên

Giá trị

MSG_FLAG_FALSE

0

MSG_FLAG_TRUE

...

...

...

7.2.2. Mã hóa và ngữ nghĩa của các trường

message_counter: Một bản tin dữ liệu yêu cầu một bộ đếm duy nhất. Việc sử dụng trường này được giải thích trong điều 7.4.1.

protocol_version: tham số này chỉ ra phiên bản giao thức của bản tin này. Thiết bị này phải bỏ qua bản tin có số của protocol_version mà nó không hỗ trợ. Trong tiêu chuẩn này, giá trị của protocol_version của bản tin này phải được thiết lập là 0x0.

authentication_cipher_flag: Tham số này là chỉ ra thuật toán giải mã hóa được sử dụng để tạo ra trường xác thực này theo quy định tại Bảng 7.6:

Bảng 7.6 - Các giá trị cho phép đối với authentication_cipher_flag

Nội dung

Ý nghĩa

Diễn giải

0x0

...

...

...

Chế độ XCBC-MAC được trình bày trong RFC 3566 [20] (CHÚ THÍCH 2)

0x1-0x7

Dự phòng

CHÚ THÍCH

1. Thiết bị tuân theo tiêu chuẩn này phải phân tích giá trị 0x0 và bỏ qua các bản tin có giá trị authentication_cipher_flag không được hỗ trợ.

2. Ngoại trừ đầu ra MAC 128 bit MAC không bị cắt và giữ nguyên 128 bit.

payload_encryption_flag: tham số này chỉ ra nếu tải được mã hóa. Giá trị 1 chỉ ra mã hóa tải và giá trị 0 chỉ ra không mã hóa tải. Một thiết bị tuân theo tiêu chuẩn này phải phân tích giá trị là 1 và bỏ qua các bản tin có giá trị payload_encryption_flag không được hỗ trợ khác.

encryption_cipher_flag: tham số này chỉ ra thuật toán giải mã hóa được sử dụng để mã hóa tải của bản tin như quy định tại Bảng 7.7:

...

...

...

encrypted_payload: trường này chứa dữ liệu được mã hóa bao gồm tải của bản tin, phần đệm nếu được yêu cầu và xác thực. Tham khảo điều 7.3.2 dành cho mô tả của trường này.

payload: trường này mang tải của bản tin không được mã hóa (ví dụ dữ liệu đầu vào như một APDU).

authentication: trường này mang xác thực của bản tin. Tham khảo điều 7.3.1 dành cho mô tả về thủ tục xác thực. Trường này có thể được mã hóa và thông báo bằng "payload_encryption_flag"; tham khảo điều 7.3.2 để biết chi tiết.

CHÚ THÍCH: Cl SAC có thể gửi và nhận các bản tin cả hai chiều

Hình 7.8 - Nhiều Mô-đun

Bảng 7.7 - Các giá trị cho phép đối với encryption_cipher_fIag

Nội dung

Ý nghĩa

...

...

...

0x0

AES-128 in CBC mode

AES-128 tuân theo FIPS 197 [4] trong chế độ CBC tuân theo 800-38A [25]

0x1-0x7

Dự phòng

CHÚ THÍCH: Thiết bị tuân theo tiêu chuẩn này phải phân tích giá trị 0x0 và bỏ qua các bản tin có giá trị authentication_cipher_flag không được hỗ trợ.

7.3. Truyền các bản tin SAC

Một bản tin dữ liệu được gửi đến Cl SAC phải được xử lý như sau:

...

...

...

2) Tính toán xác thực của bản tin. Tham khảo điều 7.3.1 để biết chi tiết.

3) Ghép xác thực và tải và (tùy chọn) mã hóa bản tin này. Tham khảo điều 7.3.2 để biết chi tiết.

4) Dựng lên bản tin cuối cùng: (message_counter ǁ phần mào đầu I phần bản tin thu được từ bước 3). Tham khảo điều 7.2 để biết chi tiết.

5) Truyền bản tin này.

Chú ý: Nếu một trong các bước này thất bại, bản tin và trạng thái này (ví dụ như cặp mã khóa, bộ đếm, v.v..) phải bị hủy và một lỗi phải được đưa ra. Tham khảo điều 7.1.4 để biết chi tiết.

7.3.1. Xác thực bản tin

Bản tin dữ liệu trên Cl SAC được một trường xác thực bảo vệ. Trường xác thực này được tính như sau:

authentication = MAC {SAK}(length(header_h_i)□i□header _h_i □ payload_P_i)   Eq.7.4

Trong đó:

...

...

...

• SAK một khóa 128 bit, theo quy định tại điều 7.1.3.

• Việc xác thực được thực hiện trên toàn bộ bản tin, ngoại trừ trường xác thực. Các thông số này được sử dụng trong tính toán trường xác thực được quy định trong Bảng 7.8:

Bảng 7.8 - Các thông số trong tính toán của MAC

Thông số

Độ dài

Kiểu

length_hi

8

uimsbf

...

...

...

32

uimsbf

header_hi

length_hi * 8

bslbf

payload_pi

y * 8

bslbf

i - Trường này chứa giá trị message_counter từ bản tin này. Tham khảo điều 7.2.2 dành cho mô tả của trường này.

...

...

...

header_h_i - Thông số này trình bày phần mào đầu của bản tin, xem Bảng 7.4:

payload_p_i - Thông số này chứa tải của bản tin. Để tính toán trường xác thực này, tải không được mã hóa ban đầu phải được sử dụng.

7.3.2. Mã hóa bản tin

Một cờ cho biết nếu tải được mã hóa hay không. Nếu một bản tin SAC yêu cầu mã hóa, dữ liệu này được mã hóa như sau:

encryted _ payload_i = E{SEK,SIV}(payload_p_i □ authentication _a_i)              Eq.7.5

Trong đó:

• E là thuật toán được encryption_cipher_flag quy định, xem điều 7.2.2.

• SEK là mã khóa 128 bit. Tham khảo điều 7.1.3 để biết chi tiết.

• SIV là cố định, dài 128 bit và một hằng số của giấy phép, tham khảo Đặc tả về giấy phép Cl Plus [33]. SIV phải được sử dụng ở phần đầu của mỗi bản tin SAC.

...

...

...

Chú ý: Nếu payload_p_i không là bội số của kích thước khối mã (tức là 128 bit) thì bản tin này được đệm bằng cách thêm bit 1 (một) và tiếp theo là bit 0 (không) cho đến khi kích thước khối được làm đầy. Nếu tải không được mã hóa thì việc đệm không được áp dụng.

7.4. Nhận các bản tin SAC

Một bản tin dữ liệu được Cl SAC nhận phải được xử lý như sau:

1) Trước tiên kiểm tra xem bản tin nhận được có chứa message_counter và protocol_version chính xác. Tham khảo điều 7.4.1 để biết chi tiết.

2) Nếu payload_encryption_flag = 1 thì giải mã tải của bản tin được mã hóa. Tham khảo điều 7.4.2 để biết chi tiết chính xác.

3) Tính toán lại trường xác thực và kiểm tra tính toàn vẹn của bản tin. Tham khảo điều 7.4.3 để biết chi tiết.

Chú ý: Nếu một trong các bước này thất bại thì bản tin và trạng thái (ví dụ như cặp mã khóa, bộ đếm, v.v..) phải bị hủy và một lỗi phải được đưa ra. Tham khảo điều 7.1.4 để biết chi tiết.

7.4.1. Trạng thái bộ đếm bản tin

Thiết bị nhận (CICAM hoặc máy chủ) phải duy trì nội bộ một bộ đếm bản tin an toàn dành cho các bản tin nhận được để theo dõi số bản tin của bản tin cuối cùng nhận được. Khi nhận được một bản tin từ Cl SAC, máy chủ phải cập nhật trạng thái của receiver_message_counter. receiver_message_counter là một trường 32 bit (là trường bộ đếm bản tin của bản tin này).

...

...

...

Số bản tin chính xác: (i = receiver_message_counter + 1)

Số bản tin không chính xác: (i ≤ receiver_message_counter) ˅ (i > receiver_message_counter+1)

Số bản tin không chính xác gây ra "lỗi thứ tự bản tin"; Điều này phải được xử lý như đã giải thích trong điều 7.1.4

Các giới hạn của bản tin:

Số bản tin bị giới hạn ở 2 ^32-1 bản tin. Trường hợp số bản tin vượt quá, thiết bị phải dừng sử dụng các mã khóa hiện tại và thương lượng các mã khóa mới (xem điều 7.1.2). Số bản tin, i, trở lại 0x1 (khác không).

Chú ý: CICAM là thiết bị duy nhất có thể quyết định và khởi tạo các hành động tiếp theo dựa vào việc sử dụng hết của bộ đếm bản tin. Hành vi này được quy định tại điều 7.1.4.

7.4.2. Giải mã bản tin

Bản tin dữ liệu trên Cl SAC có thể được mã hóa. Việc giải mã được thực hiện như sau:

payload _ p, □ authentication _ a_i = D{SEK, SIV}(encrypted_payload_i)         Eq.7.6

...

...

...

• D là thuật toán được encryption_cipher_fIag quy định, xem điều 7.2.2.

• SEK là mã khóa 128 bit. Tham khảo điều 7.1.3 để biết chi tiết.

• SIV là cố định, dài 128 bit và một hằng số của giấy phép, tham khảo Đặc tả về giấy phép Cl Plus [33]. SIV phải được sử dụng ở phần đầu của mỗi bản tin SAC.

• Việc giải mã một bản tin không chính xác gây ra một "lỗi giải mã bản tin"; Điều này được xử lý như trong điều 7.1.4

Chú ý: authentication_a _i được tách ra từ payload_p _i nơi độ dài của authentication_a _i có thể được suy ra từ giá trị của authentication_cipher_flag.

Dữ liệu đầu vào SAC ban đầu = payload_p_i thu được - authentication_ a_i.

Nếu payload_p_i không là bội số của kích thước khối mã (tức là 128 bit) thì bản tin này được đệm bằng cách thêm bít 1 (một) và tiếp theo là bit 0 (không) cho đến khi kích thước khối được làm đầy. Nếu tải không được mã hóa thì việc đệm không được áp dụng.

7.4.3. Kiểm tra bản tin

Bản tin dữ liệu trên Cl SAC chứa một trường xác thực. Việc xác thực phải được xác nhận như:

...

...

...

Trong đó:

• MAC là thuật toán được authentication_cipher_flag quy định, xem điều 7.2.2.

• SAK một khóa 128 bit, theo quy định tại điều 7.1.3.

• Để mô tả các thông số còn lại tham khảo điều 7.3.1.

Chú ý: Nếu authentication_a _i được tính không bằng authentication_a _i được rút ra từ bản tin được giải mã (trong trường hợp payload_encryption_flag = 1), hoặc nếu a _i được tính không bằng trường xác thực được chứa trong bản tin này (trong trường hợp payload_encryption_flag = 0) thì bản tin m nhận được phải bị loại bỏ và phải tạo ra một lỗi kiểm tra bản tin và xử lý như quy định tại điều 7.1.4.

7.5. Tích hợp SAC vào Cl Plus

SAC được thiết kế là một giao thức đa mục đích và được tích hợp vào tài nguyên CC như được giải thích trong hình 7.9.

Hình 7.9 -Tích hợp bản tin SAC

...

...

...

TT

Mô tả

Tham chiếu đến

1

Hệ thống thu thập các đối tượng dữ liệu tạo thành tải SAC.

điều 11.3.1.7

2

Hệ thống xác thực bản tin SAC đầy đủ, bao gồm phần mào đầu SAC, tải SAC và phần đệm (nếu yêu cầu).

điều 7.3

...

...

...

Tải SAC và xác thực SAC được mã hóa. Dữ liệu SAC được mã hóa được gắn với phần mào đầu SAC, thẻ APDU và độ dài APDU.

điều 7.5

CHÚ THÍCH: Tham chiếu Bảng 11.10 dành cho các bản tin được truyền qua SAC

8. Các tính toán mã khóa nội dung

8.1. Giao thức làm mới mã khóa kiểm soát nội dung

8.1.1. Tổng quan bản tin và khởi tạo

Hình 8.1 được sử dụng để tham khảo:

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/ khối hóa.

...

...

...

Quá trình này được quy định trong Bảng 8.1:

Bảng 8.1 - Tính toán CCK

TT

Mô tả

Tham chiếu đến

1

Khi CICAM phát hiện có yêu cầu làm mới CCK, CICAM phải bắt đầu quá trình khởi tạo CCK. Các điều kiện chính xác để mã khóa (lại) được quy định trong điều tham chiếu ở cột bên.

điều 8.1.2

2

...

...

...

Kp = SHA₂₅₆ (nonce)

Phụ lục A.1

3

CICAM có thể ngay lập tức bắt đầu tính CIV và/ hoặc CCK.

điều 8.1.4

4

CICAM phải gửi cc_sac_data_req APDU đến máy chủ, bao gồm các thông số sau:

• Kp.

• CICAM_ID được lấy từ giấy chứng nhận thiết bị của CICAM.

...

...

...

điều 11.3.3.4

5

Máy chủ phải kiểm tra xem CICAM_ID nhận được có giống CICAM_ID được lưu trữ trước đó (Xem CHÚ THÍCH 5). Nếu chúng giống nhau, máy chủ có thể bắt đầu tính CIV và/ hoặc CCK.

Việc kiểm tra CICAM_ID không thành công phải dẫn đến trả lời 'no CC support'.

điều 8.1.4

6

Máy chủ phải xác nhận bằng cc_sac_data_cnf APDU đến CICAM, bao gồm các thông số sau:

• HOST_ID được lấy từ giấy chứng nhận thiết bị của máy chủ.

Không trả lời bằng cc_data_cnf dẫn đến hệ thống kiểm soát sao chép không thành công.

...

...

...

7

CICAM phải kiểm tra xem HOST_ID nhận được có giống HOST_ID được lưu trữ trước đó (CHÚ THÍCH 5). Nếu chúng giống nhau, CICAM có thể sử dụng CCK và CIV đã được tính.

Việc máy chủ trả lời 'CC_no support' hoặc việc kiểm tra HOST_ID không thành công dẫn đến hệ thống kiểm soát sao chép không thành công. Xem CHÚ THÍCH 6

điều 8.1.4

8

Máy chủ có thể tính CIV và/ hoặc CCK.

điều 8.1.4

9

CICAM phải gửi cc_sac_sync_req APDU đến máy chủ, chỉ ra CCK mới.

...

...

...

điều 11.3.3.4

10

Máy chủ phải gửi cc_sac_sync_cnf APDU để xác nhận với CICAM rằng nó đã sẵn sàng để bắt đầu sử dụng CCK mới được tính.

Việc không trả lời bằng cc_sac_sync_cnf dẫn đến hệ thống kiểm soát sao chép không thành công. Xem CHÚ THÍCH 6.

điều 11.3.3.4

CHÚ THÍCH:

1. Khi đã được tính, thông tin mã khóa mới phải được lưu trữ trong một thanh ghi thích hợp của bộ (giải) xáo trộn. Tham chiếu đến điều 5.6 để biết thông tin chi tiết.

2. Các điều kiện làm mới CCK được quy định trong điều 8.1.2.

3. Tham chiếu Phụ lục H để biết tổng quan các thông số liên quan.

...

...

...

5. HOST_ID / CICAM_ID được lưu trữ trước đó trong 'Authentication Context'. Tham chiếu đến điều 6.3

6. Tham chiếu đến điều 5.4.3 và phụ lục F để biết thông tin chi tiết về cơ chế báo cáo lỗi chung.

8.1.2. Các điều kiện mã khóa lại mã khóa kiểm soát nội dung

Việc làm mới mã khóa kiểm soát nội dung (CCK) được CICAM khởi tạo, trong khi máy chủ trả lời một cách thụ động. Việc làm mới CCK phải được kích hoạt dưới một trong các điều kiện sau:

• Sau khi cả hai quá trình khởi tạo SAC và xác thực đã hoàn thành thành công.

• Khi được CAS kích hoạt.

• Khi được kích hoạt định kỳ (tham số thời gian sống lớn nhất của mã khóa). Xem điều 8.1.3.

• Khi giới hạn bộ đếm khối bị tràn (chỉ dành cho chế độ AES).

• Tại mỗi khi khởi động lại.

...

...

...

Hình 8.2 giải thích hoạt động của CICAM khi làm mới CCK.

CHÚ THÍCH:

1. Đồng hồ làm mới mã khóa là thời gian chờ để tính CCK mới; Tham khảo hình 5.15 để biết thông tin chi tiết

2. Thời gian sống của mã khóa được trình bày trong điều 8.1.3

3. Giới hạn bộ đếm khối được quy định trong bảng 8.2

4. Key_lifetime ban đầu được quy định là khoảng thời gian sống của mã khóa đầu tiên (tức là khoảng thời gian tính CCK) sau khi khởi tạo (lại) SAC.

5. Việc bắt đầu hoạt động xáo trộn CC phụ thuộc vào dữ liệu URI liên kết với dịch vụ được chọn

Hình 8.2 - Hoạt động của CICAM khi làm mới CCK

...

...

...

Lựa chọn bộ xáo trộn

Giới hạn của bộ đếm khối

Diễn giải

DES

Không áp dụng

không được sử dụng

AES

2^32

...

...

...

Hình 8.3 giải thích hoạt động của máy chủ khi làm mới CCK.

Hình 8.3 - Hoạt động của máy chủ khi làm mới CCK

8.1.3. Thời gian sống của mã khóa nội dung

Tham số thời gian sống lớn nhất của mã khóa được hệ thống CA kiểm soát và nằm ngoài phạm vi của tiêu chuẩn này. Việc đếm ngược giá trị này được CICAM duy trì để kích hoạt quá trình làm mới CCK.

Việc đếm ngược chỉ được thực hiện khi CICAM đang xáo trộn nội dung. Điều này đảm bảo rằng không tính toán lại mã khóa nội dung khi không đang sử dụng nó.

8.1.4. Tính toán mã khóa kiểm soát nội dung (CCK)

Bộ xáo trộn yêu cầu một mã khóa nội dung (và IV nếu được yêu cầu) dành cho hoạt động của nó: mã khóa kiểm soát nội dung (CCK) và véc-tơ khởi tạo nội dung (CIV). Việc tính toán CCK (và CIV) được thực hiện theo hai bước:

• Tính tiền thân của mã khóa

...

...

...

Các bước này được quy định như sau:

Bước 1: tính tiền thân của mã khóa.

Tiền thân của mã khóa Kp dài 256 bit và phải được sử dụng để tính Km. Quá trình tính Kp phải được thực hiện trên CICAM.

Tiền thân của mã khóa Kp được tính trên CICAM như sau:

K p = S H A ₂₅₆ (n o n ce)                                                                          Eq.8.1

Trong đó:

• Các thông số đầu vào được quy định tại Bảng 8.3:

Bảng 8.3 - Các thông số đầu vào trong việc tính mã khóa

Mã khóa hoặc biến số

...

...

...

Diễn giải

Tham chiếu đến

nonce

256

Nonce 256 bit ngẫu nhiên được CICAM tạo ra.

Phụ lục A

CHÚ THÍCH:

1. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

2. Các yêu cầu đối với bộ tạo số ngẫu nhiên của nonce được trình bày trong phụ lục A

...

...

...

Mã khóa Km dài 256 bit và được sử dụng để rút ra mã khóa kiểm soát nội dung (CCK). Mã khóa Km được tính như sau:

CCK,CIV = f - CC (Kp)                                                                             Eq.8.2

Lưu ý: hàm f - CC không được định nghĩa trong tiêu chuẩn này và có thể tham khảo Đặc tả về giấy phép Cl Plus [33].

Sau khi xác thực thành công, hệ thống sẽ xác định xem các thuật toán giả mã hóa AES hay DES có được sử dụng để bảo vệ nội dung chưa được CA xáo trộn trả lại máy chủ (xem điều 6). Mã kiểm soát nội dung (CCK) và véc-tơ khởi tạo (CIV) được rút ra từ mã khóa Km theo những cách khác nhau dành cho bộ xáo trộn AES-128 và bộ xáo trộn DES-56.

8.1.5. Mã khóa nội dung dành cho bộ xáo trộn DES-56-ECB.

Mã khóa nội dung DES-56 (CCK_DES) là 64 bit. Mã khóa CCK từ f-CC được đệm với các bit chẵn lẻ theo cách giống như SCTE41 [5], Phụ lục B sang CCK_DES thu được. CCK_DES phải được thay đổi như được quy định tại điều 5.6.1.

Khi sử dụng DES, phải sử dụng CCK để giải xáo trộn gói tin TS như sau:

clear _ packet = D_DES-56-ECB{CCK_DES}(Ts_Packet)                                          Eq.8.3

Chú ý: Tham khảo điều 5.6.2.2 dành cho các đặc điểm chi tiết của bộ xáo trộn (lại) DES.

...

...

...

Mã khóa nội dung AES-128 (CCKAES) có chiều dài 128 bit. Khi sử dụng AES, phải áp dụng CCK và CIV vào AES để giải xáo trộn gói tin TS như sau:

clear _ packet = D_DES-128-CBC {CCK_AES}{CIV}(Ts_Packet)                                 Eq.8.4

Trong đó:

• CCK_AES phải thay đổi theo quy định tại điều 5.6.1. Ngoài ra, CCK _AES phải được thay đổi sau khi xử lý 2 ^32 khối AES.

• CIV là cố định đối với mỗi giai đoạn thời gian sống của mã khóa và phải thay đổi khi CCK thay đổi. CIV hiện tại phải được sử dụng lại ở phần đầu của mỗi gói tin MPEG2 TS.

Chú ý: Tham khảo điều 5.6.2.3 dành cho đặc điểm chi tiết của bộ xáo trộn (lại) AES.

9. Chi tiết về chứng nhận và PKI

9.1. Giới thiệu

Việc xác thực giữa một máy chủ Cl Plus và mô-đun bao gồm việc trao đổi chứng nhận. Chứng nhận thiết bị của một máy chủ hoặc mô-đun phục vụ 3 mục đích:

...

...

...

• Cung cấp một mã khóa công khai RSA của thiết bị. Mã khóa này được sử dụng để kiểm tra mã khóa công khai Diffie- Hellman của thiết bị trong giao thức xác thực, xem hình 6.2 và Bảng 6.1

• Truyền những khả năng bộ xáo trộn của thiết bị

Mỗi nhà cung cấp dịch vụ cung cấp các dịch vụ Cl Plus có giấy chứng nhận của nhà điều hành dịch vụ. Giấy chứng nhận này được CICAM sử dụng để kiểm tra tính toàn vẹn của danh sách thu hồi mà nó nhận được.

9.2. Kiến trúc quản lý chứng nhận

Hệ thống phân cấp tin cậy Cl Plus được tổ chức theo cấu trúc hình cây với một gốc tin cậy duy nhất (ROT). Chỉ có một cây dành cho tất cả các thành viên tham gia Cl Plus, xem Hình 9.1.

Hình 9.1- Cây phân cấp giấy chứng nhận

Có bốn loại giấy chứng nhận khác nhau.

• Giấy chứng nhận gốc

...

...

...

- tự đóng dấu

- chỉ có một giấy chứng nhận gốc tồn tại dành cho tất cả các thiết bị Cl Plus

• Giấy chứng nhận thương hiệu

- do ROT cấp

- đóng dấu với mã khóa riêng của giấy chứng nhận gốc

- một giấy chứng nhận của loại này tồn tại dành cho mỗi thương hiệu (hoặc nhà sản xuất)

• Giấy chứng nhận thiết bị

- do ROT cấp

- đóng dấu với mã khóa riêng của giấy chứng nhận thương hiệu

...

...

...

• Giấy chứng nhận nhà điều hành dịch vụ

- do ROT cấp

- đóng dấu với mã khóa riêng của giấy chứng nhận gốc

- một giấy chứng nhận của loại này tồn tại dành cho mỗi nhà điều hành dịch vụ

Mỗi giấy chứng nhận chứa một mã khóa công khai mà dành cho nó có một mã khóa riêng tương ứng.

Mỗi thiết bị máy chủ và mô-đun phải tích hợp các thông tin liên quan đến giấy chứng nhận sau tại thời điểm sản xuất.

• Giấy chứng nhận gốc Cl Plus

• Giấy chứng nhận thương hiệu

• Giấy chứng nhận thiết bị

...

...

...

Giấy chứng nhận nhà điều hành dịch vụ có tính chất phát rộng và không giống như các giấy chứng nhận khác nên nó không được tích hợp vào máy chủ hoặc CICAM tại nơi sản xuất.

9.3. Định dạng giấy chứng nhận

Tất cả các giấy chứng nhận Cl Plus phải được dựa vào hồ sơ Internet X.509, được quy định trong RFC 3280 [19]. Bản quy định kỹ thuật MHP 1.0.3, TS 101 812 [9], điều 12.11 cung cấp tổng quan về mã hóa giấy chứng nhận.

Định nghĩa ASN.1 của một giấy chứng nhận X.509 được lấy từ RFC 3280 [19], điều 4.1, được trình bày dưới đây để tham khảo:

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,

signatureAlgorithm Algorithmldentifier,

signatureValue BIT STRING}

TBSCertificate ::= SEQUENCE {

...

...

...

serialNumber CertificateSerialNumber,

signature Algorithmldentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeylnfo SubjectPublicKeylnfo,

issuerUniquelD [1] IMPLICIT Uniqueldentifier OPTIONAL,

-- If present, version MUST be v2 or v3

subjectUniquelD[2] IMPLICIT Uniqueldentifier OPTIONAL,

...

...

...

extensions [3] EXPLICIT Extensions OPTIONAL

-- If present, version MUST be v3

}

Version ::= INTEGER {v1(0), v2(1), v3(2)}

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {

notBefore Time,

notAfter Time}

Time ::= CHOICE {

...

...

...

generalTime GeneralizedTime}

Uniqueldentifier ::= BIT STRING

SubjectPublicKeylnfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

...

...

...

Phần này giải thích các trường và các phần mở rộng được sử dụng trong tiêu chuẩn này.

9.3.1. Phiên bản

Cl Plus phải sử dụng X.509 phiên bản 3.

9.3.2. Số sêri

Mỗi giấy chứng nhận phải bao gồm một số sêri duy nhất mà được tổ chức phát hành giấy chứng nhận cấp.

9.3.3. Đóng dấu

Tất cả các giấy chứng nhận sử dụng các đóng dấu RSASSA-PSS theo quy định tại PKCS1v2.1 [1], điều 8.1.1.

Bảng 9.1 - Thuật toán đóng dấu giấy chứng nhận

Thông số

...

...

...

hashAlgorithm

SHA-1

maskGenAlgorithm

MGF1 sử dụng SHA-1

saltLength

20 byte

trailerField

1 byte: 0xbc

Các nhãn định danh đối tượng ASN.1 tương ứng là

...

...

...

pkcs-1 OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {

sha1Identifier, mgf1SHA1Identifier, 20,1}

sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }

id-sha1 OBJECT IDENTIFIER ::= {

iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 }

mgf1SHA1Identifier AlgorithmIdentifier ::= { id-mgf1, sha1Identifier }

9.3.4. Tổ chức phát hành

...

...

...

Bảng 9.2 - Tổ chức phát hành giấy chứng nhận

Loại giấy chứng nhận

Tổ chức phát hành

Giấy chứng nhận gốc

C: <quốc gia nơi ROT nằm> ST: <bang/tỉnh nơi ROT nằm>

L: <thành phố nơi ROT nằm>

O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo thử” hoặc “sản xuất”

...

...

...

Giấy chứng nhận thương hiệu

C: <quốc gia nơi ROT nằm> ST: <bang/tỉnh nơi ROT nằm> L: <thành phố nơi ROT nằm>

O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo thử” hoặc “sản xuất”

CN: “Giấy chứng nhận CA gốc Cl PLus”

Giấy chứng nhận thiết bị

C: <quốc gia nơi thương hiệu nằm> ST: <bang/ tỉnh nơi thương hiệu nằm> L: <thành phố nơi thương hiệu nằm>

O: <tên của thương hiệu>

...

...

...

CN: “Cl Plus ROT for” <tên của thương hiệu>

Giấy chứng nhận nhà điều hành dịch vụ

C: <quốc gia nơi ROT nằm> ST: <bang/tỉnh nơi ROT nằm>

L: <thành phố nơi ROT nằm> O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo thử” hoặc “sản xuất”

CN: “Giấy chứng nhận CA gốc Cl PLus”

Các thuộc tính X.501 được Cl Plus sử dụng là đất nước (C), bang (ST), khu vực (L), tên tổ chức (O), tên đơn vị (OU) và tên phổ biến (CN). Xin lưu ý rằng các thuộc tính tương tự có thể xuất hiện trong một tên nhiều lần.

Việc mã hóa ASN.1 của một tên phân biệt X.501 được định nghĩa trong RFC 3280 [19], điều 4.1.2.4. Tất cả các giá trị thuộc tính có thể được mã hóa theo PrintableString hoặc UTF8String.

...

...

...

Hiệu lực của Giấy chứng nhận phải lớn hơn thời gian sống dự kiến của thiết bị. Tiêu chuẩn này không đưa ra phương pháp thay thế giấy chứng nhận gốc, thương hiệu hoặc thiết bị. Giấy chứng nhận nhà điều hành dịch vụ nhận được thông qua phát sóng và có thể dễ dàng được cập nhật; thời gian sống của nó có thể ngắn hơn đáng kể so với các giấy chứng nhận khác.

Định nghĩa của các thời gian sống chính xác dành cho các giấy chứng nhận này nằm ngoài phạm vi của tiêu chuẩn này.

Thời gian trong các trường notBefore và notAfter phải được mã hóa theo Thời gian UTC và phải bao gồm giây, tức là có định dạng YYMMDDHHMMSSZ. Trường năm phải được hiểu là 20YY.

9.3.6. Đối tượng

Đối tượng là một tên phân biệt X.501 [22] và sử dụng mã hóa tương tự như trường tổ chức phát hành.

Bảng 9.3 - Đối tượng giấy chứng nhận

Loại giấy chứng nhận

Đối tượng

Giấy chứng nhận gốc

...

...

...

L: <thành phố nơi ROT nằm>

O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo thử” hoặc “sản xuất”

CN: “Giấy chứng nhận CA gốc Cl PLus”

Giấy chứng nhận thương hiệu

C: <quốc gia nơi thương hiệu nằm> ST: <bang/ tỉnh nơi thương hiệu nằm> L: <thành phố nơi thương hiệu nằm>

0O: <tên của thương hiệu>

OU: “đo thử” hoặc “sản xuất”

...

...

...

Giấy chứng nhận thiết bị

C: <quốc gia nơi thương hiệu nằm> ST: <bang/ tỉnh nơi thương hiệu nằm>

L: <thành phố nơi thương hiệu nằm> O: <tên của thương hiệu>

OU: <tên sản phẩm> (tùy chọn) OU: “đo thử” hoặc “sản xuất”

CN: <ID của thiết bị>

Giấy chứng nhận nhà điều hành dịch vụ

C: <quốc gia nơi nhà điều hành nằm> ST: <bang/ tỉnh nơi nhà điều hành nằm> L: <thành phố nơi nhà điều hành nằm>

O: <tên của nhà điều hành>

OU: “đo thử” hoặc “sản xuất”

...

...

...

ID của thiết bị là một số thập lục phân gồm 16 số. Để lưu số này trong thuộc tính X.501 Common Name (CN), nó phải được chuyển đổi thành một chuỗi. Mỗi số được trình bày bằng mã ASCII tương ứng, tức là 1 được viết như 0x31 và 7 như 0x37. Đối với các số thập lục phân A đến F, các chữ hoa được sử dụng (giá trị các số thập lục là từ 0x41 đến 0x46).

Để biết chi tiết về nội dung ID của thiết bị, tham khảo Đặc tả về giấy phép Cl Plus [33].

ID của nhà điều hành dịch vụ là một số thập lục phân gồm 16 số. Nó được mã hóa giống như đối với ID của thiết bị. ID của nhà điều hành dịch vụ được sử dụng để liên kết một giấy chứng nhận nhà điều hành dịch vụ với tập tin dữ liệu thông báo thu hồi (RSD), xem điều 3.1.4 của Bản quy định kỹ thuật bổ sung Cl Plus [37].

9.3.7. subjectPublicKeylnfo

Thuật toán này là RSA sử dụng nhãn định danh đối tượng ASN.1

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}

pkcs-1 OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

Trường các thông số phải có loại ASN.1 là NULL.

...

...

...

9.3.8. issuerUniquelD và subjectUniquelD

Các thông số issuerUniquelD và subjectUniquelD được định nghĩa trong RFC 3280 [19], điều 4.1.2.8. Các giấy chứng nhận Cl Plus không được sử dụng các nhãn định danh duy nhất.

9.3.9. Phần mở rộng

Các giấy chứng nhận dành cho Cl Plus sử dụng một số phần mở rộng tiêu chuẩn này được định nghĩa trong RFC 3280 [19] và hai phần mở rộng riêng dành cho Cl Plus. Bảng sau liệt kê các phần mở rộng bắt buộc đối với từng loại giấy chứng nhận

Bảng 9.4 -Các phần mở rộng giấy chứng nhận

Loại giấy chứng nhận

Các phần mở rộng quy định

Giấy chứng nhận gốc

sử dụng mã khóa

...

...

...

các giới hạn cơ bản

Giấy chứng nhận thương hiệu

sử dụng mã khóa

nhãn nhận dạng mã khóa đối tượng

nhãn nhận dạng mã khóa quyền các giới hạn cơ bản

Giấy chứng nhận thiết bị

sử dụng mã khóa

nhãn nhận dạng mã khóa quyền

các giới hạn cơ bản

...

...

...

Thông tin Cl Plus (tùy chọn)

Nhãn nhận dạng thương hiệu CICAM (CICAM only)

Giấy chứng nhận nhà điều hành dịch vụ

sử dụng mã khóa

nhãn nhận dạng mã khóa quyền

các giới hạn cơ bản

Tất cả các phần mở rộng khác có thể được sử dụng được định nghĩa trong RFC 3280 [19] và chúng không được xem là quan trọng. Máy chủ và CICAM tuân thủ Cl Plus có thể bỏ qua các phần mở rộng này khi phân tích và kiểm tra giấy chứng nhận.

9.3.9.1. Nhãn định danh mã khóa đối tượng

Nhãn định danh mã khóa đối tượng phải được tính theo đề xuất (1) trong RFC 3280 [19], điều 4.2.1.2.

...

...

...

Phần mở rộng nhãn định danh mã khóa cơ quan thẩm quyền được định nghĩa trong RFC 3280 [19], điều 4.2.1.1. Trường Keyldentifier phải được tính theo đề xuất (1) trong RFC 3280 [19], điều 4.2.1.2.

9.3.9.3. Sử dụng mã khóa

Phần mở rộng sử dụng mã khóa được định nghĩa trong RFC 3280 [19], điều 4.2.1.3 và phải luôn luôn sẵn có và được đánh dấu là quan trọng. Giá trị của KeyUsage phụ thuộc vào loại giấy chứng nhận như thể hiện trong Bảng 9.5.

Bảng 9.5 - Các giá trị sử dụng mã khóa dành cho các loại giấy chứng nhận

Loại giấy chứng nhận

Sử dụng mã khóa

Giấy chứng nhận gốc

keyCertSign crlSign

Giấy chứng nhận thương hiệu

...

...

...

Giấy chứng nhận thiết bị

digitalSignature

Giấy chứng nhận nhà điều hành dịch vụ

cRLSign digitalSignature

9.3.9.4. Các giới hạn cơ bản

Phần mở rộng giới hạn cơ bản được định nghĩa trong RFC 3280 [19], điều 4.2.1.10. Các giá trị này phải được thiết lập như sau:

Bảng 9.6 - Các trường mở rộng

Loại giấy chứng nhận

CA

...

...

...

Giấy chứng nhận gốc

True

1

Giấy chứng nhận thương hiệu

True

0

Giấy chứng nhận thiết bị

False

-

...

...

...

False

-

9.3.9.5. Các khả năng của bộ xáo trộn

Các khả năng của bộ xáo trộn là một phần mở rộng riêng dành cho Cl Plus, nó phải sẵn có trong mỗi giấy chứng nhận thiết bị và được đánh dấu là quan trọng. Định nghĩa ASN.1 này được định nghĩa là:

id-pe-scramblerCapabilities OBJECT IDENTIFIER ::= {id-pe 25}

id-pe ::= {

iso(1) identified-organization(3) dod(6) internet(1) security(5)

mechanisms(5) pkix(7) 1 }

ScramblerCapabilities ::= SEQUENCE {

...

...

...

version INTEGER (0..MAX)}

Các giá trị sau được hỗ trợ

Bảng 9.7 - Các khả năng được hỗ trợ

Giá trị

Ý nghĩa

0

DES

1

DES and AES

...

...

...

Dự phòng

Trường phiên bản này được sử dụng để phân biệt hơn nữa các khả năng khác nhau của bộ xáo trộn. Xem Đặc tả về giấy phép Cl Plus [33] để biết thêm chi tiết.

9.3.9.6. Cl Plus info

Phần mở rộng riêng tùy chọn của Cl Plus info truyền thông tin bổ sung về thiết bị Cl Plus. Phần mở rộng này chỉ phải sẵn có trong giấy chứng nhận thiết bị và không được khai báo là quan trọng.

Định nghĩa ASN.1 của nó là

id-pe-cipluslnfo OBJECT IDENTIFIER ::= {id-pe 26 }

id-pe ::= {

iso(1) identified-organization(3) dod(6) internet(1) security(5)

mechanisms(5) pkix(7) 1}

...

...

...

Nội dung của Cipluslnfo không được tiêu chuẩn này quy định và có thể được phần mở rộng hồ sơ trong tương lai sử dụng.

9.3.9.7. Nhãn định danh thương hiệu CICAM

Phần mở rộng riêng nhãn định danh thương hiệu CICAM truyền nhận dạng của nhà sản xuất CICAM trong giấy chứng nhận thiết bị Cl Plus nên được phù hợp với dòng truyền tải dành cho cơ chế ngăn chặn của máy chủ (Xem điều 10.1.1). Phần mở rộng này không được khai báo là quan trọng. Phần mở rộng này phải sẵn có trong giấy chứng nhận thiết bị CICAM.

Định nghĩa ASN.1 này là:

id-pe-cicamBrandld OBJECT INDENTIFIER ::= { id-pe 27 } id-pe ::= {

iso(1) identified-organization(3) dod(6) internet(1) security(5)

mechanisms(5) pkix(7) 1 }

CicamBrandld ::= INTEGER (1..65535)

9.3.10. signatureAlgorithm

...

...

...

9.3.11. signatureValue

Trường này được định nghĩa trong RFC 3280 [19], điều 4.1.1.3

9.4. Kiểm tra giấy chứng nhận

Trong quá trình xác thực (xem điều 6), các chuỗi giấy chứng nhận được trao đổi và mỗi thiết bị kiểm tra chuỗi của thiết bị kia. Phần này giải thích quá trình kiểm tra.

Giấy chứng nhận gốc Cl Plus được lưu trữ trong mỗi thiết bị, trong quá trình xác thực, chỉ có giấy chứng nhận thương hiệu và thiết bị được trao đổi, giấy chứng nhận gốc không bao giờ được bất kỳ thiết bị nào trao đổi.

9.4.1. Kiểm tra giấy chứng nhận thương hiệu

Các bước sau đây phải được thực hiện để kiểm tra giấy chứng nhận thương hiệu.

1) Kiểm tra xem tổ chức phát hành giấy chứng nhận thương hiệu có trùng với đối tượng của giấy chứng nhận gốc.

2) Kiểm tra thời hạn hiệu lực của giấy chứng nhận thương hiệu bao gồm ngày và thời gian hiện tại.

...

...

...

4) Kiểm tra xem Keyldentifier trong phần mở rộng nhãn định danh mã khóa tổ chức thẩm quyền của giấy chứng nhận thương hiệu này có giống với Keyldentifier trong phần mở rộng nhãn định danh mã khóa đối tượng của giấy chứng nhận gốc.

5) Kiểm tra đóng dấu của giấy chứng nhận bằng cách sử dụng kiểm tra RSASSA-PSS được mô tả trong RSA PKCS # 1 [1], điều 8.12.

Bảng 9.8 - Kiểm tra giấy chứng nhận thương hiệu

Thông số

Giá trị

Mã khóa công khai RSA của đóng dấu

subjectPublicKeylnfo của giấy chứng nhận gốc

Bản tin được kiểm tra

TBSCertificate của giấy chứng nhận thương hiệu (xem RFC 3280 [19], điều 4.1)

...

...

...

signatureValue của giấy chứng nhận thương hiệu

9.4.2. Kiểm tra giấy chứng nhận thiết bị

Khi giấy chứng nhận thương hiệu được xác định là hợp lệ, giấy chứng nhận thiết bị được kiểm tra. Quá trình này tương tự như việc kiểm tra giấy chứng nhận thương hiệu.

1) Kiểm tra xem tổ chức phát hành giấy chứng nhận thiết bị có trùng với đối tượng của giấy chứng nhận thương hiệu

2) Kiểm tra thời hạn hiệu lực của giấy chứng nhận thiết bị bao gồm thời gian hiện tại.

3) Kiểm tra xem mỗi phần mở rộng được liệt kê trong phần 9.3.9 có tồn tại và các giá trị có hợp lệ. Kiểm tra xem không có phần mở rộng khác được đánh dấu là quan trọng.

Kiểm tra phần mở rộng nhãn định danh thương hiệu CICAM có tồn tại trong giấy chứng nhận thiết bị CICAM và nó có chứa các giá trị hợp lệ theo điều 9.3.9.7.

Lưu ý: Mặc dù phần mở rộng này không được đánh dấu là quan trọng nhưng việc kiểm tra giấy chứng nhận sẽ bị “fail” nếu phần mở rộng này không tồn tại hoặc chứa một giá trị không hợp lệ.

4) Kiểm tra xem Keyldentifier trong phần mở rộng nhãn định danh mã khóa tổ chức thẩm quyền của giấy chứng nhận thiết bị này có giống với Keyldentifier trong phần mở rộng nhãn định danh mã khóa đối tượng của giấy chứng nhận thương hiệu.

...

...

...

Bảng 9.9 - Kiểm tra giấy chứng nhận thiết bị

Thông số

Giá trị

Mã khóa công khai RSA của đóng dấu

subjectPublicKeylnfo của giấy chứng nhận thương hiệu

Bản tin được kiểm tra

TBSCertificate của giấy chứng nhận thiết bị (xem RFC3280 [19], điều 4.1)

Đóng dấu được kiểm tra

signatureValue của giấy chứng nhận thiết bị

...

...

...

7) Kiểm tra xem ID của thiết bị (một phần của trường đối tượng) có chứa một giá trị hợp lệ. Xem Phụ lục B để biết chi tiết.

Các thông tin chi tiết về việc kiểm tra thu hồi danh sách có thể được tìm thấy trong Đặc tả về giấy phép Cl Plus [33].

9.4.3. Kiểm tra giấy chứng nhận nhà điều hành dịch vụ

Để kiểm tra giấy chứng nhận nhà điều hành dịch vụ, các bước sau đây phải được thực hiện:

1) Kiểm tra xem tổ chức phát hành giấy chứng nhận nhà điều hành dịch vụ có trùng với đối tượng của giấy chứng nhận gốc.

2) Kiểm tra xem thời hạn hiệu lực của giấy chứng nhận nhà điều hành dịch vụ có bao gồm ngày và thời gian hiện tại.

3) Kiểm tra xem mỗi phần mở rộng bắt buộc được liệt kê trong điều 9.3.9 có tồn tại và các giá trị có hợp lệ. Kiểm tra xem không có phần mở rộng khác được đánh dấu là quan trọng.

4) Kiểm tra xem Keyldentifier trong phần mở rộng nhãn định danh mã khóa tổ chức thẩm quyền của giấy chứng nhận nhà điều hành dịch vụ này có giống với Keyldentifier trong phần mở rộng nhãn định danh mã khóa đối tượng của giấy chứng nhận gốc.

5) Kiểm tra đóng dấu của giấy chứng nhận bằng cách sử dụng kiểm tra RSASSA-PSS được mô tả trong RSA PKCS # 1 [1], điều 8.12.

...

...

...

Thông số

Giá trị

Mã khóa công khai RSA của đóng dấu

subjectPublicKeylnfo của giấy chứng nhận gốc

Bản tin được kiểm tra

TBSCertificate của giấy chứng nhận nhà điều hành dịch vụ (xem RFC3280 [19], điều 4.1)

Đóng dấu được kiểm tra

signatureValue của giấy chứng nhận nhà điều hành dịch vụ

6) Kiểm tra xem trình bày số ID của nhà điều hành dịch vụ trong đối tượng có phù hợp với service_operator_identity của tập tin dữ liệu thông báo thu hồi (RSD) trên bộ ghép kênh hiện tại.

...

...

...

Việc ngăn chặn dịch vụ của máy chủ cho phép nhà điều hành dịch vụ thông báo cho máy chủ sử dụng các dịch vụ có yêu cầu sự bảo vệ của CI Plus để cho phép máy chủ ngăn chặn việc hiển thị nội dung khi CICAM không tuân thủ CI Plus. Việc ngăn chặn dịch vụ của máy chủ đảm bảo rằng DVB CICAM không thể hiển thị nội dung trên các dịch vụ mà nó không được phép.

10.1. Thông báo dịch vụ được CI Plus bảo vệ

Thông báo dịch vụ được CI Plus bảo vệ được truyền trong Bảng mô tả dịch vụ (SDT_Actual) dành cho bộ ghép kênh thực tế, theo quy định tại EN 300 468 [10]. Một dịch vụ được CI Plus bảo vệ được thông báo bằng sự bao gồm của một nhãn quy định dữ liệu riêng CI Plus và ci_protection_descriptor riêng trong vòng nhãn mô tả dịch vụ của SDT_Actual. Nhãn mô tả này xác định xem dịch vụ có được CI Plus cho phép và có thể tùy chọn hạn chế máy chủ hoạt động với một thương hiệu cụ thể của CI Plus CICAM.

Thông báo dịch vụ được CI Plus bảo vệ là một thuộc tính trạng thái gần tĩnh của dịch vụ và không được thay đổi trên cơ sở sự kiện. Một dịch vụ có thể chuyển đổi giữa rõ ràng và được xáo trộn trên cơ sở sự kiện. Việc kiểm tra ngăn chặn dịch vụ của máy chủ hoạt động trên tất cả các dịch vụ, cả FTA và được CA xáo trộn, khi có bất kỳ CICAM trong một thiết bị máy chủ thì đảm bảo rằng thông báo truyền ngăn chặn dịch vụ này phải luôn luôn được quan trọng.

10.1.1  Nhãn mô tả được CI bảo vệ

Nhãn mô tả được CI bảo vệ (Xem Bảng 10.1) cung cấp một cách để chỉ ra chế độ hoạt động của CI được một dịch vụ yêu cầu. Nhãn này phải được chèn vào tối đa một lần trong vòng nhãn mô tả dịch vụ của SDT_Actual và phải đứng sau nhãn mô tả của nhãn quy định dữ liệu riêng CI Plus theo tiêu chuẩn EN 300 468 [10].

Bảng 10.1 - Nhãn mô tả được CI bảo vệ

10.1.1.1. Nhãn mô tả được CI bảo vệ

...

...

...

descriptor_length: Độ dài nhãn mô tả này là một trường 8-bit xác định tổng số byte của phần dữ liệu của ci_protection_descriptor tiếp theo byte xác định giá trị của trường này.

free_ci_mode_flag: Đây là một trường 1-bit xác định chế độ hoạt động của CI. Khi được thiết lập là "0" thì chỉ ra rằng tất cả các dòng thành phần của dịch vụ không yêu cầu được CI Plus bảo vệ. Khi được thiết lập là "1" thì chỉ ra rằng tất cả các dòng thành phần của dịch vụ yêu cầu được CI Plus bảo vệ nếu chúng không được truyền rõ ràng trên mạng.

match_brand_flag: Đây là một trường 1-bit thông báo rằng nhãn mô tả này bao gồm một danh sách các CICAM_brand_identifier. Khi được thiết lập là "0" thì chỉ ra rằng dịch vụ này không lựa chọn các thương hiệu của CICAM. Khi được thiết lập là "1" thì chỉ ra rằng dịch vụ này đã lựa chọn thiết lập thương hiệu của CICAM. match_brand_flag chỉ phân tích khi free_ci_mode_flag được thiết lập là "1".

reserved_future_use: Các bit dự phòng này phải là "1".

number_of_entries: Trường này xác định số các cicam_brand_identifier được chứa trong vòng nhãn định danh thương hiệu. Khi trường match_brand_flag đã được thiết lập là 1 thì number_of_entries phải khác 0.

cicam_brand_identifier: Đây là một trường 16-bit nhận dạng các thương hiệu CICAM có thể được sử dụng với dịch vụ này.

Khi không có các nhãn định danh thương hiệu CICAM thì có thể sử dụng bất kỳ CI Plus CICAM với máy chủ này. Khi một hoặc nhiều nhãn định danh thương hiệu CICAM được quy định thì máy chủ chỉ phải hoạt động với thiết bị CI Plus CICAM có cicamBrandld của giấy chứng nhận thiết bị phù hợp với cicam_brand_identifier. Nếu không có các cicam_brand_identifier hiện có phù hợp với giấy chứng nhận thiết bị CICAM thì CICAM phải ngăn chặn dịch vụ này. Giá trị cicam_brand_identifier là 0x0000 được dự phòng và không được sử dụng.

private_data_byte: Trường này được bao gồm dành cho các phần mở rộng trong tương lai đối với việc ngăn chặn dịch vụ của máy chủ. Đối với tiêu chuẩn này là không xác định và nếu có trường này phải bị bỏ qua.

10.1.1.2. Nhãn mô tả của nhãn quy định dữ liệu riêng

...

...

...

10.2. Tiếp nhận tin cậy

Máy chủ phải có hai chế độ định tuyến dòng truyền tải CICAM:

1) chế độ by-pass; MPEG-2 TS phải được định tuyến trực tiếp đến Bộ giải ghép kênh máy chủ.

2) chế độ pass-through; MPEG-2 TS được định tuyến thông qua CICAM đến Bộ giải ghép kênh máy chủ.

Có hai chế độ nhận được tin cậy dành cho việc nhận SDT Actual. Trường hợp đầu tiên là trường hợp một hoặc nhiều CICAM không tuân thủ CI Plus được ghép vào máy chủ; trong trường hợp này, máy chủ phải nhận được MPEG2 TS trong chế độ by-pass để xác định xem việc được CI Plus bảo vệ có được yêu cầu dành cho dịch vụ này. Điều này được yêu cầu vì dữ liệu truyền thông qua CICAM không tuân thủ CI Plus là không đáng tin cậy.

Trường hợp thứ hai là trường hợp mà máy chủ chỉ có một CI Plus CICAM được ghép; trong trường hợp này, máy chủ sử dụng.

Trong khi nhận được MPEG-2 TS ở một trong hai phương thức nhận được tin cậy, máy chủ phải cố gắng để có được SDT_Actual. Nếu máy chủ nhận được MPEG-2 TS nhưng SDT_Actual không nhận được thì sau 5 giây, máy chủ có thể chuyển sang hoạt động ngăn chặn dịch vụ. Máy chủ phải nhận được MPEG- TS hợp lệ trước khi khởi tạo bộ đếm 5 giây để xác định xem SDT_Actual không tồn tại.

Khái niệm hoạt động của phần cứng dành cho chế độ by-pass của máy chủ và chế độ pass-through của CICAM được mô tả trong hình 10.1. Hình 10.1 xem nguồn dòng truyền tải có thể chuyển dưới sự kiểm soát của máy chủ. Hình này có tính tham khảo và các giải pháp phần cứng khác có thể được sử dụng để tạo ra hoạt động tương tự.

...

...

...

Việc thông báo dịch vụ được CI Plus bảo vệ của một dịch vụ là gần tĩnh và trạng thái CI Plus có thể được máy chủ lưu trữ. Máy chủ phải định kỳ xác nhận lại trạng thái dịch vụ CI Plus bằng cách kiểm tra SDT_Actual sử dụng chế độ nhận được tin cậy.

Nếu máy chủ lưu trữ việc thông báo dịch vụ được CI Plus bảo vệ thì nó chỉ phải lưu trữ trong khoảng thời gian tối đa là 7 ngày, sau đó dữ liệu này phải bị xóa và làm mới lại bằng cách thu nhận SDT_Actual phù hợp. Việc lưu trữ 7 ngày chỉ ra rằng một máy chủ có thể mất đến 7 ngày để phản ứng với sự thay đổi trạng thái CI Plus trong mạng.

10.3. Chế độ dịch vụ được CI Plus bảo vệ

Các chế độ dịch vụ được CI Plus bảo vệ được định nghĩa là:

Bảng 10.2 - Các chế độ dịch vụ được CI Plus bảo vệ

Thông báo

Loại CICAM

Chế độ hoạt động ngăn chặn dịch vụ

ci_protection_descriptor không sẵn có (Xem CHÚ THÍCH 1)

...

...

...

không hoạt động

ci_protection_descriptor sẵn có và free_CI_mode là “0”

DVB CI và CI Plus

không hoạt động

ci_protection_descriptor sẵn có và free_CI_mode là “1”

DVB CI

hoạt động

ci_protection_descriptor sẵn có, free_CI_mode là "1" và match_brand_flag là "0" hoặc number_of_entries là "0"

CI Plus

...

...

...

ci_protection_descriptor sẵn có, free_CI_mode là "1", match_brand_flag = "1" và number_of_entries ≠ "0" và nhãn nhận dạng thương hiệu CICAM không giống

CI Plus

hoạt động

ci_protection_descriptor sẵn có, free_CI_mode là "1", match_brand_flag = “1” và number_of_entries ≠ "0" và nhãn nhận dạng thương hiệu CICAM giống nhau

CI Plus

không hoạt động

CHÚ THÍCH:

1. Không thu được SDT_Actual trong chế độ nhận được tin cậy thì máy chủ có thể xem là ci_protection_descriptor không sẵn có và chế độ hoạt động ngăn chặn dịch vụ không hoạt động

10.4. Ngăn chặn dịch vụ

...

...

...

Bất cứ khi nào máy chủ đang hoạt động (1) và lựa chọn một dịch vụ bất kỳ nào (2). Máy chủ kiểm tra xem dữ liệu thông báo dịch vụ được CI Plus bảo vệ được lưu trữ có tồn tại (3). Nếu không máy chủ chuẩn bị việc kiểm tra ngăn chặn của máy chủ và không được yêu cầu CICAM giải xáo trộn dịch vụ (4). Máy chủ chuyển sang chế độ nhận được tin cậy và thu nhận SDT_Actual và xác định trạng thái ngăn chặn của máy chủ có sử dụng nhãn mô tả được CI bảo vệ nếu có (5). Máy chủ cố gắng để có được SDT_Actual. Nếu không có được SDT_Actual sau 5 giây thì việc ngăn chặn dịch vụ được hoạt động (6). Máy chủ kiểm tra xem trạng thái ngăn chặn dịch vụ có đang hoạt động (7). Nếu CI_protection_descriptor không tồn tại hoặc (nếu có) free_CI_mode_flag được thiết lập là "0" thì ngăn chặn dịch vụ là chưa hoạt động (8). Nếu nhãn mô tả được CI bảo vệ tồn tại và các free_CI_mode_flag thiết lập là “1” thì máy chủ phải tiếp tục kiểm tra xem dữ liệu thương hiệu có tồn tại (9). Nếu match_brand_flag được thiết lập là "0" hoặc list_length được thiết lập là 0 (không) thì máy chủ xác định rằng dữ liệu thương hiệu không tồn tại và tiếp tục kiểm tra xem CICAM có hoạt động trong một chế độ CI Plus (10). Nếu CICAM đang hoạt động trong chế độ CI Plus thì chưa kích hoạt ngăn chặn dịch vụ dành cho dịch vụ này (11), CICAM đang hoạt động trong một chế độ không tuân thủ CI Plus thì việc ngăn chặn dịch vụ được kích hoạt dành cho dịch vụ này (12). Tuy nhiên, nếu trong bước 9, match_brand_flag là “1” và list_length không bằng "0" thì máy chủ kiểm tra xem nhãn định danh của CICAM và cicam_brand_identifier được dịch vụ này thông báo có phù hợp (13), nếu nhãn định danh này không phù hợp thì ngăn chặn dịch vụ được hoạt động (12). Nếu một cicam_brand_identifier phù hợp với CICAM thì ngăn chặn dịch vụ chưa hoạt động (14).

10.4.1. Ngăn chặn dịch vụ chưa hoạt động

Ngăn chặn dịch vụ chưa hoạt động là điều kiện mà CICAM hoạt động hoặc hiện tại được phép giải xáo trộn dịch vụ này. Trong trường hợp này, dịch vụ có thể cho phép các DVB CICAM hoặc CICAM hiện tại tuân thủ CI Plus và brand_identifier phù hợp với các yêu cầu hoạt động của dịch vụ này (nếu có thể áp dụng). Xem hình 10.2 để biết thêm về ngăn chặn dịch vụ chưa hoạt động.

Khi trong chế độ hoạt động ngăn chặn dịch vụ chưa hoạt động, yêu cầu máy chủ thu nhận SDT_Actual phù hợp từ dòng truyền tải để có được trạng thái hoạt động CI Plus nếu có bất kỳ trạng thái CI Plus lưu trữ cũ hơn 7 ngày, điều này có thể yêu cầu máy chủ để làm gián đoạn dịch vụ hiện đang được xem.

10.4.2. Ngăn chặn dịch vụ hoạt động

Ngăn chặn dịch vụ hoạt động là điều kiện mà CICAM hoạt động hoặc hiện tại không được phép giải xáo trộn dịch vụ này. Trong trường hợp này, CICAM có thể không tuân thủ CI Plus hay thương hiệu CICAM không phù hợp với thông báo của dịch vụ này. Việc ngăn chặn dịch vụ cũng có thể được kích hoạt tạm thời khi máy chủ thực hiện việc nhận SDT tin cậy và thu nhận nhãn mô tả được CI bảo vệ dành cho dịch vụ được lựa chọn. Xem hình 10.2 để biết thêm về ngăn chặn dịch vụ hoạt động.

Máy chủ phải thực hiện việc ngăn chặn dịch vụ bằng cách khởi tạo chế độ by-pass. Nếu TS vẫn được định tuyến đến CICAM trong chế độ này thì máy chủ không được gửi CA_PMT đến CICAM.

Khi trạng thái ngăn chặn thay đổi "hoạt động" sang "chưa hoạt động" thì máy chủ phải gửi ngay lập tức CA_PMT đến CICAM.

...

...

...

CHÚ THÍCH 2: Việc kiểm tra ở bước (9) là kiểm tra xem trường “match_brand_flag” có là 1 và trường “brand_identifier_length” có lớn hơn 0 (không) ?

Hình 10.2 - Hoạt động ngăn chặn

11. Giao diện lệnh

Phần này giải thích các tài nguyên mới trong CI Plus. Những thay đổi đối với tài nguyên thông tin ứng dụng hiện tại cũng được bao gồm trong phần này.

11.1. Tài nguyên thông tin ứng dụng

11.1.1. Thông tin ứng dụng phiên bản 3

Tài nguyên thông tin ứng dụng phiên bản 3 (xem Bảng L1 trong Phụ lục L dành cho ID của tài nguyên) bổ sung các lệnh mới dành cho việc thiết lập lại CICAM và các giới hạn của tốc độ dữ liệu bus của PCMCIA của máy chủ.

11.1.2. Yêu cầu thiết lập lại CICAM

Khi một điều kiện xảy ra yêu cầu CICAM phải thiết lập lại CICAM về mặt vật lý thì CICAM phải gửi request_cicam_reset APDU.

...

...

...

Khi nhận được yêu cầu này, máy chủ phải thiết lập lại CICAM trong vòng 10 giây. Sau khi gửi lệnh request_cicam_reset, CICAM không được gửi bất kỳ APDU khác đến máy chủ.

Bảng 11.1 - Cú pháp của APDU yêu cầu thiết lập lại CICAM

Cú pháp

Số bit

Kiểu

request_cicam_reset() { request_cicam_reset_tag
length_field() = 0
}

24

uimsbf

request_cicam_reset_tag: Giá trị của thẻ này có thể được tìm thấy trong Bảng L.1 tại Phụ lục L.

...

...

...

Lưu ý: CICAM cũng có thể yêu cầu giao diện vật lý được khởi tạo lại bằng cách sử dụng bit IIR của thanh ghi trạng thái. Việc hỗ trợ đối với bit IIR là tùy chọn trong CI Plus và được giải thích trong phần sau.

11.1.2.2. Yêu cầu thiết lập lại bằng cách sử dụng bit IIR

Bit bổ sung được gọi là IIR (yêu cầu khởi tạo giao diện) được thêm vào thanh ghi trạng thái, xem bảng 11.2 dưới đây. CICAM thiết lập bit này để yêu cầu thiết lập lại giao diện vật lý. Sau khi thiết lập bit IIR này, CICAM không được gửi bất kỳ APDU khác đến máy chủ. CICAM xóa bit IIR khi máy chủ thiết lập bit RS trong khi thiết lập lại.

Bảng 11.2 - Thanh ghi trạng thái bao gồm IIR

Bit

7

6

5

4

...

...

...

2

1

0

DA

FR

R

IIR

R

...

...

...

WE

RE

Lưu ý: các bit DA, FR, WE và RE là không thay đổi, xem EN 50221 [7], phụ lục A.2.2.1.

11.1.3. Tốc độ dữ liệu trên bus PCMCIA

Tiêu chuẩn này hỗ trợ hai tốc độ dữ liệu khác nhau trên bus PCMCIA: 72 Mbit/s và 96 Mbit/s. CICAM phải hỗ trợ 96 Mbit/s. Máy chủ phải hỗ trợ 72 Mbit/s, việc hỗ trợ đối với 96 Mbit/s là tùy chọn.

11.1.3.1. data_rate_info APDU

Máy chủ gửi một data_rate_info APDU để thông báo cho CICAM về tốc độ dữ liệu tối đa mà nó hỗ trợ. Thông thường, data_rate_info APDU được gửi sau các bản tin application_info_enq và application_info khởi tạo. CICAM không được vượt quá tốc độ dữ liệu đầu ra 72 Mbit/s cho đến khi nó đã nhận được một bản tin data_rate_info từ máy chủ. Nếu data_rate_info APDU không được máy chủ gửi thì tốc độ dữ liệu tối đa được máy chủ hỗ trợ là 72 Mbit/s.

Bảng 11.3 - Cú pháp data_rate_info APDU

Cú pháp

...

...

...

Kiểu

data_rate_info() {

data_rate_info_tag

24

uimsbf

length_field() = 1

...

...

...

data_rate

8

uimsbf

}

data_rate_info: Giá trị của thẻ này là 0x9F8024.

data_rate: Giá trị này xác định tốc độ dữ liệu tối đa PCMCIA được máy chủ hỗ trợ. Bảng 11.4 liệt kê các giá trị có thể.

Bảng 11.4 - Các giá trị có thể dành cho data_rate

...

...

...

Giá trị

72 Mbit/s

00

96 Mbit/s

01

Dự phòng

các giá trị khác

11.2. Tài nguyên ngôn ngữ và quốc gia của máy chủ

Máy chủ sử dụng tài nguyên ngôn ngữ và quốc gia của máy chủ để thông báo cho CICAM về các thiết lập ngôn ngữ và quốc gia hiện nay của nó. CICAM có thể thiết lập ngôn ngữ của trình đơn của nó để thể hiện thiết lập này của máy chủ.

...

...

...

11.2.1. Các APDU dành cho tài nguyên ngôn ngữ và quốc gia của máy chủ

Các APDU sau đây được tài nguyên ngôn ngữ và quốc gia của máy chủ sử dụng. Chúng được giải thích chi tiết trong các phần tiếp theo.

Bảng 11.5 - Các APDU dành cho tài nguyên ngôn ngữ và quốc gia của máy chủ

TÊN APDU

Chiều

Host_country_enq

CICAM à HOST

Host_country

CICAM ß HOST

...

...

...

CICAM à HOST

Host_language

CICAM ß HOST

11.2.1.1. host_country_enq APDU

CICAM gửi APDU này đến máy chủ để truy vấn thiết lập về quốc gia hiện tại. Máy chủ trả lời bằng một host_country APDU.

Bảng 11.6 - Cú pháp host_country_enq APDU

Cú pháp

Số bit

Kiểu

...

...

...

24

uimsbf

host_country_enq_tag: xem Bảng L.1, Phụ lục L.

11.2.1.2. host_country APDU

Máy chủ gửi APDU này để thông báo cho CICAM thiết lập về quốc gia hiện tại của máy chủ. Nó được gửi để trả lời cho host_country_enq từ CICAM.

Máy chủ cũng gửi APDU này không đồng bộ khi có sự thay đổi về quốc gia của nó.

Khi mở tài nguyên ngôn ngữ và quốc gia của máy chủ, máy chủ gửi một host_country APDU đến CICAM để truyền thiết lập hiện tại này của máy chủ.

Bảng 11.7 - Cú pháp host_country APDU

Cú pháp

...

...

...

Kiểu

Host_country() {
Host_country_tag
length_field() = 3
iso_3166_country_code
}

24

24

uimsbf

bslbf

host_country_tag: xem Bảng L.1, Phụ lục L.

iso_3166_country_code: Trường này chứa thiết lập về quốc gia hiện tại của máy chủ. Mã quốc gia là một trường 24-bit xác định quốc gia của máy chủ sử dụng 3 ký tự viết hoa theo quy định của tiêu chuẩn TCVN 7217-1:2007 [17]. Mỗi ký tự được mã hóa 8-bit theo tiêu chuẩn ISO 8859-1 [15].

Chú ý: Máy chủ có thể truyền một mã quốc gia mà CICAM không hỗ trợ hoặc nhận ra, việc xử lý trạng thái này tùy thuộc vào CICAM. CICAM có thể sử dụng MMI để lựa chọn một tùy chọn phù hợp.

11.2.1.3. host_language_enq APDU

CICAM gửi APDU này đến máy chủ để truy vấn thiết lập về ngôn ngữ hiện tại. Máy chủ trả lời bằng một host_language APDU.

...

...

...

Cú pháp

Số bit

Kiểu

Host_language_enq() {
Host_language_enq_tag
length_field() = 0
}

24

uimsbf

host_language_enq_tag: xem Bảng L.1, Phụ lục L.

11.2.1.4. host_language APDU

Máy chủ gửi APDU này để thông báo cho CICAM thiết lập về ngôn ngữ hiện tại của máy chủ. Nó được gửi để trả lời cho một host_language_enq từ CICAM.

...

...

...

Khi mở tài nguyên ngôn ngữ và quốc gia của máy chủ, máy chủ gửi một host_language APDU đến CICAM để truyền thiết lập về ngôn ngữ hiện tại của máy chủ.

Bảng 11.9 - Cú pháp host_language APDU

Cú pháp

Số bit

Kiểu

Host_language() {
Host_language_tag
length_field() = 3
iso_639.2_language_code
}

24

24

uimsbf

bslbf

host_language_tag: xem Bảng L.1, Phụ lục L.

...

...

...

Chú ý: Máy chủ có thể truyền một mã ngôn ngữ mà CICAM không hỗ trợ hoặc nhận ra, việc xử lý trạng thái này tùy thuộc vào CICAM. CICAM có thể sử dụng MMI để lựa chọn một tùy chọn phù hợp.

11.3. Tài nguyên kiểm soát nội dung

Tài nguyên kiểm soát nội dung (CC) thực hiện các giao thức bảo mật của CI Plus như xác thực, tính mã khóa và truyền URI.

Các tài nguyên CC được máy chủ cung cấp. CICAM có thể yêu cầu một phiên dành cho tài nguyên CC chỉ khi máy chủ đã thông báo tài nguyên CC này trong giao thức quản lý tài nguyên (xem EN 50221 [7], điều 8.4.1.1). Máy chủ chỉ phải hỗ trợ một phiên dành cho tài nguyên CC đối với mỗi khe CI Plus.

ID của tài nguyên đối với tài nguyên CC được liệt kê trong Bảng L.1, Phụ lục L.

11.3.1. Các APDU dành cho tài nguyên kiểm soát nội dung

Phần này mô tả cấu trúc chung của mỗi APDU của tài nguyên CC. Điều 5 giải thích cách sử dụng các bản tin này để thực hiện các giao thức bảo mật của CI Plus.

Bảng 11.10 là một tổng quan về các APDU được tài nguyên CC sử dụng.

Bảng 11.10- Các giá trị thẻ của APDU dành cho kiểm soát nội dung

...

...

...

Chiều

APDU được sử dụng để

cc_open_req

CICAM => HOST

Đánh giá nội dung của máy chủ

cc_open_cnf

CICAM <= HOST

Đánh giá nội dung của máy chủ

cc_data_req

...

...

...

Xác thực

Kiểm tra khóa xác thực

Tính khóa SAC

cc_data_cnf

CICAM <= HOST

Xác thực

Kiểm tra khóa xác thực

Tính khóa SAC

cc_sync_req

...

...

...

Tính khóa SAC

cc_sync_cnf

CICAM <= HOST

Tính khóa SAC

cc_sac_data_req

CICAM <=> HOST

Tính khóa CC

Truyền và xác nhận URI

Thương lượng phiên bản URI

...

...

...

Trao đổi giấy phép nội dung

cc_sac_data_cnf

CICAM  <=> HOST

Tính khóa CC

Truyền và xác nhận URI

Thương lượng phiên bản URI

Truyền và xác nhận SRM

Trao đổi giấy phép nội dung

cc_sac_sync_req

...

...

...

Tính khóa CC

cc_sac_sync_cnf

CICAM <= HOST

Tính khóa CC

cc_PIN_capabilities_req

CICAM <= HOST

Máy chủ yêu cầu các khả năng PIN của CICAM

cc_PIN_capabilities_reply

CICAM => HOST

...

...

...

cc_PIN_cmd

CICAM <= HOST

Chuyển mã PIN sang CICAM

cc_PIN_reply

CICAM => HOST

Trả lại trạng thái mã PIN

cc_PIN_event

CICAM => HOST

Báo máy chủ biết PIN được yêu cầu

...

...

...

CICAM <= HOST

Cung cấp một PIN chơi lại cho CICAM

cc_PIN_MMI_req

CICAM <= HOST

Yêu cầu một thảo luận PIN

Cấu trúc chung của một APDU được mô tả trong EN 50221 [7], điều 8.3.1. Một APDU bắt đầu với một thẻ 24 bit theo sau là một trường độ dài được mã hóa theo ASN.1 BER.

Các giá trị thẻ của APDU dành cho tài nguyên kiểm soát nội dung được đưa ra trong Bảng L.1, Phụ lục L.

11.3.1.1. cc_open_req APDU

CICAM gửi APDU này để yêu cầu bitmask của các ID của hệ thống CC được máy chủ hỗ trợ.

...

...

...

Cú pháp

Số bit

Kiểu

cc_open_req() {
cc_open_req_tag
length_field()=0
}

24

Uimsbf

cc_open_req_tag: xem Bảng L.1, Phụ lục L.

11.3.1.2. cc_open_cnf APDU

Máy chủ gửi APDU này cho CICAM để thông báo cho nó về ID của hệ thống CC mà nó hỗ trợ.

...

...

...

Cú pháp

Số bit

Kiểu

cc_open_cnf() {
cc_open_cnf_tag
length_field()
cc_system_id_bitmask
}

24

8

uimsbf

bslbf

cc_open_cnf_tag: xem Bảng L.1, Phụ lục L.

cc_system_id_bitmask: Mỗi bit trong số 8 bit này chỉ ra sự hỗ trợ dành cho một phiên bản của hệ thống CC. CICAM có thể lựa chọn phiên bản phổ biến nhất được hỗ trợ ở cả hai đầu. Bit ít quan trọng nhất là dành cho phiên bản 1, không có phiên bản 0.

Tiêu chuẩn này mô tả phiên bản 1 của CC, không phụ thuộc vào nội dung của phiên bản cc_resource. Máy chủ và CICAM phải luôn luôn thực hiện một phép toán kiểm tra trên trường này chứ không phải là so sánh đơn giản.

...

...

...

Bản tin cc_data_req được CICAM sử dụng để truyền dữ liệu liên quan đến giao thức đến máy chủ và để yêu cầu máy chủ trả lời. Dữ liệu được gửi và được yêu cầu dành cho mỗi giao thức được giải thích trong điều 11.3.2. cc_data_req được sử dụng dành cho dữ liệu không cần phải được xác thực hoặc mã hóa. Đối với dữ liệu phải được xác thực hoặc mã hóa thì sử dụng cc_sac_data_req.

Bảng 11.13 - Cú pháp APDU của bản tin cc_data_req

cc_data_req_tag: xem Bảng L.1, Phụ lục L.

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin

datatype_id: xem Bảng H.1, Phụ lục H, dành cho các giá trị có thể

datatype_length: giá trị này là độ dài của data_type để gửi tính theo byte

datatype: trường này được sử dụng dành cho nội dung của datatype_id.

...

...

...

datatype_id: danh sách các mục dữ liệu được yêu cầu trong trả lời của máy chủ, xem Bảng H.1, Phụ lục H.

11.3.1.4. cc_data_cnf APDU

Bản tin cc_data_cnf được máy chủ gửi để truyền dữ liệu liên quan đến giao thức đến CICAM. Dữ liệu chính xác với các giao thức này được quy định trong điều 5.

cc_data_cnf được sử dụng dành cho dữ liệu không cần phải được xác thực hoặc mã hóa. Nếu điều này được yêu cầu thì sử dụng cc_sac_data_cnf.

Bảng 11.14 - Cú pháp cc data_cnf APDU

cc_data_cnf_tag: xem Bảng L.1, Phụ lục L.

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin này datatype_id: xem Bảng H.1 (phụ lục H) dành cho các giá trị có thể

...

...

...

data_type: phần dữ liệu thực tế

11.3.1.5. cc_sync_req APDU

Đối tượng APDU này được CICAM gửi vào phần cuối của quá trình tính mã khóa để thông báo rằng việc sử dụng mã khóa mới được tính đã sẵn sàng.

Bảng 11.15 - Cú pháp cc_sync_req APDU

Cú pháp

Số bit

Kiểu

cc_sync_req() {
cc_sync_req_tag
length_field()=0
}

24

...

...

...

cc_sync_req_tag: xem Bảng L.1, Phụ lục L.

11.3.1.6. cc_sync_cnf APDU

APDU này là trả lời của máy chủ đối với cc_sync_req, nó thông báo rằng máy chủ đã hoàn thành việc tính mã khóa của nó. Để biết chi tiết, xem điều 11.3.2 bên dưới.

Bảng 11.16 - Cú pháp cc_sync_cnf APDU

Cú pháp

Số bit

Kiểu

cc_sync_cnf() {
cc_sync_cnf_tag
length_field()=1
status_field
}

24

...

...

...

uimsbf

uimsbf

cc_sync_cnf_tag: xem Bảng L.1, Phụ lục L.

status_field: byte này trả về trạng thái của máy chủ. Bảng 11.17 liệt kê các giá trị có thể.

Bảng 11.17 - Các giá trị có thể dành cho status_field

status_field

Giá trị

OK

0x00

...

...

...

0x01

Host Busy

0x02

Authentication failed

0x03

CICAM Busy

0x04

Recording Mode error

0x05

...

...

...

0x06-0xFF

11.3.1.7. cc_sac_data_req APDU

APDU này được máy chủ và CICAM sử dụng để gửi dữ liệu của giao thức cụ thể và để yêu cầu một trả lời. Ngược lại với cc_data_req, dữ liệu được chứa trong bản tin này được xác thực và mã hóa. SAC đóng gói dữ liệu đầu vào theo quy định trong Bảng 11.19 thành tải trong bản tin SAC.

Bảng 11.18 - Cú pháp cc_sac_data_req APDU

Cú pháp

Số bit

Kiểu

cc_sac_data_req() {
cc_sac_data_req_tag
length_field()
sac_message()
}

24

...

...

...

cc_sac_data_req_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bảng 7.4. payload_encryption_flag phải là 1.

Tải của bản tin SAC này được định nghĩa trong Bảng 11.19. Để biết thêm chi tiết, xem điều 11.3.3.

Bảng 11.19 - Tải cc_sac_data_req

Cú pháp

Số bit

Kiểu

cc_system_id_bitmask
send_datatype_nbr
for (i=0; i<send_datatype_nbr; i++) {
datatype_id
datatype_length
data_type
}
request_datatype_nbr
for (i=0; i<request_datatype_nbr; i++) {
datatype_id
}

8
8

8
16
8*datatype_length

8

8

...

...

...

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin này

datatype_id: xem Bảng H.1, Phụ lục H, dành cho các giá trị có thể

datatype_length: độ dài của dữ liệu tính theo byte

data_type: dữ liệu bản tin

request_datatype_nbr: số các mục dữ liệu mà máy chủ phải bao gồm trong trả lời đối với bản tin này

datatype_id: danh sách các mục dữ liệu được yêu cầu trong trả lời của máy chủ, xem Bảng H.1, Phụ lục H.

11.3.1.8. cc_sac_data_cnf APDU

Máy chủ và CICAM sử dụng bản tin này để gửi dữ liệu của giao thức cụ thể để trả lời đối với cc_sac_data_req () khi dữ liệu phải được xác thực và mã hóa. Điều 7 mô tả chi tiết về dữ liệu của giao thức được truyền trong mỗi bản tin. SAC đóng gói dữ liệu đầu vào này theo quy định trong Bảng 11.21 thành tải trong bản tin SAC.

...

...

...

Cú pháp

Số bit

Kiểu

cc_sac_data_cnf() {
cc_sac_data_cnf_tag
length_field()
sac_message()
}

24

uimsbf

cc_sac_data cnf_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bảng 7.4. payload_encryption_fIag phải là 1.

Tải của các bản tin SAC được quy định trong Bảng 11.21. Để biết thêm chi tiết, xem điều 11.3.2.

...

...

...

Cú pháp

Số bit

Kiểu

cc_system_id_bitmask
send_datatype_nbr
for (i=0; i<send_datatype_nbr; i++) {
datatype_id
datatype_length
data_type
}

8
8

8
16
8*datatype_length

bslbf
uimsbf

uimsbf
uimsbf
bslbf

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin này

data_type_id: xem Bảng H.1, Phụ lục H, dành cho các giá trị có thể

...

...

...

data_type: phần dữ liệu thực tế

11.3.1.9. cc_sac_sync_req APDU

APDU này được sử dụng trong quá trình tính mã khóa CC. CICAM gửi APDU này để chỉ ra rằng nó đã hoàn thành việc tính mã khóa CC mới.

Bảng 11.22 - Cú pháp cc_sac_sync_req APDU

Cú pháp

Số bit

Kiểu

cc_sac_sync_req() {
cc_sac_sync_req_tag
length_field()
sac_message()
}

24

...

...

...

cc_sac_sync_req_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bảng 7.4.

payload_encryption_flagshall phải là 1. Tải của bản tin SAC này là trống.

11.3.1.10. cc_sac_sync_cnf APDU

APDU này được sử dụng trong quá trình tính mã khóa CC. Máy chủ sử dụng APDU này để trả lời đối với một cc_sac_sync_req từ CICAM.

Bảng 11.23 - Cú pháp cc_sac_sync_cnf APDU

Cú pháp

Số bit

Kiểu

...

...

...

24

8

uimsbf

uimsbf

cc_sac_sync_cnf_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bảng 7.4 payload_encryption_fIagshall phải là 1.

Tải của bản tin SAC này là một trường trạng thái. Các giá trị có thể dành cho status_field được liệt kê trong Bảng 11.27

Bảng 11.24 - Các trạng thái của cc_sac_sync_cnf

status_field

Giá trị

OK

...

...

...

Không hỗ trợ CC

0x01

Máy chủ bận

0x02

Không được yêu cầu

0x03

Dự phòng

0x04-0xFF

11.3.2. Các APDU dành cho PIN của tài nguyên kiểm soát nội dung

...

...

...

11.3.2.1. Các cc_PIN_capabilities APDU

Các cc_PIN_capabilities APDU cho phép máy chủ xác định cách quản lý các mã PIN kiểm soát của cha mẹ đối với nội dung FTA và CICAM (được CAS kiểm soát).

Bảng 11.25 - Cú pháp cc_PIN_capabilities_req APDU

Cú pháp

Số bit

Kiểu

cc_PIN_capabilities_req() {
cc_PIN_capabilities_req_tag
length_field() = 0
}

24

uimsbf

...

...

...

Bảng 11.26 - Cú pháp cc_PIN_capabilities_reply APDU

Cú pháp

Số bit

Kiểu

cc_PIN_capabilities_reply() {
cc_PIN_capabilities_reply_tag
length_field()
capability_field
pin_change_time_utc
rating
}

24

8
40
8

uimsbf

uimsbf
bslbf
uimsbf

cc_PIN_capabilities_reply_tag: xem Bảng L.1 tại Phụ lục L.

capability_field: byte này trả về mã khả năng quản lý CICAM, xem Bảng 11.27.

...

...

...

capability_field

Giá trị

CICAM không có khả năng quản lý PIN

0x00

CICAM chỉ có thể quản lý PIN nội dung được điều khiển bởi CAS

0x01

CICAM có thể quản lý cả PIN nội dung được điều khiển bởi CAS và PIN nội dung không được điều khiển bởi PIN

0x02

CICAM chỉ có thể quản lý PIN nội dung không được điều khiển bởi CAS (với các PIN lưu trong CICAM)

...

...

...

CICAM có thể quản lý cả PIN nội dung được điều khiển bởi CAS và PIN nội dung không được điều khiển bởi PIN (với các PIN lưu trong CICAM)

0x04

Dự phòng

0x05-0xFF

Việc phân tích các giá trị capability_field được mô tả chi tiết hơn trong điều 5.11.1.

pin_change_time_utc: trả về thời gian khi CICAM PIN đã được thay đổi lần cuối. Đây là một trường 40-bit quy định ngày và thời gian theo MJD và UTC khi mã PIN đã được thay đổi lần cuối (Xem trường start_time của EIT trong EN 300 468 [10]). Trường này được mã hóa 40-bit với 16 LSB dành cho MJD và tiếp theo 24-bit được mã hóa thành 6 số theo mã 4-bit BCD. Trường này được quy định là không nếu PIN không được xử lý hoặc khi nó chưa bao giờ được thay đổi. Máy chủ có thể sử dụng "thời gian thay đổi" để cảnh báo người sử dụng cuối rằng bất kỳ việc ghi lại tự động được lập trình có thể bị thất bại khi nó đã được lập trình trước và lập lịch sau thời gian được trường pin_change_time_utc này quy định.

rating: trường 8-bit này được mã hóa theo đánh giá của DVB (độ tuổi 3+). Đánh giá này được định nghĩa trong nhãn mô tả đánh giá của cha mẹ EN 300 468 [10]. Đây là đánh giá hiện tại được thiết lập trong CICAM. Trường này cho phép máy chủ phát huy việc kiểm soát của cha mẹ khi đánh giá của máy chủ được thiết lập ở mức thấp hơn so với đánh giá của CICAM. Máy chủ có thể sử dụng cc_PIN_MMI_req () APDU dành cho mục đích này tùy thuộc vào các khả năng CICAM PIN. CICAM không được yêu cầu nhập PIN dành cho đánh giá độ tuổi thấp hơn giá trị này.

11.3.2.2. cc_PIN_cmd APDU

cc_PIN_cmd () APDU được máy chủ sử dụng để gửi CICAM PIN cho CIAM. CICAM PIN được CICAM xác nhận và cc_PIN_reply () APDU được gửi lại cho máy chủ. Máy chủ sử dụng trả lời này để kiểm tra xem CICAM PIN được lưu trữ của nó có đúng không.

...

...

...

Cú pháp

Số bit

Kiểu

cc_PIN_cmd() {
cc_PIN_cmd_tag
length_field()
for (i=0; i<n; i++) {
PINcode_data_bytes
}
}

24


8

uimsbf


uimsbf

cc_PIN_cmd_tag: xem Bảng L.1 tại Phụ lục L.

PINcode_data_bytes: tải dành cho mã PIN, một byte được sử dụng cho mỗi số của mã PIN theo định dạng ASCII.

11.3.2.3. cc_PIN_reply APDU

...

...

...

Bảng 11.29 - Cú pháp cc_PIN_reply APDU

Cú pháp

Số bit

Kiểu

cc_PIN_reply() {
cc_PIN_reply_tag
length_field()
PINcode_status_field
}

24

8

uimsbf

uimsbf

cc_PIN_reply_tag: xem Bảng L.1 tại Phụ lục L.

PINcode_status_field: byte này trả về trạng thái quản lý của CICAM đối với mã PIN, xem Bảng 11.30.

...

...

...

PINcode_status_field

Giá trị

Lỗi -Mã PIN không chính xác

0x00

Lỗi -CICAM đang bận

0x01

Mã PIN đúng

0x02

Mã PIN không được xác nhận

...

...

...

Không cần làm trống tín hiệu video

0x04

Dự phòng

0x05-0xFF

Các trường này được quy định như sau:

Error - Bad PIN code: PIN được người sử dụng đầu cuối nhập vào là không chính xác và CAS sẽ không giải xáo trộn nội dung.

Error - CICAM Busy: CICAM đang bận.

PIN code correct: xác nhận rằng mã PIN được cung cấp trước đó bằng cách sử dụng cc_PIN_cmd () APDU, giao thức khởi tạo ghi lại, hoặc được người sử dụng cuối nhập vào, sử dụng MMI, là đúng.

PIN code unconfirmed: khi có nhiều hệ thống CA và không biết được hệ thống nào sẽ được sử dụng cho sự kiện được ghi lại này. Trả lời lỗi này xảy ra khi máy chủ gửi một cc_PIN_cmd () đến CICAM khi đang đăng ký việc ghi lại mà không biết hệ thống CA liên kết với sự kiện này. Máy chủ có thể tùy chọn thông báo cho người sử dụng rằng mã PIN được sử dụng để đăng ký việc ghi lại này chưa được CICAM kiểm tra.

...

...

...

11.3.2.4. cc_PIN_event APDU

cc_PIN_event () APDU được CICAM gửi để thông báo cho máy chủ khi yêu cầu PIN để giải xáo trộn chương trình được ghi lại và xác nhận mã PIN bằng cách sử dụng cc_PIN_event () với đánh giá độ tuổi trưởng thành này dành cho việc sử dụng trong quá trình phát lại.

CICAM phải gửi cc_PIN_event () APDU đến máy chủ bất cứ khi nào đánh giá của cha mẹ thay đổi, điều này bao gồm việc chuyển đổi của mã PIN được yêu cầu và mã PIN không còn được yêu cầu, tức là đánh giá của cha mẹ đã bị loại bỏ.

Lưu ý: Nếu CICAM đã thông báo khả năng mã PIN là "0", trong quá trình trao đổi cc_PIN_capabilities, xem điều 11.3.2.1 thì CICAM không được gửi cc_PIN_event () APDU đến máy chủ.

Bảng 11.31 - Cú pháp cc_PIN_event APDU

Cú pháp

Số bit

Kiểu

cc_PIN_event() {
cc_PIN_event_tag
length_field()
program_number
PINcode_status_field
rating

...

...

...

uimsbf

uimsbf
uimsbf
uimsbf

pin_event_time_utc
pin_event_time_centiseconds
private_data
}

40
8
8x15

uimsbf
uimsbf
uimsbf

cc_PIN_event_tag: xem Bảng L.1 tại Phụ lục L.

program_number: số chương trình của giao thức khởi tạo ghi lại có liên kết dành cho việc ghi lại này.

PINcode_status_field: trường 8-bit này trả về trạng thái của mã PIN được gửi trước đó theo quy định tại Bảng 11.30.

rating: trường 8-bit này được mã hóa theo đánh giá của DVB (độ tuổi 3+). Đánh giá này được định nghĩa trong nhãn mô tả đánh giá của cha mẹ EN 300 468 [10]. Nó thể hiện đánh giá của mục nội dung được phát do cc_PIN_event () APDU kích hoạt.

pin_event_time_utc: Trường này trả về thời gian khi đánh giá của cha mẹ thay đổi yêu cầu nhập vào số PIN. Đây là một trường 40-bit quy định ngày và thời gian theo MJD và UTC khi đánh giá của cha mẹ thay đổi (Xem trường start_time của EIT trong EN 300 468 [10]). Trường này được mã hóa 40-bit với 16 LSB dành cho MJD và tiếp theo 24-bit được mã hóa thành 6 số theo mã 4-bit BCD.

...

...

...

private_data: Các byte dữ liệu riêng cung cấp cho CICAM các tùy chọn để bao gồm thông tin đối với CAS cụ thể được lưu trữ và đánh giá độ tuổi trưởng thành trong quá trình ghi lại. private_data được trả về cho CICAM khi phát lại bằng cách sử dụng cc_PIN_playback () APDU.

11.3.2.5. cc_PIN_playback APDU

APDU này được gửi đến CICAM để trả lời một cc_PIN_event () APDU lúc bắt đầu phát lại và khi đánh giá của cha mẹ đối với nội dung thay đổi.

Bảng 11.32 - Cú pháp cc_PIN_playback APDU

Cú pháp

Số bit

Kiểu

cc_PIN_playback() {
cc_PIN_playback_tag
length_field()
rating
private_data
}

24

8
8x15

...

...

...

CC_PIN_ playback_tag: xem Bảng L.1 tại Phụ lục L.

rating: trường 8-bit này được mã hóa theo đánh giá của DVB (độ tuổi 3+). Đánh giá này được định nghĩa trong nhãn mô tả đánh giá của cha mẹ EN 300 468 [10].

private_data: Các byte này chứa dữ liệu riêng được truyền đến máy chủ trong cc_PIN_event () APDU.

11.3.2.6. cc_PIN_MMI_req APDU

APDU này được gửi đến CICAM để yêu cầu một MMI dành cho việc nhập mã PIN. Vòng PINcode_data_bytes cho phép máy chủ cung cấp CICAM FTA PIN (do máy chủ quản lý) hoặc CICAM PIN (do CICAM quản lý). Kết quả của việc nhập mã PIN được trả về cho máy chủ thông qua cc_PIN_reply () APDU. Xem điều 5.11.3.

Bảng 11.33 - Cú pháp cc_PIN_MMI_req APDU

Cú pháp

Số bit

Kiểu

...

...

...

24


8

uimsbf


uimsbf

cc_PIN_MMI_req_tag: xem Bảng L.1 tại Phụ lục L.

PINcode_data_bytes: Tải dành cho mã PIN, một byte được sử dụng cho mỗi số của mã pin theo định dạng ASCII.

11.3.3. Nội dung giao thức kiểm soát

Phần này giải thích tải của APDU dành cho mỗi giao thức bảo mật của CI Plus.

11.3.3.1. Đánh giá khả năng của máy chủ

Sau khi phiên dành cho tài nguyên CC đã được thành lập, CICAM yêu cầu bitmask của các ID của hệ thống CC mà máy chủ hỗ trợ. Nên lưu ý rằng máy chủ thông báo các phiên bản của tài nguyên kiểm soát nội dung được hỗ trợ bằng cách sử dụng quản lý tài nguyên và CICAM phải sử dụng tài nguyên kiểm soát nội dung có sẵn cao nhất được máy chủ thông báo khi thiết lập một phiên CC.

Bảng 11.34 - Đánh giá khả năng của máy chủ

...

...

...

Thực hiện

APDU

Nội dung

1

CICAM yêu cầu mặt nạ bit của ID hệ thống cc của máy chủ

cc_open_req

2

Máy chủ gửi mặt nạ bit của ID hệ thống CC của nó

...

...

...

cc_system_id_bitmask:

• bit 0 chỉ thị việc hỗ trợ CI Plus

11.3.3.2. Xác thực

Xác thực được mô tả trong điều 6.2 và tổng quan của nó được thể hiện trong hình 6.2, nó sử dụng các bản tin cc_data_req và cc_data_cnf.

Bảng 11.35 - Xác thực

Bước

Thực hiện

APDU

Nội dung

...

...

...

CICAM gửi một nonce tới máy chủ

cc_data_req

send_datatype_nbr =1

i

datatype_id

datatype_len

0

19(nonce)

256 bits

...

...

...

i

datatype_id

0

13 (DHPH)

1

17 (Signature_A)

2

15 (Host_DevCert)

3

...

...

...

2

Máy chủ gửi một nonce, mã khóa công khai DH, đóng dấu dữ liệu của giấy chứng nhận thiết bị máy chủ và giấy chứng nhận thương hiệu máy chủ

cc_data cnf

send_datatype_nbr =4

i

datatype_id

0

...

...

...

2048bits

1

17 (Signature_A)

2048bits

2

15 (Host_DevCert)

độ dài thay đổi được

3

7 (Host_BrandCert)

...

...

...

3

CICAM gửi mã khóa công khai DH, đóng dấu, dữ liệu của giấy chứng nhận thiết bị CICAM và giấy chứng nhận thương hiệu CICAM

cc_data_req

send_datatype_nbr =4

i

datatype_id

datatype_len

0

14 (DHPM)

...

...

...

1

18 (Signature_B)

2048bits

2

16 (CICAM_DevCert)

độ dài thay đổi được

3

8 (CICAM_BrandCert)

độ dài thay đổi được

...

...

...

30

status_field

4

Máy chủ gửi một xác nhận

cc_data_cnf

send_datatype_nbr =1

i

datatype_id

datatype_len

...

...

...

30(status_field)

(Xem CHÚ THÍCH 2)

8 bits

CHÚ THÍCH

1. Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2. Máy chủ có thể thiết lập là OK hoặc xác thực không thành công, xem Bảng 11.17

11.3.3.3. Kiểm tra mã khóa xác thực

Kiểm tra mã khóa xác thực được thực hiện lúc khởi tạo và sau khi hoàn thành giao thức xác thực (xem điều 6.2 và 11.3.3.2). CICAM kiểm tra xem cả hai phía có mã khóa xác thực được lưu trữ giống nhau (AKH và AKM).

Bảng 11.36 - Kiểm tra mã khóa xác thực

...

...

...

Thực hiện

APDU

Nội dung

1

CICAM yêu cầu mặt nạ bit của ID hệ thống CC của máy chủ

cc_open_req

2

Máy chủ gửi mặt nạ bit của ID hệ thống CC của nó

...

...

...

cc_system_id_bitmask:

• bit 0 chỉ thị việc hỗ trợ CI Plus

11.3.3.4. Tính mã khóa CC

Giao thức này được sử dụng để tính mã khóa CC mới, xem điều 8 để biết chi tiết.

Tất cả các bản tin của giao thức này được SAC bảo vệ.

Bảng 11.37 - Tính toán mã khóa CC

Bước

Thực hiện

APDU

...

...

...

1

CICAM gửi CICAM_ID và một nonce

cc_sac_data_req

send_datatype_nbr =3

i

datatype_id

datatype_len

0

6 (CICAM_ID)

...

...

...

1

12 (Kp)

256 bits

2

28 (keyregister)

8 bits

request_datatype_nbr = 2

i

datatype_id

...

...

...

5 (HOST_ID)

1

30 (Status_field)

2

Máy chủ trả lời bằng HOST_ID và một nonce

cc_sac_data_cnf

send_datatype_nbr = 2

i

datatype_id

...

...

...

0

5 (HOST_ID)

64 bits

1

30 (Status_field) (Xem CHÚ THÍCH 2)

8 bits

3

CICAM báo máy chủ biết đã hoàn thành tính mã khóa CC mới

cc_sac_sync_req

...

...

...

4

Máy chủ báo CICAM biết đã hoàn thành tính mã khóa CC mới

cc_sac_sync_cnf

Status_field (xem Bảng 11.17)

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Máy chủ có thể thiết lập giá trị là OK hoặc máy chủ bận hoặc không hỗ trợ CC, xem Bảng 11.17

3: Tất cả các bản tin SAC được mã hóa và xác thực

11.3.3.5. Tính mã khóa SAC

...

...

...

Bảng 11.38 - Tính mã khóa SAC

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi CICAM_ID và một nonce

cc_data_req

send_datatype_nbr = 2

...

...

...

datatype_id

datatype_len

0

6 (CICAM_ID)

64bits

1

21 (Ns_module)

64 bits

request_datatype_nbr = 2

...

...

...

datatype_id

0

5 (HOST_ID)

1

20 (Ns_Host)

2

Máy chủ trả lời băng HOST_ID và một nonce

cc_data_cnf

send_datatype_nbr = 2

...

...

...

datatype_id

datatype_len

0

5(HOST_ID)

64bits

1

20 (Ns_Host)

64 bits

3

...

...

...

cc_sync_req

4

Máy chủ báo CICAM biết đã hoàn thành tính mã khóa SAC mới

cc_sync_cnf

status_field (xem Bảng 11.20)

CHÚ THÍCH: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

11.3.3.6. Truyền và xác nhận URI

Giao thức này truyền tập tin các quy tắc sử dụng (URI) và thu xác nhận của máy chủ, xem điều 5.7.5.

...

...

...

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi URI

tới máy chủ

cc_sac_data_req

send_datatype_nbr = 2

...

...

...

datatype_id

datatype_len

0

25 (uri_message)

64 bits

1

26 (program_number)

16 bits

request_datatype_nbr = 1

...

...

...

datatype_id

0

27(uri_confirm)

2

Máy chủ gửi một xác nhận tới CICAM

cc_sac_data_cnf

send_datatype_nbr =1

i

datatype_id

...

...

...

0

27(uri_confirm)

256 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

11.3.3.7. Thương lượng phiên bản URI

Sau khi các mã khóa SAC đã được tính, CICAM yêu cầu một danh sách các phiên bản URI mà máy chủ hỗ trợ. Máy chủ gửi lại một bitmask các phiên bản. Mỗi bit tương ứng với một phiên bản và được thiết lập khi phiên bản này được hỗ trợ; bit ít quan trọng nhất chỉ ra sự hỗ trợ dành cho phiên bản 1. Bit quan trọng tiếp theo chỉ ra sự hỗ trợ cho phiên bản 2. Để biết thêm chi tiết, xem điều 5.7.4.

Bảng 11.40-Thương lượng phiên bản URI

...

...

...

Thực hiện

APDU

Nội dung

1

CICAM yêu cầu mặt nạ bit của các phiên bản URI được hỗ trợ từ máy chủ

cc_sac_data_req

request_datatype_nbr = 1

i

datatype_id

...

...

...

29(uri_versions)

2

Máy chủ gửi mặt nạ bit của các phiên bản URI được hỗ trợ

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

...

...

...

256 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

11.3.4. Trao đổi giấy phép nội dung

Khi một mục của nội dung được ghi lại có URI với giá trị EMI là 0b11, CICAM có thể tùy chọn cung cấp một giấy phép tại lúc ghi lại. Máy chủ phải kết hợp giấy phép này với mục của nội dung này dành cho thời gian sống của việc ghi lại. Nếu một giấy phép tồn tại dành cho một mục của nội dung thì giấy phép này phải được CICAM gốc kiểm tra bởi khi nội dung này được phát lại để xem nếu các quyền để xem nội dung vẫn còn tồn tại. Giấy phép được CICAM cung cấp chứa dữ liệu dành cho CAS cụ thể được máy chủ lưu trữ cùng với nội dung này. Khi mục của nội dung này được phát lại thì máy chủ phải truyền giấy phép này trở lại CICAM gốc mà không có bất kỳ thay đổi nào.

Các giấy phép luôn luôn được trao đổi thông qua SAC bằng cách sử dụng các giao thức dưới đây.

11.3.4.1. Giao thức trao đổi giấy phép từ CICAM đến máy chủ

Nếu yêu cầu một giấy phép liên kết với một mục của nội dung thì khi bắt đầu ghi lại, CICAM gửi cho chủ giấy phép này bằng cách sử dụng SAC. Quá trình này sử dụng giao thức trao đổi giấy phép từ CICAM đến máy chủ và trình bày sau đây bao gồm cả trả lời.

...

...

...

Bước

Thực hiện

APDU

Nội dung

1

CICAM cung cấp giấy phép nội dung cho máy chủ

cc_sac_data_req

send_datatype_nbr = 3 or 4

i

...

...

...

datatype_len

0

26 (program_number) (Xem CHÚ THÍCH 3)

16 bits

1

34 (license_status)(Xem CHÚ THÍCH 4)

8 bits

2

25 (uri_messaqe)

...

...

...

3

33 (cicam_license)

variable

request_datatype_nbr = 1

i

datatype_id

0

35(license_rcvd_status)

2

...

...

...

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype ten

0

35 (license_rcvd_status)(Xem CHÚ THÍCH 5)

8 bits

CHÚ THÍCH

...

...

...

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Giá trị program_number này trùng với giá trị program_number của bản tin Bắt đầu ghi

4: Bảng 11.45 chứa các giá trị cho phép vá ý nghĩa của trường này

5: Bảng 11.42 chứa các giá trị cho phép và ý nghĩa của trường này

Bảng 11.42 - Các giá trị license_rcvd_status

license_rcvd_status

Giá trị

OK

0x00

...

...

...

0x01

Dữ liệu không hợp lệ

0x02

Lỗi máy chủ

0x03

Dự phòng

0x04-0xFF

11.3.4.2. Giao thức trao đổi giấy phép phát lại

Khi một mục của nội dung được kết hợp với một giấy phép, tại lúc được phát lại, máy chủ phải cung cấp cho CICAM giấy phép gốc. CICAM xử lý giấy phép này để thiết lập xem máy chủ vẫn có quyền phát lại nội dung này. Một giấy phép và URI mới được trả về cho máy chủ để thay thế bản gốc trong trường hợp thông tin đã bị thay đổi, ví dụ như số lượt phát lại.

...

...

...

Bảng 11.43 - Giao thức trao đổi giấy phép phát lại

Bước

Thực hiện

APDU

Nội dung

1

Máy chủ cung cấp giấy phép CICAM

cc_sac_data_req

send_datatype_nbr = 2

...

...

...

datatype_id

datatype_len

0

26 (program_number)

16 bits

1

36(Host_license)

variable

request_datatype_nbr = 4

...

...

...

datatype_id

0

26 (program_number)

1

34 (license_status)

2

25 (uri_message)

3

33(cicam_license)

...

...

...

CICAM trả lời bằng giấy phép và URI mới

cc_sac_data_cnf

send_datatype_nbr = 4

i

datatype_id

datatype_len

0

26 (program_number)

16 bits

...

...

...

34 (license_status)(Xem CHÚ THÍCH 3)

8 bits

2

25 (uri_message)

64 bits

3

33 (cicam_license)

variable

CHÚ THÍCH:

...

...

...

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.45 chứa các giá trị cho phép và ý nghĩa của trường này

11.3.4.3. Giao thức trao đổi kiểm tra giấy phép

Khi máy chủ cần trao đổi với CICAM về trạng thái hiện tại của một giấy phép nội dung có liên kết với việc ghi lại thì nó thực hiện theo giao thức sau đây.

Trả lời từ CICAM chứa thông tin liên quan đến trạng thái của giấy phép đã được gửi trong yêu cầu. Trả lời này chỉ mang tính tham khảo, ví dụ như để cung cấp chi tiết hơn về nội dung sẵn có khi hiển thị một thư mục ghi lại.

Bảng 11.44 - Giao thức trao đổi kiểm tra giấy phép

Bước

Thực hiện

APDU

...

...

...

1

Máy chủ cung cấp giấy phép CICAM

cc_sac_data_req

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

36 (Host_license)

...

...

...

request_datatype_nbr = 2

i

datatype_id

0

34 (license_status)

1

37 (play_count)

2

CICAM trả lời bằng trạng thái giấy phép và play_count

...

...

...

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

34 (license_status) (Xem CHÚ THÍCH 3)

8 bits

1

37 (play_count)

...

...

...

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.45 chứa các giá trị cho phép và ý nghĩa của trường này

Bảng 11.45 - Các giá trị license_status

license_status

Giá trị

OK

0x00

...

...

...

0x01

Không thể giải xáo trộn, lỗi không xác định (chỉ ghi lại)

0x02

Các quyền sử dụng hết hạn (xem & kiểm tra trạng thái)

0x03

Số lượt phát lại vượt quá (xem & kiểm tra trạng thái)

0x04

Giới hạn lưu giữ vượt quá (xem & kiểm tra trạng thái)

0x05

...

...

...

0x06

Dự phòng

0x07-0xFF

11.3.4.4. Giao thức khởi tạo ghi lại

Máy chủ thông báo sự bắt đầu của một dịch vụ được CA bảo vệ ghi lại cho CICAM thông qua giao thức sau đây bằng cách sử dụng SAC. Việc trao đổi này cũng thông báo cho CICAM chế độ hoạt động hiện tại của máy chủ.

Trường hợp máy chủ là trong chế độ hoạt động "Unattended_Recording" hoặc "Watch_and_Buffer" thì tham số PINcode_data được sử dụng để cung cấp cho CICAM mã CICAM PIN. CICAM PIN chỉ phải được sử dụng để cho phép ghi lại tự động khi một sự kiện kiểm soát của cha mẹ trong tương lai có thể xảy ra. CICAM PIN không được sử dụng để thực hiện việc kiểm soát của cha mẹ khi phát lại và xem trực tiếp; trong trường hợp này phải yêu cầu người sử dụng nhập CICAM PIN bằng MMI cấp cao hoặc ứng dụng.

Bảng 11.46 - Giao thức khởi tạo ghi lại

Bước

Thực hiện

...

...

...

Nội dung

1

Máy chủ thông báo cho CICAM bắt đầu ghi lại

cc_sac_data_req

send_datatype_nbr = 2 or 3

i

datatype_id

datatype_len

0

...

...

...

8 bits

1

26 (program_number)

16 bits

2

39 (PINcode data)

variable (tùy chọn)

request_datatype_nbr = 1

i

...

...

...

0

40 (record_start_status)

2

CICAM gửi xác nhận đến máy chủ

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

...

...

...

40 (record_start_status) (Xem CHÚ THÍCH 4)

8 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.47 chứa các giá trị cho phép và ý nghĩa của trường này

4: Bảng 11.17 chứa các giá trị cho phép của trường này

Bảng 11.47 - Các giá trị operating_mode

operating mode

...

...

...

Xem và đệm (Watch_and_Buffer)

0x00

Chế độ tạm dừng (Timeshift)

0x01

Ghi laji tự động (Unattended_Recording)

0x02

Dự phòng

0x03-0xFF

Các chế độ hoạt động này được mô tả như sau:

...

...

...

PINcode_status_field là "0x02".

Timeshift - người sử dụng đang xem nội dung được ghi lại trước đó trong khi máy chủ tiếp tục ghi lại nội dung trực tiếp. CICAM không được cung cấp một MMI dành cho việc nhập CICAM PIN và phải sử dụng CICAM PIN được lưu trữ để tiếp tục giải xáo trộn nội dung được ghi lại tự động. Máy chủ phải sử dụng cc_PIN_playback () APDU khi xem nội dung được ghi lại và lưu trữ để thông báo cho CICAM đánh giá độ tuổi trưởng thành đối với nội dung đang được phát lại. Máy chủ phải làm trống video và âm thanh cho đến khi nhận cc_PIN_reply () APDU có PINcode_status_field là "0x02".

Unattended_Recording - người sử dụng đã lập lịch cho máy chủ ghi lại nội dung trong một chế độ tự động. Trước khi lập lịch ghi lại, máy chủ có thể xác nhận CICAM PIN được lưu trữ bằng cách sử dụng cc_PIN_cmd () APDU. Tại lúc bắt đầu ghi lại, máy chủ gửi CICAM PIN trong bản tin khởi tạo ghi lại đến CICAM. Trong quá trình ghi lại, CICAM thông báo cho máy chủ về trạng thái độ tuổi trưởng thành bằng cách sử dụng cc_PIN_event () APDU để máy chủ sử dụng khi phát lại.

11.3.4.5. Giao thức chế độ hoạt động thay đổi

Giao thức sau đây được sử dụng khi máy chủ thay đổi chế độ hoạt động và được so sánh với bản tin khởi tạo ghi lại. Bản tin chế độ hoạt động thay đổi được sử dụng trong trường hợp không có giấy phép mới ví dụ như chế độ hoạt động thay đổi từ "Watch_and_Buffer" sang "Timeshift".

Bảng 11.48 - Giao thức chế độ hoạt động thay đổi

Bước

Thực hiện

APDU

...

...

...

1

Máy chủ thông báo cho CICAM về sự thay đổi chế độ hoạt động

cc_sac_data_req

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

38 (operating_mode)

...

...

...

1

26 (program_number)

16 bits

request_datatype_nbr = 1

i

datatype_id

0

41 (mode_change_status)

2

...

...

...

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

41 (mode_change_status)

8 bits

CHÚ THÍCH:

...

...

...

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.47 chứa các giá trị cho phép và ý nghĩa của trường này

4: BẢng 11.17 chứa các giá trị cho phép của trường này

11.3.4.6. Giao thức dừng ghi lại

Máy chủ sử dụng giao thức này để thông báo cho CICAM rằng việc ghi lại đã được dừng lại và tất cả các thông tin liên quan đến mã PIN được CICAM lưu trữ phải bị xóa.

Bảng 11.49 - Giao thức dừng ghi lại

Bước

Thực hiện

APDU

...

...

...

1

Máy chủ thông báo cho CICAM rằng việc ghi lại đã bị dừng

cc_sac_data_req

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

26 (program_number)

...

...

...

request_datatype_nbr = 0

i

datatype_id

0

42 (record_stop_status)

2

CICAM gửi xác nhận đến máy chủ

cc_sac_data_cnf

send_datatype_nbr = 1

...

...

...

datatype_id

datatype_len

0

42 (record_stop_status) (Xem CHÚ THÍCH 3)

8 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.17 chứa các giá trị cho phép của trường này

...

...

...

Giao thức truyền tập tin dữ liệu này truyền các tập tin dữ liệu như tập tin dữ liệu SRM và thu trạng thái và xác nhận của máy chủ. Giao thức này sử dụng các CI Plus SAC APDU để gửi các tập tin dữ liệu từ CICAM đến máy chủ. Tập tin dữ liệu này được xác định bằng một datatype_id (xem bảng H.1 trong Phụ lục H dành cho datatype_id chỉ ra một tập tin SRM). Thông tin chi tiết được giải thích trong bảng 11.50.

Bảng 11.50 - Truyền và xác nhận tập tin SRM

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi SRM đến máy chủ

cc_sac_data_req

...

...

...

i

datatype_id

0

31 (srm_data)

request_datatype_nbr = 2

i

datatype_id

...

...

...

30 (status_field)

1

32 (datatransfer_confirm)

2

Máy chủ gửi xác nhận đến CICAM

cc_sac_data_cnf

send_datatype_nbr = 2

i

datatype_id

...

...

...

0

30 (status_field) (Xem CHÚ THÍCH 3)

8 bits

1

32 (datatransfer_confirm)

256 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

...

...

...

11.4. Hỗ trợ ứng dụng cụ thể

CI Plus cung cấp một tài nguyên hỗ trợ ứng dụng cụ thể (SAS) tương tự như tài nguyên này được quy định trong các bản quy định kỹ thuật OpenCable ™, giao diện 2.0 CableCARD ™ [27]. Tài nguyên này cung cấp một ống trong suốt cho phép một ứng dụng trên máy chủ truy nhập chức năng trên CICAM.

Đối với tài nguyên SAS có ích, một giao thức phải được xác định trên đầu của ống trong suốt này. Mỗi một giao thức được gán một private_host_application_ID để nhận dạng nó duy nhất.

Tài nguyên SAS được áp dụng cho các MHP CA API cho phép trao đổi dữ liệu giữa môi trường ứng dụng MHP và CAS cư trú trên CICAM như mô tả trong hình 11.2.

Hình 11.1 - Ví dụ môi trường ứng dụng dành cho SAS

Giao thức bản tin tài nguyên SAS dành cho các MHP CA API được quy định tại Phụ lục M.

APDU và cú pháp bản tin của tài nguyên SAS trong các bản quy định kỹ thuật OpenCable ™, giao diện 2.0 CableCARD ™ [27], điều 9.17, phải được hồ sơ này định nghĩa và sử dụng.

CICAM phải mở một phiên SAS lúc khởi tạo. Khi máy chủ yêu cầu một kết nối đến một ứng dụng trên CAM, nó gửi một SAS_connect_rqst () APDU theo điều 9.17.1 của [27] để một phiên SAS chưa được sử dụng.

...

...

...

Máy chủ phải theo dõi các mối liên kết giữa mỗi phiên SAS và một ID ứng dụng. Khi máy chủ muốn kết nối với một ID ứng dụng, nó phải sử dụng một phiên SAS được mở và chưa được liên kết với một ID ứng dụng.

CICAM có thể hỗ trợ nhiều máy khách được kết nối với cùng một ID ứng dụng tại cùng một lúc.

11.4.1. Thời gian sống của ứng dụng

Mỗi ứng dụng của máy chủ yêu cầu truy nhập tài nguyên SAS phải tạo ra một kết nối SAS mới và thời gian sống của ứng dụng với tài nguyên SAS này được định nghĩa như sau:

1) Ứng dụng khởi tạo trên máy chủ.

2) Ứng dụng của máy chủ khởi tạo một kết nối với phiên SAS bằng một SAS_connect_rqst () APDU khi yêu cầu một kết nối.

3) CICAM xử lý yêu cầu và trả lời bằng một SAS_connect_cnf () APDU.

• Nếu kết nối này đã được chấp nhận thì CICAM phải tạo một phiên SAS mới sẵn sàng dành cho bất kỳ kết nối mới tiếp theo.

• Nếu kết nối này không được chấp nhận thì phiên này vẫn mở sẵn sàng dành cho một yêu cầu kết nối tiếp theo.

...

...

...

5) Ứng dụng của máy chủ kết thúc và phiên SAS này được máy chủ đóng lại.

11.4.2. Truyền dữ liệu

Chỉ sử dụng chế độ không đồng bộ để chuyển dữ liệu CI Plus theo quy định tại Đặc tả kỹ thuật về giao diện OpenCable phiên bản 2.0 [27]. Chế độ đồng bộ thì không được hỗ trợ.

12. MMI cấp ứng dụng CI Plus

12.4. Phạm vi

TS 101 699 [8] điều 6.5 quy định khái niệm MMI miền ứng dụng. MMI miền ứng dụng này cho phép một công cụ trình bày chưa được quy định được sử dụng (nếu có) cho phép thực hiện trình bày và tương tác ứng dụng đặc biệt của CICAM khi so sánh với MMI ứng dụng cấp cao thông thường.

Hình 12.1 - Hoạt động của công cụ trình bày CI Plus và tài nguyên MMI ứng dụng

Phần này quy định hồ sơ ứng dụng CI Plus được thực hiện trong một máy chủ CI Plus và xác định chức năng tối thiểu mà máy chủ phải hỗ trợ.

...

...

...

Hình 12.2 - Phạm vi của CI Plus

MMI ứng dụng CI Plus được dựa trên bản quy định kỹ thuật công cụ UK-DTT MHEG-5 [23] và là nhóm cung cấp chức năng đầy đủ để cho phép một ứng dụng của mô-đun trình bày ký tự và đồ họa với sự kiểm soát tối thiểu lên dòng truyền tải. Tất cả nội dung đến công cụ trình bày CI Plus phải được CICM cung cấp cho máy chủ trực tiếp thông qua tài nguyên MMl ứng dụng: CICAM có thể tùy chọn tự tạo tập tin dữ liệu và/hoặc tạo trực tiếp từ dòng truyền tải.

MMI ứng dụng CI Plus có thể hoạt động trong một máy chủ có hỗ trợ các môi trường ứng dụng khác ví dụ như MHEG-5, MHP, v.v.. Việc thực hiện MMI ứng dụng CI Plus của máy chủ có thể lựa chọn để hỗ trợ giao diện sử dụng bất kỳ môi trường ứng dụng MHEG-5 hiện có nào hoặc thực hiện riêng biệt. MMI ứng dụng CI Plus phải được ưu tiên hơn bất kỳ môi trường ứng dụng hiện có nào và có thể tùy chọn được trình bày trên màn hình đồ họa riêng của máy chủ, màn hình ứng dụng hoặc một màn hình khác có thể tồn tại giữa màn hình riêng của máy chủ và màn hình ứng dụng, điều này được thể hiện trong hình 12.3

Hình 12.3 - Các màn hình hiển thị

Hình 12.3 chỉ là tham khảo và bao gồm cả màn hình lô gíc và vật lý, việc thực hiện của máy chủ phải xác định ánh xạ vật lý phù hợp nhất dành cho một kiến trúc máy chủ nhất định. MMI ứng dụng phải hỗ trợ video đầy đủ cho phép ký tự và đồ họa được phủ trong suốt trên video (và có thể là trên bất kỳ màn hình ứng dụng riêng nào). MMI ứng dụng có độ phân giải SD gốc 720x576 pixel và phải được mở rộng toàn màn hình để phù hợp với khuôn dạng hình ảnh hiện tại trong cả hai môi trường SD và HD.

Việc cung cấp kiểm soát bị hạn chế trên các bộ giải mã MPEG cho phép video và âm thanh của dịch vụ hiện tại này được trình bày là bắt buộc đối với MMI ứng dụng, có thể sử dụng bổ sung một I-frame có khung hình đầy đủ để cung cấp nền đồ họa phong phú. MMI ứng dụng có thể từ chối việc kiểm soát MMI ứng dụng của bộ giải mã MPEG nếu một xung đột tài nguyên xảy ra.

Hồ sơ MMI ứng dụng bao gồm một phần mở rộng tùy chọn dành cho phông chữ phác thảo TrueType và OpenType tự động nạp cho phép các bộ ký tự quốc tế được ứng dụng này sử dụng. Phông chữ tự động nạp có thể không có sẵn trong tất cả các máy chủ và ứng dụng này có thể kiểm tra sự hỗ trợ của máy chủ từ bên trong ứng dụng.

...

...

...

12.2. Hồ Sơ MMI ứng dụng

Ứng dụng CI Plus phải tuân thủ hồ sơ MHEG-5 phiên bản 1.06 [D-Book 5.0, điều 12-18] [23] với một số chức năng được giảm bớt dành cho máy chủ tuân thủ CI Plus.

12.2.1. Miền ứng dụng

Tiêu chuẩn này là một miền ứng dụng trong các điều khoản nêu tại Phụ lục D của tiêu chuẩn ISO 13.522-5 [16] và D-Book 5.0 [23] Điều 13. Miền ứng dụng của CI Plus được gọi là "CIEngineProfile1".

12.2.2. Tập các lớp

Tập các lớp được định nghĩa trong D-Book 5.0 [23], 13.3 với các trường hợp ngoại lệ được ghi trong Bảng 12.1:

Bảng 12.1 - Các trường hợp ngoại lệ đối với các lớp D-Book 5.0

Lớp

Ghi chú

...

...

...

Bắt buộc (Xem CHÚ THÍCH)

Nghệ thuật đường thẳng động

Không bắt buộc.

HyperText

Không bắt buộc.

CHÚ THÍCH: Xem D-Book[23] and điều 12.5.1 Các phông chữ có thể tải về

Thiết bị thu có thể tùy chọn hỗ trợ các lớp "Không bắt buộc" nhưng chúng không được ứng dụng CI Plus sử dụng trừ khi được tham chiếu trong bối cảnh của một miền ứng dụng khác nhau hoặc ứng dụng này đã xác nhận lớp đó tồn tại.

12.2.3. Tập các tính năng

Tập các tính năng được xác định trong D-Book 5.0 [23], điều 13.4 với các trường hợp ngoại lệ sau đây trong Bảng 12.2:

...

...

...

Tính năng

Ghi chú

Lưu tạm thời

Không bắt buộc.

Co dãn tín hiệu video

Không bắt buộc.

Tỷ số kích thước hình ảnh

Không bắt buộc.

UniversalEngineProfile

...

...

...

Một hồ sơ MHEG đầy đủ thường bao gồm đối tượng dòng cung cấp việc kiểm soát của các thành phần âm thanh và video. Để duy trì video và âm thanh hiện tại, một ứng dụng thường tạo một đối tượng dòng có chứa âm thanh và video được thiết lập theo các thành phần mặc định. Sau đó ứng dụng có thể thay đổi các thẻ của thành phần để chọn các thành phần âm thanh và video. Đối với hồ sơ CI Plus, chỉ cho phép ứng dụng này sử dụng các thành phần video và âm thanh mặc định. Cho phép ứng dụng CI Plus dừng lại và bắt đầu dòng để hiển thị một I-frame nếu nó được cho phép sử dụng chương trình thường trú RequestMPEGDecoder.

Các thành phần mặc định được thiết lập không kể các thành phần hiện đang hoạt động trên thiết bị thu. Việc tải về một ứng dụng CI Plus với tập các thành phần mặc định không được làm thay đổi chúng. Các thành phần hiện tại có thể đã được thiết lập bởi một môi trường ứng dụng, chẳng hạn như MHP, và không được ứng dụng CI Plus can thiệp.

12.2.3.1. Hồ sơ công cụ CI Plus

UniversalEngineProfile phải trả lời bằng xác nhận đối với một đối số kiểu chuỗi "CIPLUS001" xác định công cụ MHEG này là tuân thủ hồ sơ CI Plus 1.

12.2.3.2. Tính năng không bắt buộc

Các tính năng được xác định là không bắt buộc trong hồ sơ này có thể được máy chủ phù hợp với hồ sơ này tùy chọn thực hiện. Điều này cho phép hồ sơ CI Plus cùng tồn tại với các hồ sơ MHEG-5 khác.

Các ứng dụng CI Plus không được sử dụng bất kỳ tính năng được xác định là không bắt buộc trừ khi ứng dụng này kiểm tra xem nó có được công cụ này sử dụng UniversalEngineProfile () hoặc bất kỳ một phương pháp tiêu chuẩn khác để xác định các khả năng của môi trường này hỗ trợ.

Công cụ này chỉ có thể cung cấp các tính năng tùy chọn từ một (nhiều) hồ sơ khác đã được chứng nhận ví dụ như các tính năng của hồ sơ New Zealand MHEG có thể hoạt động nếu máy chủ được chứng nhận dành cho New Zealand.

12.2.3.3. Các đối tượng dòng

...

...

...

Yêu cầu sự cho phép của RequestMPEGDecoder khi các môi trường ứng dụng khác hiện tại đang sử dụng bộ giải mã MPEG có thể đang chạy.

Bất kỳ ứng dụng nào không bắt đầu với một đối tượng dòng hoạt động với các thành phần mặc định phải bị xử lý theo một cách không xác định.

Bất kỳ nỗ lực nào ngăn chặn đối tượng video hoặc toàn bộ dòng mà không được phép phải bị xử lý theo một cách không xác định.

Khi được cho phép, việc kiểm soát của các bộ giải mã MPEG phải tuân theo các quy tắc ứng dụng cư trú bình thường hoặc cho đến khi ứng dụng CI Plus này giải phóng nó bằng cách sử dụng RequestMPEGDecoder. Trước khi giải phóng bộ giải mã MPEG này, ứng dụng này phải trả bộ giải mã MPEG về trạng thái bình thường của nó bằng cách loại bỏ bất kỳ I-frame khỏi màn hình và khởi tạo lại các đối tượng với các thẻ thành phần video và âm thanh mặc định.

Cơ chế này đảm bảo rằng ứng dụng này hoạt động theo cách có thể đoán được trước ngay cả khi một môi trường ứng dụng đang hoạt động.

Hồ sơ CI Plus không yêu cầu các đối tượng dòng tạo các sự kiện dòng.

12.2.3.4. RTGraphics/phụ đề

Khi khởi tạo MMI ứng dụng CI Plus, trạng thái của phụ đề phải được xác định từ bản tin khởi tạo yêu cầu CICAM được xác định trong điều 13.6.2. Trường hợp dừng phụ đề để cho phép khởi tạo MMI ứng dụng CI Plus thì phụ đề phải được kích hoạt lại tự động khi ứng dụng CI Plus kết thúc.

12.2.4. GetEngineSupport

...

...

...

Bảng 12.3 - Các “tính năng” của GetEngineSupport

Chuỗi

Giới hạn

Tiêu chuẩn

Ngắn

MultipleAudioStreams(N)

MAS(N)

Có thể trả giá trị “true" với N≤1

MultipleVideoStreams(N)

...

...

...

Có thể trả giá trị “true" với N≤1

VideoScaling(CHook,X,Y)[a]

VSc(CHook,X,Y)[a]

Có thể trả giá trị “false" với tất cả cả bộ giá trị của CHook, X và Y

VideoDecodeOffset(CHook,Level)

VDO(CHook,Level)

Có thể trả giá trị “false” với tất cả cả bộ giá trị của CHook, X và Y

DownloadableFont(CHook)

DLF(CHook)

...

...

...

12.3. Mã hóa nội dung dữ liệu

Mã hóa dữ liệu nội dung được xác định trong D-Book 5.0 [23], điều 13.5 với các trường hợp ngoại lệ được quy định trong phần này và các phần tiếp theo.

12.3.1. Bảng nội dung

Trong CIEngineProfile1 bảng 13.7 sẽ theo D-Book 5.0 [23] với trường hợp ngoại lệ sau đây:

Bảng 12.4 - Bảng nội dung

Thuộc tính

Các giá trị cho phép

Phông chữ

Xem 12.5.1 "Các phông chữ có thể tải về"

...

...

...

Trong CIEngineProfile1 không có yêu cầu dành cho các định dạng lưu trữ của dòng, D-Book 5.0 [23] điều 13.5.3.

12.3.3. Đầu vào của người sử dụng

Ứng dụng CI Plus phải làm nổi bật đầu vào và ưu tiên hiển thị nếu MMI ứng dụng CI Plus cùng tồn tại với bất kỳ công cụ ứng dụng nào khác (ví dụ như chạy đồng thời).

Yêu cầu thực hiện của hồ sơ UK luôn luôn bắt đầu trong thanh ghi 3 của đầu vào của người sử dụng trong màn ảnh đầu tiên không được áp dụng đối với các ứng dụng CI Plus.

12.3.4. Các sự kiện của công cụ

Tập tối thiểu các sự kiện của công cụ mà công cụ này hỗ trợ được xác định trong D-Book 5.0 [23] điều 13.8, ngoại trừ các sự kiện của dòng sau đây không được CIEngineProfile1 yêu cầu.

Bảng 12.5 - Các trường hợp ngoại lệ của EventData trong CIEngineProfile1 đối với D-Book 5.0

EventData

Giá trị

...

...

...

VideoPrefChanged

6

Không bắt buộc

NetworkBootInfo

9

Không bắt buộc

12.3.5. Ánh xạ giao thức và kết nối ngoài

Ánh xạ giao thức và kết nối ngoài của D-Book 5.0 [23] điều 13,9 với trường hợp ngoại lệ của các hành động của dòng và các sự kiện của dòng không được CIEngineProfile1 yêu cầu.

12.3.6. Các chương trình thường trú

...

...

...

Bảng 12.6 - Các trường hợp ngoại lệ của chương trình thường trú của CIEngineProfile1 đối với D-Book 5.0

Chương trình thường trú

Tên

Ghi chú

SI_Tunelndex

Tin

Không bắt buộc

SI_Tunelndexlnfo

TII

...

...

...

GetBootlnfo

GBI

Không bắt buộc

VideoToGraphics

VTG

Không bắt buộc

SetWidescreenAlignment

SWA

Không bắt buộc

...

...

...

SSM

Không bắt buộc

RequestMPEGDecoder

RMD

Ghi chú: Chỉ gọi. Xem điều 12.3.6.1

12.3.6.1. RequestMPEGDecoder

Các yêu cầu truy nhập dành riêng bộ giải mã MPEG và màn hình video để hiển thị I-frame. Bộ giải mã MPEG này phải sẵn có khi không có môi trường ứng dụng khác đang hoạt động.

Tóm tắt RMD (Kết quả)

Các đối số

...

...

...

vào-ra

Kiểu

Tên

Diễn giải

Vào

GenericBool

Yêu cầu

Nếu 'true' thì ứng dụng MHEG đang yêu cầu sử dụng dành riêng bộ giải mã MPEG và màn hình video.

Nếu 'false' nó giải phóng bộ giải mã này.

...

...

...

GenericBool

Kết quả

Nếu yêu cầu là ‘true' thì:

• Nếu kết quả là ‘true' thì các I-frame có thể được sử dụng và phải duy trì có sẵn cho tới khi thoát khỏi ứng dụng này, một ứng dụng mới bắt đầu (xem D-Book 5.0 [23] điều 13.10.12) hoặc RequestMPEGDecoder được gọi ra lại bằng yêu cầu = ‘false'.

• Nếu kết quả là ‘false’ thì bộ giải mã MPEG là không có sẵn và các I-frame có thể không được sử dụng.

Nếu yêu cầu là ‘false' thì:

• Kết quả phải là 'false', bộ giải mã MPEG là không có sẵn và các I-frame có thể không được sử dụng.

Mô tả

Nếu ứng dụng CI Plus yêu cầu dừng dòng truyền tải và hiển thị một I-frame thì trước tiên nó phải được cho phép sử dụng bộ giải mã MPEG. Khi ứng dụng này đã kết thúc với bộ giải mã MPEG này, nó có thể giải phóng bộ giải mã bằng cách gọi RequestMPEGDecoder với yêu cầu = 'false' tuy nhiên ứng dụng này đã phải loại bỏ bất kỳ các I-frame trên màn hình và khởi tạo lại dòng với các thành phần mặc định nếu không kết quả sẽ không xác định.

...

...

...

Màn hình đồ họa được sử dụng để trình bày tất cả các hình ảnh có thể nhìn thấy, ngoại trừ các MPEG I-frame. Trình đơn ứng dụng CI này phải có một vùng đồ họa 720x576 pixel. Màn hình đồ họa này phải phù hợp với độ phân giải và khuôn dạng hình ảnh hiện tại. Trường hợp video có độ nét cao thì màn hình đồ họa phải bị thu nhỏ để phù hợp với độ phân giải và khuôn dạng hiện tại.

Màn hình đồ họa CI Plus phải ở trên (các) màn hình video và bất kỳ màn hình phụ đề nào. Bất kỳ màn hình trung gian giữa màn hình đồ họa CI Plus và các màn hình video (và phụ đề) có thể tùy chọn bị tắt hoặc làm trong suốt, tức là trong một môi trường ứng dụng, màn hình đồ họa ứng dụng có thể được hiển thị nếu màn hình ứng dụng CI Plus là trong suốt.

Việc trình bày không gian màu sắc và bảng màu tối thiểu được D-Book 5.0 [23], điều 14 xác định, truecolour với số bit tối thiểu là 16 bit được khuyến nghị thực hiện.

12.4.1. Lineart và Dynamic Lineart

Lineart và Dynamic Lineart không được CIEngineProfile1 yêu cầu, theo quy định tại D-Book 5.0 [23], điều 14.5.

12.4.2. Các PNG bitmap

Các PNG bitmap phải tuân thủ D-Book 5.0 [23], điều 14.7.

12.4.3. MPEG Stills

MPEG stills hoặc I-frame phải tuân thủ D-Book 5.0 [23], điều 14.8.

...

...

...

Đầu vào của người sử dụng được xác định trong D-Book 5.0 [23], điều 13.6. Một ứng dụng được CI Plus khởi tạo có thể bắt đầu trong bất kỳ nhóm thanh ghi nào bao gồm các nhóm thanh ghi 5.

12.4.5. Mẫu đồ họa độ nét cao.

Thiết bị thu độ nét cao (tức là các thiết bị thu có khả năng giải mã và trình bày hình ảnh có độ phân giải hình ảnh HD) phải tuân thủ mẫu đồ họa công cụ được quy định tại điều 12.4 và 12.4.1 đến 12.4.4 với các trường hợp ngoại lệ theo quy định của HDGraphicsPlaneExtension và HDVideoExtension được quy định tại ETSI MHEG [38] điều 12.11 và các mục có liên quan.

12.4.5.1. Khả năng phát hiện

Các ứng dụng CI Plus phải có khả năng xác định khả năng đồ họa của thiết bị thu mà chúng được cung cấp. Máy chủ hỗ trợ mẫu đồ họa HD phải hỗ trợ tính năng "HDExtension" ("HDE") GetEngineSupport được định nghĩa trong ETSI MHEG [38] điều 11.4.1.

12.5. Ký tự của công cụ

CIEngineProfile1 phải tuân thủ hoàn toàn D-Book 5.0 [23], điều 15, ngoại trừ các trường hợp sau đây. Các mục sau đây thay thế điều 15.3.1 và 15.3.1.1 trong D-Book 5.0.

Danh mục ký tự của CIEngineProfile1 tối thiểu phải là danh mục ký tự của UKEngineProfile1 khi sử dụng phông chữ cư trú. Ứng dụng MHEG có thể sử dụng các ký tự khác có sẵn trong bộ ký tự thay thế sau khi lần đầu tiên xác nhận sự có mặt của bộ ký tự này trong rec://font/xxx, trong đó XXX là bộ ký tự được yêu cầu.

CIEngineProfile1 có một lớp thuộc tính của phông chữ là “rec://font/CI1”.

...

...

...

12.5.1. Các phông chữ có thể tải về

Các thiết bị thu có thể tùy chọn hỗ trợ phông chữ có thể tải về sử dụng lớp phông chữ MHEG-5. Việc hỗ trợ được chỉ ra bằng trả lời đồng ý đối với DownloadableFont để xác nhận nội dung được hỗ trợ. Chỉ các phông chữ của thiết bị thu có thể được tham chiếu theo tên, các phông chữ được tải về phải được tham chiếu theo đối tượng phông chữ MHEG-5. Thiết bị thu phải hỗ trợ tất cả các ký tự trong một phông chữ được tải về và sẽ không bị giới hạn bởi hồ sơ công cụ của một quốc gia cụ thể. Tập các ký tự được hỗ trợ trong bất kỳ tập tin phông chữ được nhúng trong thiết bị thu có thể bị giới hạn trong một tập các ký tự của một quốc gia cụ thể.

Thiết bị thu hỗ trợ các phông chữ có thể tải về tối thiểu phải dành 256K byte bộ nhớ cho các phông chữ được tự động nạp. Các phông chữ châu Á, như Trung Quốc, yêu cầu thiết bị thu dành bộ nhớ nhiều hơn đáng kể.

Các thiết bị thu được CI Plus cho phép triển khai tại các khu vực này phải xác định yêu cầu CI Plus về bộ nhớ dựa trên các yêu cầu truyền hình của các khu vực địa phương.

Trường hợp các phông chữ có thể tải về được máy chủ hỗ trợ thì chỉ yêu cầu máy chủ hỗ trợ việc tải về của một phông chữ duy nhất. Máy chủ có thể tùy chọn hỗ trợ nhiều phông chữ có thể tải về.

12.5.1.1. Các phông chữ OpenType

Giá trị của Chook là 10 được quy định dành cho phông chữ OpenType® phù hợp phiên bản 1.4 của bản quy định kỹ thuật OpenType với TrueType ™ được công bố trên các trang web sau đây:

<http://www.microsoft.com/typography/otspec/default.htm>

<http://partners.adobe.com/asn/tech/type/opentype/index.jsp>

...

...

...

• Các bảng liên quan đến phông chữ TrueType

• bảng co giãn (định dạng "0" chỉ co giãn chiều ngang).

Việc hỗ trợ các bảng này không phải là bắt buộc mà là tùy chọn.

Đối với các phông chữ OpenType, bảng sau đây xác định các giá trị được sử dụng dành cho các tham số của phông chữ trong D-Book 5.0 [23], điều 15.5.

Bảng 12.7 - Các tham số của phông chữ OpenType

Tên thông số

Lấy được từ

metricsResolution,

outlineResolution

...

...

...

advanceWidth,

charSetWidth

Các giá trị advanceWidth, được định nghĩa ở bảng Horizontal Metrics ('htmx’). Xem CHÚ THÍCH

xMin, yMin, yMax

được định nghĩa ở bảng Font Header ('head')

Kem

Giá trị, được định nghĩa ở bảng Kernng ('kern') table

CHÚ THÍCH: đối với các phông chữ đơn khoảng cách, chỉ có thể định nghĩa một giá trị advanceWidth

12.5.1.2. Trình bày

...

...

...

12.5.1.3. Phản ứng phòng ngừa

Việc tải về phông chữ có thể thất bại và các ứng dụng có thể yêu cầu các tính năng và đặc điểm không hợp lệ hoặc không được hỗ trợ. Để xử lý các sự kiện này theo cách có thể dự đoán trước và chắc chắn, thiết bị thu phải thực hiện những biện pháp sau đây:

• Thiết bị thu phải sử dụng phông chữ sẵn có của nó thay thế phông chữ được tải khi

o Phông chữ được yêu cầu không có sẵn

o Xác nhận nội dung không được xác nhận

o Các thuộc tính của phông chữ không hợp lệ

Khi sử dụng phông chữ của thiết bị thu thì phải trình bày hộp văn bản theo phông chữ của thiết bị thu được quy định.

• Kiểu phông chữ được hỗ trợ chỉ là 'đơn giản'. Nếu có quy định bất kỳ kiểu font khác thì phải xử lý như kiểu ‘đơn giản’.

• Nếu kích thước phông chữ được yêu cầu không được phông chữ này hỗ trợ thì phải sử dụng kích thước nhỏ hơn tiếp theo. Nếu phông chữ được yêu cầu nhỏ hơn kích thước phông chữ nhỏ nhất có sẵn thì phải sử dụng kích thước có sẵn này.

...

...

...

Phần này trình bày thời gian sống của ứng dụng. Không được thay đổi D-Book 5.0 [23] điều 16, trừ những thay đổi cụ thể được trình bày trong trong phần này.

12.6.1. Thời gian sống của ứng dụng

Thời gian sống của ứng dụng là phương pháp thông báo ứng dụng CI được khởi tạo hoặc kết thúc.

12.6.1.1. Khởi tạo và kết thúc ứng dụng CI Plus

Ứng dụng CI Plus dành cho máy chủ CIEngineProfile1 phải được CICAM giới thiệu một cách rõ ràng bằng một RequestStart. Máy chủ có thể trả lời bằng một trả lời API busy nếu nó không thể đáp ứng yêu cầu này và CICAM có thể cố thử lại yêu cầu này sau đó.

Các ứng dụng CICAM có thể kết thúc vì một số lý do và điều kiện kết thúc phải được thông báo cho CICAM như sau:

• Chúng thực hiện thao tác "Quit"

• Chúng bị máy chủ chấm dứt vì thay đổi kênh.

• Chúng bị chấm dứt vì mô-đun CI tạo một bản tin RequestStart hoặc AppAbortRequest.

...

...

...

Hệ thống tập tin CI được gắn kết với hoạt động của mô-đun CI. Trạng thái đầu ra hiện tại của video, âm thanh, và tùy chọn bất kỳ ứng dụng khác, phải giữ không đổi. Tùy chọn có thể vô hiệu, phụ đề và ứng dụng này được khởi tạo và sẵn có. Đồ họa của ứng dụng này phải được thu nhỏ/phóng to để phù hợp với độ phân giải màn hình video hiện tại.

12.6.2. Tương tác với mô-đun giao diện chung DVB

Tương tác với mô-đun giao diện chung DVB phải tuân thủ D-Book 5.0 [23], điều 16.11. Phải sử dụng nhãn nhận dạng miền ứng dụng "CIMHEGP1" (0x43494d4845475031) trong bản tin Requeststart để xác định rằng miền ứng dụng được yêu cầu là CIEngineProfile1.

Nhãn nhận dạng miền ứng dụng có thể được tùy chọn thay đổi bằng các đối số xác định các yêu cầu của môi trường ứng dụng CI Plus. Các tùy chọn này được quy định tại phần cuối của nhãn nhận dạng miền ứng dụng được phân cách nhau bằng dấu chấm phẩy (;) tức là <applicationDomainIndentifier> [; <option1>; <option2>;...; <tùy chọn #> ] trong đó các tùy chọn được định nghĩa như sau:

Bảng 12.8 - Các tùy chọn khởi tạo nhãn nhận dạng miền ứng dụng

Tên

Giá trị tùy chọn

Ghi chú

SSM RTGraphics State

...

...

...

Các phụ đề (RT Graphics) phải được tắt trước khi bắt đầu CI Plus Application, các tiêu đề phải được trả lại trạng thái trước đó sau khi chấm dứt CI PlusApplication

SSM=1

Các phụ đề (RTGraphics) phải xuất hiện khi được kích hoạt bởi lựa chọn của người sử dụng, nếu CI PlusApplication và các phụ đề không thể cùng tồn tại thì CI PlusApplication không được phép bắt đầu.

SSM=2

Các phụ đề (RTGraphics) phải được tùy chọn để xuất hiện khi được kích hoạt bởi sự lựa chọn của người sử dụng, nếu CI PlusApplication và các phụ đề không thể cùng tồn tại thì phụ đề phải bị tắt và CI PlusApplication phải bắt đầu. Tại những chỗ mà phụ đề tạm thời ghi đè lên lựa chọn của người sử dụng và được tắt thì trạng thái phụ đề đang tồn tại phải được khôi phục khi kết thúc ứng dụng. Tùy chọn này là trạng thái mặc định phải được giả thiết khi tùy chọn SSM bị bỏ ra khỏi bộ xác định miền ứng dụng.

12.6.2.1. Hồ Sơ truyền hình MHEG

Trường hợp hồ sơ truyền hình của một quốc gia nhất định hỗ trợ một môi trường MHEG truyền hình thì có thể thiết kế CICAM theo một hồ sơ truyền hình cụ thể và khởi tạo với nhãn nhận dạng miền ứng dụng của hồ sơ này mà không phải là hồ sơ CI. Xem D-Book 5.0 [23], điều 16.11.3.2. Thời gian sống của ứng dụng đối với hồ sơ truyền hình này có thể là quan trọng và có thể cho phép:

• Mô-đun CI giới thiệu một ứng dụng CI

• Một ứng dụng truyền hình tùy chọn giới thiệu một ứng dụng CI.

...

...

...

12.6.2.2. Hồ Sơ truyền hình MHP

Trường hợp hồ sơ này hỗ trợ MHP thì MMI ứng dụng CI Plus phải được ưu tiên hơn môi trường ứng dụng MHP này và phải tập trung đầu vào. Màn hình đồ họa MHP có thể bị tạm thời loại bỏ hoặc MMI ứng dụng CI Plus phải xuất hiện ở phía trước nó. Khi MMI ứng dụng CI Plus là một phần mở rộng của OSD riêng thì việc tồn tại đầu ra CI Plus trên màn hình đồ họa riêng của máy chủ để thay thế cho giao diện đồ họa riêng (OSD) là có thể chấp nhận.

12.6.2.3. Yêu cầu và xác nhận tập tin

Độ dài tối đa của một FileNameLeng yêu cầu hoặc xác nhận tập tin không được quy định nhưng phải phù hợp với tài nguyên bộ nhớ trình duyệt CI Plus.

12.6.2.4. Lưu trữ thường trực

Công cụ CI Plus phải cung cấp tối thiểu 1.024 byte dữ liệu theo D-Book [23] điều 16.7. Lưu trữ thường trực có thể được thực hiện trong bộ nhớ dễ thay đổi.

12.6.3. Mẫu tài nguyên máy chủ

Theo D-Book 5.0 [23] các điều 16.8 và 16.9 với những giới hạn sau đây.

12.6.3.1. Tài nguyên bộ nhớ

...

...

...

12.6.3.2. Hành vi quay lại liên kết

Công cụ CI Plus phải cho phép ít nhất 128 hoạt động đồng thời và ít nhất là 1024 hoạt động thành phần chờ xử lý.

12.6.3.3. Tính và độ chi tiết của thời gian

Công cụ CI Plus phải cho phép ít nhất 4 đồng hồ MHEG-5 có thể hoạt động đồng thời với độ chính xác +/- 10 ms. Khi có nhiều hơn 4 đồng hồ đang hoạt động thì độ chính xác có thể bị suy giảm theo một cách cụ thể.

Thiết bị thu phải hỗ trợ khoảng thời gian của đồng hồ hoạt động lên đến ít nhất 1 giờ.

12.6.3.4. Xếp chồng ứng dụng

Xếp chồng ứng dụng theo điều 16.9 của D-Book 5.0 ngoại trừ việc xếp chồng ứng dụng phải có khả năng giữ tham chiếu đến ít nhất 5 ứng dụng.

12.7. Ánh xạ tên

12.7.1. Các tên trong máy chủ

...

...

...

Bảng 12.9 - Các tên trong máy chủ hồ sơ CI

Tên

Ghi chú

rec://font/CI1

Nhận diện phông chữ được dùng kè, các tên phông chữ khác có thể tồn tại nhưng không bị bắt buộc bởi CIEngineProfile1.

Phông chữ này được định nghĩa cho Tây Âu và phải giống hệt UK-DTT“UK1”

ram://<name>

Không gian tên cho việc lưu trữ lâu.

12.7.2. Ánh xạ không gian tên

...

...

...

Các tập tin đối tượng MHEG là màn ảnh, ứng dụng hoặc dữ liệu nội dung của một đối tượng thành phần, trong đó mỗi màn ảnh, đối tượng ứng dụng hoặc dữ liệu nội dung được lưu trữ trong một tập tin riêng biệt.

12.7.3. Tham chiếu đối tượng MHEG-5

Các quy tắc tham chiếu đối tượng MHEG-5 của D-Book 5.0 [23] điều 18.3.1 được áp dụng ngoại trừ các đối tượng DSM-CC.

12.7.4. Các quy tắc ánh xạ dành cho GroupIdentifier và ContentReference

Các quy tắc ánh xạ dành cho GroupIdentifier và ContentReference của D-Book 5.0 [23] điều 18.3.2 được áp dụng với những lưu ý sau đây:

12.7.4.1. Nhạy cảm loại chữ

Hệ thống tập tin CI cung cấp các tên tập tin nhạy cảm loại chữ.

12.7.4.2. Cấu trúc tham chiếu tập tin

“DSM:" và “~” (viết tắt của "DSM:") không được yêu cầu trong CIEngineProfile1. Hệ thống tập tin gốc CI được tham chiếu là “CI:”.

...

...

...

Hành vi nhớ đệm mặc định của nội dung "CI:" là "việc nhớ đệm không được phép" (CCPO) và theo mặc định tất cả các tham chiếu tập tin được yêu cầu thông qua giao diện CI. Việc hỗ trợ ContentCachPriority (CCP) với hệ thống tập tin CI là không bắt buộc đối với CIEngineProfile1.

Máy chủ có thể tùy chọn thực hiện việc nhớ đệm hệ thống tập tin CI và có thể phân tích ContentCachePriority và GroupCachingPriority này và phải được sử dụng tuân thủ theo D-Book [23], Bất kỳ máy chủ thực hiện cơ chế nhớ đệm phải hỗ trợ hành vi nhớ đệm tương tự như được quy định trong hồ sơ băng chuyền đối tượng MHEG, ngoại trừ những từ "dòng truyền hình" và "băng chuyền truyền hình" được thay thế bằng "hệ thống tập tin CI". Có thể thực hiện nhớ đệm bằng cách sử dụng tài nguyên MMI ứng dụng v1 hoặc v2 cho hiệu quả cao hơn (xem 14.5).

Ưu tiên nhớ đệm nhóm hay nội dụng phải được phân tích và áp dụng cho hệ thống tập tin CI này theo Bảng 12.10.

Bảng 12.10 - Hành vi nhớ đệm của CICAM

Ưu tiên nhớ đệm

Ý nghĩa

Phương pháp truy tìm nhớ đệm

Các giá trị chẵn (trừ không)

Các giá trị chẵn khác không của mức ưu tiên lưu trữ (2, 4, 6, v.v.) cho biết rằng đối tượng này có thể được lấy về từ bộ lưu trữ cục bộ mà không cần tham chiếu đến CICAM. Giá trị này cho biết dữ liệu là tĩnh và giá trị càng cao thì dữ liệu này càng có ích để lưu trữ.

...

...

...

Sử dụng nội dung được lưu trữ cục bộ và không cũ (hoặc không có ý nghĩa)

Các giá trị lẻ

Các giá trị chẵn khác không của mức ưu tiên lưu trữ (2, 4, 6, v.v.) cho biết rằng máy chủ phải kiểm chứng nội dung là mới trước khi sử dụng dữ liệu từ bộ lưu trữ. Giá trị càng cao có nghĩa dữ liệu càng có ích để lưu trữ.

CHÚ THÍCH: Để kiểm chứng rằng nội dung là mới thì một yêu cầu File phải được gửi tới CICAM, tức là bộ lưu trữ chỉ có ích cho các máy chủ có hỗ trợ các yêu cầu loại FileHash.

RequestType=FileHash hoặc RequestType=File

Không

Đây là giá trị mặc định khi không có bộ lưu trữ CICAM.

Không được phép lưu trữ nội dung này, các bản sao đã được lưu trữ của dữ liệu này, nếu có, phải được hủy và phải được lấy lại một cách rõ ràng từ CICAM với RequestType=File.

RequestType=FileHash không được sử dụng cho CPP0

...

...

...

12.8. Các phần mở rộng VOD

MMI ứng dụng mở rộng các tính năng của công cụ này để hỗ trợ các yêu cầu của tiêu chuẩn này và bao gồm các chương trình thường trú bổ sung để hỗ trợ các ứng dụng VOD. Cung cấp VOD sử dụng kiểm soát máy chủ v2 và một ứng dụng VOD yêu cầu một cơ chế lấy mã khóa nâng cao và việc kiểm soát ẩn màn hình đồ họa là các phần mở rộng VOD và là yêu cầu đối với tất cả các máy chủ thực hiện theo tiêu chuẩn này (CI Plus).

12.8.1. Các chương trình thường trú

Các chương trình thường trú phải bao gồm thêm các chương trình được liệt kê trong Bảng 12.11.

Bảng 12.11 - Các phần mở rộng chương trình thường trú VOD của CI Plus

Chương trình thường trú

Tên

Ghi chú

TestlnputMask

...

...

...

Quản lý mã khóa VOD - Sách trắng DTG

SuppressMHEGGraphics

SMG

Điều khiển hiện thị VOD-CI Plusv1.3 Extension

Một ứng dụng có thể kiểm tra sự tồn tại của các phần mở rộng VOD bằng cách kiểm tra sự tồn tại của chương trình thường trú SMG này.

12.8.1.1. Mặt nạ đầu vào kiểm tra

Việc xử lý mã khóa đầu vào phải được mở rộng với các phần mở rộng mặt nạ đầu vào để cung cấp MMI ứng dụng khả năng truy nhập các mã khóa kiểm soát video, điều này được trình bày chi tiết trong tài liệu "DTG MHEG spec Group White Paper: MHEG InputMaskExtensions".

Phải cung cấp InputEventMask trong lớp màn ảnh.

Phải hỗ trợ SetlnputMask (NewInputMask) của hành động thành phần.

...

...

...

Chương trình thường trú SuppressMHEGGraphics cung cấp việc kiểm soát chuyển đổi giữa các màn hình phụ đề và đồ họa ứng dụng trên các máy chủ chỉ hỗ trợ một màn hình đồ họa duy nhất. Chương trình thường trú này cho phép phụ đề tồn tại trong khi một ứng dụng tiếp tục được thực hiện, ngoài ra cũng cho phép phụ đề bị ngăn chặn và đồ họa ứng dụng được khôi phục đối với môi trường ứng dụng này. Gọi chương trình cư trú trên một máy chủ có hỗ trợ hiển thị đồng thời phụ đề và đồ họa MHEG, không đảm bảo rằng màn hình đồ họa này bị loại bỏ và việc loại bỏ tất cả các đối tượng nhìn thấy được là trách nhiệm của ứng dụng này.

Tóm tắt SMG (GraphicsState)

Đối số

Vào/ra

Kiểu

Tên

Diễn giải

Vào

GenericBool

...

...

...

Nếu đúng thì MMI ứng dụng này đã loại bỏ màn hình đồ họa và phụ đề có thể được hiển thị khi được kích hoạt. Màn hình đồ họa có thể bị ngăn chặn.

Nếu sai thì MMI ứng dụng này yêu cầu màn hình đồ họa và phụ đề phải bị dừng lại và việc kiểm soát màn hình đồ họa phải trả về cho MMI ứng dụng vào cuối cuộc gọi chương trình thường trú.

Mô tả

Khi máy chủ hỗ trợ hiển thị đồng thời MMI ứng dụng và phụ đề thì chương trình thường trú này không được có hiệu lực. Không được yêu cầu MMI ứng dụng ẩn các đối tượng đồ họa và các đối tượng đồ họa có thể vẫn còn nhìn thấy được.

Khi máy chủ không hỗ trợ hiển thị đồng thời MMI ứng dụng và phụ đề thì trường hợp MMI ứng dụng đã được khởi tạo với SSM = 2 và MMI ứng dụng được hiển thị thì màn hình đồ họa phải bị ngắt kết nối khỏi MMI ứng dụng và phải được sử dụng để hiển thị phụ đề, khi phụ đề được kích hoạt và tồn tại trong dòng truyền tải này. Ứng dụng có thể mất màn hình đồ họa khi SuppressMHEGGraphics (đúng) được gọi ngay cả khi phụ đề không được kích hoạt. Khi SupressMHEGGraphics (sai) được gọi thì phụ đề phải bị dừng lại và màn hình đồ họa phải được trả về cho ứng dụng.

Chương trình thường trú có thể được một ứng dụng sử dụng như sau:

1. Ứng dụng MMI được khởi tạo với SSM = 2 trên một thiết bị thu không hỗ trợ hiển thị đồng thời ứng dụng và phụ đề. Người sử dụng đã kích hoạt phụ đề và phụ đề có mặt trong dòng truyền tải này.

2. Ứng dụng được bắt đầu và phụ đề bị ngăn chặn.

3. Người sử dụng chuyển hướng thông qua ứng dụng này và lựa chọn một tùy chọn không yêu cầu đồ họa (tức là màn hình được lấp đầy rõ ràng), ứng dụng này ẩn tất cả các thành phần đồ họa có thể nhìn thấy và gọi SuppressMHEGGraphics (đúng).

...

...

...

5. Ứng dụng này tiếp tục nhận được mã khóa được nhập vào và có thể liên kết và tải các tập tin từ CICAM

6. Người sử dụng thực hiện một hành động yêu cầu hiển thị ứng dụng này. ứng dụng này gọi SuppressMHEGGraphics (sai). Khi chương trình thường trú này trở lại, phụ đề bị ẩn và màn hình đồ họa được khôi phục đối với ứng dụng này. Ứng dụng này có thể làm cho các thành phần đồ họa có thể nhìn thấy và chúng phải xuất hiện.

Các sản phẩm lỗi thời sẽ không hỗ trợ chương trình thường trú SuppressMHEGGraphics 0 và phụ đề sẽ vẫn bị vô hiệu trong khi ứng dụng này đang chạy.

12.9. Hướng dẫn và quy định thực hiện MHEG-5

Các quy tắc thực hiện này được quy định tại D-Book 5.0 [23] điều 19 được áp dụng nhưng phải tuân thủ các giới hạn của CI Plus, tức là các ứng dụng bị giới hạn với 512 Kbyte. Lưu ý rằng các ứng dụng HD có thể lớn hơn nhưng ứng dụng này phải xác định rằng công cụ này hỗ trợ HD trước khi cố gắng tăng kích thước ứng dụng lên đến 1 Mbyte.

Các ứng dụng CI Plus phải được thực hiện với lưu ý rằng chúng có thể được triển khai trong các môi trường SD hay HD nơi màn hình đồ họa ứng dụng này phải phụ thuộc vào việc phóng to thu nhỏ.

CICAM phải xem xét trạng thái phụ đề (RTGraphics) khi khởi tạo một ứng dụng CI Plus. Đối với một số máy chủ, việc tồn tại cùng một lúc đối với ứng dụng CI Plus và phụ đề có thể là không được, trong trường hợp này phụ đề phải được ưu tiên khi CICAM cố gắng cài đặt một ứng dụng CI Plus nền, cho phép người sử dụng duy trì phụ đề.

Các ứng dụng phải đảm bảo rằng việc hỗ trợ phông chữ có thể tải về tồn tại trên máy chủ khi được sử dụng. Các phông chữ OpenType sử dụng các bảng tùy chọn nên được các người tạo ra ứng dụng tránh vì các kết quả này sẽ thay đổi theo thiết bị thu cụ thể. Ứng dụng này chỉ phải sử dụng một phông chữ có thể tải về duy nhất.

Việc tải về phông chữ có thể thất bại. Nếu điều này xảy ra thì văn bản có sử dụng các ký tự không có trong bộ ký tự mặc định của thiết bị thu sẽ được trả lại không chính xác. Ứng dụng này cần phòng ngừa điều này, ví dụ như bằng cách giám sát sự kiện ContentAvailable từ đối tượng phông chữ trước khi kích hoạt đối tượng văn bản.

...

...

...

Các ứng dụng CI Plus có thể tồn tại trong các môi trường mà chúng có thể cạnh tranh với các môi trường ứng dụng khác để sử dụng bộ giải mã MPEG vì khi sử dụng các I-frame là mong muốn đối với ứng dụng CI Plus mà chúng có thể không luôn luôn có sẵn. Điều này không có ý để ứng dụng CI Plus can thiệp dòng truyền tải. Người tạo ra ứng dụng này phải lưu ý để đảm bảo các kết quả có thể dự đoán trước, để đảm bảo điều này, các ứng dụng CI Plus phải thực hiện theo các quy tắc sau đây:

• Ứng dụng này luôn luôn phải bắt đầu với một dòng hoạt động có một nội dung gốc thuộc "rec://svc/cur". Đối tượng dòng này phải ghép đối tượng âm thanh và một đối tượng video. Cả đối tượng âm thanh và video phải có một thẻ thành phần là -1. Đối tượng video này phải có một orignalBoxSize rộng 720 và cao 576. Đối tượng video này phải có một XYPosition là 0,0.

• Ứng dụng này không được quy định khuôn dạng màn ảnh.

• Ứng dụng này không được thay đổi vị trí, mức phóng to thu nhỏ hoặc độ lệch bù giải mã của hình ảnh trực tiếp, tuy nhiên ứng dụng này có thể thay đổi vị trí, mức phóng to thu nhỏ và độ lệch bù giải mã của các I-frame.

• Trước khi dừng đối tượng dòng này trình bày dòng truyền tải, ứng dụng CI Plus phải được cho phép của chương trình thường trú RequestMPEGDecoder (điều 12.3.5.1). Khi sự cho phép đã được cấp, nó vẫn được cấp trong suốt thời gian của chương trình thường trú theo quy định tại D-Book 5.0 điều 13.01.12 hoặc cho đến khi ứng dụng CI Plus giải phóng sự cho phép này.

• Các ứng dụng không nên yêu cầu sử dụng bộ giải mã MPEG nhiều hơn mức cần thiết. Nếu RequestMPEGDecoderhas được trả về ‘sai’ thì nó có khả năng trả về ‘sai’ nếu nó được gọi lại.

• Khi đối tượng dòng truyền tải đã bị dừng thì một I-frame có thể được trình bày.

• Ứng dụng CI Plus có thể từ bỏ sự cho phép sử dụng bộ giải mã MPEG, trước khi làm như vậy, ứng dụng CI Plus phải đảm bảo bộ giải mã MPEG trong trạng thái tương tự như trước khi sự cho phép sử dụng bộ giải mã MPEG đã được cấp. Phải loại bỏ bất kỳ I-frame nào khỏi màn hình và một đối tượng dòng dành cho dòng truyền tải được khởi tạo.

Bất kỳ ứng dụng CI Plus nào không tuân theo các quy tắc này có nguy cơ có hành vi không dự đoán được.

...

...

...

Người tạo ra ứng dụng nên xem xét điều 14,7 của D-Book 5.0 khi tạo các PNG. Loại bỏ những phần không sử dụng từ một PNG và giảm độ sâu màu có thể tác động đáng kể lên kích thước tập tin và thời gian tải ứng dụng.

13. Tài nguyên giao diện người - máy của CI Plus

13.1. MMI cấp thấp

MMI cấp thấp là tùy chọn và không bắt buộc đối với CI Plus.

13.2. MMI cấp cao

Tiêu chuẩn này không làm thay đổi EN 50221 [7] điều 8.6, MMI cấp cao, nhưng mở rộng với một yêu cầu bổ sung:

• Máy chủ phải có thể hiển thị 40 ký tự và 5 dòng ngoài của tiêu đề, phụ đề và dòng dưới cùng.

Hình 13.1 - Trình bày MMI cấp cao

...

...

...

Bảng dưới đây chỉ ra các khả năng MMI của máy chủ và CICAM trong các hồ sơ DVB CI và CI Plus.

Bảng 13.1 - Tài nguyên MMI của máy chủ/CICAM DVB-CI/CI Plus

Máy chủ

DVB-CI

CI Plus

CICAM

DVB-CI

- MMI cấp cao: Bắt buộc

...

...

...

- MMI cấp cao: Bắt buộc

- MMI ứng dụng "CI Plusbrowser":Tùy chọn

CI Plus

- MMI cấp cao: Bắt buộc

- MMI cấp cao: Bắt buộc

- MMI ứng dụng "CI Plusbrowser": Bắt buộc

13.4. Trình đơn CICAM

Khuyến nghị sau đây được thực hiện đối với trình đơn CICAM trên máy chủ.

• Số lượng tối đa của các cấp để truy nhập vào menu CICAM là nhỏ hơn 3.

...

...

...

14.1. Tài nguyên truyền tốc độ thấp phiên bản 3

Phiên bản 3 của truyền tốc độ thấp thay đổi các bản tin và giao thức để tăng thông lượng dữ liệu.

• Kích thước tối đa của các bộ đệm gửi và nhận được tăng lên 2048 byte.

• Máy chủ và CICAM sử dụng một nhóm bộ đệm cố định có 16 bộ đệm theo mỗi hướng.

• Xác nhận nhiều bộ đệm.

• Thông báo tính sẵn có của nhiều bộ đệm không được xác nhận.

Tốc độ bit tối thiểu được hỗ trợ phải là 1 Mbps.

14.1.1. Sửa đổl comms_cmd

Những thay đổi trong comms_cmd () APDU có liên quan đến lệnh Set_Params. Buffer_size nó hiện tại đã được mã hóa như một giá trị 16 bit. buffer_size và reception_timeout đều có các giá trị mặc định.

...

...

...

Bảng 14.1 - Mã hóa đối tượng Comms Cmd

buffer_size: Kích thước tối đa, tính theo byte, của các bộ đệm được trao đổi theo cả hai hướng. Giá trị tối đa của buffer_size là 2048. Giá trị mặc định dành cho kích thước bộ đệm, khi lệnh Set_Params không được gửi, là 254 byte.

reception_timeout: Một giá trị thời gian chờ nhận, tính theo bội số của 10 ms. Nếu máy chủ đã nhận được một hoặc nhiều byte trong bộ đệm hiện tại và thời gian chờ này đã trôi qua mà không có thêm byte nhận được, thì bộ đệm này được gửi đến CICAM. Nếu bộ đệm đầy tới giới hạn được tham số buffer_size thiết lập mà không có thời gian chờ thì bộ đệm này được gửi ngay lập tức. Giá trị mặc định dành cho reception_timeout là 10, tức là 100 ms. reception_timeout 0 là không hợp lệ và không được sử dụng.

14.1.2. Sửa đổi comms_reply

Với phiên bản 3 của tài nguyên LSC, máy chủ không được xác nhận tính sẵn có của một bộ đệm trước khi gửi nó đến CICAM. Do đó, máy chủ không bao giờ được gửi comms_reply () với comms_reply_id được thiết lập là 05 (comms_reply_id của Get_Next_Buffer_Ack trước đó).

Bảng comms_reply_id được quy định như sau:

Bảng 14.2 - comms_reply_id

comms_reply_id

...

...

...

Connect_Ack

0x01

Disconnect_Ack

0x02

Set_Params_Ack

0x03

Status_Reply

0x04

Dự phòng

...

...

...

Send_Ack

0x06

Dự phòng

Các giá trị khác

Cú pháp của bản tin comms_reply () là không đổi so với Bảng 54 trong EN 50221 [7].Zero (0x00) là giá trị trả về OK tiêu chuẩn, 0xff là lỗi không xác định. Xem Phụ lục E.14.

Giá trị trả về comms_reply () dành cho Set_Params_Ack là 0 khi máy chủ chấp nhận kích thước bộ đệm được CICAM yêu cầu hoặc 0xfe (bộ đệm quá lớn) khi máy chủ không thể xử lý các bộ đệm gửi và nhận có kích thước được CICAM yêu cầu này. Trong trường hợp này, kích thước bộ đệm và thời gian chờ vẫn không thay đổi và CICAM có thể gửi lại một lệnh Set_Params với một kích thước bộ đệm nhỏ hơn.

Set_Params_Ack phải trả về 0xff khi CICAM yêu cầu reception_timeout là 0. reception_timeout trước đó không được thay đổi trong trường hợp này. Set_Params_Ack phải trả về 0xff để trả lời lệnh Set_Params đã được gửi sau khi kết nối mạng được thiết lập và dữ liệu đã được truyền.

14.1.3. Kiểm soát dòng của CICAM

Với phiên bản 3 của tài nguyên truyền tốc độ thấp, CICAM sử dụng một số bộ đệm cố định là 16 bộ đệm.

...

...

...

comm_phase_id được thiết lập theo nhãn nhận dạng của bộ đệm cuối cùng trong tập các bộ đệm. Tập các bộ đệm được định nghĩa là Get_Next_Buffer comm_phase_id cuối cùng cộng với một (mô đun 16), hoặc không khi không có Get_Next_Buffer đã được gửi từ khi mở phiên hoặc kết nối kênh, đến Get_Next_Buffer comm_phase_id hiện tại, bao gồm cả hai Get_Next_Buffer comm_phase_id.

Khi dữ liệu nhận được có sẵn từ kênh này, máy chủ phải sử dụng comms_rcv APDU với comm_phase_id được thiết lập theo comms_rcv APDU comm_phase_id cuối cùng cộng với một (mô đun 16), hoặc không khi không có comms_rcv APDU đã được gửi từ khi mở phiên hoặc kết nối kênh. Bộ đệm này tương ứng với comm_phase_id được xem là không còn có sẵn cho đến khi CICAM gửi Get_Next_Buffer APDU mô tả một tập các bộ đệm trong đó bao gồm cả bộ đệm đã đề cập.

Máy chủ phải dừng gửi comms_rcv APDU khi tất cả các bộ đệm có sẵn đã được sử dụng. Máy chủ phải đợi cho đến khi CICAM chỉ ra tính sẵn có của một tập các bộ đệm mới trước khi gửi một APDU comms_rcv, nếu được yêu cầu.

Hình 14.1 - Kiểm soát dòng của CICAM

Bảng 14.3 dưới đây chỉ ra tính sẵn có của mỗi bộ đệm trong số 16 bộ đệm, sau một số bước của hình 14.1 trên:

Bảng 14.3 - Tính sẵn có của bộ đệm trong hình 14.1

Buffer Id

Bước

...

...

...

[3]

[5]

[10]

[12]

[14]

[16]

[18]

[20]

0

...

...

...

X

O

O

O

O

O

O

O

1

...

...

...

O

O

X

O

O

O

O

O

2

...

...

...

O

O

X

X

O

O

O

O

3

...

...

...

O

O

X

X

X

X

O

O

4

...

...

...

O

O

X

X

X

X

X

O

5

...

...

...

O

O

O

O

O

X

X

O

6

...

...

...

O

O

O

O

O

O

O

O

7

...

...

...

O

O

O

O

O

O

O

O

8

...

...

...

O

O

O

O

O

O

O

O

9

...

...

...

O

O

O

O

O

O

O

O

10

...

...

...

O

O

O

O

O

O

O

O

11

...

...

...

O

O

O

O

O

O

O

O

12

...

...

...

O

O

O

O

O

O

O

O

13

...

...

...

O

O

O

O

O

O

O

O

14

...

...

...

O

O

O

O

O

O

O

O

15

...

...

...

O

O

O

O

O

O

O

O

"O" có nghĩa là bộ đệm có sẵn dành cho máy chủ

...

...

...

Bộ đệm có sẵn tiếp theo được máy chủ sử dụng để nhận dữ liệu được đánh dấu bằng một "O" đậm. Các bước trong hình 14.1 được mô tả dưới đây:

1) Sau khi kết nối được thiết lập thành công trên kênh này, CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 15, để chỉ ra cho máy chủ rằng các bộ đệm từ 0 đến 15 thể được lấp đầy

2) Máy chủ nhận dữ liệu trên kênh này

3) Máy chủ gửi bộ đệm nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 0

4) CICAM xử lý bộ đệm 0

5) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 0, để chỉ ra cho máy chủ rằng bộ đệm 0 có thể được lấp đầy

6) Máy chủ nhận dữ liệu trên kênh này

7) Máy chủ gửi một phần của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 1

8) Máy chủ gửi một phần của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 2

...

...

...

10) Máy chủ gửi một phần của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 4

11) CICAM xử lý bộ đệm 1

12) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 1, để chỉ ra cho máy chủ rằng bộ đệm 1 có thể được lấp đầy

13) CICAM xử lý bộ đệm 2

14) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 2, để chỉ ra cho máy chủ rằng bộ đệm 2 có thể được lấp đầy

15) Máy chủ nhận dữ liệu trên kênh này

16) Máy chủ gửi bộ đệm đã nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 5

17) CICAM xử lý bộ đệm 3

18) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 3, để chỉ ra cho máy chủ rằng bộ đệm 3 có thể được lấp đầy

...

...

...

20) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 5, để chỉ ra cho máy chủ rằng các bộ đệm 4 và 5 có thể được lấp đầy

14.1.4. Kiểm soát dòng của máy chủ

Với phiên bản 3 của tài nguyên truyền tốc độ thấp, máy chủ phải chấp nhận lên đến 16 bộ đệm trước khi CICAM kích hoạt kiểm soát dòng.

Khi CICAM phải gửi dữ liệu cho kênh này, CICAM sử dụng một comms_send APDU với comms_phase_id được thiết lập theo comms_send APDU comm_phase_id cuối cùng cộng với một (mô đun 16), hoặc không khi không có comms_send APDU đã được gửi từ khi mở phiên hoặc kết nối kênh.

Hình 14.2 - Kiểm soát dòng của máy chủ với 16 bộ đệm

Việc xác nhận việc truyền thông qua kênh này của một tập các bộ đệm liên tiếp được máy chủ chỉ ra bằng cách gửi comms_reply APDU với comms_reply_id = Send_Ack và return_value được thiết lập theo nhãn nhận dạng của bộ đệm cuối cùng trong tập các bộ đệm. Tập các bộ đệm được xác nhận để truyền được định nghĩa là comms_reply APDU cuối cùng với comms_reply_id = Send_Ack return_value cộng thêm một (mô đun 16), hoặc không khi không có comms_reply APDU với comms_reply_id = Send_Ack đã được gửi từ khi mở phiên hoặc kết nối kênh, đến comms_reply return_value hiện tại, bao gồm cả hai comms_reply.

CICAM phải dừng gửi comms_send APDU này khi tất cả các bộ đệm đã được gửi đến máy chủ để truyền cho kênh này không được xác nhận. CICAM phải đợi cho đến khi máy chủ xác nhận truyền một tập mới các bộ đệm trước khi gửi thêm comms_send APDU, nếu được yêu cầu.

...

...

...

1) Sau khi một kết nối được thiết lập thành công trên kênh này, CICAM gửi 16 bộ đệm đến máy chủ với comms_phase_id từ 0 đến 15

2) Máy chủ truyền các bộ đệm 0 và 1 (với comms_phase_id = 0 và comms_phase_id = 1)

3) Máy chủ gửi đến CICAM một comms_reply với comms_reply_id = Send_Ack và return_value = 1 để xác nhận việc truyền tập các bộ đệm từ comms_phase_id = 0 đến comms_phase_id = 11

4) Máy chủ truyền các bộ đệm từ 2 đến 12

5) Máy chủ gửi đến CICAM một comms_reply với comms_reply_id = Send_Ack và return_value = 0 để xác nhận việc truyền tập các bộ đệm từ comms_phase_id = 2 đến comms_phase_id = 12

6) CICAM lấp đầy bộ đệm 0 và gửi nó cho máy chủ với comms_phase_id = 0

7) Máy chủ truyền các bộ đệm từ 13 đến 0

8) Máy chủ gửi đến CICAM một comms_reply với comms_reply_id = Send_Ack và return_value = 0 để xác nhận việc truyền tập các bộ đệm từ comms_phase_id = 13 đến comms_phase_id = 0

14.1.5. Yêu cầu đối với bộ đệm

...

...

...

• Máy chủ phải chấp nhận lên đến 16 bộ đệm được CICAM gửi trước khi việc kiểm soát dòng diễn ra

• Số lượng byte tối đa của bản tin trong comms_send () là 2048 byte

• Số lượng byte tối đa của bản tin trong comms_rcv () là 2048 byte

14.1.6. Hành vi ngắt kết nối

Khi một ngắt kết nối được thiết bị đầu cuối mạng khởi tạo, máy chủ phải truyền tất cả các bộ đệm đã nhận được đang chờ đến CICAM và sau đó phải gửi comms_reply () không mong muốn, xem đoạn cuối cùng của điều 8.7.1.5 trong EN 50221 [7]. Phiên truyền tốc độ thấp vẫn mở và CICAM có thể yêu cầu một kết nối khác.

14.1.7. Truyền dữ liệu

Để truyền dữ liệu tải giữa CICAM và một thiết bị đầu cuối mạng thông qua máy chủ, trao đổi các APDU giữa máy chủ và CICAM được yêu cầu như sau:

CICAM chia tải của nó thành các khối có buffer_size byte. Các bộ đệm được lấp đầy hoàn toàn được gửi bằng một comms_send_more () APDU, bộ đệm cuối cùng (một phần hoặc toàn bộ) phải được gửi bằng comms_send_last (). CICAM không được gửi một bộ đệm được lấp đầy một phần bằng một comms_snd_more () APDU. Máy chủ phải cung cấp dữ liệu tải này vào mạng sao cho thiết bị đầu cuối mạng có thể đọc chúng trong một bước.

Máy chủ gửi dữ liệu tải nhận được từ mạng đến CICAM sử dụng comms_rcv_more () hoặc comms_rcv_last () APDU. Máy chủ chia tải của nó thành các khối có buffer_size byte. Các bộ đệm được lấp đầy hoàn toàn được gửi bằng một comms_rcv_more () APDU ngay lập tức. Một bộ đệm được lấp đầy một phần khi thời gian chờ hoặc gần thiết bị đầu cuối mạng phải được gửi bằng một comms_rcv_last () APDU. Đối với một số giao thức, việc gần một thiết bị đầu cuối mạng có thể không được phát hiện một cách đáng tin cậy. CICAM không nên dựa vào comms_rcv_last () APDU để phát hiện sự kết thúc của tải này.

...

...

...

Lớp tài nguyên truyền tốc độ thấp theo quy định tại EN 50221 [7] được nâng cấp để cung cấp truyền hai chiều qua một kết nối IP. Điều này có thể được sử dụng để hỗ trợ các chức năng truy nhập có điều kiện và có thể được sử dụng kết hợp với các dịch vụ tương tác. Phiên bản 2 trở lên của tài nguyên truyền tốc độ thấp bao gồm kết nối IP.

Máy chủ phải có khả năng thiết lập một kết nối IP bên ngoài và quản lý nó.

Ngăn xếp IP của máy chủ phải tuân thủ các tiêu chuẩn sau đây:

RFC768 (UDP)

RFC793 (TCP)

RFC791 (IPv4)

Việc hỗ trợ IPv6 và IPv4 multicast là tùy chọn trên máy chủ.

Việc thực hiện IPv4 multicast phải tuân thủ RFC1112 (IGMPv1). Việc hỗ trợ IPv6 trên máy chủ phải tuân thủ RFC2460 (IPv6) và RFC4443 (ICMPv6).

Đối với tất cả các kết nối multicast, protocol_type trong nhãn mô tả IP phải là UDP.

...

...

...

Máy chủ chỉ hỗ trợ một kết nối cho mỗi phiên, nhưng máy chủ có thể hỗ trợ nhiều phiên song song.

Các bản tin được truyền phải giống như được mô tả trong EN 50221 [7] điều 8.7.

Các nội dung của tải phải theo Network Byte Order.

Hình 14.3 Định dạng gói tin truyền tải

Trên kết nối TCP, máy chủ có thể gửi các tải của các comms_send_more () hoặc comms_send_last () APDU đến mạng ngay lập tức vì TCP cung cấp bộ đệm và truyền đáng tin cậy.

Trên kết nối UDP, máy chủ phải đệm tất cả các tải comms_send_more đến () cho đến khi nó nhận được một comms_send_last () hoặc kích thước của tất cả các tải của bộ đệm vượt quá kích thước của tất cả các bộ đệm gửi sẵn có. Sau đó nó phải gửi dữ liệu này đến mạng trong một bước.

Máy chủ có thể đọc dữ liệu TCP từ mạng trong các khối có độ dài bất kỳ phù hợp cho việc chuyển tiếp dữ liệu trong các comms_rcv_more () và comms_rcv_last () APDU.

Khi đọc dữ liệu UDP từ mạng, máy chủ phải đảm bảo rằng nó đọc một gói hoàn chỉnh và không có dữ liệu bị loại bỏ trong quá trình đọc. Mỗi gói hoàn chỉnh được đọc theo cách này nên được chia thành các comms_rcv_more () và comms_rcv_last () APDU.

...

...

...

Một loại kết nối mới được bổ sung vào đối tượng connection descriptor để cung cấp các thông số dành cho một kết nối IP đối với tài nguyên truyền tốc độ thấp.

Bảng 14.4 - Mã hóa đối tượng connection descriptor

Bảng "connection_descriptor" này được sửa đổi để bao gồm các loại nhãn mô tả dành cho liên kết Ethernet.

Bảng 14.5 - Connection Descriptor Type

connection_descriptor_type

Giá trị của loại

Sl_Telephone_Descriptor

01

...

...

...

02

IP_Descriptor

03

Hostname_descriptor

04

Tất cả các giá trị khác được dự phòng

14.2.1.1. Comms Cmd IP_descriptor

Cú pháp nhãn mô tả IP này được quy định trong Bảng 14.7

...

...

...

Cú pháp

Số bit

Kiểu

IP_descriptor() {
descriptor_tag

descriptor_length
IP_protocol_version
IP_address
destination_port
protocol_type
}

8
8
8
128
16
8

uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf

descriptor_tag: descriptor_tag dành cho IP_descriptor là 0xCF.

descriptor_length: độ dài nhãn mô tả này là một trường 8-bit xác định tổng số byte của phần dữ liệu của IP_descriptor theo sau byte xác định giá trị của trường này.

IP_protocol_version: trường này xác định phiên bản của giao thức IP

...

...

...

IP_Protocol_version

Giá trị của loại

Dự phòng

0x00

IPv4

0x01

IPv6

0x02

Tất cả các giá trị khác được dự phòng

...

...

...

IP_address: trường này xác định địa chỉ IP đích. Trong IPv4,12 byte đầu tiên bằng "0".

destination_Port: trường này xác định cổng đích được máy chủ sử dụng, cổng thu nhận này được máy chủ quản lý.

protocol_type: trường này được sử dụng để xác định giao thức được sử dụng; UDP hoặc TCP.

Bảng 14.8 - Các loại giao thức

protocol_type

Giá trị của loại

Dự phòng

0x00

TCP

...

...

...

UDP

0x02

Tất cả các giá trị khác được dự phòng

0x03-0xFF

14.2.1.2. Comms Cmd Hostname_descriptor

Bảng 14.9 - Hostname_descriptor

Cú pháp

Số bit

Kiểu

...

...

...

8
8
8
16

8

uimsbf
uimsbf
uimsbf
uimsbf

uimsbf

descriptor_tag: descriptor_tag dành cho Hostname_descriptor là 0xCD.

descriptor_length: độ dài nhãn mô tả là một trường 8-bit xác định tổng số byte của phần dữ liệu của hostname_descriptor theo sau byte xác định giá trị của trường này.

protocol_type: trường này được sử dụng để xác định giao thức được sử dụng; UDP hoặc TCP.

destination_Port: trường này xác định cổng đích được máy chủ sử dụng, cổng thu nhận này được máy chủ quản lý.

Hostname_byte: Các byte dữ liệu tạo thành tên của máy chủ, ví dụ FQDN. Tham khảo RFC1123 [40], điều 2.1.

14.2.1.3 Số lượng tối đa các kết nối đồng thời

Một CICAM có thể yêu cầu một máy chủ để mở các phiên truyền tốc độ thấp bổ sung cho phiên truyền hiện tại qua hai hay nhiều kết nối IP. Tùy thuộc vào khả năng của máy chủ, máy chủ có thể chấp nhận hoặc từ chối các kết nối bổ sung này. Việc từ chối có thể biểu hiện bởi chính nó tới CICAM như là một lỗi về việc mở một phiên làm việc mới trên các tài nguyên LSC hoặc như comms_reply (Connect Ack) với một lỗi không rõ ràng (theo phụ lục E.14.1).

...

...

...

Các CICAM phải đủ mạnh để xử lý cả hai tình huống lỗi. Các CICAM nên quản lý số lượng tối đa máy chủ kết nối đồng thời bằng cách đóng các kết nối mà không được sử dụng hoặc yêu cầu một kích thước bộ đệm nhỏ hơn bằng cách gửi một comms_cmd (Set_Params).

14.2.1.4 Hành vi Set_Params

Các comms_cmd () APDU là có liên quan đến lệnh Set_Params như mô tả trong phần 14.1.1. Phần này nêu rõ các hành vi Set Params yêu cầu. Lệnh Set_Params được gửi đi sau khi một comms_cmd (connect_on_channel) trước khi chuyển giao được khởi xướng theo R206-001:1998 [24], như hình dưới đây:

CICAM

Lệnh

Máy chủ

Yêu cầu một phiên với tài nguyên truyền tốc độ thấp

(... open_session ...)

èç

...

...

...

Request for a connection on a channel.

Yêu cầu cho một kết nối trên một kênh

comms_cmd (Connect_on_Channel)

è

Cố gắng kết nối vào kênh

comms_reply (Connect_Ack)

ç

Kết nối được kết thúc với các trạng thái

...

...

...

comms_cmd (Set_Params)

è

comms_reply (Set_Params_Ack)

ç

Các thông số truyền được thiết lập

Sau khi một kết nối thành công được thiết lập, các vấn đề Get_Next_Buffer của CICAM với comms_phase_id thiết lập thành 15, để chỉ báo tới máy chủ rằng các thông số bộ đệm Buffers từ 0 đến 15 có thể được điền vào.

comms_cmd (Get_Next_Buffer, comms_phase_id = 15)

...

...

...

Máy chủ nhận dữ liệu trên kênh

comms_rcv (comms_phase_id = 0, data)

ç

Máy chủ gửi các bộ đệm nhận được sử dụng đối tượng Comms Rcv với giá trị comms_phase_id thiết lập về 0.

14.2.2. Sửa đổi các loại tài nguyên truyền tốc độ thấp

Các giá trị mới của các loại tài nguyên truyền tốc độ thấp được bổ sung để hỗ trợ kết nối IP.

9

8

...

...

...

6

5

4

3

2

1

0

device type (kiểu thiết bị)

device no. (số hiệu thiết bị)

...

...

...

Trường về loại của thiết bị được quy định tại Bảng 14.10

Bảng 14.10 - Các loại thiết bị truyền

Mô tả

Giá trị

Các modem

0x00-0x3F

Các cổng nối tiếp

0x40-0x4F

Kênh trả về của cáp

...

...

...

Dự phòng

0x51-0x5F

Kết nối IP

0x60

Dự phòng

0x61-0xFF

CHÚ THÍCH: Bảng này thay thế điều 8.8.1.1 trong tài liệu EN 50221 [7]

device no. phải là 0 đối với loại thiết bị kết nối IP.

14.3. Tải về phần mềm và tài nguyên nâng cấp CAM

...

...

...

Phần mềm CICAM ngày càng trở nên phức tạp, để đảm bảo chức năng và an ninh của một CICAM trong lĩnh vực này, việc nâng cấp phần mềm có thể là cần thiết. Việc nâng cấp firmware có thể có sẵn trên mạng bằng cách sử dụng thông tin được chứa trong một hoặc nhiều dòng truyền tải.

Các DVB CICAM hiện nay có thể thực hiện việc nâng cấp phần mềm nhưng bản quy định kỹ thuật hiện tại không cung cấp bất kỳ giao diện chuẩn hóa giữa máy chủ và CICAM để phối hợp việc tải về phần mềm. Tiêu chuẩn này giới thiệu một phương pháp chuẩn để xử lý việc nâng cấp phần mềm cho phép CICAM thương lượng với máy chủ và hệ thống CA để thực hiện việc nâng cấp.

Tiêu chuẩn này quy định một giao diện tài nguyên và đảm bảo rằng việc nâng cấp phần mềm không dành cho các phương pháp báo hiệu độc quyền. Phần này xác định về báo hiệu và đồng bộ giữa CICAM và máy chủ, việc truyền và báo hiệu thực tế của việc nâng cấp phần mềm CICAM không được tiêu chuẩn này quy định và có thể sử dụng các cơ chế nâng cấp phần mềm truyền hình tiêu chuẩn như DVB-SSU hoặc cơ chế truyền độc quyền do nhà điều hành hoặc cung cấp CA xác định.

Việc nâng cấp CAM có thể bắt đầu một hoạt động dò kênh của máy chủ dưới sự kiểm soát của CICAM như một phần của quá trình nâng cấp bằng cách sử dụng Host control tune() APDU hoặc Host control tune_broadcast_req() APDU. Tiêu chuẩn này quy định Host control tune() APDU và Host control tune_broadcast_req() APDU.

14.3.2. Các nguyên tắc

Quá trình nâng cấp CICAM xem xét các yêu cầu khác nhau từ:

• Nhà cung cấp CA

• Nhà điều hành dịch vụ

• Máy chủ (TV hoặc thiết bị ghi lại)

...

...

...

Chế độ ngay lập tức được sử dụng khi việc nâng cấp phần mềm được yêu cầu ngay lập tức. CICAM dừng xử lý các dịch vụ được CA bảo vệ cho đến khi một bản nâng cấp đã hoàn thành thành công.

Chế độ trì hoãn được sử dụng khi việc nâng cấp phần mềm có thể được hoãn lại. CICAM tiếp tục xử lý các dịch vụ được CA bảo vệ và cho phép việc nâng cấp lên được dời lại xảy ra tại một thời điểm thích hợp hơn. Điều này có thể được máy chủ tự động xác định, giảm thiểu sự gián đoạn dịch vụ, hoặc được người sử dụng kiểm soát một cách rõ ràng. Việc nâng cấp phần mềm chế độ trì hoãn có thể được một số phiên bản khác hoặc một số tiêu chí của hệ thống CA khác xác định.

CICAM không được thực hiện bất kỳ yêu cầu nâng cấp phần mềm trừ khi một dịch vụ CA đã được một ca_pmt lựa chọn. CICAM này có thể trên một transponder truyền hoặc thông báo tính sẵn sàng nâng cấp phần mềm, trừ khi một dịch vụ CA hiện đang được chọn thì CICAM không được bắt đầu bất kỳ sự tương tác về nâng cấp. CICAM có thể âm thầm tiến hành việc tải về bản nâng cấp với điều kiện là không có sự gián đoạn đối với dòng truyền tải và biết rằng transponder này có thể bị thay đổi bất cứ lúc nào.

14.3.3. Quá trình nâng cấp CAM

Quá trình nâng cấp phần mềm cơ bản này được thể hiện trong Hình 14.5 theo một trình tự các bước sau:

Hình 14.5 - Quá trình nâng cấp CAM

Quá trình này được quy định như sau:

1) Chờ đợi một tín hiệu kích hoạt thông báo tính sẵn có của việc nâng cấp phần mềm mới dành cho CICAM. Hệ thống CA và nhà điều hành dịch vụ xác định cách hệ thống thiết bị đầu cuối thông báo tính sẵn có của việc nâng cấp firmware đến CICAM đã được công nhận trong hệ thống truyền hình.

...

...

...

3) Tài nguyên CAM_upgrade được mở ra và CICAM thông báo cho máy chủ về tính sẵn có của việc nâng cấp phần mềm bao gồm cả chế độ nâng cấp. CICAM chờ đợi máy chủ trả lời để xác định cách nâng cấp được tiến hành.

4) Chế độ tải về và trả lời của máy chủ xác định cách CICAM phải xử lý việc tải về phần mềm có thể được bắt đầu.

14.3.3.1. Quá trình bị trì hoãn

Hình 14.6 - Quá trình bị trì hoãn

Khi việc nâng cấp bị trì hoãn được Thiết bị đầu cuối yêu cầu, quá trình trì hoãn được bắt đầu ngay sau khi CICAM nhận được trả lời từ máy chủ.

Tùy theo trả lời của máy chủ, CICAM có các trạng thái sau:

Nếu trả lời của máy chủ là "Không" thì CICAM đóng phiên CAM_upgrade và quá trình CAM_upgrade bị dừng lại.

Nếu trả lời của máy chủ là "Có" thì CICAM tùy chọn mở một phiên họp về DVB Host Control để gửi một bản tin yêu cầu dò kênh và thực hiện tải phần mềm về CICAM

...

...

...

14.3.3.2. Quá trình ngay lập tức

Hình 14.7 - Quá trình ngay lập tức

Khi việc nâng cấp ngay lập tức được thiết bị đầu cuối yêu cầu thì CICAM dừng việc giải xáo trộn CA cho đến khi việc nâng cấp đã nhận được và cài đặt thành công, quá trình này được thể hiện trong hình 14.7.

CICAM thông báo cho máy chủ việc nâng cấp bằng cách sử dụng tài nguyên CAM_upgrade và chờ đợi trả lời này để xử lý như sau:

Khi máy chủ trả lời là "Có" CICAM khởi tạo quá trình nâng cấp phần mềm ngay lập tức. Điều này có thể yêu cầu CICAM mở một phiên đến tài nguyên Host Control Tune để thực hiện hoạt động dò kênh để có được việc nâng cấp này.

Khi máy chủ trả lời là "Hỏi" CICAM hiển thị một cuộc đối thoại MMI để thông báo cho người sử dụng về tính sẵn có của việc nâng cấp và yêu cầu sự cho phép để thực hiện nâng cấp. CICAM hoặc phải tiếp tục nâng cấp hoặc dừng quá trình này phụ thuộc vào trả lời của người sử dụng (chấp nhận hoặc từ chối). Khi việc nâng cấp bị dừng lại, người sử dụng chỉ có thể dò kênh đến dịch vụ FTA vì không có dịch vụ CA nào được giải xáo trộn. Khi người sử dụng chấp nhận nâng cấp thì máy chủ phải cho phép việc nâng cấp phần mềm được hoàn thành, tùy chọn hiển thị thanh chỉ thị quá trình này. Việc can thiệp của người sử dụng phải bị vô hiệu cho đến khi việc nâng cấp đã hoàn thành.

14.3.4. Giao thức nâng cấp CAM

14.3.4.1. Chế độ trì hoãn

...

...

...

Máy chủ phải trả lời yêu cầu này bằng một cam_firmware_upgrade_reply bao gồm một trạng thái trong tham số ‘answer’, chế độ hoạt động này của máy chủ có khả năng để xác định trả lời tức là kiểm soát của người sử dụng hoặc tự động/không giám sát. CICAM sẽ sử dụng trả lời của máy chủ để xác định cách để tiếp tục quá trình nâng cấp.

Nếu việc nâng cấp này đã được chấp nhận thì trước tiên CICAM phải gửi bản tin cam_firmware_upgrade_progress để chỉ ra rằng một quá trình nâng cấp phần mềm đã bắt đầu. Sau đó CICAM có thể sử dụng các DVB Host Control APDU để gửi một hoặc nhiều yêu cầu tune () hoặc tune_broadcast () để xác định vị trí và lựa chọn dịch vụ tải về, sau đó quá trình tải về phải được thông báo mỗi 20 giây bằng những bản tin cam_firmware_upgrade_progress. Khi quá trình nâng cấp đã hoàn thành thì CICAM gửi cam_firmware_upgrade_complete APDU.

Nếu việc nâng cấp không được chấp nhận nó có thể được cố thử lại lần tiếp theo, máy chủ lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp. CICAM không được cố thử lại một nâng cấp trước thời điểm này. CICAM có thể lựa chọn để trì hoãn một cố thử nâng cấp cho đến một thời gian sau khi máy chủ một lần nữa lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp.

cam_firmware_upgrade_complete APDU chỉ ra cho HOST xem có yêu cầu thiết lập lại CICAM để hoàn thành quá trình nâng cấp. Khi nhận được cam_firmware_upgrade_complete APDU, máy chủ phải thực hiện bất kỳ việc thiết lập lại được yêu cầu và có thể lấy lại việc kiểm soát bộ dò kênh.

Máy chủ phải tránh tương tác của người sử dụng ảnh hưởng đến việc tải xuống ngay sau khi đã nhận được cam_firmware_upgrade_ APDU đầu tiên và cho đến khi nhận được một cam_firmware_upgrade_complete. Nếu máy chủ không nhận được cam_firmware_upgrade_progress APDU trong khoảng thời gian 60 giây thì nó có thể giả định rằng CICAM đã thất bại và cố gắng khôi phục hồi máy chủ.

Trình tự nâng cấp bị trì hoãn được thể hiện trong hình 14.8.

Hình 14.8 - Giao thức nâng cấp bị trì hoãn

14.3.4.2. Chế độ ngay lập tức

...

...

...

Khi nhận được, máy chủ trả lời bằng một cam_firmware_upgrade_reply chỉ ra rằng máy chủ sẵn sàng bằng tham số 'answer'. Tùy thuộc vào trả lời từ máy chủ mà CICAM phải dừng việc thương lượng nâng cấp hoặc tiến hành để bắt đầu quá trình nâng cấp.

Nếu việc nâng cấp này đã được chấp nhận thì trước tiên CICAM phải gửi bản tin cam_firmware_upgrade_progress để chỉ ra rằng một quá trình nâng cấp phần mềm đã bắt đầu. Sau đó CICAM có thể sử dụng các DVB Host Control APDU để gửi một hoặc nhiều yêu cầu tune() để xác định vị trí và lựa chọn dịch vụ tải về, sau đó quá trình tải về phải được thông báo mỗi 20 giây bằng những bản tin cam_firmware_upgrade_progress. Khi quá trình nâng cấp đã hoàn thành thì CICAM gửi cam_firmware_upgrade_complete APDU.

Nếu việc nâng cấp này không được chấp nhận thì nó có thể cố thử lại lần tiếp theo, máy chủ lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp. CICAM không được cố thử lại một nâng cấp trước thời điểm này. CICAM có thể lựa chọn để trì hoãn một nỗ lực nâng cấp cho đến một thời gian sau khi máy chủ một lần nữa lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp.

cam_firmware_upgrade_complete APDU chỉ ra cho HOST xem có yêu cầu thiết lập lại CICAM để hoàn thành quá trình nâng cấp. Khi nhận được cam_firmware_upgrade_complete APDU, máy chủ phải thực hiện bất kỳ việc thiết lập lại được yêu cầu và có thể lấy lại việc kiểm soát bộ dò kênh.

Hình 14.9 - Giao thức nâng cấp ngay lập tức

Máy chủ phải tránh tương tác của người sử dụng ảnh hưởng đến việc tải xuống ngay sau khi đã nhận được cam_firmware_upgrade_APDU đầu tiên và cho đến khi nhận được một cam_firmware_upgrade_complete. Nếu máy chủ không nhận được cam_firmware_upgrade_progress APDU trong khoảng thời gian 60 giây thì nó có thể giả định rằng CICAM đã thất bại và cố gắng khôi phục hồi máy chủ.

14.3.4.3. Gián đoạn nâng cấp

Quá trình nâng cấp CICAM có thể bị gián đoạn vì một số lý do:

...

...

...

• Tắt nguồn điện

CICAM bị thiết lập lại

Một quá trình nâng cấp CICAM, không phân biệt chế độ, phải được khởi tạo lại hoàn toàn khi dịch vụ CA System ID được lựa chọn.

Tắt nguồn điện/khôi phục

Máy chủ và CICAM có thể bị ảnh hưởng của sự cố tắt nguồn điện bất cứ lúc nào trong hoạt động nâng cấp, CICAM phải có khả năng phục hồi và bắt đầu việc nâng cấp khi lựa chọn một dịch vụ CA System ID. CICAM không được khôi phục việc nâng cấp có gây ra bất kỳ sự gián đoạn của dòng truyền tải hoặc người sử dụng (thông qua các bản tin MMI) khi không lựa chọn một dịch vụ CA System ID.

14.3.4.4. Thực hiện thiết lập lại

Khi CICAM đã hoàn thành việc nâng cấp firmware, nó phải gửi cam_firmware_upgrade_complete APDU với loại thiết lập lại thích hợp.

14.3.4.5. Hoạt động của máy chủ

1) Máy chủ phải hỗ trợ tài nguyên CAM_upgrade và quản lý DVB Host Control Resource

...

...

...

3) Trả lời của máy chủ đối với bản tin cam_firmware_upgrade_reply phải tuân theo Bảng 14.12:

Bảng 14.11 - Các trạng thái trả lời nâng cấp của máy chủ

Xử lý sau

Xử lý ngay lập tức

Chế độ người dùng

Hỏi

Hỏi

Chế độ tự động

...

...

...

Có

Chế độ dịch vụ

Có

Có

4) Trong chế độ hoạt động bình thường (chế độ người sử dụng), trả lời phải là ASK (0x02). Điều này có nghĩa rằng người sử dụng đang xem một dịch vụ CA và CICAM cung cấp một dấu hiệu về tính sẵn có của việc nâng cấp cho người sử dụng.

5) Trong chế độ tự động (tức là ghi lại), trong chế độ nâng cấp trì hoãn, trả lời có khả năng là NO (0x00) cho phép việc ghi lại tiếp tục mà không bị gián đoạn, bất kỳ việc nâng cấp sẽ bị trì hoãn đến một thời gian sau này thuận tiện nhiều hơn. Đối với chế độ nâng cấp ngay lập tức thì trả lời phải là CÓ (0x01), trong đó việc nâng cấp phải được bắt đầu ngay khi có thể và có thể dẫn đến một phần của bất kỳ chương trình bị bỏ qua.

6) Trong chế độ dịch vụ (tức là nâng cấp phần mềm máy chủ, phát triển mạng v.v..) trả lời có thể là có (0x01) dành cho tất cả các loại quá trình nâng cấp và CICAM có thể bắt đầu quá trình nâng cấp ngay lập tức.

7) CICAM phải quản lý các thông báo quá trình này cho người sử dụng bằng có sử dụng MMI.

8) Máy chủ quản lý việc thiết lập lại CICAM khi hoàn thành việc nâng cấp và máy chủ phải trở lại hoạt động bình thường với CICAM trong tất cả các khía cạnh, bao gồm cả hoạt động thời gian chờ và thiết lập lại.

...

...

...

Nếu CICAM hủy bỏ nâng cấp phần mềm thì nó phải gửi cam_firmware_upgrade_complete APDU với loại thiết lập lại được thiết lập là 0x02 "không yêu cầu thiết lập lại".

14.3.5. Tài nguyên CAM_Upgrade

Tài nguyên CAM_Upgrade cho phép CICAM phối hợp quá trình nâng cấp phần mềm CICAM với máy chủ. Các bản tin này cho phép CICAM bắt đầu tải xuống với một số thỏa thuận từ thiết bị máy chủ, thông báo quá trình nâng cấp này và cuối cùng thông báo hoàn thành. Máy chủ được cung cấp những thông tin về sự cấp thiết của việc nâng cấp để cho máy chủ xác định khi nào yêu cầu sự can thiệp của người sử dụng phụ thuộc vào chế độ hoạt động hiện tại của nó.

14.3.5.1. Các APDU của tài nguyên CAM_Upgrade

CICAM mở tài nguyên CAM_Upgrade khi việc nâng cấp firmware được yêu cầu. Tài nguyên CAM_Upgrade hỗ trợ các đối tượng sau:

Bảng 14.12 - Các CAM_Upgrade APDU

CAM Upgrade APDU

Chiều

cam_firmware_upgrade

...

...

...

cam_firmware_upgrade_reply

CICAM □ □ HOST

cam_firmware_upgrade_progress

CICAM □ □ HOST

cam_firmware_upgrade_complete

CICAM □ □ HOST

14.3.5.2. cam_firmware_upgrade APDU

CICAM phải truyền cam_firmware_upgrade APDU này đến máy chủ để thông báo cho nó về chế độ nâng cấp được hệ thống CA hoặc nhà điều hành hệ thống yêu cầu. Đối tượng này bao gồm thông tin về sự cấp thiết của việc tải về và thời gian hoàn thành dự kiến.

Bảng 14.13 - Cú pháp đối tượng nâng cấp Firmware

...

...

...

Số bit

Kiểu

cam_firmware_upgrade() {
cam firmware upgrade tag
length_field()
upgrade_type
download time
}

24

8
16

uimsbf

uimsbf
uimsbf

cam_firmware_upgrade_tag: xem Bảng L.1 tại Phụ lục L.

upgrade_type: tham số này xác định loại nâng cấp phần mềm CAM được yêu cầu:

0x00: Chế độ nâng cấp trì hoãn

0x01: Chế độ nâng cấp ngay lập tức

...

...

...

14.3.5.3. cam_firmware_upgrade_reply APDU

Máy chủ trả lời cam_firmware_upgrade APDU. CICAM không được bắt đầu hoạt động tải về này cho đến khi nó nhận được trả lời này.

Bảng 14.14 - Cú pháp APDU trả lời nâng cấp Firmware

Cú pháp

Số bit

Kiểu

cam_firmware_upgrade_reply() {
cam_firmware_upgrade_reply_tag
length_field()
answer
}

24

8

uimsbf

uimsbf

...

...

...

answer: Trả lời của máy chủ có các giá trị có thể sau đây:

• 0x00 có nghĩa là KHÔNG/NO.

• 0x01 có nghĩa là CÓ/YES.

• 0x02 có nghĩa là HỎI/ASK người sử dụng. CICAM phải mở hội thoại MMI để nhận được trả lời của người sử dụng.

• 0x03-0xFF dự phòng trong tương lai.

14.3.5.4. cam_firmware_upgrade_progress APDU

Sau khi CICAM đã bắt đầu việc nâng cấp của nó, nó truyền cam_firmware_upgrade_progress () APDU đến máy chủ để thông báo cho nó về quá trình tải về phần mềm. Bản tin này được gửi theo định kỳ 20 giây, từ CICAM đến máy chủ. Máy chủ sử dụng đối tượng này để đảm bảo rằng CICAM vẫn còn hoạt động trong quá trình nâng cấp phần mềm. Nếu không nhận được đối tượng này (và cập nhật) trong một thời gian quá 60 giây trong suốt thời gian tải về thì máy chủ có thể cố thử khôi phục CICAM bằng cách thiết lập lại v.v..

Bảng 14.15 - Cú pháp APDU quá trình nâng cấp Firmware

Cú pháp

...

...

...

Kiểu

cam_firmware_upgrade__progress() {
cam_firmware_upgrade_progress_tag
length_field()
download_progress_status
}

24

8

uimsbf

uimsbf

cam_firmware_upgrade_progress_tag: xem Bảng L.1 tại Phụ lục L.

download_progres_status: giá trị phần trăm của quá trình nâng cấp CAM, trong khoảng từ 0 đến 100 (tức là một tỷ lệ phần trăm hoàn thành).

14.3.5.5. cam_firmware_upgrade_complete APDU

Khi CICAM đã hoàn thành việc nâng cấp của nó, nó truyền cam_firmware_upgrade_complete () APDU đến máy chủ. Đối tượng này thông báo cho máy chủ rằng việc nâng cấp đã hoàn thành và xem CICAM có yêu cầu thiết lập lại. Bất kỳ các tài nguyên kiểm soát máy chủ được sử dụng trong quá trình nâng cấp phải được CICAM đóng trước khi gửi đối tượng này.

Bảng 14.16 - Cú pháp APDU hoàn thành nâng cấp Firmware

...

...

...

Số bit

Kiểu

cam_firmware_upgrade_complete() {
cam_firmware_upgrade_complete_tag
length_field()
reset_request_status
}

24

8

uimsbf

uimsbf

cam_firmware_upgrade_complete_tag: xem Bảng L.1 tại Phụ lục L.

reset_request_status: trường này chứa trạng thái thiết lập lại dành cho CICAM.

Bảng 14.17 - Các loại reset_request_status

Giá trị

...

...

...

0x00

thiết lập lại PCMCIA được yêu cầu - Máy chủ thiết lập tín hiệu thiết lập lại là hoạt động sau đó là không hoạt động.

0x01

thiết lập lại CI Plus CAM được yêu cầu - Máy chủ thiết lập cờ RS và bắt đầu khởi tạo giao diện

0x02

thiết lập lại không được yêu cầu - Hoạt động bình thường vẫn tiếp tục

0x03 - 0xFF

Dự phòng

CHÚ THÍCH: Nếu CICAM muốn hủy nâng cấp firmware, nó có thể gửi APDU cam_firmware_upgrade_complete APDU với yêu cầu không thiết lặp lại. Máy chủ nhận được APDU này vẫn phải tiếp tục hoạt động bình thường.

...

...

...

Tài nguyên MMI ứng dụng, TS 101 699 [8], được mở rộng để cho phép trao đổi tập tin và dữ liệu theo cả hai hướng, điều này cho phép thông tin trạng thái được trả về từ miền ứng dụng đến mô-đun này. Những phần mở rộng chỉ được miền ứng dụng CI Plus sử dụng để truyền tập tin hoặc thông tin ống dữ liệu riêng. Phiên bản tài nguyên MMI ứng dụng này vẫn là 1 và các phần mở rộng CI Plus xác định các quy tắc đặt tên tập tin phải được sử dụng trong miền ứng dụng CI Plus "CIEngineProfile1".

14.4.1. Quy tắc đặt tên tập tin

Máy chủ phải luôn luôn bao gồm "CI://" ở phần đầu của bất kỳ một tên của tập tin nào được sử dụng trong hoạt động với tập tin tài nguyên MMI ứng dụng để đảm bảo khả năng phối hợp với các CICAM hiện có. Bất kỳ đường dẫn đưa vào một tên của tập tin phải được phân tích hoàn toàn, nó không được chứa thành phần đường dẫn tương đối ví dụ như "..". Để đảm bảo khả năng phối hợp với các máy chủ hiện có, CICAM phải phân tích được bất kỳ tham chiếu của tập tin MHEG sau:

• /mydir/myfile

• //mydir/myfile

• /myfile

• //myfile

• CI:/mydir/myfile

• CI://mydir/myfile

...

...

...

• CI://myfile

14.4.2. FileRequest

Bản tin FileRequest được mở rộng (xem Bảng 14.18) để cho phép việc truyền tải này đến mô đun yêu cầu tập tin này theo quy định tại TS 101 699 [8] hoặc để thiết lập một ống dữ liệu riêng giữa máy chủ và mô-đun này.

Các ứng dụng có thể thực hiện không đồng bộ các yêu cầu tập tin của loại tập tin và nhiều FileRequests có thể được máy chủ gửi mà không cần chờ đợi một FileAcknowledge (tức là các yêu cầu tập tin không phải là tuần tự). CICAM phải xếp hàng các yêu cầu và trả về một FileAcknowledge cho mỗi FileRequest. CICAM tối thiểu phải có khả năng quản lý 8 FileRequests tại một thời điểm.

Đối với các bản tin của loại tập tin, FileResponse phải trả về dữ liệu ngay khi nó trở nên có sẵn, điều này có thể dẫn đến các bản tin FileResponse được nhận được theo một trật tự khác với các yêu cầu ban đầu. Bản tin của loại dữ liệu phải giữ theo trật tự và phải được CICAM xử lý theo trình tự và trả về một FileAcknowlegde theo thứ tự giống như FileRequest.

Bảng 14.18 - Bản tin FileRequest

Cú pháp

Số bit

Kiểu

...

...

...

24

8

8





8

uimsbf

bslbf

bslbf





bslbf

RequestType: Trường 8 bit này xác định loại yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bảng 14.19.

Bảng 14.19 - Các giá trị RequestType trong FileRequest

RequestType

Giá trị

Tập tin (File)

0x00

Dữ liệu (Data)

...

...

...

Dự phòng

0x02-0xff

FileNameByte: Một byte của tên tập tin được yêu cầu hoặc một byte của ống dữ liệu để trả về mô đun. Diễn giải của byte được xác định trong phần RequestType.

DataByte: Một byte của dữ liệu được gửi đến mô đun này.

14.4.3. File Acknowledge

FileAcknowledge được mở rộng (xem Bảng 14.20) để cho phép mô-đun này để trả về các byte của tập tin được yêu cầu hoặc ống dữ liệu đến máy chủ dành cho các bản tin MMI ứng dụng CI Plus.

Bảng 14.20 - Bản tin FileAcknowledge

Cú pháp

Số bit

...

...

...

FileAck() {
FileAckTag
length_field()
Reserved
FileOK
RequestType
if (RequestType == File) {
FileNameLength
for (i=0; i<FileNameLength; i++) {
FileNameByte
}
FileDataLength
for (i=0; i<FileDataLength; i++) {
FileDataByte
}
}
if (RequestType == Data) {
for (i=0; i<(n-1); i++) {
DataByte
}
}
}

24

7
1
8

8

8

32

8





8

uimsbf

bslbf
bslbf
bslbf

uimsbf

bslbf

uimsbf

bslbf





bslbf

FileOK: Trường 1 bit này được thiết lập là "1" nếu tập tin này có sẵn hay là một trả lời để xác nhận bản tin FileRequest có RequestType là dữ liệu, nếu khác nó phải là "0".

RequestType: Trường 8 bit này xác định kiểu yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bảng 14.21

Bảng 14.21 - Các giá trị của RequestType trong FileAcknowledge

RequestType

Giá trị

Tập tin (File)

...

...

...

Dữ liệu( Data)

0x01

Dự phòng

0x02-0xff

FileNameLength: số byte trong tên tập tin.

FileNameByte: Tên của tập tin mà máy chủ yêu cầu. Điều này cho phép máy chủ yêu cầu việc truyền nhiều tập tin không đồng bộ trước khi xác nhận nhận được vì xác nhận này xác định tập tin của yêu cầu ban đầu. Tên tập tin được trả về phải giống như tên được cung cấp trong FileRequest ban đầu.

FileDataLength: Độ dài của nội dung của tập tin theo byte.

FileDataByte: Một byte của dữ liệu tập tin được lấy ra. Lưu ý rằng các APDU không bị giới hạn ở 65535 byte. Xem Phụ lục E.9.

DataByte: Một byte của dữ liệu đã được gửi đến máy chủ.

...

...

...

Máy chủ hoặc mô-đun này có thể ngăn chặn trước miền ứng dụng CI Plus, nó có thể được loại bỏ ngay lập tức mà không cần chờ đợi một AppAbortAcknowledge. Máy chủ phải gửi một AppAbortRequest APDU đến CICAM khi ứng dụng này bị đóng, điều này bao gồm, nhưng không giới hạn, khi công cụ ứng dụng này bị máy chủ từ chối cho phép bắt đầu, ứng dụng không được bắt đầu, ứng dụng thoát ra thông qua một lỗi hoặc khi ứng dụng tự nhiên thoát ra. AppAbortRequest hủy bỏ các mã dành cho miền ứng dụng CI Plus được quy định tại Bảng 14.22.

CICAM nên kết thúc bất kỳ ứng dụng đang chạy hiện tại một cách rõ ràng bằng một AppAbortRequest trước khi bắt đầu một ứng dụng mới với Requeststart vì thứ tự của một AppAbortRequest (ứng dụng hiện tại bị đóng) và RequestStartAck (ứng dụng mới bắt đầu) có thể không được máy chủ bảo đảm.

Bảng 14.22 - Các mã hủy bỏ ứng dụng

AbortReqCode

Ý nghĩa

0x00

Dự phòng.

0x01

Hủy bỏ bởi người sử dụng -Người sử dụng khởi đầu sự kết thúc của miền ứng dụng.

...

...

...

Hủy bỏ bởi hệ thống - Hệ thống xóa miền ứng dụng để thực hiện nhiệm vụ khác.

0x03-0xff

Dự phòng.

14.5. Tài nguyên MMI ứng dụng v2

Tài nguyên MMI ứng dụng, TS 101 699 [8], được mở rộng cho phép lưu trữ nội dung trong thiết bị máy chủ để tăng tốc độ thực hiện ứng dụng CI. Những phần mở rộng này chỉ được miền ứng dụng CI Plus sử dụng để truyền tập tin hoặc thông tin ống dữ liệu riêng với phiên bản 2 của tài nguyên MMI ứng dụng.

Cơ chế lưu trữ được một RequestType mới gọi là FileHash cung cấp, cho phép máy chủ để tính toán một mã băm MD5 của nội dung tập tin và cho phép máy chủ yêu cầu một tập tin từ CICAM với cả tên tập tin và một mã băm nội dung được máy chủ tính. Khi nhận được yêu cầu FileHash, CICAM sử dụng mã băm của tập tin để xác định xem nội dung tập tin đã thay đổi, nếu mã băm của tập tin được CICAM tính giống mã băm trong yêu cầu bản tin thì nội dung tập tin không được trả về cho máy chủ và một chỉ thị được cung cấp trong bản tin trả lời cho biết rằng nội dung tập tin vẫn không thay đổi. Nếu mã băm tập tin là khác thì CICAM trả về các nội dung tập tin mới.

Cơ chế mã băm tập tin này cho phép băng thông giữa máy chủ và CICAM được giảm khi nội dung hiện có đã thu được từ đó tăng tốc độ thực hiện ứng dụng.

Tài nguyên MMI ứng dụng v2 cũng bao gồm một cơ chế dành cho RequestType được mở rộng trong tương lai mà không cần thiết phải tăng phiên bản của tài nguyên.

Yêu cầu CICAM hỗ trợ phiên bản v1 và v2 của tài nguyên MMI ứng dụng. Yêu cầu máy chủ hỗ trợ tài nguyên MMI ứng dụng v1 và có thể tùy chọn hỗ trợ v2 ngoài v1. Trừ khi có quy định khác, hành vi của tài nguyên MMI ứng dụng v1 giống với tài nguyên MMI ứng dụng v2 dành cho RequestType tập tin và dữ liệu.

...

...

...

Bản tin FileRequest được mở rộng (xem Bảng 14.23) để bao gồm hỗ trợ việc truyền tập tin được băm Cú pháp giống hệt với phiên bản 1 dành cho RequestType tập tin và dữ liệu.

Các ứng dụng có thể thực hiện không đồng bộ các yêu cầu tập tin của loại tập tin và FileHash. Nhiều FileRequest có thể được máy chủ cung cấp mà không cần chờ đợi một FileAcknowledge (tức là yêu cầu tập tin không phải là tuần tự). CICAM phải xếp hàng theo yêu cầu và trả về một FileAcknowledge cho mỗi FileRequest. CICAM phải có khả năng tối thiểu quản lý 8 FileRequest tại một thời điểm.

Đối với các bản tin của loại tập tin và FileHash, FileResponse phải trả về dữ liệu ngay khi nó có sẵn, điều này có thể dẫn đến việc các bản tin FileResponse nhận được trong một thứ tự khác so với yêu cầu ban đầu. Các bản tin của loại dữ liệu phải giữ theo trật tự và phải được CICAM xử lý theo trình tự và trả về một FileAcknowlegde theo thứ tự giống như FileRequest.

Bảng 14.23 - Bản tin FileRequest

Cú pháp

Số bit

Kiểu

FileReq() {
FileReqTag
length_field()
RequestType
if (RequestType == File) {
for (i=0; i<(n-1); i++) {
FileNameByte
}
}
if (RequestType == Data) {
for (i=0; i<(n-1): i++) {
DataByte
}
}
if (RequestType == FileHash) {
FileHash
for (i=0; i<(n-17); i++) {
FileNameByte
}
}
}

24

8


8




8



128

8

...

...

...

RequestType: trường 8-bit này xác định loại của yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bảng 14.24. Máy chủ không được gửi bất kỳ loại yêu cầu nào khác với tập tin (0x00), dữ liệu (0x01) hoặc FileHash (0x02) trừ khi khả năng tương thích với CICAM đã được xác nhận, tham khảo điều 14.4.4, Khôi phục loại yêu cầu v2.

Bảng 14.24 - Các giá trị RequestType

RequestType

Mô tả

Giá trị

File

Một file đang được yêu cầu mà không có bất kỳ điều khiển phiên bản

0x00

Data

...

...

...

0x01

FileHash

Một file đang được yêu cầu với trường phiên bản bị hỏng.

0x02

ReqTypes

Một danh sách các RequestType được hỗ trợ đang được yêu cầu

0x03

Dự phòng

Dự phòng

...

...

...

Định nghĩa bởi người sử dụng

Định nghĩa bởi người sử dụng

0x80-0xff

FileNameByte: Một byte của tên tập tin được yêu cầu hoặc một ống byte dữ liệu để gửi đến mô-đun này. Diễn giải của byte được xác định trong phần RequestType.

DataByte: Một byte của dữ liệu được gửi đến mô-đun này.

FileHash: trường 128-bit này được thiết lập theo mã băm MD5 của các nội dung của tập tin này trên máy chủ với tên tập tin được gửi trong bản tin này. Thuật toán MD5 được định nghĩa trong RFC 1321.

14.5.2. FileAcknowledge v2

FileAcknowledge được mở rộng (xem Bảng 14.25) để cho phép mô-đun này trả về các byte của tập tin yêu cầu hoặc ống dữ liệu đến máy chủ dành cho các bản tin MMI ứng dụng CI Plus. Một trạng thái mở rộng của yêu cầu ban đầu được bao gồm trong bản tin trả lời phiên bản 2.

Bảng 14.25 - Bản tin FileAcknowledge

...

...

...

Số bit

Kiểu

FileAck() {
FileAckTag
length_field()
Reserved_zero
RequestOK
FileOK
RequestType
if (RequestType == File) II (RequestType == FileHash) {
FileNameLength
for (i=0; i<FileNameLength; i++) {
FileNameByte
}
FileDataLength
for (i=0; i<FileDataLength; i++) { FileDataByte
}
}
if (RequestType == Data) {for (i=0; i<(n-1); i++) {
DataByte
}
}
if (RequestType == ReqTypes) {for (i=0; i<(n-1); i++) {
ReqTypeByte
}
}
}

24

6
1
1
8


8
8

32

8


8




8

uimsbf

bslbf
bslbf
bslbf
uimsbf


uimsbf
bslbf

uimsbf

bslbf


bslbf




uimsbf

Reserved_zero: trường 6-bit này được dự phòng trong tương lai và phải được thiết lập là không.

RequestOK: trường 1-bit này chỉ được phân tích trong phạm vi của một RequestType theo Bảng 14.26. Trường này được thiết lập là "0" khi giá trị trường này là không sử dụng.

Bảng 14.26 - Giá trí trạng thái RequestOK

RequestType

...

...

...

RequestOK=0

RequestOK=1

0x00

File

Không sử dụng, giá trị trường bị bỏ qua.

0x01

Data

Không sử dụng, giá trị trường bị bỏ qua.

0x02

...

...

...

Yêu cầu không thành công vì không tìm thấy file hoặc yêu cầu không hợp lệ.

Yêu cầu thành công, trường FileOK cho biết liệu file đó đã thay đổi hay chưa.

0x03

ReqTypes

Không sử dụng, giá trị trường bị bỏ qua.

0x04-0xff

Dự phòng

Không sử dụng, giá trị trường bị bỏ qua.

FileOK: trường 1-bit này chỉ được phân tích trong phạm vi của một RequestType theo Bảng 14.27. Trường này được thiết lập là "0" khi RequestType không xác định.

...

...

...

RequestType

Request

FileOK=0

FileOK=1

0x00

File

File không tìm thấy hoặc không có sẵn.

File được yêu cầu có sẵn để dùng và các nội dung được gộp vào trong bản tin xác nhận.

0x01

...

...

...

Dữ liệu không tìm thấy hoặc không có sẵn.

Đây là một trả lời xác nhận thành công và nội dung dữ liệu có thể được gộp vào trong bản tin xác nhận.

0x02

FileHash

Khi RequestOK=1 các nội dụng file chưa thay đổi và phù hợp với file hash.

Khi RequestOK=0 yêu cầu không thành công.

Các nội dung file đã thay đổi và không phù hợp với file hash được yêu cầu. Các nội dung file mới được gộp vào trong bản tin xác nhận này.

0x03

ReqTypes

...

...

...

Đây là một trả lời xác nhận thành công và bản tin chứa một danh sách các RequestType được hỗ trợ của CICAM.

0x04-0xff

Dự phòng

Lệnh không biết hoặc không thành công.

Không được dành cho mục đích khác.

RequestType: trường 8-bit này xác định loại yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bảng 14.24.

FileNameLength: số byte trong tên tập tin.

FileNameByte: Tên của tập tin mà máy chủ yêu cầu. Việc trả về tên tập tin được yêu cầu cho phép máy chủ để yêu cầu không đồng nghĩa việc truyền nhiều tập tin trước khi nhận được xác nhận vì xác nhận này xác định tập tin được yêu cầu ban đầu. Tên tập tin được trả về phải giống như tên được cung cấp trong FileRequest ban đầu.

FileDataLength: Độ dài của các nội dung của tập tin này theo byte. Trường này phải được thiết lập là không trên RequestType của FileHash khi tập tin hiện có trên CICAM và FileHash của máy chủ giống mã băm của tập tin của CICAM tức là khi thông tin trạng thái được trả về là RequestOK = 1 và FileOK = 0.

...

...

...

DataByte: Một byte của dữ liệu đã được gửi đến máy chủ.

ReqTypeByte: trường 8-bit này chứa RequestType được CICAM hỗ trợ. Mỗi RequestType được CICAM hỗ trợ phải được bao gồm trong trả lời và phải được trình bày theo thứ tự số tăng dần.

14.5.3. Khôi phục RequestType v2

Phiên bản 2 của tài nguyên MMI ứng dụng cho phép máy chủ truy vấn các RequestType được CICAM hỗ trợ để cho phép các RequestType bổ sung được thêm vào tài nguyên MMI ứng dụng mà không cần phải tăng phiên bản của tài nguyên. Máy chủ chỉ được sử dụng các RequestType tập tin, dữ liệu, FileHash và ReqTypes. Các RequestType khác với tập tin, dữ liệu, FileHash và ReqTypes chỉ có thể được máy chủ sử dụng sau khi truy vấn CICAM để xác nhận sự hiện có của RequestType được yêu cầu. RequestType này có thể không được máy chủ sử dụng nếu nó không được CICAM thông báo. CICAM phải chắc chắn về sự hiện có của một RequestType không xác định và phải luôn luôn trả lại trạng thái của FileOK là "0".

Để truy vấn các RequestType được CICAM hỗ trợ thì máy chủ gửi một bản tin FileRequest () với một RequestType ReqTypes là (0x03). CICAM phải trả lời bằng một bản tin FileAcknowledge () với một RequestType ReqTypes là (0x03), trường FileOK được thiết lập là "1" và trường ReqTypeByte này bao gồm mỗi RequestType được CICAM hỗ trợ và được sắp xếp theo thứ tự tăng dần, tức là nếu CICAM hỗ trợ tập tin, dữ liệu, FileHash và ReqTypes thì trường ReqTypeByte phải có độ dài 4 byte và chứa các byte 0x00, 0x01,0x02 và 0x03.

Ví dụ:

4 bytes (hex)

00010203

CICAM chỉ hỗ trợ 4 loại tài nguyên cơ bản v2 là tập tin (0x00), dữ liệu (0x01), FileHash (0x02) và ReqTypes (0x03).

...

...

...

0001020304

CICAM hỗ trợ 5 giao thức. Các loại tài nguyên cơ bản v2 là tập tin (0x00), dữ liệu (0x01), FileHash (0x02) và ReqTypes (0x03), thêm vào một loại chưa được xác định là 0x04.

14.6. Tài nguyên kiểm soát máy chủ DVB

14.6.1. Kiểm soát máy chủ DVB phiên bản 2

Lớp tài nguyên kiểm soát máy chủ DVB theo quy định tại EN 50221 [7] được tăng cường để nó không còn bị giới hạn đối với việc dò kênh DVB triplet được máy chủ biết (kiểm soát máy phiên bản 1). Xem Phụ lục E.16 dành cho việc làm rõ hành vi dò kênh của kiểm soát máy chủ phiên bản 1. Phiên bản 2 của tài nguyên này thêm các lệnh mới dành cho CICAM để giải quyết một loại hoạt động dò kênh khác:

• Kiểm soát máy chủ 2: Yêu cầu máy chủ dò kênh đến một dịch vụ không thuộc bảng sắp xếp kênh của máy chủ (dịch vụ này chưa được máy chủ phát hiện trong quá trình phát hiện dịch vụ), dịch vụ này được lựa chọn dựa vào:

o Mô tả vật lý của dòng truyền tải mang dịch vụ

o Nhận dạng dịch vụ (ví dụ như service_id)

14.6.2. Các APDU của kiểm soát máy chủ DVB phiên bản 2

...

...

...

Bảng 14.28: Các APDU của kiểm soát máy chủ DVB phiên bản 2

Các APDU kiểm soát máy chủ phiên bản 2

Hướng

tune

CICAM à HOST

replace

CICAM à HOST

CIear_replace

CICAM à HOST

...

...

...

CICAM ß HOST

tune_broadcast_req

CICAM à HOST

tune_reply

CICAM ß HOST

ask_release_reply

CICAM à HOST

14.6.2.1. tune_broadcast_req APDU

CICAM gửi APDU này để yêu cầu máy chủ dò kênh đến một dịch vụ dựa trên mô tả vật lý của dòng truyền tải mang dịch vụ và nhận dạng của dịch vụ này. Máy chủ trả lời bằng tune_reply () APDU.

...

...

...

Cú pháp

Số bit

Kiểu

tune_broadcast_req() {
tune_broadcast_req_tag length_field() reserved
pmt_flag service_id reserved
descriptor loop_length for (i=0; i<N; i++) {
descriptor()
}
if (pmt_flag==1) { program_map_section()
}
}

24

7
1
16
4
12

uimsbf

uimsbf
uimsbf
uimsbf
uimsbf
uimsbf

pmt_flag: pmt_flag là trường 1-bit chỉ ra khi tune_broadcast_req chứa một PMT. Giá trị "0" chỉ ra rằng yêu cầu này không chứa một PMT và rằng máy chủ phải lấy về PMT của service_id dịch vụ này từ dòng truyền tải. Giá trị "1" chỉ ra rằng yêu cầu này chứa một PMT mà máy chủ phải sử dụng để thực hiện lựa chọn dòng thành phần.

service_ld: trường 16-bit này được sử dụng làm nhãn để nhận dạng dịch vụ được yêu cầu này so với bất kỳ dịch vụ khác trong dòng truyền tải được dò kênh. Nó cũng giống như program_number trong PMT. Nếu service_id bằng không thì pmt_flag cũng phải bằng không và máy chủ phải dò kênh tần số này nhưng không phải lựa chọn một dịch vụ, một ca_pmt sẽ không được gửi đi.

descriptor_loop_length: trường 12-bit này chỉ ra tổng độ dài theo byte của vòng các nhãn mô tả tiếp theo.

...

...

...

program_map_section (): bảng ánh xạ chương trình theo tiêu chuẩn ISO/IEC 13818-1.

14.6.2.2. tune_reply APDU

APDU này là trả lời của máy chủ đối với một tune_broadcast_req () hoặc tune () như được quy định tại điều 8.5.1.1 của EN 50221 [7]. Nó cung cấp cho CICAM trạng thái của yêu cầu dò kênh.

Bảng 14.30 - Cú pháp tune_reply APDU

Cú pháp

Số bit

Kiểu

tune_reply () {
tune_reply_tag
length_field()
status_field
}

24

8

...

...

...

status_field: trường 8-bit này xác định trạng thái dò kênh theo Bảng 14.31.

Bảng 14.31 - Các giá trị trạng thái tune_reply

status_field

Giá trị

Trạng thái OK-Dò kênh thành công (Xem CHÚ THÍCH 1)

0x00

Lỗi -Bộ mô tả hệ thống phân phối không được hỗ trợ

0x01

Lỗi -Bộ dò kện không khóa

...

...

...

Lỗi -Bộ dò kênh đang bận

0x03

Lỗi -Các tham số bị lỗi hoặc bị sót. (Xem CHÚ THÍCH 2)

0x04

Lỗi -Không tìm thấy dịch vụ

0x05

Lỗi -Không xác định

0x06

Dự phòng

...

...

...

CHÚ THÍCH:

1: Theo sau một hoạt động dò kênh thành công, máy chủ phải trả lại một ca_pmt() tách từ PMT có thể áp dụng được.

2: Nếu một bộ mô tả bắt buộc bị sót trong yêu cầu dò kênh, thì phải trả lại lỗi này. Các bộ mô tả bắt buộc được liệt kê trong Bảng Table 14.28

14.6.2.3. ask_release APDU

Kiểm soát máy chủ phiên bản 2 sử dụng ask_release () APDU này. Cú pháp của APDU này được quy định tại điều 8.5.1.4 của EN 50221 [7] và hành vi của nó bị thay đổi để cho phép CICAM nắm quyền kiểm soát bộ dò kênh nếu được yêu cầu. CICAM có thể truy vấn người sử dụng để xác nhận hành động này. CICAM trả lời cho máy chủ trạng thái giải phóng bộ dò kênh bằng ask_release_reply APDU này.

14.6.2.4. ask_release_reply APDU

APDU này là trả lời của CICAM đối với một ask_release (). APDU này chỉ ra xem CICAM có xác nhận hay không khi bộ dò kênh phải được giải phóng và phiên này đóng.

Bảng 14.32 - Cú pháp Tune Release Reply APDU

Cú pháp

...

...

...

Kiểu

ask_release_reply() {
ask_release_query_tag
length_field()
release reply
}

24

8

uimsbf

uimsbf

release_reply: trường 8-bit này chỉ ra trạng thái dò kênh theo Bảng 14.33

Bảng 14.33 - Các giá trị trả lời giải phóng bộ dò kênh

release_reply

Giá trị

Trả về OK - Máy chủ lấy lại quyền điều khiển bộ dò kênh

...

...

...

Trả lại bị từ chối - CICAM giữ lại quyền điều khiển bộ dò kênh

0x01

Dự phòng

0x02-0xFF

14.6.3. Quản lý PMT

Đối với triển khai video theo yêu cầu (VOD), thường là trong các mạng cáp thì các thành phần VOD được phân phối trên kênh truyền hình chỉ là các thành phần của dòng thành phần và kênh truyền hình này không cung cấp các thành phần PSI và SI. Trong trường hợp này thì PMT được CICAM cung cấp trong APDU và được xây dựng từ thông tin mà CICAM lấy được từ thiết bị đầu cuối, thường là thông qua tài nguyên truyền tốc độ thấp.

Người tạo ra ứng dụng của bất kỳ ứng dụng VOD phải lưu ý rằng trong trường hợp không có bất kỳ SI trong dòng thì hoạt động dò kênh này gây ra trễ 5 giây trong khi việc kiểm tra ngăn chặn máy chủ được thực hiện để có được SDT_Actual sẽ bị thất bại và hết thời gian chờ. Việc kiểm tra máy chủ này đối với SDT không thể bị vô hiệu vì điều này gây ảnh hưởng đến an ninh được máy chủ trên mạng tạo nên.

Khi CICAM yêu cầu dò kênh trên một kênh truyền hình, nó có thể cung cấp PMT của dịch vụ này trong APDU. APDU PMT này được máy chủ sử dụng và máy chủ không phải cố gắng để có được PAT hoặc PMT từ mạng phát sóng.

14.6.4. Nhãn mô tả

...

...

...

Khi CICAM yêu cầu máy chủ dò kênh bằng tune_broadcast_req () thì CICAM phải cung cấp cho máy chủ với một vị trí dò kênh duy nhất được một hoặc nhiều nhãn mô tả hệ thống cung cấp. Nếu vòng nhãn mô tả chứa nhiều hơn một vị trí dò kênh thì máy chủ phải xem xét vị trí đầu tiên và bỏ qua các vị trí còn lại.

CICAM có thể tùy chọn cung cấp cho máy chủ thêm thông tin về dịch vụ được yêu cầu dò kênh. Thông tin được cung cấp có thể được máy chủ sử dụng để cung cấp cho người sử dụng mô tả của dịch vụ và sự kiện, ví dụ như để đưa các hội thoại thông tin và băng chương trình. Cơ chế chính xác mà máy chủ cung cấp thông tin này vào các ngăn xếp DVB của nó không được xác định và tùy thuộc vào thiết bị thu cụ thể, ví dụ như máy chủ có thể xây dựng một EIT_pf nội bộ với thông tin này dành cho dịch vụ hiện đang được chọn.

Bảng sau quy định danh sách các nhãn mô tả DVB có thể xuất hiện trong vòng nhãn mô tả của một yêu cầu dò kênh.

Bảng 14.34 - Các nhãn mô tả được cho phép trong tune_broadcast_req APDU

Descriptor

Giá trị thẻ DVB

Diễn giải

terrestrial_delivery_system_descriptor

0x5A

...

...

...

T2_delivery_system_descriptor

0x7F, 0x04 Xem CHÚ THÍCH

satellite_delivery_system_descriptor

0x43

S2_satellite_delivery_system_descriptor

0x79

cable_delivery_system_descriptor

0x44

C2_delivery_system_descriptor

...

...

...

service_descriptor

0x48

Thông tin tùy chọn thêm vào cho máy thu mô tả dịch vụ.

short_event_descriptor

0x4D

component descriptor

0x50

parental_rating_descriptor

0x55

...

...

...

0x54

CHÚ THÍCH: T2_delivery_system_descriptor và C2_deIivery_system_descriptor là các bộ mô tả DVB mở rộng, xem EN 300 468 [10], điều 6.2.16 và điều 6.3.

14.6.5. Giao thức dò kênh máy chủ

Hình 14.10 cung cấp tổng quan về hành vi của máy chủ sau khi nhận được một yêu cầu dò kênh kiểm soát máy chủ DVB phiên bản 2.

Hình 14.10 - Quá trình dò kênh với kiểm soát máy chủ phiên bản 2

1) Máy chủ nhận được một tune_broadcast_req ()

2) Máy chủ kiểm tra tính sẵn sàng và tính nhất quán của các thông số này. Nếu một hoặc nhiều thông số này không phù hợp hoặc là thiếu thì máy chủ tiếp tục với bước 10

3) Máy chủ kiểm tra hệ thống cung cấp được hỗ trợ. Nếu nhãn mô tả của hệ thống cung cấp không được hỗ trợ thì máy chủ tiếp tục với bước 11

...

...

...

5) Máy chủ xác nhận rằng hoạt động dò kênh này thành công và nhận được một tín hiệu hợp lệ. Nếu việc dò kênh thất bại thì máy chủ tiếp tục với bước 12

6) Máy chủ xác định xem một PMT đã được truyền trong yêu cầu này, nếu PMT không có thì PMT phải được lấy từ dòng truyền hình. Nếu PMT này không có sẵn thì máy chủ tiếp tục với bước 13.

7) Máy chủ gửi tune_reply () đến CICAM với trạng thái OK

8) Máy chủ sử dụng PMT này để chọn các dòng thành phần

9) Máy chủ gửi một ca_pmt () đến CICAM

10) Máy chủ gửi một tune_reply () với Error 04 (các thông số thiếu hoặc không phù hợp)

11) Máy chủ gửi một tune_reply () với Error 01 (nhãn mô tả của hệ thống cung cấp không được hỗ trợ)

12) Máy chủ gửi một tune_reply () với Error 02 (bộ dò kênh không khóa)

13) Nếu PMT này không có sẵn trong tune_broadcast_request máy chủ lấy PMT này từ dòng truyền tải được dò kênh này

...

...

...

15) Máy chủ gửi một tune_reply () với Error 05 (dịch vụ này không tìm thấy)

14.6.6. Các yêu cầu giải phóng kiểm soát máy chủ

Khi một phiên được mở với tài nguyên kiểm soát máy chủ DVB và máy chủ phát hiện tương tác của người sử dụng dẫn đến việc dò kênh đến một dịch vụ khác, máy chủ phải xin phép CICAM để giải phóng bộ dò kênh này dành cho máy chủ sử dụng

Hình 14.11 cung cấp tổng quan về hành vi của máy chủ khi nó phát hiện tương tác của người sử dụng trong khi một phiên kiểm soát máy chủ DVB được mở.

1) CICAM đã mở một phiên với tài nguyên kiểm soát máy chủ DVB.

2) Máy chủ phát hiện tương tác của người sử dụng thường sẽ dẫn đến việc dò kênh đến một dịch vụ mới.

3) Máy chủ gửi một ask_release () đến CICAM để yêu cầu bộ dò kênh này được giải phóng.

4) Máy chủ nhận được một ask_release_reply () từ CICAM để trả lời truy vấn này.

5) Máy chủ kiểm tra xem CICAM có chấp nhận ask_release () này. Điều này có thể liên quan đến việc CICAM sử dụng MMI để truy vấn của người sử dụng. Nếu CICAM thừa nhận thì máy chủ tiếp tục với bước 6). Nếu CICAM không thừa nhận thì máy chủ trở về bước 1)

...

...

...

7) Máy chủ dò kênh đến dịch vụ được người sử dụng lựa chọn.

Hình 14.11 - Quá trình dò kênh với kiểm soát máy chủ phiên bản 2

14.7. Hồ sơ nhà điều hành

14.7.1. Giới thiệu

Các hồ sơ truyền hình trong phân khúc thị trường theo chiều dọc thường bị cản trở bởi việc triển khai các thiết bị thu độc quyền hiện có sử dụng tín hiệu riêng để truyền tải thông tin từ thiết bị đầu cuối đến thiết bị thu trong trường hợp này. Vì mạng này đã được thiết lập nên rất khó khăn cho các nhà điều hành dịch vụ thay đổi mạng lưới để phục vụ cho sự ra đời của các thiết bị thu của thị trường theo chiều ngang sử dụng giao diện chung không làm ảnh hưởng đến mạng lưới này và các thiết bị thu hiện có.

Các tín hiệu riêng trong các mạng này yêu cầu thiết bị thu của thị trường theo chiều ngang được thiết kế để nhận biết bất kỳ tín hiệu độc quyền trước khi chúng có thể được sử dụng trên mạng này. Việc phân tích các tín hiệu riêng này chỉ ra rằng tín hiệu độc quyền đa dạng nhất ở các cấp cao hơn trong hồ sơ mạng trong khi tín hiệu này ở cấp dịch vụ và cấp PSI nói chung là tuân thủ tín hiệu DVB chuẩn. Tín hiệu mạng cấp cao hơn thường bao gồm việc kiểm soát chặt chẽ danh sách kênh và đánh số kênh logic có thể được dựa vào, một phần, các quyền đăng ký và quyền sử dụng được người sử dụng mua.

Tài nguyên hồ sơ của nhà điều hành cố gắng giải quyết các vấn đề tương thích giữa mạng và thiết bị thu bằng cách cung cấp một hồ sơ truyền hình theo chuẩn CI Plus và sử dụng CICAM để phân tích tính hiệu riêng của mạng thành một cấu trúc thông tin thống nhất cho phép tất cả các thiết bị máy chủ CI Plus thực hiện cài đặt đầy đủ và lập một danh sách kênh của tất cả các dịch vụ theo yêu cầu của các nhà điều hành dịch vụ.

14.7.2. Tổng quan hoạt động

...

...

...

Các nhà khai thác dịch vụ trong thị trường theo chiều dọc không có khả năng làm thay đổi đáng kể tín hiệu SI/PSI hiện có vì các thiết bị thu có thể đã được triển khai trong mạng. Tài nguyên hồ sơ nhà điều hành cung cấp một cơ chế dành cho tín hiệu SI cấp cao hơn được cấu hình, đóng gói lại và cung cấp đến cho một máy chủ CI Plus nội bộ mà không ảnh hưởng đến tín hiệu truyền hình hiện có của mạng. Một cơ chế thông báo CICAM NIT cho phép SDT truyền hình được cấu hình lại một phần từ NIT này sử dụng ciplus_service_descriptor cung cấp việc kiểm soát hoàn toàn NIT. Một số điều chỉnh của PSI và EIT truyền hình trong mạng có thể được yêu cầu để cho phép tương thích hoàn toàn với một máy chủ CI Plus, điều này nói chung có nghĩa là tuân thủ đầy đủ hơn các tiêu chuẩn DVB. Hành vi hoạt động của mạng hiện tại có thể được cung cấp cho máy chủ thông qua operator_info () APDU trong đó xác định môi trường hoạt động này cho phép máy chủ đáp ứng các thay đổi hoạt động trong các mạng khác nhau.

Tài nguyên hồ sơ nhà điều hành cung cấp hai chế độ hoạt động khác nhau tùy thuộc vào profile_type được định nghĩa như sau:

• profile_type = 0 - hoạt động tiêu chuẩn (hoặc không định hình) theo DVB CI, trong đó mạng được xác định từ thông tin dịch vụ truyền hình. Thông tin thêm về hành vi mạng có thể xác định và truyền đến máy chủ trong tài nguyên này.

• profile_type = 1 - hoạt động định hình trong đó máy chủ xây dựng một danh sách kênh nội bộ một cách rõ ràng dành cho nhà điều hành dịch vụ và CICAM cung cấp một CICAM NIT thay thế cho máy chủ trong đó xác định mạng. Máy chủ không truy vấn mạng truyền hình này để xác định bảng sắp xếp kênh logic.

Hình 14.12 chỉ ra hoạt động của tài nguyên hồ sơ nhà đều hành khi chạy trong một chế độ cung cấp CICAM NIT.

Hình 14.12 - Hoạt động của tài nguyên hồ sơ nhà điều hành

Dòng truyền tải TS in truyền qua CICAM và được giải xáo trộn dưới sự kiểm soát máy chủ theo ca_pmt (). Thông tin dịch vụ (SI) của mạng tùy chọn được CICAM tách kênh và sử dụng để xây dựng CICAM NIT mới và được truyền đến máy chủ thông qua các operator_status () và operator_nit () APDU. Các bảng này được CICAM sử dụng để xây dựng CICAM NIT được nhà điều hành dịch vụ xác định và có thể được cung cấp từ các NIT, BAT, SDT của dòng truyền hình hoặc bất kỳ phần bảng riêng nào khác xuất hiện trên mạng. Các quyền sử dụng CAS/thẻ thông minh và service_type từ operator_search_start () APDU được sử dụng để xác định những dịch vụ nào có thể xuất hiện trong CICAM NIT. CICAM NIT là một cấu trúc gần như tĩnh và được lưu trữ liên tục trong CICAM từ khi bảng này được xây dựng. Bảng này được CICAM duy trì bằng cách giám sát mạng và các quyền sử dụng CAS/ thẻ thông minh và truyền bất kỳ thay đổi đến máy chủ bằng cách quản lý số phiên bản của CICAM NIT.

Máy chủ cung cấp một danh sách kênh đặc biệt dành cho từng hồ sơ CICAM được ghép với nó. Khi hoạt động với một danh sách kênh của một hồ sơ CICAM thì CICAM NIT này luôn luôn được sử dụng ưu tiên hơn bất kỳ NIT truyền hình nào. Thông tin CICAM NIT được sử dụng để xây dựng danh sách kênh này dành cho hồ sơ CICAM liên quan này. Những thay đổi trong hồ sơ này được gửi đến máy chủ bằng một operator_status () APDU không đồng bộ, trong đó chưa thông tin phiên bản của bất kỳ CICAM NIT được cập nhật với một số phiên bản của phần bảng mới và hoạt động giống như một phần bảng NIT được cập nhật trong một mạng truyền hình thông thường.

...

...

...

Trong phạm vi của một hồ sơ CICAM thì có thể sử dụng Hướng dẫn chương trình điện tử địa phương của máy chủ để hiển thị thông tin sự kiện chương trình của hồ sơ thu được thông qua thông tin EIT_sch từ mỗi bộ ghép kênh, thu được từ bộ ghép kênh tương tự khi truyền qua hoàn toàn hoặc thu được bởi việc dò kênh đến một kênh quảng cáo đặc biệt. EIT_sch có thể được cung cấp dưới dạng bị xáo trộn trên mạng.

CICAM và máy chủ phải tuân thủ hoàn toàn hồ sơ cá truyền hình được quy định tại Phụ lục N để đảm bảo tương thích hoàn toàn với tất cả các thiết bị CI Plus.

14.7.3. Xử lý hồ sơ nhà điều hành máy chủ

Tài nguyên hồ sơ nhà điều hành CICAM với một profile_type khác không yêu cầu máy chủ tạo ra một danh sách kênh logic riêng dành cho nhà điều hành dịch vụ với một nhãn được trường profile_name của operator_info () APDU mô tả. Máy chủ phải cung cấp một cơ chế lựa chọn để chuyển vào các danh sách kênh khác nhau như trong hình 14.13, trong đó CICAM đã thông báo một hồ sơ với tên hồ sơ là "CICAM network 1".

Hình 14.13 - Ví dụ một giao diện người sử dụng lựa chọn mạng

Tiêu chuẩn này không quy định cơ chế chính xác này của máy chủ để lựa chọn, thay đổi và cuối cùng là xóa các hồ sơ mạng khác nhau. Thủ tục cài đặt của một CICAM mới thông báo một hồ sơ nhà điều hành phải đơn giản đối với người sử dụng và máy chủ phải tự động khởi tạo và hướng dẫn người sử dụng thông qua thủ tục cài đặt này khi một CICAM mới với một hồ sơ có thể được hỗ trợ và đưa ra được ghép vào máy chủ.

Máy chủ phải giữ lại hồ sơ mạng này của CICAM cho đến khi cặp xác thực CI Plus CICAM bị gỡ bỏ hoặc người sử dụng gỡ bỏ hồ sơ này. Máy chủ phải giữ lại hồ sơ này thông qua hoạt động gỡ bỏ CICAM cho phép một số lượng hạn chế các CICAM khác nhau được quay vòng mà không làm mất thông tin danh sách kênh được lưu trữ.

Thông tin hồ sơ nhà điều hành CICAM phải bao gồm một danh sách kênh logic độc lập giữ nguyên tín hiệu NIT của mạng CICAM này đối với profile_type 1. Máy chủ phải cung cấp một cơ chế bởi để di chuyển từ một hồ sơ nhà điều hành này sang một hồ sơ nhà điều hành khác.

...

...

...

Phần này mô tả việc trao đổi APDU giữa máy chủ và CICAM.

14.7.4.1. Khởi tạo

operator_status () APDU phải được CICAM tự động thông báo lúc khởi tạo và phải chứa thông tin hồ sơ được lưu trữ trong CICAM, thông tin này phải được cung cấp ngay lập tức. Nếu CICAM chưa được khởi tạo thì initialised_flag phải là "0", nếu CICAM yêu cầu một hoạt động dò kênh để thực hiện khởi tạo thì refresh_request_flag phải được thiết lập là "2" để chỉ ra rằng yêu cầu một hoạt động dò kênh ngay lập tức để khởi tạo CICAM.

14.7.4.1.1. CICAM không định hình

CICAM thông báo profile_type không (0) không hỗ trợ một danh sách kênh logic riêng và hoạt động như một DVB CICAM thông thường và được coi là không có một hồ sơ đặc biệt. Máy chủ nhận biết thông tin được truyền trên mạng và mạng này hoàn toàn tuân thủ DVB hoặc máy chủ đã được xây dựng đặc biệt để hoạt động với mạng này thì operator_info () APDU cung cấp một số thông tin cho máy chủ về môi trường mạng này.

Những cờ CICAM được phân tích theo một cách giống như một CICAM định hình và CICAM có thể yêu cầu dò kênh v.v.. điều này có thể được sử dụng để có được thông tin từ mạng và kiểm soát máy chủ. Thông thường CICAM bắt đầu trong trạng thái được khởi tạo vì không có thông tin bổ sung được truyền đến máy chủ.

14.7.4.1.2. CICAM định hình

CICAM thông báo profile_type một (1) yêu cầu máy chủ hỗ trợ một hồ sơ riêng và máy chủ tạo ra một danh sách kênh logic riêng dành cho nhà điều hành dịch vụ theo các quy tắc được nêu trong Phụ lục N.

Máy chủ phải tự động cài đặt hồ sơ này khi ghép CICAM và xây dựng danh sách kênh logic này với sự can thiệp của người sử dụng là tối thiểu. Hồ sơ và danh sách kênh kênh logic này phải được liên tục trong cả CICAM và máy chủ và không được tự động bị xóa khi CICAM hoặc thẻ thông minh được lấy ra tạm thời. Hồ sơ này nên được giữ lại cho đến khi người sử dụng xóa nó hoặc bất kỳ cặp xác thực CI Plus giữa CICAM và máy chủ bị gỡ bỏ.

...

...

...

14.7.4.1.3. Khôi phục hồ sơ

CICAM định hình có khả năng bắt đầu trong trạng thái chưa được khởi tạo và máy chủ được yêu cầu để xác định hệ thống cung cấp này của CICAM. Điều này có thể được xác định bằng cách truy vấn CICAM như trong hình 14.14.

Hình 14.14 - Trình tự APDU khôi phục hồ sơ

1. CICAM thông báo hồ sơ hiện tại khi mở phiên.

2. Máy chủ truy vấn CICAM về thông tin hồ sơ chung của nhà điều hành dịch vụ và mạng bằng cách sử dụng một operator_info_req () APDU.

3. CICAM thông báo thông tin hồ sơ này cho máy chủ trong operator_info () APDU. Số phiên bản của thông tin nhà điều hành được duy trì trong operator_status () APDU và máy chủ có thể phát hiện một thay đổi thông tin từ số phiên bản mà không cần truy vấn lại thông tin hồ sơ nhà điều hành một lần nữa.

4. Máy chủ cài đặt hồ sơ này, nếu hồ sơ chưa được khởi tạo thì khởi tạo việc tìm kiếm hồ sơ để tìm kiếm thông tin hồ sơ này bằng cách sử dụng operator_search_start () APDU.

5. Khi nhận được một operator_search_start () APDU thì CICAM phải điều khiển các hoạt động dò kênh của máy chủ và hiển thị trạng thái tìm kiếm đang diễn ra thông qua CICAM MMI. CICAM có thể yêu cầu có hoặc không có nhiều hoạt động dò kênh đến (các) bộ ghép kênh được yêu cầu bằng một operator_tune () APDU.

...

...

...

7. Khi CICAM đã hoàn thành việc tìm kiếm hồ sơ thì bất kỳ NIT nội bộ được cập nhật trên CICAM với thông tin mạng mới và phiên bản NIT này được cập nhật. operator_search_status () APDU được gửi và phải bao gồm trạng thái và mọi số phiên bản NIT mới. error_flag được thiết lập một cách thích hợp nếu system_descriptor của việc tìm kiếm không được hỗ trợ. Bất kỳ MMI ứng dụng hoặc cấp cao phải được loại bỏ trước khi operator_search_status () APDU được gửi đi.

8. Một CICAM profile_type = 0 có thể dừng ở đây. Nếu việc tìm kiếm hồ sơ không có lỗi thì máy chủ có thể cài đặt hồ sơ dựa trên thông tin CICAM NIT, máy chủ phải yêu cầu NIT sử dụng operator_nit_req () APDU.

9. CICAM phải trả về phiên bản mới nhất của NIT đến máy chủ bằng operator_nit () APDU.

Nếu hồ sơ không thể được CICAM tìm thấy thì error_flag phải được thiết lập trong bất kỳ operator_status_body () để chỉ ra rằng hồ sơ nhà điều hành bị lỗi. error_flag dành cho việc tìm kiếm hồ sơ bị thất bại phải liên tục. error_flag này chỉ phải bị việc tìm kiếm nhà điều hành do máy chủ khởi tạo xóa hoặc thiết lập lại hoặc bằng một tương tác bên ngoài nào khác với CICAM ví dụ như các tùy chọn MMI để thiết lập lại hoặc sự phát hiện của CICAM rằng CICAM đã được tháo ra và ghép trở lại.

14.7.4.1.4. Các vấn để khởi tạo

Tài nguyên hồ sơ nhà điều hành nên được tạo ra càng nhanh càng tốt từ khi được CICAM khởi tạo để cho máy chủ một cơ hội để bao gồm hồ sơ nhà điều hành trong bất kỳ thủ tục cài đặt. Một CICAM định hình nên thông báo sự hiện diện của một hồ sơ nhà điều hành trong thông tin CIS để thông báo cho máy chủ rằng một hồ sơ nhà điều hành là sẵn có và sau đó máy chủ có thể chờ đợi CICAM để tạo ra tài nguyên hồ sơ nhà điều hành trước khi tiến hành bất kỳ quá trình cài đặt.

Khi cài đặt lần đầu thì có khả năng là tài nguyên hồ sơ nhà điều hành nên được xử lý trước khi máy chủ và CICAM có thể kết nối vào mạng và sau đó lấy được thời gian và ngày. CICAM phải đảm bảo rằng bất kỳ thủ tục xác thực tài nguyên kiểm soát nội dung chỉ được bắt đầu khi CICAM và máy chủ đều đã lấy ngày và thời gian hợp lệ, tức là, tài nguyên hồ sơ nhà điều hành được xử lý trước bất kỳ việc thực hiện xác thực kiểm soát nội dung.

14.7.4.2. Chuyển đổi giữa hai hồ sơ

Yêu cầu máy chủ thông báo cho CICAM khi nó vào và rời khỏi môi trường profile_type 1. Máy chủ vào môi trường nhà điều hành bằng cách gửi một operator_status_req () APDU, CICAM có thể giả định rằng máy chủ đang chủ động chạy trong hồ sơ này cho đến khi một operator_exit () APDU nhận được. Khi vào môi trường hồ sơ nhà điều hành thì các hành vi sau đây được yêu cầu:

...

...

...

• CICAM có thể giả định rằng các dòng truyền tải truyền qua CICAM là một phần của môi trường hồ sơ nhà điều hành.

• Máy chủ phải duy trì môi trường hồ sơ này bằng cách sử dụng operator_status () APDU.

Máy chủ có thể rời khỏi một hồ sơ nhà điều hành vì một hồ sơ khác hoặc một trong các danh sách kênh riêng bất kỳ của nó. Khi máy chủ rời khỏi hồ sơ này, các hành vi sau đây được yêu cầu:

• CICAM không được giả định rằng các dòng truyền tải truyền qua CICAM là một phần của môi trường hồ sơ nhà điều hành.

• CICAM phải tiếp tục xử lý ca_pmt () và giải xáo trộn nội dung khi nó có thể.

• Không yêu cầu máy chủ duy trì môi trường hồ sơ này hoặc xử lý operator_status () APDU.

Máy chủ sau đó có thể quay trở lại môi trường hồ sơ nhà điều hành một lần nữa bằng cách gửi một operator_status_req () APDU. Trình tự APDU được mô tả trong hình 14.15.

Hình 14.15 - Vào và rời khỏi một môi trường định hình

...

...

...

1. CICAM tự động thông báo profile_status () APDU khi khởi tạo.

2. Máy chủ chuyển vào môi trường hồ sơ nhà điều hành và gửi một operator_status_req () APDU.

3. CICAM đang được hoạt động trong môi trường nhà điều hành định hình và xác nhận cho máy chủ bằng một operator_status () APDU.

4. Máy chủ rời khỏi môi trường hồ sơ nhà điều hành bằng cách gửi một operator_exit () APDU, và có thể hoạt động trong một hồ sơ nhà điều hành khác hoặc với một hệ thống cung cấp khác bằng cách sử dụng một danh sách kênh khác.

5. Máy chủ chuyển trở lại môi trường nhà điều hành định hình và gửi một operator_status_req () APDU.

6. CICAM một lần nữa được hoạt động trong môi trường nhà điều hành định hình và xác nhận cho máy chủ bằng một operator_status () APDU.

14.7.4.3. Thay đổi quyền

entitlement_change_flag của operator_status_body () được thiết lập khi quyền CAS đã thay đổi. Sự thay đổi quyền có thể được thông báo khi người sử dụng cập nhật thuê bao của mình. Sự thay đổi thuê bao này có thể cho phép truy nhập nhiều hơn/ít hơn các dịch vụ và có thể yêu cầu một bản cập nhật vào danh sách kênh máy chủ. Khi phát hiện sự thay đổi quyền thì máy chủ phải thông báo cho người sử dụng rằng các quyền được hưởng đã thay đổi, cập nhật danh sách kênh ở nhưng nơi cần thiết và sau đó xác nhận cho CICAM rằng quyền này đã được xử lý khi CICAM phải xóa cờ thay đổi quyền.

entitlement_change_flag phải được máy chủ xử lý càng nhanh càng tốt để cài đặt bất kỳ các dịch vụ mới tương ứng với sự thay đổi quyền. Điều này có thể yêu cầu thông báo cho người sử dụng rằng sự thay đổi quyền đã xảy ra và sau đó ngay lập tức chuyển việc kiểm soát dò kênh cho CICAM để có được các thay đổi của bảng sắp xếp dịch vụ từ mạng.

...

...

...

14.7.4.3.1. Thay đổi quyền đơn giản

Trong trường hợp đơn giản, thì quyền được cập nhật, nó có thể dẫn đến một sự thay đổi đối với bảng CICAM NIT. Máy chủ cập nhật danh sách kênh với bất kỳ thay đổi CICAM NIT và sau đó xác nhận cho CICAM rằng quyền này đã được xử lý. Sự trao đổi APDU được thể hiện trong hình 14.16.

Hình 14.16 - Trình tự APDU thay đổi quyền đơn giản

Các hành vi của hệ thống được mô tả như sau:

1. CICAM phát hiện sự thay đổi quyền được hưởng và cập nhật NIT nếu cần. Sự thay đổi này được thông báo trong một operator_status () APDU với trường entitlement_pending_flag được thiết lập. refresh_request_flag có thể chưa được thiết lập chỉ ra rằng CICAM đã nhận biết được sự thay đổi quyền và NIT đã sẵn sàng, không yêu cầu tìm kiếm.

2. Máy chủ thông báo cho người sử dụng về sự thay đổi quyền và chuẩn bị để cập nhật danh sách kênh nếu CICAM NIT đã thay đổi (điều này có thể yêu cầu sự cho phép của người sử dụng để xử lý sự thay đổi quyền ngay lập tức).

3. Nếu NIT đã thay đổi, được thể hiện qua số phiên bản được cập nhật thì máy chủ yêu cầu CICAM NIT mới từ CICAM.

4. CICAM gửi CICAM NIT mới đến máy chủ. Khi máy chủ đã xử lý CICAM NIT này và cập nhật danh sách kênh thì sự thay đổi được xác nhận cho CICAM bằng cách gửi một operator_entitlement_ack ().

...

...

...

Lưu ý rằng CICAM có thể không yêu cầu sự cập nhật cho CICAM NIT và CICAM có thể thông báo sự thay đổi quyền mà không cần cập nhật phiên bản CICAM NIT. Yêu cầu máy chủ thông báo cho người sử dụng rằng quyền đã được thay đổi và sau đó xác nhận cho CICAM rằng người sử dụng đã được thông báo về sự thay đổi quyền.

14.7.4.3.2. Thay đổi quyền có yêu cầu tìm kiếm

Sự thay đổi quyền đôi khi có thể yêu cầu CICAM tìm kiếm trên mạng để có được sự thay đổi bảng sắp xếp dịch vụ mới, trong trường hợp này CICAM có thể thông báo sự thay đổi quyền này bằng yêu cầu làm mới lại trong cùng APDU, tức là entitlement_change_flag = 1 và refresh_request_flag = 1. Nếu hoạt động dò kênh là cấp thiết thì CICAM có thể thông báo refresh_request_flag = 2 chỉ ra rằng quyền này không thể được xử lý cho đến khi máy chủ đã gửi tìm kiếm. Việc trao đổi APDU được thể hiện trong hình 14.17.

Hình 14.17 - Trình tự APDU thay đổi quyền tìm kiếm

Các hành vi của hệ thống được mô tả như sau:

1. CICAM phát hiện sự thay đổi quyền được hưởng nhưng không có khả năng xác định liệu danh sách kênh có bị sự thay đổi này làm thay đổi mà không cần quét mạng. Sự thay đổi này được thông báo trong một operator_status () APDU và entitlement_pending_flag được thiết lập và refresh_request_flagis thiết lập là 1 hoặc 2 tùy thuộc vào tính cấp thiết của việc tìm kiếm mạng.

2. Máy chủ thông báo cho người sử dụng về sự thay đổi quyền, nếu refresh_request_flag được thiết lập là 1 thì có thể cho người sử dụng một tùy chọn để xử lý sự thay đổi quyền này ngay lập tức, khi refresh_request_flag là 2 thì việc yêu cầu truy vấn mạng là cấp thiết hơn thì có thể không cho người sử dụng bất kỳ tùy chọn để cài đặt sau đó. Khi máy chủ đã sẵn sàng để xử lý sự thay đổi quyền thì việc tìm kiếm được khởi tạo để bắt đầu quét mạng và một operator_search_start () APDU được gửi và việc kiểm soát chuyển đến cho CICAM.

3. Khi nhận được một operator_search_start () thì CICAM có thể yêu cầu một hoặc nhiều hoạt động dò kênh đối với (các) bộ ghép kênh bằng một operator_tune () APDU. Trong một chế độ có máy chủ tham gia thì CICAM phải duy trì sự thông báo cho người sử dụng về tiến độ bằng cách sử dụng MMI ứng dụng hoặc cấp cao.

...

...

...

5. Khi CICAM đã hoàn thành việc tìm kiếm thì bất kỳ NIT được lưu trữ được cập nhật với thông tin mạng mới, số phiên bản được cập nhật và một operator_search_status () APDU được gửi đến máy chủ. Trường entitlement_change_flag vẫn phải được thiết lập vì sự thay đổi quyền này đã không được máy chủ xác nhận. Bất kỳ MMI ứng dụng hoặc cấp cao phải được gỡ bỏ trước khi gửi trạng thái tìm kiếm.

6. Khi nhận được operator_search_status () APDU máy chủ xác định xem NIT đã thay đổi bằng cách sử dụng trường nit_version. Nếu phiên bản NIT đã được cập nhật thì máy chủ có thể yêu cầu CICAM NIT mới bằng cách sử dụng operator_nit_req () APDU.

7. CICAM trả về NIT được cập nhật cho máy chủ bằng operator_nit () APDU và máy chủ cập nhật danh sách kênh nếu CICAM NIT đã thay đổi.

8. Khi danh sách kênh đã được cập nhật thì sự thay đổi quyền được xác nhận đến CICAM bằng cách gửi một operator_entitlement_ack () APDU.

9. Khi nhận được một operator_entitlement_ack () để xóa yêu cầu về quyền thì CICAM xóa entitlement_change_flag và xác nhận sự thay đổi của trạng thái bằng một operator_status () APDU mới.

14.7.4.4. Dò kênh và quét

Có một số kịch bản dò kênh và quét khác nhau được hồ sơ nhà điều hành yêu cầu, tất cả các kịch bản dò kênh được máy chủ khởi tạo một cách rõ ràng bằng cách sử dụng operator_search_start () APDU. Máy chủ có thể lựa chọn để khởi tạo một trình tự dò kênh khi:

• CICAM yêu cầu dò kênh bằng refresh_request_flag trong operator_status_body () của một APDU của hồ sơ nhà điều hành.

• Máy chủ tìm kiếm không theo yêu cầu, thường là một phần của việc bảo trì mạng của thiết bị thu của máy chủ được thực hiện trong trạng thái chờ, v.v..

...

...

...

CICAM có khả năng thông báo cho máy chủ rằng nó yêu cầu dò kênh bằng cách sử dụng refresh_request_flag trong thành phần operator_status_body () của một APDU. Tính cấp thiết của yêu cầu dò kênh được xác định từ trạng thái của trường này.

• cảnh báo nâng cao (1) thông báo cho máy chủ rằng yêu cầu dò kênh trong tương lai gần. Thông báo này không nên ảnh hưởng đến người sử dụng và phải được sử dụng tại thời điểm thích hợp tiếp theo của máy chủ, nghĩa là khi việc quét nền trở lại khi người sử dụng ở trạng thái chờ, v.v...

• yêu cầu cấp thiết (2) thông báo cho máy chủ rằng yêu cầu dò kênh ngay lập tức. Điều này chỉ được CICAM thông báo trong các trường hợp trong đó một số phận của mạng không thể truy nhập cho đến khi dò kênh được thực hiện. Máy chủ nên khởi tạo dò kênh ngay lập tức sau khi có sự xác nhận từ người sử dụng.

• yêu cầu có chu kỳ thời gian (3) thông báo cho máy chủ rằng yêu cầu tìm kiếm theo lịch trình tại một thời gian và ngày trong tương lai. Máy chủ phải thực hiện tìm kiếm theo lịch trình nếu nó có thể (tức là không được tắt nguồn điện). Nếu tìm kiếm đã bị bỏ lỡ thì CICAM không cần thiết phải yêu cầu máy chủ thực hiện quét ngay lập tức nhưng nên lập lịch trình lại vào một ngày sau đó. Điều này tránh làm gián đoạn không cần thiết đối với người sử dụng.

Hoạt động dò kênh được coi là cấp thiết hơn nếu entitlement_pending_flag được thiết lập cùng với refresh_request_flag để chỉ ra rằng các quyền được hưởng đã được cập nhật và yêu cầu hoạt động dò kênh để đánh giá lại quyền đó.Trong trường hợp này, máy chủ có thể lựa chọn để thông báo cho người sử dụng sự thay đổi quyền và yêu cầu sự cho phép để khởi tạo việc tìm kiếm ngay lập tức để đánh giá lại mạng.

refresh_request_flag có thể được thiết lập và xóa như là một phần của hoạt động bình thường của hệ thống (tức là khi người sử dụng đang theo dõi một dịch vụ) vì thông tin nhận được từ bộ ghép kênh hiện tại có thể gây ra một yêu cầu chờ được thêm vào hoặc gỡ bỏ khi thông tin cập nhật nhận được từ mạng.

14.7.4.4.1. Tìm kiếm hồ sơ

Việc trao đổi APDU để tìm kiếm hồ sơ được thể hiện trong hình 14.18.

...

...

...

Các hành vi của hệ thống được mô tả như sau:

1. CICAM tùy chọn phát hiện sự thay đổi của mạng mà yêu cầu CICAM thực hiện một hoạt động tìm kiếm. Mức ưu tiên của yêu cầu tìm kiếm được xác định và refresh_request_flag được thiết lập đến một giá trị thích hợp với mức ưu tiên tìm kiếm. Sự thay đổi này được thông báo trong một operator_status () APDU và refresh_request_flagis thiết lập một giá trị khác không phụ thuộc vào tính cấp thiết của việc dò kênh.

2. Khi máy chủ đã sẵn sàng để xử lý việc tìm kiếm hồ sơ thì operator_search_start () APDU được gửi đến CICAM và việc kiểm soát của dò kênh và MMI được chuyển sang CICAM.

3. Khi nhận được một operator_search_start () với tìm kiếm hồ sơ thì CICAM yêu cầu một hoặc nhiều hoạt động dò kênh đối với (các) bộ ghép kênh được bằng một operator_tune () APDU. Quá trình của việc tìm kiếm phải được truyền đến người sử dụng bằng cách sử dụng MMI ứng dụng hoặc cấp cao trong đó có sự tham gia của máy chủ.

4. Khi nhận được một operator_tune () APDU thì máy chủ dò kênh đến bộ ghép kênh được yêu cầu và xác nhận dò kênh bằng một operator_tune_status () APDU có chứa trạng thái của dò kênh.

5. Khi CICAM đã hoàn thành việc tìm kiếm hồ sơ thì bất kỳ NIT trong CICAM được cập nhật với thông tin mạng mới, phiên bản CICAM NIT được cập nhật và operator_search_status () APDU được gửi đến máy chủ. refresh_request_flag được thiết lập lại. Bất kỳ MMI ứng dụng hoặc cấp cao phải được gỡ bỏ.

6. Nếu phiên bản NIT đã thay đổi trong operator_status_body () thì máy chủ có thể yêu cầu bảng CICAM NIT mới bằng operator_nit_req () APDU.

7. Khi nhận được operator_nit_req () APDU thì CICAM trả về các phần CICAM NIT được lưu trữ mới nhất cho máy chủ trong một operator_nit () APDU. Máy chủ có thể sử dụng CICAM NIT để cập nhật danh sách kênh.

14.7.4.4.2. Các yêu cầu dò kênh

...

...

...

• chuyển đến một vị trí hệ thống cung cấp rõ ràng.

• yêu cầu máy chủ để thực hiện dò kênh quét dựa trên một danh sách các vị trí hệ thống cung cấp.

Việc dò kênh rõ ràng này yêu cầu máy chủ chuyển bộ dò kênh đến vị trí được delivery_system_descriptor xác định, không yêu cầu máy chủ lựa chọn bất kỳ dịch vụ trên bộ ghép kênh này. Nhiều vị trí dò kênh có thể được quy định và máy chủ phải xử lý các vị trí tuần tự theo thứ tự được quy định trong APDU này cho đến khi một tín hiệu hợp lệ được tìm thấy khi nó hoàn thành yêu cầu dò kênh này.

Trong trường hợp CICAM tìm kiếm thì máy chủ phải cho phép CICAM sử dụng các APDU khác để có được các thông tin bao gồm, nhưng không loại trừ, tài nguyên truyền tốc độ thấp. CICAM phải đảm bảo rằng các APDU khác mở ra trong trường hợp tìm kiếm này được đóng lại trước khi việc tìm kiếm này hoàn thành. CICAM không được phép sử dụng APDU nâng cấp phần mềm trong trường hợp tìm kiếm này.

Lệnh operator_tune () APDU cũng có thể được CICAM sử dụng để khôi phục dịch vụ và yêu cầu máy chủ quét mạng liên tục bằng cách sử dụng các nhãn mô tả hệ thống cung cấp để tìm một vị trí chứa tín hiệu. Lệnh này của máy chủ hoàn thành khi tín hiệu được tìm thấy hoặc đến cuối danh sách. Máy chủ trả về thông tin của vị trí được dò kênh đến CICAM. Thông tin này được máy chủ trả về trong bất kỳ phần định nghĩa của nhãn mô tả hệ thống cung cấp phải chính là thông tin có thể được sử dụng để xây dựng CICAM NIT.

Máy chủ hoàn thành một yêu cầu chạy dò kênh bằng cách gửi một operator_tune_status () APDU đến CICAM chứa thông tin về trạng thái hoạt động dò kênh. Máy chủ phải trả về một delivery_system_descriptor phải được gửi một cách đầy đủ và chính xác, mô tả vị trí được dò kênh hiện tại, một số giá trị của system_delivery_descriptor có thể được cung cấp từ thông tin thông báo tham số dò kênh được truyền trong tín hiệu thực tế. Thông tin cường độ và chất lượng tín hiệu từ giao diện mạng phải được bao gồm trong APDU này theo các giá trị tương đối phần trăm mà không nên được CICAM phân tích theo nghĩa tuyệt đối. Máy chủ không phải thông báo các tín hiệu sẵn có không khả thi đến CICAM, máy chủ có thể thông báo một vị trí tần số nơi mà tín hiệu dữ liệu được giao diện mạng này phát hiện nhưng tín hiệu này không chứa một dòng truyền tải hợp lệ, tức là không yêu cầu máy chủ phải xác định rằng tín hiệu này thực tế mang một dòng truyền tải hợp lệ.

Trong hoạt động dò kênh thì CICAM phải chắc chắn chống lại được những dao động của dữ liệu và tạp âm trên bus truyền dòng truyền tải. Máy chủ có thể lựa chọn, nhưng không bắt buộc, ngắt kết nối giao diện dòng truyền tải trong thời gian của hoạt động dò kênh để tăng thêm sự chắc chắn của hệ thống. Trong trường hợp dòng truyền tải bị máy chủ ngắt kết nối trong suốt thời gian dò kênh thì nó phải được nối lại trước khi gửi operator_tune_status () APDU đến CICAM.

14.7.4.4.3. Vấn đề nâng cấp CAM

Trình tự APDU nâng cấp phần mềm CICAM không được bắt đầu giữa một trình tự operator_search_start () cho đến khi CICAM trả về xác nhận operator_search_status () cuối cùng.

...

...

...

14.7.5. Tài nguyên hồ sơ nhà điều hành

Tài nguyên hồ sơ nhà điều hành cho phép CICAM phối hợp quản lý hồ sơ này với máy chủ. Các bản tin này cho phép CICAM có được và duy trì các thông tin hồ sơ nhà điều hành với một số thỏa thuận từ thiết bị máy chủ. Thông báo những thay đổi môi trường nhà điều hành cho máy chủ bao gồm cả những thay đổi trong bảng sắp xếp dịch vụ và máy chủ được thông báo khi CICAM cần tìm kiếm trên mạng để có được các thông tin mới nhất. CICAM được cung cấp phương tiện để dò kênh và quét mạng để có được thông tin mạng được máy chủ hỗ trợ.

14.7.5.1. Các APDU tài nguyên hồ sơ nhà điều hành

CICAM mở tài nguyên operator_profile ngay từ khởi tạo và tài nguyên này vẫn mở để cung cấp bất kỳ thay đổi sau đó đối với thông tin hồ sơ này.

Bảng 14.35 - Các APDU hồ sơ nhà điều hành

1

Chiều

Mô tả

operator_status_req

...

...

...

Nhập vào hồ sơ profile và/ hoặc yêu cầu thông tin hồ sơ hiện thời.

operator_status

CICAM=>HOST

Thông tin trạng thái hồ sơ hiện thời.

operator_nit_req

HOST=>CICAM

Yêu cầu các phần CICAM NIT hiện thời.

operator_nit

CICAM=>HOST

...

...

...

operator_info_req

HOST=>CICAM

Yêu cầu thông tin nhà khai thác.

operator_info

CICAM=>HOST

Thông tin nhà khai thác.

operator_search_start

HOST=>CICAM

Máy chủ cho phép khởi đầu việc tìm mạng.

...

...

...

CICAM=>HOST

CICAM thông báo rằng việc tìm mạng đã hoàn thành.

operator_exit

HOST=>CICAM

Máy chủ đã để lại hồ sơ nhà khai thác dịch vụ.

operator_tune

CICAM=>HOST

Yêu cầu chỉnh kênh tới một vị trí ghép cụ thể.

operator_tune_status

...

...

...

Yêu cầu dò kênh của máy chủ đã hoàn thành.

operator_entitlement_ack

HOST=>CICAM

Xác nhận rằng việc thay đổi quyền đã được thực thi.

14.7.5.2. operator_status_req APDU

Máy chủ gửi APDU này cho CICAM khi vào hồ sơ nhà điều hành dịch vụ và truy vấn trạng thái hồ sơ nhà điều hành hiện tại. CICAM trả lời bằng một operator_status () APDU. Khi CICAM nhận được operator_status_req () thì nó có thể giả định rằng máy chủ đang hoạt động trong phạm vi hồ sơ nhà điều hành này cho đến thời điểm nhận được một operator_exit () APDU khi không có thêm APDU bản cập nhật hồ sơ nhà điều hành không đồng bộ có thể tiếp tục được thông báo cho máy chủ cho đến thời điểm mà máy chủ vào lại hồ sơ này một lần nữa bằng một operator_status_req () APDU.

Bảng 14.36 - Cú pháp operator_status_req APDU

Cú pháp

Số bit

...

...

...

operator_status_req() {
operator_status_req_tag
length_field()
}

24

uimsbf

Trong đó các trường được quy định như sau:

operator_status_req_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.3. operator_status APDU

APDU này được CICAM gửi để thông báo cho máy chủ về các thiết lập hồ sơ nhà điều hành hiện tại của CICAM. Nó được gửi để trả lời một operator_status_req () APDU từ máy chủ. CICAM cũng gửi APDU này không đồng bộ lúc khởi tạo hoặc khi có sự thay đổi trong hồ sơ nhà điều hành phải được máy chủ ban hành.

Khi mở tài nguyên hồ sơ nhà điều hành CICAM gửi một operator_status () APDU đến máy chủ để truyền các thiết lập hồ sơ hiện tại.

Bảng 14.37 - Cú pháp operator_status APDU

...

...

...

Số bit

Kiểu

operator_status () {
operator_status_tag
length_field()
operator_status_body()
}

24

uimsbf

Trong đó operator_status_body () được xác định theo quy định tại Bảng 14.38. Các operator_status_body () truyền tải thông tin về trạng thái của hệ thống CA khi dịch vụ CA được điều khiển bởi CICAM. Các operator_status_body () chứa các cờ và giá trị mà có thể làm cho máy chủ thực hiện một số hành động. Như một quy định chung, máy chủ và CICAM phải thống nhất với các loại hình dịch vụ đang được chọn như sau:

• Dịch vụ Free-to-air

o CICAM sẽ không thay đổi các thiết lập của cờ refresh_request_flag sang khẩn cấp.

o Máy chủ không nhất thiết phải gián đoạn hoặc ngăn chặn người dùng đang xem từ các dịch vụ hiện tại. Máy chủ sẽ xử lý bất kỳ yêu cầu nào có tính thời gian cấp bách hoặc thời gian hết hạn vào thời điểm sớm nhất sau khi người dùng không sử dụng dịch vụ để không làm gián đoạn dịch vụ hiện tại. Máy chủ có thể chọn thông báo cho người dùng rằng hệ thống CA yêu cầu một số thao tác và cho phép người sử dụng ra quyết định xem hoạt động này có thể được thực hiện ngay lập tức hoặc phải hoãn lại. Bất kỳ thao tác nào, khẩn cấp hoặc không có thể được hoãn lại để tránh bị gián đoạn người xem ví dụ hoãn lại cho đến khi người dùng chuyển kênh khác.

...

...

...

• Hồ sơ khai thác CICAM làm chủ một dịch vụ CA

o CICAM có thể thay đổi các cờ resfresh_request_flag sang thiết lập bất kỳ bao gồm cả khẩn cấp.

o Máy chủ sẽ phải thực hiện thay đổi cờ refresh_request_flag sang khẩn cấp ngay lập tức, điều này có thể làm gián đoạn việc xem các dịch vụ hiện tại. Một thiết lập cờ refresh_request_flag sang khẩn cấp phải được thực hiện ngay lập tức trong sự lựa chọn của dịch vụ CA.

Bảng 14.38 - Cú pháp operator_status_body

Cú pháp

Số bit

Kiểu

operator_status_body() {
info_version
nit_version
profile_type
initialised_flag
entitlement_change_flag

3
5
2
1
1

...

...

...

entitlement_valid_flag
reserved
refresh_request_flag
error_flag
delivery_system_hint
refresh_request_date
refresh_request_time
}

1
1
2
4
4
16
8

bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
uimsbf

Trong đó các trường được quy định như sau:

operator_status_tag: Xem bảng L.1 tại Phụ lục L.

info_version: trường 3-bit này là một nhãn định danh duy nhất xác định phiên bản của thông tin hồ sơ được chứa trong operator_info () APDU. Phiên bản thông tin hồ sơ phải được tăng thêm 1, quay về 0, khi thông tin hồ sơ này thay đổi và yêu cầu máy chủ đánh giá lại nơi chứa hồ sơ. Phiên bản thông tin hồ sơ này chỉ được tăng lên khi có những thay đổi hồ sơ lớn bao gồm sự thay đổi tên hồ sơ, thay đổi loại hồ sơ v.v.. Nó không được tăng lên khi có sự thay đổi nit_version hoặc bất kỳ thay đổi trong trạng thái cờ.

nit_version: trường 5-bit này chỉ được phân tích trong phạm vi của một hồ sơ khác không và được thiết lập là số phiên bản hiện tại của NIT được CICAM cung cấp. Nếu CICAM không cung cấp một NIT thì trường này phải là không và không được máy chủ phân tích.

profile_type: trường 2-bit này xác định loại của hồ sơ CICAM, các hồ sơ CICAM được xác định trong Bảng 14.38.

Bảng 14.39 - Các giá trị profile_type

...

...

...

Mô tả

0

CICAM không hỗ trợ bất kỳ hồ sơ nào và tách các dòng tín hiệu cơ sở cho từng DVBCI

1

Hồ sơ là một mạng cá nhân sử dụng một CICAMNIT và có danh sách kênh logic hồ sơ cá nhân.

2-3

Dự phòng.

initialised_flag: trường 1-bit này chứa trạng thái khởi tạo hồ sơ dành cho hồ sơ cụ thể. Giá trị “0" chỉ ra rằng hồ sơ đã không được khởi tạo, một giá trị "1" chỉ ra rằng hồ sơ đã được CICAM khởi tạo.

entitlement_change_flag: trường 1-bit này phải được thiết lập khi sự thay đổi quyền đã xảy ra mà không được máy chủ xác nhận. Giá bị "0", mặc định, chỉ ra không có sự thay đổi quyền bị treo, giá trị "1" chỉ ra rằng sự thay đổi quyền chưa được xác nhận bị treo.

...

...

...

refresh_request_flag: trường 2-bit này phải được thiết lập khi CICAM yêu cầu hoạt động dò kênh để đi đến bộ ghép kênh khác để có được thêm thông tin về hồ sơ hoặc để kiểm tra quyền được hưởng, v.v..

Bảng 14.40 - Các giá trị refresh_request_flag

Giá trị

Mô tả

0

Trạng thái mặc định, cho biết rằng CICAM không cần tham vấn mạng và đã được cập nhật.

1

Cảnh báo trước cho máy chủ rằng có gì đó trong mạng đã thay đổi và CICAM yêu cầu máy chủ điều chỉnh để thực hiện việc kiểm tra cập nhật khi thuận tiện. Yêu cầu này phải được trì hoãn cho đến khi máy chủ sẵn sàng thực hiện việc tìm kiếm mà không làm gián đoạn người sử dụng.

2

...

...

...

3

Yêu cầu nạp lại đã được lên kế hoạch từ CICAM rằng mạng cần phải được tham vấn tại một thời điểm cập nhật cụ thể. Máy chủ phải khởi đầu việc tìm hồ sơ tại thời điểm đó nếu có thể hoặc sau thời điểm đó. Điều này có thể yêu cầu máy chủ tự động bật từ chế độ chờ tại một thời điểm đã xác định để khởi động việc tìm kiếm. Nếu khe thời gian tìm kiếm bị lọt, ví dụ nếu máy thu bị tắt nguồn điện, thì CICAM nên lên kế hoạch lại vào một thời điểm khác thay vì bắt buộc máy chủ thực hiện việc tìm kiếm không cần thiết.

Việc làm mới kế hoạch đòi hỏi máy chủ phải gọi trình tìm kiếm nhà khai thác càng sớm càng tốt sau khi sự kiện này đã hết hạn. Khi trình tìm kiếm thông tin nhà điều hành được gọi bởi máy chủ thì CICAM có thể thực hiện tìm kiếm và/hoặc sắp xếp lại một tìm kiếm khác trong một thời gian/ngày sau đó bằng cách cập nhật các trường yêu cầu làm mới.

The state of the refresh_request_flag (and time/date) shall be updated by the CICAM to reflect the next refresh state required by the CICAM on completion of any operator search operation. The Host is notified of the new refresh request flag setting in addition to the other flags of the operator_status_body() in the operator_search_status () APDU.

error_flag: trường này là một trường cờ 4-bit, chứa trạng thái của hồ sơ đang hoạt động hiện tại. Các bit của trường này được quy định theo Bảng 14.41.

Bảng 14.41 - Các giá trị error_flag

Giá trị

Mô tả

0

...

...

...

1

Lỗi hồ sơ. CICAM đã gặp một lỗi và không thể lấy được hồ sơ, không có thông tin hồ sơ nào được lưu trữ.

2

Hệ thống phân phối không được hỗ trợ. CICAM không hỗ trợ (các) bộ mô tả hệ thống phân phối mà máy chủ báo cáo.

3

Bị hủy bỏ. Tìm kiếm nhà khai thác đã bị gián đoạn và không hoàn thành

4-15

Dự phòng.

delivery_system_hint: trường này là một trường 4-bit, chứa một gợi ý của hệ thống cung cấp được hồ sơ nhà điều hành hỗ trợ và cung cấp cho máy chủ một đánh giá hồ sơ CICAM. Các bit của trường này nên được thiết lập theo Bảng 14.42.

...

...

...

Bit

Mô tả

0b0001

Đây mà một mạng cáp và có thể là DVB-C và/ hoặc DVB-C2

0b0010

Đây là một mạng vệ tinh và có thể là DVB-S và/ hoặc DVB-S2

0b0100

Đây là một mạng mặt đất và có thể là DVB-T và/ hoặc DVB-T2

0b1000

...

...

...

Các CICAM có thể hỗ trợ nhiều hệ thống phân phối mà sẽ dẫn đến nhiều bit của trường này được thiết lập. Nếu máy chủ không hỗ trợ bất kỳ báo cáo hệ thống phân phối nào thì máy chủ có thể bỏ qua hồ sơ.

refresh_request_date: trường 16-bit này chỉ ra ngày của chu kỳ làm mới theo lịch tiếp theo được CICAM yêu cầu. Ngày được quy định theo MJD trong EN 300 468 [10], Phụ lục C. Giá trị 0x0000 chỉ ra rằng không yêu cầu làm mới theo lịch.

refresh_request_time: trường 8-bit này chỉ ra thời gian của chu kỳ làm mới theo lịch tiếp theo được CICAM yêu cầu. Thời gian được quy định theo UTC là một giá trị số nguyên với mỗi bước thời gian là 6 phút tính từ nửa đêm và có giá trị trong phạm vi từ 0 đến 239. Trường này chỉ được phân tích khi refresh_request_date khác không. Khi refresh_request_flag là số không thì trường này cũng phải là số không.

Ví dụ:

0

44

239

00:00 - nửa đêm

04:24 - 4 giờ 24 phút sáng

...

...

...

14.7.5.4. operator_nit_req APDU

Máy chủ gửi APDU này cho CICAM để truy vấn NIT hiện tại. CICAM trả lời bằng một APDU operator_nit trả về CICAM NIT cho máy chủ.

Bảng 14.43 - Cú pháp operator_nit_req APDU

Cú pháp

Số bit

Kiểu

operator_nit_req() {
operator_nit_req_tag
length_field()
}

24

uimsbf

...

...

...

operator_nit_req_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.5. operator_nit APDU

CICAM gửi APDU này đến máy chủ để trả lời một operator_nit_req () APDU. ADPU này, nếu thành công, chứa phần CICAM NIT mới nhất

Bảng 14.44 - Cú pháp operator_nit APDU

Cú pháp

Số bit

Kiểu

operator_nit 0 {
operator_nit_tag
length_field()
nit_loop_length
for (i=0; i<N; i++K){
nit_section_byte
}
}

24

16

8

...

...

...

Trong đó các trường được quy định như sau:

operator_nit_tag: Xem bảng L.1 tại Phụ lục L.

nit_loop_length: trường 16-bit này xác định độ dài tính theo byte của trường phần NIT tiếp theo chứa các phần CICAM NIT. Trường này có thể là không (0) nếu không có NIT.

nit_section_byte: vòng của một hoặc nhiều phần NIT mô tả đầy đủ mạng này. Một NIT chỉ được cung cấp khi thông tin mạng truyền hình và/hoặc Bouquet bị bỏ qua và được CICAM chuẩn bị. Các phần NIT này phải giữ nguyên các quy tắc tín hiệu truyền hình và phải có kích thước tối đa là 4096 byte, phải xuất hiện theo thứ tự số phần tăng dần và phải chứa một giá trị CRC-32. Vòng NIT đầu tiên có thể được chia thành nhiều phần và phải tuân thủ các quy tắc chia của DVB. Vòng NIT thứ hai có thể được chia thành nhiều phần, các phần được đánh số liên tục và các nhãn

delivery_system_descriptor thích hợp và nhãn quy định dữ liệu riêng phải được xuất hiện trong mỗi phần.

Khi NIT này được trả về cho máy chủ thì phiên bản NIT này phải phù hợp với số phiên bản trong operator_status () APDU được thông báo cuối cùng. Phiên bản NIT này chỉ được khác nhau khi NIT này đã được cập nhật và CICAM chưa gỡ operator_status () APDU chứa thông tin nit_version mới nhất.

CICAM NIT phải chứa tất cả các thông tin mà máy chủ yêu cầu phải xây dựng và duy trì danh sách kênh logic của hồ sơ nhà điều hành. Không yêu cầu máy chủ truy vấn thông tin dịch vụ truyền hình (SI) để xây dựng hoặc duy trì danh sách kênh hồ sơ này.

Vòng NIT đầu tiên này có thể tùy chọn chứa một tên mạng trong một network_name_descriptor ngoài các nhãn mô tả riêng CI Plus để cung cấp một dấu hiệu của hoạt động mạng truyền hình và ấn định các nhãn văn bản nội dung. Vòng đầu tiên này cũng có thể tùy chọn bao gồm thông tin tín hiệu truyền hình khác như DVB-SSU tuân theo tiêu chuẩn DVB.

Vòng NIT thứ hai phải chứa (các) nhãn system_delivery_descriptor xác định chính xác vị trí mạng của bộ ghép kênh ngoài một hoặc nhiều nhãn ciplus_service_descriptor mô tả nhãn văn bản và loại dịch vụ của mỗi dịch vụ được chứa trong danh sách kênh logic theo hồ sơ này. Các dịch vụ được ấn định một số kênh logic và có thể bị ẩn.

...

...

...

Tham khảo Phụ lục N để có thông tin đầy đủ về hồ sơ.

14.7.5.6. operator_info_req APDU

Máy chủ gửi APDU này cho CICAM để truy vấn thông tin nhà điều hành. CICAM trả lời bằng một operator_info () APDU trả về thông tin nhà điều hành gần như tĩnh cho máy chủ.

Bảng 14.44 Cú pháp operator_info_req APDU

Cú pháp

Số bit

Kiểu

operator_info_req() {
operator_info_req_tag
length_field()
}

24

...

...

...

Trong đó các trường được quy định như sau:

operator_info_req_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.7. operator_info APDU

CICAM gửi APDU này đến máy chủ để trả lời một operator_info_req () APDU. APDU này chứa thông tin quan trọng đối với máy chủ để phân tích và trình bày chính xác của cấu hình của SI này trong các bộ ghép kênh của mạng. Điều quan trọng là bất kỳ thông tin được cung cấp trong APDU này phù hợp chính xác hoạt động mạng thực tế nếu không thì hành vi của máy chủ thể bị ảnh hưởng xấu. Thông tin trong APDU này được xem là gần như tĩnh.

Bảng 14.45 - Cú pháp operator_info APDU

Trong đó các trường được quy định như sau:

operator_info_tag: Xem bảng L.1 tại Phụ lục L.

info_valid: đây là trường 1 bit, khi thiết lập là "1", chỉ ra rằng có các thông tin nhà khai thác. Bit này chỉ được thiết lập về "1" khi các thông tin nhà khai thác được phản ánh chính xác thông qua các nội dung của các mạng lưới phát sóng.

...

...

...

cicam_original_network_id: Trường 16-bit, xác định rõ định danh của original_network_id của các nhà điều hành dịch vụ theo sự phân bổ được tìm thấy trong ETSI TS 101 162 [32]. Trường này có thể khác với original_network_id được thông báo trong mạng do sự phát triển lịch sử của mạng.

cicam_identifier: trường 32-bit này xác định một trường hợp phần cứng cụ thể của CICAM. Các cicam_identifier phải là duy nhất để sử dụng kết hợp với CICAM_original_network_id để liên kết một CICAM với một hồ sơ nhà khai thác. Ví dụ, giá trị có thể được xây dựng bằng những việc sau đây:

• băm của CICAM_ID

• băm của số sê ri của thiết bị CICAM

• băm của trường số sê ri của xác thực thiết bị CICAM

• giá trị được xác định bởi nhà sản xuất CICAM

Các cơ hội của hai CICAM với cùng định danh sẽ phải ít hơn 1 trong 109. Máy chủ có thể sử dụng giá trị trường này kết hợp với các thông tin khác về CICAM để kết hợp một danh sách các kênh cấu hình tới một CICAM nhất định.

character_code_table: trường 8-bit này xác định việc mã hóa bộ ký tự mặc định đã được sử dụng trên mạng, trong đó nhà điều hành mạng đã thay đổi so với định dạng mã hóa ký tự DVB được quy định trong ETSI EN 300 468 [10], Phụ lục A. Mặc định là 0x00 trình bày bảng mã ký tự DVB 00 - bảng chữ cái Latin được quy định nghĩa trong tiêu chuẩn ISO/IEC 6937. Trong đó, giá trị character_code_table khác không đã được trường này xác định thì tất cả các trường văn bản của mạng, bao gồm các trường văn bản trong các nhãn mô tả riêng CI Plus của NIT, không bắt đầu với dữ liệu không hiển thị, không khoảng trống phải lấy mã ký tự được trường này và/hoặc các trường liên quan của nó quy định.

encoding_type_id: trường 8-bit này làm rõ trường character_code_table khi được thiết lập là 0x1f và chỉ ra cơ chế mã hóa của chuỗi ký tự theo phân bổ được quy định trong ETSI TR 101 162.

...

...

...

third_byte_value: trường 8-bit này làm rõ trường character_code_table khi được thiết lập là 0x10 và giá trị byte thứ hai của 16-bit này được sử dụng để xác định bảng mã ký tự theo quy định tại ETSI EN 300 468 [10], Phụ lục A, Bảng A.4.

sdt_running_status_trusted: trường 1-bit này là một gợi ý cho máy chủ để xác định nếu trường running_status của SDT là chính xác, là đáng tin cậy và có thể được máy chủ phân tích. Khi trường này được thiết lập là "1" thì trạng thái đang chạy của SDT là đáng tin cậy và thiết bị thu máy chủ có thể chỉ ra các dịch vụ không trong trạng thái hoạt động đang chạy. Khi trường được thiết lập là "0", thì trạng thái đang chạy SDT phải được phân tích để luôn trong trạng thái đang chạy. Hoạt động máy chủ mặc định là "0".

eit_running_status_trusted: trường 1-bit này là một gợi ý cho máy chủ để xác định nếu trường running_status của EIT là chính xác, là đáng tin cậy và có thể được máy chủ phân tích. Khi trường này được thiết lập là "1" thì trạng thái đang chạy của EIT là đáng tin cậy và chỉ ra một cách chính xác xem các dịch vụ có đang trong trạng thái hoạt động đang chạy. Khi trường được thiết lập là "0" thì máy chủ phải cho rằng trạng thái đang chạy của EIT luôn trong trạng thái hoạt động đang chạy. Hoạt động máy chủ mặc định là "0".

eit present_following_usage: trường 2-bit này mô tả trạng thái hoạt động của thông tin sự kiện EIT _{hiện tại/ tiếp theo} trong mạng theo các giá trị trong Bảng 14.47. Hoạt động máy chủ mặc định thu được từ bộ ghép kênh nội bộ (1).

Bảng 14.47 - Các giá trị hoạt động hiện tại/tiếp theo của EIT

Giá trị

Mô tả

0

Không có bảng EIT.

...

...

...

Có bảng EIT trên mạng. Bảng EIT không được vận chuyển chéo đầy đủ và chỉ được phân phối trên bộ ghép kênh chứa dịch vụ. Máy chủ bắt buộc phải dò tìm xung quanh mạng để thu thập thông tin EIT đầy đủ. Các mạng vận chuyển chéo một phần phải gửi thiết lập này.

2

Có bảng EIT trên mạng và phải được vận chuyển chéo đầy đủ. Máy chủ có thể ở lại trên cùng bộ ghép kênh để thu thập thông tin EIT đầy đủ.

3

Dự phòng.

eit_schedule_usage: trường 3-bit này mô tả trạng thái hoạt động của thông tin sự kiện theo lịch của EIT trong mạng theo các giá trị trong Bảng 14.48. Hoạt động máy chủ mặc định thu được từ bộ ghép kênh nội bộ (1) hoặc hoạt động kênh quảng cáo (3) khi một liên kết dịch vụ EPG là sẵn có.

Bảng 14.48 - Các giá trị hoạt động theo lịch của EIT

Giá trị

Mô tả

...

...

...

Không có bảng EIT.

1

Có bảng EIT trên mạng. Bảng EIT không được vận chuyển chéo đầy đủ và chỉ được phân phối trên bộ ghép kênh chứa dịch vụ. Máy chủ bắt buộc phải dò tìm xung quanh mạng để thu thập thông tin EIT đầy đủ. Các mạng vận chuyển chéo một phần phải gửi thiết lập này.

2

Có bảng EIT trên mạng và phải được vận chuyển chéo đầy đủ. Máy chủ có thể ở lại trên cùng bộ ghép kênh để thu thập thông tin EIT đầy đủ.

3

Có bảng EIT trên mạng và có sẵn từ một kênh Barker. Máy chủ buộc phải chuyển sang kênh Barker để thu thập thông tin EIT đầy đủ. Vị trí kênh Barker được thông báo trong bộ mô tả kết nối với Iinkage_type0x02 (EPGService) trong vòng đầu tiên của NIT.

4

Thông tin ElectronicProgrammeGuideinformation được phân phối sử dụng một ứng dụng.

...

...

...

Dự phòng.

extended_event_usage: trường 1-bit này xác định cách thông tin sự kiện mở rộng được trình bày và xác định liệu các trường văn bản short_event_descriptor (0x4d) và extended_event_descriptor (0x4e) có được sử dụng loại trừ lẫn nhau. Các giá trị này được quy định tại Bảng 14.49.

Bảng 14.49 - Các giá trị ngữ nghĩa sự kiện mở rộng của EIT

Giá trị

Mô tả

0

Phần văn bản của extended_event_descriptor khác với short_event_descriptor và phải được ghép lại cùng nhau để cung cấp thông tin sự kiện mở rộng.

1

Phần văn bản của extended_event_descriptor chứa phần văn bản của short_event_descriptor và các bộ mô tả này được sử dụng loại trừ lẫn nhau. short_event_descriptor được dùng riêng để cung cấp một mô tả ngắn, extended_event_descriptor được dùng riêng để cung cấp một mô tả văn bản đầy đủ hơn.

...

...

...

eit_event_trigger: trường 1-bit này xác định nếu việc chuyển đổi sự kiện EIT _{hiện tại/tiếp theo} trên mạng là đủ chính xác để được sử dụng cho việc ghi lại dựa trên sự kiện. Khi trường được thiết lập là "1" thì việc chuyển đổi sự kiện EIT_p/f (khi EIT _{tiếp theo} trở thành EIT _{hiện tại}) được chuyển đổi chính xác và có thể được sử dụng như tín hiệu kích hoạt để bắt đầu và dừng ghi lại của một sự kiện. Khi trường này là "0" thì việc chuyển đổi EIT _p/f là không chính xác và máy chủ có thể sử dụng một cơ chế khác để đảm bảo rằng toàn bộ sự kiện được ghi lại tức là bổ sung thời gian 5 phút cho đoạn quảng cáo phim và đoạn dẫn đầu phim trước và sau thời gian sự kiện này thông báo.

Tín hiệu kích hoạt EIT _p/f yêu cầu nhà điều hành dịch vụ sắp xếp chính xác nội dung truyền hình với việc cung cấp sự kiện và chỉ cho phép các sự kiện được chuyển đổi khi thay đổi nội dung chương trình. Điều này yêu cầu nhà điều hành dịch vụ giữ sự kiện hiện tại khi một chương trình đang chạy chậm và chuyển đổi sang sự kiện tiếp theo khi một chương trình đang chạy nhanh.

ISO_639_language_code: trường 24-bit này xác định mã ngôn ngữ mặc định của các trường văn bản và các thành phần dòng thành phần chưa được dán nhãn. Mã ngôn ngữ mặc định được máy chủ sử dụng để thực hiện lựa chọn thành phần và văn bản trong trường hợp không có bất kỳ thông báo rõ ràng từ nhà điều hành dịch vụ. Các mã ngôn ngữ mà không xác định (bao gồm cả "und" hoặc "qaa") phải được giả định là mã ngôn ngữ mặc định được trường này quy định.

profile_name_length: trường 8-bit này xác định độ dài theo byte của trường văn bản tiếp theo mô tả tên hồ sơ. Đối với profile_type = 1 trường này phải luôn khác không và chứa một tên hồ sơ hợp lệ. Trường này có thể bằng không (0) nếu không có tên hồ sơ.

profile_name_byte: Đây là một trường 8-bit, một chuỗi các trường "char" quy định tên hồ sơ này. Thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được xác định trong ETSI EN 300 468 [10], Phụ lục A. Tên hồ sơ phải được sử dụng để dán nhãn cho một hồ sơ và phải được sử dụng ưu tiên hơn bất kỳ tên trên mạng được tìm thấy trong bất kỳ thông tin truyền hình hoặc CICAM NIT.

14.7.5.8. operator_search_start APDU

Máy chủ gửi APDU này cho CICAM để bắt đầu một trình tự tìm kiếm hồ sơ. Khi gửi APDU thì máy chủ bỏ quyền kiểm soát và chuyển quyền kiểm soát đó (MMI và dò kênh) cho CICAM. Trong trường hợp tìm kiếm này thì CICAM phải kiểm soát giao diện người sử dụng thông qua MMI ứng dụng hoặc cấp cao và có thể kiểm soát bộ dò kênh của máy chủ kênh để di chuyển trong mạng để có được thông tin hồ sơ. Khi CICAM hoàn thành việc tìm kiếm này thì nó phải trả lời cho máy chủ bằng một profile_search_status () APDU.

Bảng 14.50 - Cú pháp operator_search_start APDU

Cú pháp

...

...

...

Kiểu

operator_search_start() {
operator_search_start_tag
length_field()
unattended_flag
service_type_loop_length
for (i=0; i<N; i++) {
service_type
}
delivery_capability_loop_length
for (i=0; i<N; i++){
delivery_capability_byte
}
application_capability_loop_length
for (i=0; i<N; i++) {
application_capability_byte;
}
}

24

1
7

8

8

8

8

8

uimsbf

bslbf
uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

operator_search_start_tag: Xem bảng L.1 tại Phụ lục L.

unattended_flag: trường 1-bit này xác định xem máy chủ có đang hoạt động trong chế độ không tham gia (tức là không có mặt người sử dụng). Giá trị "1" chỉ ra rằng không có mặt người sử dụng và máy chủ là không thể sử dụng bất kỳ các yêu cầu tương tác. Khi máy chủ là không tham gia thì CICAM phải tránh sử dụng MMI cấp cao hoặc ứng dụng vì chúng có thể không được sử dụng. Giá trị "0” chỉ ra rằng người sử dụng có mặt và màn hình tương tác có thể được CICAM sử dụng.

service_type_loop_length: trường 7-bit này xác định số byte tiếp theo ngay sau trường này xác định danh sách service_type của máy chủ có thể sẵn có.

service_type: trường 8-bit này quy định loại dịch vụ mà máy chủ có thể sẵn có. Các giá trị loại dịch vụ được xác định bởi trường service_type trong service_descriptor được mô tả trong EN 300 468 [10].

Ví dụ:

...

...

...

Các dịch vụ truyền hình MPEG-2 (0x01) và phát thanh Layer-ll (0x02), MPEG-1 được hỗ trợ.

0x01020c

Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-ll (0x02), MPEG-1 và dữ liệu được trường application_capability_byte (0x0c) xác định được hỗ trợ.

0x0102030a16

Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-ll (0x02), MPEG-1, Teletext (0x03), phát thành mã hóa tiên tiến (0x0a) và video SD mã hóa tiên tiến (0x16) được hỗ trợ

0x0102030a101619

...

...

...

delivery_capability_loop_length: trường 8-bit này xác định độ dài theo byte của vòng delivery_capability.

delivery_capability_byte: trường 8-bit này mô tả (các) hệ thống cung cấp được máy chủ hỗ trợ. Mỗi hệ thống cung cấp được máy chủ hỗ trợ được nhãn mô tả hệ thống cung cấp.

descriptor_tag EN 300 468 [10] mô tả, bất kỳ nhãn mô tả mở rộng được bắt đầu bằng thẻ mô tả mở rộng (0x7F). Máy chủ có thể lựa chọn để thông báo tất cả các nhãn mô tả hệ thống cung cấp được hỗ trợ hoặc các nhã mô tả hệ thống cung cấp có thể áp dụng đối với chế độ hoạt động hiện tại của máy chủ.

Ví dụ:

 0x43

DVB-S. Một máy chủ chỉ có một bộ dò kênh truyền hình vệ tinh.

0x4379

DVB-S và DVB-S2. Một máy chủ có một bộ dò kênh truyền hình vệ tinh hỗ trợ S và S2.

...

...

...

0x5a7f0444

DVB-T, DVB-T2 và DVB-C. Một máy chủ có bộ dò kênh lai truyền hình mặt đất và cáp đa chức năng.

application_capability_loop_length: trường 8-bit này xác định độ dài theo byte của vòng application_capability.

application_capability_byte: trường 8-bit này mô tả nhiều hay không ứng dụng nào được máy chủ hỗ trợ. Mỗi ứng dụng được máy chủ hỗ trợ được mô tả bằng một giá trị data_broadcast_id 16-bit ETSI TR 101 162, nhiều môi trường ứng dụng được thông báo bằng cách bao gồm nhiều giá trị 16-bit tương ứng với từng môi trường ứng dụng được hỗ trợ. Máy chủ chỉ phải thông báo những loại ứng dụng sẵn có.

Các phiên bản của các hồ sơ ứng dụng chưa được xác định và không có gì đảm bảo rằng máy chủ có thể hỗ trợ phiên bản của bất kỳ môi trường ứng dụng nào.

Ví dụ:

0x00f0

Máy chủ hỗ trợ truyền hình MHP

...

...

...

Máy chủ hỗ trợ truyền hình hồ sơ MHEG-5

0x01230107

Hỗ trợ máy chủ truyền hình HbbTV và Open TV

14.7.5.9. operator_search_cancel APDU

Máy chủ sẽ gửi APDU này đến CICAM để hủy một chuỗi tìm kiếm hồ sơ. Về việc ban hành APDU sau đó máy chủ yêu cầu CICAM chấm dứt việc tìm kiếm hồ sơ hiện tại và đáp ứng ngay với một operator_search_status () APDU. Các CICAM phải cố ngăn chặn việc tìm kiếm hồ sơ hiện hành càng nhanh càng tốt, ví dụ như không cần chờ đợi bất kỳ operator_tune_status nào ().

Bảng 14.51: Cú pháp operator_search_cancel APDU

Cú pháp

Số bit

...

...

...

operator_search_cancel() {
operator_search_cancel_tag
length_field() = 0
}

24

uimsbf

Trong đó các trường được quy định như sau:

operator_search_cancel_tag: Xem bảng L.1 trong Phụ lục L.

14.7.5.10. operator_search_status APDU

APDU này được CICAM gửi để thông báo cho máy chủ rằng việc tìm kiếm hồ sơ đã được hoàn thành. Nội dung APDU giống như một operator_status () APDU ngoại trừ thẻ của APDU này.

Vào điểm cuối của việc tìm kiếm nhà khai thác thì CICAM phải thiết lập các thiết lập cờ trong operator_status_body () để phản ánh chính xác tình trạng hiện tại, ví dụ cờ refresh_request_flag sẽ phải được loại bỏ hoặc khởi tạo với yêu cầu tìm kiếm tiếp theo. Máy chủ sẽ xử lý operator_search_status () APDU như là một chỉ báo cho thấy việc tìm kiếm đã chấm dứt và sẽ xử lý bổ sung tất cả các lá cờ của operator_status_body () để xác định tình trạng hiện tại của hồ sơ cá nhân điều hành. Các CICAM không ban hành một APDU operator_status () bổ sung cho một operator_search_status () APDU vào điểm cuối của tìm kiếm.

Bảng 14.52 - Cú pháp operator_profile APDU

...

...

...

Số bit

Kiểu

operator_search_status () {
operator_search_status_tag
length_field()
operator_status_body()
}

24

uimsbf

Trong đó các trường được quy định như sau:

operator_search_status_tag: Xem bảng L.1 tại Phụ lục L.

operator_status_body (): Xem Bảng 14.38 trong phần 14.7.5.3.

14.7.5.11. operator_tune APDU

...

...

...

Yêu cầu máy chủ dò kênh đến vị trí được trường delivery_system_descriptor quy định và để dòng truyền tải của vị trí này truyền qua CICAM. Nhiều vị trí có thể được APDU này xác định và máy chủ phải cố gắng dò kênh từng vị trí theo thứ tự mà chúng được thể hiện trong APDU này cho đến khi máy chủ xác định một tín hiệu truyền dữ liệu hợp lệ khi việc tìm kiếm kết thúc mà không có bất kỳ xử lý nào đối với các vị trí này và một operator_tune_status () APDU được trả về cho CICAM xác định đã tìm thấy bộ ghép kênh này.

Máy chủ phải tính các nhãn mô tả được xử lý trong vòng nhãn mô tả của APDU này và yêu cầu máy chủ phải trả về số của nhãn mô tả của nhãn mô tả chưa được xử lý tiếp theo cho CICAM trong operator_tune_status () APDU khi hoàn thành việc dò kênh. Việc tính nhãn mô tả bắt đầu từ 0 tương ứng với nhãn mô tả đầu tiên của vòng này.

Việc xử lý của máy chủ đối với yêu cầu dò kênh được mô tả sau đây:

Máy chủ phải sử dụng bất kỳ sự hỗ trợ phần cứng của bộ dò kênh để tăng tốc độ tìm kiếm và có thể bỏ qua các vị trí dò kênh không khởi tạo một hoạt động dò kênh rõ ràng nếu vị trí dò kênh này được cho là đã được phần cứng này tìm kiếm trước đó. Việc tối ưu hóa máy chủ này dựa vào việc CICAM nhóm một cách chính xác các yêu cầu dò kênh tương tự nhau sao cho máy chủ có thể xác định và loại bỏ các vị trí này.

Bảng 14.53 - Cú pháp operator_tune APDU

Cú pháp

Số bit

Kiểu

...

...

...

24

4
12

8

uimsbf

bslbf
uimsbf

uimsbf

Trong đó các trường được quy định như sau:

operator_tune_tag: Xem bảng L.1 tại Phụ lục L.

Iength_field (): APDU này phải bị giới hạn tối đa là 2048 byte để cho phép 157 system_delivery_descriptor với độ dài 13 byte.

descriptor_loop_length: trường 12-bit này xác định độ dài theo byte của vòng descriptor() tiếp theo trường này.

descriptor(): vòng các nhãn mô tả hệ thống cung cấp mô tả vị trí yêu cầu CICAM dò kênh. Vòng nhãn mô tả này phải bao gồm một hoặc nhiều nhãn mô tả hệ thống cung cấp đều từ cùng một hệ thống cung cấp. CICAM phải tạo một bộ thông số dò kênh đầy đủ và tối ưu trong nhãn mô tả cung cấp này, tức là các tần số phải được nhóm lại v.v... Máy chủ phải cố gắng dò kênh từng vị trí được quy định và xác định tín hiệu khả thi có dấu hiệu truyền dữ liệu phù hợp, ngay sau khi máy chủ xác định một vị trí tín hiệu truyền, hoặc đến cuối danh sách nhãn mô tả, thì hoạt động dò kênh này được dừng lại và trạng thái này được thông báo cho CICAM bằng một operator_tune_status () APDU.

14.7.5.12. operator_tune_status APDU

Máy chủ gửi APDU này cho CICAM để trả lời một operator_tune () hoặc APDU sau khi máy chủ đã dò kênh đến vị trí được yêu cầu.

...

...

...

Cú pháp

Số bit

Kiểu

operator_tune_status () {
operator_tune_status_tag
length_field()
descriptor_number
signal_strength
signal_quality
status
descriptor_loop_length
for (i=0; i<N; i++){
descriptor()
}
}

24

8
8
8
4
12

8

uimsbf

uimsbf
uimsbf
uimsbf
uimsbf
uimsbf

uimsbf

Trong đó các trường được quy định như sau:

operator_tune_status_tag: Xem bảng L.1 tại Phụ lục L.

descriptor_number: trường 8-bit này xác định số của nhãn mô tả chưa được xử lý tiếp theo trong operator_tune () APDU mà chưa được máy chủ xử lý, giá trị 0xFF chỉ ra rằng máy chủ đã đến cuối của bảng này. Các nhãn mô tả được tính từ 0, việc xử lý descriptor_number được mô tả trong phần văn bản giới thiệu dành cho operator_tune () APDU.

...

...

...

Giá trị

Mô tả

0

Hoạt động dò kênh thành công và máy chủ đã chuyển thành công tới vị trí được yêu cầu; bộ dò kênh bị khóa và một tín hiệu số có sẵn. Dòng tín hiệu vận chuyển phải đi qua CICAM.

Trường descriptor_number phải là số chưa được xử lý tiếp theo.

Trường signal_strength phải khác không.

Trường signal_quality phải khác không.

Trường descriptors() phải chứa các delivery_system_descriptor mô tả vị trí dò kênh đạt yêu cầu hiện thời. Bộ mô tả này có thể sai khác một chút so với bộ mô tả phân phối CICAM gốc nếu thông tin này đã được sửa bởi thông tin bộ dò kênh của máy chủ.

1

...

...

...

Trường descriptor_number phải là số hiệu bộ mô tả chưa được xử lý tiếp theo. Trường signal_strength phải bằng không.

Trường signal_quality phải bằng không.

Trường descriptor_loop phải chứa các bộ mô tả không được hỗ trợ.

2

Tham số bộ mô tả hệ thống phân phối không hợp lệ.

Trường descriptor_number phải là số hiệu bộ mô tả chưa được xử lý tiếp theo.

Trường signal_strength phải bằng không.

Trường signal_quality phải bằng không.

Trường descriptor_loop phải chứa các bộ mô tả không hợp lệ.

...

...

...

Hoạt động dò kênh thành công và máy chủ đã chuyển thành công tới vị trí được yêu cầu và không có tín hiệu.

Trường descriptor_number phải bằng 0xff vì danh sách bộ mô tả đã được dò hết.

Trường signal_strength phải bằng không.

Trường signal_quality phải bằng không.

Trường descriptor_loop_length phải bằng không.

4-15

Dự phòng.

Trường hợp máy chủ thông báo một delivery_system_descriptor không xác định hoặc không hợp lệ thì máy chủ phải dừng tìm kiếm và trả về system_delivery_descriptor bị lỗi đến CICAM. CICAM sau đó có thể tạo lại danh sách dò kênh với một tập các vị trí dò kênh mới không chứa các mô tả có cùng một loại nếu tìm kiểm này được tiếp tục.

signal_strength: trường 8-bit này xác định cường độ tín hiệu theo giá trị phần trăm từ 0 đến 100, trong đó 0 là không có tín hiệu và 100 là một tín hiệu cường độ mạnh nhất. Lưu ý rằng chỉ số cường độ tín hiệu không phải là thước đo chất lượng tín hiệu và phải truy vấn trường signal_quality để đánh giá chất lượng tín hiệu.

...

...

...

status: 4-bit này là trạng thái của yêu cầu dò kênh. Các giá trị trạng thái được quy định trong Bảng 14.53.

descriptor_loop_length: trường 12-bit này xác định độ dài theo byte của vòng descriptor() tiếp theo trường này.

descriptor(): vòng các nhãn mô tả hệ thống cung cấp mô tả vị trí được dò kênh hiện tại của máy chủ được truyền qua CICAM hoặc các nhãn mô tả gây ra lỗi. Vòng nhãn mô tả chỉ được chứa một vị trí hệ thống cung cấp duy nhất, nó có thể được mô tả bằng một hoặc nhiều nhãn mô tả.

14.7.5.13. operator_entitlement_ack APDU

Máy chủ gửi APDU này cho CICAM để xác nhận rằng bất kỳ thay đổi về quyền đã được máy chủ xử lý, điều này có thể dẫn đến một thay đổi trong danh sách kênh logic v.v. CICAM phải gửi operator_status () APDU để trả lời lệnh này bằng trường entitlement_change_flag bị xóa.

Bảng 14.56 - Cú pháp operator_entitlement_ack APDU

Cú pháp

Số bit

Kiểu

...

...

...

24

uimsbf

Trong đó các trường được quy định như sau:

operator_entitlement_ack_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.14. operator_exit APDU

Máy chủ gửi APDU này cho CICAM để thông báo cho CICAM rằng máy chủ đã rời khỏi môi trường profile_type = 1 và đang hoạt động trong một danh sách kênh khác hoặc trường hợp khác. Bất kỳ dòng truyền tải truyền qua CICAM có thể không có nguồn gốc từ môi trường hồ sơ nhà điều hành này cho đến khi máy chủ trở lại môi trường nhà điều hành này được thông báo bằng một operator_status_req () APDU.

Bảng 14.57 - Cú pháp operator_exit APDU

Cú pháp

Số bit

...

...

...

operator_exit() {
operator_exit_tag
length_field()
}

24

uimsbf

Trong đó các trường được quy định như sau:

operator_exit_tag: Xem bảng L.1 tại Phụ lục L.

Phụ lục A

(quy định)

Bộ tạo số ngẫu nhiên

...

...

...

Bộ tạo số ngẫu nhiên được sử dụng để tạo ra các số ngẫu nhiên sau đây trong tiêu chuẩn này:

Bảng A1 - Các số ngẫu nhiên

Trường

Độ dài (bit)

Diễn giải

DHX

2048

Số mũ Diffie Hellman “x”

DHY

...

...

...

Số mũ Diffie Hellman “y”

Kp

256

Tiền thân của mã khóa CCK của CICAM đến máy chủ

Ns_Host

64

Yêu cầu SAC của máy chủ đến CICAM

Ns_Module

64

...

...

...

Auth_nonce

256

Nonce trong giao thức xác thực

Bộ tạo số ngẫu nhiên phải tuân theo một trong hai điều sau đây:

1) PRNG được mô tả trong SCTE 41 [5], điều 4.6.

Chú ý: Giá trị nhân duy nhất được tạo ra là pmg_seed trong tiêu chuẩn này. Trừ khi được ghi rõ ràng, các giá trị nhân này phải được xem là rất bí mật như được mô tả trong Bản quy định kỹ thuật cấp giấy phép CI Plus [33]. Việc triển khai SHA nên tuân theo danh sách xác nhận SHS, tham khảo Danh sách xác nhận SHS [11].

2) Thuật toán dựa vào AES theo ANSI X 9,31 [12] được minh họa trong hình A.1 và mô tả dưới đây:

Hình A.1 - Ví dụ PRNG dựa trên AES

...

...

...

Chú ý: Trừ khi được ghi rõ ràng, các giá trị k và S phải được xem là rất bí mật như được mô tả trong thỏa thuận cấp giấy phép.

Sự kết hợp của giá trị cố định k và giá trị nhân ban đầu S phải không thể đoán trước và duy nhất dành cho mỗi sản phẩm được cấp giấy phép. Bộ tạo nhân dành cho S phải tuân theo SP800-22b [36]. Nếu không có bộ tạo nhân dành cho S thì S phải được duy trì trong một thanh ghi không thay đổi, trong trường hợp này không yêu cầu một nguồn dữ liệu ngẫu nhiên. Ngoài ra DT phải đảm bảo là không lặp lại cho đến thời gian kế tiếp sản phẩm được cấp giấy phép này được khởi tạo lại.

Các giá trị 128 bit ngẫu nhiên R_i( i = 0,1...) được tạo ra như sau:

I_i = E_AES-128{k}(DT_i)

Eq.A.1

R_i = E_AES-128{k}(I_iÅS_i)

Eq.A.2

S_i=1 = E_AES-128{k}(I_iÅR_i)

Eq.A.3

...

...

...

Phụ lục B

(quy định)

Giao thức ID thiết bị

B.1. Bản quy định kỹ thuật ID thiết bị

Lưu ý: Định dạng ID thiết bị không được định nghĩa trong tiêu chuẩn này và có thể được lấy từ Đặc tả về giấy phép CI Plus [33].

Phụ lục C

(quy định)

...

...

...

C.1. Các thuật toán kiểm tra tổng

Phần này bị phản đối. Giao tiếp giữa các CICAM và các nhà khai thác dịch vụ không nằm trong phạm vi của tiêu chuẩn này.

Phụ lục D

(quy định)

Các khả năng SD và HD

D.1. Định nghĩa SD và HD

Trong tiêu chuẩn này định nghĩa một thiết bị SD hoặc một thiết bị HD không được xác định. Một thiết bị HD là một thiết bị có thể xử lý và giải mã tín hiệu HD được truyền qua giao diện chung. Ví dụ, điều này có nghĩa là thiết bị HD tuân thủ logo HD TV của EICTA. Một số quốc gia hay lục địa có những định nghĩa khác nhau của các chương trình logo, các định nghĩa logo khác có thể áp dụng cho phù hợp với các khả năng xử lý tín hiệu HD.

...

...

...

(quy định)

Kiểm tra các trường hợp sử dụng DVB-CI

E1. Khởi tạo

E.1.1. Bản quy định kỹ thuật

Tiêu chuẩn PCMCIA định nghĩa trong tập 2, điều 4.4.6 rằng máy chủ phải đợi 5 giây để thiết lập tín hiệu sẵn sàng. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

Thẻ mà yêu cầu nhiều hơn 20 ms để khởi tạo nội bộ trước khi việc truy nhập bị từ chối SẴN SÀNG cho đến khi nó đã sẵn sàng cho việc truy nhập ban đầu, khoảng thời gian không được nhiều hơn 5 giây sau thời điểm mà tín hiệu THIẾT LẬP LẠI bị từ chối (hoặc nếu không thực hiện thiết lập lại thì VCC là ổn định).

E.1.2. Yêu cầu

Máy chủ phải kiểm tra một cách rõ ràng tín hiệu SẴN SÀNG cho đến khi nó được mô-đun này thiết lập hoặc cho đến khi thời gian chờ 5 giây đã hết.

E.2. CA_PMT rõ ràng

...

...

...

Bản quy định kỹ thuật DVB-CI xác định trong "Hướng dẫn thực hiện và sử dụng giao diện chung dành cho các ứng dụng bộ giải mã DVB (R206-001:1998)" [24] rằng máy chủ phải gửi đối tượng ca_pmt ngay cả khi chương trình được lựa chọn là rõ ràng. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

CA_PMT được máy chủ gửi ngay cả khi chương trình rõ ràng được người sử dụng lựa chọn (thường là một chương trình không có CA_descriptor trong PMT). Trong trường hợp này, máy chủ phải gửi CA_PMT mà không có bất kỳ CA_descriptor (ví dụ: CA_PMT với program_info_length == 0 và ES_info_length == 0).

E.2.2. Yêu cầu

Máy chủ phải gửi CA_PMT ngay cả khi chương trình lựa chọn là rõ ràng (FTA).

E.3. CA_PMT rõ ràng sang bị xáo trộn /bị xáo trộn sang rõ ràng

E.3.1. Bản quy định kỹ thuật

Hướng dẫn thực hiện và sử dụng giao diện chung cho các ứng dụng bộ giải mã DVB (R206-001 [24]; điều 9.5.6.2) đã được định nghĩa:

Chuyển từ xáo trộn sang giải xáo trộn và ngược lại

• Khi một chương trình chuyển từ xáo trộn sang rõ ràng, có một số khả năng:

...

...

...

2. Thay đổi này dẫn đến sự thay đổi của PMT. Trong trường hợp này, một CA_PMT được máy chủ gửi.

• Khi một chương trình chuyển từ rõ ràng sang xáo trộn, có một số khả năng:

1. Sự thay đổi này không được thông báo trong PMT, nhưng lại có trong trường TSC của phần mào đầu gói tin hoặc trong trường PES_SC của phần mào đầu PES. Trong trường hợp này, máy chủ không gửi một CA_PMT mới. Ứng dụng CA phải phát hiện ra sự chuyển đổi đó.

2. Thay đổi này dẫn đến sự thay đổi của PMT (ví dụ: các CA_descriptor bị loại bỏ). Trong trường hợp này, một CA_PMT được máy chủ gửi.

Chú ý: Trong cả hai trường hợp, ứng dụng CA nên tạo ra một tương tác với người sử dụng để thông báo cho người sử dụng.

E.3.2. Khuyến nghị

Ứng dụng CA không được tạo ra một tương tác với người sử dụng khi không cần thiết.

E.4. Cập nhật PMT và CA_PMT mới

E.4.1. Bản quy định kỹ thuật

...

...

...

Nếu máy chủ muốn cập nhật một CA_PMT của một trong những chương trình trong danh sách thì nó gửi một CA_PMT với ca_pmt_list_management == cập nhật. Điều này xảy ra khi máy chủ phát hiện ra version_number hoặc current_next_indicator của PMT đã thay đổi. Sau đó ứng dụng CA trong mô-đun kiểm tra xem sự thay đổi này có những hệ quả trong hoạt động CA hay không. Nó cũng xảy ra khi danh sách các dòng thành phần của một chương trình được lựa chọn thay đổi (ví dụ: người sử dụng đã lựa chọn một ngôn ngữ khác). Trong trường hợp này, máy chủ phải gửi lại toàn bộ danh sách các dòng thành phần của chương trình được cập nhật đó.

E.4.2. Khuyến nghị

Khi phiên bản PMT đã thay đổi, đối tượng CA_PMT_Update phải được sử dụng để tránh một màn hình màu đen.

E.5. MMI tức thời

E.5.1. Bản quy định kỹ thuật

R206-001 [24] (điều 9.5.6.1) đã định nghĩa:

Các ứng dụng CA hiện tại không hoạt động cho bất kỳ chương trình hiện tại được người sử dụng lựa chọn có thể tạo ra các phiên MMI dành cho tương tác với người sử dụng, ví dụ như để cảnh báo về một sự kiện PPV sắp xảy ra trên một chương trình khác đã được người sử dụng mua trước đó.

E.5.2. Giải pháp

Hiển thị tất cả các bản tin MMI được CICAM gửi. Không cho phép tự động MMI đóng, cho phép người sử dụng đóng MMI.

...

...

...

E.6. Dòng truyền tải đến CICAM

E.6.1. Bản quy định kỹ thuật

Bản quy định kỹ thuật DVB-CI trong EN 50221 [7] (điều 5.4.3) định nghĩa rằng một kết nối dòng truyền tải phải được thiết lập nếu mô-đun này tuân thủ DVB. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

Khi một mô-đun không được kết nối, giao diện dòng truyền tải phải bỏ qua mô-đun này và giao diện lênh của mô-đun này phải là không hoạt động. Khi có kết nối với mô-đun, máy chủ phải khởi tạo một trình tự khởi tạo cấp thấp với mô-đun này. Điều này sẽ thực hiện bất cứ thủ tục thiết lập kết nối cấp thấp được lớp vật lý cụ thể sử dụng, và sau đó xác nhận rằng mô-đun này tuân thủ DVB. Nếu thành công hoàn toàn, máy chủ phải thiết lập kết nối dòng truyền tải bằng cách chèn mô đun này vào đường dẫn dòng truyền tải của máy chủ. Có thể chấp nhận rằng một số dữ liệu của dòng truyền tải bị mất trong quá trình này.

E.6.2. Giải pháp

Luôn luôn gửi dòng truyền tải đến CICAM khi nó đã được khởi tạo.

E.7. Trả lời về hồ sơ

E.7.1. Bản quy định kỹ thuật

Bản quy định kỹ thuật DVB-CI trong EN 50221 [7] (điều 8.4.1.1) định nghĩa rằng khi một truy vấn hồ sơ được máy chủ hoặc mô-đun gửi, một trả lời về hồ sơ phải được mô-đun hoặc máy chủ gửi. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

...

...

...

Điều đầu tiên một ứng dụng hoặc nhà cung cấp tài nguyên làm là yêu cầu một phiên đến tài nguyên Nhà quản lý tài nguyên, được tạo ra không thay đổi vì nhà quản lý tài nguyên không có hạn chế phiên. Sau đó Nhà quản lý tài nguyên gửi một yêu cầu hồ sơ cho ứng dụng hoặc nhà cung cấp tài nguyên này để được trả lời bằng một trả lời hồ sơ liệt kê các tài nguyên mà nó cung cấp (nếu có), ứng dụng hoặc nhà cung cấp tài nguyên bây giờ phải chờ đợi một đối tượng thay đổi hồ sơ. Trong khi chờ đợi đối tượng thay đổi hồ sơ này nó không được tạo ra các phiên đến các tài nguyên khác cũng như không được chấp nhận các phiên từ các ứng dụng khác, mà trả về một trả lời là ‘tài nguyên không tồn tại’ hoặc ‘tài nguyên tồn tại nhưng không có sẵn’ cho phù hợp.

E.7.2. Khuyến nghị

Trả lời đối với đối tượng yêu cầu hồ sơ.

E.8. Hoạt động trên một bus dùng chung

E.8.1. Giới thiệu

Trong nhiều thiết lập, một khe PCMCIA dùng chung địa chỉ và các đường dữ liệu với các thiết bị khác như một khe PCMCIA thứ hai hoặc một chip bộ nhớ cực nhanh. Mỗi thiết bị sẽ có đường cho phép chip riêng, đường này điện áp thấp khi việc truy nhập hiện tại liên quan đến một thiết bị cụ thể này. Đối với một khe PCMCIA, đường cho phép chip này được kết nối với chân CICAM Chip Enable # 1 (CE1 #), Chip Enable # 2 (CE2 #) không sử dụng.

E.8.2. Khuyến nghị

CICAM phải kiểm tra chân CE1 # của nó và chắc chắn rằng nó là điện áp thấp trước khi xử lý bất kỳ dữ liệu từ bus dữ liệu. Khi chân Chip Enable # 1 (CE1 #) điện áp cao, CICAM không được gửi bất kỳ dữ liệu hoặc thay đổi trạng thái nội bộ của nó dựa trên các tín hiệu từ bus dữ liệu.

E.9. Kích thước APDU tối đa

...

...

...

Các đối tượng được mã hoá bằng mã hóa Tag-Length-Value chung theo mã hóa được sử dụng để mã hóa cú pháp ASN.1.

Và tiếp theo trong phần này quy định:

Do đó bất kỳ giá trị độ dài trường có giá trị lên đến 65535 có thể được mã hóa bằng ba byte.

Các nguyên tắc mã hóa cơ bản ASN.1 (BER) cho phép mã hóa với các độ dài sử dụng nhiều hơn ba byte. Việc sử dụng định dạng dài này cho một giá trị độ dài có thể sử dụng tối đa 127 byte đối với một độ dài được mã hóa có độ dài 128 byte để đại diện cho một độ dài lớn hơn 10^305 byte.

Đoạn thứ hai trong văn bản của EN 50.221 thực chất là một ví dụ về cách chúng ta có thể sử dụng ba byte để mã hóa một độ dài. Chúng ta đều có thể đưa ra một ví dụ sử dụng bốn byte để có thể mã hóa một độ dài lên đến 16 777 216 byte.

E.10. Tài nguyên kiểm soát máy chủ

E.10.1. Bản quy định kỹ thuật

Tài nguyên kiểm soát máy chủ 00x200041 là bắt buộc đối với một máy chủ Cl Plus, nó cho phép CICAM dò kênh đến một dịch vụ để nâng cấp CAM theo quy định tại điều 14.3 và các ứng dụng loại Video on Demand.

E.10.2. Khuyến nghị

...

...

...

E.11. Trả lời CA-PMT

E.11.1. Bản quy định kỹ thuật

Bản quy định kỹ thuật DVB-CI định nghĩa trong EN 50221 [7] (điều 8.4.3.5). Đối tượng này luôn được ứng dụng này gửi đến máy chủ sau khi nhận một đối tượng CA PMT với ca_pmt_cmd_id được thiết lập là ‘truy vấn’. Nó cũng có thể được gửi sau khi nhận một đối tượng CA PMT với ca_pmt_cmd_id được thiết lập là 'ok_mmi' để thông báo cho máy chủ kết quả của tương tác MMI ('descrambling_possible' nếu người sử dụng đã mua, ‘descrambling not possible’ (vì không có quyền) nếu người sử dụng chưa mua).

E.11.2. Khuyến nghị

CICAM phải luôn luôn gửi một CA-PMT Reply khi đối tượng PMT được gửi với ca_pmt_cmd_id được thiết lập là 'truy vấn'.

E.12. Tài nguyên CC và CP

E.12.1. Bản quy định kỹ thuật

Tài nguyên CC trong Cl Plus cho phép tăng cường kiểm soát nội dung bằng cách sử dụng URI như được định nghĩa trong điều 5.7, các phần mở rộng trong DVB TS 101 699 [8], điều 6.6, cung cấp tài nguyên CP để kiểm soát nội dung. Cả hai tài nguyên này được sử dụng để kiểm soát việc phân phối nội dung và không bao giờ được mở cùng một lúc.

E.12.2. Khuyến nghị

...

...

...

E.13. Các yêu cầu vật lý

E.13.1. Giao diện dữ liệu

EN 50221 [7] điều 5.4.2.5 quy định:

Tất cả giao diện phải hỗ trợ tốc độ dữ liệu trung bình ít nhất là 58 Mb/s trong khoảng giữa các byte đồng bộ của các gói tin truyền tải liên tiếp.

Tiêu chuẩn này làm tăng yêu cầu đối với tốc độ dữ liệu này. Các CICAM tuân thủ tiêu chuẩn này phải hỗ trợ 96 Mb/s. Máy chủ tuân thủ tiêu chuẩn này có băng thông đủ lớn dành cho các giao diện mạng của chúng. Tham khảo điều 11.1.3 để biết thêm thông tin về các yêu cầu tốc độ dữ liệu Cl Plus.

E.13.2. Giao diện lệnh

EN 50221 [7] điều 5.4.2 quy định:

Giao diện lệnh phải truyền các lệnh theo quy định của phần Lớp Truyền tải phù hợp trong tiêu chuẩn này theo cả hai hướng. Tốc độ dữ liệu được hỗ trợ trong mỗi hướng phải ít nhất là 3,5 Mbit/giây.

Yêu cầu này chỉ được áp dụng cho tiêu chuẩn này.

...

...

...

E.14.1. Bản quy định kỹ thuật

Trong điều 8.7.1.5 của EN 50221 [7] return_value trong phần mô tả của mã hóa đối tượng Comms Reply được phân loại theo kiểu “uimsbf”. Tuy nhiên, trong văn bản của bản quy định kỹ thuật này quy định là return_value chứa các giá trị âm để chỉ ra lỗi và đặc biệt là giá trị -1 dành cho các lỗi không xác định.

E.14.2. Khuyến nghị

Trường return_value 8 bit trong một comms_reply APDU nên được phân tích là một giá trị “hai thành phần" có dấu.

E.15. Mã hóa đối tượng văn bản MMI cấp cao

E.15.1. Bản quy định kỹ thuật

Điều 8.6.5.1 của EN 50221 [7] quy định rằng thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10] và văn bản đó được ứng dụng này gửi có thể bao gồm các ký tự kiểm soát như được quy định trong [10] để cung cấp chỉ dẫn về cách hiển thị sẽ được trình bày.

Máy chủ có thể trình bày bất kỳ đối tượng văn bản mà không có một byte lựa chọn bảng ký tự đứng trước như Bảng 00 - Bảng chữ cái Latinh như trong EN 300 468 [10] Phụ lục A1, hình A.1, mà có thể không phải là những gì CICAM muốn.

E.15.2. Khuyến nghị

...

...

...

E.16. Đối tượng dò kênh kiểm soát máy chủ DVB

E.16.1. Bản quy định kỹ thuật

Điều 8.5.1.1 của EN 50221 [7] mô tả cách thức tài nguyên kiểm soát máy chủ cho phép CICAM hướng dẫn máy chủ dò kênh đến một vị trí khác. Vị trí mới này được tổ hợp của network_id, original_network_id, transport_stream_id và service_id xác định. Hành vi của thiết bị thu khi một số các giá trị là số không và bất kỳ phương pháp thiết lập giá trị thẻ không được mô tả.

E.16.2. Khuyến nghị

network_id không nên được sử dụng. Giá trị không (0) phải được xem xét đối với thẻ hoặc không được sử dụng. Nên chỉ có hai tổ hợp hợp lệ của thông số dò kênh và giá trị thẻ. Tổ hợp hợp lệ được trình bày trong Bảng E.1.

Bảng E.1 - Tổ hợp hợp lệ của các thông số đối tượng dò kênh kiểm soát máy chủ DVB

network_id

transport_

stream_id

...

...

...

network_id

service_id

Thực hiện

0

TSID

ONID

SID

Dò kênh kếnh một dịch vụ, dịch vụ này phải tồn tại

0

...

...

...

ONID

0

Dò kênh đến một bộ ghép kênh, máy chủ không lựa chọn dịch vụ, ca_pmt sẽ không được máy chủ gửi.

CHÚ THÍCH: Giả thiết rằng thiết bị thu có vị trí mong muốn đã được tham chiếu trong danh sách dịch vụ của nó để có thể lấy các thông số dò kênh thực. Danh sách dịch vụ của máy chủ có thể chỉ chứa các dịch vụ mà máy chủ có thể nhận biết, tức là chỉ các dịch vụ truyền hình và phát thanh

E.17. Hỗ trợ truy nhập có điều kiện

E.17.1. Bản quy định kỹ thuật

EN 50221 [7], điều 8.4.3.4 quy định:

CA PMT chứa tất cả các CA_descriptor của chương trình được lựa chọn. Nếu một số chương trình được lựa chọn, máy chủ gửi một số đối tượng CA PMT đến ứng dụng này. CA_PMT chỉ chứa các CA_descriptor. Tất cả các nhãn mô tả khác phải được máy chủ loại bỏ khỏi PMT.

R206-001:1998 [24], điều 9.5.5 quy định:

...

...

...

E.17.2. Yêu cầu đối với máy chủ

Khi lựa chọn một dịch vụ được giải xáo trộn, yêu cầu máy chủ xử lý tất cả các CA_descriptor xuất hiện trong cả vòng nhãn mô tả đầu tiên (Program Stream Loop) và vòng nhãn mô tả thứ hai (Elementary Stream Loop) của PMT. Nhiều CA_descriptor với CA_system_ID khác nhau có thể có trong một hoặc cả hai vòng.

Máy chủ phải truyền tất cả các CA_descriptor có trong PMT đến CICAM trong ca_pmt sử dụng cấp chương trình tương ứng và/hoặc các vòng cấp dòng thành phần, ngoại trừ máy chủ có thể tùy chọn loại bỏ bất kỳ CA_descriptor không phù hợp với bất kỳ CA_system_id được CICAM thông báo trong ca_info () APDU.

Máy chủ nên, không bắt buộc, duy trì thứ tự CA_descriptor và dòng thành phần giống nhau của PMT trong ca_pmt.

E.17.3. Yêu cầu đối với CICAM

CICAM phải bao gồm tất cả các CA_system_ID mà nó hỗ trợ trong ca_info () APDU khi có yêu cầu của máy chủ.

CICAM phải chắc chắn về sự có mặt của nhiều CA_descriptor có thể xuất hiện theo một thứ tự bất kỳ. CICAM phải chắc chắn về sự có mặt của các CA_descriptor phù hợp với bất kỳ (các) CA_system_id của CICAM và phải bỏ qua các CA_descriptor nếu chúng không được CICAM hỗ trợ.

CICAM phải chắc chắn về thứ tự của các dòng thành phần và phải có khả năng giải xáo trộn các dòng thành phần được CA hỗ trợ và thông báo một cách chính xác mà không phân biệt thứ tự của chúng trong ca_pmt.

E.18. Xử lý phiên bản tài nguyên

...

...

...

En 50.221 [7], điều 8.4.1.1 quy định:

Khi máy chủ yêu cầu về các hồ sơ trên tất cả các kết nối truyền tải và trả lời hồ sơ đã nhận được thì máy chủ xây dựng một danh sách các tài nguyên sẵn có. Trường hợp có hai hoặc nhiều tài nguyên phù hợp trong cả lớp và loại thì máy chủ giữ một tài nguyên với số phiên bản cao nhất trong danh sách của nó.

E.18.2. Yêu cầu

Trong trường hợp máy chủ hỗ trợ nhiều phiên bản của cùng một tài nguyên thì số phiên bản cao nhất của tài nguyên chỉ được máy chủ thông báo. Các phiên bản thấp hơn của tài nguyên phải được máy chủ hỗ trợ nhưng không được thông báo trong profile_reply () APDU.

CICAM có thể yêu cầu một phiên bản thấp hơn của tài nguyên so với phiên bản được máy chủ thông báo, điều này được thảo luận trong điều E.19.

E.19. Yêu cầu mở phiên

E.19.1. Bản quy định kỹ thuật

En 50.221 [7], điều 7.2.6.1 quy định:

Đối tượng này được mô-đun gửi đến máy chủ để yêu cầu mở một phiên giữa mô đun này và một tài nguyên được máy chủ hoặc mô-đun cung cấp. resource_identifier phải phù hợp với cả lớp và loại của tài nguyên mà máy chủ có trong danh sách các tài nguyên sẵn có. Nếu trường phiên bản của nhãn định danh tài nguyên được cung cấp là số không thì máy chủ sẽ sử dụng phiên bản hiện tại trong danh sách của nó. Nếu số phiên bản trong yêu cầu là nhỏ hơn hoặc bằng số phiên bản hiện tại trong danh sách của máy chủ thì phiên bản hiện tại được sử dụng. Nếu số phiên bản được yêu cầu cao hơn so với các phiên bản trong danh sách của máy chủ thì máy chủ sẽ từ chối yêu cầu với mã trả về phù hợp.

...

...

...

Nội dung sửa đổi so với EN 50221 [7] như sau:

Đối tượng này được mô-đun gửi đến máy chủ để yêu cầu mở một phiên giữa mô đun này và một tài nguyên được máy chủ hoặc mô-đun cung cấp. resource_identifier phải phù hợp với cả lớp và loại của tài nguyên mà máy chủ có trong danh sách các tài nguyên sẵn có. Nếu trường phiên bản của nhãn định danh tài nguyên được cung cấp là số không thì máy chủ sẽ sử dụng phiên bản hiện tại trong danh sách của nó. Nếu số phiên bản trong yêu cầu là bằng với số phiên bản hiện tại trong danh sách của máy chủ thì phiên bản hiện tại được sử dụng. Nếu số phiên bản trong yêu cầu nhỏ hơn so với số phiên bản hiện tại trong danh sách của máy chủ thì máy chủ phải sử dụng số phiên bản theo yêu cầu của CICAM. Nếu số phiên bản được yêu cầu cao hơn so với các phiên bản trong danh sách của máy chủ, sau đó máy chủ sẽ từ chối yêu cầu với mã trả về phù hợp.

Yêu cầu máy chủ phải luôn luôn hỗ trợ tất cả các phiên bản thấp hơn của một tài nguyên được thông báo.

E.19.3. Khuyến nghị

CICAM không nên sử dụng trường phiên bản của nhãn định danh tài nguyên là số không và phải quy định số phiên bản cao nhất của tài nguyên được CICAM hỗ trợ.

CICAM không bao giờ được yêu cầu một số phiên bản mà nó không có khả năng hỗ trợ hoàn toàn và không được trả về số phiên bản được máy chủ thông báo, trừ khi nó được hỗ trợ hoàn toàn.

E.20. Cung cấp CA PMT

E.20.1. Giới thiệu

Việc máy chủ không gửi CA PMT khi thay đổi từng và mọi dịch vụ gây ra nhiều vấn đề đối với CICAM bao gồm:

...

...

...

2) Kiểm soát của cha mẹ không luôn luôn được thực thi khi truy nhập lại một dịch vụ được bảo vệ.

3) MMI ứng dụng không được khởi tạo lại.

E.20.2. Bản quy định kỹ thuật

EN 50221 [7], điều 8.4.3.3 quy định:

Máy chủ có thể quyết định việc gửi CA PMT cho tất cả các ứng dụng CA được kết nối hoặc chỉ đến các ứng dụng hỗ trợ giá trị CA_system_id giống như giá trị được cho trong CA_descriptor của dòng thành phần được lựa chọn (ES).

EN 50221 [7], điều 8.4.3.4 quy định:

Thiết bị thu gửi một CA PMT mới hoặc một danh sách mới của CA PMT đến ứng dụng này khi:

• người sử dụng chọn một chương trình khác

• lệnh 'dò kênh' lựa chọn một dịch vụ khác (xem 8.5.1.1)

...

...

...

• current_next_indicator thay đổi

E.20.3. Khuyến nghị đối với máy chủ

Máy chủ nên gửi một CA PMT mới khi thay đổi từng dịch vụ và khi thay đổi version_number hoặc current_next_indicator đến tất cả các ứng dụng CA được kết nối có hoạt động giải xáo trộn.

E.21. Đánh giá của CICAM về các CA_descriptor

E.21.1. Bản quy định kỹ thuật

EN50221: 1997 [7], điều 8.4.3.4 quy định:

(Các) CA_descriptor ở cấp elementary_stream là hợp lệ chỉ đối với elementary_stream. Nếu, đối với một elementary_stream, (các) CA_descriptor tồn tại ở cấp chương trình và cấp elementary_stream thì chỉ (các) CA_descriptor ở cấp elementary_stream được xem xét.

ITU-T J.96: 2001 [39], điều 6.2.3, các chế độ 2 và 3 quy định:

Một CA_descriptor có thể có mặt trong PMT ở cấp chương trình, cho một ECM_pid đối với tất cả các thành phần của một chương trình. Các CA_descriptor bổ sung có thể có mặt tại cấp độ thành phần. Trong trường hợp này, nó thay thế giá trị đã được quy định ở cấp chương trình, chỉ dành cho các thành phần liên quan.

...

...

...

Trong ca_pmt () APDU; các CA_descriptor sẵn có ở cấp thành phần (ES) đối với một thành phần nhất định có thể được CICAM giải xáo trộn thì bất kỳ các CA_descriptor ở cấp chương trình phải bị bỏ qua đối với thành phần này.

E.22. Hành vi đóng phiên hỗ trợ CA

E.22.1. Bản quy định kỹ thuật

EN-50221:1997 [7], điều 8.4.3 quy định:

Sau đó phiên này được giữ mở dành cho hoạt động định kỳ của giao thức liên kết với các đối tượng CA PMT và CA PMT Reply.

R206-001:1998 [24], điều 9.5.5.1 quy định:

Trong trường hợp lỗi lặp đi lặp lại, nó cũng có thể đóng phiên hỗ trợ CA và mở lại nó.

Nếu phiên dành cho tài nguyên hỗ trợ CA đóng, ứng dụng CA này nên cố gắng mở một phiên khác.

E.22.2. Yêu cầu đối với máy chủ

...

...

...

E.22.3. Yêu cầu đối với CICAM

Nếu phiên hiện tại của tài nguyên hỗ trợ CA bị đóng thì CICAM phải cố gắng mở lại nó.

E.23. Các lệnh ca_pmt

E.23.1. Bản quy định kỹ thuật

EN50221 [7] liệt kê một số giá trị ca_pmt_cmd_id. Tác động của loại ca_pmt từ máy chủ được CICAM phân tích

E.23.2. Yêu cầu đối với CICAM

CICAM phải hỗ trợ tất cả các giá trị ca_pmt_cmd_id được liệt kê trong EN 50221 [7], điều 8.4.3.4. Khi CICAM nhận được một ca_pmt với ca_pmt_cmd_id được thiết lập là truy vấn đối với một chương trình hoặc dòng thành phần, CICAM phải gửi ca_pmt_reply đến máy chủ và không được bắt đầu giải xáo trộn và không được hiển thị bất kỳ MMI.

E.24. open_session_response

E.24.1. Bản quy định kỹ thuật

...

...

...

E.24.2. Yêu cầu đối với CICAM

CICAM phải xử lý tất cả các giá trị trạng thái trong EN 50221 [7], bảng 7.

CICAM phải chắc chắn khi máy chủ trả về trạng thái "phiên không được mở, tài nguyên bận". Trong trường hợp này, CICAM nên thử mở phiên cho đến khi máy chủ có thể đáp ứng yêu cầu này.

E.25. Mã hóa ký tự

E.25.1. Bản quy định kỹ thuật

Tuân theo EN50221 [7], điều 8.6.2.3 và sửa đổi theo R206-001 [24], điều 9.8.5.

E.25.2. Yêu cầu đối với máy chủ

Máy chủ phải trả lời một display_control () APDU có các loại get_display_character_table_list (02) và get_input_character_table_list (03).

E.25.3. Khuyến nghị đối với máy chủ

...

...

...

Trong trường hợp mạng chỉ yêu cầu bộ ký tự mặc định (theo ISO/IEC 6937) thì máy chủ phải trả lời yêu cầu display_control () APDU bằng một display_reply () APDU và vòng character_table_byte phải có độ dài bằng không để chỉ ra rằng bộ ký tự mặc định được hỗ trợ. Ví dụ:

Quốc gia/Khu vực

character_table_byte

Các bảng ký tự

Pháp,Đức,...

{0x01}

ISO/IEC 6937 và ISO/IEC 8859-9

Vương quốc Anh

{}

...

...

...

Nordig

{0x01, 0x05, 0x10, 0x00, 0x01, 0x10, 0x00, 0x04, 0x10, 0x00, 0x0f}

ISO/IEC 6937, ISO/IEC 8859-9, ISO/IEC 8859-9, ISO/IEC 8859-1, ISO/IEC 8859-4, ISO/IEC 8859-15

Phụ lục F

(quy định)

Định nghĩa và xử lý mã lỗi

F.1. Các mã lỗi

Bảng F.1 - Các mã lỗi ARC

Mã lỗi

...

...

...

Lỗi phát hiện bởi

Hành động của máy chủ

Hành động của mô-đun Cl+

Diễn giải

00

Không

N/A

Không

Không

...

...

...

01

Mô đun phát hiện

CICAM

Không

CICAM chuyển sang chế độ pass-through (CHÚ THÍCH 1)

02

Máy chủ phát hiện

CICAM

...

...

...

- CICAM chuyển sang chế độ pass-through (CHÚ THÍCH 1)

- Một bản tin thông báo thu hồi được hiển thị.

03

SAC thất bại

CICAM/Host

- Nếu EMI>0 CICAM chuyển sang chế độ pass-through, nếu không chuyển qua chế độ DVB Cl.

- Một bản tin thông báo lỗi được hiển thị.

...

...

...

04

CCK thất bại

CICAM/Host

- Nếu EMI>0 CICAM chuyển sang chế độ pass-through, nếu không chuyển qua chế độ DVB Cl.

- Một bản tin thông báo lỗi được hiển thị.

Các nhà khai thác dịch vụ và CAS có thể chọn theo những điều kiện để giải mã khi vận hành ở chế độ DVB Cl.

05

Cập nhật Firmware CICAM thất bại;

...

...

...

CICAM

Không

Khuyến nghị:

- CICAM thử lại tải về lần 2.

- Một bản tin thông báo lỗi được hiển thị.

06

Cập nhật Firmware CICAM thất bại;

- Lỗi vị trí

...

...

...

Không

Khuyến nghị:

- CICAM thử lại tải về lần 2.

- Một bản tin thông báo lỗi được hiển thị.

07

Cập nhật Firmware CICAM thất bại;

• Lỗi ký hình ảnh

CICAM

...

...

...

Khuyến nghị:

- CICAM thử lại tải về lần 2.

- Một bản tin thông báo lỗi được hiển thị.

08

Xác thực thất bại

- Quá tải

CICAM

Không

...

...

...

09

Xác thực thất bại

- Xác minh chữ ký thất bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyển sang chế độ pass-through.

10

...

...

...

- Xác minh khóa xác thực thất bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyển sang chế độ pass-through.

11

Xác thực thất bại

- Tính toán khóa thất bại

CICAM/Host

...

...

...

- CICAM chuyển sang chế độ pass-through.

12

Xác thực thất bại

- DH thất bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyển sang chế độ pass-through.

...

...

...

Giấy chứng nhận CICAM không hợp lệ

- Sai cú pháp

Host

Máy chủ dừng CICAM

Không

14

Giấy chứng nhận CICAM không hợp lệ
- Hết hạn

Host

...

...

...

Không

15

Giấy chứng nhận CICAM không hợp lệ

- Xác thực chữ ký thất bại

Host

Máy chủ dừng CICAM

Không

...

...

...

Giấy chứng nhận máy chủ không hợp lệ

- Sai cú pháp

CICAM

Không

- CICAM chuyển sang chế độ Pass-through

- một bản tin phản hồi thông báo lỗi được hiển thị

17

Giấy chứng nhận máy chủ không hợp lệ

...

...

...

CICAM

Không

• CICAM chuyển sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển thị.

18

Giấy chứng nhận máy chủ không hợp lệ

- Xác thực chữ ký thất bại

CICAM

...

...

...

- CICAM chuyển sang chế độ Pass-through

- một bản tin phản hồi thông báo lỗi được hiển thị

19

Giấy chứng nhận nhà khai thác dịch vụ không hợp lệ

- Sai cú pháp

CICAM

Không

- CICAM chuyển sang chế độ DVB-CI (CHÚ THÍCH 3)

...

...

...

20

Giấy chứng nhận nhà khai thác dịch vụ không hợp lệ

- Hết hạn

CICAM

Không

- CICAM chuyển sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển thị.

...

...

...

Giấy chứng nhận nhà khai thác dịch vụ không hợp lệ

- Xác thực chữ ký thất bại

CICAM

Không

- CICAM chuyển sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển thị.

22

Trình cập nhật các yêu cầu của CICAM

...

...

...

Không

- CICAM chuyển sang chế độ Pass-through

- một bản tin phản hồi thông báo lỗi được hiển thị

23 - 127

Dự phòng cho Cl Plus

CICAM

Không

- một bản tin phản hồi thông báo lỗi được hiển thị

...

...

...

128 - 255

Dùng riêng cho nhà khai thác dịch vụ

CICAM

Không

- một bản tin phản hồi thông báo lỗi được hiển thị

CHÚ THÍCH:

1: CICAM chuyển tiếp dòng truyền tải không bị thay đổi và không giải xáo trộn bất kỳ dịch vụ (dịch vụ Cl Plus hoặc dịch vụ DVB-CI).

2: Máy chủ hoạt động như một máy chủ tuân thủ DVB-CI.

...

...

...

Phụ lục G

(quy định)

Tối ưu PCMCIA

Lớp vật lý dựa trên PC-Card dành cho DVB-CI được mô tả trong EN 50221 [7], phụ lục A. Trong Cl Plus, nhiều dữ liệu phải được truyền qua giao diện lệnh hơn so với DVB-CI. Phần sau đây xác định những thay đổi trong lớp vật lý DVB-CI để tăng thông lượng trên giao diện lệnh. Xin lưu ý rằng những thay đổi này không ảnh hưởng đến giao diện dòng truyền tải.

G.1. Kích thước bộ đệm

Kích thước bộ đệm để gửi và nhận dữ liệu trên giao diện lệnh được thương lượng trong quá trình khởi tạo giao diện lệnh, xem EN 50221 [7], phụ lục A.2.2.1.1.

Một thiết bị tuân thủ Cl Plus phải cung cấp một kích thước bộ đệm tối thiểu là 1024 byte nhưng nó có thể lên đến 65535 byte.

G.2. Chế độ ngắt

Cl Plus sử dụng ngắt điều khiển hoạt động trên giao diện lệnh được trình bày trong R206-001 [24], CICAM có thể chiếm IREQ # khi nó có dữ liệu để gửi hoặc khi nó đã sẵn sàng để nhận dữ liệu từ máy chủ, tức là khi nó thiết lập bit DA hoặc bit FR trong thanh ghi trạng thái.

...

...

...

Bảng G.1 - Thanh ghi lệnh

7

6

5

4

3

2

1

0

...

...

...

FRIE

R

R

RS

SR

SW

HC

Bảng G.2 - Các bit cho phép ngắt

DAIE

...

...

...

FRIE

Khi bit này được thiết lập thì mô đun sử dụng IREQ# mỗi lần nó không bắt buộc nhận dữ liệu

Các giá trị mặc định khi khởi tạo là 0 dành cho cả hai bit. Trước khi thiết lập DAIE hoặc FRIE là 1, máy chủ phải đảm bảo rằng CICAM tuân thủ Cl Plus.

Một CAM tuân thủ Cl Plus phải thông báo hỗ trợ ngắt trong cấu trúc thông tin thẻ (CIS). CIS chứa một CISTPL_CFTABLE_ENTRY dành cho mỗi giao diện mà PC-Card hỗ trợ. Một CAM Cl Plus sử dụng giao diện PC-card tùy chỉnh giống như một CAM DVB-CI và do đó CISTPL_CFTABLE_ENTRY giống nhau. Bảng G.3 giải thích những thay đổi trong CISTPL_CFTABLE_ENTRY để chỉ ra sự hỗ trợ ngắt. Xem tiêu chuẩn PC-Card, tập 4 [30], điều 3.3.2 dành cho một phân tích đầy đủ về CFTABLE_ENTRY và các thành phần của nó.

Bảng G.3 - Những thay đổi đối với CISTPL_CFTABLE_ENTRY

TPCE_FS (byte lựa chọn tính năng)

Thiết lập bit 4 (IRQ) sang 1 để chỉ thị rằng có đầu vào TPCE_IR

TPCE_IR

Chỉ một byte được sử dụng dành cho TPCE_IR được thiết lập bit 5 (Mức) sang 1, tất cả các bit khác được thiết lập là 0

...

...

...

Khi máy chủ nhận được một ngắt từ CICAM, nó kiểm tra các thiết lập dành cho DAIE và FRIE và các bit DA và FR của CICAM trong thanh ghi trạng thái để xác định nguyên nhân ngắt. Máy chủ phải chuẩn bị sẵn sàng để phát hiện cả hai FR và DA được thiết lập là 0. Điều này có thể xảy ra nếu CICAM được thông báo rằng nó được phép nhận dữ liệu nhưng nó đã bận và đã thu hồi bộ đệm trống trước khi ngắt này được phục vụ.

Nếu ngắt đã được kích hoạt vì CICAM có dữ liệu sẵn sàng, máy chủ thực hiện truyền từ mô-đun sang máy chủ như được mô tả trong EN 50221 [7], điều A.2.2.1.3. Nếu ngắt thông báo rằng CICAM sẵn sàng nhận dữ liệu thì máy chủ có thể thực hiện truyền từ máy chủ sang mô-đun theo EN 50221 [7], điều A.2.2.1.2.

Trong chế độ ngắt nếu CICAM yêu cầu một thiết lập lại (tức là thiết lập bit IIR trong thanh ghi trạng thái) thì nó có thể chiếm bit FR trong thanh ghi trạng thái để gây ra một ngắt và chiếm tín hiệu IREQ #.

Việc hỗ trợ xử lý ngắt là bắt buộc trong cả máy chủ và CICAM. Xem R206-001 [24], điều 4.3.3 để biết thêm thông tin về ngắt điều khiển hoạt động.

Mô-đun Cl Plus phải luôn luôn có khả năng hoạt động với hoạt động bỏ phiếu mặc dù hỗ trợ ngắt là bắt buộc. Mô-đun sẽ gây ra một ngắt và chờ máy chủ bắt đầu truyền dữ liệu; máy chủ có thể thăm dò thường xuyên mà không kiểm tra đối với một ngắt, việc truyền dữ liệu thực tế là không thay đổi.

G.3. Xác định khả năng tương thích Cl Plus

Một Cl Plus CICAM (và tùy chọn bất kỳ CICAM khác mà không nhất thiết phải là Cl Plus nhưng có thể hoạt động một cách chính xác trong một máy chủ Cl Plus) phải thông báo khả năng tương thích Cl Plus trong thông tin CIS. Một CICAM phải thông báo khả năng tương thích Cl Plus trong bộ dữ liệu CISTPL_VERS_1. Trong TPLLV_INFO, một CICAM tuân thủ Cl Plus phải bao gồm một chuỗi thông báo khả năng tương thích Cl Plus trong một dòng của hai dòng dành cho thông tin sản phẩm bổ sung (API).

Chuỗi khả năng tương thích này phải tuân theo định nghĩa BNF sau:

<compatibility> ::= "$compatible[" <compatibility_sequence> "]$"

...

...

...

<compatibility_item> := <label> "=" [<compatibility_flag>] <identity>

<compatibility_flag> ::= "-"l"+"l"*"

<label> ::= <word>

<identity> ::= <word>

<word> ::= <char> {<char>}

<char> ::= "a"-"z"|"A"-"Z"|"0"-"9"|"."|"_"

Trong đó các trường được quy định như sau:

<compatibility>: chuỗi khả năng tương thích được sử dụng để chỉ sự bắt đầu và kết thúc của thông tin khả năng tương thích. Chuỗi này được xác định bởi ký tự đồng đô la ($) xuất hiện ở cả hai đầu và cuối của chuỗi khả năng tương thích. Chuỗi này bắt đầu với từ mã không phân biệt chữ ký tự viết thường hay hoa compatible theo sau là một ký tự ngoặc vuông không có ký tự trống nghĩa là "$compatible[". <compatibility_sequence> phải tiếp theo ngay sau ngoặc vuông và được kết thúc bằng một ngoặc vuông đóng " ] ". Chuỗi có thể chỉ xuất hiện một lần trong một dòng của hai dòng dành cho thông tin sản phẩm bổ sung. Chuỗi này có thể đứng trước hoặc sau các ký tự văn bản khác.

<compatibility_sequence>: một chuỗi các <compatibility_item> cách nhau bằng ký tự trống, một ký tự trống phải phân cách từng <compatibility_item>.

...

...

...

<identity>: một chuỗi ký tự kiểm tra khả năng tương thích của nhãn đã cho.

<compatibility_flag>: một ký tự tùy chọn xác định khả năng tương thích của mục có nhãn liên kết được quy định tại Bảng G.4.

Bảng G.4 - Compatibility Flag

Ký ta

Mtag

- (Âm)

CICAM không tương thích với <nhận dạng>

+ (Dương)

CICAM chỉ tương thích với <nhận dạng> đã cho. Đây là thiết lập mặc định khi bị từ chối.

...

...

...

CICAM tương thích với tất cả các phiên bản từ thấp đến <nhận dạng>.

Trường hợp một nhãn xuất hiện trong chuỗi khả năng tương thích với nhiều thiết lập khả năng tương thích thì tập của chuỗi khả năng tương thích phải được đánh giá hoàn toàn đối với nhãn này trước khi được áp dụng. Trong ví dụ "label =*4 label=-2", "nhãn" chỉ hợp lệ đối với tập các giá trị {0,1,3,4} và ngoại trừ giá trị 2.

Tất cả các thành phần của chuỗi khả năng tương thích được định nghĩa là không phân biệt chữ ký tự viết thường hay hoa và việc máy chủ xử lý chuỗi khả năng tương thích CIS phải thực hiện phân tích không phân biệt chữ ký tự viết thường hay hoa. Ví dụ, các thông tin sản phẩm bổ sung sau đây được coi là có khả năng tương thích tương đương:

"Some text $compatible[acme=+this ciplus=1 acme=-that]$ more text"

"Some text $COMPATIBLE[Acme=+This CIPLUS=1 Acme=-that]$ more text"

"Some text $CoMpAtlbLe[AcMe=+Thls Clplus=1 aCmE=-tHaT]$ more text"

Trong mọi trường hợp, CICAM không được thông báo khả năng tương thích với Cl Plus tại một phiên bản đã cho trừ khi CICAM đã được kiểm tra hoàn toàn với máy chủ Cl Plus tại phiên bản được xác định đó. Việc chỉ ra trạng thái khả năng tương thích Cl Plus của nó trong thông tin CIS đối với Cl Plus CICAM là bắt buộc.

Máy chủ Cl Plus có thể tùy chọn xử lý thông tin khả năng tương thích CIS. Máy chủ Cl Plus xử lý thông tin khả năng tương thích và xác định rằng CICAM không tương thích Cl Plus thì máy chủ có thể tùy chọn bỏ qua việc thông báo các tài nguyên Cl Plus hoặc dừng sử dụng các Cl Plus APDU cụ thể. Loại bỏ các Cl Plus APDU cụ thể giảm thiểu các vấn đề tương thích với các CICAM không tương thích Cl Plus. Việc thông báo các tài nguyên Cl Plus cụ thể của nó cho một CICAM tương thích cho dù mô-đun này có thực sự là một CI Plus CICAM đối với máy chủ Cl Plus là bắt buộc.

G.3.1. Xác định Cl Plus

...

...

...

Đối với một CICAM tuân thủ tiêu chuẩn này thì <label> và <compatibilty_item> được định nghĩa là "ciplus=1". Chuỗi khả năng tương thích điển hình dành cho một Cl Plus CICAM (hoặc một CICAM đã được kiểm tra với một máy chủ Cl Plus) phải là

$compatible[ciplus=1]$

Thông tin khả năng tương thích có thể xuất hiện với thông tin khác được nhúng trong chuỗi, một ví dụ của một chuỗi phức tạp có thể là:

"Some text $compatible[acme=+this ciplus=1 acme=-that]$ more text"

Trong đó CICAM tương thích với "acme=this", nhưng không tương thích với "acme=that" và cũng tương thích với bản quy định kỹ thuật phiên bản 1.2 ("ciplus=1").

Phiên bản sau của tiêu chuẩn này có thể yêu cầu số nhận dạng Cl Plus được tăng lên và một CICAM tương thích với các phiên bản 1 và 2 của nhãn nhận dạng sẽ thông báo khả năng tương thích như sau:

$compatible[ciplus=*2]$

Trong đó CICAM tương thích với tiêu chuẩn này với identity=1 và identity=2 (phiên bản sau này của tiêu chuẩn này). Tất cả các máy chủ phân tích thông tin CIS này phải xử lý thẻ khả năng tương thích.

G.3.2. Xác định tính năng Cl Plus bổ sung

...

...

...

Chuỗi khả năng tương thích phải tuân thủ theo định nghĩa BNF được quy định tại G.3.

Đối với một CICAM tương thích với các tính năng Cl Plus bổ sung thì <label> và <compatibilty_item> được định nghĩa là "ciprof=int". Chuỗi khả năng tương thích và các tính năng điển hình đối với một CICAM hỗ trợ các tính năng Cl Plus bổ sung phải là

$compatible[ciplus=1 ciprof=int]$

Trong đó "int" được định nghĩa là một số nguyên không dấu 32-bit có thể được thể hiện như một số nguyên thập phân không dấu sử dụng các chữ số 0..9 hoặc là một số nguyên hệ thập lục phân được bắt đầu bằng 0x và bao gồm các chữ số và 0..9 và các ký tự a..f. Các ký hiệu thập lục phân phải là không phân biệt chữ ký tự viết thường hay hoa tức là 0x4ac hoặc 0X4AC hoặc 0x4Ac đều hợp lệ.

Nhãn nhận “ciprof” được phân tích là một mặt nạ bit như sau:

Bảng G.5 - Mặt nạ bit của các tính năng

Các tính năng (các tài nguyên)

Mặt nạ bít

Ghi chú

...

...

...

0x00000001

Xem điều 14.7.4.1.4

Dự phòng

0x00000002 - 0x80000000

Ví dụ về khả năng tương thích và các tính năng có thể là:

$compatible[ciplus=1 ciprof=1]$

$compatible[ciplus=1 ciprof=0x4401]$

$compatible[ciplus=*22 ciprof=116893]$

...

...

...

Trong mọi trường hợp, CICAM không được thông báo tính năng Cl Plus trừ khi CICAM đã hoàn toàn được kiểm tra với một máy chủ Cl Plus. Việc chỉ ra khả năng tương thích Cl Plus và các tính năng trong thông tin CIS đối với Cl Plus CICAM là bắt buộc.

Máy chủ Cl Plus có thể tùy chọn xử lý thông tin các tính năng Cl Plus bổ sung trong CIS.

Khi chuỗi “ciprof” được loại bỏ trong thông tin CIS thì máy chủ phải xác định rằng không có các tính năng nào được biết được hỗ trợ, trừ trường hợp được máy chủ xác định khi kết nối hoàn toàn với CICAM đã được bắt đầu.

Nhãn “ciprof nên được đặt sau nhãn “ciplus” trong chuỗi này.

G.3.2.1. Tài nguyên hồ sơ nhà điều hành (Bit 0 - 0x00000001)

Bit tài nguyên hồ sơ nhà điều hành khi được thiết lập là "1" chỉ ra rằng CICAM hỗ trợ một hồ sơ nhà điều hành đang hoạt động. Bit này được thiết lập là "0" khi không có hồ sơ nhà điều hành trên CICAM hoặc hồ sơ nhà khai thác này chưa được thông báo trước đó.

Thiết bị máy chủ có thể tùy chọn phân tích bit này để xác định xem một hồ sơ nhà điều hành là hiện tại và có thể chờ đợi CICAM tạo ra APDU của hồ sơ nhà điều hành này trước khi tiếp tục với bất kỳ quá trình cài đặt nào. Khi bit này là không thì CICAM vẫn có thể có một hồ sơ nhà điều hành hiện tại tuy nhiên việc cài đặt hồ sơ này trong bất kỳ thủ tục cài đặt ban đầu đối với máy chủ có thể là không thể vì nó đã không được thông báo đủ sớm. Trong một sự kiện như vậy thì hồ sơ nhà điều hành phải được máy chủ cài đặt trong một thủ tục cài đặt riêng sau khi cài đặt ban đầu.

Phụ lục H

(quy định)

...

...

...

H.1. Các thông số được trao đổi trong các APDU

Bảng H.1 - Các thông số đầu vào trong các tính toán (được trao đổi trong các APDU)

Khóa hoặc biến

Kích thước (bit)

Diễn giải

datatype id

Didatype

-

-

...

...

...

Didatype

-

-

2

Didatype

-

-

3

Didatype

...

...

...

-

4

HOST_ID

64

được ROT tạo ra và được chứa trong giấy chứng nhận X.509.

5

CICAM_ID

64

được ROT tạo ra và được chứa trong giấy chứng nhận X.509.

...

...

...

Host_BrandCert

CHÚ THÍCH 1

Giấy chứng nhận thương hiệu máy chủ

7

CICAM_BrandCert

CHÚ THÍCH 1

Giấy chứng nhận thương hiệu CICAM

8

Dự phòng

...

...

...

-

9

Dự phòng

-

-

10

Dự phòng

-

-

...

...

...

Kp

256

Tiền thân của mã khóa CCK CICAM đến máy chủ

12

DHPH

2048

Mã khóa công khai DH máy chủ

13

DHPM

...

...

...

Mã khóa công khai DH mô đun/ CICAM

14

Host_DevCert

CHÚ THÍCH 1

Dữ liệu giấy chứng nhận thiết bị máy chủ

15

CICAM_DevCert

CHÚ THÍCH 1

Dữ liệu giấy chứng nhận thiết bị CICAM

...

...

...

Signature_A

2048

Đóng dấu của mã khóa công khai DH máy chủ

17

Signature_B

2048

Đóng dấu của mã khóa công khai DH CICAM

18

auth_nonce

...

...

...

Nonce 256 bit ngẫu nhiên được CICAM tạo ra và được CICAM truyền đến máy chủ để sử dụng trong giao thức xác thực.

19

Ns_Host

64

Yêu cầu SAC của máy chủ đến CICAM

20

Ns_module

64

Yêu cầu SAC của CICAM đến máy chủ

...

...

...

AKH

256

Mã khóa xác thực máy chủ

22

AKM

256

Mô đun mã khóa xác thực/CICAM

23

D3ICAM m

...

...

...

-

24

uri_message

64

Bản tin dữ liệu mang URI

25

program_number

16

Số chương trình MPEG

...

...

...

uri_confirm

256

Mã Hash trên dữ liệu được máy chủ xác nhận.

27

key register

8

(uimsbf) 0 = chẵn, 1 = lẻ, các giá trị khác không được hỗ trợ.

28

uri_versions

...

...

...

Mặt nạ bit thể hiện các phiên bản URI có thể được máy chủ hỗ trợ. Định dạng là ‘uimsbf’

29

status_field

8

Trường trạng thái trong các bản tin xác nhận APDU.

30

srm_data

CHÚ THÍCH 2

SRM dành cho HDCP

...

...

...

srm_confirm

256

Mã Hash trên dữ liệu được máy chủ xác nhận.

32

cicam_license

variable

Giấy phép liên kết với nội dung từ CICAM (CHÚ THÍCH 3)

33

license status

...

...

...

Trạng thái hiện tại của giấy phép nội dung

34

license_rcvd_status

8

Trạng thái trao đổi giấy phép nội dung

35

Host_license

variable

Giấy phép mà máy chủ yêu cầu trạng thái hiện tại. (CHÚ THÍCH 3)

...

...

...

play_count

8

Số lượt xem còn lại

37

operating_mode

8

Chế độ hoạt động ghi lại

38

PINcode data

...

...

...

Mã CICAM PIN 1 byte dành cho từng mã PIN

39

record_start_status

8

Trạng thái CICAM sau giao thức khởi tạo ghi lại

40

mode_change_status

8

Trạng thái CICAM sau giao thức chế độ hoạt động thay đổi

...

...

...

record_stop_status

8

Trạng thái CICAM sau giao thức dừng ghi lại

42

CHÚ THÍCH:

1. Độ dài giấy chứng nhận là có thể thay đổi.

2. Các SRM dành cho HDCP được xác định trong bản quy định kỹ thuật HDCP, [34]. Các SRM thế hệ đầu tiên không được vượt quá 5 kbyte.

3. Các giấy phép không được có độ dài bằng không và phải được ghép với byte tiếp theo. Giấy phép phải không lớn hơn 1024 byte.

4. Đối với đặc tả Cl Plus v1.4 và trên nữa thì datatype_id 43-49 bao gồm những bản tin SRM. Một máy chủ tuân thủ v1.4 sẽ xử lý một cách chính xác tất cả các datatype_ids như thế được chỉ định là độ dài bản tin nhắn SRM. Bản tin SRM có độ dài khả biến

...

...

...

Phụ lục I

(quy định)

Sử dụng PKCS # 1

I.1. Các đóng dấu RSA theo PKCS # 1

Các đóng dấu RSA được xây dựng bằng cách sử dụng các hướng dẫn thực hiện theo RSA PKCS # 1 [1].

Cơ sở này là RSA + SHA1. Có hai lựa chọn được quy định tại RSA PKCS #1 [1] vì có RSASSA-PSS và RSASSA-PKCS1-V1_5. RSASSA-PSS phải được sử dụng để đóng dấu và xác nhận các bản tin. Các đóng dấu phải dài 2048 bit.

Phụ lục J

(quy định)

...

...

...

J.1. Định dạng độ dài thẻ

Định dạng độ dài thẻ (TLF) được định nghĩa để xác định các mục trong các đóng dấu của giao thức xác thực (xem điều 6). Một mục trong đóng dấu được xác định bởi cú pháp sau:

<tag> <length> <signature_item>

<tag> - một trường 8 bit có một giá trị duy nhất (uimsbf) dành cho mục dữ liệu được quy định tại Bảng J.1. Thẻ được mã hoá là giá trị nhị phân. Các giá trị thẻ sau được xác định và phải được sử dụng.

Bảng J.1 - Định nghĩa thẻ và độ dài

Giá trị thẻ (8 bit)

Tên thẻ

Diễn giải

Độ dài (16 bit)

...

...

...

version

Phiên bản của giao thức ( giá trị 0x01 dành cho tiêu chuẩn này)

8

0x01

msg_label

Nhãn bản tin

8

0x02

auth_nonce

...

...

...

256

0x03

DHPM

Mã khóa công khai DH của CICAM

2048

0x04

DHPH

Mã khóa công khai DH của máy chủ

2048

...

...

...

Dự phòng

Dự phòng

Không áp dụng

<length> - một trường 16 bit (uimsbf) để diễn tả độ dài của một mục dữ liệu thực trong đóng dấu theo bit. Độ dài được mã hóa là giá trị nhị phân với min=0 và max= 2^16 -1.

<signature_item> - trường này mang mục dữ liệu thực trong đóng dấu. Ví dụ; đóng dấu sau: <version 1> + <msg_label 02> + <auth_nonce> + <DHPH> sẽ mã hóa nội dung được phân tích trong bảng J.2:

Bảng J.2: Ví dụ

Mục

Mã hóa

<version>

...

...

...

0000 0000 0000 1000

0000 0001

<msg_label 02>

0000 0001

0000 0000 0000 1000

0000 0010

<auth_nonce>

0000 0010

0000 0001 0000 0000

...

...

...

<DHPH>

0000 0100

0000 1000 0000 0000

(tiếp theo là 2048 bít dữ liệu ngẫu nhiên)

Phụ lục K

(quy định)

Bản quy định kỹ thuật điện

K.1. Bản quy định kỹ thuật điện

...

...

...

K.1.1. Giới thiệu

Máy chủ tuân thủ DVB phải chấp nhận bất kỳ hình dạng mô-đun PCMCIA mà không làm hỏng máy chủ hoặc PCMCIA mô-đun và xác định rằng nó không phải là một CICAM. Tương tự CICAM có thể được cắm vào một ổ cắm PCMCIA trên bất kỳ hệ thống nào khác mà không làm hỏng máy chủ hoặc CICAM và khả năng sử dụng của CICAM trong hệ thống đó sẽ được xác định.

K.1.2. Giao diện kết nối

Lớp vật lý giao diện chung sử dụng các thông số hình dạng vật lý thẻ PC loại I và II được định nghĩa trong Bản quy định kỹ thuật vật lý PCMCIA 8.0 tập 3 [29], Giao diện này quy định một kết nối với 68 chân. Ngay sau khi bật nguồn điện, thiết lập lại các chân của CICAM như được thể hiện trong Bảng L.1, đây là một bản tóm tắt của định nghĩa tín hiệu thẻ PC 16 bit được định nghĩa trong bản quy định kỹ thuật điện PCMCIA [28]. Khi CICAM được cấu hình theo DVB-CI trong quá trình khởi tạo, các chân được bố trí như được thể hiện trong Bảng L.2

Bảng K.1 - Bố trí các chân của giao diện chung trước khi thay đổi

Bố trí các chân của giao diện chung trước khi thay đổi

Chân

Tín hiệu

I/O

...

...

...

Chân

Tín hiệu

I/O

Diễn giải

1

GND

Ground

...

...

...

GND

2

D3

I/O

Data Bit 3

36

CD1#

...

...

...

Card Detect 1

3

D4

I/O

Data Bit 4

37

D11

I/O

High Z

...

...

...

D5

I/O

Data Bit 5

38

D12

I/O

High Z

5

D6

...

...

...

Data Bit 6

39

D13

I/O

High Z

6

D7

I/O

Data Bit 7

...

...

...

D14

I/O

High Z

7

CE1#

I

Card Enable 1

41

D15

...

...

...

High Z

e

A10

I

Address Bit 10

42

CE2#

1

Card Enable 2

...

...

...

OE#

I

Output Enable

43

VS1#

O

Voltage Sense 1

10

A11

...

...

...

Address Bit 11

44

RFU

11

A9

I

Address Bit 9

...

...

...

RFU

12

A8

I

Address Bit 8

46

A17

...

...

...

High Z

13

A13

I

Address Bit 13

47

A18

I

High Z

...

...

...

A14

I

Address Bit 14

48

A19

I

High Z

15

WE#

...

...

...

Write Enable

49

A20

I

High Z

16

Ready

O

Ready

...

...

...

A21

I

High Z

17

VCC

Supply

51

VCC

...

...

...

Supply

18

VPP1

Program Voltage 1

52

VPP2

Program Voltage2

...

...

...

A16

I

High Z

53

A22

I

High Z

20

A15

...

...

...

High Z

54

A23

I

High Z

21

A12

I

Address Bit 12

...

...

...

A24

I

High Z

22

A7

I

Address Bit 7

56

A25

...

...

...

High Z

23

A6

I

Address Bit 6

57

VS2#

O

Voltage Sense 2

...

...

...

A5

I

Address Bit 5

58

RESET

I

Card Reset

25

A4

...

...

...

Address Bit 4

59

WAIT#

I

Extend Bus Cycle

26

A3

I

Address Bit 3

...

...

...

RFU

27

A2

I

Address Bit 2

61

REG#

...

...

...

Register Select

28

A1

I

Address Bit 1

62

BVD2

O

...

...

...

A0

I

Address Bit 0

63

BVD1

O

30

D0

...

...

...

Data Bit 0

64

D8

I/O

High Z

31

D1

I/O

Data Bit 1

...

...

...

D9

I/O

High Z

32

D2

I/O

Data Bit 2

66

D10

...

...

...

High Z

33

WP

O

Write Protect

67

CD2#

Card Detect 2

...

...

...

GND

68

GND

CHÚ THÍCH:

1. “I” chỉ thị các tín hiệu vào CICAM.

...

...

...

3. Sử dụng byte thấp nhất của bus dữ liệu. Việc đọc và ghi 16 bit không được hỗ trợ.

4. Các tín hiệu hiệu dữ liệu D8 - D15 không sẵn sàng cho dữ liệu.

5. Các tín hiệu địa chỉ A15 - A25 không sẵn sàng cho địa chỉ.

6. Các tín hiệu BVD1 BVD2 phải ở trạng thái “Cao” trong quá trình khởi tạo.

7. CE2# phải bị CICAM bỏ qua khi ở trạng thái “Cao”.

8. Các tín hiệu màu ghi là các tín hiệu không được sử dụng trên CICAM.

9. Các mục sau đây áp dụng cho tất cả các tín hiệu có trở kháng cao. Các tín hiệu vào “I” không được máy chủ chuyển sang hoạt động và phải được giữ ở trạng thái trở kháng cao trừ khi các tín hiệu này được máy chủ thay đổi theo các bảng K5, K6 và K7

10. Các mục sau đây áp dụng cho tất cả các tín hiệu có trở kháng cao. Các tín hiệu ra "O" không được CICAM chuyển sang hoạt động và phải được giữ ở trạng thái trở kháng cao trừ khi các tín hiệu này được máy chủ thay đổi theo các bảng K5, K6 và K7

11. Tất cả các tín hiệu không hoạt động (màu ghi) nên được bỏ qua ở đầu vào.

...

...

...

Bố trí các chân sau khi thay đổi

Chân

Tín hiệu

I/O

Diễn giải

Chân

Tín hiệu

I/O

...

...

...

1

GND

Ground

35

GND

2

...

...

...

I/O

Data Bit 3

36

CD1#

Card Detect 1

3

D4

I/O

...

...

...

37

MDO3

O

MP data out 3

4

D5

I/O

Data Bit 5

38

...

...

...

O

MP data out 4

5

D6

I/O

Data Bit 6

39

MDO5

O

...

...

...

6

D7

I/O

Data Bit 7

40

MDO6

O

MP data out 6

7

...

...

...

I

Card Enable 1

41

MDO7

O

MP data out 7

8

A10

I

...

...

...

42

CE2#

I

Card Enable 2

9

OE#

I

Output Enable

43

...

...

...

O

Voltage Sense 1

10

A11

I

Address Bit 11

44

IORD#

I

...

...

...

11

A9

I

Address Bit 9

45

IOWR#

I

I/O write

12

...

...

...

I

Address Bit 8

46

MISTRT

I

MP in start

13

A13

I

...

...

...

47

MDI0

I

MP data in 0

14

A14

I

Address Bit 14

48

...

...

...

I

MP data in 1

15

WE#

I

Write Enable

49

MDI2

I

...

...

...

16

IREQ#

O

Interrupt Request

50

MDI3

I

MP data in 3

17

...

...

...

Supply

51

VCC

Supply

18

VPP1

...

...

...

52

VPP2

Program Voltage2

19

MIVAL

I

MP invalid

53

...

...

...

I

MP data in 4

20

MCLKI

I

MP clock input

54

MDI5

I

...

...

...

21

A12

I

Address Bit 12

55

MDI6

I

MP data in 6

22

...

...

...

I

Address Bit 7

56

MDI7

I

MP data in 7

23

A6

I

...

...

...

57

MCLKO

O

MP clock output

24

A5

I

Address Bit 5

58

...

...

...

I

Card Reset

25

A4

I

Address Bit 4

59

WAIT#

O

...

...

...

26

A3

I

Address Bit 3

60

INPACK#

O

In Port Ack.

27

...

...

...

I

Address Bit 2

61

REG#

I

Register Select

28

A1

I

...

...

...

62

MOVAL

O

MP out valid

29

A0

I

Address Bit 0

63

...

...

...

O

MP out start

30

D0

I/O

Data Bit 0

64

MDO0

O

...

...

...

31

D1

I/O

Data Bit 1

65

MDO1

O

MP data out 1

32

...

...

...

I/O

Data Bit 2

66

MDO2

O

MP data out 2

33

IOIS16#

...

...

...

67

CD2#

Card Detect 2

34

GND

68

...

...

...

CHÚ THÍCH:

1. IOIS16# không được sử dụng.

2. CE2# bị CICAM bỏ qua và được máy chủ đưa lên Vcc”.

3. INPACK# là tùy chọn đối với các máy chủ có các khe cắm Cl đơn, là bắt buộc đối với các CICAM

K.1.3. Các chân cấu hình

K.1.3.1. Các chân phát hiện thẻ

• Các chân phát hiện thẻ (CD1 # và CD2 #) được máy chủ sử dụng để phát hiện sự hiện diện của một CICAM.

...

...

...

• Máy chủ phải cung cấp một điện trở 10 kΩ hoặc lớn hơn để đưa lên "Vcc" tại mỗi chân phát hiện thẻ. Vcc này không giống Vcc được sử dụng để cung cấp cho CICAM

• CICAM phải ghim cả hai chân phát hiện thẻ tại "GND".

Hình K.1 - Cơ chế phát hiện thẻ

• Máy chủ chỉ phải thông báo việc cắm hợp lệ khi cả hai chân phát hiện thẻ được chiếm.

• Các chân phát hiện thẻ không được kết nối với nhau giữa các CICAM.

• Nếu máy chủ chỉ nhận biết được có một chân phát hiện thẻ được chiếm thì nó có thể thông báo cho người sử dụng một trong các điều kiện sau

○ CICAM chưa được cắm đúng hoặc hoàn toàn

○ Thẻ được cắm là một loại không được giao diện chung hỗ trợ.

...

...

...

• Sau bản quy định kỹ thuật PCMCIA phiên bản 8, các chân nhận biết điện áp được sử dụng để cấu hình các mức điện áp cung cấp.

• máy chủ Cl Plus phải hỗ trợ 5V và tùy chọn 3.3V.

• Cl Plus CICAM chì phải hỗ trợ cung cấp 5V.

• Chân nhận biết điện áp VS1 # có thể được kết nối với GND hoặc để hở trên CICAM do nhu cầu trước đó.

• Chân VS1 # không được kết nối với nhau giữa các CICAM.

• Ổ cắm chính dành cho máy chủ là loại 5V.

K.1.3.3. Chức năng của VPP1 Và VPP2

• Các CAM được phép sử dụng các chân VPP1 và VPP2 làm chân nguồn điện.

• CICAM không được phép nối chân VPP1 với chân VPP2.

...

...

...

• Khi chân VPP1 và VPP2 được sử dụng làm chân nguồn điện thì chúng phải tuân theo các điều kiện tắt/ bật nguồn điện và trình tự phù hợp với chân VCC.

• CICAM không phải lấy được hơn 30% điện năng tiêu thụ thông qua các chân VPP và không quá 15 % cho mỗi chân VPP.

• Các chân VPP không được nối với nhau giữa các CAM.

K.1.4. Bản quy định kỹ thuật cung cấp nguồn điện K.1.4.1. Bản quy định kỹ thuật cung cấp 5V DC

Bảng K.3 - Các đặc tính cung cấp 5V cho thẻ.

Các đặc tính DC của thẻ giao diện chung

Tên

Nhỏ nhất

Lớn nhất

...

...

...

Đánh dấu

Vcc

4.75

5.25

V

Xem 1.

Vpp

4.75

5.25

...

...

...

Xem 1.

lcc + Ipp

-

300

mA

Xem 2.

Ipp

50

...

...

...

Hợp lệ cho chân VPP

Icc + Ipp_{power up}

100

mA

Xem 4.

ICC + Ipp_peak

500

...

...

...

Xem 3.

P_Total

1.5

W

Xem 2.

CHÚ THÍCH:

1. “Vcc" chỉ thị điện áp của các chân VCC và "Vpp" chỉ thị điện áp của các chân VPP1 and VPP2. Khi được chỉ thị là 5V thì nó yêu cầu thẻ hoạt động đúng trong dải điện áp cung cấp được quy định.

2. Tổng mức tiêu thụ điện dài hạn của một thẻ giao diện chung không được vượt quá Ptotal.

...

...

...

4. Mức tiêu thụ dòng điện lớn nhất ngay sau khi bật nguồn điện, thiết lập lại và trong thời gian truy nhập cấu hình.

Bảng K.4 - Các đặc tính cung cấp 5V cho máy chủ.

Các đặc tính nguồn một chiều (DC) cho máy chủ

Tên chân

Nhỏ nhất

Lớn nhất

Đơn vị

Đánh dấu

Vcc

...

...

...

5.25

V

Xem 1.

Vpp

4.75

5.25

V

Xem 1.

lcc

...

...

...

mA

Xem 2.

Ipp

55

mA

Icc + Ipp_peak

...

...

...

mA

Xem 3.

CHÚ THÍCH:

1. "Vcc" hoặc "Vpp" được chỉ thị là 5V đáp ứng tiêu chuẩn này trong tất cả các điều kiện tải tĩnh không đáp ứng các giới hạn tải có CHÚ THÍCH là máy chủ không ở trạng thái tắt/bật nguồn điện.

2. Máy chủ nên cung cấp tải đỉnh nhỏ nhất trong khoảng thời gian ít nhất là 1 ms.

3. Các yêu cầu đối với tải hiện tại được dựa trên một thẻ đơn. Các máy chủ hỗ trợ nhiều thẻ phải cung cấp các yêu cầu đối với tải hiện tại nhân với số lượng khe cắm thẻ.

K.1.4.2. Sơ đồ thời gian bật nguồn điện cung cấp cho máy chủ

...

...

...

Hình K.3 - Sơ đồ thời gian tắt nguồn điện cung cấp cho máy chủ

K.1.5. Bản quy định kỹ thuật mức tín hiệu

K.1.5.1. Các yêu cầu tải điện dung và điện trở

Bảng K.5 - Các yêu cầu tải đối với tín hiệu điều khiển.

Các yêu cầu tải đối với các tín hiệu điều khiển

Tên tín hiệu

Thẻ

Máy chủ

...

...

...

CE1#

CE2#

REG#

IORD#

Đưa lên "Vcc" ≥ 10KΩ phải giữ các tín hiệu không hoạt động khi các chân này không được kết nối tại máđược.

IOWR#

Tải điện dung ≤ 50pF

...

...

...

OE#

WE#

Đưa lên VCC ≥ 10KΩ

Tải điện dung ≤ 50pF

...

...

...

Đưa lên VCC ≥ 100KΩ

Tải điện dung ≤ 50pF

Bảng K.6 - Các yêu cầu tải đối với tín hiệu trạng thái.

Các yêu cầu tải đối các tín hiệu trạng thái

Tên tín hiệu

...

...

...

Máy chủ

Diễn giải

READY

INPACK#WAIT#

WP = IOIS16#

Đưa lên VCC ≥ 10KΩ

...

...

...

Bảng K.7 - Các yêu cầu tải đối với tín hiệu địa chỉ và dữ liệu.

Các yêu cầu tải đối với các tín hiệu địa chỉ và dữ liệu

Tên tín hiệu

Thẻ

Máy chủ

Diễn giải

A[14:0]

Đưa xuống GND ≥ 100KΩ

...

...

...

Tải điện dung ≤ 100pF

D[7:0]

Đưa xuống GND ≥ 100KΩ

...

...

...

Bảng K.8 - Các yêu cầu tải đối với tín hiệu đầu vào MPEG.

Các yêu cầu tải đối các tín hiệu đầu vào MPEG

Tên tín hiệu

Thẻ

Máy chủ

Diễn giải

MDI[7:0]

...

...

...

MICLK

MIVAL

Đưa xuống GND ≥ 100KΩ

Khả năng tải giữa 5 và 25pF

Bảng K.9 - Các yêu cầu tải đối với tín hiệu đầu ra MPEG.

...

...

...

Tên tín hiệu

Thẻ

Máy chủ

Diễn giải

MDO[7:0]

Đưa xuống GND ≥ 100KΩ

MOCLK

...

...

...

Tải điện dung ≤ 50pF

Ghi chú: Điện dung đối với tải có thể áp dụng đối với từng thẻ đơn.

K.1.5.2. Bản quy định kỹ thuật DC đối với các tín hiệu có nguồn cung cấp 5V

Bảng K.10 - Bản quy định kỹ thuật DC đối với các tín hiệu có nguồn cung cấp 5V

Tên

Thông số

Nhỏ nhất

...

...

...

Đơn vị

VIH = “High”

Điện thế cao đầu vào

2.4

"Vcc" + 0.25

V

VOH = “High"

Điện thế cao đầu ra

2.8

...

...

...

V

VIL = “Low”

Điện thế cao đầu vào

0.0

0.8

V

VOL = “Low”

Điện thế cao đầu ra

0.0

...

...

...

V

Tín hiệu điều khiển IIH

Dòng điện đầu vào cao dành cho các điều kiện tải lớn nhất được quy định đối với mỗi thẻ xem điều K.1.5.1.

150

μA

Tín hiệu điều khiển IOH

Dòng điện đầu ra cao dành cho các điều kiện tải lớn nhất được quy định

300

...

...

...

μA

Tín hiệu điều khiển IOL

DILh cho các điều kiện tải lớn nhất được quy định lớn nhất được quy định đối với mỗi thẻ xem điều K.1.5.1.

700

μA

Tín hiệu điều khiển IOH

Dòng điện đầu ra cao dành cho các điều kiện tải lớn nhất được quy định

1400

...

...

...

μA

Tín hiệu trạng thái IIH

Dòng điện đầu vào cao dành cho các điều kiện tải lớn nhất của máy chủ được quy định, xem điều K.1.5.1.

100

μA

Tín hiệu trạng thái IOH

Dòng điện đầu ra cao dành cho các điều kiện tải lớn nhất được quy định

100

...

...

...

μA

Tín hiệu trạng thái IIL

Dòng điện đầu vào cao dành cho các điều kiện tải lớn nhất của máy chủ được quy định, xem điều K.1.5.1.

400

μA

Tín hiệu trạng thái IOH

Dòng điện đầu vào cao dành cho các điều kiện tải lớn nhất của thẻ được quy định.

400

...

...

...

μA

Tín hiệu địa chỉ và dữ liệu IIH

Dòng điện đầu vào cao dành cho các điều kiện tải lớn nhất của từng thẻ và máy chủ được quy định, xem K.1.5.1.

150

μA

Tín hiệu địa chỉ và dữ liệu IOH

Dòng điện đầu ra cao dành cho các điều kiện tải lớn nhất của máy chủ được quy định

300

...

...

...

μA

Tín hiệu địa chỉ và dữ liệu IIL

Dòng điện đầu vào thấp dành cho các điều kiện tải lớn nhất của thẻ được quy định, xem K.1.5.1

450

μA

Tín hiệu địa chỉ và dữ liệu IOH

Dòng điện đầu ra cao dành cho các điều kiện tải lớn nhất của máy chủ được quy định

1600

...

...

...

μA

CHÚ THÍCH:

1. Tất cả các giá trị phù hợp với từng tín hiện riêng.

2. Mức VIL nhỏ nhất nên là 0 V, mức giới hạn VIL nhỏ nhất cho phép là -0,5 V.

K.1.6. Mô tả các tín hiệu của giao diện chung

K.1.6.1. Các tín hiệu liên quan CPU của giao diện chung

Tiêu chuẩn này tham khảo bản quy định kỹ thuật thẻ PC. Giao diện chung có một số thay đổi khác thẻ PC được mô tả trong phần này.

Ngay sau khi thiết lập lại và trước khi cấu hình và thay đổi chân đưa ra được thể hiện trong Bảng K.1. Trong chế độ này CICAM phải hoạt động như chỉ là thiết bị nhớ. Chế độ này không hỗ trợ I/O.

Sau khi thay đổi chân đưa ra được thể hiện trong Bảng K.2. Trong chế độ này CICAM hỗ trợ I/O và bộ nhớ thuộc tính.

...

...

...

Bộ nhớ chung là tên chung dành cho các loại bộ nhớ khác nhau như SRAM, MaskROM, OTPROM, (E) EPROM và bộ nhớ cực nhanh. Việc hỗ trợ bộ nhớ chung đối với máy chủ là tùy chọn. CICAM không được sử dụng bộ nhớ chung.

Việc hỗ trợ I/O đối với máy chủ và CICAM là bắt buộc sau khi thay đổi chân. CICAM phải hỗ trợ thanh ghi tùy chọn cấu hình. Việc hỗ trợ các thanh ghi khác thanh ghi tùy chọn cấu hình đối với máy chủ là không bắt buộc.

Các đường địa chỉ A [14: 0],

• Trước khi thay đổi chân các mục sau đây được áp dụng.

• Máy chủ phải cung cấp đầy đủ 32 kbyte A [14: 0] không gian địa chỉ cho CICAM.

• CICAM phải giải mã ít nhất 12 bit địa chỉ A [11: 0].

• Do hoạt động chế độ byte của CICAM truy nhập đến các địa chỉ lẻ không được hỗ trợ và máy chủ không được truy nhập vào địa chỉ lẻ.

• Sau khi thay đổi chân các mục sau đây được áp dụng.

• Máy chủ phải cung cấp ít nhất 4 vị trí địa chỉ trong chế độ I/O A [1: 0] bắt đầu từ 00h.

...

...

...

• Để truy nhập bộ nhớ thuộc tính máy chủ và CICAM phải hỗ trợ dải địa chỉ giống như trước khi thay đổi chân.

• Nhiều CAM có thể dùng chung các đường địa chỉ.

Các đường dữ liệu D [7: 0]

• Các đường dữ liệu D [7: 0] tạo thành bus dữ liệu hai chiều.

• Các đường dữ liệu phải chuyển sang "trở kháng cao" khi không được kích hoạt.

• Bit quan trọng nhất là D [7], bit ít quan trọng nhất là D [0],

• Nhiều CAM có thể dùng chung các đường dữ liệu.

Chân cho phép thẻ CE2 # # và CE1

• CE1 # (trong sơ đồ có tên CE #) được kích hoạt khi địa chỉ chẵn.

...

...

...

• CE1 # ở trạng thái hoạt động để truy nhập bộ nhớ thuộc tính và truy nhập I/O.

• Máy chủ không bao giờ chiếm đường CE1 # cho nhiều hơn một CICAM tại cùng một lúc.

• CE2 # và CE1 # không được kết nối với nhau giữa các CICAM.

Chân cho phép đầu ra OE #

• OE # được sử dụng để đọc dữ liệu từ bộ nhớ thuộc tính của CICAM.

• Máy chủ phải đưa chân OE # về điện áp cao trong hoạt động ghi bộ nhớ và đọc và ghi I/O.

• Nhiều CAM có thể dùng chung OE #

Chân cho phép ghi WE #

• WE # được sử dụng để ghi ngày và bộ nhớ thuộc tính của CICAM.

...

...

...

Yêu cầu ngắt IREQ #

• IREQ # sẵn có sau khi thay đổi chân.

• IREQ # được chiếm để thông báo cho máy chủ rằng CICAM yêu cầu dịch vụ phần mềm của máy chủ.

• Máy chủ phải hỗ trợ một đầu vào IREQ # cho mỗi khe cắm giao diện chung. Việc hỗ trợ nhiều hơn một IREQ # cho mỗi khe là tùy chọn.

• Nên định tuyến IREQ # đến một trong những đầu vào ngắt tiêu chuẩn khi máy chủ là một thiết bị tương thích máy tính. Trong trường hợp này phải được đảm bảo rằng ngắt này không bị máy chủ tự ý chiếm.

• Ngắt phải phụ thuộc mức điện áp.

Lựa chọn bộ nhớ thuộc tính REG #

• Trong trường hợp đọc hoặc ghi bộ nhớ, việc truy nhập bộ nhớ thuộc tính bị hạn chế khi REG # bị chiếm.

• Trong trường hợp đọc và ghi I/O, REG # bị chiếm.

...

...

...

Đọc vào ra IORD #

• IORD # được hỗ trợ sau khi thay đổi chân.

• IORD # bị chiếm trong hoạt động đọc I/O từ CICAM vào máy chủ.

• Nhiều CAM có thể dùng chung IORD #

Ghi vào ra IOWR #

• IOWR # được hỗ trợ sau khi thay đổi chân.

• IOWR # bị chiếm trong hoạt động ghi I/O từ máy chủ vào CICAM.

• Nhiều CAM có thể dùng chung IOWR #

Tăng thời gian chiếm bus WAIT #

...

...

...

• WAIT # không được nối với nhau giữa các CAM.

Xác nhận cổng đầu vào INPACK #

• INPACK # hoạt động ở trạng thái điện áp thấp.

• INPACK # bị CICAM chiếm khi thẻ được lựa chọn để trả lời một hoạt động đọc I/O và có thể trả lời.

• Tín hiệu này được máy chủ sử dụng để kiểm soát khả năng cho phép của bất kỳ bộ đệm dữ liệu đầu vào giữa CICAM và bus dữ liệu hệ thống của máy chủ D [7: 0].

• INPACK # không được hoạt động cho đến khi thẻ đã hoàn thành thay đổi chân.

• INPACK # không được kết nối với nhau giữa các CAM.

K.1.6.2. Các tín hiệu liên quan dòng truyền tải MPEG

Phần này mô tả các tín hiệu của các cổng của dòng truyền tải MPEG của giao diện chung. Giao diện chung thay thế các tín hiệu này nhưng được quy định tại Bảng K.1 bằng các tín hiệu được quy định tại Bảng L2 sau khi thay đổi chân để cho phép các tín hiệu của cổng này theo yêu cầu của dòng truyền tải MPEG. Trước khi thay đổi chân các tín hiệu liên quan đến dòng truyền tải MPEG không được xác định và máy chủ phải giữ các tín hiệu ở trạng thái “trở kháng cao”. Trong một cấu hình nhiều CICAM, các tín hiệu dòng truyền tải MPEG này có thể được xếp theo chuỗi qua ổ cắm trên máy chủ.

...

...

...

Đầu vào dữ liệu MPEG MDI [7: 0]

• Các đường dữ liệu dòng truyền tải MPEG MDI [7: 0] tạo thành bus dữ liệu đầu vào.

• Bit quan trọng nhất là MDI [7], bit ít quan trọng nhất là MDI [0].

• CICAM có thể nối đầu vào dữ liệu dòng truyền tải MPEG với đầu ra dữ liệu dòng truyền tải MPEG miễn là tuân theo các thông số kỹ thuật về thời gian.

Bắt đầu đầu vào MPEG MISTRT

• Tín hiệu này hoạt động để chỉ ra byte đầu tiên của một gói tin truyền tải MPEG trên MDI [7: 0].

• CICAM có thể nối MISTRT với MOSTRT miễn là tuân theo các thông số kỹ thuật về thời gian.

Đầu vào MPEG hợp lệ MIVAL

• Tín hiệu này hoạt động để chỉ ra byte hợp lệ của một gói tin truyền tải MPEG trên MDI [7:0],

...

...

...

• CICAM có thể nối MIVAL với MOVAL miễn là tuân theo các thông số kỹ thuật về thời gian

Xung nhịp đầu vào MPEG MCLKI

• Tín hiệu này là một xung nhịp đầu vào liên tục chạy sau khi thay đổi chân trong trường hợp chuyển mạch đổi hướng dòng truyền tải này được thiết lập là truyền qua mô-đun. "Dẫn đến trường hợp này là việc dòng truyền tải được định tuyến qua CICAM ".

• MCLKI nên có xung nhịp tần số liên tục liên quan đến tốc độ dữ liệu của dòng truyền tải thu được.

• CICAM có thể nối MCLKI với MCLKO miễn là tuân theo các thông số kỹ thuật về thời gian. Trong trường hợp đó, MCLKO là tín hiệu đệm của MCLKI với một thời gian trễ nhỏ.

Đầu ra dữ liệu MPEG MDO [7: 0]

• Các đường dữ liệu dòng truyền tải MPEG MDO [7: 0] tạo thành bus dữ liệu đầu ra.

• Bit quan trọng nhất là MDO [7], bit ít quan trọng nhất là MDO [0],

Bắt đầu đầu ra MPEG MOSTRT

...

...

...

Đầu ra MPEG hợp lệ MOVAL

• Tín hiệu này hoạt động để chỉ ra byte hợp lệ của một gói tin truyền tải MPEG trên MDO [7: 0].

• Trong giai đoạn mà giao diện này liên tục được chạy thì yêu cầu có và sử dụng tín hiệu này để nhận dạng dữ liệu không hợp lệ giữa và trong các lần truyền gói tin dòng truyền tải MPEG.

Xung nhịp đầu ra MPEG MCLKO

• Tín hiệu này là một xung nhịp đầu vào liên tục chạy sau khi thay đổi chân trong trường hợp chuyển mạch đổi hướng dòng truyền tải này được thiết lập là truyền qua mô-đun. "Dẫn đến trường hợp này là việc dòng truyền tải được định tuyến qua CICAM ".

• Nhiều CICAM có thể nối MCLKO với một thẻ có MCLKI của một thẻ tiếp theo khác miễn là tuân theo các thông số kỹ thuật về thời gian.

K.1.6.3. Các vấn đề định thời xung nhịp MPEG

• Để dễ dàng thiết kế EMC trên giao diện chung, nên thỏa mãn thời gian tối thiểu là 5 ns đối với thời gian tăng và giảm của các tín hiệu xung nhịp MCLKI và MCLKO.

• Do méo tín hiệu tích lũy khi truyền các xung nhịp qua ít nhất 2 CICAM và tiết kiệm về kinh tế trong việc tạo hình lại và đệm xung nhịp và vẫn đáp ứng yêu cầu thời gian ở tốc độ xung nhịp tối đa, nên thỏa mãn thời gian tối thiểu là 20 ns đối với thời gian tăng và giảm của các tín hiệu xung nhịp MCLKI và MCLKO

...

...

...

• Thời gian tăng được định nghĩa là thời gian chuyển tiếp từ Vl_max sang Vh_min được quy định tại điều K.1.5.

• máy chủ đệm tín hiệu MCLKO của giao diện chung của nó để truyền đến giao diện chung tiếp MCLKI không được tạo ra chênh lệch tích lũy tuyệt đối giữa thời gian tăng và thời gian giảm hơn 20 ns.

• Để thỏa mãn yêu cầu thời gian tăng và giảm, bổ sung yêu cầu sau vào điều K.1.5. Tải điện dung dành cho MCLKO phải từ 10 pF đến 50pF. Tải điện dung dành MCLKI phải từ 5 pF đến 25 pF.

• Không nên sử dụng các bộ tạo hình xung nhịp đơn giản kết hợp với nhiều CICAM có thực hiện truyền MCLKO từ một CICAM qua một bộ đệm trên máy chủ đến MCLKI của CICAM tiếp theo.

K.1.7. Các thông số quy định thời gian

Mô tả chi tiết của các tín hiệu và bus dữ liệu được trình bày trong điều K.1.6.1

K.1.7.1. Sơ đồ đọc bộ nhớ thuộc tính của giao diện chung

Hình K.4 - Sơ đồ thời gian đọc bộ nhớ thuộc tính.

...

...

...

Mục

Ký hiệu

300 ns

min

max

Read Cycle Time

t_cR

300

...

...

...

t_a(A)

300

Card Enable Access Time

t_a(CE#)

300

Output Enable Access Time

t_a(OE#)

...

...

...

150

Output Disable Time from OE#

t_dis(OE#)

100

Output Enable Time from OE#

t_en(OE#)

5

...

...

...

t_v(A)

0

Address Setup Time^1

t_su(A)

100

Address Hold Time ^1

t_h(A)

...

...

...

Card Enable Setup Time ^1

t_su(CE#)

0

Card Enable Hold Time ^1

t_h(CE#)

35

...

...

...

t_v(WT- OE#)

100

WAIT# Pulse Width ^6

t_w(WT)

12 μs

Data Setup for WAIT# Released

t_v(WT)

...

...

...

CHÚ THÍCH:

1. Các thời gian này được quy định dành cho máy chủ và CICAM có hỗ trợ tín hiệu WAIT#.

2. Các thời gian được tính theo ns khi không được ghi rõ đơn vị.

K.1.7.2. Sơ đồ ghi bộ nhớ thuộc tính của giao diện chung

Hình K.5 - Sơ đồ thời gian ghi bộ nhớ thuộc tính.

Bảng K.12 - Các thông số quy định thời gian ghi bộ nhớ thuộc tính

Mục

...

...

...

250 ns

min

max

Write Cycle Time

t­_c(W)

250

Write Pulse Width

t_w(WE#)

...

...

...

Address Setup Time ^1

t_su(A)

30

Address Setup Time for WE# ^1

t_su(A-WE#)

180

...

...

...

t_su(CE#-WE#)

180

Data Setup Time for WE#

t(D-CE#)

80

Data Hold Time

t_h(D)

...

...

...

Write Recover Time

t_rec(WE#)

30

Output Disable Time from WE#

t_dis(WE#)

100

...

...

...

t_dis(OE#)

100

Output Enable Time from WE#

t_en(WE#)

5

Output Enable Time from OE#

t_en(OE#)

...

...

...

Output En. Setup from WE#

t_su(OE#-WE#)

10

Output Enable Hold from WE#

t_h(OE#-WE#)

10

...

...

...

t_su(CE#)

0

Card Enable Hold Time^2

t_h(CE#)

20

WAIT# Valid from WE# ^2

t_v(WT-WE#}

...

...

...

35

WAIT# Pulse Width ^4

t_w(WT)

12 μs

WE# High from WAIT# released ^3

t_v(WT)

0

...

...

...

1. Định thời tín hiệu REG# giống định thời tín hiệu địa chỉ.

2. Các thời gian này được quy định dành cho máy chủ và CICAM có hỗ trợ tín hiệu WAIT#.

3. Các thời gian này chỉ được quy định khi WAIT# được sử dụng.

4. Các thời gian được đo tại thẻ Cl. Các độ lệch và độ trễ từ thiết bị thu đến thẻ Cl phải được tính.

5. Các thời gian được tính theo ns khi không được ghi rõ đơn vị.

K.1.7.3. Thời gian đọc I/O của giao diện chung

Hình K.6 - Sơ đồ thời gian đọc I/O.

Bảng K.13 - Các thông số quy định thời gian đọc I/O

...

...

...

Ký hiệu

min

max

Data Delay after IORD#

t­_su(D)

100

Data Hold following IORD#

t_h(D)

...

...

...

IORD# Width Time

t_w(IORD)

165

Address Setup before IORD#

t_su(A)

70

...

...

...

t_h(A)

20

CE# Setup before IORD#

t_su(CE#)

5

CE# Hold following IORD#

t_h(CE#)

...

...

...

REG# Setup before IORD#

t_su(REG#)

5

REG# Hold following IORD#

t_h(REG#)

0

...

...

...

_df(INPACK#)

0

45

INPACK# Delay Rising from IORD#

_dr(INPACK#)

45

WAIT# Delay Falling from IORD#

t_df(WAIT#)

...

...

...

35

Data Delay from WAIT# Rising

t_dr(WAIT#)

0

WAIT# Width Timing

t_w(WAIT#)

12000

...

...

...

K.1.7.4. Thời gian ghi I/O của giao diện chung

Hình K.7 - Sơ đồ thời gian ghi I/O.

Bảng K.14 - Các thông số quy định thời gian I/O

Mục

Ký hiệu

min

Max

Data Delay before IOWR#

...

...

...

60

Data Hold following IOWR#

t_h(D)

30

IOWR# Width Time

t_w(IORD)

165

...

...

...

Address Setup before IOWR#

t_su(A)

70

Address Hold following IOWR#

t_h(A)

20

CE# Setup before IOWR#

...

...

...

5

CE# Hold following IOWR#

t_h(CE#)

20

REG# Setup before IOWR#

t_su(REG#)

5

...

...

...

REG# Hold following IOWR#

t_h(REG#)

0

WAIT# Delay Falling from IOWR#

t_df(WAIT#)

35

IOWR# High from WAIT# High

...

...

...

0

WAIT# Width Timing

t_w(WAIT#)

12000

NOTE: All timings in ns.

K.1.7.5. Định thời tín hiệu MPEG của giao diện chung

...

...

...

Bảng K.15 - Các thông số quy định thời gian tín hiệu dòng truyền tải MPEG

Mục

Ký hiệu

Minimum Timings

72 MBits/s

96 MBits/s

Clock Period

t_clkp

111

...

...

...

Clock High Time

t_clkh

40

20

Clock Low Time

t_clkl

40

20

Input Data Setup Time

...

...

...

15

10

Input Data Hold Time

t_h

10

10

Output Data Setup Time

t_osu

20

...

...

...

Output Data Hold Time

t_oh

15

10

NOTE: All timings in ns.

Phụ lục L

(quy định)

Tóm tắt tài nguyên

...

...

...

Có hai phiên bản ID tài nguyên khác nhau. Phiên bản 1 được quy định trong EN [7] 50.221, điều 8.2.2, phiên bản 2 được quy định trong TS 101 699 [8] điều 4.1. Trong phiên bản 1, resource_type là 10 bit. Phiên bản 2 chia trường này thành resource_type 4 bit và resource_instance 6 bit. resource_instance giống với module_id được mô tả trong TS 101 699 [8], điều 4.2.

resource_instance được sử dụng để phân biệt giữa các hoạt động khác nhau có cùng một tài nguyên được máy chủ và CAM cung cấp mà chung phải cùng tồn tại. Khái niệm này chỉ áp dụng đối với các tài nguyên được liệt kê trong TS 101 699 [8], điều 4.2. Máy chủ hỗ trợ một trong những tài nguyên này phải thực hiện quản lý tài nguyên theo phiên bản 2 và thương lượng một module_id với mỗi CICAM.

Đối với tất cả các tài nguyên không được liệt kê trong TS 101 699 [8], điều 4.2, Tài nguyên ID phiên bản 1 được sử dụng. Tất cả các tài nguyên được xác định trong tiêu chuẩn này sử dụng tài nguyên ID phiên bản 1. Các tài nguyên này có thể được nhà quản lý tài nguyên phiên bản 1 hoặc 2 xử lý.

resource_id_type (xem EN 50221 [7], điều 8.8.2) được thiết lập là 0 dành cho tất cả các tài nguyên để chỉ ra rằng chúng là các tài nguyên lực chung.

L.2. Tóm tắt tài nguyên

Bảng L.1 - Tóm tắt tài nguyên

Nguồn lực

Đối tượng ứng dụng

Hướng

...

...

...

Tên

ID nguồn lực

Lớp

Kiểu

P.Bản

Thẻ APDU

Giá trị thẻ

Máy chủ

...

...

...

Sự bắt buộc

Tài liệu

Quản lý nguồn lực

00 01 00 41

1

1

1

profile_enq

9F 80 10

...

...

...

Có

Có thể sử dụng phiên bản 1 hoặc phiên bản 2

EN 50221

profile

9F 80 11

ÙÚ

profile_change

9F 80 12

ÙÚ

...

...

...

1

1

2

profile_enq

9F 80 10

ÙÚ

TS 101 699

profile

9F 80 11

...

...

...

profile_change

9F 80 12

ÙÚ

module_id_send

9F 80 13

Ù

module_id_command

9F 80 14

Ú

...

...

...

00 02 00 41

2

1

1

application_info_enq

9F 80 20

Ú

Có

EN 50221

...

...

...

9F 80 21

Ù

enter_menu

9F 80 22

Ú

00 02 00 42

2

1

2

...

...

...

9F 80 20

Ú

Có

TS 101 699

application_info

9F 80 21

Ù

enter_menu

9F 80 22

...

...

...

00 02 00 43

2

1

3

application_info_enq

9F 80 20

Ú

Có

Cl Plus

...

...

...

9F 80 21

Ù

enter_menu

9F 80 22

Ú

request_cicam_reset

9F 80 23

Ù

data_rate_info

...

...

...

Ú

Hỗ trợ truy nhập có điều kiện

00 03 00 41

3

1

1

ca_info_enq

9F 80 30

Ú

...

...

...

EN 50221

ca_info

9F 80 31

Ù

ca_pmt

9F 80 32

Ú

ca_pmt_reply

9F 80 33

...

...

...

Kiểm soát máy chủ

00 20 00 41

32

1

1

tune

9F 84 00

Ù

Có

...

...

...

replace

9F 84 01

Ù

clear_replace

9F 84 02

Ù

ask_release

9F 84 03

Ú

...

...

...

32

1

2

tune

9F 84 00

Ù

Có

Cl Plus 1.3

replace

...

...

...

Ù

clear_replace

9F 84 02

Ù

ask_release

9F 84 03

Ú

tune_broadcast_req

9F 84 04

...

...

...

tune_reply

9F 84 05

Ú

ask_release_reply

9F 84 06

Ù

Ngày - giờ

00 24 00 41

36

...

...

...

1

date_time_enq

9F 84 40

Ù

Có

EN 50221

date_time

9F 84 41

Ú

...

...

...

00 40 00 41

64

1

1

close_mmi

9F 88 00

Ú

Chỉ mức cao

EN 50221

...

...

...

9F 88 01

Ù

display_reply

9F 88 02

Ú

text_last

9F 88 03

Ù

text_more

...

...

...

Ù

keypad_control

9F 88 05

Ù

keypress

9F 88 06

Ú

enq

9F 88 07

...

...

...

answ

9F 88 08

Ú

menu_last

9F 88 09

Ù

menu _more

9F 88 0A

Ù

...

...

...

9F 88 0B

Ú

list_last

9F 88 0C

Ù

list_more

9F 88 0D

Ù

subtitle_segment_last

...

...

...

Ù

subtitle_segment_more

9F 88 0F

Ú

display_message

9F 88 10

Ù

scene_end_mark

9F 88 11

...

...

...

scene_done

9F 88 12

Ù

scene_control

9F 88 13

Ú

subtitle_download_last

9F 88 14

Ù

...

...

...

9F 88 15

Ú

flush_download

9F 88 16

Ù

download_reply

9F 88 17

Ù

Giao tiếp tốc độ thấp

...

...

...

96

1

comms_cmd

9F 8C 00

Ù

Có cho phiên bản 1.3 phần ID máy chủ tồn tại hỗ trợ

EN 50221

connection_descriptor

...

...

...

Ù

comms_reply

9F 8C 02

Ú

comms_send_Iast

9F 8C 03

Ù

comms_send_more

9F 8C 04

...

...

...

comms_rcv_last

9F 8C 05

Ú

comms_rcv_more

9F 8C 06

Ú

00 60 xx x2

96

...

...

...

comms_cmd

9F 8C 00

Ù

Có cho phiên bản 1.3 tại Các tồn tại hỗ trợ IP máy chủ

Cl Plus

connection_descriptor

9F 8C 01

Ù

comms_reply

...

...

...

Ú

comms_send_Iast

9F 8C 03

Ù

comms_send_more

9F 8C 04

Ù

comms_rcv_last

9F 8C 05

...

...

...

comms_rcv_more

9F 8C 06

Ú

00 60 xx x3

96

3

comms_cmd

9F 8C 00

...

...

...

Có cho phiên bản 1.3 tại Các tồn tại hỗ trợ IP máy chủ

Cl Plus 1.3

connection_descriptor

9F 8C 01

Ù

comms_reply

9F 8C 02

Ú

comms_send_last

...

...

...

Ù

comms_send_more

9F 8C 04

Ù

comms_rcv_last

9F 8C 05

Ú

comms_ rcv_more

9F 8C 06

...

...

...

Kiểm soát nội

dung

00 8C 10 01

140

64

1

cc_open_req

9F 90 01

Ù

...

...

...

Cl Plus

cc_open_cnf

9F 90 02

Ú

cc_data_req

9F 90 03

Ù

cc_data_cnf

9F 90 04

...

...

...

cc_sync_req

9F 90 05

Ù

cc_sync_cnf

9F 90 06

Ú

cc_sac_data_req

9F 90 07

Ù

...

...

...

9F 90 08

Ú

cc_sac_sync_req

9F 90 09

Ù

cc_sac_sync_cnf

9F 90 10

Ú

00 8C 10 02

...

...

...

64

2

cc_open_req

9F 90 01

Ù

Có

Cl Plus 1.3

cc_open_cnf

9F 90 02

...

...

...

cc_data_req

9F 90 03

Ù

cc_data_cnf

9F 90 04

Ú

cc_sync_req

9F 90 05

Ù

...

...

...

00 96 10 01

150

64

1

SAS_connect_rqst

9F 9A 00

Ú

Không

Cl Plus

...

...

...

9F 9A 01

Ù

SAS_date_rqst (see note 1)

9F 9A 02

ÙÚ

SAS_date_av (see note 1)

9F 9A 03

ÙÚ

SAS_data_cnf (see note 1)

...

...

...

ÙÚ

SAS_server_query (see note 1)

9F 9A 05

ÙÚ

SAS_server_reply (see note 1)

9F 9A 06

ÙÚ

SAS_async_msg

9F 9A 07

...

...

...

Ứng dụng MMI

00 41 00 41

65

1

1

RequestStart

9F 80 00

Ù

Có

...

...

...

RequestStartAck

9F 80 01

Ú

FileRequest

9F 80 02

Ú

FileAcknowledge

9F 80 03

Ù

...

...

...

9F 80 04

ÙÚ

AppAbortAck

9F 80 05

ÙÚ

00 41 00 42

65

1

2

...

...

...

9F 80 00

Ù

Không cho máy chủ và Có cho CICAM

CI Plus 1.3

RequestStartAck

9F 80 01

Ú

FileRequest

9F 80 02

...

...

...

FileAcknowledge

9F 80 03

Ù

AppAbortRequest

9F 80 04

ÙÚ

AppAbortAck

9F 80 05

ÙÚ

...

...

...

cc_sync_cnf

9F 90 06

Ú

...

...

...

cc_sac_data_req

9F 90 07

Ù

cc_sac_data_cnf

9F 90 08

Ú

cc_sac_sync_req

9F 90 09

Ù

...

...

...

9F 90 10

Ú

cc_PIN_capabilities_req

9F 90 11

Ú

cc_PIN_capabilities_reply

9F 90 12

Ù

cc_PIN_cmd

...

...

...

Ú

cc_PIN_reply

9F 90 14

Ù

cc_PIN_event

9F 90 15

Ù

cc_PIN_playback

9F 90 16

...

...

...

cc_PlN_MMI_req

9F 90 17

Ú

Ngôn ngữ và quốc gia của máy chủ

00 8D 10 01

141

64

1

Host_country_enq

...

...

...

Ù

Có

Cl Plus

Host_country

9F 81 01

Ú

Host_language_enq

9F 81 10

Ù

...

...

...

9F 81 11

Ú

Nâng cấp CAM

(CAM_Upgrade)

00 8E 10 01

142

64

1

cam_firmware_upgrade

...

...

...

Ù

Có

Cl Plus

cam_firmware_upgrade_reply

9F 9D 02

Ú

cam_firmware upgrade_progress

9F 9D 03

Ù

...

...

...

9F 9D 04

Ù

Hồ sơ nhà

khai thác

00 8F 10 01

143

64

1

operator_status_req

...

...

...

Ù

Có

Cl Plus 1.3

operator_status

9F 9C 01

Ú

operator_nit_req

9F 9C 02

Ú

...

...

...

9F 9C 03

Ù

operator_info_req

9F 9C 04

Ú

operator_info

9F 9C 05

Ù

operator_search_start

...

...

...

Ú

operator_search_status

9F 9C 07

Ù

operator_exit

9F 9C 08

Ú

operator_tune

9F 9C 09

...

...

...

operator_tune_status

9F 9C 0A

Ú

operator_entitlement_ack

9F 9C 0B

Ú

operator_search_cancel

9F 9C 0C

Ú

...

...

...

(quy định)

Định dạng bản tin ứng dụng MHP

M.1. Giới thiệu

Phụ lục này mô tả định dạng bản tin ứng dụng MHP để kết nối giữa hệ thống CA tồn tại trên CICAM và giao diện ứng dụng MHP được quy định trong TS 102 757 [35]. Khi xem xét định dạng bản tin này thì những khác biệt kiến trúc của một thiết bị thu tích hợp không chứa hệ thống truy nhập có điều kiện và một thiết bị thu có chứa một hệ thống tích hợp CA đã được xem xét. Tổng quan kiến trúc của những môi trường khác nhau này được trình bày.

M.2. Môi trường nhúng CAS

Môi trường nhúng CAS được mô tả trong hình M.1 và có lẽ là một môi trường đơn giản nhất dành cho môi trường ứng dụng truy nhập có điều kiện. Trong trường hợp này nhà sản xuất kiểm soát phần mềm trên thiết bị thu và làm việc với nhà cung cấp CA cho phép thành phần MHP được kết nối với hệ thống CA. Các vấn đề tương thích giữa hệ thống CA và API ứng dụng MHP có thể được nhà sản xuất giải quyết.

Hình M.1 - Môi trường nhúng CAS

M.1.2. Môi trường Cl CAS

...

...

...

Hình M.2 - Môi trường CICAM CAS

Trong môi trường này thì nhà sản xuất CICAM có nhận biết về các giao diện CA, nhà sản xuất DTV không có nhận biết về các giao diện CA, do đó thông tin CA và truyền hình trả tiền cho mỗi lần xem phải được truyền qua Cl đến môi trường ứng dụng và trình bày tại giao diện ứng dụng này. Đối với một nhà sản xuất để thực hiện it.dtt.ca thì giao diện chung này phải cung cấp tất cả các thông tin vì các bản tin Cl mới được môi trường truyền hình bản địa nhận biết. Điều này yêu cầu có một tài nguyên Cl dành cho thông tin CA mà thiết bị thu cho phép MHP và các CAM cho phép thông tin Cl CA đã biết.

M.1.3. Sử dụng SAS để hỗ trợ MHP

Tài nguyên SAS đã được chọn là tài nguyên APDU truyền dữ liệu để truyền dữ liệu giữa CICAM và máy chủ (và ngược lại). Tiêu chuẩn này cung cấp việc kiểm soát các lần truyền không đồng bộ tốt hơn so với tài nguyên ống truyền DVB CA. Hình M.3 mô tả một khái niệm kết nối giữa CICAM và máy chủ.

Hình M.3 - Kết nối MHP và hệ thống CA thông qua SAS.

Trong đó:

• private_host_application_ID phải được xác định trước dành cho các môi trường MHP.

• Open_Session_Request/Responseand SAS_Connect_Request/cnf được sử dụng để thiết lập phiên truyền.

...

...

...

Ngoài ra,

• Hoạt động MHP CA API phải được ứng dụng MHP SAS xử lý trong trường hợp CICAM được sử dụng cho CAS (hoặc CA nhúng nếu CAS địa phương được chọn).

• Ứng dụng SAS MHP phải ánh xạ giữa MHP CA API và MHP CA API dành cho Cl Plus như được quy định tại phụ lục này.

• Các bản tin SAS MHP phải hỗ trợ siêu tập MHP CA API đầy đủ. Dữ liệu riêng của nhà cung cấp CA cụ thể phải được truyền trong suốt qua giao diện này theo một cách xác định và rõ ràng như được quy định trong CA MHP API dành cho Cl Plus.

• Ứng dụng SAS MHP trong CAM là một tập con tuân theo các yêu cầu dành cho một CAS cụ thể.

M.1.4. Các quyết định quan trọng

Các quyết định quan trọng trong việc xác định liên kết ứng dụng MHP được trình bày dưới đây:

• SAS được chọn để truyền dữ liệu qua giao diện chung.

• Liên kết hệ thống CA không cần được mã hóa.

...

...

...

• Các nhà sản xuất CICAM và máy chủ thực hiện tạo định dạng bản tin này, tức là các nhà sản xuất máy chủ ghép với ita.dtt.ca, các nhà sản xuất CICAM ghép với hệ thống CA API.

• Các bản tin phải đóng gói tất cả các yêu cầu của ita.dt.ca và không yêu cầu sử dụng tài nguyên Cl khác để biết thông tin.

M.2. Định dạng bản tin

Phần này mô tả định dạng bản tin it.dtt.ca MHP [35]. CICAM và máy chủ cho phép MHP phải hỗ trợ tất cả các bản tin này.

M.2.1. Thiết lập phiên

Miền ứng dụng trên CICAM phải mở phiên SAS. Máy chủ phải yêu cầu một kết nối dành cho ứng dụng MHP bằng cách sử dụng SAS_connect_rqst () APDU gửi đến CICAM để thiết lập kết nối giữa ứng dụng này và hệ thống CA. Kết nối này phải được thành lập với private_host_application_ID 64-bit có "itdttca \ 0" có giá trị thập lục phân là 0x6974647474636100.

CICAM phải trả lời bằng một SAS_connect_cnf () APDU và thiết lập trường SAS_session_status để xác định trạng thái kết nối.

M.2.2. Hoạt động phiên

Ứng dụng API này phải hoạt động ở chế độ không đồng bộ chỉ để truy vấn và trao đổi dữ liệu bằng cách sử dụng SAS_async_msg () được sao chép lại trong Bảng M.1.

...

...

...

Cú pháp

Số bit

Kiểu

SAS_async_msg() {

24

uimsbf

SAS_async_msg_tag

*

...

...

...

8

uimsbf

message_nb

16

uimsbf

message_length

message byte()

}

8 * message_length

...

...

...

Ngữ nghĩa cho cú pháp SAS_async_msg () APDU được Bản quy định kỹ thuật OpenCableTM, giao diện CableCardTM 2.0 [27, 9.17.8] định nghĩa với các tiêu chí sau đây:

message_nb: số bản tin được tạo ra từ một bộ đếm vòng 8-bit, máy chủ và CICAM phải duy trì các số bộ đếm bản tin của riêng nó, số này phải được tăng thêm 1 khi mỗi bản tin được gửi đi. Bộ đếm quay vòng từ 255 về 0.

Trường message_byte 0 dành cho mỗi bản tin phải có định dạng chung được quy định tại Bảng M.2, trong đó dữ liệu bản tin có thể được chia thành một số các bản ghi có chứa các loại dữ liệu giống hoặc khác nhau được xác định bởi datatype_id.

Bảng M.2 - Cú pháp message_byte 0 chung

Cú pháp

Số bit

Kiểu

message_byte() {

...

...

...

command_id

8

uimsbf

ca_system_id

16

uimsbf

transaction_id

32

uimsbf

...

...

...

8

uimsbf

for (i=0; i<send_datatype_nbr; i++) { datatype_id datatype_length data_type()

8

uimsbf

}

16

...

...

...

}

8 * datatype_length

bslbf

Ngữ nghĩa dành cho cú pháp message_byte () chung:

command_id: Đây là một giá trị 8-bit để xác định loại bản tin và phải là một lệnh hoặc một trả lời. Các giá trị của trường này được quy định tại Bảng M.3. Miền nhận dạng lệnh nói chung được chia thành hai phần, lệnh là phần chẵn, trả lời của một lệnh là nhận dạng chẵn của lệnh này cộng với 1.

Bảng M.3 - Các nhận dạng bản tin lệnh

Command_id

Nhận dạng

Chiều

...

...

...

Dự phòng

0x00

Dự phòng.

Dự phòng

0x01

Dự phòng.

CMD_ATR_GET_REQUEST

...

...

...

HÚM

Yêu cầu được máy chủ gửi để truy vấn thông tin ATR của thẻ thông minh

CMD_ATR_GET_RESPONSE

0x03

HÙM

Trả lời bản tin ATR Get Request của CICAM chứa thông tin ATR của thẻ thông minh trong khe cắm đã cho hoặc có nhận dạng đã cho

CMD_CANCEL_REQUEST

0x04

HÙM

...

...

...

Yêu cầu được máy chủ hoặc CICAM gửi để hủy yêu cầu có một nhận dạng giao dịch xác định, lệnh này (nếu có) sẽ được hủy và lệnh này trả về trạng thái không thành công

CMD_CANCEl_RESPONSE

0x05

HÙM

HÚM

Trả lời bản tin Cancel Request, trả lời này chỉ được gửi khi không có transaction_id cần được hủy.

CMD_CAPABILITIES_REQUEST

0x06

HÚM

...

...

...

CAS được hỗ trợ.

CMD_CAPABILITIES_RESPONSE

0x07

HÙM

Trả lời bản tin CMD_CAPABILITIES_REQUEST từ CICAM đến máy chủ chứa thông tin hệ thống CA.

CMD_HISTORY_GET_REQUEST

0x08

HÚM

Yêu cầu được máy chủ gửi để lấy thông tin quá trình.

...

...

...

0x09

HÙM

Trả lời bản tin History Get Request từ CICAM chứa thông tin quá trình của sự kiện.

CMD_HISTORY_SET_REQUEST

0x0a

HÚM

Yêu cầu được máy chủ gửi để thiết lập thông tin quá trình.

CMD_HISTORY_SET_RESPONSE

0x0b

...

...

...

Trả lời bản tin History Set Request từ CICAM.

CMD_NOTIFICATION_DISABLE

0x0c

HÚM

Không cho phép các thông báo sự kiện không đồng bộ của CICAM.

CMD_NOTIFICATION_ENABLE

0x0d

HÚM

Cho phép các thông báo sự kiện không đồng bộ của CICAM.

...

...

...

0x0d

HÚM

Cho phép các thông báo sự kiện không đồng bộ của CICAM.

CMD_PARENTAL_LEVEL_GET_REQUEST

0x0s

HÚM

Yêu cầu từ máy chủ để truy vấn mức kiểm soát của cha mẹ hiện tại.

CMD_PARENTAL_LEVEL_GET_RESPONSE

0x0f

...

...

...

Trả lời từ CICAM để lấy mức kiểm soát của cha mẹ hiện tại và để trả lời bản tin CMD_PARENTAL_LEVEL_GET_REQUEST.

CMD_PARENTAL_LEVEL_SET_REQUEST

0x10

HÚM

Yêu cầu từ máy chủ để sửa đổi mức kiểm soát của cha mẹ hiện tại.

CMD_PARENTAL_LEVEL_SET_RESPONSE

0x11

HÙM

Trả lời từ CICAM để sửa đổi mức kiểm soát của cha mẹ và để trả lời bản tin CMD_SET_PARENTAL_LEVEL_REQUEST.

...

...

...

0x12

HÚM

Yêu cầu được máy chủ gửi để kiểm tra thông tin PIN.

CMD_PIN_CHECK_RESPONSE

0x13

HÙM

Trả lời bản tin Set PIN Request của CICAM để xác nhận mã PIN đúng

CMD_PIN_GET_REQUEST

0x14

...

...

...

Truy vấn CICAM thông tin trạng thái của PlN.

CMD_PlN_GET_RESPONSE

0x15

HÙM

Trả Iời bản tin CMD_PIN STATUS_REQUEST từ CICAM chứa thông tin trạng thái của các PIN.

CMD_PIN_SET_REQUEST

0x16

HÚM

Yêu cầu được máy chủ gửi để thay đổi thông tin PIN hiện tại.

...

...

...

0x17

HÙM

Trả lời bản tin PIN Set Request của CICAM chứa thông tin PIN được hệ thống CA này nắm giữ.

CMD_PRIVATE_DATA_REQUEST

0x18

HÙM

HÚM

Yêu cầu được máy chủ CICAM gửi để trao đổi thông tin riêng

CMD_PRIVATE_DATA_RESPONSE

...

...

...

HÙM

HÚM

Trả lời bản tin Private Data Request.

CMD_PRODUCT_GET_REQUEST

0x1a

HÚM

Yêu cầu được máy chủ gửi để truy vấn bảng tin sản phẩm hiện tại.

CMD_PRODUCT_GET_RESPONSE

0x1b

...

...

...

Trả lời bản tin Product Get Request của CICAM chứa thông tin sản phẩm của sự kiện.

CMD_PURCHASE_CANCEL_REQUEST

0x1c

HÚM

Yêu cầu được máy chủ gửi để hủy mua một sự kiện.

CMD_PURCHASE_CANCEL_RESPONSE

0x1d

HÙM

...

...

...

CMD_PURCHASE_SET_REQUEST

0x1e

HÚM

Yêu cầu được máy chủ gửi để mua một sự kiện

CMD_PURCHASE_SET_RESPONSE

0x1f

HÙM

Trả lời bản tin Purchase Set Request của CICAM chứa thông tin sản phẩm của sự kiện.

CMD_RECHARGE_REQUEST

...

...

...

HÚM

Yêu cầu được máy chủ gửi để nạp tiền vào ví tiền.

CMD_RECHARGE_RESPONSE

0x21

HÙM

Trả lời bản tin Recharge Request của CICAM chứa kết quả chi tiết của sự kiện nạp tiền

CMD_SLOT_GET_REQUEST

0x22

HÚM

...

...

...

CMD_SLOT_GET_RESPONSE

0x23

HÙM

Trả lời bản tin Slot Get Request của CICAM chứa thông tin khe cắm của thẻ thông minh trong khe cắm đã cho.

CMD_SMARTCARD_GET_REQUEST

0x24

HÚM

Yêu cầu được máy chủ gửi để truy vấn thông tin thẻ thông minh

CMD_SMARTCARD_GET_RESPONSE

...

...

...

HÙM

Trả lời bản tin SmartCard Get Request của CICAM chứa thông tin thẻ thông minh trong khe cắm đã cho hoặc có nhận dạnh đã cho.

CMD_SMARTCARD_GET_REQUEST

0x26

HÚM

Yêu cầu được máy chủ gửi để thiết lập thông tin dữ liệu của người sử dụng trên thẻ thông minh

CMD_SMARTCARD_GET_RESPONSE

0x27

HÙM

...

...

...

CMD_WALLET_GET_REQUEST

0x28

HÚM

Yêu cầu được máy chủ gửi để lấy thông tin của ví tiền

CMD_ WALLET_GET_RESPONSE

0x29

HÙM

Trả lời bản tin Wallet Get Request của CICAM.

CMO_PRODUCT_INFO_GET_REQUEST

...

...

...

HÚM

Yêu cầu được máy chủ gửi để truy vấn thông tin trạng thái sản phẩm hiện tại

CMD_PRODUCT_INFO_GET_RESPONSE

0x31

HÙM

Trả lời bản tin Product Info Get Request của CICAM chứa thông tin trạng thái sản phẩm.

0x32-

0x3f

...

...

...

Dự phòng

CMD_ACCESS_EVENT

0x40

HÙM

Bản tin sự kiện từ CICAM để thông báo về những thay đổi trạng thái của mô đun CA liên quan đến các khoảng thời gian mua, giải xáo trộn và truy nhập.

CMD_CREDIT_EVENT

0x42

HÙM

Bản tin sự kiện từ CICAM về sự thay đổi trạng thái của tín dụng

...

...

...

0x44

HÙM

Bản tin sự kiện từ CICAM thông báo một bản tin thông tin mới.

CMD_PIN_REQUEST_EVENT

0x46

HÙM

Sự kiện từ CICAM chỉ ra yêu cầu nhập PIN

CMD_PlN_RESPONSE_EVENT

0x47

...

...

...

Trả lời bản tin Pin Request Event từ máy chủ đến CICAM chứa mã PIN được yêu cầu

CMD_PRIVATE_DATA_EVENT

0x48

HÙM

HÚM

Yêu cầu được máy chủ hoặc CICAM gửi để trao đổi thông tin riêng không yêu cầu xác nhận.

CMD_PRODUCT_EVENT

0x4a

HÙM

...

...

...

CMD_PURCHASE_HISTORY_ EVENT

0x4c

HÙM

Bản tin sự kiện từ CICAM về sự thay đổi của quá trình mua

CMD_RECHARGE_EVENT

0x4e

HÙM

Bản tin sự kiện từ CICAM chỉ ra rằng sự kiện nạp tiền đã hoàn thành

CMD_SLOT_EVENT

...

...

...

HÙM

Bản tin sự kiện từ CICAM về sự thay đổi trạng thái thẻ, bản tin này phải được gửi không đồng bộ bất cứ khi nào trạng thái thẻ thay đổi.

CMD_SMARTCARD_EVENT

0x52

HÙM

Bản tin sự kiện từ CICAM về sự thay đổi trạng thái thẻ

0x54-

0x7f

...

...

...

Dự phòng.

0x80-0xff

Được người sử dụng xác định.

ca_system_id: Đây là một số nguyên 16-bit để xác định hệ thống CA đang được truy vấn đến, nó có thể là 0 khi truy vấn CICAM hoặc truyền một bản tin không thuộc CA cụ thể.

transaction_id: Một giá trị 32-bit, được thiết bị gửi bản tin yêu cầu dữ liệu tạo ra, nó được trả về trong bất kỳ bản tin trả lời tương ứng cho yêu cầu đó. transaction_id cho phép bất kỳ yêu cầu không đồng bộ về thông tin được liên kết với bất kỳ trả lời nào trả về thông tin này. Không có hạn chế về giá trị của trường này.

send_datatype_nbr: Số các mục của loại dữ liệu được bao gồm trong bản tin này.

datatype_id: Loại dữ liệu được chứa trong vòng loại dữ liệu, các giá trị này được quy định tại Bảng M.4.

...

...

...

Nhận dạng kiểu dữ liệu

datatype id

Mô tả

0

Dự phòng.

dtid_access_event

31

Thông tin về truy nhập dịch vụ từ hệ thống CA.

...

...

...

1

Byte dữ liệu chung.

dtid_cas_information()

2

Nhận dạng nhà cung cấp CA và thông tin về hệ thống CA.

dtid_cicam_information()

3

Nhận dạng nhà cung cấp CICAM và thông tin về hệ thống CICAM.

dtid_credit_event()

...

...

...

Thông báo trạng thái ví tiền và tín dụng từ hệ thống CA.

dtid_error_status

5

Thông tin trạng thái lỗi.

dtid_history()

6

Bản ghi bản tin hoặc quá trình.

dtid_history_event()

7

...

...

...

dtid_history_request()

8

Yêu cầu thông tin quá trình.

dtid_numeric_index()

9

Một chỉ số hoặc một giá trị số nguyên.

dtid_object_identity()

10

Nhận dạng đối tượng được hệ thống CA cấp.

...

...

...

11

Mức của cha mẹ.

dtid_pin_code()

12

Mã PIN.

dtid_pin_event()

13

Thông báo trạng thái từ hệ thống CA yêu cầu mã PIN nên được nhập vào.

dtid_pin_information()

...

...

...

Thông tin về mã PIN.

dtid_product()

15

Bản ghi của sản phẩm.

dtid_product_event()

16

Thông báo trạng thái sản phẩm từ hệ thống CA.

dtid_product_info()

30

...

...

...

dtid_product_request()

17

Yêu cầu thông tin sản phẩm.

dtid_purchase()

18

Bản ghi việc mua.

dtid_recharge()

19

Yêu cầu nạp tiền.

...

...

...

20

Thông báo trạng thái nạp tiền từ hệ thống CA.

dtid_service_id()

21

Nhận dạng dịch vụ.

dtid_slot()

22

Nhận dạng trạng thái của khe cắm thẻ thông minh.

dtid_slot_event()

...

...

...

Thông báo trạng thái của sự kiện thẻ từ hệ thống CA.

dtid_smartcard()

24

Thông tin của thẻ thông minh.

dtid_smartcard_event()

25

Thông báo trạng thái của sự kiện thẻ thông minh từ hệ thống CA.

dtid_smartcard_request()

26

...

...

...

dtid_user_data()

27

Dữ liệu của người sử dụng.

dtid_wallet()

28

Bản ghi của ví tiền.

dtid_wallet_id()

29

Nhận dạng của ví tiền.

...

...

...

32

-

12

7

Dự phòng.

12

8-

25

...

...

...

Được người sử dụng xác định.

datatype_length: Giá trị của trường datatype theo byte.

data_type (): Các nội dung dữ liệu này được xác định bởi datatype_id của độ dài datatype_length theo byte. Vòng loại dữ liệu chỉ phải bao gồm loại dữ liệu quy định, nhưng có thể chứa nhiều bản ghi cùng loại, số bản ghi có thể được xác định bằng cách tính trường datatype_length.

M.3. Các thành phần bản tin

Phần này mô tả định dạng của các thành phần tiêu chuẩn được sử dụng trong các định nghĩa bản tin. Đây là những đoạn dữ liệu được mô tả như là các chuỗi byte được các bản tin truyền thông tự tham chiếu. Các cấu trúc cơ bản đại diện cho các cấu trúc chung được sử dụng trong các bản tin Cl. Chúng được sử dụng là một định nghĩa trường hơn là lặp lại một định nghĩa của một cấu trúc chung.

M.3.1. Money

Money thể hiện một số lượng tiền và bao gồm loại tiền tệ và số lượng. Định dạng chung của bất kỳ giá trị tiền tệ phải được chuyển về Định dạng trong Bảng M.5.

Bảng M.5 - Cú pháp trường money

Cú pháp

...

...

...

Kiểu

money() {

currency

24

bslbf

num_of_decimals

3

uimsbf

sign

...

...

...

bslbf

decimals

20

uimsbf

}

Ngữ nghĩa dành cho cú pháp money () là:

currency: Một chuỗi 3 ký tự đại diện cho loại tiền tệ theo quy định trong tiêu chuẩn ISO 4217. Loại tiền tệ được quy định bằng 3 ký tự chữ hoa ví dụ như EUR, GBP, USD, v.v..

...

...

...

sign: Dấu của giá trị thập phân để chỉ ra giá trị dương hay âm. "0" là dương, "1" là âm.

decimals: Giá trị của loại tiền tệ này quy định là một số nguyên không dấu 20-bit. Đơn vị tiền tệ có thể được xác định bằng cách sử dụng trường num_of_decimals.

Khi trường này không được xác định thì tất cả các bit của money () phải là "1" (tức là 0xffffffffffff)

M.3.2. Time

Trường 40-bit này chứa thời gian theo UTC và MJD được quy định tại EN 300 468 [10], Phụ lục C. Định dạng chung của bất kỳ giá trị thời gian phải được chuyển về định dạng trong Bảng M.6.

Bảng M.6 - Cú pháp trường time

Cú pháp

Số bit

Kiểu

...

...

...

mjd

utc

}

16

24

uimsbf

bslbf

Ngữ nghĩa dành cho time () là:

mjd: ngày MJD 16-bit, tham khảo EN 300 468 [10], Phụ lục C.

...

...

...

Nếu thời gian không được xác định thì tất cả các bit của time phải được thiết lập là "1" (tức là 0xffffffffff).

M.3.3. Duration

Đây là một trường 24-bit chứa một thời lượng được xác định theo giờ, phút và giây. Định dạng chung của bất kỳ giá trị thời lượng phải được chuyển về định dạng trong Bảng M.7.

Bảng M.7 - Cú pháp trường duration

Cú pháp

Số bit

Kiểu

duration() {

elapsed

...

...

...

24

bslbf

Ngữ nghĩa dành cho duration () là:

elapsed: Thời lượng đã trôi qua được mã hoá BCD 4 bit gồm 6 số - nó có định dạng giống như trường utc trong date ().

Nếu thời lượng không được xác định thì tất cả các bit của trường thời lượng được thiết lập là "1" (tức là 0xffffff).

M.3.4. String

Trường chuỗi đại diện cho một chuỗi có độ dài biến đổi lên đến 255 ký tự. Định dạng chung của bất kỳ chuỗi phải được chuyển về định dạng trong Bảng M.8.

Bảng M.8 - Cú pháp trường string

Cú pháp

...

...

...

Kiểu

string() {

length

8

uimsbf

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

char

8

bslbf

...

...

...

}

Ngữ nghĩa dành cho string() là:

length: trường 8-bit này xác định độ dài theo byte của các ký tự tạo thành chuỗi văn bản.

char: Đây là một trường 8-bit. Chuỗi các trường char xác định văn bản của chuỗi. Thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10] Phụ lục A.

M.3.5. Lstring

Trường chuỗi dài đại diện cho một chuỗi có độ dài biến đổi lớn hơn 255 ký tự và thường được sử dụng dành cho một thông tin mô tả hoặc chi tiết dài. Định dạng chung của bất kỳ chuỗi dài phải được chuyển về định dạng trong bảng M.9.

Bảng M.9 - Cú pháp trường Istring

...

...

...

Số bit

Kiểu

Istring() {

length

16

uimsbf

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

char

8

...

...

...

      }

}

Ngữ nghĩa dành cho Istring() là:

length: trường 16-bit này xác định độ dài theo byte của các ký tự tạo thành chuỗi văn bản.

char: Đây là một trường 8-bit. Chuỗi các trường char xác định văn bản của chuỗi. Thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10] Phụ lục A.

M.3.6. Locator

Vị trí đại diện cho một tham chiếu DVB đến một dịch vụ hay sự kiện chương trình. Định dạng chung của bất kỳ vị trí phải được chuyển về định dạng trong Bảng M.10.

...

...

...

Cú pháp

Số bit

Kiểu

locator() {

string_indicator

if (string_flag == 1) {

...

...

...

bslbf

length

7

uimsbf

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

char

    }

...

...

...

bslbf

}

else {

tsid_indicator

1

...

...

...

sid_indicator

1

bslbf

event_indicator

1

bslbf

...

...

...

1

bslbf

num_components

3

uimsbf

original_network_id

if (tsid_indicator == 1) {

...

...

...

uimsbf

transport_stream_id

}

16

uimsbf

if (sid_indicator == 1) {

 service_id

...

...

...

16

uimsbf

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

component_tag

}

8

uimsbf

...

...

...

event_id

}

16

uimsbf

   }

}

path_segments

...

...

...

string()

Ngữ nghĩa dành cho locator () là:

string_indicator: cờ 1-bit này chỉ ra việc sử dụng một định dạng chuỗi định vị DVB khi được thiết lập là "1" và chỉ ra một định dạng trường nhị phân khi được thiết lập là "0". Trong Cl Plus thì định dạng nhị phân là định dạng truyền tải ưu tiên và trường này phải luôn luôn là "0", định dạng chuỗi chỉ được sử dụng khi không thể hiện vị trí dưới dạng nhị phân.

length: trường 7-bit này xác định độ dài theo byte của chuỗi vị trí DVB.

char: Đây là một trường 8-bit. Chuỗi các trường char xác định văn bản của chuỗi. Thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10] Phụ lục A.

tsid_indicator: cờ 1-bit này chỉ ra rằng vị trí bao gồm transport_stream_id khi được thiết lập là "1". Nếu trường này là "0" thì nhận dạng dòng truyền tải không được xác định.

sid_indicator: cờ 1 -bit này chỉ ra rằng vị trí bao gồm một service_id khi được thiết lập là "1". Nếu trường này là "0" thì nhận dạng dịch vụ không được xác định.

event_indicator: cờ 1 -bít này chỉ ra rằng vị trí bao gồm một event_id khi được thiết lập là "1". Nếu trường này là "0" thì nhận dạng sự kiện không được xác định.

num_components: cờ 3-bit này xác định số thẻ thành phần được quy định trong vị trí, nó có thể là 0 khi không có thành phần nào.

...

...

...

transport_stream_id: Đây là một trường 16-bit xác định dòng truyền tải chứa dịch vụ được chỉ ra. Trường này có thể tùy chọn bỏ qua.

service_id: Đây là một trường 16-bit xác định duy nhất một dịch vụ thông tin trong một dòng truyền tải. service_id này giống như program_number trong PMT tương ứng. Trường này có thể tùy chọn bỏ qua.

component_tag: trường 8-bit này xác định một thành phần dòng thành phần, component_tag không có thứ tự cụ thể. Trường này có thể tùy chọn bỏ qua.

event_id: trường 16-bit này chứa số nhận dạng của sự kiện chương trình được mô tả trong EIT. Trường này có thể tùy chọn bỏ qua.

path_segments: Các đoạn đường dẫn văn bản của vị trí DVB được định nghĩa trong IETF RFC 2396.

M.3.7. Pin Code

Số nhận dạng cá nhân, hoặc mã PIN, là một mã truy nhập 4 số cho phép truy nhập đến một số dịch vụ của hệ thống CA và/hoặc nội dung chương trình. Định dạng chung của mã PIN phải được chuyển về định dạng trong Bảng M.11.

Bảng M.11 - Cú pháp mã PIN

Cú pháp

...

...

...

Kiểu

pin_code()

16

uimsbf

Ngữ nghĩa dành cho pin_code () là:

pin_code: Đây là một trường 16-bit chứa mã PIN 4 số mã hóa BCD 4-bit. Khi giá trị này không xác định (tức là không được thiết lập) thì giá trị các bit của trường phải là "1" tức là 0xffff. Khi mã PIN là bí mật và không có sẵn thì giá trị của trường này phải là 0xfffe.

Ví dụ: Một mã PIN 1234 được mã hoá là 0x1234.

Ví dụ: Một pin-mã mà không được xác định được mã hoá là 0xffff.

Ví dụ: Một pin-mã được thiết lập là bí mật được mã hoá là 0xfffe.

...

...

...

Mức kiểm soát của cha mẹ mô tả mức truy nhập nội dung. Định dạng chung của trường này phải được chuyển về định dạng trong Bảng M.12.

Bảng M.12 - Cú pháp mức kiểm soát của cha mẹ

Cú pháp

Số bit

Kiểu

parental_level()

8

uimsbf

Ngữ nghĩa dành cho parental_level () là:

...

...

...

Bảng M.13 - Các giá trị mức kiểm soát của cha mẹ

Giá trị

Kiểu

Mô tả

0x00

Không áp dụng

Dự phòng để sử dụng sau

0x01

PARENTAL_CONTROL_STRICT_MODE

...

...

...

0x02

PARENTAL_CONTROL_INTERMEDIATE_MODE

Chế độ trung gian yêu cầu nhập thêm PIN để xem tất cả các sự kiện PPV được phân loại nội dung bị hạn chế và chỉ dành cho người lớn không có PIN dành cho tất cả các loại sự kiện khác.

0x03

PARENTAL_CONTROL_PERMISSIVE_MODE

Yêu cầu nhập thêm PIN để xem tất cả các sự kiện PPV được phân loại chỉ dành cho người lớn và không có PIN dành cho tất cả các loại sự kiện khác.

0x04-0x7f

Không áp dụng

Dự phòng để sử dụng sau

...

...

...

Không áp dụng

Người dùng phân loại

M.3.9. Các thuộc tính

Các thuộc tính truyền tải thông tin chung bao gồm một vòng của tên, mỗi tên là một chuỗi dữ liệu liên quan. Định dạng chung của các thuộc tính phải được chuyển về định dạng trong Bảng M.14.

Bảng M.14 - Cú pháp trường thuộc tính

Cú pháp

Số bit

Kiểu

properties() {

...

...

...

   num_properties

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

8

uimsbf

        name

*

string() Istring()

        data

...

...

...

*

}

Ngữ nghĩa dành cho properties () khối là:

num_properties: số thuộc tính được vòng thuộc tính mô tả.

name: Tên của thuộc tính.

data: Dữ liệu liên quan đến thuộc tính. Nội dung chuỗi phải được phân tích tùy theo name

...

...

...

Các loại bản tin khác nhau được xác định trong các phần sau:

M.4.1. Bản tin ATR Get Request

Yêu cầu được máy chủ gửi để truy vấn thông tin thẻ thông minh ATR. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_ATR_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên kết với yêu cầu này được thể hiện trong Bảng M.15.

Bảng M.15-Các loại dữ liệu trong bản tin ATR Get Request

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Thẻ hoặc khe cắm được truy vấn.

M.4.2. Bản tin ATR Get Response

Trả lời bản tin ATR Get Request từ CICAM đưa ra thông tin ATR của thông tin thẻ thông minh được cắm trong khe đã cho hoặc với nhận dạng đã cho. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_ATR_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong atr_get_request_message ().

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.16.

Bảng M.16 - Các loại dữ liệu trong bản tin ATR Get Response

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_data_byte()

Dữ liệu được liên kết với ATR.

M.4.3. Bản tin yêu cầu hủy bỏ

Yêu cầu được máy chủ hoặc CICAM gửi để hủy bỏ một yêu cầu với một nhận dạng trao đổi xác định, lệnh này (nếu có) phải bị hủy bỏ và lệnh này trả về trạng thái thất bại. Nếu không có yêu cầu như vậy thì CMD_CANCEL_RESPONSE phải được gửi. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_CANCEL_REQUEST

ca_system_id: Nhận dạng của hệ thống CA

transaction_id: lệnh yêu cầu/trả lời để hủy bỏ.

data_type (): Các trường loại dữ liệu liên kết với yêu cầu này được thể hiện trong Bảng M.17.

...

...

...

Nhận dạng loại dữ liệu

Mô tả

dtid_user_data()

Một hoặc nhiều trường dữ liệu riêng.

M.4.4. Bản tin trả lời hủy bỏ

Trả lời một bản tin yêu cầu hủy bỏ, trả lời hủy bỏ này chỉ được gửi đi khi không có transaction_id nào tồn tại cần phải được hủy bỏ. Ngữ nghĩa cho cú pháp CAS_response_message () là:

command_id: CMD_CANCEL_RESPONSE

ca_system_id: ca_system_id nhận được trong cancel_request_message ().

data_type (): Các trường loại dữ liệu liên kết với yêu cầu này được thể hiện trong Bảng M.18.

...

...

...

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

M.4.5. Bản tin Capabilities Request

Yêu cầu của máy chủ về thông tin chung của (các) nhà cung cấp CA và số phiên bản CA dành cho tất cả các hệ thống CA được CICAM hỗ trợ ngoài thông tin của về CICAM. CICAM phải trả lời bằng CAS_Response_Message (). Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_CAPABILITIES_REQUEST

ca_system_id: Hệ thống CA để truy vấn, giá trị 0x0000 phải trả về cho tất cả các hệ thống CA được CICAM hỗ trợ, giá trị khác không truy vấn thông tin chỉ dành cho một nhà cung cấp CA cụ thể.

data_type (): Dữ liệu này được bỏ qua và phải là không.

...

...

...

Trả lời bản tin CAS_request_message () từ CICAM đưa ra thông tin chi tiết của (các) nhà cung cấp CA và số phiên bản CA cho tất cả các hệ thống CA được CICAM hỗ trợ. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_CAPABILITIES_RESPONSE

ca_system_id: ca_system_id nhận được trong CAS_request_message ().

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.19.

Bảng M.19 - Các loại dữ liệu bản tin trả lời các khả năng

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

...

...

...

Một hoặc nhiều khối dữ liệu cung cấp thông tin chung về (các) hệ thống CA sẵn có trên CICAM. Phải sử dụng một khối đơn cho từng hệ thống CA được thiết bị hỗ trợ

dtid_cicam_information()

Khối dữ liệu đơn cung cấp thông tin về chính CICAM.

M.4.7. Bản tin History Get Request

Yêu cầu được máy chủ gửi để có được thông tin quá trình. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_HISTORY_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên kết với yêu cầu này được thể hiện trong Bảng M.20.

Bảng M.20 - Các loại dữ liệu bản tin History Get Request

...

...

...

Mô tả

dtid_history_request()

Một hoặc nhiều mục xác định quá trình được yêu cầu.

M.4.8. Bản tin History Get Response

Trả lời bản tin History Get Request từ CICAM đưa ra chi tiết thông tin sản phẩm của sự kiện. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_HISTORY_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong history_get_request_message ().

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.21.

Bảng M.21 - Các loại dữ liệu bản tin History Get Response

...

...

...

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_history()

Thông tin quá trình này có thể có nhiều mục. Các mục này phải được cung cấp theo một danh sách trong đó mục đầu tiên của danh sách phải có chỉ số là 0. Các mục này phải được cung cấp theo thứ tự phù hợp với yêu cầu ban đầu.

M.4.9. Bản tin History Set Request

Yêu cầu được máy chủ gửi để thiết lập thông tin quá trình. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_HISTORY_SET_REQUEST

...

...

...

data_type (): Các trường loại dữ liệu liên kết với yêu cầu này được thể hiện trong Bảng M.22.

Bảng M.22 - Các loại dữ liệu bản tin History Set Request

Nhận dạng loại dữ liệu

Mô tả

dtid_history ()

Một hoặc nhiều mục xác định quá trình được cập nhật, mục đầu tiên phải được trình bày có chỉ số là 0 khi danh sách đang được thay thế. Nếu trạng thái của quá trình bị xóa thì phải xóa quá trình này.

M.4.11. Bản tin History Set Response

Trả lời bản tin History Set Request từ CICAM. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_HISTORY_SET_RESPONSE

...

...

...

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.23.

Bảng M.23 - Các loại dữ liệu bản tin History Set Response

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_history()

Thông tin quá trình được sửa đổi này có thể có nhiều mục. Các mục này phải được cung cấp theo một danh sách trong đó mục đầu tiên của danh sách phải có chỉ số là 0.

M.4.11. Bản tin NotificationEnable/DisableRequest

...

...

...

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_NOTIFICATION_ENABLE_REQUEST,

CMD_NOTIFICATION_DISABLE_REQUEST

ca_system_id: Nhận dạng của hệ thống CA dành cho các sự kiện được yêu cầu.

data_type (): Không

M.4.12. Bản tin Parental Level Get Request

Yêu cầu từ máy chủ để truy vấn mức kiểm soát của cha mẹ hiện tại.

command_id: CMD_PARENTAL_LEVEL_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

...

...

...

M.4.13. Bản tin Parental Level Get Response

Trả lời từ CICAM đưa ra mức kiểm soát của cha mẹ hiện tại.

command_id: CMD_PARENTAL_LEVEL_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin Parental Level Get Request.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.24.

Bảng M.24 - Các loại dữ liệu bản tin Parental Level Get Response

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

...

...

...

dtid_parental_level()

Thông tin mức cha mẹ hiện tại được cung cấp cho hệ thống.

M.4.14. Bản tin Parental Level Set Request

Yêu cầu từ máy chủ để thay đổi mức kiểm soát của cha mẹ hiện tại.

command_id: CMD_PARENTAL_LEVEL_SET_REQUEST ca_system_id: Nhận dạng của hệ thống CA để thay đổi.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.25.

Bảng M.25 - Các loại dữ liệu bản tin Parental Level Set Request

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Mức cha mẹ mới được cung cấp cho hệ thống CA.

dtid_pin_code()

Mã PIN tùy chọn được hệ thống CA yêu cầu để xác nhận sự thay đổi mức cha mẹ khi được yêu cầu.

M.4.15. Bản tin Parental Level Set Response

Trả lời từ CICAM để thay đổi mức kiểm soát của cha mẹ.

command_id: CMD_PARENTAL_LEVEL_SET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin Parental Level Set Request

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.26.

Bảng M.26 - Các loại dữ liệu bản tin Parental Level Set Response

...

...

...

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_parental_level()

Thông tin mức cha mẹ mới được cung cấp cho hệ thống.

M.4.16. Bản tin yêu cầu kiểm tra PIN

Yêu cầu được máy chủ gửi để kiểm tra thông tin PIN. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PIN_CHECK_REQUEST

...

...

...

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.27.

Bảng M.27 - Các loại dữ liệu bản tin yêu cầu kiểm tra PIN

Nhận dạng loại dữ liệu

Mô tả

dtid_pin_information()

Thông tin PIN để kiểm tra, trường pin_code phải chứa mật khẩu để kiểm tra. Thông tin PIN không được thay đổi trong hệ thống CA.

M.4.17. Bản tin trả lời kiểm tra PIN

Trả lời bản tin yêu cầu thiết lập PIN từ CICAM đưa ra chi tiết thông tin PIN được hệ thống CA nắm giữ. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PIN_CHECK_RESPONSE

...

...

...

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.28.

Bảng M.28 - Các loại dữ liệu bản tin trả lời kiểm tra PIN

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

M.4.18. Bản tin yêu cầu nhận PIN

pin_request_message () được máy chủ gửi để truy vấn về mã PIN hiện tại được hệ thống CA nắm giữ. CICAM trả lời bằng pin_response_message () chứa thông tin mã PIN. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PIN_GET_REQUEST

...

...

...

data_type (): Dữ liệu được bỏ qua và phải là không.

M.4.19. Bản tin trả lời nhận PIN

Trả lời bản tin PIN_request_message () từ CICAM đưa ra chi tiết thông tin PIN được hệ thống CA nắm giữ. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PIN_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nhận PIN.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.29.

Bảng M.29 - Các loại dữ liệu bản tin trả lời nhận PIN

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_pin_information()

Thông tin mã PIN. Một hoặc nhiều mã PIN có thể được trả về.

M.20. Bản tin yêu cầu thiết lập PIN

Yêu cầu được máy chủ gửi để thay đổi thông tin PIN hiện tại. CAS có thể không cho phép tất cả các trường của thông tin mã PIN được sửa đổi dưới kiểm soát của ứng dụng và phải áp dụng các thay đổi cho các trường được CAS cho phép. Tức là, CAS có thể bỏ qua các thông số thiết lập trường mà nó không sẵn sàng để thay đổi dưới sự kiểm soát của ứng dụng, ứng dụng này có thể xác định trạng thái thay đổi trong bất kỳ bản tin trả lời PIN. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PIN_SET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.30.

Bảng M.30 - Các loại dữ liệu bản tin yêu cầu thiết lập PIN

...

...

...

Mô tả

dtid_pin_information()

Thông tin PIN được cập nhật phải chứa mã PIN hiện có.

dtid_pin_code()

Nếu PIN bị thay đổi thì có thể yêu cầu xác nhận PIN để cho phép thay đổi mã PIN và phải được truyền ở một khối riêng biệt.

M.21. Bản tin trả lời thiết lập PIN

Trả lời bản tin yêu cầu thiết lập PIN từ CICAM đưa ra chi tiết thông tin PIN được hệ thống CA nắm giữ. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PIN_SET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu thiết lập PIN.

...

...

...

Bảng M.31 - Các loại dữ liệu bản tin trả lời thiết lập PIN

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_pin_information()

Chứa thông tin PIN được cập nhật. Thông tin trả về phản ánh thông tin PIN hiện tại và các giá trị thiết lập trong trường có thể không phù hợp với yêu cầu ban đầu nếu hệ thống CA không cho phép cập nhật một số trường.

M.4.22. Bản tin yêu cầu dữ liệu riêng

Yêu cầu được máy chủ hoặc CICAM gửi để trao đổi thông tin riêng. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

...

...

...

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.32.

Bảng M.32 - Các loại dữ liệu bản tin yêu cầu dữ liệu riêng

Nhận dạng loại dữ liệu

Mô tả

dtid_user_data()

Một hoặc nhiều trường dữ liệu riêng.

M.4.23. Bản tin trả lời dữ liệu riêng

Trả lời bản tin yêu cầu dữ liệu riêng. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

...

...

...

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu dữ liệu riêng.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.33.

Bảng M.33 - Các loại dữ liệu bản tin trả lời dữ liệu riêng

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_user_data()

Một hoặc nhiều trường dữ liệu riêng.

...

...

...

Yêu cầu được máy chủ gửi để truy vấn thông tin sản phẩm hiện tại. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PRODUCT_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.34.

Bảng M.34 - Các loại dữ liệu bản tin Product Get Request

Nhận dạng loại dữ liệu

Mô tả

dtid_product_request()

Sản phẩm được truy vấn.

...

...

...

Trả lời bản tin Product Get Request từ CICAM đưa ra chi tiết thông tin sản phẩm của sự kiện. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PRODUCT_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin Product Get Request.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.35.

Bảng M.35 - Các loại dữ liệu bản tin Product Get Response

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

...

...

...

Dữ liệu sản phẩm, nhiều sản phẩm có thể được trả về trong một hoặc nhiều khối.

M.4.26. Bản tin yêu cầu nhận thông tin sản phẩm

Yêu cầu được máy chủ gửi để truy vấn thông tin trạng thái sản phẩm hiện tại. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PRODUCT_INFO_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.36.

Bảng M.36 - Các loại dữ liệu bản tin nhận thông tin sản phẩm

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Nhãn nhận dạng sản phẩm để truy vấn, nhiều nhãn nhận dạng sản phẩm có thể được chứa trong một yêu cầu thông tin.

M.4.27. Bản tin trả lời nhận thông tin sản phẩm

Trả lời bản tin yêu cầu nhận thông tin sản phẩm từ CICAM đưa ra chi tiết thông tin trạng thái sản phẩm của sự kiện. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_INFO_PRODUCT_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nhận thông tin sản phẩm.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.37.

Bảng M.37 - Các loại dữ liệu bản tin trả lời nhận thông tin sản phẩm

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_product_info()

Thông tin hiện tại của sản phẩm, nhiều thông tin sản phẩm có thể được trả về. Thông tin chỉ được trả về cho các sản phẩm hiện có.

M.4.28. Bản tin yêu cầu hủy bỏ mua

Yêu cầu được máy chủ gửi để hủy bỏ việc mua một sự kiện. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PURCHASE_CANCEL_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.38.

Bảng M.38 - Các loại dữ liệu bản tin hủy bỏ mua

...

...

...

Mô tả

dtid_purchase ()

Nhận dạng mục để hủy.

M.4.29. Bản tin trả lời hủy bỏ mua

Trả lời bản tin yêu cầu hủy bỏ mua từ CICAM đưa ra chi tiết thông tin sản phẩm của sự kiện. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PURCHASE_CANCEL_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu hủy bỏ mua.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.39.

Bảng M.39 - Các loại dữ liệu bản tin trả lời hủy bỏ mua

...

...

...

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_purchase()

Thông tin việc mua.

M.4.40. Bản tin yêu cầu thiết lập mua

Yêu cầu được máy chủ gửi để mua một sự kiện. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PURCHASE_SET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

...

...

...

Bảng M.40 - Các loại dữ liệu bản tin yêu cầu thiết lập mua

Nhận dạng loại dữ liệu

Mô tả

dtid_purchase ()

Nhận dạng mục để mua.

M.4.31. Bản tin trả lời thiết lập mua

Trả lời bản tin yêu cầu thiết lập mua từ CICAM đưa ra chi tiết thông tin sản phẩm của sự kiện. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PURCHASE_SET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu thiết lập mua.

...

...

...

Bảng M.41- Các loại dữ liệu bản tin trả lời thiết lập mua

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_purchase()

Dữ liệu việc mua.

dtid_product()

Dữ liệu sản phẩm liên kết với việc mua.

...

...

...

Yêu cầu được máy chủ gửi để nạp tiền. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_RECHARGE_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.42.

Bảng M.42 - Các loại dữ liệu bản tin yêu cầu nạp tiền

Nhận dạng loại dữ liệu

Mô tả

dtid_recharge ()

Thông tin yêu cầu nạp tiền.

...

...

...

Trả lời bản tin yêu cầu nạp tiền từ CICAM đưa ra chi tiết kết quả của sự kiện nạp tiền. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_RECHARGE_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nạp tiền.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.43.

Bảng M.43 - Các loại dữ liệu bản tin trả lời nạp tiền

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

...

...

...

Dữ liệu ví tiền được cập nhật

dtid_recharge()

Chứa thông tin giao dịch ban đầu, bao gồm khoản tiền nạp.

M.4.34. Bản tin yêu cầu nhận khe cắm

Yêu cầu được máy chủ gửi để truy vấn thông tin khe cắm. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_SLOT_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.44.

Bảng M.44 - Các loại dữ liệu bản tin yêu cầu nhận khe cắm

...

...

...

Mô tả

dtid_numeric_index()

Nhận dạng số của khe cắm để truy vấn. Nếu không có số thì phải hiểu là dành cho tất cả các khe cắm.

M.4.35. Bản tin trả lời nhận khe cắm

Trả lời bản tin yêu cầu nhận khe cắm từ CICAM đưa ra chi tiết thông tin khe cắm thẻ thông minh trong một khe đã cho. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_SLOT_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nhận khe cắm.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.45.

Bảng M.45 - Các loại dữ liệu bản tin trả lời nhận khe cắm

...

...

...

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_slot()

Thông tin khe cắm, có thể có nhiều khối nếu có nhiều khe cắm trong CICAM.

M.4.36. Bản tin yêu cầu nhận thẻ thông minh

Yêu cầu được máy chủ gửi để truy vấn thông tin thẻ thông minh. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_SMARTCARD_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

...

...

...

Bảng M.46 - Các loại dữ liệu bản tin yêu cầu nhận thẻ thông minh

Nhận dạng loại dữ liệu

Mô tả

dtid_smartcard_request()

Thẻ thông minh để truy vấn.

M.4.37. Bản tin trả lời nhận thẻ thông minh

Trả lời bản tin yêu cầu nhận thẻ thông minh từ CICAM đưa ra chi tiết thông tin thẻ thông minh của thẻ thông minh trong một khe cắm đã cho hay với một nhận dạng đã cho. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_SMARTCARD_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nhận thẻ thông minh.

...

...

...

Bảng M.47 - Các loại dữ liệu bản tin trả lời nhận thẻ thông minh

Nhận dạng loại dữ liệu

Mô tả

dtid_error_status()

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_smartcard()

Một hoặc nhiều khối dữ liệu chứa thông tin thẻ thông minh.

M.4.38. Bản tin yêu cầu thiết lập thẻ thông minh

Yêu cầu được máy chủ gửi để thiết lập thông tin dữ liệu người sử dụng trên thẻ thông minh. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

...

...

...

ca_system_id: Nhận dạng của hệ thống CA để thay đổi.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.48.

Bảng M.48 Các loại dữ liệu bản tin yêu cầu thiết lập thẻ thông minh

Nhận dạng loại dữ liệu

Mô tả

dtid_smartcard_request()

dtid_wallet_id()

Thẻ thông minh để truy vấn.

Nhận dạng ví tiền mới được thiết lập là ví tiền hiện tại. Nếu khối này bị bỏ qua thì ví tiền hiện tại phải giữ nguyên không thay đổi.

...

...

...

Dữ liệu của người sử dụng để ghi vào thẻ thông minh nếu dữ liệu của người sử dụng được cập nhật. Nếu khối dữ liệu này bị bỏ qua thì dữ liệu của người sử dụng phải giữ nguyên không thay đổi.

M.4.39. Bản tin trả lời thiết lập thẻ thông minh

Trả lời bản tin yêu cầu thiết lập thẻ thông minh từ CICAM đưa ra chi tiết thông tin thẻ thông minh của thẻ thông minh trong khe cắm hay với một nhận dạng đã cho. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_SMARTCARD_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu thiết lập thẻ thông minh.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.49.

Bảng M.49 - Các loại dữ liệu bản tin trả lời thiết lập thẻ thông minh

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

M.4.40. Bản tin yêu cầu nhận ví tiền

Yêu cầu được máy chủ gửi để có được thông tin ví tiền. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_WALLET_GET_REQUEST

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.50.

Bảng M.50 - Các loại dữ liệu bản tin yêu cầu nhận ví tiền

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Ví tiền để truy vấn, có thể có nhiều loại dữ liệu nhận dạng ví tiền nếu yêu cầu thông tin của nhiều ví tiền khác nhau trong yêu cầu.

M.4.41. Bản tin trả lời nhận ví tiền

Trả lời bản tin yêu cầu nhận ví tiền từ CICAM. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_WALLET_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nhận ví tiền.

data_type (): Các trường loại dữ liệu liên kết với trả lời này được thể hiện trong Bảng M.51.

Bảng M.51 - Các loại dữ liệu bản tin trả lời nhận ví tiền

Nhận dạng loại dữ liệu

Mô tả

...

...

...

Trạng thái của yêu cầu khi không thành công hoặc khi không có thông tin sẵn có, thông tin của trạng thái này có thể tùy chọn được bao gồm với trạng thái OK hoặc có thể bị bỏ qua trong trả lời và phải giả định là thành công.

dtid_wallet()

Dữ liệu ví tiền được yêu cầu, có thể có nhiều loại dữ liệu nhận dạng ví tiền nếu yêu cầu ban đầu là nhiều ví tiền. Các ví tiền phải xuất hiện theo thứ tự giống như thứ tự trong yêu cầu.

M.5. Các loại sự kiện

Các loại bản tin sự kiện khác nhau được quy định trong các phần sau, sự kiện thường khác biệt với loại bản tin yêu cầu/trả lời vì nó là không mong muốn và thường không yêu cầu có trả lời.

M.5.1. Bản tin sự kiện truy nhập

Một bản tin sự kiện từ CICAM khi có sự thay đổi truy nhập vào nội dung truyền hình, bản tin này phải được gửi không đồng bộ bất cứ khi nào trạng thái truy nhập thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền đi khi thông báo được cho phép.

Sự kiện truy nhập có thể được sử dụng để thông báo cho thiết bị thu về một trạng thái của mô-đun CA thay đổi liên quan đến việc truy nhập, khoảng thời gian giải xáo trộn và mua. Trong một số trường hợp, một sự kiện duy nhất trong hệ thống CA có thể dẫn đến nhiều CAAccessEvents được gửi đi. Ví dụ, việc mua thành công của một chương trình hiện tại có thể dẫn đến cả ACCESS_DESCRAMBLING_BEGIN và ACCESS_GRANTED

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

...

...

...

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.52.

Bảng M.52 - Các loại dữ liệu bản tin sự kiện truy nhập

Nhận dạng loại dữ liệu

Mô tả

dtid_access_event()

Trạng thái truy nhập. Nhiều sự kiện có thể được chứa trong một hoặc nhiều khối.

M.5.2. Bản tin sự kiện tín dụng

Một bản tin sự kiện từ CICAM khi có sự thay đổi về tín dụng, bản tin này phải được gửi không đồng bộ bất cứ khi nào trạng thái tín dụng mua thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép.

...

...

...

command_id: CMD_CREDIT_EVENT

ca_system_id: Nhận dạng của hệ thống CA thực hiện trách nhiệm tín dụng.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.53.

Bảng M.53: Các loại bản tin dữ liệu sự kiện tín dụng

Nhận dạng loại dữ liệu

Mô tả

dtid_credit_event()

Trạng thái tín dụng. Nhiều sự kiện có thể được chứa trong nhiều khối. Khối dữ liệu này phải xuất hiện trước bất kỳ thông tin loại dữ liệu liên kết với sự kiện.

...

...

...

Ví tiền được liên kết với sự thay đổi tín dụng.

dtid_smartcard()

Thẻ thông minh được liên kết với sự thay đổi tín dụng.

M.5.3. Bản tin sự kiện bản tin

Một bản tin sự kiện từ CICAM khi có một bản tin mới từ nhà điều hành dịch vụ, bản tin này phải được gửi không đồng bộ. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép.

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_MESSAGE_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.54.

...

...

...

Nhận dạng loại dữ liệu

Mô tả

dtid_history_event()

Trạng thái bản tin mới. Khối dữ liệu này phải xuất hiện trước bất kỳ thông tin loại dữ liệu liên kết với sự kiện.

dtid_history()

Thông tin của bản tin.

dtid_smartcard()

Thẻ thông minh được liên kết với sự kiện bản tin này.

...

...

...

Một sự kiện từ CICAM chỉ ra rằng yêu cầu nhập vào PIN, bản tin này phải được gửi không đồng bộ. Trả lời mã PIN có thể tùy chọn được trả về thẻ thông minh. Bản tin này chỉ được truyền khi thông báo được cho phép.

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PIN_REQUEST_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.55.

Bảng M.55 - Các loại dữ liệu bản tin sự kiện yêu cầu PIN

Nhận dạng loại dữ liệu

Mô tả

dtid_pin_event()

...

...

...

dtid_pin_information()

Thông tin PIN.

Bản tin trả lời yêu cầu PIN

Trả lời bản tin sự kiện yêu cầu PIN từ máy chủ đến CICAM chứa mã PIN được yêu cầu. Trả lời này có thể tùy chọn được máy chủ gửi và phải sử dụng chung một transaction_id để trả về số mã PIN. Đây là bản tin sự kiện duy nhất mà một trả lời có thể được trả về.

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PIN_RESPONSE_EVENT

ca_system_id: Nhận dạng của hệ thống CA được quy định trong bản tin sự kiện yêu cầu mã PIN.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.56.

Bảng M.56 - Các loại dữ liệu bản tin sự kiện trả lời mã PIN

...

...

...

Mô tả

dtid_pin_information()

Thông tin PIN. Một mã PIN hợp lệ phải được chứa trong trường pin_code.

M.5.6. Bản tin sự kiện dữ liệu bản tin riêng

Một sự kiện được máy chủ hoặc CICAM gửi để trao đổi thông tin riêng, không yêu cầu có xác nhận. Ngữ nghĩa dành cho cú pháp CAS_request_message () là:

command_id: CMD_PRIVATE_DATA_EVENT

ca_system_id: Nhận dạng của hệ thống CA nhận được.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.57.

Bảng M.57 - Các loại dữ liệu bản tin sự kiện dữ liệu riêng

...

...

...

Mô tả

dtid_user_data()

Một hoặc nhiều trường dữ liệu riêng.

M.5.7. Bản tin sự kiện sản phẩm

Một bản tin sự kiện từ CICAM khi có sự thay đổi về trạng thái sản phẩm, bản tin này phải được gửi không đồng bộ bất cứ khi nào trạng thái của sản phẩm thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép.

Sự kiện sản phẩm có thể được sử dụng để thông báo cho thiết bị thu về một trạng thái chương trình thay đổi liên quan đến khi bắt đầu, dừng lại và danh mục sản phẩm thay đổi.

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PRODUCT_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

...

...

...

Bảng M.58 - Các loại dữ liệu bản tin sự kiện sản phẩm

Nhận dạng loại dữ liệu

Mô tả

dtid_product_event()

Trạng thái sản phẩm. Nhiều sự kiện có thể được chứa trong một hoặc nhiều khối. Khối dữ liệu này phải xuất hiện trước bất kỳ dtid_product() được liên kết với sự kiện này.

dtid_product()

Sản phẩm được liên kết với sự kiện này. Nhiều sản phẩm có thể được chứa trong một hoặc nhiều khối. Chương trình liên quan đến dtid_product_event() cuối cùng được chứa trong trường này.

M.5.8. Bản tin sự kiện quá trình mua

Một bản tin sự kiện từ CICAM khi có sự thay đổi của quá trình mua, thông báo này được gửi phải không đồng bộ bất cứ khi nào trạng thái của quá trình này thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép.

...

...

...

command_id: CMD_PURCHASE_HISTORY_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.59.

Bảng M.59 - Các loại dữ liệu bản tin sự kiện quá trình mua

Nhận dạng loại dữ liệu

Mô tả

dtid_history_event()

Trạng thái quá trình mua. Khối dữ liệu này phải xuất hiện trước bất kỳ thông tin loại dữ liệu liên kết với sự kiện này.

dtid_history()

...

...

...

dtid_smartcard()

Thẻ thông minh được liên kết với sự kiện quá trình mua này.

M.5.9. Bản tin sự kiện nạp tiền

Một bản tin sự kiện từ CICAM chỉ ra rằng một sự kiện nạp tiền đã hoàn thành, thông báo này phải được gửi đồng bộ. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép.

Sự kiện sản phẩm CA có thể được sử dụng để thông báo cho thiết bị thu về các giao dịch nạp tiền. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_RECHARGE_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.60.

Bảng M.60: Các loại dữ liệu bản tin sự kiện nạp tiền

...

...

...

Mô tả

dtid_recharge_event()

Trạng thái nạp tiền. Khối dữ liệu này phải xuất hiện trước bất kỳ thông tin loại dữ liệu liên kết với sự kiện này.

M.5.10. Bản tin sự kiện khe cắm

Một bản tin sự kiện từ CICAM khi có sự thay đổi về trạng thái khe cắm, bản tin này phải được gửi không đồng bộ bất cứ khi nào trạng thái khe cắm thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_SLOT_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.61.

Bảng M.61 - Các loại dữ liệu bản tin sự kiện khe cắm

...

...

...

Mô tả

dtid_slot_event()

Trạng thái của khe cắm.

M.5.11. Bản tin sự kiện thẻ thông minh

Một bản tin sự kiện từ CICAM khi có sự thay đổi về trạng thái thẻ cắm, thông báo này được gửi phải không đồng bộ bất cứ khi nào trạng thái thẻ cắm thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_SMARTCARD_EVENT

ca_system_id: Nhận dạng của hệ thống CA tạo ra sự kiện này.

data_type (): Các trường loại dữ liệu liên quan đến yêu cầu này được thể hiện trong Bảng M.62.

Bảng M.62 - Các loại dữ liệu bản tin sự kiện thẻ thông minh

...

...

...

Mô tả

dtid_smartcard_event()

Trạng thái của thẻ thông minh.

dtid_smartcard()

Thẻ thông minh được liên kết với sự kiện.

M.6. Các thành phần datatype_id

Các cấu trúc datatype_id được xác định trong các phần sau:

M.6.1. Sự kiện truy nhập

Thông tin trạng thái truy nhập các dịch vụ từ hệ thống CA. Định dạng chung của dữ liệu trạng thái truy nhập phải được chuyển về định dạng trong Bảng M.63.

...

...

...

Cú pháp

Số bit

Kiểu

dtid_access_event(){

acccess_status

8

...

...

...

description

*

string()

object_id

*

string()

...

...

...

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu sự kiện dtid_access_event ():

access_status: Trạng thái truy nhập nội dung hiện tại. Các giá trị này được thể hiện trong Bảng M.64.

Bảng M.64 - Các giá trị trạng thái truy nhập

Giá trị

...

...

...

Mô tả

0x00

Không áp dụng

Dự phòng.

0x01

ACCESS_GENERIC_EVENT

Một sự kiện chưa được xác định.

0x02

ACCESS_DESCRAMBLING_BEGIN

...

...

...

0x03

ACCESS_DESCRAMBLING_END

Quá trình giải xáo trộn đã bị dừng đối với dịch vụ hiện tại.

0x04

ACCESS_FREE_WINDOW_BEGIN

Cửa sổ thời gian miễn phí dành cho sự kiện PPV hiện tại đã bắt đầu.

0x05

ACCESS_FREE_WINDOW_END

Cửa sổ thời gian miễn phí dành cho sự kiện PPV hiện tại đã kết thúc.

...

...

...

ACCESS_PURCHASE_PERIOD_BEGIN

Khoảng thời gian mua dành cho sự kiện PPV hiện tại đã bắt đầu.

0x07

ACCESS_PURCHASE_PERIOD_END

Khoảng thời gian mua dành cho sự kiện PPV hiện tại đã kết thúc.

0x08

ACCESS_GRANTED

CA được sử dụng để giải xáo trộn sự kiện PPV hiện tại.

0x09

...

...

...

CA không được sử dụng để giải xáo trộn sự kiện PPV hiện tại

0x0a

ACCESS_DENIED_FOR_PARENTAL_RATING

CA không được sử dụng để giải xáo trộn sự kiện PPV hiện tại vì mức kiểm soát của cha mẹ

0x0b

ACCESS_CARD_NEEDED

Thẻ được yêu cầu.

0x0c

ACCESS_DENIED_FOR_SMART_CARD_ERROR

...

...

...

0x0d

ACCESS_CLEAR

Tín hiệu không được xáo trộn

0x0e

ACCESS_FREE

Tín hiệu được xáo trộn trong chế độ miễn phí

0x0e-0x7f

Không áp dụng

Dự phòng.

...

...

...

Không áp dụng

Được người sử dụng xác định.

description: Mô tả văn bản tùy chọn của sự kiện.

object_id: Nhận dạng đối tượng CA tùy chọn liên quan đến sự kiện này.

private_data: dữ liệu riêng tùy chọn liên quan đến sự kiện này.

M.6.2. Dữ liệu byte

Dữ liệu byte bao gồm một chuỗi tùy ý các byte dữ liệu. Loại dữ liệu này có định dạng như trong Bảng M.65.

Bảng M.65 Cú pháp loại dữ liệu của dữ liệu byte

Cú pháp

...

...

...

Kiểu

dtid_byte_data() {

byte_data

}

*

Istring()

Ngữ nghĩa dành cho cú pháp dtid_byte_data () kiểu dữ liệu:

byte_data: Khối dữ liệu tùy ý.

M.6.3. Thông tin CAS

...

...

...

Bảng M.66 - Cú pháp loại dữ liệu thông tin hệ thống CA

Cú pháp

Số bit

Kiểu

dtid_cas_information() {

ca_system_id

...

...

...

uimsbf

name

*

string()

revision

*

string()

...

...

...

version

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_cas_infomation ():

ca_system_id: Nhận dạng hệ thống DVB CA được ETR 162 [32] quy định hay 0x0000 chỉ ra rằng bản ghi này xác định CICAM.

name: Tên của nhà cung cấp CA được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10].

...

...

...

version: Phiên bản của nhân CA, theo định dạng nhà cung cấp hệ thống CA, được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10].

M.6.4. Thông tin CICAM

dtid_cicam_information () truyền tải thông tin về CICAM. Định dạng chung trong Bảng M.67.

Bảng M.67 - Cú pháp loại dữ liệu thông tin CICAM

Cú pháp

Số bit

Kiểu

dtid_cicam_information() {

...

...

...

slot_count

4

uimsbf

reserved

4

bslbf

...

...

...

*

string()

revision

*

string()

version

*

...

...

...

serial_number

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_cicam_infomation ():

slot_count: số khe cắm thẻ thông minh được CICAM hỗ trợ.

...

...

...

name: Tên của nhà cung cấp CICAM được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10].

revision: Sửa đổi của CICAM theo định dạng xác định CICAM, được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10].

version: Phiên bản của CICAM theo định dạng CICAM, được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10].

serial_number: Số xê ri của CICAM theo định dạng CICAM, được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong EN 300 468 [10].

M.6.5. Sự kiện trạng thái tín dụng

Trang thông báo về ví tiền và tín dụng từ hệ thống CA. Định dạng chung của dữ liệu trạng thái ví tiền và tín dụng phải được chuyển về định dạng trong Bảng M.68.

Bảng M.68 - Cú pháp sự kiện trạng thái tín dụng

Cú pháp

Số bit

...

...

...

dtid_credit_event() {

       credit_status

       description

       object_id

       private_data

}

8

*

*

...

...

...

uimsbf

string()

string()

string()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_credit_event ():

credit_status: Trạng thái tín dụng được quy định trong Bảng M.69:

Bảng M.69 - Các giá trị trạng thái tín dụng

Giá trị

Kiểu

...

...

...

0x00

CREDIT_CHANGED

Tín dụng của thẻ bị thay đổi.

0x01-0x7f

Không áp dụng

Dự phòng.

0x80-0xff

Không áp dụng

Được người sử dụng xác định

...

...

...

object_id: Nhận dạng đối tượng CA tùy chọn liên quan đến sự kiện này.

private_data: dữ liệu riêng tùy chọn liên quan đến sự kiện này.

M.6.6. Trạng thái lỗi

Loại dữ liệu dtid_error_status truyền tải thông tin về một thất bại của một yêu cầu. Định dạng chung phải được chuyển về định dạng trong Bảng M.70.

Bảng M.70 - Cú pháp trường trạng thái lỗi

Cú pháp

Số bit

Kiểu

dtid_error_status() {

...

...

...

uimsbf string()

        error_code

       message

}

8

*

Ngữ nghĩa dành cho dtid_error_status () là:

error_code: Mã lỗi liên quan với yêu cầu ban đầu bị thất bại, mã lỗi phải được phân tích trong bối cảnh của yêu cầu ban đầu. Các mã lỗi được thể hiện trong Bảng M.71.

Bảng M.71 - Các giá trị mã lỗi

...

...

...

Kiểu

Mô tả

0

OK

Không lỗi.

1

PIN_REQUIRED

Mã PIN được yêu cầu (hoặc NULL PIN đã được gửi).

2

...

...

...

Nhập mã PIN không đúng.

3

CARD_BLOCKED

Thẻ thông minh bị chặn.

4

CARD_EXPIRED

Thẻ hết hạn.

5

CREDIT_LACK

...

...

...

6

CARD_REMOVED

Thẻ đã bị rút ra trong quá trình.

7

CARD_ERROR

Lỗi thẻ thông minh.

8

PURCHASE_TIME_ENDED

Khoảng thời gian để mua hết khi đang trong quá trình mua

...

...

...

ALREADY_PURCHASED

Sự kiện này đã được mua

10

CARD_MUTED

Thẻ bị cấm.

11-21

Không áp dụng

Dự phòng.

22

...

...

...

Không có thẻ thông minh trong khe cắm.

23

UNSUPPORTED_FEATURE

Tính năng không được hỗ trợ.

24

NO_OFFERS

Không có sự kiện nào hiện tại được đề xuất.

25-50

Không áp dụng

...

...

...

51

SMS_DENIAL

SMS từ chối việc nạp tiền thành công.

52

CONNECTION_ERROR

Việc nạp tiền kết thúc không thành công do lỗi kết nối.

53

INVALID_SCRATCH

Sự kiện nạp tiền kết thúc không thành công do số của thẻ cào không đúng.

...

...

...

MAXIMUM_CREDIT

Sự kiện nạp tiền kết thúc không thành công vì người sử dụng đã đạt mức tín dụng lớn nhất.

55

PARAMETER_ERROR

Sự kiện nạp tiền kết thúc không thành công vì các thông số được sử dụng trong giao dịch đã không đúng.

56-99

Không áp dụng

Dự phòng.

100

...

...

...

Lỗi chưa xác định.

101-124

Không áp dụng

Dự phòng.

125

BUSY

Hệ thống bận và không thể đáp ứng yêu cầu.

126

SYSTEM_ERROR

...

...

...

127

BAD_COMMAND

Lệnh nhận được chưa được xác định

128-255

Không áp dụng

Được người sử dụng xác định.

message: Một bản tin chuỗi tùy chọn liên quan đến mã lỗi này.

M.6.7. Quá trình

Mục quá trình trình bày việc mua trước đó của một sự kiện trả tiền, có thể là một sự kiện thuê bao hoặc sự kiện PPV. Định dạng chung của yêu cầu quá trình phải được chuyển về định dạng trong Bảng M.72.

...

...

...

Cú pháp

Số bit

Kiểu

dtid_history() {

type

8

...

...

...

id

*

string()

nid

32

uimsbf

...

...

...

1

bslbf

status

7

uimsbf

history_date

*

...

...

...

private_data

If (type == HISTORY_TYPE_PPV) {

*

Istring()

ppv_product_id

*

string()

...

...

...

ppv_order_date

ppv_item_status

*

time()

}

...

...

...

8

uimsbf

recharge_value

*

money()

...

...

...

8

recharge_transaction_id

}

...

...

...

else if (type == HISTORY_TYPE_MESSAGE) {

message_subject

*

...

...

...

*

string()

message_priority

8

Istring()

message_date

*

...

...

...

}

time()

else {

...

...

...

*

}

}

properties()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_history ():

...

...

...

Bảng M.73 - Các giá trị loại quá trình

Giá trị

Kiểu

Mô tả

0x00

HISTORY_TYPE_RESERVED

Dự phòng.

0x01

HISTORY_TYPE_PPV

...

...

...

0x02

HISTORY_TYPE_RECHARGE

Mục nạp tiền.

0x03

HISTORY_TYPE_MESSAGE

Một bản tin từ đài truyền hình.

0x04-0x7f

Không áp dụng

Dự phòng.

...

...

...

Không áp dụng

Được người sử dụng xác định.

id: Nhận dạng kiểm chuỗi của hệ thống CA liên quan đến mục quá trình, trường này là không rõ ràng và riêng đối với hệ thống CA. Đây là một chuỗi văn bản có độ dài biến đổi.

nid: Nhận dạng kiểu số của hệ thống CA liên quan đến mục quá trình để xác định nó một cách duy nhất.

cancelled: Trạng thái hủy bỏ mua, không "0" chỉ ra rằng việc mua không bị hủy bỏ, "1" chỉ ra rằng việc mua đã bị hủy.

status: Trạng thái của mục quá trình được quy định trong Bảng M.74:

Bảng M.74 Các giá trị trạng thái quá trình

Giá trị

Kiểu

...

...

...

0x00

HISTORY_STATUS_RESERVED

Dự phòng.

0x01

HISTORY_STATUS_UNREAD

Mục của quá trình chưa được đọc.

0x02

HISTORY_STATUS_READ

Mục của quá trình đã được đọc.

...

...

...

HISTORY_STATUS_DISPOSED

Mục của quá trình đã được giải quyết.

0x04-0x3e

Không áp dụng

Dự phòng.

0x3f

HISTORY_STATUS_DELETE

Xóa mục này của quá trình.

0x40-0x7f

...

...

...

Được người sử dụng xác định.

history_date: Ngày khi mục này đã được thêm vào danh sách quá trình. Điều này có thể chưa được xác định nếu hệ thống CA không kết hợp ngày này với quá trình.

private_data: dữ liệu riêng liên quan đến việc mua.

ppv_product_id: Nhận dạng sản phẩm được hệ thống CA cấp cho đã được mua. Đây là một chuỗi có độ dài biến đổi.

ppv_order_date: Ngày khi thực hiện mua.

ppv_item_status: Tình trạng hiện tại của mục của quá trình này được quy định trong Bảng M.75.

Bảng M.75 - Các giá trị trạng thái của mục sự kiện quá trình

Giá trị

Kiểu

...

...

...

0x00

ITEM_STATUS_ EVENT_SEEN

Sự kiện đã được xem.

0x01

ITEM_STATUS_

EVENT_UPCOMING

Sự kiện đã được mua và sắp tới.

0x02

ITEM_STATUS_EVENT_LOST

...

...

...

0x03

ITEM_STATUS_ EVENT_REFUNDED

Sự kiện đã được đài truyền hình trả lại tiền.

0x04-0x7f

Không áp dụng

Dự phòng.

0x80-0xff

Không áp dụng

Được người sử dụng xác định.

...

...

...

recharge_source: Nguồn gốc của việc nạp tiền được định nghĩa trong Bảng M.76:

Bảng M.76 - Các giá trị nguồn gốc nạp tiền

Giá trị

Kiểu

Mô tả

0x00

RECHARGE_SOURCE_RESERVED

Dự phòng.

0x01

...

...

...

Đài truyền hình đã nạp tiền để quảng cáo.

0x02

RECHARGE_DEBIT_CANCELLATION

Đài truyền hình đã nạp tiền để hủy khoản tiền đặt trước.

0x03

RECHARGE_REQUESTED

Người sử dụng nạp tiền (quas OTA và RC).

0x04-0x7f

Không áp dụng

...

...

...

0x80-0xff

Không áp dụng

Được người sử dụng xác định.

recharge_transaction_id: Nhãn nhận dạng duy nhất của giao dịch nạp tiền.

message_subject: chuỗi tùy chọn với chủ đề của bản tin, trường này sẽ trống nếu không có chủ đề.

message_body: văn bản của bản tin.

message_priority: mức ưu tiên của bản tin được định nghĩa trong Bảng M.77:

Bảng M.77 - Các mức ưu tiên của bản tin

Giá trị

...

...

...

Mô tả

0x00

PRIORITY_LOW

Mức ưu tiên thấp

0x01

PRIORITY_NORMAL

Mức ưu tiên trung bình

0x02

PRIORITY_HIGH

...

...

...

0x03-0x71

Không áp dụng

Dự phòng.

0x80-0xff

Không áp dụng

Được người sử dụng xác định.

message_date: Ngày khi bản tin này đã được lưu trữ ban đầu.

M.6.8. Sự kiện quá trình

Trạng thái thông báo về một sự thay đổi trong trạng thái quá trình mua hoặc sự xuất hiện của một bản tin mới từ hệ thống CA. Định dạng chung của dữ liệu trạng thái quá trình phải được chuyển về định dạng trong Bảng M.78

...

...

...

Cú pháp

Số bit

Kiểu

dtid_history_event() {

       history_status

8

uimsbf

...

...

...

*

string()

       objectjd

*

string()

       private_data

}

*

string()

...

...

...

history_status: Trạng thái của quá trình được quy định trong Bảng M.79:

Bảng M.79 - Các giá trị trạng thái thay đổi quá trình

Giá trị

Kiểu

Mô tả

0x00

PURCHASE_HISTORY_CHANGE

Danh sách mua được lưu trữ trên thẻ đã bị thay đổi.

0x01

...

...

...

Danh sách nạp tiền được lưu trữ trên thẻ đã bị thay đổi

0x02

MESSAGE_HISTORY_CHANGED

Danh sách bản tin được lưu trữ trên thẻ đã bị thay đổi

0x03-0x0f

Không áp dụng

Dự phòng.

0x10

NEW_MESSAGE

...

...

...

0x01-0x7f

Không áp dụng

Dự phòng.

0x80-0xff

Không áp dụng

Được người sử dụng xác định.

discription: Mô tả văn bản của sự kiện.

object_id: Nhận dạng chuỗi đối tượng CA liên quan đến sự kiện này.

private_data: dữ liệu riêng liên quan đến sự kiện này.

...

...

...

Yêu cầu quá trình yêu cầu thông tin quá trình từ hệ thống CA. Định dạng chung của yêu cầu mua phải được chuyển về định dạng trong Bảng M.80.

Bảng M.80 - Cú pháp trường yêu cầu quá trình

Cú pháp

Số bit

Kiểu

dtid_history_request() {

       reserved

...

...

...

bslbf

       request_type

       if (request_type == ID_HISTORY) {

4

uimsbf

            history_id

       else if (request_type == NID_HISTORY) {

*

string()

...

...

...

       }

       private_data

}

32

uimsbf

*

string()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_history_request ():

request_type: Các loại quá trình được yêu cầu theo quy định trong Bảng M.81:

...

...

...

Giá trị

Kiểu

Mô tả

0x0

ALL_HISTORY

Tất cả thông tin quá trình.

0x1

PPV_HISTORY

Quá trình của các sự kiện PPV

...

...

...

RECHARGE_HISTORY

Quá trình các lần nạp tiền.

0x3

MESSAGE_HISTORY

Quá trình tin nhắn.

0x4

ID_HISTORY

Mục quá trình có nhận dạng kiểu chuỗi được hệ thống CA xác định cấp.

0x5

...

...

...

Mục quá trình có nhận dạng kiểu số được hệ thống CA xác định cấp.

0x6-0xf

Không áp dụng

Dự phòng.

history_id: Nhận dạng chuỗi hệ thống CA được cấp cho mục của quá trình này, trường này là không rõ ràng và riêng đối với hệ thống CA. Đây là một chuỗi văn bản có độ dài biến đổi. Lưu ý rằng một mục của quá trình thường được dự kiến sử dụng một nhận dạng kiểu số CA mà không phải là một nhận dạng kiểu chuỗi CA.

history_nid: Nhận dạng kiểu số của hệ thống CA đối với một mục của quá trình, trường này là không rõ ràng và riêng đối với hệ thống CA.

private_data: dữ liệu riêng tùy chọn liên quan đến việc yêu cầu.

M.6.10. Số index

Số index xác định một mục được xác định theo kiểu số trong hệ thống CA. Loại dữ liệu này được định dạng như trong Bảng M.82.

...

...

...

Cú pháp

Số bit

Kiểu

dtid_numeric_index() {

        numeric_index

}

32

uimsbf

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_numeric_index ():

...

...

...

M.6.11. Nhận dạng đối tượng

Đối tượng này xác định nhận dạng đối tượng được hệ thống CA trả về. Loại dữ liệu này được định dạng như trong Bảng M.83.

Bảng M.83 - Cú pháp loại dữ liệu nhận dạng đối tượng

Cú pháp

Số bit

Kiểu

dtid_object_identity() {

       identity

}

...

...

...

Istring()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_object_identity ():

identity: Chuỗi nhận dạng thu được từ một đối tượng CA được phân tích trong bối cảnh của loại bản tin.

M.6.12. Mức của cha mẹ

Mức của cha mẹ truyền đạt thông tin về mức độ kiểm soát của cha mẹ hiện tại. Loại dữ liệu được định dạng như trong Bảng M.84.

Bảng M.84 - Cú pháp loại dữ liệu mức của cha mẹ

Cú pháp

Số bit

Kiểu

...

...

...

       parental_level

}

*

parental_level()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_parental_level ():

parental_level: Mức của cha mẹ.

M.6.13. Mã PIN

Mã PIN chuyển tải mã PIN được yêu cầu để thực hiện một hoạt động nào đó. Thông tin này được định dạng như trong Bảng M.85.

Bảng M.85 -Cú pháp loại dữ liệu mã PIN

...

...

...

Số bit

Kiểu

dtid_pin_code() {

       pin_code

}

*

pin_code()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_pin_code (): new_parental_level: Mức của cha mẹ được yêu cầu.

pin_code: Mã PIN được yêu cầu để thay đổi thiết lập mức của cha mẹ, cho phép cập nhật dữ liệu hoặc giải phóng một sự kiện v.v..

...

...

...

Trạng thái thông báo từ hệ thống CA yêu cầu rằng mã PIN nên được nhập vào. Định dạng chung của thông báo nhập vào PIN phải được chuyển về định dạng trong Bảng M.86.

Bảng M.86 - Cú pháp sự kiện yêu cầu PIN

Cú pháp

Số bit

Kiểu

dtid_pin_event() {

...

...

...

8

uimsbf

description

*

string()

object_id

*

...

...

...

private_data

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_pin_event ():

pin_type: Loại mã PIN được yêu cầu, các loại này giống như các loại được quy định trong dtid_pin_information () dành cho trường type được quy định trong Bảng M.87.

...

...

...

object_id: Nhận dạng đối tượng CA liên quan đến sự kiện này.

private_data: dữ liệu riêng liên quan đến sự kiện này.

M.6.15. Thông tin PIN

Mã PIN truyền tải thông tin liên quan đến PIN liên kết với hệ thống CA hoặc thẻ thông minh. Thông tin PIN truyền tải thông tin được định dạng như trong Bảng M.87.

Bảng M.87 - Cú pháp loại dữ liệu thông tin PIN

Cú pháp

Số bit

Kiểu

dtid_pin_information() {

...

...

...

id

*

string()

type

6

uimsbf

...

...

...

is_required

2

bslbf

is_validated

1

bslbf

reserved

...

...

...

bslbf

retries_remaining

4

uimsbf

pin_code

*

pin_code()

...

...

...

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_pin_infomation ():

id: Nhận dạng hệ thống CA được cấp cho thẻ thông minh này, trường này là không rõ ràng và riêng đối với hệ thống CA và xác định duy nhất PIN. Đây là một chuỗi văn bản có độ dài biến đổi.

type: Các loại mã PIN. Các giá trị được thể hiện trong Bảng M.88.

Bảng M.88 - Các giá trị loại PIN

Giá trị

Mô tả

0x00

...

...

...

0x01

Cha mẹ kiểm soát mã PIN để bảo vệ các chế độ kiểm soát của cha mẹ.

0x02

Mã PIN của thẻ thông minh bảo vệ các chức năng hệ thống CA của thẻ thông minh.

0x03

Mã PIN của quá trình để bảo vệ dữ liệu quá trình.

0x04-0x0f

Dự phòng.

0x10-0x1f

...

...

...

is_required: trường 2-bit này được ấn định khi có yêu cầu sử dụng mã PIN, bit đầu tiên là một mã khóa và để xác định khi việc truy nhập này có thể được thay đổi, bit thứ hai là trạng thái của yêu cầu mã PIN được quy định trong Bảng M.89.

Bảng M.89 - Các giá trị yêu cầu PIN

Giá trị

Mô tả

0x0

Mã PIN không được yêu cầu

0x1

Mã PIN được yêu cầu.

0x2

...

...

...

0x3

Mã PIN được yêu cầu và cho phép.

is_validated: bit duy nhất này chỉ ra nếu PIN hiện tại đã được xác nhận khi lần thiết lập lại cuối cùng. "1" chỉ ra rằng mã PIN đã được xác nhận, ngược lại là không "0"

retries_remaining: Số lần nhập vào mã PIN trước khi mã PIN bị chặn không cho tiếp tục sử dụng. Giá trị của 0xF chỉ ra rằng không bị chặn v.v.., giá trị 0x0 chỉ ra rằng mã PIN hiện đang bị chặn và không còn lại lần nhập vào lại nào.

M.6.16. Sản phẩm

Sản phẩm này xác định thông tin về một sản phẩm cụ thể. Loại dữ liệu được định dạng như trong Bảng M.30

Sản phẩm đưa ra chi tiết một mục trả tiền. Định dạng chung của bất kỳ sản phẩm nào phải được chuyển về định dạng như trong Bảng M.90.

Bảng M.90 - Cú pháp loại dữ liệu sản phẩm

Cú pháp

...

...

...

Kiểu

dtid_product() {

product_type

8

uimsbf

...

...

...

*

string()

name

*

string()

description

*

...

...

...

xdescription

*

Istring()

pw_start_time

*

time()

...

...

...

*

time()

preview

*

duration()

cost

*

...

...

...

num_contained _products

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

8

uimsbf

     contained_product_id

...

...

...

}

*

string()

if (product_type == PPT) {

     ppt_locator

...

...

...

locator()

     ppt_rating

8

uimsbf

     ppt_slice_price

*

money()

...

...

...

     ppt_slice_duration

}

else if (product_type == PPE) {

*

duration()

     ppv_locator

*

locator()

...

...

...

     ppv_rating

8

uimsbf

     ppv_start_time

*

time()

     ppv_end_time

...

...

...

time()

     ppv_num_packages

8

uimsbf

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

         ppv_package

     }

...

...

...

string()

}

else if (product_type == SUB) {

*

time()

sub_start_time

*

...

...

...

sub_end_time

16

uimsbf

sub_num_services

...

...

...

         sub_service

      }

*

locator()

}

private_data

*

Istring()

...

...

...

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_product ():

product_type: loại sản phẩm. Các loại sản phẩm được quy định trong Bảng M.91.

Bảng M.91 - Các giá trị loại sản phẩm

Giá trị

Mô tả

0x00

Dự phòng.

...

...

...

Sản phẩm chung

0x02

Sự kiện PPT.

0x03

Sự kiện PPE.

0x04

Gói PPV.

0x05

Gói SUB.

...

...

...

Dự phòng.

0x80-0xff

Được người sử dụng xác định.

id: Nhận dạng hệ thống CA được cấp cho sản phẩm, trường này là không rõ ràng và riêng đối với hệ thống CA. Đây là một chuỗi văn bản có độ dài biến đổi.

name: Tên mục của sản phẩm. Đây là một chuỗi văn bản có độ dài biến đổi.

desscription: Mô tả ngắn gọn của sản phẩm có thể lên đến 255 ký tự.

xdescription: Mô tả mở rộng của sản phẩm có thể vượt quá 255 ký tự.

pw_start_time: Thời gian bắt đầu của cửa sổ mua và ngày của mục sản phẩm được tính theo UTC. Nếu pw_start_time không áp dụng cho sản phẩm này thì trường này có thể có một giá trị không xác định.

pw_end_time: Thời gian kết thúc của cửa sổ mua và ngày của mục sản phẩm được tính theo UTC. Nếu pw_end_time không áp dụng cho sản phẩm này thì trường này có thể có một giá trị không xác định.

...

...

...

cost: Chi phí của sản phẩm, nếu sản phẩm là miễn phí thì chi phí phải được gán giá trị 0. Nếu không có chi phí được gán cho nó thì giá trị của trường này phải giá trị không xác định.

num_contained_products: Số sản phẩm được chứa trong sản phẩm này.

contained_product_id: Nhận dạng sản phẩm được chứa đựng. Chúng là những nhận dạng của các sản phẩm được chứa trong sản phẩm này.

ppt_locator: Vị trí tiền trả theo thời gian của sự kiện có loại locator ().

ppt_rating: Mức tiền trả theo thời gian của sự kiện này. Trường 8-bit này được mã hoá là trường của mức tiền trả theo thời gian của nhãn parental_rating_descriptor được xác định trong EN 300 468 [10]. Giá trị của "0" có nghĩa là mức không (0) không được xác định.

ppt_slice_price: Giá tiền trả theo thời gian đối với mỗi đoạn thời gian có loại money ().

ppt_slice_duration: Khoảng thời gian tiền trả theo thời gian đối với mỗi đoạn thời gian có loại duration ().

ppv_locator: Vị trí tiền trả theo lần xem đối với mỗi sự kiện có loại locator ().

ppv_rating: Mức trả tiền theo lần xem cho mỗi sự kiện này. Trường 8-bit này được mã hoá là trường của mức tiền trả theo lần xem của nhãn parental_rating_descriptor được xác định trong EN 300 468 [10]. Giá trị của "0" có nghĩa là mức không (0) không được xác định.

...

...

...

ppv_end_time: Thời gian kết thúc của cửa sổ mua trả tiền theo lần xem.

ppv_num_packages: Số gói tin liên quan đến sự kiện trả tiền theo lần xem.

ppv_package: Gói tin liên quan đến sự kiện trả tiền theo lần xem. Mỗi gói là một chuỗi nhận dạng hệ thống CA tham chiếu đến một sản phẩm.

sub_start_time: Ngày bắt đầu của dịch vụ thuê bao.

sub_end_time: Ngày kết thúc của dịch vụ thuê bao.

sub_num_service: Số dịch vụ bao gồm trong gói thuê bao.

sub_service: Vị trí mô tả tham chiếu của dịch vụ.

private_data: Một chuỗi các byte có thể được sử dụng dành cho dữ liệu riêng.

M.6.17. Sự kiện sản phẩm

...

...

...

Bảng M.92 - Cú pháp sự kiện sản phẩm

Cú pháp

Số bit

Kiểu

dtid_product_event() {

product_status

...

...

...

uimsbf

description

*

string()

object_id

*

string()

...

...

...

private_data

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_product_event ():

product_status: Trạng thái của sản phẩm hiện tại được quy định trong Bảng M.93:

Bảng M.93 - Các giá trị trạng thái sản phẩm

...

...

...

Kiểu

Mô tả

0x00

EVENT_END

Sự kiện PPV hiện tại tới lúc kết thúc

0x01

EVENT_STOPPED

Sự kiện PPV hiện tại bị dừng bởi người dùng (ví dụ sử dụng điều khiển từ xa).

0x02

...

...

...

Sự kiện PPV mới vừa được bắt đầu

0x03

PRODUCTS_OFFERS_LIST_CHANGE

Danh sách các sản phẩm được đặt mua đã bị thay đổi

0x04-0x7f

Không áp dụng

Dự phòng.

0x80-0xff

Không áp dụng

...

...

...

description: Mô tả văn bản tùy chọn của sự kiện này.

object_id: Một nhận dạng đối tượng CA tùy chọn liên quan đến sự kiện này.

private_data: dữ liệu riêng tùy chọn liên quan đến sự kiện này.

M.6.18. Thông tin sản phẩm

Thông tin trạng thái về sản phẩm nhận được từ hệ thống CA. Định dạng chung của thông tin sản phẩm phải được chuyển về định dạng trong Bảng M.94.

Bảng M.94 - Cú pháp trường thông tin sản phẩm

Cú pháp

Số bit

Kiểu

...

...

...

purchase_status

4

bslbf

is_current_service

1

...

...

...

reserved

3

bslbf

access_state

8

uimsbf

...

...

...

*

string()

private_data

*

Istring()

}

...

...

...

purchase_status: Trạng thái mua của sản phẩm được quy định trong Bảng M.95:

Bảng M.95 - Các giá trị trạng thái mua

Giá trị

Kiểu

Mô tả

0x0

PURCHASE_STATUS_PURCHASABLE

Sản phẩm này có thể mua được.

0x1

...

...

...

Sản phẩm này có thể không mua được vì các lí do CAS (ví dụ không có quyền truy nhập dịch vụ đang được phát)

0x2

PURCHASE_STATUS_PURCHASED

Sản phẩm này đã được mua và các quyền cụ thể nằm trên thẻ thông minh.

0x3

PURCHASE_STATUS_LOW_CREDIT

Thẻ thông minh không có đủ tín dụng để mua một sự kiện liên quan

0x4

PURCHASE_STATUS_ NO_CREDIT

...

...

...

0x5

PURCHASE_STATUS_SMART_CARD_ISSUE

Thẻ thông minh có điều kiện nào đó khiến cho sự kiện không thể được mua. Lý do này có thể thu được bằng cách sử dụng phương pháp thu thông tin trạng thái chuyên dụng của thẻ thông minh

0x6-0xf

Không áp dụng

Dự phòng.

access_status: Trạng thái truy nhập của chương trình hiện tại. Các giá trị được thể hiện trong Bảng M.64.

is_current_service: Cờ 1-bit chỉ ra khi đây là dịch vụ đang được phát mà thiết bị thu đang dò kênh đến. Trường này là "1" nếu dịch vụ này là hiện tại và là "0" khi nó không phải là dịch vụ hiện tại.

product_id: Nhận dạng sản phẩm được hệ thống CA cấp cho đã được mua. Đây là một chuỗi có độ dài biến đổi.

...

...

...

M.6.19. Yêu cầu sản phẩm

Yêu cầu sản phẩm yêu cầu thông tin sản phẩm từ hệ thống CA. Định dạng chung của yêu cầu sản phẩm phải được chuyển về định dạng như trong Bảng M.96.

Bảng M.96 - Cú pháp trường yêu cầu sản phẩm

Cú pháp

Số bit

Kiểu

dtid_product_request() {

...

...

...

3

bslbf

     request_qualifier

2

uimsbf

     type

     if (request_qualifier == PRODUCT_ID) {

3

uimsbf

...

...

...

     } else if (request_qualifier == PRODUCT_LOCATOR) {

*

string()

          locator

     }

*

locator()

...

...

...

*

Istring()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_product_request ():

request_qualifier: Đánh giá thông tin được yêu cầu được quy định trong Bảng M.97:

Bảng M.97 - Các giá trị đánh giá yêu cầu sản phẩm

Giá trị

...

...

...

Mô tả

0x0

PRODUCT_NONE

Không quy định việc đánh giá.

0x1

PRODUCT_ID

Yêu cầu (các) sản phẩm có product_id đã cho.

0x2

PRODUCT_LOCATOR

...

...

...

0x3

Không áp dụng

Dự phòng.

type: Loại sản phẩm yêu cầu được quy định trong Bảng M.98. Khi request_qualifier là một nhận dạng thì loại phải là ALL_PRODUCT.

Bảng M.98 - Các giá trị loại yêu cầu sản phẩm

Giá trị

Kiểu

Mô tả

0x0

...

...

...

Yêu cầu tất cả các sản phẩm

0x1

CURRENT_PRODUCT

Yêu cầu (các) sản phẩm của sự kiện hiện tại.

0x2

NEXT_PRODUCT

Yêu cầu (các) sản phẩm của sự kiện kế tiếp.

0x3

OFFERED_PRODUCT

...

...

...

0x4-0x7

Không áp dụng

Dự phòng.

product_id: Nhận dạng hệ thống CA được cấp cho sản phẩm, trường này là không rõ ràng và riêng đối với hệ thống CA. Đây là một chuỗi văn bản có độ dài biến đổi.

locator: Vị trí DVB của dịch vụ này để truy vấn.

private_data: Các dữ liệu riêng liên quan đến việc mua.

M.6.20. Mua

Mua thể hiện việc mua của một sự kiện trả tiền, là một sự kiện thuê bao hoặc PPV. Định dạng chung của yêu cầu mua này phải được chuyển về định dạng trong Bảng M.99.

Bảng M.99 - Cú pháp trường mua

...

...

...

Số bit

Kiểu

dtid_purchase() {

id

*

string()

...

...

...

product_id

* 1

string()

cancelled

7

bslbf

reserved

...

...

...

bslbf Istring()

private_data

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_purchase ():

...

...

...

product_id: Nhận dạng sản phẩm được hệ thống CA cấp cho đã được mua. Đây là một chuỗi có độ dài biến đổi.

cancelles: Việc mua đã bị hủy bỏ.

private_data: Các dữ liệu riêng liên quan đến việc mua.

M.6.21. Nạp tiền

Nạp tiền yêu cầu nạp tiền tín dụng từ hệ thống CA. Định dạng chung của bản tin nạp tiền phải được chuyển về định dạng trong Bảng M.100.

Bảng M.100 - Cú pháp trường Recharge

Cú pháp

Số bit

Kiểu

...

...

...

4

bslbf

reserved

4

uimsbf

request_type

*

...

...

...

phone

*

string()

user

*

string()

...

...

...

*

string()

ip_address

*

string()

port

...

...

...

if (request_type == CREDIT_CARD_MODE) {

surname

*

string()

...

...

...

*

string()

card_number

*

string()

start_date

16

...

...

...

expiry_date

16

bslbf

value

*

money()

...

...

...

recharge_value

*

money()

transaction

*

Istring()

...

...

...

private_data

*

Istring()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_recharge ():

request_type: Loại nạp tiền được yêu cầu được quy định trong Bảng M.101:

Bảng M.101 - Các giá trị loại yêu cầu

...

...

...

Kiểu

Mô tả

0x0

Không áp dụng

Dự phòng

0x1

CREDIT_CARD_MODE

Yêu cầu nạp tiền sử dụng thẻ tín dụng

0x2

...

...

...

Yêu cầu nạp tiền sử dụng thẻ cào

0x3-0xf

Không áp dụng

Dự phòng.

phone: Số điện thoại để gọi.

user: Tên của người sử dụng để đăng nhập

password: mật khẩu được người sử dụng cung cấp để đăng nhập.

ip_address: Địa chỉ IP của máy tính chủ, được quy định là một chuỗi ký tự số thập phân với một ký tự chấm (.) phân định dải địa chỉ.

port: Số cổng của máy tính chủ, được quy định là một chuỗi ký tự số thập phân.

...

...

...

name: Tên riêng chủ thẻ tín dụng hoặc chữ cái đầu viết tắt.

card_number: số thẻ tín dụng, được quy định là một chuỗi ký tự số thập phân không có khoảng trống.

start_date: Ngày bắt đầu sử dụng của thẻ tín dụng được thể hiện theo MJD, hãy tham khảo định nghĩa trường time ().

expiry_date: Ngày hết hạn sử dụng của thẻ tín dụng thể hiện theo MJD, hãy tham khảo định nghĩa trường time ().

value: Giá trị nạp tiền được yêu cầu.

recharge_value: Lượng tiền nạp, trường này phải chưa được xác định khi tạo yêu cầu.

gtransaction: thông tin giao dịch bổ sung có thể được tùy chọn cung cấp thông tin.

private_data: dữ liệu riêng bổ sung.

M.6.22. Sự kiện nạp tiền

...

...

...

Bảng M.102 - Cú pháp sự kiện nạp tiền

Cú pháp

Số bit

Kiểu

dtid_recharge_event() {

recharge_status

...

...

...

uimsbf

description

*

string()

object_id

*

string()

...

...

...

value

*

money()

private_data

*

string()

}

...

...

...

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_recharge_event ():

recharge_status: Trạng thái nạp tiền, các giá trị được quy định trong Bảng M.76

description: Mô tả văn bản tùy chọn của sự kiện

value: Giá trị của sự kiện nạp tiền.

object_id: Một tùy chọn nhận dạng đối tượng CA liên quan đến sự kiện này.

private_data: dữ liệu riêng tùy chọn liên quan đến sự kiện này.

M.6.23. Id của dịch vụ

Id của dịch vụ bao gồm một vị trí để xác định dịch vụ này. Loại dữ liệu được định dạng như trong Bảng M.103.

Bảng M.103 - Cú pháp loại dữ liệu nhận dạng dịch vụ

...

...

...

Số bit

Kiểu

dtid_servicejd() {

       service_locator

}

*

locator()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_service_id ():

service_locator: Một vị trí để xác định dịch vụ này.

...

...

...

Khe cắm xác định trạng thái của một khe cắm thẻ thông minh trong hệ thống này. Loại dữ liệu được định dạng như trong Bảng M.104.

Bảng M.104 - Cú pháp loại dữ liệu khe cắm

Cú pháp

Số bit

Kiểu

dtid_slot() {

...

...

...

8

uimsbf

slot_status

8

uimsbf

}

...

...

...

slot_id: Số nhận dạng của khe bắt đầu từ 0.

slot_status: Trạng thái của một khe cắm thẻ thông minh. Các giá trị được thể hiện trong Bảng M.105.

Bảng M.105 - Các giá trị trạng thái khe cắm

Giá trị

Kiểu

Mô tả

0x00

SLOT_STATUS_RESERVED

Dự phòng.

...

...

...

SLOT_STATUS_CARD_IN

Thẻ hiện có trong khe cắm.

0x02

SLOT_STATUS_CARD_OUT

Thẻ không có trong khe cắm.

0x03

SLOT_STATUS_CARD_ERROR

Thẻ thông minh được cắm vào đầu đọc nhưng nhận được ATR không đúng (ví dụ vì thẻ bị hư hỏng).

0x04

...

...

...

Thẻ thông minh được cắm vào đầu đọc nhưng không nhận được ATR vì không có kết nối điện được thiết lập với thẻ thông minh (ví dụ cắm thẻ sai mặt).

0x05

SLOT_STATUS_ACCESS_DENIED

Truy nhập thẻ đang trong khe cắm bị từ chối, thẻ chưa được kích hoạt dịch vụ và CAS

0x06

SLOT_STATUS_ VERIFYING

Thẻ thông minh trong khe cắm và đang được kiểm tra

0x07

SLOT_STATUS_UNKNOWN

...

...

...

0x08-0x7f

Không áp dụng

Dự phòng.

0x80-0xff

Không áp dụng

Được người sử dụng xác định.

M.6.25. Sự kiện khe cắm

Trạng thái thông báo về một sự kiện thẻ thông minh từ hệ thống CA. Định dạng chung của dữ liệu sự kiện khe cắm phải được chuyển về định dạng trong Bảng M.106.

Bảng M.106 - Cú pháp sự kiện khe cắm

...

...

...

Số bit

Kiểu

dtid_slot_event() {

slot_status

8

uimsbf

...

...

...

slot_id

8

uimsbf

description

*

string()

object_id

...

...

...

string()

private_data

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_slot_event ():

...

...

...

slot_id: Số nhận dạng của khe cắm bắt đầu từ 0.

description: Mô tả văn bản tùy chọn của sự kiện này.

value: Giá trị của sự kiện nạp tiền.

object_id: Một tùy chọn nhận dạng đối tượng CA liên quan đến sự kiện này.

private_data: dữ liệu riêng tùy chọn liên quan đến sự kiện này.

Thẻ thông minh

Thẻ thông minh truyền tải thông tin liên quan đến khe cắm thẻ thông minh trong hệ thống này. Loại dữ liệu được định dạng như trong Bảng M.107.

Bảng M.107 - Cú pháp loại dữ liệu thẻ thông minh

Cú pháp

...

...

...

Kiểu

dtid_smartcard() {

id

*

string()

...

...

...

8

uimsbf

slot_id

8

uimsbf

expiry_date

*

...

...

...

id_number

*

string()

version

*

string()

...

...

...

*

string()

service_provider_name

*

string()

user_data

*

...

...

...

num_pin_codes

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

8

uimsbf

pin_id

}

num_wallets

...

...

...

string()

8

uimsbf

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

wallet_id

...

...

...

current_wallet

*

string()

*

string()

additional_info

...

...

...

properties()

private_data

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_smartcard ():

...

...

...

status: giá trị 8-bit này biểu thị trạng thái hiện tại của thẻ thông minh. Các giá trị được thể hiện trong Bảng M.108.

Bảng M.108 - Các giá trị trạng thái thẻ thông minh

Giá trị

Kiểu

Mô tả

0x00

SCS_VALID

Thông báo thẻ thông minh hợp lệ. Giá trị này cũng được trả về khi việc kiểm tra thẻ thông minh được thực hiện

0x01

...

...

...

Thông báo thẻ thông minh không hợp lệ. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này cũng có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x02

SCS_EXPIRED

Thông báo thẻ thông minh hết hạn. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này cũng có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x03

SCS_BLACKLISTED

Thông báo thẻ thông minh bị đưa vào danh sách đen. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này cũng có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x04

SCS_SUSPENDED

...

...

...

0x05

SCS_NEVER_PAIRED

Thông báo thẻ thông minh chưa từng kết hợp với thiết bị thu. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này cũng có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x06

SCS_NOT_PAIRED

Thông báo rằng thẻ thông minh không thực sự kết hợp được với thiết bị thu. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này cũng có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x07

SCS_NOT_CERTIFIED

Thông báo thẻ thông minh chưa được xác nhận. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

...

...

...

SCS_MEMORY_FULL

Thông báo thẻ thông minh bị đầy bộ nhớ. Giá trị này có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x09

SCS_GENERIC_CARD_ERROR

Thông báo có lỗi không xác định với thẻ thông minh. Khi ở trạng thái này, thẻ thông minh sẽ không thể thực hiện bất kì hoạt động gì. Giá trị này có thể được trả về khi việc kiểm tra thẻ thông minh được thực hiện.

0x0a

SCS_PIN_CHANGED

Thông báo PIN của thẻ thông minh bị thay đổi (ví dụ để có thông báo khi việc thiết lập lại bằng SMS)

0x0b-0x7f

...

...

...

Dự phòng.

0x80-0xff

Không áp dụng

Được người sử dụng xác định.

slot_id: Nhận dạng của khe cắm, trong đó thẻ được đặt vào.

expiry_date: Ngày hết hạn sử dụng của thẻ nếu không có ngày hết hạn sử dụng thì trường này có thể là giá trị không xác định.

id_number: Số nhận dạng thẻ thông minh. Đây là một chuỗi có độ dài biến đổi.

version: Số phiên bản của thẻ thông minh, được trả về là một chuỗi có định dạng của hệ thống CA cụ thể.

provider_name: Tên của nhà cung cấp thẻ thông minh (thường giống như tên nhà cung cấp CA).

...

...

...

user_data: Trường dữ liệu của người sử dụng được lưu trữ trên thẻ. Định dạng của dữ liệu tuân theo hệ thống CA cụ thể.

num_pin_codes: một số 8-bit của PIN có sẵn trên thẻ.

pin_id: Nhận dạng hệ thống CA của mã PIN.

num_wallets: Trường 8-bit này cho biết số ví tiền có sẵn trên thẻ thông minh. Trường này có thể là không nếu không có ví tiền nào.

wallet_id: Nhận dạng hệ thống CA của ví tiền được lưu trữ trên thẻ thông minh.

current_wallet_id: Nhận dạng hệ thống CA của ví tiền hiện tại. Trường này có thể là một chuỗi có độ dài là không nếu không có ví tiền hiện tại.

additional_info: Thông tin bổ sung có sẵn trên thẻ thông minh, nó có thể bao gồm các số phiên bản và thông tin nhận dạng bổ sung.

private_data: dữ liệu riêng tùy chọn liên quan đến đối tượng này.

M.6.27. Sự kiện thẻ thông minh

...

...

...

Bảng M.109 - Cú pháp sự kiện thẻ thông minh

Cú pháp

Số bit

Kiểu

dtid_smartcard_event() {

smartcard_status

...

...

...

uimsbf

description

*

string()

object_id

*

string()

...

...

...

private_data

*

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_smartcard_event ():

smartcard_status: Trạng thái thẻ thông minh, các giá trị được quy định trong Bảng M.108.

description: Mô tả văn bản tùy chọn của sự kiện.

...

...

...

private_data: dữ liệu riêng tùy chọn liên quan đến sự kiện này.

M.6.28. Yêu cầu thẻ thông minh

Yêu cầu thẻ thông minh yêu cầu thông tin về thẻ thông minh từ hệ thống CA. Định dạng chung của yêu cầu thẻ thông minh phải được chuyển về định dạng trong Bảng M.110.

Bảng M.110 - Cú pháp trường yêu cầu thẻ thông minh

Cú pháp

Số bit

Kiểu

dtid_smartcard_request() {

...

...

...

reserved

6

bslbf

request_qualifier

2

uimsbf

...

...

...

if (request_qualifier == SMARTCARD_ID) {

smartcard_id

*

string()

} else if (request_qualifier == SMARTCARD_SLOT) {

slot_id

...

...

...

8

uimsbf

}

private_data

...

...

...

string()

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_smartcard_request ():

request_qualifier: Đánh giá thông tin được yêu cầu được quy định trong Bảng M.111:

Bảng M.111 - Các giá trị đánh giá yêu cầu

Giá trị

...

...

...

Mô tả

0x0

SMARTCARD_ALL

Tất cả thông tin của thẻ thông minh.

0x1

SMARTCARD_ID

Thẻ thông minh được nhãn nhận dạng CA xác định.

0x2

SMARTCARD_SLOT

...

...

...

0x3

Không áp dụng

Dự phòng.

smartcard_id: Nhận dạng của thẻ thông minh được hệ thống CA cấp cho

slot_id: Nhận dạng của khe cắm chứa thẻ thông minh bắt đầu từ số 0

private_data: dữ liệu riêng tùy chọn liên quan đến việc yêu cầu.

M.6.29. Dữ liệu của người sử dụng

Dữ liệu của người sử dụng bao gồm một chuỗi tùy ý của các byte dữ liệu. Loại dữ liệu được định dạng như trong Bảng M.112.

Bảng M.112 - Cú pháp loại dữ liệu người sử dụng

...

...

...

Số bit

Kiểu

dtid_user_data() { byte_data

}

*

Istring()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_user_data ():

byte_data: Một khối dữ liệu tùy ý.

M.6.30. Ví tiền

...

...

...

Bảng M.113 - Cú pháp trường Wallet

Cú pháp

Số bit

Kiểu

dtid_wallet() {

product_type

...

...

...

uimsbf

id

*

string()

name

*

string()

...

...

...

balance

*

money()

expiry_date

*

time()

transaction_count

...

...

...

uimsbf

transaction_remain

8

uimsbf

}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_wallet ():

...

...

...

name: Tên liên kết với ví tiền này. Đây là một chuỗi có độ dài biến đổi.

balance: Số tiền dư trong ví tiền.

Eexpiry_date: Ngày hết hạn sử dụng của ví tiền, khi không có ngày hết hạn sử dụng thì giá trị dữ liệu này phải được thiết lập là một giá trị không xác định.

transaction_count: Số giao dịch đã được thực hiện đối với ví tiền này. Giá trị của 0xffff chỉ ra rằng số giao dịch không xác định.

transaction_remain: Ước tính về số giao dịch còn lại có thể được mua. Giá trị của 0xff chỉ ra rằng không có ước tính nào.

M.6.31. Nhận dạng ví tiền

Nhận dạng ví tiền xác định tên của một ví tiền. Loại dữ liệu được định dạng như trong Bảng M.114.

Bảng M.114 - Cú pháp loại dữ liệu nhận dạng ví tiền

Cú pháp

...

...

...

Kiểu

dtid_wallet_id() {

      wallet_id

}

*

string()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_wallet_id ():

wallet_id: Nhận dạng hệ thống CA dành cho ví tiền này.

M.7. Ánh xạ MHP API

...

...

...

Bảng M.115-Ánh xạ bản tin MHP API

Lớp

Phương pháp

Ánh xạ bản tin

CAManagerFactory

SessionOpener() SessionCloser()

openSession() closeSession() AccessDeniedException

M.2.1 Session Establishment 

APDU

...

...

...

APDU

open_session_response()

APDU

close_session_request()

APDU

close_session_response() 

APDU

SAS_connect_rqst() 

APDU

...

...

...

CAManager

getCAProvider() getCARevision() getCAVersion() getSlots()

CMD_CAPABILITIES_REQUEST

CAManager

getCurrentProducts()

getNextProducts()

CMD_PRODUCT_GET_REQUEST

CAManager

...

...

...

CMD_PARENTAL_LEVEL_GET_REQUEST

CAManager

setParentalControlLevel()

CMD_PARENTAL_LEVEL_SET_REQUEST

CAManager

getPins()

CMD_PIN_GET_REQUEST

PIN

setRequired() reset() change()

...

...

...

PIN

check()

CMD_PIN_CHECK_REQUEST

PIN

isRequired()

getRetriesRemaining()

isValidated()

Xem CAManager::getPins()

Khe cắm

...

...

...

CMD_SLOT_GET_REQUEST

Khe cắm

getSmartCard()

CMD_SMARTCARD_GET_REQUEST

Thẻ thông minh

getATR()

CMD_ATR_GET_REQUEST

Thẻ thông minh

getExpiryDate() getMorelnfo() getNumber() getPins() getProvider() getServiceProviderName() getStatus() getUsedWallet() getUserData() getVersion() getWallets()

...

...

...

Thẻ thông minh

setUserData() setUsedWallet()

CMD_SMARTCARD_SET_REQUEST

CAAcessEvent

CAAdapter() getType()

CMD_ACCESS_EVENT

CAProductEvent

CAProductEvent

CMD_PRODUCT_EVENT

...

...

...

CMD_CREDIT_EVENT

NewMessageEvent

CMD_MESSAGE_EVENT

HistoryUpdateEvent

CMD_PURCHASE_HISTORY_EVENT

PinRequestEvent

...

...

...

CMD_PIN_REQUEST_EVENT

RechargeEvent

CMD_RECHARGE_EVENT

SlotEvent

CMD_SLOT_EVENT

SmartCardEvent

...

...

...

ppv.Product

getld() getPrivateData() getType() getName() getDescription() getExtendedDescription() getPurchaseWindowStartTime()

getPurchaseWindowEndTime() getContainedProducts() getPrice() isFree() getPreviewTime()

CMD PRODUCT_GET_REQUEST

PPVEvent

getRating() getLocator() getPackages()

getStartTime() getEndTime() isFree() getType()

CMD PRODUCT_GET_REQUEST

PPTEvent

...

...

...

CMD PRODUCT_GET_REQUEST

PPVPackage

isFree() getType()

CMD PRODUCT_GET_REQUEST

Subscription

getSubscriptionStart()

getSubscriptionEnd()

getServices()

isFree() getType()

...

...

...

request

BuyRequest()

CMD_PURCHASE_SET_REQUEST

request.CARequest

cancel()

CMD_PURCHASE_CANCEL_REQUEST

request.CARequest

setPrivateData()

CMD_PURCHASE_SET_REQUEST

...

...

...

isCancelled() getPrivateDate()

CMD_PURCHASE_SET_REQUEST

HistoryRequest

getHistoryLength() getltem() getltems() getPrivateData() isCancelled()

CMD_HISTORY_GET_REQUEST

HistoryRequest

setltems() setPrivateData() cancel()

CMD_HISTORY_SET_REQUEST

BuyResponseEvent

...

...

...

CMD_PURCHASE_SET_RESPONSE

FailureResponseEvent

FailureResponseEvent()

getErrorCode()

CMD_*_RESPONSE

HistoryResponseEvent

HistoryResponseEvent()

getHistory()

CMD_HISTORY_GET_RESPONSE

...

...

...

HistoryUpdateRequest()

getHistory()

CMD_HISTORY_SET_REQUEST

HistoryUpdateResponseEv

HistoryUpdateResponseEvent()

CMD_HISTORY_SET_RESPONSE

ProductlnfoRequest

ProductlnfoRequest()

getProduct()

...

...

...

CMD_PRODUCT_INFO_GET_RESPONSE

RcRechargeRequest

RcRechargeRequest()

getRcParameter()

CMD_RECHARGE_REQUEST

RcRechargeResponse

RcRechargeResponse() getRechargeValue() getWallet

CMD_RECHARGE_RESPONSE

R.Offered Products

...

...

...

CMP_PRODUCT_GET_REQUEST

OfferedProductsResponse

OfferedProductsResponseEvent() getProducts()

CMP_PRODUCT_GET_RESPONSE

Phụ lục N

(quy định)

Hồ sơ truyền hình CICAM

Phụ lục này mô tả hồ sơ truyền hình giả được tạo ra bằng tài nguyên hồ sơ nhà điều hành phải được máy chủ Cl Plus hỗ trợ và tùy chọn được CICAM hỗ trợ. Việc hỗ trợ tài nguyên hồ sơ nhà điều hành và hỗ trợ các yêu cầu hồ sơ truyền hình được thiết lập trong phụ lục này là một bắt buộc đối với một máy chủ Cl Plus.

...

...

...

Phần này mô tả thông tin dịch vụ (SI) được máy chủ quy định và phân tích một cách tối thiểu.

N.1.1. Cl Plus tin Descriptors

Các nhãn mô tả riêng được một thiết bị máy chủ Cl Plus xác nhận được tóm tắt trong bảng N.1. Tất cả các nhãn mô tả riêng Cl Plus chỉ được phân tích trong bối cảnh của giá trị quy định dữ liệu riêng Cl Plus.

Bảng N.1 - Các nhãn mô tả riêng Cl Plus

Nhãn mô tả

Thẻ

Mô tả

ci_protection_descriptor

0xce

...

...

...

ciplus_content_label_descriptor

0xcb

Nhãn văn bản của nhãn mô tả nội dung có thể áp dụng cho mạng

ciplus_service_descriptor

0xcc

Tên và loại dịch vụ.

N.1.2. CICAM NIT

CICAM NIT _thực gẫn tĩnh duy nhất phải được phổ biến cho tất cả các bộ ghép kênh của mạng. Nó phải đưa ra chi tiết các thông số truyền dẫn của các bộ ghép kênh trong mạng và có thể được CICAM tạo ra bằng cách sử dụng thông tin nhà điều hành dịch vụ cụ thể. Một phiên bản mới của CICAM NIT phải được truyền đến máy chủ trong một trong các trường hợp sau đây:

• Một bộ ghép kênh mới được thêm vào hoặc gỡ khỏi mạng.

...

...

...

• Khi bản sắp xếp dịch vụ thay đổi.

• Khi các thuộc tính của mạng bị thay đổi (bao gồm các nhãn văn bản).

Số phiên bản NIT có thể không thay đổi mà không thay đổi tải tức là một CICAM tạo ra NIT thực từ các bảng truyền hình khác không được cập nhật NIT khi một phiên bản của bảng truyền hình thay đổi nếu sự thay đổi này không làm thay đổi tải NIT. Số phiên bản NIT phải luôn luôn được cập nhật khi có bất kỳ sự thay đổi tải NIT bằng cách tăng trường version_number.

CICAM NIT là một định nghĩa đầy đủ khép kín của bảng sắp xếp dịch vụ hồ sơ nhà điều hành. Máy chủ phải tạo danh sách kênh từ thông tin hoàn toàn thu được từ CICAM NIT, việc quét hoặc giám sát bất kỳ phần nào của SI truyền hình để tạo ra và duy trì danh sách kênh không bắt buộc đối với máy chủ.

Việc sử dụng các nhãn mô tả trong NIT phải tuân theo đúng như Bảng N.2, các nhãn mô tả khác có thể được bỏ qua nếu không được máy chủ biết đến. Phạm vi của tất cả các mô tả riêng phải được máy chủ giữ nguyên.

Bảng N.2 - Các nhãn mô tả CICAM NIT

Nhãn mô tả NIT

Giá trị thẻ

Vòng

...

...

...

Khác

Ghi chú

*_delivery_system_descriptor

*

2^nd

Mb/Mr

Không áp dụng

Các nhãn mô tả hệ thống cung cấp được các giao diện mạng của máy chủ hỗ trợ phải được hỗ trợ. Các nhãn mô tả hệ thống cung cấp không được máy chủ hỗ trợ phải bị bỏ qua.

ciplus_content_label_descriptor

...

...

...

1^st

Ob/Or

Không áp dụng

Phải được đặt trước bằng một nhãn xác định dữ liệu riêng Cl Plus.

ciplus_service_descriptor

0xcc

2^nd

Mb/Mr

Không áp dụng

...

...

...

linkage_descriptor

0x4a

1^st

Ob/Mr

Không áp dụng

Máy chủ phải phân tích và sử dụng dịch vụ linkage_type 0x02 EPG.

linkage_descriptor

0x4a

1^st

...

...

...

Không áp dụng

Thông tin DVB-SSU với linkage_type 0x09 và 0x0A.

network_name_descriptor

0x40

1^st

Ob/Or

Không áp dụng

Profile_name của operator_info() APDU phải được sử dụng ưu tiên hơn bất kì tên mạng nào xuất hiện trong NIT.

private_data_specifier_descriptor

...

...

...

1^st/2^nd

Ob/Mr

Không áp dụng

Giá trị của nhãn xác định dữ liệu riêng Cl Plus phải được tất cả các máy chủ công nhận và phải đứng trước bất kỳ các nhãn mô tả riêng Cl Plus.

image_icon_descriptor

0x7f/0x00

1^st

Ob/Or

Không áp dụng

...

...

...

CHÚ THÍCH: Mb - Bắt buộc truyền; Ob-Tùy chọn truyền; Mr- Bắt buộc thu; Or-Tùy chọn thu.

CICAM phải truyền thông tin liên kết DVB-SSU trong CICAM NIT bằng tín hiệu DVB-SSU phù hợp bằng cách sử dụng linkage_descriptor với linkage_type là 0x09 và 0x0A. Điều này có thể yêu cầu CICAM tạo ra tín hiệu chính xác từ một NIT hoặc BAT truyền hình.

N.1.2.1. system_delivery_descriptor

system_delivery_descriptor, được quy định trong ETSI EN 300 468 [10], phù hợp với mạng phải được bao gồm trong vòng thứ hai của CICAM NIT và phải mô tả hoàn toàn vị trí của bộ ghép kênh.

N.1.2.2. linkage_descriptor

linkage_descriptor với thẻ 0x4a, được quy định trong ETSIEN 300 468 [10], có thể tùy chọn có mặt trong vòng đầu tiêu của NIT với linkage_type 0x02 (dịch vụ EPG). Liên kết này phải chỉ ra sự có mặt của bất kỳ dịch vụ quảng cáo Hướng dẫn chương trình điện tử (EPG) và phải được máy chủ phân tích khi EPG được gọi.

Nhãn mô tả liên hệ khác có thể có mặt trong CICAM NIT. Yêu cầu CICAM truyền mô tả tất cả các nhãn mô tả DVB-SSU đến máy chủ.

N.1.2.3. ciplus_service_descriptor

Nhãn mô tả dịch vụ Cl Plus cung cấp các tên của các nhà cung cấp dịch vụ và dịch vụ này dưới dạng văn bản cùng với service_type và thông tin kênh logic. Nhãn mô tả này phải được sử dụng trong vòng thứ hai của NIT, một nhãn mô tả phải có mặt dành cho mỗi dịch vụ được bao gồm trong danh sách kênh logic. Nhãn mô tả này chỉ được phân tích trong bối cảnh của một quy định dữ liệu riêng Cl Plus.

...

...

...

Dữ liệu trong nhãn mô tả này phải xem là gần như tĩnh và phải được sử dụng để xác định các dịch vụ trong danh sách dịch vụ hoặc danh sách kênh của máy chủ. Một dịch vụ có thể được gán cho nhiều hơn một số kênh logic có nghĩa là dịch vụ giống nhau có thể được xác định để xuất hiện nhiều lần trong một danh sách kênh với một số kênh logic khác nhau, trạng thái khả năng hiển thị khác nhau và tên khác nhau.

CICAM phải đảm bảo rằng tất cả các dịch vụ có thể được lựa chọn được gán cho một số kênh logic duy nhất, điều này yêu cầu CICAM lựa chọn một thứ tự dịch vụ có đánh số trong trường hợp việc đánh số kênh logic không được mạng cấp. Điều này có thể dựa trên thứ tự chữ cái của các kênh v.v.. để xác định thứ tự và để đánh số. Việc cấp phát số kênh logic cho bất kỳ dịch vụ nào dành cho các dịch vụ được đánh nhãn không chính xác là không bắt buộc đối với máy chủ và các dịch vụ xung đột phải bị loại bỏ.

Bảng N.3 - Cú pháp ciplus_service_descriptor

Cú pháp

Số bit

Kiểu

ciplus_service_descriptor(){

...

...

...

descriptor_tag

8

uimsbf

descriptor_length

8

uimsbf

service_id

...

...

...

uimsbf

service_type

8

uimsbf

visible_service_flag

1

bslbf

...

...

...

selectable_service_flag

1

bslbf

logical_channel_number

14

uimsbf

service_provider_name_length

...

...

...

uimsbf

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

     char

8

uimsbf

...

...

...

}

service_name_length

8

uimsbf

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

8

...

...

...

char

}

}

...

...

...

descriptor_tag: trường 8-bit này phải được gán giá trị 0xcc và chỉ được phân tích trong bối cảnh của một nhãn mô tả quy định dữ liệu riêng Cl Plus.

service_id: Đây là một trường 16-bit xác định dịch vụ từ bất kỳ dịch vụ khác trong dòng truyền tải. service_id này giống như program_number trong program_map_table tương ứng.

service_type: Đây là một trường 8-bit xác định loại của dịch vụ này. Nó phải được mã hóa phù hợp với trường service_type của service_descriptor được định nghĩa trong ETSI EN 300 468 [10].

visible_service_flag: Trường 1 -bit này khi được thiết lập là "1" thì chỉ ra rằng dịch vụ này là bình thường có thể nhìn thấy thông qua dịch vụ hoặc danh sách kênh và EPG của máy chủ v.v.. Khi được thiết lập là "0" thì chỉ ra rằng thiết bị thu không được dự kiến để cung cấp dịch vụ này cho người sử dụng trong các chế độ chuyển hướng bình thường nhưng thiết bị thu phải cung cấp một cơ chế để truy nhập các dịch vụ này bằng cách nhập trực tiếp số kênh logic, tùy thuộc vào thiết lập của trường selectable_service_flag.

selectable_service_flag: trường 1-bit này chỉ được phân tích khi trường visible_service_flag được thiết lập là "0". Khi thiết lập là "1" thì chỉ ra rằng dịch vụ ẩn này có thể lựa chọn bằng cách nhập trực tiếp số kênh logic, khi được thiết lập là "0" thì dịch vụ ẩn này không được người sử dụng lựa chọn trực tiếp (nhưng có thể được lựa chọn bằng LCN từ một môi trường ứng dụng).

logical_channel_number: trường 14-bit này chỉ ra số kênh logic được gán cho dịch vụ này, tuy nhiên chỉ cho phép số kênh có 4 số từ 0 đến 9999. Giá trị 0x3fff chỉ ra rằng dịch vụ không có sẵn để lựa chọn và phải được ẩn nhưng được giữ lại trong danh sách kênh máy chủ. Dịch vụ tương tự này có thể được phân bổ cho nhiều hơn một số kênh logic và phải xuất hiện tại nhiều vị trí trong danh sách dịch vụ này. Các số kênh logic phải là duy nhất trong mạng tức là số kênh logic chỉ được sử dụng một lần duy nhất (ngoại trừ 0x3fff).

Hành vi của máy chủ đối với các số kênh logic lớn hơn 9999 chưa được xác định và có thể bị loại bỏ. Trường hợp các dịch vụ được gán số kênh logic giống nhau thì máy chủ phải giữ lại một dịch vụ và loại bỏ những dịch vụ khác.

service_provider_name_length: trường 8-bit này xác định số byte tiếp theo trường service_provider_name_length để mô tả các ký tự của tên nhà cung cấp dịch vụ.

char: Đây là một trường 8-bit. Trường chuỗi ký tự quy định tên của nhà cung cấp dịch vụ hoặc dịch vụ. Thông tin văn bản này được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được mô tả trong ETSI EN 300 468 [10], Phụ lục A kết hợp với operator_info () APDU.

...

...

...

N.1.2.4. ciplus_content_label_descriptor

Nhãn mô tả nhãn nội dung Cl Plus được sử dụng trong vòng nhãn mô tả đầu tiên của NIT và cung cấp một nhãn văn bản mới dành cho trường content_byte content_descriptor (0x54) ETSI EN 300 468 [10]. Nhãn mô tả này cho phép các nhãn văn bản mặc định kết hợp với thể loại của sự kiện chương trình được sửa đổi trong bối cảnh mạng. Nhiều trường hợp của nhãn mô tả được cho phép trong vòng này có thể xuất hiện theo thứ tự content_byte bất kỳ. Nhiều trường hợp của nhãn văn bản tương tự dành cho một dải giống nhau có thể tồn tại cùng với một phân cấp ngôn ngữ khác nhau. Các nhãn văn bản liên kết với một dải giá trị content_byte bằng một chuỗi văn bản.

Khi xử lý content_descriptor thì content_byte được so sánh với dải hoạt động của nhãn mô tả nhãn nội dung, nếu content_byte phù hợp với dải này thì nhãn văn bản này được sử dụng. Trường hợp nhiều nhãn phù hợp content_byte thì nhãn nội dung có dải nội dung phù hợp nhỏ nhất phải được lựa chọn ưu tiên hơn bất kỳ nhãn nào khác có dải nội dung phù hợp lớn hơn. Nếu không có nhãn nào của CICAM NIT phù hợp với một giá trị content_byte thì các nhãn văn bản DVB content_descriptor được gán mặc định được sử dụng. Tức là một nhãn cụ thể được cấp cho một dải hẹp của các giá trị content_byte trong khi nhóm thể loại chung có một dải rộng hơn các giá trị content_byte.

Tham khảo: Việc xử lý của máy chủ tương đương với việc lập lại thứ tự một cách hiệu quả các nhãn văn bản để đánh giá bằng các nhãn có dải hẹp trước bất kỳ các nhãn khác có dải rộng hơn và nhãn nội dung được tìm kiếm từ trên xuống dưới cho tới khi tìm thấy sự phù hợp. Ví dụ:

0x67-0x67 Dance music

// Tạo một nhãn mới

0x65-0x65 Opera

// Chồng lên nhãn hiện có

0x60-0x6f Music

...

...

...

// trong cùng dải

Bảng N.4 - Cú pháp ciplus_content_label_descriptor

Cú pháp

Số bit

Kiểu

ciplus_content_label_descriptor(){

...

...

...

8

uimsbf

     descriptor_length

8

uimsbf

     content_byte_min

8

uimsbf

content_byte max

...

...

...

uimsbf

ISO_639_language_code

24

bslbf

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

       label_char

8

...

...

...

     }

}

Trong đó các trường được quy định như sau:

descriptor_tag: Trường này 8-bit phải được gán giá trị 0xcb và chỉ được phân tích trong bối cảnh của một nhãn mô tả quy định dữ liệu riêng Cl Plus.

content_byte_min/max: Các trường 8-bit này xác định dải lớn nhất và nhỏ nhất của giá trị trường content_descriptor content_byte. Giá trị này nên phù hợp nếu nhãn này nên được sử dụng dành cho content_byte này. Các giá trị này là các giá trị bao hàm và được so sánh như sau:

If ((content_byte> = content_byte_min) && (content_byte <= content_byte_max))

then //Sử dụng nhãn nội dung này.

...

...

...

ISO_639_language_code: trường 24-bit này xác định mã ngôn ngữ của nhãn nội dung này.

Iabel_char: Đây là một trường 8-bit, một chuỗi các trường "char" quy định nhãn văn bản của content_byte. Thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được xác định trong ETSI EN 300 468 [10], Phụ lục A.

N.1.3. SDT

Trong một môi trường định hình (profile_type = 1) thì tất cả các thông tin loại và tên dịch vụ tĩnh thu được từ CICAM NIT chứ không phải từ SDT truyền hình, service_descriptor () của SDT truyền hình phải bị bỏ qua.

SDT _thực được cơ chế ngăn chặn của máy chủ sử dụng, ngoài ra SDT thực có thể được sử dụng dành cho thông tin trạng thái chạy dịch vụ có thời gian chạy. Các bảng SDT khác chỉ được tin cậy khi trường sdt_other_trusted của operator_info () APDU được thiết lập là "1".

Việc phân tích một cách tối thiểu của các nhãn mô tả trong SDT được một máy chủ Cl Plus với một CICAM NIT xử lý phải tuân theo Bảng N.5.

Bảng N.5 - Các nhãn mô tả SDT Cl Plus được phân tích một cách tối thiểu

Nhãn mô tả SDT

Giá trị thẻ

...

...

...

Khác

Gần tĩnh

Ghi chú

ci_protection_descriptor

0xce

Ob/Mr

Ob/Or

Có

Phải đứng trước bằng một nhãn xác định dữ liệu riêng

...

...

...

0x5f

Ob/Mr

Ob/Or

Không

Đứng trước nhãn mô tả ci_protection

CHÚ THÍCH: Mb - Bắt buộc truyền; Ob-Tùy chọn truyền; Mr - Bắt buộc thu; Or-Tùy chọn thu.

running_state trong SDT này có thể được máy chủ phân tích nếu trường operator_info () APDU sdt_running_status_trusted được thiết lập là "1" và máy chủ có thể tùy chọn chỉ ra cho người sử dụng rằng dịch vụ này không có sẵn khi dịch vụ này không được chạy.

N.1.4. EIT

EIT _p/f và EIT _sch có thể có mặt dành cho mỗi dịch vụ để cung cấp thông tin về các sự kiện hiện tại, tiếp theo và lập lịch. Máy chủ phải có khả năng xử lý mạnh SDT :: EIT_present_following_flag và

...

...

...

Trường hợp linkage_descriptor chứa linkage_type 0x02 có mặt trong vòng đầu tiên của CICAM NIT thì máy chủ phải có được thông tin EIT _sch từ các kênh quảng cáo bằng cách dò kênh đến bộ ghép kênh được xác định trong linkage_descriptor khi được yêu cầu thiết trong bất kỳ Hướng dẫn chương trình điện tử (EPG).

running_state của EIT này có thể được máy chủ phân tích nếu trường operator_info () APDU eit_running_status_usage được thiết lập là "1" và máy chủ có thể tùy chọn chỉ ra cho người sử dụng rằng dịch vụ này không có sẵn khi dịch vụ được thông báo là không chạy hoặc tạm dừng.

N.1.4.1. Cung cấp EIT

Hướng dẫn chương trình điện tử (EPG) của một máy chủ Cl Plus được bắt nguồn từ thông tin truyền hình EIT _sch trên mạng, hoạt động này của mạng có thể được đánh giá bằng thông tin gợi ý chương trình EIT operator_info ciplus () APDU. EIT _sch có thể được bảo vệ trong mạng truyền hình bằng cách xáo trộn các phần bảng EIT. EIT _p/f không được bị xáo trộn. Trường hợp các bảng EIT _sch bị xáo trộn trên một kênh quảng cáo thì các hướng dẫn trong ETSI TR 101 211 phải được tuân thủ và dịch vụ phải có thể sử dụng một PMT với service_id là 0xffff. PMT phải chứa một dòng thành phần của các phần riêng với một hoặc nhiều CA_descriptor để xác định CAS liên kết. Máy chủ phải truyền dịch vụ EIT trong ca_pmt () khi việc giải xáo trộn là bắt buộc. Vị trí của kênh quảng cáo phải được xác định bằng một linkage_descriptor có linkage_type là 0x02 và hoạt động dò kênh là bắt buộc đối với máy chủ để di chuyển sang dịch vụ EPG. Mạng này nên chứa một dịch vụ mô tả dịch vụ EPG này (dịch vụ này có thể được ẩn).

Trường hợp các bảng EIT _sch bị xáo trộn và truyền qua các bộ ghép kênh của mạng thì việc giải xáo trộn phải được hoạt động như sau:

• CICAM có thể tùy chọn tự động giải mã các bảng EIT _sch cho một máy chủ được Cl Plus xác thực, điều này yêu cầu không có thêm tín hiệu thông báo trong PMT.

• PMT phải bao gồm một dòng thành phần có stream_type là 0x05 có chứa các phần riêng ISO/IEC 13818-1 dành elementary _PID = 0x0012. Vòng elementary_stream phải chứa một hoặc nhiều CA_descriptor để xác định các dòng CA liên kết và máy chủ phải truyền dòng thành phần này cho CICAM trong một yêu cầu ca_pmt () với bất kỳ các thành phần dòng thành phần khác yêu cầu được giải xáo trộn.

N.2. Hành vi định hình

Phần này mô tả hành vi của mạng CICAM (profile_type = 1)

...

...

...

Danh sách kênh logic dành cho một CICAM định hình được tổ chức thành một danh sách kênh riêng biệt (sandbox) của các số kênh được xác định bằng profile_name của operator_info () APDU. Danh sách kênh logic phải được giới hạn nghiêm ngặt đối với các dịch vụ được nhà điều hành dịch vụ quy định bằng cách sử dụng ciplus_service_descriptor () trong vòng thứ hai của CICAM NIT. Các dịch vụ bổ sung có thể không được thêm vào danh sách kênh của hồ sơ cụ thể. Thiết bị thu của máy chủ có thể tạo các danh sách kênh khác (tức là các danh sách yêu thích) dưới sự kiểm soát của người sử dụng.

N.2.2. Đánh số kênh logic

Các dịch vụ được cung cấp với CICAM NIT phải được dán nhãn và đánh số theo ciplus_service_descriptor. CICAM phải đảm bảo rằng một số kênh logic chỉ được phân bổ một lần cho một dịch vụ tức là các số kênh logic là duy nhất. Một dịch vụ có thể được gán cho nhiều số kênh logic và dịch vụ được gán này phải xuất hiện nhiều lần trong danh sách kênh logic với một số kênh logic khác nhau.

Các dịch vụ bị ẩn có thể lựa chọn không được xuất hiện trong danh sách kênh này nhưng có thể được lựa chọn bằng cách nhập trực tiếp số kênh logic và phải được trình bày.

Các dịch vụ bị ẩn không lựa chọn không được xuất hiện trong danh sách kênh và chỉ có thể được một môi trường ứng dụng lựa chọn (mà ứng dụng này được máy chủ hỗ trợ).

Trong các mạng không có bất kỳ phân cấp kênh logic thì CICAM phải xác định thứ tự kênh có nghĩa là thứ tự mạng, chữ cái đầu, v.v.. và gán các số kênh logic. Các dịch vụ đặc biệt không được gán một cách rõ ràng một phân cấp kênh logic phải sử dụng giá trị 0x3fff được sử dụng để ẩn một dịch vụ ví dụ như một dịch vụ tải về phần mềm đặc biệt. Bất kỳ dịch vụ bị ẩn đặc biệt dành cho tải về S/W và tương tự phải được bao gồm trong danh sách kênh logic để bộ ghép kênh của chúng có thể truy nhập vào CICAM thông qua lệnh tune () kiểm soát máy chủ.

Các dịch vụ được nhà điều hành dịch vụ gán một số kênh logic, thông qua CICAM NIT, có thể không bị người sử dụng đánh số lại trong trường hợp danh sách kênh logic của nhà điều hành dịch vụ.

CICAM phải quản lý việc phân cấp số kênh logic thông qua CICAM NIT và phải xem xét service_type được máy chủ hỗ trợ (tức là SD hay HD) và các dịch vụ theo khu vực dựa vào vị trí của thiết bị thu. Các phương pháp này được CICAM sử dụng để xác định vị trí khu vực và bảng sắp xếp dịch vụ theo khu vực nằm ngoài phạm vi của tiêu chuẩn này và tùy thuộc vào nhà điều hành.

N.2.3. Các loại dịch vụ

...

...

...

CICAM phải đảm bảo rằng danh sách dịch vụ này được tạo ra dựa trên các quy tắc của nhà điều hành dịch vụ và xem xét các khả năng service_type được máy chủ hỗ trợ.

Máy chủ gặp một loại dịch vụ không xác định vẫn phải hoạt động và phải cung cấp một chỉ dẫn cho người sử dụng rằng dịch vụ này không được hỗ trợ ví dụ như "Dịch vụ này không được hỗ trợ xin vui lòng liên hệ với nhà điều hành dịch vụ của bạn để biết thêm thông tin"

N.2.4. Cập nhật mạng

Những thay đổi trong mạng xảy ra trong CICAM NIT phải được máy chủ xử lý trong vòng 24 giờ kể từ khi có thông báo thay đổi trong khi máy chủ đang hoạt động trong danh sách kênh định hình này. Máy chủ có thể tự động cập nhật danh sách kênh này hoặc tối thiểu là thông báo cho người sử dụng rằng đã có một sự thay đổi trong mạng, để cung cấp một cơ chế hướng dẫn thao tác để cập nhật máy chủ.

N.2.5. Các chuỗi văn bản

CICAM phải giám sát host_language APDU để xác định ngôn ngữ của máy chủ, một thay đổi trong ngôn ngữ của máy chủ có thể yêu cầu CICAM cập nhật CICAM NIT bằng các chuỗi văn bản mới phù hợp với ngôn ngữ mà máy chủ ưa thích.

THƯ MỤC TÀI LIỆU THAM KHẢO

[1] Cl PlusTM Specification v1.3.2: Cl Plus Specification - Content Security Extensions to the Common lnterface.(Đặc tả kỹ thuật về giao diện dùng chung mở rộng - Các mở rộng bảo mật nội dung cho giao diện dùng chung).

...

...

...