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Ố – YÊU CẦU KỸ THUẬT ĐỐI VỚI GIAO DIỆN CHUNG MỞ RỘNG (CI PLUS)

Hiệu lực: Còn hiệu lực

TIÊU CHUẨN QUỐC GIA

TCVN 11819:2017

KHỐI TRUY NHẬP CÓ ĐIỀU KIỆN DÙNG TRONG TRUYỀN HÌNH KỸ THUẬT SỐ – YÊU CẦU KỸ THUẬT ĐỐI VỚI GIAO DIỆN CHUNG MỞ RỘNG (CI PLUS)

Conditional access module for digital television – Technical requirements for common interface plus (CI PLUS)

MỤC LỤC

1 Phạm vi áp dụng

2 Tài liệu viện dẫn

3 Định nghĩa, ký hiệu và chữ viết tắt

3.1 Định nghĩa

3.2 Ký hiệu

3.3 Chữ viết tắt

4 Tổng quan hệ thống

4.1 Giới thiệu

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

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

4.4 Xác thực thiết bị

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

4.6 MMI nâng cao

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

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

5.1 Kiến trúc

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

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

5.4 Triển khai mô-đun

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

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

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

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

5.9. Tổng quan xác thực

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

5.12. Ghi và phát lại

5.13. Cung cấp SRM

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

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

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

6.3. Xác thực lại khi bật nguồn điện

7. Kênh được xác thực an toàn

7.1. Hoạt động Cl SAC

7.2. Định dạng của bản tin SAC

7.3. Truyền các bản tin SAC

7.4. Nhận các bản tin SAC

7.5. Tích hợp SAC vào Cl Plus

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

9. Chi tiết về chứng nhận và PKI

9.1. Giới thiệu

9.2. Kiến trúc quản lý chứng nhận

9.3. Định dạng giấy chứng nhận

9.4. Kiểm tra giấy chứng nhận

10. Ngăn chặn dịch vụ của máy chủ

10.1. Thông báo dịch vụ được Cl Plus bảo vệ

10.2. Tiếp nhận tin cậy

10.3. Chế độ dịch vụ được Cl Plus bảo vệ

10.4. Ngăn chặn dịch vụ

11. Giao diện lệnh

11.1. Tài nguyên thông tin ứng dụng

11.2. Tài nguyên ngôn ngữ và quốc gia của máy chủ

11.3. Tài nguyên kiểm soát nội dung

11.4. Hỗ trợ ứng dụng cụ thể

12. MMI cấp ứng dụng Cl Plus

12.4. Phạm vi

12.2. Hồ Sơ MMI ứng dụng

12.3. Mã hóa nội dung dữ liệu

12.4. Mẫu đồ họa của công cụ

13. Tài nguyên giao diện người – máy của Cl Plus

13.3. Kết hợp các tài nguyên MMI

13.4. Trình đơn CICAM

14. Các phần mở rộng Cl khác

14.2. Phần mở rộng truyền IP tốc độ thấp

14.3. Tải về phần mềm và tài nguyên nâng cấp CAM

14.4. Tài nguyên MMI ứng dụng

14.5. Tài nguyên MMI ứng dụng v2

14.6. Tài nguyên kiểm soát máy chủ DVB

14.7. Hồ sơ nhà điều hành

Phụ lục A (quy định) Bộ tạo số ngẫu nhiên

A.1. Định nghĩa bộ tạo số ngẫu nhiên

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ị

Phụ lục C (quy định) Các thuật toán kiểm tra tổng

C.1. Các thuật toán kiểm tra tổng

Phụ lục D (quy định) Các khả năng SD và HD

D.1. Định nghĩa SD và HD

Phụ lục E (quy định) Kiểm tra các trường hợp sử dụng DVB-CI

E1. Khởi tạo

E.2. CA_PMT rõ ràng

E.3. CA_PMT rõ ràng sang bị xáo trộn /bị xáo trộn sang rõ ràng

E.4. Cập nhật PMT và CA_PMT mới

E.5. MMI tức thời

E.6. Dòng truyền tải đến CICAM

E.7. Trả lời về hồ sơ

E.8. Hoạt động trên một bus dùng chung

E.9. Kích thước APDU tối đa

E.10. Tài nguyên kiểm soát máy chủ

E.11. Trả lời CA-PMT

E.12. Tài nguyên CC và CP

E.13. Các yêu cầu vật lý

E.14. Đối tượng Comms Reply truyền tốc độ thấp

E.15. Mã hóa đối tượng văn bản MMI cấp cao

E.16. Đối tượng dò kênh kiểm soát máy chủ DVB

E.17. Hỗ trợ truy nhập có điều kiện

E.18. Xử lý phiên bản tài nguyên

E.19. Yêu cầu mở phiên

E.20. Cung cấp CA PMT

E.21. Đánh giá của CICAM về các CA_descriptor

E.22. Hành vi đóng phiên hỗ trợ CA

E.23. Các lệnh ca_pmt

E.24. open_session_response

E.25. Mã hóa ký tự

Phụ lục F (quy định) Định nghĩa và xử lý mã lỗi

F.1. Các mã lỗi

Phụ lục G (quy định) Tối ưu PCMCIA

G.1. Kích thước bộ đệm

G.2. Chế độ ngắt

G.3. Xác định khả năng tương thích Cl Plus

Phụ lục H (quy định) Bản quy định kỹ thuật chứng nhận

H.1. Các thông số được trao đổi trong các APDU

Phụ lục I (quy định) Sử dụng PKCS # 1

l.1. Các đóng dấu RSA theo PKCS # 1

Phụ lục J (quy định) Định dạng độ dài thẻ

J.1. Định dạng độ dài thẻ

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

Phụ lục L (quy định) Tóm tắt tài nguyên

L.1. ID tài nguyên

L.2. Tóm tắt tài nguyên

Phụ lục M (quy định) Định dạng bản tin ứng dụng MHP

M.1. Giới thiệu

M.2. Định dạng bản tin

M.3. Các thành phần bản tin

M.4. Các loại bản tin

M.5. Các loại sự kiện

M.6. Các thành phần datatype_id

M. 7. Ánh xạ MHP API

Phụ lục N (quy định) Hồ sơ truyền hình CICAM

N.1. Thông tin dịch vụ

N.2. Hành vi định hình

Lời nói đầu

TCVN 11819:2017 được xây dựng trên cơ sở tham khảo tiêu chuẩn Cl Plus™ Specification v1.3.2.

TCVN 11819:2017 do Viện Khoa học Kỹ thuật Bưu Điện biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

KHỐI TRUY NHẬP CÓ ĐIỀU KIỆN DÙNG TRONG TRUYỀN HÌNH KỸ THUẬT SỐ – YÊU CẦU KỸ THUẬT ĐỐI VỚI GIAO DIỆN CHUNG MỞ RỘNG (Cl PLUS)

Conditional Access Module for Digital Television – Technical requirements for Common Interface plus (Cl Plus)

1 Phạm vi áp dụng

Tiêu chuẩn này giải quyết các vấn đề về bảo vệ nội dung sau khi gỡ bỏ bảo vệ truy nhập có điều kiện, đặc biệt tại vị trí nội dung rời khỏi CICAM và trở lại máy chủ. Đây là các vấn đề mà các nhà cung cấp dịch vụ, nhà khai thác CA và chủ sở hữu nội dung luôn quan tâm, lo ngại. Để loại bỏ những lo ngại này, cần phải có một hệ thống kiểm soát nội dung mạnh mẽ và hiệu quả để bảo vệ nội dung tại vị trí này.

Tiêu chuẩn này mô tả một hệ thống bao gồm tất cả các quy tắc để xác thực, tạo khóa và chuyển tiếp thông tin kiểm soát sao chép. Phạm vi của hệ thống này là kết nối từ CICAM đến máy chủ, nó không liên quan đến một hệ thống CA cụ thể hay hệ thống CA mở rộng bên ngoài máy chủ. Phạm vi này không giới hạn ở một loại giao diện cụ thể nào, tuy nhiên hiện tại vẫn phổ biến sử dụng khe cắm PCMCIA, những vấn đề có thể phát sinh từ việc sử dụng giao diện khác chưa được xác định hoặc giải quyết trong tiêu chuẩn này.

Các cơ chế được xác định trong tiêu chuẩn này được gọi là giao diện chung mở rộng hoặc Cl Plus. Tiêu chuẩn này dựa trên và mở rộng từ các tiêu chuẩn Cl hiện có như EN 50221 [7] và TS 101 699 [8].

Để đảm bảo an ninh tối đa trong một môi trường tiềm ẩn nhiều hành động xâm hại hệ thống, tiêu chuẩn này sử dụng một tập hợp các kỹ thuật đã được thiết lập, đã được ngành công nghiệp chấp nhận và xác nhận, bao gồm cả mã hóa và xác thực thiết bị và bản tin.

Việc xác thực giữa CICAM và máy chủ sẽ xác nhận với CICAM rằng nó đang hoạt động với một máy chủ hợp pháp. Điều này cũng đồng nghĩa với việc máy chủ đang hoạt động với một CICAM hợp pháp.

Tiêu chuẩn này sử dụng các mã khóa mật dùng chung, được cả CICAM và máy chủ tính toán một cách độc lập, và thông tin đi qua giao diện chung đảm bảo một thiết bị thứ ba không đủ để tính toán ra mã khóa này. Quá trình này sử dụng những phương pháp thiết lập, thử và kiểm nghiệm mà hiện tại chúng chưa có điểm yếu cụ thể nào.

Tiêu chuẩn này chỉ áp dụng đối với việc tiếp nhận các dịch vụ được điều khiển bởi một hệ thống truy nhập có điều kiện và đã được các nhà cung cấp dịch vụ xáo trộn. Dịch vụ không được điều khiển bởi một hệ thống truy nhập có điều kiện nằm ngoài phạm vi của tiêu chuẩn này.

Tiêu chuẩn này được sử dụng kết hợp với quy trình cấp giấy chứng nhận phù hợp và phải dựa trên sự tuân thủ của nhà sản xuất đối với Các nguyên tắc Cl Plus bền vững [6] do Cơ quan cấp giấy chứng nhận kiểm soát.

Tiêu chuẩn này cũng cung cấp một danh sách các khuyến nghị để làm rõ hơn các tiêu chuẩn DVB-CI.

2 Tài liệu viện dẫn

Tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả sửa đổi, bổ sung (nếu có).

RSA PKCS#1 v2.1: June 14, 2002. RSA Cryptography Standard, RSA security inc. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf. RSA PKCS # 1 v2.1:14 tháng Sáu 2002. Tiêu chuẩn mã RSA, Công ty an ninh RSA. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

FIPS PUB 46-3: October 25, 1999. National Institute of Standards and Technology, Data Encryption Standard (DES). http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf. FIPS PUB 46-3: 25 tháng 10 năm 1999. Viện Tiêu chuẩn và Công nghệ quốc gia, Tiêu chuẩn mã dữ liệu (DES). http://csrc.nist.gov/publications/fips/fips46-3/fips46- 3.pdf

FIPS PUB 180-3: October 2008. Secure Hash Signature Standard, NIST. http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf . FIPS PUB 180-3: Tháng Mười năm 2008. Tiêu chuẩn đóng dấu mã băm an ninh, NIST. http://csrc.nist.gov/publications/fips/fips180- 3/fìps180-3_final.pdf

FIPS PUB 197: November 26, 2001. Specification for the Advanced Encryption Standard (AES), National Institute of Standards and Technology, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

SCTE 41:2004. POD copy protection system. Society of Cable Telecommunications Engineers. Http://www.scte.org/documents/pdf/ANSISCTE412004.pdf. SCTE 41: 2004. Hệ thống bảo vệ sao chép POD. Hiệp hội kỹ thuật cáp viễn thông. http://www.scte.org/documents/pdf/ANSISCTE412004.pdf

Cl Plus Device Interim License Agreement http://www.ci-plus.com. Thỏa thuận cấp phép tạm thời thiết bị Cl Plus, http://www.ci-plus.com

CENELEC EN 50221: February, 1997. Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications, http://pda.etsi.org/pda/queryform.asp . CENELEC EN 50221: Tháng Hai, 1997. Bản quy định kỹ thuật giao diện chung dành cho truy nhập có điều kiện và các ứng dụng của bộ giải mã truyền hình kỹ thuật số khác, http://pda.etsi.org/pda/queryform.asp

ETSI TS 101 699 V1.1.1: November, 1999. Digital Video Broadcasting (DVB); Extensions to the Common Interface Specification Http://pda.etsi.org/pda/queryform.asp. ETSI TS 101 699 V1.1.1: Tháng Mười Một, 1999. Truyền hình kỹ thuật số (DVB); Phần mở rộng của bản quy định kỹ thuật giao diện chung. http://pda.etsi.org/pda/queryform.asp

ETSI TS 101 812: August 2006. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3. http://pda.etsi.org/pda/queryform.asp. ETSI TS 101 812: Tháng Tám năm 2006 Truyền hình kỹ thuật số; Nền tảng nhà ở đa phương tiện (MHP) Bản quy định kỹ thuật 1.0.3. http://pda.etsi.org/pda/queryform.asp

ETSI EN 300 468 V1.12.1 (2009-12): Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems. http://pda.etsi.org/pda/queryform.asp. ETSI EN 300 468 V1.12.1 (2009-12): Truyền hình kỹ thuật số; Bản quy định kỹ thuật thông tin dịch vụ (SI) trong các hệ thống DVB. http://pda.etsi.org/pda/queryform.asp

SHS validation list. http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Danh sách xác nhận SHS. http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm

ANSI X 9.31: September 9, 1998. American National Standards Institute, Digital Signatures using reversible public key cryptography for financial services industry (rDSA). ANSI X 9,31:09 tháng chín năm 1998 Viện tiêu chuẩn quốc gia Hoa Kỳ, Các đóng dấu số sử dụng mã khóa công khai đảo ngược dành cho ngành công nghiệp dịch vụ tài chính (RDSA).

ISO/IEC 13818-1:2000(E). Information technology – Generic coding of moving pictures and associated audio information: Systems. ISO/IEC 13818-1: 2000 (E). Công nghệ thông tin – Mã hóa chung của các hình ảnh chuyển động và thông tin âm thanh liên quan: Các hệ thống.

ISO/IEC 13818-6:1998(E). Information technology – Generic coding of moving pictures and associated audio information, Extensions for DSM-CC. ISO/IEC 13.818-6:1998 (E). Công nghệ thông tin – Mã hóa chung của các hình ảnh chuyển động và thông tin âm thanh liên quan, phần mở rộng dành cho DSM-CC.

ISO/IEC 8859-1:1998. 8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1. ISO/IEC 8859-1:1998. Các bộ ký tự đồ họa mã hóa 1-byte 8-bit, Phần 1: Bảng chữ cái Latin số 1

ISO/IEC 13522-5:1997, Information technology – Coding of multimedia and hypermedia information – Part 5: Support for base-level interactive applications. ISO/IEC 13.522-5: năm 1997, công nghệ thông tin – Mã hóa thông tin đa phương tiện và hypermedia – Phần 5: Hỗ trợ cho các ứng dụng tương tác cấp cơ bản

TCVN 7217-1:2007 (ISO 3166-1:2006) về Mã thể hiện tên và vùng lãnh thổ của các nước – Phần 1: Mã nước

ISO 639-2:1998. Codes for the representation of names of languages – Part 2: Alpha-3 code. ISO 639- 2: 1998. Mã dành cho các ngôn ngữ – Phần 2: Mã Alpha-3.

RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (version 3). http://www.ietf.org/rfc/rfc3280.txt. RFC3280. Hồ sơ danh sách thu hồi giấy chứng nhận (CRL) và Giấy chứng nhận cơ sở hạ tầng mã khóa công khai Internet X.509 (phiên bản 3) http://www.ietf.org/rfc/rfc3280.txt

RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With Ipsec, S. Frankel (NIST) H. Herbert (Intel), September 2003. RFC 3566,Thuật toán AES-XCBC-MAC-96 và sử dụng nó với Ipsec, S. Frankel (NIST) Herbert H. (Intel), tháng 9 năm 2003

RFC4055: Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. http://www.ietf.org/rfc/rfc4055.txt. RFC4055: Các thuật toán bổ sung và các nhãn nhận dạng dành cho mã RSA sử dụng trong hồ sơ danh sách thu hồi giấy chứng nhận (CRL) và Giấy chứng nhận cơ sở hạ tầng mã khóa công khai Internet X.509. http://www.ietf.org/rfc/rfc4055.txt

ITU-T Rec X.501: Series X: Data Networks And Open System Communications. ITU-T X.501: Mạng dữ liệu và truyền thông hệ thống mở.

DTG D-Book 5.0: Digital Terrestrial Television, Requirements for Interoperability Issue 5.0. http://www.dtg.org.uk/publications/books.html. DTG D-Book 5.0: Truyền hình kỹ thuật số mặt đất, Các yêu cầu tương thích, phiên bản 5,0. http://www.dtg.org.uk/publications/books.html

R206-001:1998. Guidelines for implementation and use of the common interface for DVB decoder applications. http://www.cenelec.org/Cenelec/Homepage.htm. R206-001: 1998. 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 http:/www.cenelec.org/Cenelec/Homepage.htm

NIST Special Publication 800-38A, 2001 Edition, Computer Security Division, National Institute of Standards and Technology. Http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. NIST Ấn phẩm đặc biệt 800-38A, 2001, Cục An ninh Máy tính, Viện Quốc gia Tiêu chuẩn và Công nghệ. http://csrc.nist.gov/publications/nistpubs/800- 38a/sp800-38a.pdf

ATSC Doc. A/70A:2004, July 22, 2004: Advanced Television Systems Committee, ATSC Standard: Conditional Access System for Terrestrial Broadcast, Revision A. ATSC Doc. A/70A: năm 2004, ngày 22 tháng 7 năm 2004: Ủy ban Hệ Thống Truyền Hình tiên tiến, tiêu chuẩn ATSC: Hệ thống truy nhập có điều kiện dành cho truyền hình mặt đất, bản sửa đổi A.

OC_SP_CCIF2.0-I07-061031: 2006-10-31. Cable Card Interface 2.0 Specification, Cable Television Laboratories. OC_SP_CCIF2.0-I07-061031: 2006/10/31. Bản quy định kỹ thuật giao diện thẻ truyền hình cáp 2.0, Phòng thí nghiệm truyền hình cáp

Thẻ PC Standard version 8.0 Volume 2 Electrical Specification: 2001-04. PCMCIA/JEITA Standardisation Committee. Tiêu chuẩn thẻ PC phiên bản 8.0 Tập 2 Bản quy định kỹ thuật điện: 2001-04. Ủy ban tiêu chuẩn PCMCIA/ JEITA

Thẻ PC Standard version 8.0 Volume 3 Physical Specification: 2001-04. PCMCIA/JEITA Standardisation Committee. Tiêu chuẩn thẻ PC phiên bản 8.0 Tập 3 Bản quy định kỹ thuật vật lý: 2001-04. Ủy ban Tiêu chuẩn PCMCIA/JEITA

Thẻ PC Standard version 8.0 Volume 4 Metaformat Specification: 2001-04. PCMCIA/JEITA Standardisation Committee . Tiêu chuẩn thẻ PC phiên bản 8.0 Tập 4 Bản quy định kỹ thuật Metaformat: 2001-04. Ủy ban tiêu chuẩn PCMCIA/ JEITA

PKCS #3: Diffie-Hellman Key Agreement Standard, ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc. PKCS # 3: Tiêu chuẩn thương lượng mã khóa Diffie-Hellman ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc

ETSI ETR 162:1995-10. Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems. ETSI ETR 162: 1995/10. Truyền hình kỹ thuật số; Phân bổ các mã thông tin dịch vụ (SI) cho các hệ thống DVB

Cl Plus Licensee Specification, available under licence from the Cl Plus Trust Authority. Đặc tả về giấy phép Cl Plus, có sẵn theo giấy phép của Cơ quan ủy quyền tin cậy Cl Plus.

High-bandwidth Digital Content Protection System, Interface Independent Adaptation, Revision 2.0. Hệ thống bảo vệ nội dung số băng thông rộng, thích ứng độc lập giao diện, phiên bản 2.0.

ETSI TS 102 757; Content Purchasing API. ETSI TS 102 757; API mua nội dung.

A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications. http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22b.pdf. Một phương pháp đo thống kê đối với các bộ tạo số ngẫu nhiên và giả ngẫu nhiên dành cho các ứng dụng mật mã. http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800- 22b.pdf

Cl Plus Supplementary Specification, available under licence from the Cl Plus Trust Authority. Bản quy định kỹ thuật bổ sung Cl Plus, có sẵn theo giấy phép của Tổ chức tin cậy Cl Plus.

ETSI ES 202 184 V2.1.1. MHEG-5 Broadcast Profile. ETSI ES 202 184 v2.1.1. Hồ Sơ truyền hình MHEG- 5

ITU-T J.96:2001; Technical method for ensuring privacy in long-distance international MPEG-2 television transmission conforming to ITU-T J.89. ITU-T J.96: 2001; Phương pháp kỹ thuật để đảm bảo sự riêng tư trong truyền dẫn truyền hình MPEG-2 quốc tế khoảng cách xa phù hợp với ITU-T J.89

RFC 1123; Requirements for Internet Hosts — Application and Support. RFC1123; Yêu cầu đối với máy chủ Internet – Ứng dụng và Hỗ trợ.

3 Định nghĩa, ký hiệu và chữ viết tắt

3.1 Định nghĩa

Theo mục đích của tiêu chuẩn này, các định nghĩa sau đây được áp dụng:

3.1.1

Xác thực (authentication)

Là thủ tục an toàn để xác nhận máy chủ hoặc CICAM có chứng nhận hợp lệ và không phải giả mạo, đồng thời thực hiện xác nhận an toàn về nguồn gốc của tin đến.

3.1.2

Được xác thực (Authenticated)

Một thông số chất lượng thu được từ việc áp dụng một thủ tục xác thực; được xác nhận an toàn.

3.1.3

Chế độ by-pass (bypass mode)

Chế độ hoạt động của máy chủ nơi đầu vào TS đến bộ giải ghép kênh của máy chủ được lấy trực tiếp từ nguồn (bộ dò kênh) mà không phải từ CICAM.

3.1.4

Băng truyền (Carousel)

Phương pháp truyền dữ liệu lặp lại trong một chu trình liên tục. Trong trường hợp này, thông qua một MPEG 2 TS.

3.1.5

CA-only

Chế độ CICAM có nội dung CA-descrambling EMI = 00 và trả lại cho máy chủ CC-unscrambled.

3.1.6

Cached PIN

Mã PIN mà đã gửi trong giao thức record_start

3.1.7

Nội dung được kiểm soát (controlled content)

Nội dung được kiểm soát có nghĩa là nội dung đã được truyền từ thiết bị đầu cuối với (a) các bit EMI được thiết lập một giá trị khác không, không (0,0), (b) các bit EMI được thiết lập một giá trị bằng không, không (0,0), nhưng có giá trị RCT được thiết lập là một (1).

3.1.8

CICAM (Common Interface Conditional Access Module)

Mô-đun truy nhập có điều kiện và có giao diện chung.

3.1.9

Giấy chứng nhận CICAM (CICAM Certificate)

Giấy chứng nhận duy nhất được cấp cho mỗi CICAM và được sử dụng để xác thực CICAM. Tên thông số: CICAM_DevCert.

3.1.10

Dữ liệu băng truyền (Data Carousel)

Một trong hai dạng băng truyền dữ liệu do DSM-CC, ISO 13.818-6 [14] quy định.

3.1.11

Máy chủ/Thiết bị chủ/chính (Host)

Thiết bị có khe CAM tuân thủ Cl Plus.

3.1.12

Giấy chứng nhận máy chủ (Host Certificate)

Giấy chứng nhận duy nhất được cấp cho mỗi máy chủ và được sử dụng để xác thực máy chủ. Tên thông số: Host_DevCert.

3.1.13

Mã hóa (Encrypted)

Dữ liệu được sửa đổi để ngăn chặn truy nhập trái phép (so sánh với “xáo trộn”)

3.1.14

Nonce

Một giá trị được chọn ngẫu nhiên được chèn vào một bản tin hoặc giao thức để bảo vệ chống lại các cuộc tấn công lặp lại.

3.1.15

Chế độ Pass-through

Một chế độ hoạt động của máy chủ nơi đầu vào TS đến bộ giải ghép kênh của máy chủ trước đó đã đi qua CICAM từ nguồn (bộ dò kênh).

3.1.16

Xáo trộn lại (re-scramble)

Chế độ của CICAM có nội dung CA-descrambling và CC-scrambling

3.1.17

Kênh được xác thực an toàn (Secure Authenticated Channel)

Đường truyền an toàn giữa máy chủ và CICAM.

3.1.18

Xáo trộn (Scrambled)

Nội dung được sửa đổi để ngăn chặn truy nhập trái phép (so sánh với “mã hóa”)

3.1.19

Tiếp nhận tin cậy (trusted reception)

Tiếp nhận dữ liệu SI không thông qua CICAM, tức là chế độ by-pass.

3.1.20

Nội dung không kiểm soát (uncontrolled content)

Nội dung được chỉ ra bởi giá trị EMI = 00.

3.1.21

Mã xem (viewing PIN)

Mã PIN được sử dụng để xem nội dung trực tiếp (live) hoặc nội dung đã ghi trong chế độ xem lại.

3.1.22

Chế độ/Chức năng tạm dừng (Timeshift/Timeshifting)

Chức năng cho phép tạm dừng chương trình rồi xem tiếp lại nội dung đã phát.

3.2 Ký hiệu

Theo mục đích của tiêu chuẩn này, các ký tự sau đây được áp dụng:

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):

• Thiết bị thu DTV (Máy chủ)

• 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.

Bảng 4.1 – Khả năng phối hợp giữa CICAM và máy chủ (tham khảo)

		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. Hành vi Cl mặc định được mô tả trong EN 50221 nếu việc ngăn chặn của máy chủ không được nhà cung cấp dịch vụ truyền hình kích hoạt. 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.

Đối với các phiên bản không phải là Cl Plus của giao diện chung, nội dung được truyền hoàn toàn không mã hóa đến máy chủ thông qua kết nối Cl và bỏ qua việc chặn hay sao chép nội dung. Tiêu chuẩn này đảm bảo bất kỳ nội dung được thông báo là cấm sao chép được CICAM mã hóa tại chỗ bằng một hệ thống kiểm soát nội dung trước khi được truyền đến máy chủ.

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ủ.

4.4 Xác thực thiết bị

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

• Tạo mã khóa

• 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.

Tiêu chuẩn này mở rộng hồ sơ ứng dụng để bao gồm hỗ trợ cho các ứng dụng truyền hình theo yêu cầu.

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.

• Tài nguyên hồ sơ nhà điều hành mới cung cấp một hồ sơ truyền hình theo chuẩn Cl Plus và sử dụng CICAM để dịch bất kỳ thông báo riêng của mạng sang một cấu trúc thông tin thống nhất cho phép tất cả các máy chủ Cl Plus thực hiện cài đặt hoàn toàn và 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ụ.

• Đ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

Theo mục đích của tiêu chuẩn này, hệ thống hoàn chỉnh bao gồm tất cả mọi thứ từ thiết bị đầu cuối đến máy chủ bao gồm cả CICAM. Hướng lên của Thiết bị đầu cuối không nằm trong phạm vi tiêu chuẩn này. Bất kỳ kết nối giữa máy chủ và các thiết bị khác không được xem xét trong tiêu chuẩn này. Tiêu chuẩn này đề cập đến việc truyền thông tin các quy tắc sử dụng mà máy chủ phải sử dụng khi trình bày phương tiện đến giao diện bên ngoài có liên quan bất kỳ.

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

Quá trình này được xác định như mô tả trong Bảng 5.1:

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
2	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.	Điều 6
Bước # 3 Khởi tạo – Thiết lập SAC
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.	Điều 7
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
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	Điều 5.7.5.3
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.

Hình 5.3 – Hệ thống phân cấp mã khóa

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ế)
Brand cert	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ữ (hằng số giấy phép)	đượ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ộ
DH_q	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 lưu trữ	đượ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
DHX	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 thay đổi	đượ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ộ
AKM	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 thay đổi	đượ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ộ
SAK	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 thay đổi	đượ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ộ

5.3.1 Các mã khóa trên lớp chứng nhận

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

Lớp SAC sử dụng các mã khóa để xác thực và mã hóa bản tin trước khi được gửi đi. Phần nhận được sử dụng các mã khóa được tính toán tương tự để giải mã và kiểm tra bản tin. Mã khóa xác thực SAC (SAK) được sử dụng để xác thực và kiểm tra bản tin SAC. Tương tự như vậy mã khóa mã hóa SAC (SEK) được sử dụng để mã hóa và giải mã bản tin SAC. SAK và SEK được tính độc lập ở CICAM và máy chủ. SAK và SEK đều là thông số mật ngắn hạn không ổn định. Tham khảo điều 7 để biết chi tiết.

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

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

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.

5.4.1. Triển khai trong chế độ dịch vụ cơ bản

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).

SAC được sử dụng để truyền nội dung thông tin các quy tắc sử dụng (URI) một cách an toàn. URI là liên kết với một dịch vụ/sự kiện được bảo vệ CA và truyền thông tin kiểm soát sao chép đến các đầu ra thiết bị máy chủ số (EMI) và tương tự (APS) (xem điều 5.7.5.4). Thiết bị máy chủ sử dụng các quy tắc sử dụng mặc định, hạn chế nhất cho đến khi giao thức truyền URI được kết thúc thành công (xem điều 5.7.5) và sự kiện liên quan các quy tắc sử dụng được thông báo cho thiết bị máy chủ.

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

Các Lỗi có thể được phát hiện và báo cáo bởi CICAM hoặc Máy chủ. Khi một lỗi được phát hiện bởi CICAM thì nó sẽ sử dụng High-Level hoặc ứng dụng MMI để hiển thị một mã lỗi được quy định trước. Khi Máy chủ phát hiện lỗi thì nó có thể sử dụng một vài phương pháp cụ thể trên máy chủ để hiển thị mã lỗi đã được quy định trước. Các mã lỗi có thể kèm theo văn bản mô tả và phải được xác nhận bởi sự tương tác của người dùng. Phụ lục F định nghĩa các điều kiện lỗi tiêu chuẩn và các mã lỗi.

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ủ

Thu hồi máy chủ là thu hồi bằng từ chối dịch vụ tức là CICAM dừng hoạt động Cl Plus, không cung cấp cho thiết bị máy chủ các dịch vụ kiểm soát nội dung của Cl Plus. Tổ chức thiết bị bị thu hồi được liệt kê trong một danh sách thu hồi giấy chứng nhận (SOCRL). Các danh sách thu hồi sau đây được quy định cho mục đích này:

• 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ó.

Mối đe dọa đầu tiên được xử lý bằng cách thêm một mốc dấu thời gian hoặc bộ đếm vào SOCRL. Mối đe dọa thứ hai được xử lý bằng cách quy định một giới hạn chu kỳ bắt buộc; CICAM phải thu được một SOCRL trong một cửa sổ thời gian được xác định trước (với một khoảng thời gian đáng kể để ngăn chặn các điều kiện hiếm gặp). Để ngăn chặn giả mạo, một SOCRL được mã khóa RSA riêng của nhà điều hành dịch vụ đóng dấu và được nhà điều hành dịch vụ nhà phân phối đến các CICAM trong mạng của họ. Một CICAM có thể kiểm tra tính toàn vẹn của một SOCRL bằng cách sử dụng mã khóa công khai RSA trong giấy chứng nhận của nhà điều hành dịch vụ. Giấy chứng nhận này lại được giấy chứng nhận nguồn gốc tin cậy kiểm tra (Xem điều 9).

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:

1) nhận dạng nhà điều hành dịch vụ; quy định các nhà cung cấp dịch vụ được Cl Plus bảo vệ, SOCRL và SOCWL.

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.

• Bắt đầu (1). Việc tải của RSD có thể bắt đầu sau khi CICAM và máy chủ đã được liên kết thành công.

• 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.

Hình 5.8 – Sơ đồ tải về SOCRL và SOCWL

• 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

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

○ 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.

• Thu hồi tạm thời: CICAM hoạt động hạn chế (20). Khi kết thúc thời gian chờ truyền RSD, thời gian chờ truyền SOCRL, một SOCRL hoặc SOCWL hoặc SOPKC không hợp lệ thì CICAM 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 tạm thời bị loại bỏ khi SOPKC hợp lệ, SOCRL hợp lệ (10) và khi một SOCWL hiện tại cũng hợp lệ (14).

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).

• Dịch vụ được CA giải xáo trộn và dịch vụ được Cl Plus xáo trộn lại. Dịch vụ được lựa chọn này là một dịch vụ được Cl Plus bảo vệ và máy chủ liên kết không bị thu hồi, trước tiên, dịch vụ này được CA giải xáo trộn và sau đó được Cl Plus xáo trộn lại. Dịch vụ được Cl Plus bảo vệ đượ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	Không giải xáo trộn	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	Yêu cầu hỗ trợ
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

Hình 5.11 – Làm mới khóa đôi và truyền URI

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	CICAM	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).

Nếu có một liên kết hiện có, tức là phù hợp với các mã khóa xác thực, thì mã hóa được thương lượng trước đây phải được sử dụng (xem Điều 6.3).

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	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	Xáo trộn lại TS đầu ra có thể sử dụng 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.

Hệ thống kiểm soát nội dung Cl Plus tuân thủ các quy tắc xáo trộn sau đâ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.

Chú ý: Có sự khác biệt trong đánh số bit và byte được sử dụng trong MPEG2 (xem ISO 13818-1 [13]) và Chuẩn DES (xem FIPS 46-3 [2]). Việc ánh xạ hệ thống đánh số được định nghĩa trong tài liệu A/70A, Phụ lục A của ATSC [26].

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.

Khi văn bản rõ ràng là lớn hơn 128 bit thì nội dung này được mã hóa bằng cách sử dụng AES trong chế độ CBC (tức là Chuỗi mã hóa khối CBC), sử dụng công thức sau đây:

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).

Các gói tin TS của tất cả các dòng thành phần được lựa chọn sử dụng mã khóa và véc-tơ khởi tạo giống nhau, có hai trường hợp đặc biệt của các khối dư: các khối ngắn đơn độc và kết thúc. Cả hai khối này vẫn là rõ ràng và không được xáo trộn hay giải xáo trộn.

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”

Tương tự như xáo trộn ở trên, chức năng giải mã AES được trình bày bằng b = D _AES-12_8-_CBC {CCK} (s), trong đó mã khóa kiểm soát nội dung (CCK, được quy định tại điều 8.1.4) được sử dụng để giải mã/giải xáo trộn một khối nhị phân s có chiều dài bằng 128 bit (16 byte). Quá trình giải mã s thành một khối b có cùng kích thước.

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.

Chú ý: nội dung (tức là các sự kiện MPEG2) được đề cập đến trong tiêu chuẩn này không được sử dụng số chương trình có giá trị là 0 (không).

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.

Ngay lập tức sau khi bật nguồn điện hoặc thay đổi kênh tới một dịch vụ kiểm soát CAS, máy chủ phải sử dụng các giá trị URI mặc định ban đầu dưới đây.

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
ict_copy_control_info	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	Giá trị khởi tạo mặc định
protocol version	0x02
emi_copy_control_info	0b11
aps_copy_control_info	0b00
ict_copy_control_info	0b0
rct_copy_control_info	0b0
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.

Máy chủ được thiết lập để lưu giữ URI trong khi đồng nhất tới một dịch vụ nào đó mà không phụ thuộc vào trạng thái tín hiệu, ví dụ: Nếu tín hiệu bị mất do ngắt kết nối ăng ten hoặc tín hiệu giảm xuống dưới mức yêu cầu tối thiểu thì bất kỳ URI nào đã nhận trước đây sẽ vẫn có hiệu lực.

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

1. Lưu đồ này không chỉ ra rằng bất kỳ hành vi nào (không) được đồng bộ/ được chia khối.

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	Kết hợp URI với chương trình. 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ì: uri_confirm = SHA₂₅₆ (uri_ message ǁ UCK) 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. CICAM khởi tạo thời gian chờ 1 giây để thủ tục URI phải hoàn thành. (CHÚ THÍCH 1)	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.
7	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. Giá trị này không tương đương 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).
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. 4. Tham chiếu đ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. 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.

Bảng 5.10: 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
ict_copy_control_info	1	uimsbf
rct_copy_control_info	1	uimsbf
reserved for future use	4	uimsbf
r1_copy_control_info	6	uimsbf
reserved for future use	40	uimsbf
}

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
ict_copy_control_info	1	uimsbf
if (emi_copy_control_info == 00) {
rct_copy_control_info } else {	1	uimsbf
rct_copy_control_info } else {
reserved = 0 }	1	uimsbf
reserved = 0 }
reserved for future use	1	uimsbf
if (emi_copy_control_info == 11) {	1
dot_copy_control_info rl_copy_control_info } else {	8	uimsbf


reserved = 0x00	9	uimsbf
}
reserved for future use	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	Ý nghĩa	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	Bản quy định kỹ thuật phiên bản 1.3
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
0x0	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	11	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
0x1	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.

Bảng 5.15: Giá trị cho phép của ict_copy_control_info

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

rct_copy_control_info: tham số này mô tả bit RCT. Máy chủ phải sử dụng bit RCT để kích hoạt kiểm soát phân phối lại về nội dung được kiểm soát khi giá trị RCT được đặt thành một (1) kết hợp với các bit EMI được thiết lập một giá trị là không, không (0,0), để thông báo sự cần thiết kiểm soát phân phối lại để khẳng định về kiểm soát nội dung mà không phải khẳng định kiểm soát sao chép số như được giải thích trong Bảng 5.16.

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	Sử dụng kiểm soát phân phối lại.

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	1	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	000000	Á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	Áp dụng giá trị giới hạn duy trì là bội số 1 đến 61 lần của 24 giờ tùy theo giá trị nhị phân

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	Áp dụng giá trị giới hạn duy trì 6 giờ
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

Nếu CICAM nhận rl_copy_control_infofrom từ mạng mà là phiên bản URI cao hơn so với phiên bản mà máy chủ có thể hỗ trợ, CICAM phải sử dụng giá trị rl_copy_control_info cao nhất có khả năng đối với phiên bản URI phù hợp.

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	Trạng thái	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	SAC không thành công	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	CICAM bị hủy bỏ	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	Xác thực không thành công	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.

Đối với máy chủ có một bộ dò kênh duy nhất, TS phải được truyền nối tiếp qua từng CICAM được ghép vào máy chủ, xem Hình 5.20. Đối với các máy chủ có hai bộ dò kênh thì không cần truyền nối tiếp mà tùy thuộc vào nhà sản xuất máy chủ để định tuyến hai TS này một cách phù hợp.

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. CICAM duy nhất với sự hỗ trợ của nhiều hệ thống CA

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.

5.9. Tổng quan xác thực

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ệ:

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

• 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.

• CICAM và máy chủ phải trao đổi lẫn nhau các thông số của giao thức được bảo vệ bằng đóng dấu bằng cách sử dụng khuôn khổ mã khóa riêng/công khai từ các giấy chứng nhận. Phía gửi phải tạo ra một đóng dấu trên tất cả các các thông số của giao thức được trao đổi bằng cách sử dụng mã khóa riêng của nó và máy chủ phải kiểm tra xác nhận đóng dấu bằng cách sử dụng mã khóa công khai của thiết bị phía còn lại thu được từ giấy chứng nhận của nó.

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.

5.10.3. Trao đổi giấy phép nội dung đối với việc kiểm tra

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)

Máy chủ phải đánh dấu kết thúc của một bản ghi bằng cách dùng Thỏa thuận dừng ghi sử dụng SAC, xem điều 11.3.4.6. Với mỗi Thỏa thuận dừng ghi cho một program_number cụ thể, máy chủ phải thi hành một Thỏa thuận dừng ghi tương ứng. Ví dụ: Khi chuyển kênh, Máy chủ sẽ gửi một Thỏa thuận dừng ghi cho dịch vụ hiện tại, khởi tạo đồng bộ đến một vị trí mới và sau đó gửi Thỏa thuận dừng ghi cho dịch vụ mới.

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ố.

Trong tình huống cha mẹ kiểm soát nội dung AV, các thông tin liên quan đến tình huống này có thể được hiển thị cho người xem. Ví dụ: hiển thị “AV blanking” được hiểu rằng các máy chủ sẽ vô hiệu hóa trình bày của âm thanh, video, phụ đề, vv

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.

5.11.1.2. Khả năng của CICAM PIN chỉ dành cho các dịch vụ CA

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.

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.

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

5.11.4. Thông báo khi mã PIN được yêu cầu

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.

Những thay đổi của URI, giấy phép và mã PIN phải được lưu trữ một cách chính xác với nội dung chương trình sao cho mỗi chuyển đổi có thể được máy chủ thực hiện lại một cách chính xác khi phát lại sau đó phù hợp các sự kiện với vị trí nội dung gốc được cung cấp. Thông báo mã PIN chứa một mốc dấu thời gian và có thể được sắp xếp một cách chính xác với dòng truyền tải. URI và giấy phép không chứa mốc dấu thời gian và phải được sắp xếp với nội dung này dựa trên thời gian nhận được chúng tại máy chủ.

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.

• Nên lưu ý rằng giấy phép # 1 và giấy phép # 2 có thể là cùng một giấy phép hoặc là khác nhau. Trong khi ở chế độ ghi lại, URI và giấy phép được ghép cùng nhau trong một bản tin đơn. Máy chủ không phân tích giấy phép này mà chỉ đơn giản là trả về nó trong hoạt động phát lại tại một thời điểm thích hợp trong dòng truyền tải khi một giấy phép mới được nhập vào.

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].

Máy chủ không được loại bỏ nội dung ghi lại được lưu trữ khi nó vượt quá số lượt phát của nó. Nếu nhà điều hành dịch vụ yêu cầu nội dung này phải bị loại bỏ khi nó đã được xem khi phát lại, khi chuyển đổi số lượt phát từ một sang không (0) xảy ra thì giới hạn lưu trữ này phải được thiết lập một cách thích hợp thông qua URI phát lại để bắt buộc máy chủ loại bỏ nội dung này khi giới hạn thời gian lưu giữ đã bị vượt quá.

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

Bảng 5.21 – Hành vi giao thức truyền 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). Việc cung cấp SRM thường được hệ thống CA bảo vệ hoặc được cung cấp đến CICAM bằng các cách khác (ví dụ: nạp trước). 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. 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. CICAM phải tạo cc_sac_data_req APDU dành cho bản tin của tập tin dữ liệu (SRM), bao gồm: • 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).	điều 7.3 and 11.3.1
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) • trạng thái 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	Áp dụng dữ liệu SRM (nằm ngoài phạm vi tiêu chuẩn này). 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.

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

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 hệ thống được triển khai trong chế độ đăng ký dịch vụ, CICAM khởi tạo một bản tin MMI “đăng ký”, cho phép dữ liệu được thông báo lại cho nhà cung cấp dịch vụ. Tham khảo điều 5.4.2 để biết chi tiết.

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).

4) CICAM yêu cầu máy chủ gửi mã khóa xác thực của nó (AKH). Máy chủ phải trả lời bằng AKH của nó trong vòng 5 giây. Nếu AKH không có sẵn thì nó phải gửi một giá trị với tất cả các số là không. Giá trị với tất cả các số là không được CICAM công nhận là một AKH không hợp lệ.

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.

12) Hệ thống này bị giới hạn chỉ xử lý nội dung rõ rà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:

Bảng 6.1 – Trao đổi xác thực

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
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). • 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 ở cột bên.	đ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
7	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	Máy chủ phải xác nhận bằng cc_data_cnf APDU, bao gồm: • 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: • AKH, hợp lệ hoặc không hợp lệ (tham chiếu đến điều 6.2.3.4). 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	Người sử dụng đầu cuối có thể gửi các ID của thiết bị đến nhà điều hành dịch vụ. Xem điều 5.4.2.
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. 2. Hành vi không thành công của hệ thống kiểm soát nội dung được trình bày trong điều 6.1 và hình 6.1, bước 20. 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.

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

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

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.

9) CICAM tạo ra một nonce ngẫu nhiên DHY để sử dụng trong các tính toán DH.

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ủ.

19) CICAM phải nhận được trả lời của máy chủ trong vòng 5 giây. Nếu không nhận được trong vòng 5 giây, việc xác thực thất bại và CICAM tiếp tục với bước 23.

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.

Hình 6.4 – Tổng quan các điều kiện xác thực phía mặt chủ

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.

8) Máy chủ gửi dữ liệu giao thức đến 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.

18) Máy chủ kiểm tra xem DHSK và AKH có hợp lệ theo điều 6.2.3.3 và 6.2.3.4.

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.

Hình 6.5 – Biểu đồ trình tự tính toán mã khóa xác thực

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	CICAM phải tạo nonce 256 bit ngẫu nhiên (auth_nonce), nó được bao gồm trong đóng dấu chứa các thông số trao đổi của giao thức DH 3 pass. Nonce này phải được một PRNG phù hợp tạo ra.	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.	Phụ lục A
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. • HDQ là mã khóa riêng của thiết bị được quy định trong điều 5.3. • 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. b) CICAM phải kiểm tra đóng dấu A, để: 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ệ’ c) CICAM phải kiểm tra để: 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	CICAM phải tạo ra đóng dấu B trên mã khóa DHPM và các thông số được trao đổi auth_nonce và DHPH, sao cho: 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	CICAM gửi đóng dấu B và mã khóa DHPM, cùng với giấy chứng nhận thương hiệu của CICAM và giấy chứng nhận thiết bị của CICAM đế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.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. • MDP là mã khóa riêng của thiết bị nhận được trong bước 12. • 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	Máy chủ phải xác nhận nó sẵn sàng gửi trạng thái bằng cách sử dụng một bản tin APDU thích hợp.	đ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.	điều 6.2.3.3
	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
19	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].

6.2.3.2. Tính các mã khóa công khai DH (DHPH và DHPM)

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.

6.2.3.3. Tính các mã khóa DH (DHSK)

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)	Diễn giải	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
CICAM_ID	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:

• AKM/AKH

• 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	Mô tả	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.	điều 7.1.1
.. 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 … 21	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

Phần này quy định chi tiết về cách khởi tạo SAC. Hình 7.3 đượ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.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	Khi CICAM phát hiện thấy có yêu cầu mã khóa (lại) SAC, CICAM phải bắt đầu quá trình khởi tạo SAC. 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 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. • CICAM_ID được lấy từ giấy chứng nhận thiết bị của CICAM.
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.	điều 11.3.3.5
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.	điều 11.3.3.5
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

Việc làm mới mã khóa SAC đượ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 mã khóa SAC phải được kích hoạt dưới một trong các điều kiện sau:

• 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:

Ks_host = SHA₂₅₆ (DHSK ǁ AKH ǁ Ns_host ǁ Ns_module) Eq.7.1

Nhân mã khóa Ks phải được tính toán trên CICAM như sau:

Ks_C_IC_AM = SHA₂₅₆(DHSK ǁ AKM ǁ Ns_host ǁ Ns_module) Eq.7.2

Trong đó:

• Ks _C_I_CAM = 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	Tham chiếu đến
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	64	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 3. DHSK bị cắt từ 1024 xuống 128 bit

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

Một bản tin dữ liệu được truyền tải cho Cl SAC phải được chuyển đổi thành một bản tin SAC như sau:

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	3	uimsbf
payload_encryption_flag	1	bslbf
encryption_cipher_flag	3	uimsbf
reserved for future use	5	bslbf
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 } else if (payload_encryption_flag == MSG_FLAG_FALSE) {	length_payload *8 + 128	bslbf
payload	length_payload * 8	bslbfk
authentication } /* Phần thân bản tin kết thúc ở đây */ }	128	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	1

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	AES-128-XCBC-MAC	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:

length_payload: Thông số này là độ dài bản tin của tải tính theo byte bao gồm cả phần đệm tùy chọn, không bao gồm độ dài xác thực đối với cả tải được mã hóa và không được mã hóa.

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	Diễn giải
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:

1) Kiểm tra message_counter xem đã bị dùng hết và cập nhật message_counter. Tham khảo điều 7.2.2 để biết chi tiết.

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 đó:

• 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.

• 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
i	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.

Iength_h_i – Thông số này là độ dài của phần mào đầu tính theo byte.

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.

• Xác thực a_i phải được tính như mô tả trong điều 7.3.1.

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).

Bất kỳ số bản tin mới phải có số bản tin được tăng một cách chặt chẽ i. Bản tin đầu tiên phải sử dụng số 0x1, thứ hai tương ứng số 0x2, và tiếp tục như vậy. Phía nhận không được nhận các bản tin không có thứ tự 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 ³²-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

Trong đó:

• 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.

• 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 _inơ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ư:

authentication_a’_i = MAC{SAK}(length(header_h_i)□i□header_h_i □ payload_p_i) Eq.7.7

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

Bảng 7.9 – Đóng gói dữ liệu sang một 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
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.

Hình 8.1 – Sơ đồ trình tự tính toán CCK.

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	CICAM tạo nonce để tạo Kp như sau: 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. • Lựa chọn thanh ghi chẵn hoặc lẻ.	đ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.	điều 11.3.3.4
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. Khi CICAM đã hoàn thành việc khởi tạo bộ xáo trộn, CICAM phải gửi yêu cầu đồng bộ đến máy chủ. Điều này thông báo cho máy chủ rằng CICAM đã sẵn sàng để bắt đầu sử dụng CCK mới được tính.	đ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. 4. Các APDU này được yêu cầu trong giao thức làm mới CCK phải được gửi qua SAC; tham chiếu đến điều 7. 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.

• Tại mỗi khi thiết lập lại CICAM.

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

Bảng 8.2 – Các giới hạn của bộ đếm khối của bộ xáo trộn

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³²
CHÚ THÍCH: Giới hạn của bộ đếm khối là số khối mã đã được xử lý từ khi làm mới CCK.

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

• Rút ra mã khóa CCK và CIV.

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ố

Kích thước (bit)

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

Bước 2: tính toán mã khó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_D_E_S_–₅₆_-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.

8.1.6. Mã khóa nội dung và IV dành cho bộ xáo trộn AES-128-CBC

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 ³² 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:

• Chứng minh rằng thiết bị tuân thủ Bản quy định kỹ thuật Cl Plus

• 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

– do ROT cấp

– 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

– mỗi thiết bị đơn lẻ có một giấy chứng nhận thiết bị duy nhất

• 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ị

• Mã khóa riêng tương ứng với giấy chứng nhận thiết bị (MDQ hoặc HDQ, xem Bảng 5.2)

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 {

version [0] EXPLICIT Version DEFAULT v1,

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,

— If present, version MUST be v2 or v3

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 {

utcTime UTCTime,

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,

extnValue OCTET STRING }

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ố	Giá trị
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à

id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }

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

Các giấy chứng nhận Cl Plus (giống như tất cả các giấy chứng nhận X.509 khác) sử dụng một tên phân biệt X.501 [22] trong trường tổ chức phát hành. Bảng 9.2 chỉ ra trường tổ chức phát hành đối với các loại giấy chứng nhận khác nhau.

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” 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 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> OU: “đo thử” hoặc “sản xuất” 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.

9.3.5. Hiệu lực

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	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 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” CN: “Cl Plus ROT dành cho” <tên thương hiệu>
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” CN: <ID của nhà điều hành>

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.

Số mũ công khai của mã khóa RSA phải là 65537 == 0x10001, độ dài mô đun phải là 2048 bit. Tham khảo RFC 3280 [19], điều 4.1.2.7 dành cho mã hóa khóa công khai.

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 nhãn nhận dạng mã khóa đối tượng 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 scrambler capabilities 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.

9.3.9.2. Nhãn định danh mã khóa cơ quan thẩm quyền

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	keyCertSign
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	pathLenConstraint
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	–
Giấy chứng nhận nhà điều hành dịch vụ	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 {

capability INTEGER (0..MAX),

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
Các giá trị khác	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}

Cipluslnfo ::= BIT STRING

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

Trường này giống Đóng dấu trong điều 9.3.3

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.

3) Kiểm tra xem mỗi phần mở rộng bắt buộc đượ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.

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)
Đóng dấu được kiểm tra	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.

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 PKCS # 1 v2.1 [1], điều 8.1.2.

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ị

6) Đảm bảo rằng giấy chứng nhận thiết bị chưa bị thu hồi, điều này chỉ được CICAM thực hiện khi kiểm tra giấy chứng nhận của máy chủ.

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.

Bảng 9.10 – 9.10 – Kiểm tra giấy chứng nhận nhà điều hành dịch vụ

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.

10. Ngăn chặn dịch vụ của máy chủ

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_Actua_l. 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_tag: descriptor_tag dành cho ci_protection_descriptor là 0xCE.

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

Nhãn mô tả của nhãn quy định dữ liệu riêng (xem EN 300 468 [10], Nhãn mô tả của nhãn quy định dữ liệu riêng) phải đứng trước ci_protection_descriptor trong vòng nhãn mô tả SDT_Actual. Giá trị của nhãn quy định dữ liệu riêng được định nghĩa trong Đặc tả về giấy phép CI Plus [33].

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ự.

Hình 10.1 – Khái niệm hoạt động của chế độ by-pass

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_Actualphù 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)	DVB CI và CI Plus	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	không 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 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ụ

Mỗi lần thiết bị máy chủ lựa chọn một dịch vụ bất kỳ nào thì thiết bị máy chủ phải sử dụng trạng thái CI Plus của dòng truyền tải hoặc được lưu trữ từ SDT_Actual để xác định cách CICAM phải hoạt động với dịch vụ được lựa chọn này. Tổng quan hoạt động này được thể hiện trong hình 10.2, việc lưu trữ có thể được thiết bị thu tùy chọn thực hiện.

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 1: Việc kiểm tra ở bước (7) là kiểm tra xem nhãn CI_protection_descriptor có sẵn có ? hoặc (nếu sẵn có) kiểm tra trường “free_ci_mode_flag” có là 1 ?

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.

11.1.2.1. 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.

Iength_field: Độ dài của tải APDU trong định dạng ASN.1 BER, xem EN 50221 [7], điều 8.3.1.

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	3	2	1	0
	DA	FR	R	IIR	R	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	Số bit	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

Tốc độ dữ liệu PCMCIA lớn nhất	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ủ.

Máy chủ cung cấp tài nguyên ngôn ngữ và quốc gia của máy chủ. Tài nguyên này phải hỗ trợ một phiên cho mỗi CICAM. ID của tài nguyên dành cho ngôn ngữ và quốc gia của máy chủ được liệt kê trong Bảng L.1, Phụ lục L.

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
Host_language_enq	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
Host_country_enq() { Host_country_enq_tag length_field() = 0 }	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

Số bit

Kiểu

Host_country() {
Host_country_tag
length_field() = 3
iso_3166_country_code
}

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.

Bảng 11.8 – Cú pháp host_language_enq 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.

Máy chủ cũng gửi APDU này không đồng bộ khi có thay đổi thiết lập về ngôn ngữ 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_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
}

uimsbf

bslbf

host_language_tag: xem Bảng L.1, Phụ lục L.

iso_639.2_language_code: Trường này chứa thiết lập về ngôn ngữ hiện tại của máy chủ. Đây là một trường 24-bit xác định ngôn ngữ sử dụng 3 ký tự chữ thường theo quy định của tiêu chuẩn ISO 639 Phần 2 [18]. Cả hai tiêu chuẩn ISO 639-2/B và ISO 639-2/T có thể được sử dụng. Mỗi nhân vật được mã hóa thành 8-bit theo tiêu chuẩn ISO 8859-1 [15]. 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ã 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

APDU_Tag	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	CICAM => HOST	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	CICAM => HOST	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 Truyền và xác nhận SRM 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	CICAM => HOST	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	Trả lời các khả năng PIN của CICAM
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
cc_PIN_playback	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ợ.

Bảng 11.11 – Cú pháp APDU của bản tin cc_open_req

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ợ.

Bảng 11.12 – Cú pháp APDU của bản tin cc_open_cnf

Cú pháp

Số bit

Kiểu

cc_open_cnf() {
cc_open_cnf_tag
length_field()
cc_system_id_bitmask
}

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.

11.3.1.3. cc_data_req APDU

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.

request_datatype_nbr: số các mục dữ liệu mà máy chủ phải đưa vào trong trả lời của nó

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ể

datatype_length: độ dài của phần dữ liệu tính theo byte

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	uimsbf

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
}

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
No CC Support	0x01
Host Busy	0x02
Authentication failed	0x03
CICAM Busy	0x04
Recording Mode error	0x05
Dự phòng	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	uimsbf

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

bslbf
uimsbf

uimsbf
uimsbf
bslbf

uimsbf

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.

Bảng 11.20 – Cú pháp cc_sac_data_cnf APDU

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.

Bảng 11.21 – Tải cc_sac_data_cnf

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ể

datatype_length: độ dài của phần dữ liệu tính theo byte

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	uimsbf

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

cc_sac_sync_cnf() {
cc_sac_sync_cnf_tag
length_field()
sac_message()
}

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	0x00
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

Phần này quy định cụ thể các APDU dành cho PIN của tài nguyên kiểm soát nội dung cung cấp khả năng nhập PIN, xác nhận PIN dành cho ghi lại tự động và nhập PIN để phát lại vào một ngày sau đó.

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

cc_PIN_capabilities_req_tag: xem Bảng L.1 tại Phụ lục L.

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
}

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.

Bảng 11.27 – Các giá trị của capability_field

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)	0x03
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.

Bảng 11.28 – Cú pháp cc_PIN_cmd APDU

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
}
}

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

cc_PIN_reply () APDU được sử dụng để thông báo cho máy chủ rằng CICAM PIN được người sử dụng nhập vào là đúng hay sai.

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
}

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.

Bảng 11.30 – Các giá trị của PINcode_status_field

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	0x03
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.

Video blanking not required: nếu giá trị trạng thái này nhận được bằng cách sử dụng cc_PIN_event () APDU và chế độ hoạt động là ‘Watch and Buffer’ thì máy chủ không được làm trống phần AV đối với nội dung được CA kiểm soát. Tuy nhiên, nên lưu trữ ‘PIN event’ này với nội dung được liên kết với nó để thực thi việc kiểm soát của cha mẹ trong quá trình phát lại.

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

16
8
8

uimsbf

uimsbf
uimsbf
uimsbf

pin_event_time_utc
pin_event_time_centiseconds
private_data
}

40
8
8×15

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.

pin_event_time_centiseconds: Trường này chứa phần trăm (giây/100) của thời gian thay đổi của đánh giá của cha mẹ yêu cầu nhập vào số PIN.

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
}

8
8×15

uimsbf

uimsbf
uimsbf

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

cc_PIN_MMI_req() {
cc_PIN_MMI_req_tag
length_field()
for (i=0; i<n; i++) {
PINcode_data_bytes
}
}

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ủ

Bước

Thực hiện

APDU

Nội dung

CICAM yêu cầu mặt nạ bit của ID hệ thống cc của máy chủ

cc_open_req

Máy chủ gửi mặt nạ bit của ID hệ thống CC của nó

cc_open_cnf

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
1	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
			request_datatype_nbr = 4
			i	datatype_id
			0	13 (DHPH)
			1	17 (Signature_A)
			2	15 (Host_DevCert)
			3	7 (Host_BrandCert)
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	13 (DHPH)	2048bits
			1	17 (Signature_A)	2048bits
			2	15 (Host_DevCert)	độ dài thay đổi được
			3	7 (Host_BrandCert)	độ dài thay đổi được
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)	2048bits
			1	18 (Signature_B)	2048bits
			2	16 (CICAM_DevCert)	độ dài thay đổi được
			3	8 (CICAM_BrandCert)	độ dài thay đổi được
			request_datatype_nbr = 1
			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
			0	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

Bước

Thực hiện

APDU

Nội dung

CICAM yêu cầu mặt nạ bit của ID hệ thống CC của máy chủ

cc_open_req

Máy chủ gửi mặt nạ bit của ID hệ thống CC của nó

cc_open_cnf

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	Nội dung
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)	64 bits
			1	12 (Kp)	256 bits
			2	28 (keyregister)	8 bits
			request_datatype_nbr = 2
			i	datatype_id
			0	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	datatype_len
			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

Giao thức này được thực hiện khi phải tính mã khóa mới dành cho SAC, xem hình 7.3.

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
			i	datatype_id	datatype_len
			0	6 (CICAM_ID)	64bits
			1	21 (Ns_module)	64 bits
			request_datatype_nbr = 2
			i	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
			i	datatype_id	datatype_len
			0	5(HOST_ID)	64bits
			1	20 (Ns_Host)	64 bits
3	CICAM báo máy chủ biết đã hoàn thành tính mã khóa SAC mới	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ảng 11.39 – Truyền và xác nhận URI

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
			i	datatype_id	datatype_len
			0	25 (uri_message)	64 bits
			1	26 (program_number)	16 bits
			request_datatype_nbr = 1
			i	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	datatype_len
			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

Bước	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
			0	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	29(uri_versions)	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ảng 11.41 – Giao thức trao đổi giấy phép từ CICAM đến máy chủ

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_id	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)	64 bits
			3	33 (cicam_license)	variable
			request_datatype_nbr = 1
			i	datatype_id
			0	35(license_rcvd_status)
2	Máy chủ xác nhận đã nhận được	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 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: 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
Máy chủ bận	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.

Độ dài của cicam_license và host_license phải giống nhau, nghĩa là giấy phép phát lại nhận được từ CICAM phải có độ dài giống như host_license gốc đã được gửi đến CICAM khi 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
			i	datatype_id	datatype_len
			0	26 (program_number)	16 bits
			1	36(Host_license)	variable
			request_datatype_nbr = 4
			i	datatype_id
			0	26 (program_number)
			1	34 (license_status)
			2	25 (uri_message)
			3	33(cicam_license)
2	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
			1	34 (license_status)(Xem CHÚ THÍCH 3)	8 bits
			2	25 (uri_message)	64 bits
			3	33 (cicam_license)	variable
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

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	Nội dung
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)	variable
			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	cc_sac_data_cnf	send_datatype_nbr = 2
			i	datatype_id	datatype_len
			0	34 (license_status) (Xem CHÚ THÍCH 3)	8 bits
			1	37 (play_count)	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.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
Không thể giải xáo trộn, không sử dụng (chỉ ghi lại)	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
Giấy phép không hợp lệ (xem & kiểm tra trạng thái)	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	APDU	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	38 (operating_mode)	8 bits
			1	26 (program_number)	16 bits
			2	39 (PINcode data)	variable (tùy chọn)
			request_datatype_nbr = 1
			i	datatype_id
			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
			0	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	Giá trị
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:

Watch_and_Buffer – người sử dụng đang xem trực tiếp nội dung đang được ghi lại. Khi nhận được bản tin khởi tạo ghi lại, CICAM phải lưu trữ CICAM PIN để cho phép ghi lại tự động khi đánh giá độ tuổi trưởng thành thay đổi. CICAM phải tiếp tục hiển thị một MMI để yêu cầu người sử dụng nhập vào CICAM PIN khi yêu cầu thực hiện việc đánh giá độ tuổi trưởng thành. CICAM phải tiếp tục giải xáo trộn nếu CICAM PIN được lưu trữ là chính xác và máy chủ phải làm trống video và âm thanh khi nhận được cc_PIN_event () có PINcode_status_field là “0x00” cho đến khi cc_PIN_reply APDU tiếp theo () có

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	Nội dung
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)	8 bits
			1	26 (program_number)	16 bits
			request_datatype_nbr = 1
			i	datatype_id
			0	41 (mode_change_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
			0	41 (mode_change_status)	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

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	Nội dung
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)	16 bits
			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
			i	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

11.3.5. Truyền và xác nhận tập tin SRM

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	send_datatype_nbr = 1
			i	datatype_id
			0	31 (srm_data)
			request_datatype_nbr = 2
			i	datatype_id
			0	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	datatype_len
			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 3: Máy chủ có thể thiết lập là OK, máy chủ bận hoặc không yêu cầu, xem Bảng 11.24

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.

APDU này bao gồm private_host_application_ID được yêu cầu. Nếu CICAM hỗ trợ ID của ứng dụng được yêu cầu thì nó liên kết phiên SAS này với ID của ứng dụng này và gửi trả một SAS_connect_cnf () APDU. Sau đó CICAM phải mở một phiên SAS khác dành cho các kết nối tiếp theo của máy chủ để có ít nhất một phiên SAS được mở có sẵn và không liên kết đến một ID ứng 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.

4) Ứng dụng của máy chủ và CICAM thông báo qua phiên SAS được kết nối này.

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ợ.

Một công cụ trình bày CI Plus chuẩn bắt buộc cho phép mô-đun này trình bày ký tự và đồ họa trên màn hình của máy chủ mà không cần có các phần mở rộng đối với các tài nguyên MMI có thể hạn chế ứng dụng này của mô-đun. Phạm vi của một máy chủ tuân thủ CI Plus được mô tả trong hình 12.2. Công cụ trình bày CI Plus này cho phép mô-đun này trình bày thông tin với cái nhìn và cảm nhận được nhà điều hành dịch vụ quy định chứ không phải bị MMI cấp cao hạn chế vì MMI này có kiểm soát trình bày và tương tác hạn chế.

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 720×576 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.

Tiêu chuẩn này mở rộng MMI ứng dụng bao gồm hỗ trợ tính năng dành cho các ứng dụng loại VOD.

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ú
Phông 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:

Bảng 12.2 – Các trường hợp ngoại lệ của CIEngineProfile1GetEngineSupportbehaviour đối với D-Book 5.0

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	Phải đi kèm với D-Book và có thể hỗ trợ giá trị hồ sơ CI Plus.

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

Ứng dụng này phải bắt đầu với các thành phần mặc định hoạt động bằng cách xác định một đối tượng dòng chứa các đối tượng âm thanh và video hoạt động được thiết lập theo thành phần mặc định. Nếu ứng dụng CI Plus muốn ngăn chặn dòng thì đầu tiên nó phải được cho phép sử dụng chương trình thường trú RequestMPEGDecoder, xem điều 12.3.6.

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

Các “tính năng” của GetEngineSupport trong D-Book 5.0 [23] điều 13.4.1 với các ngoại lệ trong bảng 12.3:

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	Giới hạn
MultipleAudioStreams(N)	MAS(N)	Có thể trả giá trị “true” với N≤1
MultipleVideoStreams(N)	MVS(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)	Phải trả giá trị “true” cho các giá trị của CHook được hỗ trợ bởi lớp Phông chữ. Phải trả giá trị “false” cho tất cả các giá trị khác của N.

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ề”

12.3.2. Các định dạng “lưu trữ” của dòng

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ị	Ghi chú
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ú

Các chương trình thường trú của D-Book 5.0 [23] điều 13.10 với trường hợp ngoại lệ của các chương trình thường trú sau đây không được CIEngineProfile1 yêu cầu.

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	Không bắt buộc
GetBootlnfo	GBI	Không bắt buộc
VideoToGraphics	VTG	Không bắt buộc
SetWidescreenAlignment	SWA	Không bắt buộc
SetSubtitleMode	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/

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.

12.4. Mẫu đồ họa của công cụ

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 720×576 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.

12.4.4. Đầu vào của người sử dụng

Đầ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”.

Các phông chữ được tải về có thể có một danh mục ký tự rộng hơn và tất cả các ký tự trong phông chữ được tải về phải được hỗ trợ.

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>

Tập phông chữ TrueType không được hỗ trợ trong hồ sơ này. Một tập tin phông chữ chứa một phông chữ duy nhất. Phông chữ duy nhất này sẽ được tham chiếu làm kiểu phông chữ mặc định ‘đơn giản’. Trường hợp các phông chữ có thể tải về được hỗ trợ thì yêu cầu thiết bị thu hỗ trợ các bảng dưới đây:

• 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	Trường unitsPerEm, được định nghĩa ở bảngFontHeader(“head”)
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

Khi một đối tượng ký tự tham chiếu một phông chữ được tải về thì đối tượng này phải được trình bày theo quy định tại D-Book 5.0 [23] điều 14.10, “Hình dáng của các đối tượng có thể nhìn thấy trong quá trình phục hồi nội dung” cho đến khi việc tải về phông chữ thành công hoặc việc tải về phông chữ không thành công. Nếu việc tải về phông chữ không thành công thì thiết bị thu phải sử dụng phông chữ mặc định sẵn có của thiết bị thu để thay thế. Khi sử dụng phông chữ mặc định sẵn có của thiết bị thu, đối tượng văn bản này phải được trình bày sử dụng quy tắc dành cho phông chữ đó bao gồm cả danh mục ký tự được thiết bị thu xác định.

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.

12.6. Thời gian sống của ứng dụng CI

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.

• Ứng dụng CI Plus không thể được tồn tại khi phụ đề hoặc RTGraphics được kích hoạt.

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	SSM=0	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.

Tức là, CICAM có thể sử dụng hồ sơ truyền hình MHEG chứ không phải là môi trường ứng dụng CI Plus dành cho một ứng dụng CI Plus của nhà điều hành cụ thể. CICAM có thể tiếp tục sử dụng MMI ứng dụng CI Plus dành cho các trình đơn và bản tin của CICAM cụ thể.

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ớ

Thiết bị thu phải tối thiểu cung cấp 512 Kbyte RAM dành cho ứng dụng CI Plus này. Trong trường hợp công cụ này hỗ trợ đồ họa độ nét cao thì thiết bị thu phải tối thiểu cung cấp 1 Mbyte RAM dành cho ứng dụng CI Plus này. Trong trường hợp công cụ hỗ trợ các phông chữ có thể tải về thì thiết bị thu phải cung cấp thêm một 256 Kbyte RAM để xử lý phông chữ theo quy định tại 12.5.1.

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ủ

Các tên trong một máy chủ CIEngineProfile1 bao gồm:

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

Khi một ứng dụng được bắt đầu thì một phiên MMI với một Mô-đun CI DVB đã được thiết lập và hệ thống tập tin CI có thể được sử dụng để lấy các đối tượng của tập tin chứa các đối tượng CIEngineProfile1 MHEG-5 hoặc nội dung dữ liệu như văn bản và các bitmap.

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:”.

12.7.4.3. Nhớ đệm

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ữ. Bất kỳ nội dung nào cần được lưu trữ lâu thông qua các phiên MHEG phải được xem như không có ý nghĩa khi bắt đầu một phiên MHEG mới và phải được lấy lại sử dụng RequestType = FileHash hoặc RequestType = File.	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	RequestType=File

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	TIM	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.

12.8.1.2. Ngăn chặn đồ họa MHEG

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

GraphicsState

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).

4. Màn hình đồ họa bị ngắt kết nối khỏi môi trường ứng dụng này và phụ đề được trình bày. Có thể sẽ có một khoảng thời gian trễ ngắn trong trình bày phụ đề khi khởi tạo bộ giải mã phụ đề.

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.

Văn bản phải luôn được trả lại trái sang phải, từ trên xuống dưới, ở những khu vực, dòng văn bản từ phải sang trái thì công cụ ứng dụng CI Plus sẽ không bao gói từ chính xác. Ứng dụng MHEG có thể được thực hiện điều chỉnh và việc điều chỉnh văn bản này nên chèn ký tự ngắt dòng tại các điểm thích hợp để đảm bảo dòng văn bản và trình bày chính xác.

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.

Khi màn ảnh đầu tiên của ứng dụng có thể bắt đầu trong bất kỳ chế độ thanh ghi đầu vào hợp lệ thì nó nên bắt đầu trong thanh ghi đầu vào 3. Bắt đầu trong thanh ghi đầu vào 5, ví dụ, có ảnh hưởng nói chung không mong muốn là hạn chế khả năng của người sử dụng thay đổi kênh.

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

13.3. Kết hợp các tài nguyên MMI

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 thấp: Tùy chọn	– MMI cấp cao: Bắt buộc – MMI ứng dụng “CI Plusbrowser”:Tùy chọn
CICAM	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. Các phần mở rộng CI khác

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.

CICAM chỉ phải gửi lệnh Set_Params khi phía mạng không được kết nối hoặc khi một kết nối mạng được thiết lập và dữ liệu tải chưa được truyền.

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	id_value
Connect_Ack	0x01
Disconnect_Ack	0x02
Set_Params_Ack	0x03
Status_Reply	0x04
Dự phòng	0x05
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.

Tính sẵn có của tập các bộ đệm liên tiếp được máy chủ chỉ ra bằng cách gửi Get_Next_Buffer với

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
Buffer Id	[1]	[3]	[5]	[10]	[12]	[14]	[16]	[18]	[20]
0	O	X	O	O	O	O	O	O	O
1	O	O	O	X	O	O	O	O	O
2	O	O	O	X	X	O	O	O	O
3	O	O	O	X	X	X	X	O	O
4	O	O	O	X	X	X	X	X	O
5	O	O	O	O	O	O	X	X	O
6	O	O	O	O	O	O	O	O	O
7	O	O	O	O	O	O	O	O	O
8	O	O	O	O	O	O	O	O	O
9	O	O	O	O	O	O	O	O	O
10	O	O	O	O	O	O	O	O	O
11	O	O	O	O	O	O	O	O	O
12	O	O	O	O	O	O	O	O	O
13	O	O	O	O	O	O	O	O	O
14	O	O	O	O	O	O	O	O	O
15	O	O	O	O	O	O	O	O	O

“O” có nghĩa là bộ đệm có sẵn dành cho máy chủ

“X” có nghĩa là bộ đệm không 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

9) 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à 3

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

19) CICAM xử lý bộ đệm 4 và 5

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.

Các bước trong hình 14.2 được mô tả dưới đây:

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

• Các bộ đệm có kích thước lên đến 2048 byte phải được hỗ trợ trong cả hai hướng. CICAM có thể chọn một kích thước bộ đệm thấp hơn so với 2048 nếu được yêu cầu bằng cách gửi một lệnh Set_Params

• 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.

14.2. Phần mở rộng truyền IP tốc độ thấp

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.

Nếu nhãn mô tả IP trong comms_cmd APDU của CICAM chứa một giá trị không hợp lệ hoặc loại kết nối được yêu cầu là không có sẵn trên máy chủ, máy chủ phải từ chối việc tạo kết nối. Điều này được thực hiện bằng cách trả lời bằng một comms_reply APDU với comms_reply_id được thiết lập là Send_Ack và return_value được thiết lập là 0 (xem EN 50221, điều 8.7.1.5)

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.

14.2.1. Sửa đổi Commms Cmd

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
Cable_Return_Channel_Descriptor	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

Bảng 14.6 – IP Descriptor

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

Bảng 14.7 – Các phiên bản của giao thức

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	0x03-0xFF

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	0x01
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

Hostname_descriptor() {
descriptor_tag
descriptor_length
protocol_type
destination_port
for (i=0; i<n; i++) {
Hostname_byte
}
}

8
8
8
16

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 lỗi phiên mới thường xảy ra khi máy chủ không có đủ bộ nhớ để nhớ đệm một kết nối mới. Các lỗi comms_reply xảy ra khi máy chủ không có khả năng thiết lập một kết nối cho các giao thức lớp ứng dụng yêu cầu.

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 …) èç	Nếu đây là một tài nguyên miễn phí thì phiên được cho phép
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
Cấu hình các thông số nhận và kích thước bộ đệm.	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	7	6	5	4	3	2	1	0
device type (kiểu thiết bị)								device no. (số hiệu thiết bị)

Hình 14.4 – Cấu trúc các loại tài nguyên truyền

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	0x50
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

14.3.1. Giới thiệu

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)

Một CICAM truy nhập có điều kiện điển hình cung cấp hai chế độ hoạt động nâng cấp phần mềm khác nhau được gọi là “trì hoãn” và “ngay lập tức” đáp ứng yêu cầu khác nhau của hệ thống CA:

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.

2) Chờ máy chủ thực hiện một lựa chọn dịch vụ đối với dịch vụ CA, được xác định bằng CA System Id trong ca_pmt hiện tại.

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

Nếu trả lời của máy chủ là “Hỏi” thì CICAM hiển thị một cuộc đối thoại MMI để thông báo cho người sử dụng đầu cuối về tính sẵn có của việc nâng cấp CAM này. CICAM bắt đầu hoặc dừng quá trình tải về phần mềm tùy thuộc vào thông tin phản hồi của người sử dụng (chấp nhận hoặc từ chối).

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

Đối với một nâng cấp bị trì hoãn, CICAM chờ đợi 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. Khi một dịch vụ như vậy được lựa chọn, CICAM mở tài nguyên nâng cấp CAM, nếu nó chưa được mở, và gửi một cam_firmware_upgrade APDU để bắt đầu một quá trình nâng cấp bị 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

Đối với việc nâng cấp ngay lập tức, CICAM phải ngăn chặn việc giải xáo trộn tất cả các dịch vụ CA System Id cho đến khi việc nâng cấp phần mềm mới đã được cài đặt. Khi người sử dụng chọn một dịch vụ được CA xáo trộn, CICAM mở tài nguyên nâng cấp CAM, nếu nó chưa được mở, và gửi một cam_firmware_upgrade APDU để bắt đầu một quá trình nâng cấp 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.

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:

• CICAM bị thiết lập lại

• 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

2) Chế độ hoạt động của máy chủ phải xác định trạng thái trở lại của CICAM thông qua cam_firmware_upgrade_reply.

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	Khô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.

14.3.4.6. Hủy bỏ nâng cấp

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	CICAM □ □ HOST
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

Cú pháp

Số bit

Kiểu

cam_firmware_upgrade() {
cam firmware upgrade tag
length_field()
upgrade_type
download time
}

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

download_time: Thời gian theo giây, dự kiến để hoàn thành quá trình nâng cấp firmware. Nếu giá trị là 0x0000 thì thời gian này là không xác định.

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
}

uimsbf

cam_firmware_upgrade_reply_tag: xem Bảng L.1 tại Phụ lục L.

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

Số bit

Kiểu

cam_firmware_upgrade__progress() {
cam_firmware_upgrade_progress_tag
length_field()
download_progress_status
}

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

Cú pháp

Số bit

Kiểu

cam_firmware_upgrade_complete() {
cam_firmware_upgrade_complete_tag
length_field()
reset_request_status
}

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ị	Diễn giải
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.

14.4. Tài nguyên MMI ứng dụ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

• 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

FileReq() {
FileReqTag length_field()
RequestType
if (RequestType == 0) {
for (i=0; i<(n-1); i++) {
FileNameByte
}
}
if (RequestType == 1) {
for (i=0; i<(n-1); i++){
DataByte
}
}
}

uimsbf

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)	0x01
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

Kiểu

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
}
}
}

7
1
8

uimsbf

bslbf
bslbf
bslbf

uimsbf

bslbf

uimsbf

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)	0x00
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ủ.

14.4.4. AppAbortRequest

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.
0x02	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.

14.5.1. FileRequest v2

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
}
}
}

128

uimsbf

bslbf

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	Một mục dữ liệu đang được yêu cầu	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	0x04-0x7f
Đị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

Cú pháp

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
}
}
}

6
1
1
8

8
8

uimsbf

bslbf
bslbf
bslbf
uimsbf

uimsbf
bslbf

uimsbf

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	Request	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	FileFlash	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.

Bảng 14.27 – Giá trị trạng thái FileOK

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	Data	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	Lỗi xảy ra trong khi yêu cầu.	Đâ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.

FileDataByte: Một byte dữ liệu của 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.12.

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).

5 byte (hex)

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

Tài nguyên kiểm soát máy chủ DVB phiên bản 2 hỗ trợ các đối tượng sau:

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
ask_release	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.

Bảng 14.29 – Cú pháp tune_broadcast_req 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()
}
}

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.

descriptor (): nhãn mô tả này được mã hóa theo EN 300 468 dành cho thông tin dịch vụ (SI) trong hệ thống DVB [10]. Bảng 14.34 chỉ ra các nhãn mô tả có thể có sẵn trong vòng.

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
}

uimsbf

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	0x02
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	0x07-0xFF
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

Số bit

Kiểu

ask_release_reply() {
ask_release_query_tag
length_field()
release reply
}

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	0x00
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ả

tune_broadcast_req () APDU chứa một vòng các nhãn mô tả được máy chủ sử dụng để cung cấp thông tin về dịch vụ được dò kênh này.

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	Một tần số đích duy nhất phải được xác định bởi bộ mô tả hệ thống phân phối phù hợp với mạng hiện thời.
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	0x7F, 0x0D Xem CHÚ THÍCH
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
content_descriptor	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

4) Máy chủ điều chỉnh bộ dò kênh qua dòng truyền tải được mô tả

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

14) Máy chủ kiểm tra xem PMT có được tải về thành công. Nếu PMT không được tải về thì máy chủ tiếp tục với bước 15

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)

6) Máy chủ nhận được một phiên bị đóng từ CICAM.

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

Tài nguyên hồ sơ của nhà điều hành cho phép cung cấp một bảng thông tin mạng (NIT) thông qua CICAM, bảng này được sử dụng trong ưu tiên hơn bất kỳ NIT của mạng truyền hình. Cơ chế cung cấp NIT này cho phép CICAM chuyển đổi thông tin mạng riêng và tín hiệu của nhà điều hành dịch vụ cụ thể sang một định dạng duy nhất được cung cấp trong một NIT mà tất cả thiết bị máy chủ CI Plus phù hợp tiêu chuẩn này nhận biết được.

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.

CICAM NIT mô tả đầy đủ các dịch vụ xuất hiện trong danh sách kênh của nhà điều hành dịch vụ và thông tin đầy đủ có trong CICAM NIT cho phép máy chủ xây dựng một danh sách kênh đầy đủ. Máy chủ không được yêu cầu truy vấn NIT, BAT hoặc SDT truyền hình để xây dựng, duy trì danh sách kênh và tất cả các thông tin này được cung cấp trong CICAM NIT. CICAM được yêu cầu xây dựng và duy trì CICAM NIT sử dụng thông tin danh sách kênh mới nhất, điều này có thể yêu cầu CICAM giám sát các bảng SI của mạng một cách chủ độ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.

14.7.4. Trao đổi tài nguyên hồ sơ nhà điều hành

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ỏ.

CICAM phải giữ lại thông tin hồ sơ này trong bộ nhớ liên tục (bao gồm cả CICAM NIT hoặc thông tin để xây dựng lại CICAM NIT). CICAM phải đảm bảo rằng cơ chế cập nhật bộ nhớ đệm là chắc chắn và có thể hỗ trợ hoạt động khi tắt điện ở bất kỳ giai đoạn nào trong hoạt động ghi mà không làm mất bất kỳ thông tin được lưu trữ hiện có cho đến khi thông tin mới đã được ghi hoàn toàn. Điều này tránh cho thông tin hồ sơ riêng không bị mất và ngẫu nhiên quay trở lại trạng thái chưa được khởi tạo.

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.

6. Khi nhận được một operator_tune () thì máy chủ dò kênh đến bộ ghép kênh được yêu cầu và thừa nhận sự dò kênh bằng một operator_tune_status () APDU chứa trạng thái dò kênh này. Nếu CICAM yêu cầu máy chủ tìm vị trí số tiếp theo thì CICAM có thể gửi một operator_tune () APDU khác thực hiện tìm kiếm kênh bằng cách sử dụng các vị trí được mô tả trong APDU này và được xác nhận bởi máy chủ bằng một operator_tune_status () APDU khi việc tìm kiếm hoàn thành.

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 phải chủ động duy trì môi trường hồ sơ nhà điều hành.

• 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

Các hành vi của hệ thống được quy định như sau:

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.

Các trạng thái cờ của operator_status_body () chỉ ra cách máy chủ nên xử lý sự thay đổi quyền.

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 ().

5. 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.

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.

4. Khi nhận được một operator_tune () thì máy chủ dò kênh đến bộ ghép kênh được yêu cầu và xác nhận sự dò kênh bằng một operator_tune_status () APDU có chứa trạng thái của yêu cầu dò kênh.

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..

Máy chủ nên cung cấp cho CICAM cơ hội để tự cập nhật mạng ít nhất hàng tuần như là một phần của bất kỳ chu kỳ bảo trì được máy chủ khởi tạo bằng cách khởi tạo một hoạt động tìm kiếm không theo yêu cầu. CICAM có thể thông báo một ngày và thời gian để thực hiện việc quét nền bằng cách sử dụng một yêu cầu làm mới theo một chu kỳ thời gian.

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.

Hình 14.18 – Trình tự APDU tìm kiếm hồ sơ

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

CICAM chỉ có thể khởi tạo một yêu cầu dò kênh operator_tune () APDU để đáp ứng operator_search_start () APDU của máy chủ. Khi việc tìm kiếm đã được khởi tạo thì CICAM được phép khởi tạo nhiều yêu cầu dò kênh. Hoạt động dò kênh này có thể:

• 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.

Trường hợp máy chủ khởi tạo tìm kiếm bảo trì định kỳ trong một chế độ chờ, trong đó máy chủ không tham gia, thì yêu cầu máy chủ cung cấp cho CICAM một cơ hội để đưa ra các yêu cầu thêm cho máy chủ. Khoảng thời gian 30 giây sau khi nhận được xác nhận operator_search_status () phải được máy chủ cung cấp để cho phép CICAM đủ thời gian để khởi tạo một yêu cầu APDU nâng cấp phần mềm trước khi máy chủ trở về với bất kỳ chế độ chờ sâu hơn.

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	HOST=>CICAM	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	Các phần CICAM NIT hiện thời.
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.
operator_search_status	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	HOST=>CICAM	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	Kiểu
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

Cú pháp	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 không làm chủ một dịch vụ CA – Như là dịch vụ Free-to-air.

• 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	uimsbf uimsbf uimsbf bslbf bslbf
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

Giá trị	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.

entitlement_valid_flag: trường 1-bit này được thiết lập khi quyền này là hợp lệ, trường này được quy định chỉ để tham khảo. Giá trị của “1”, chỉ ra rằng quyền được hưởng đã có và hợp lệ. Giá trị “0” chỉ ra rằng không có quyền được hưởng.

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	Yêu cầu khẩn từ CICAM rằng mạng cần phải được tham vấn để thu thập thông tin. Một yêu cầu khẩn chỉ được báo hiệu khi CICAM không có đủ khả năng hoạt động cho tới khi mạng được tham vấn. Máy chủ phải khởi đầu việc tìm hồ sơ ngay khi có thể. Một máy chủ trong dịch vụ Free-to-air hay dịch vụ CA mà không gắn với CICAM sở hữu hồ sơ nhà khai thác thì không được yêu cầu xử lý cờ này ngay lập tức khi đang xử lý yêu cầu khác. Điều này sẽ làm gián đoạn hoặc ngăn chặn người dùng đang xem các dịch vụ hiện tại.
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	Không có lỗi.
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.

Bảng 14.42 – Các giá trị delivery_system_hint

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	Dự phòng.

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ụ:

239

00:00 – nửa đêm

04:24 – 4 giờ 24 phút sáng

23:54 – nửa đêm kém 6 phút

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

Trong đó các trường được quy định như sau:

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
}
}

uimsbf

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.

Máy chủ phải luôn luôn giữ phạm vi nhãn mô tả riêng. Không yêu cầu máy chủ phân tích bất kỳ nhãn mô tả riêng khác gặp phải trong bất kỳ vòng NIT và phải bỏ qua bất kỳ nhãn mô tả không xác định.

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	uimsbf

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.

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 APDU này. Phiên bản thông tin hồ sơ sẽ đượ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...

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.

second_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 đầu tiên 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.

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.
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	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ả
0	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.
5-7	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.

sdt_other_trusted: trường 1-bit này xác định trạng thái tin cậy của các bảng SDT _other trong mạng. Trường này phải được thiết lập là “1” khi SDT này hoàn toàn được truyền qua mạng này và có thể được máy chủ tin cậy vì thông tin trạng thái eit_event_trigger chính xác. Giá trị mặc định là “0” và thông tin trong SDT_Actualchỉ là đáng tin cậy.

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

Số bit

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;
}
}

1
7

uimsbf

bslbf
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ụ:	0x0102	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	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), MHP (0x10), video SD (0x16) và HD (0x19) mã hóa tiên tiến nâng cao được hỗ trợ.

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
	0x0106	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	Kiểu
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

Cú pháp	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

CICAM gửi APDU này đến máy chủ để yêu cầu một hoạt động dò kênh trong trường hợp operator_search 0 APDU dưới sự kiểm soát của máy chủ khi một hoạt động tìm kiếm hồ sơ được yêu cầu. APDU này không được sử dụng để dò kênh ngoài trường hợp này. Máy chủ trả lời bằng một operator_tune_status () APDU khi hoạt động dò kênh này đã được hoàn thành. APDU này cho phép CICAM thực hiện hoạt động dò kênh trực tiếp.

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

operator_tune () {
operator_tune_tag
length_field()
reserved
descriptor_loop_length
for (i=0; i<N; i++) {
descriptor()
}
}

4
12

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.

Bảng 14.54 – Cú pháp operator_tune_status APDU

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()
}
}

8
8
8
4
12

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.

Bảng 14.55 – Các giá trị trạng thái

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	Bộ mô tả hệ thống phân phối không được hỗ trợ bởi máy chủ. 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ệ.
3	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.

signal_quality: trường 8-bit này xác định chất lượng của tín hiệu theo giá trị phần trăm từ 0 đến 100, trong đó 0 đại diện cho một tín hiệu có chất lượng không khả thi và 100 là một tín hiệu hoàn hảo.

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
operator_entitlement_ack() { operator_entitlement_ack_tag length_field() }	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	Kiểu
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

A.1. Định nghĩa 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	2048	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	Yêu cầu SAC của CICAM đến máy chủ
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

Trong hình A.1, k là một giá trị không đổi 128-bit, DT_i là một giá trị 128 bit được cập nhật vào mỗi lần lặp (ví dụ như véc-tơ ngày/thời gian hoặc bộ đếm đều đều) và s là một giá trị nhân. CICAM và máy chủ phải có một giá trị nhân duy nhất được tạo ra S.

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

Đối với các số ngẫu nhiên không phải là một bội số chính xác của kích thước khối AES thì khối AES cuối cùng được cắt ngắn LSB theo độ dài được quy định tại Bảng A.1.

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ác thuật toán kiểm tra tổng

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.

Phụ lục E

(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

E.2.1. Bản quy định kỹ thuật

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:

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 có lý do nào để gửi một CA_PMT mới để loại bỏ chương trình này trong danh sách. Chương trình này vẫn được lựa chọn và máy chủ vẫn tiếp tục gửi CA_PMT khi version_number của PMT tăng lên.

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:

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

R206-001 [24] (điều 9.5.5.1) đã mô tả rằng:

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.

CICAM phải xử lý các tình huống khi máy chủ đang bận và không thể trả lời yêu cầu của CICAM về việc hiển thị một bản tin MMI tức thời. Trong trường hợp này, máy chủ trả về một đối tượng open_session_response với F3 session_status (nguồn bận) khi mô-đun cố gắng mở phiên MMI. Mô-đun có thể thử mở lại một phiên MMI cho đến khi máy chủ có thể mở phiên này nhưng phải xem xét xem một số bản tin có bị lỗi thời khi dịch vụ hiện tại đã thay đổi (ví dụ như một bản tin MMI tức thời là “bạn không được phép xem chương trình này”).

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.

Khi một mô-đun được ghép vào hoặc máy chủ được bật nguồn điện thì một hoặc hai kết nối truyền tải có thể được tạo ra đến mô-đun, đáp ứng một ứng dụng và/hoặc một nhà cung cấp tài nguyên.

Đ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

EN 50221 [7] điều 7 quy định:

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³⁰⁵ 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ủ 00×200041 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ị

Việc kiểm soát máy chủ chỉ được sử dụng khi người sử dụng tương tác với CICAM cho phép CICAM dò kênh đến một dịch vụ khác (tức là nâng cấp CAM và MMI).

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ị

CICAM không được mở một phiên cho cả hai tài nguyên CC và tài nguyên CP cùng một lúc. Máy chủ phải trả lời ‘phiên không mở, tài nguyên tồn tại nhưng không sẵn sàng (0xf1)’

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. Đối tượng Comms Reply truyền tốc độ thấp

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ị

CICAM luôn luôn bao gồm một byte lựa chọn bảng ký tự đứng trước để đảm bảo rằng máy chủ sử dụng bảng ký tự chính xác. Xem EN 300 468 [10] Phụ lục A

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	original 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	TSID	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:

Nếu sử dụng các kỹ thuật mã hóa đồng thời thì một mục nhập cho một chương trình trong PMT có thể chứa các CA_descriptor dành cho nhiều hơn một CA ID. Trong trường hợp này, đối tượng CA_PMT phải chứa tất cả các CA_descriptor được sử dụng, và thiết bị thu sẽ không cố gắng lựa chọn dựa trên (các) CA ID được một ứng dụng CA cụ thể thông báo.

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

E.18.1. Bản quy định kỹ thuật

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.

E.19.2. Sửa đổi

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:

1) PPT không được tính một cách chính xác (vì không có thông báo thay đổi dịch vụ),

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)

• version_number thay đổi

• 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.

E.21.2. Yêu cầu CICAM

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ủ

Máy chủ phải hỗ trợ việc đóng và mở lại phiên hỗ trợ CA.

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

Máy chủ gửi một open_session_response () SPDU để trả lời một open_session_request () của CICAM. open_session_response () chứa một giá trị trạng thái theo tiêu chuẩn EN 50221 [7], bảng 7.

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ủ

Máy chủ nên trả lời bằng tất cả các mã ký tự được hồ sơ cơ bản của quốc gia hoặc khu vực hoặc mạng mà máy chủ hiện đang được cấu hình yêu cầu. Máy chủ có thể tùy chọn bao gồm tất cả các bảng mã ký tự khác được MMI cấp cao hỗ trợ mà có thể không được cấu hình hiện tại của máy chủ yêu cầu.

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	{}	Chỉ ISO/IEC 6937
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	Điều kiện 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ị.	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 CI.
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; – Bootloader	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í	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ị.
07	Cập nhật Firmware CICAM thất bại; • Lỗi ký hình ảnh	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ị.
08	Xác thực thất bại – Quá tải	CICAM	Không	– CICAM chuyển sang chế độ pass–through.
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 thực thất bại – 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	Máy chủ dừng CICAM	– 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.
13	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	Máy chủ chuyển sang chế độ DVB- Cl (CHÚ THÍCH 2)	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
16	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ệ – 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ị.
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	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ị
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) – một bản tin phản hồi thông báo lỗi được hiển thị.
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ị.
21	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	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. 3: CICAM chỉ giải xáo trộn trong các dịch vụ không yêu cầu được Cl Plus bảo vệ (chế độ trở về 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.

Hai bít bổ sung được quy định trong thanh ghi lệnh để kiểm soát những trường hợp khi CICAM kích hoạt một ngắt.

Bảng G.1 – Thanh ghi lệnh

7	6	5	4	3	2	1	0
DAIE	FRIE	R	R	RS	SR	SW	HC

Bảng G.2 – Các bit cho phép ngắt

DAIE	Khi bit này được thiết lập thì mô đun sử dụng IREQ# mỗi lần nó có dữ liệu để gửi
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

CICAM sử dụng ngắt kích hoạt theo cấp. Để thông báo một ngắt, CICAM chiếm đường IREQ # bằng cách thiết lập nó xuống mức thấp. Đường này được chiếm cho đến khi máy chủ xác nhận rằng ngắt này đang được phục vụ. Xác nhận này hoàn toàn được một hoạt động đọc hoặc ghi trên bus dữ liệu đưa ra. Ngắt xung không được Cl Plus hỗ trợ.

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_sequence> ::= <compatibility_item> {“ “ <compatibility_item>}

<compatibility_item> := <label> “=” [<compatibility_flag>] <identity>

<compatibility_flag> ::= “–“l“+“l“*“

<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>.

<label>: một chuỗi ký tự xác định khả năng tương thích được hỗ trợ. Nhãn này phải bao gồm các ký tự chữ hoa hoặc chữ thường từ “a” đến “z” và từ “A” đến “Z”, các số từ “0” đến “9”, ký tự (“.”) và gạch dưới (“_”). Để tương thích Cl Plus thì nhãn được định nghĩa là chuỗi không phân biệt chữ ký tự viết thường hay hoa “ciplus”.

<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.
* (Sao)	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

Một Cl Plus CICAM phải thông báo việc hỗ trợ Cl Plus bằng <label> “ciplus”. Đối với <label> “ciplus”, <identity> phải là một số phiên bản số nguyên thập phân gồm một hoặc nhiều số thập phân. Đối với phiên bản này trong tiêu chuẩn này thì <identity> phải là “1”. Phiên bản vẫn phải là 1, không phụ thuộc vào phiên bản của bản quy định kỹ thuật Cl Plus, cho đến khi có một APDU hoặc chức năng không tương thích phải bắt buộc tăng số phiên bản thêm 1.

Đố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

CICAM phải thông báo việc hỗ trợ các tính năng Cl Plus bổ sung vào thông tin CIS ví dụ như tài nguyên hồ sơ nhà điều hành.

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ú
Tài nguyên hồ sơ nhà điều hành	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]$

$compatible[ciplus=*3 ciprof=0x890a4401]$

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)

Bản quy định kỹ thuật chứng nhận

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	–	–	1
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.	6
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	–	–	11
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	2048	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	16
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	256	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ủ	21
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	26
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	256	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	31
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	8	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)	36
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	variable	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	41
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)

Định dạng độ dài thẻ

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> – 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)
0x00	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	Nonce xác thực	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
0x05-OxFF	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¹⁶ -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 0000 0000 1000 0000 0001
<msg_label 02>	0000 0001 0000 0000 0000 1000 0000 0010
<auth_nonce>	0000 0010 0000 0001 0000 0000 (tiếp theo là 256 bit dữ liệu ngẫu nhiên)
<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

Phụ lục này nhắc lại các yêu cầu kỹ thuật điện dành cho máy chủ và CICAM Cl Plus. Không có các yêu cầu kỹ thuật điện mới dành cho Cl Plus. Thông tin này được đưa ra từ EN 50221 [7], PCM CIA tập 2 [28] và PCM CIA tập 3 [29].

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	Diễn giải	Chân	Tín hiệu	I/O	Diễn giải
1	GND		Ground	35	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
4	D5	I/O	Data Bit 5	38	D12	I/O	High Z
5	D6	I/O	Data Bit 6	39	D13	I/O	High Z
6	D7	I/O	Data Bit 7	40	D14	I/O	High Z
7	CE1#	I	Card Enable 1	41	D15	I/O	High Z
e	A10	I	Address Bit 10	42	CE2#	1	Card Enable 2
9	OE#	I	Output Enable	43	VS1#	O	Voltage Sense 1
10	A11	I	Address Bit 11	44	RFU
11	A9	I	Address Bit 9	45	RFU
12	A8	I	Address Bit 8	46	A17	I	High Z
13	A13	I	Address Bit 13	47	A18	I	High Z
14	A14	I	Address Bit 14	48	A19	I	High Z
15	WE#	I	Write Enable	49	A20	I	High Z
16	Ready	O	Ready	50	A21	I	High Z
17	VCC		Supply	51	VCC		Supply
18	VPP1		Program Voltage 1	52	VPP2		Program Voltage2
19	A16	I	High Z	53	A22	I	High Z
20	A15	I	High Z	54	A23	I	High Z
21	A12	I	Address Bit 12	55	A24	I	High Z
22	A7	I	Address Bit 7	56	A25	I	High Z
23	A6	I	Address Bit 6	57	VS2#	O	Voltage Sense 2
24	A5	I	Address Bit 5	58	RESET	I	Card Reset
25	A4	I	Address Bit 4	59	WAIT#	I	Extend Bus Cycle
26	A3	I	Address Bit 3	60	RFU
27	A2	I	Address Bit 2	61	REG#	I	Register Select
28	A1	I	Address Bit 1	62	BVD2	O
29	A0	I	Address Bit 0	63	BVD1	O
30	D0	I/O	Data Bit 0	64	D8	I/O	High Z
31	D1	I/O	Data Bit 1	65	D9	I/O	High Z
32	D2	I/O	Data Bit 2	66	D10	I/O	High Z
33	WP	O	Write Protect	67	CD2#		Card Detect 2
34	GND			68	GND

CHÚ THÍCH:

1. “I” chỉ thị các tín hiệu vào CICAM.

2. “O” chỉ thị các tín hiệu ra khỏi 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ảng K.2 – Bố trí các chân của giao diện chung sau khi thay đổi

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	Diễn giải
1	GND		Ground	35	GND
2	D3	I/O	Data Bit 3	36	CD1#		Card Detect 1
3	D4	I/O	Data Bit 4	37	MDO3	O	MP data out 3
4	D5	I/O	Data Bit 5	38	MDO4	O	MP data out 4
5	D6	I/O	Data Bit 6	39	MDO5	O	MP data out 5
6	D7	I/O	Data Bit 7	40	MDO6	O	MP data out 6
7	CE1#	I	Card Enable 1	41	MDO7	O	MP data out 7
8	A10	I	Address Bit 10	42	CE2#	I	Card Enable 2
9	OE#	I	Output Enable	43	VS1#	O	Voltage Sense 1
10	A11	I	Address Bit 11	44	IORD#	I	I/O read
11	A9	I	Address Bit 9	45	IOWR#	I	I/O write
12	A8	I	Address Bit 8	46	MISTRT	I	MP in start
13	A13	I	Address Bit 13	47	MDI0	I	MP data in 0
14	A14	I	Address Bit 14	48	MDI1	I	MP data in 1
15	WE#	I	Write Enable	49	MDI2	I	MP data in 2
16	IREQ#	O	Interrupt Request	50	MDI3	I	MP data in 3
17	VCC		Supply	51	VCC		Supply
18	VPP1		Program Vottage 1	52	VPP2		Program Voltage2
19	MIVAL	I	MP invalid	53	MDI4	I	MP data in 4
20	MCLKI	I	MP clock input	54	MDI5	I	MP data in 5
21	A12	I	Address Bit 12	55	MDI6	I	MP data in 6
22	A7	I	Address Bit 7	56	MDI7	I	MP data in 7
23	A6	I	Address Bit 6	57	MCLKO	O	MP clock output
24	A5	I	Address Bit 5	58	RESET	I	Card Reset
25	A4	I	Address Bit 4	59	WAIT#	O	Extend Bus Cyde
26	A3	I	Address Bit 3	60	INPACK#	O	In Port Ack.
27	A2	I	Address Bit 2	61	REG#	I	Register Select
28	A1	I	Address Bit 1	62	MOVAL	O	MP out valid
29	A0	I	Address Bit 0	63	MOSTRT	O	MP out start
30	D0	I/O	Data Bit 0	64	MDO0	O	MP data out 0
31	D1	I/O	Data Bit 1	65	MDO1	O	MP data out 1
32	D2	I/O	Data Bit 2	66	MDO2	O	MP data out 2
33	IOIS16#		16 bit I/O	67	CD2#		Card Detect 2
34	GND			68	GND

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.

• Cả hai chân phát hiện thẻ được đặt ở hai đầu của kết nối để phát hiện việc cắm chính xác.

• 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ợ.

K.1.3.2. Các chân nhận biết điện áp và ổ cắm chính

• 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.

• CICAM không được phép nối chân VPP1 hoặc chân VPP2 với chân VCC.

• 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	Đơn vị	Đánh dấu
Vcc	4.75	5.25	V	Xem 1.
Vpp	4.75	5.25	V	Xem 1.
lcc + Ipp	–	300	mA	Xem 2.
Ipp		50	mA	Hợp lệ cho chân VPP
Icc + Ipp_p_o_wer_up		100	mA	Xem 4.
ICC + Ipp_peak		500	mA	Xem 3.
P_T_otal		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.

3. Dòng điện đỉnh ngắn hạn cho phép có thời gian không được lớn hơn 1 ms

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	4.75	5.25	V	Xem 1.
Vpp	4.75	5.25	V	Xem 1.
lcc	330		mA	Xem 2.
Ipp	55		mA
Icc + Ipp_peak	500		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ủ

K.1.4.3. Sơ đồ thời gian tắ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ủ	Diễn giải
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Ω
OE# WE#	Tải điện dung ≤ 50pF
RESET	Đưa lên VCC ≥ 100KΩ
RESET	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	Thẻ	Máy chủ	Diễn giải
READY INPACK#WAIT# WP = IOIS16#		Đưa lên VCC ≥ 10KΩ
READY INPACK#WAIT# WP = IOIS16#		Tải điện dung ≤ 50pF

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Ω
A[14:0]	Tải điện dung ≤ 100pF
D[7:0]	Đưa xuống GND ≥ 100KΩ
	Tải điện dung ≤ 50pF

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] MISTRT MICLK MIVAL	Đưa xuống GND ≥ 100KΩ
MDI[7:0] MISTRT MICLK MIVAL	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.

Các yêu cầu tải đối các 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 MOVAL	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	Lớn 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	“Vcc“	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	0.5	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ớ thuộc tính được sử dụng để lưu trữ thông tin nhận dạng và cấu hình CICAM và không được yêu cầu một không gian địa chỉ lớn. Để truy nhập bộ nhớ thuộc tính, tín hiệu REG # được giữ ở trạng thái hoạt động. Việc hỗ trợ bộ nhớ thuộc tính đối với máy chủ và CICAM là bắt buộc. Sau khi thay đổi chân, CICAM phải cung cấp ít nhất địa chỉ thanh ghi tùy chọn cấu hì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.

• CICAM phải giải mã 4 vị trí địa chỉ trong chế độ I/O sử dụng đường địa chỉ A [1:0] và phải bỏ qua đường địa chỉ A [14: 2] trong chế độ I/O.

• Để 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.

• CE2 # không được CICAM sử dụng và luôn luôn là “điện áp cao”.

• 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.

• Nhiều CAM có thể dùng chung WE #

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.

• Nhiều CAM có thể dùng chung REG #

Đọ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 # bị CICAM chiếm để tăng thời gian hoàn thành hoạt động đọc hoặc ghi bộ nhớ hoặc I/O.

• 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ủ.

Dòng truyền tải MPEG của giao diện chung có các tín hiệu được quy định dưới đây.

Đầ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],

• 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.

• 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

• 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 MDO [7: 0].

Đầ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].

Xung nhịp đầu ra MPEG MCLKO

• 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 giảm được định nghĩa là thời gian chuyển tiếp từ Vh_min sang Vl_max được quy định tại điều K.1.5.

• 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.

Bảng K.11 – Các thông số quy định thời gian đọc bộ nhớ thuộc tính

Mục	Ký hiệu	300 ns
Mục	Ký hiệu	min	max
Read Cycle Time	t_cR	300
Address Access Time	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
Data valid from Add Change	t_v(A)	0
Address Setup Time¹	t_su(A)	100
Address Hold Time ¹	t_h(A)	35
Card Enable Setup Time ¹	t_su(CE#)	0
Card Enable Hold Time ¹	t_h(CE#)	35
WAIT# valid from OE# ¹	t_v(WT- OE#)		100
WAIT# Pulse Width ⁶	t_w(WT)		12 μs
Data Setup for WAIT# Released	t_v(WT)	0

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	Ký hiệu	250 ns
Mục	Ký hiệu	min	max
Write Cycle Time	t_c(W)	250
Write Pulse Width	t_w(WE#)	150
Address Setup Time ¹	t_su(A)	30
Address Setup Time for WE# ¹	t_su(A-WE#)	180
Card Enable Setup Time for WE#	t_su(CE#-WE#)	180
Data Setup Time for WE#	t(D-CE#)	80
Data Hold Time	t_h(D)	30
Write Recover Time	t_rec(WE#)	30
Output Disable Time from WE#	t_dis(WE#)		100
Output Disable Time from OE#	t_dis(OE#)		100
Output Enable Time from WE#	t_en(WE#)	5
Output Enable Time from OE#	t_en(OE#)	5
Output En. Setup from WE#	t_su(OE#-WE#)	10
Output Enable Hold from WE#	t_h(OE#-WE#)	10
Card Enable Setup Time ²	t_su(CE#)	0
Card Enable Hold Time²	t_h(CE#)	20
WAIT# Valid from WE# ²	t_v(WT-WE#}		35
WAIT# Pulse Width ⁴	t_w(WT)		12 μs
WE# High from WAIT# released ³	t_v(WT)	0

CHÚ THÍCH:

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

Mục	Ký hiệu	min	max
Data Delay after IORD#	t_su(D)		100
Data Hold following IORD#	t_h(D)	0
IORD# Width Time	t_w(IORD)	165
Address Setup before IORD#	t_su(A)	70
Address Hold following IORD#	t_h(A)	20
CE# Setup before IORD#	t_su(CE#)	5
CE# Hold following IORD#	t_h(CE#)	20
REG# Setup before IORD#	t_su(REG#)	5
REG# Hold following IORD#	t_h(REG#)	0
INPACK# Delay Falling from IORD#	_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
NOTE: All timings in ns.

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#	t_su(D)	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#	t_su(CE#)	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	t_dr(WAIT#)	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

Hình K.8 – Sơ đồ định thời các tín hiệu dòng truyền tải MPEG.

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
Mục	Ký hiệu	72 MBits/s	96 MBits/s
Clock Period	t_cl_k_p	111	83
Clock High Time	t_cl_kh	40	20
Clock Low Time	t_cl_kl	40	20
Input Data Setup Time	t_su	15	10
Input Data Hold Time	t_h	10	10
Output Data Setup Time	t_osu	20	10
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

L.1. ID 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ủ	CAM	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	ÙÚ
	00 01 00 42	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	Ú
Thông tin ứng dụng	00 02 00 41	2	1	1	application_info_enq	9F 80 20	Ú		Có	EN 50221
					application_info	9F 80 21	Ù
					enter_menu	9F 80 22	Ú
	00 02 00 42	2	1	2	application_info_enq	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
					application_info	9F 80 21	Ù
					enter_menu	9F 80 22	Ú
					request_cicam_reset	9F 80 23	Ù
					data_rate_info	9F 80 24	Ú
Hỗ trợ truy nhập có điều kiện	00 03 00 41	3	1	1	ca_info_enq	9F 80 30	Ú		Có	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ó	EN 50221
					replace	9F 84 01	Ù
					clear_replace	9F 84 02	Ù
					ask_release	9F 84 03	Ú
	00 20 00 42	32	1	2	tune	9F 84 00	Ù		Có	Cl Plus 1.3
					replace	9F 84 01	Ù
					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	1	date_time_enq	9F 84 40	Ù		Có	EN 50221
					date_time	9F 84 41	Ú
MMI	00 40 00 41	64	1	1	close_mmi	9F 88 00	Ú		Chỉ mức cao	EN 50221
					display_control	9F 88 01	Ù
					display_reply	9F 88 02	Ú
					text_last	9F 88 03	Ù
					text_more	9F 88 04	Ù
					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	Ù
					menu_answ	9F 88 0B	Ú
					list_last	9F 88 0C	Ù
					list_more	9F 88 0D	Ù
					subtitle_segment_last	9F 88 0E	Ù
					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	Ù
					subtitle_download_more	9F 88 15	Ú
					flush_download	9F 88 16	Ù
					download_reply	9F 88 17	Ù
Giao tiếp tốc độ thấp	00 60 xx x1	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	9F 8C 01	Ù
					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		2	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	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 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	9F 8C 03	Ù
					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	Ù		Có	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	Ù
					cc_sac_data_cnf	9F 90 08	Ú
					cc_sac_sync_req	9F 90 09	Ù
					cc_sac_sync_cnf	9F 90 10	Ú
	00 8C 10 02	140	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	Ù
SAS	00 96 10 01	150	64	1	SAS_connect_rqst	9F 9A 00	Ú		Không	Cl Plus
					SAS connect_cnf	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)	9F 9A 04	ÙÚ
					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ó	TS 101 699
					RequestStartAck	9F 80 01	Ú
					FileRequest	9F 80 02	Ú
					FileAcknowledge	9F 80 03	Ù
					AppAbortRequest	9F 80 04	ÙÚ
					AppAbortAck	9F 80 05	ÙÚ
	00 41 00 42	65	1	2	RequestStart	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	ÙÚ
Note 1: The synchronous SAS APDUs are not used by this specification
					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	Ù
					cc_sac_sync_cnf	9F 90 10	Ú
					cc_PIN_capabilities_req	9F 90 11	Ú
					cc_PIN_capabilities_reply	9F 90 12	Ù
					cc_PIN_cmd	9F 90 13	Ú
					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	9F 81 00	Ù		Có	Cl Plus
					Host_country	9F 81 01	Ú
					Host_language_enq	9F 81 10	Ù
					Host_language	9F 81 11	Ú
Nâng cấp CAM (CAM_Upgrade)	00 8E 10 01	142	64	1	cam_firmware_upgrade	9F 9D 01	Ù		Có	Cl Plus
					cam_firmware_upgrade_reply	9F 9D 02	Ú
					cam_firmware upgrade_progress	9F 9D 03	Ù
					cam_firmware_upgrade_complete	9F 9D 04	Ù
Hồ sơ nhà khai thác	00 8F 10 01	143	64	1	operator_status_req	9F 9C 00	Ù		Có	Cl Plus 1.3
					operator_status	9F 9C 01	Ú
					operator_nit_req	9F 9C 02	Ú
					operator_nit	9F 9C 03	Ù
					operator_info_req	9F 9C 04	Ú
					operator_info	9F 9C 05	Ù
					operator_search_start	9F 9C 06	Ú
					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	Ú

Phụ lục M

(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

Trong một môi trường Cl CAS thì kiến trúc của hệ thống khác nhau vì như không có liên kết chặt chẽ của hệ thống CA và quyền sở hữu hoàn toàn có thể không hợp lệ với nhà sản xuất, như được mô tả trong hình M.2. Một thiết bị thu không có CAS không bao gồm các hệ thống con CA và dựa vào mô-đun truy nhập có điều kiện (CAM) trên giao diện chung (Cl) để thực hiện các dịch vụ CA và giải xáo trộn. Một thiết bị thu không có CAS không có nhận biết về hệ thống CA mà nó được trao đổi, thay vào đó dựa trên giao thức giao diện chung [4,3] để thực hiện các dịch vụ CA và giải xáo trộn (có thể sử dụng tài nguyên MMI cấp cao của Cl).

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.

• Do đó, SAS_async_msg () được sử dụng để gửi dữ liệu không đồng bộ giữa các ứng dụng cụ thể trong máy chủ và CICAM.

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.

• Yêu cầu một định dạng bản tin chung trên SAS để ánh xạ hệ thống CA sang MHP API.

• 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.

Bảng M.1 – Cú pháp SAS_Async_Message APDU

Cú pháp	Số bit	Kiểu
SAS_async_msg() {	24	uimsbf
SAS_async_msg_tag	*
length_field()	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
send_datatype_nbr	8	uimsbf
for (i=0; i<send_datatype_nbr; i++) { datatype_id datatype_length data_type()
	8	uimsbf
}	16	uimsbf
}	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	Mô tả
Dự phòng	0x00		Dự phòng.
Dự phòng	0x01		Dự phòng.
CMD_ATR_GET_REQUEST	0x02	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 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	Truy vấn CICAM thông tin của các hệ thống 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.
CMD_HISTORY_GET_RESPONSE	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	HÙM	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.
CMD_NOTlFICATION_ENABLE	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	HÙM	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.
CMD_PIN_CHECK_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	HÚM	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.
CMD_PlN_SET_RESPONSE	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	0x19	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	HÙM	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	Trả lời bản tin Purchase Get Request của CICAM chứa thông tin sản phẩm của sự kiện
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	0x20	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	Yêu cầu được máy chủ gửi để truy vấn thông tin khe cắ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	0x25	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	Trả lời bản tin SmartCard Set Request của CICAM chứa thông tin thẻ thông minh trong khe cắm đã cho hoặc có nhận dạng đã cho.
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	0x30	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
CMD_MESSAGE_EVENT	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	HÚM	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	Bản tin sự kiện từ CICAM về sự thay đổi trạng thái sản phẩ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	0x50	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.

Bảng M.4 – Các nhận dạng loại dữ liệu

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.
dtid_byte_data()	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()	4	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	Thông báo trạng thái về sự thay đổi trong trạng thái quá trình mua hoặc một bản tin mới tới từ hệ thống CA.
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.
dtid_parental_level()	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()	14	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	Bản ghi thông tin trạng thái sản phẩm record.
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.
dtid_recharge_event()	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()	23	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	Yêu cầu thông tin thẻ thông minh.
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 5	Đượ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	Số bit	Kiểu
money() { currency	24	bslbf
num_of_decimals	3	uimsbf
sign	1	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..

num_of_decimals: Số chữ số thập phân của loại tiền tệ này.

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

time() {

mjd

utc

}

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.

utc: thời gian UTC được mã hóa BCD 4 bit gồm 6 số.

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

}

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	Số bit	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

Cú pháp	Số bit	Kiểu
Istring() { length	16	uimsbf
for (i=0; i<length; i++) { char	8	bslbf
} }

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.

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.

Bảng M.10 – Cú pháp trường locator

Cú pháp		Số bit	Kiểu
locator() {
	string_indicator if (string_flag == 1) {	1	bslbf
	length	7	uimsbf
	for (i=0; i<length; i++) { char }	8	bslbf
	} else {
	tsid_indicator	1	bslbf
	sid_indicator	1	bslbf
	event_indicator	1	bslbf
	reserved_zero	1	bslbf
	num_components	3	uimsbf
	original_network_id if (tsid_indicator == 1) {	16	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
	if (event_indicator == 1) { 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.

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.

original_network_id: trường 16-bit này quy định nhãn nhận dạng network_id của hệ thống cung cấp ban đầu của dịch vụ thông tin được chỉ ra.

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	Số bit	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.3.8. Mức kiểm soát của cha mẹ

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à:

parental_level: mức kiểm soát của cha mẹ của hệ thống CA. Các giá trị này được thể hiện trong Bảng M.13.

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	Chế độ hạn chế yêu cầu nhập thêm một mã PIN để có thể xem tất cả các chương trình PPV trừ những đánh giá và cho bất kỳ khán giả nào.
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
0x80-0xff	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

M.4. Các loại bản tin

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ả
dtid_smartcard_request()	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ả
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_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.

Bảng M.17 – Các loại dữ liệu bản tin yêu cầu hủy bỏ

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.

Bảng M.18 – Các loại dữ liệu bản tin trả lời hủy bỏ

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.

M.4.6. Bản tin CapabilitiesResponse

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.
dtid_cas_information()	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

Nhận dạng loại dữ liệu	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

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 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

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 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

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.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

Yêu cầu của máy chủ đến CICAM để cho phép hoặc vô hiệu thông báo sự kiện không đồng bộ khi thay đổi trạng thái của hệ thống CA và môi trường liên kết của nó. Không có trả lời phải được trả về cho lệnh này. Khi cho phép thông báo thì CICAM phải thông báo ngay cho máy chủ về trạng thái hiện tại bằng cách gửi thông báo sự kiện phản ánh trạng thái hiện tại của hệ thống CA, sau đó các thông báo sự kiện phải chỉ được gửi khi có sự thay đổi trạng thái cho đến khi thông báo bị vô hiệu hoặc phiên SAS bị đóng.

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.

data_type (): Không

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()	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ẹ 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ả
dtid _parental_level()	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

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_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

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.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

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu kiểm tra 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.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

ca_system_id: Nhận dạng của hệ thống CA để truy vấn.

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ả
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()	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

Nhận dạng loại dữ liệu	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.

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.31.

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à:

command_id: CMD_PRIVATE_DATA_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.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à:

command_id: CMD_PRIVATE_DATA_RESPONSE

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.

M.4.24. Bản tin Product Get Request

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.

M.4.25. Bản tin Product Get Response

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.
dtid_product()	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ả
dtid_object_identity()	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ả
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_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

Nhận dạng loại dữ liệu	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

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()	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.

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.40.

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.

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.41.

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.

M.4.32. Bản tin yêu cầu nạp tiền

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.

M.4.33. Bản tin trả lời 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.
dtid_wallet()	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

Nhận dạng loại dữ liệu	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

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_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.

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.46.

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.

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.47.

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à:

command_id: CMD_SMARTCARD_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.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.

dtid_user_data()

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ả
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.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ả
dtid_wallet_id()	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ả
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_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à:

command_id: CMD_ACCESS_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.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.

Sự kiện tín dụng có thể được sử dụng để thông báo cho thiết bị thu về một trạng thái tín dụng thay đổi liên quan đến nạp tiền cho ví tiền v.v.. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

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.
dtid_wallet()	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.

Bảng M.54 – Các loại dữ liệu bản tin sự kiện bản tin

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.5.4. Bản tin sự kiện yêu cầu PIN

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()	Yêu cầu mã PIN. 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_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

Nhận dạng loại dữ liệu	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

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.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.

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.58.

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.

Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

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()	Quá trình được liên kết với sự thay đổi quá trình mua này.
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

Nhận dạng loại dữ liệu	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

Nhận dạng loại dữ liệu	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

Nhận dạng loại dữ liệu	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.

Bảng M.63 – Cú pháp sự kiện truy nhập

Cú pháp		Số bit	Kiểu
dtid_access_event(){
	acccess_status	8	uimsbf
	description	*	string()
	object_id	*	string()
	private_data	*	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ị	Kiểu	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	Dịch vụ hiện đã bắt đầu giải xáo trộn.
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.
0x06	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	ACCESS_DENIED	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	CA không được sử dụng để giải xáo trộn sự kiện PPV hiện tại vì vấn đề đối với thẻ thông minh. Có thể lấy trạng thái thẻ thông minh bằng cách sử dụng các phương pháp cụ thể đối với thẻ thông minh khác.
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.
0x80-0xff	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

Số bit

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

dtid_cas_infomnation () chuyển tải thông tin về hệ thống CA. Định dạng chung phải được chuyển về định dạng trong Bảng M.66

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	16	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].

revision: Sửa đổi 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 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
	name	*	string()
	revision	*	string()
	version	*	string()
	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ợ.

eserved: Dự phòng trong tương lai.

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

Kiểu

dtid_credit_event() {

credit_status

description

object_id

private_data

}

uimsbf

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	Mô tả
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

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.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

}

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

Giá trị	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	PIN_ERROR	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	Tín dụng không đủ để mua sự kiện PPV.
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
9	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	CARD_DAMAGED	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	Dự phò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.
54	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	GENERIC_ERROR	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	Hệ thống bị lỗi nghiêm trọng và không thể đáp ứng yêu cầu.
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.

Bảng M.72 – Cú pháp trường quá trình

Cú pháp			Số bit	Kiểu
dtid_history() {
	type		8	uimsbf
	id		*	string()
	nid		32	uimsbf
	cancelled		1	bslbf
	status		7	uimsbf
	history_date		*	time()
	private_data If (type == HISTORY_TYPE_PPV) {		*	Istring()
		ppv_product_id	*	string()
		ppv_order_date
		ppv_item_status	*	time()
	} else if (type == HISTORY_TYPE_RECHARGE) {		8	uimsbf
	} else if (type == HISTORY_TYPE_RECHARGE) {
		recharge_value	*	money()
		recharge_source	8
		recharge_transaction_id
	}			string()
	else if (type == HISTORY_TYPE_MESSAGE) {
		message_subject	*
		message_body	*	string()
		message_priority	8	Istring()
		message_date	*	uimsbf
	}			time()
	else {
		properties	*
}	}			properties()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_history ():

Type: Loại quá trình được quy định trong Bảng M.73.

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	Mục 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.
0x80-0xff	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	Mô tả
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.
0x03	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	Không áp dụng	Đượ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	Mô tả
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	Sự kiện đã được mua và chưa được xem. Sự kiện đã bị trôi qua và tín dụng đã bị trừ tiền.
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_value: Giá trị nạp tiền dành cho mục của quá trình này.

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	RECHARGE_PROMOTIONAL	Đà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	Dự phò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ị	Kiểu	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	Mức ưu tiên cao
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

Bảng M.78 – Cú pháp sự kiện quá trình

Cú pháp	Số bit	Kiểu
dtid_history_event() {
history_status	8	uimsbf
description	*	string()
objectjd	*	string()
private_data }	*	string()

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_history_event ():

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	RECHARGE_HISTORY_CHANGED	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	Bản tin mới đã tớ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.

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.

M.6.9. Yêu cầu quá trình

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	4	bslbf
request_type if (request_type == ID_HISTORY) {	4	uimsbf
history_id else if (request_type == NID_HISTORY) {	*	string()
history nid } private_data }	32	uimsbf
history nid } private_data }	*	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:

Bảng M.81 – Các giá trị loại yêu cầu quá trình

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
0x2	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	NID_HISTORY	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.

Bảng M.82 – Cú pháp loại dữ liệu của số index

Cú pháp

Số bit

Kiểu

dtid_numeric_index() {

numeric_index

}

uimsbf

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_numeric_index ():

identity: Giá trị số được phân tích trong bối cảnh của loại bản tin.

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

dtid_parental_level() {

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

Cú pháp

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..

M.6.14. Sự kiện yêu cầu PIN

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() {
	pin_type	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_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.

desscription: Mô tả văn bản của sự kiện.

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	3	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	Dự phòng.
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	Được người sử dụng xác định.

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	Mã PIN không được yêu cầu và cho phép
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		Số bit	Kiểu
dtid_product() {
	product_type	8	uimsbf
	id	*	string()
	name	*	string()
	description	*	string()
	xdescription	*	Istring()
	pw_start_time	*	time()
	pw_end_time	*	time()
	preview	*	duration()
	cost	*	money()
	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	*	time()
	sub_end_time	16	uimsbf
	sub_num_services
	for (i=0; i<sub_num_services; i++) { 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.
0x01	Sản phẩm chung
0x02	Sự kiện PPT.
0x03	Sự kiện PPE.
0x04	Gói PPV.
0x05	Gói SUB.
0x06-0x7f	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.

preview: Thời gian xem trước kết hợp với sản phẩm này. Nếu không có thời gian xem trước thì trường này không được 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_start_time: Thời gian bắt đầu của cửa sổ mua trả tiền theo lần xem.

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

Trạng thái thông báo về sản phẩm từ hệ thống CA. Định dạng chung của dữ liệu trạng thái sản phẩm này phải được chuyển về định dạng như trong Bảng M.92.

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	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_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

Giá trị	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	EVENT_BEGIN	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	Đượ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 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
dtid_product_info() {
	purchase_status	4	bslbf
	is_current_service	1	bslbf
	reserved	3	bslbf
	access_state	8	uimsbf
	product_id	*	string()
	private_data	*	Istring()
}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_product_info ():

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	PURCHASE_STATUS_NOT_PURCHASABLE	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	Thẻ thông minh không có tín dụng. Nếu sự kiện này miễn phí thì đây không là một trạng thái mua
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.

private_data: dữ liệu riêng tùy chọn liên quan đến trạng thái mua.

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() {
reserved	3	bslbf
request_qualifier	2	uimsbf
type if (request_qualifier == PRODUCT_ID) {	3	uimsbf
product_id } else if (request_qualifier == PRODUCT_LOCATOR) {	*	string()
locator }	*	locator()
locator }
private_data	*	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ị	Kiểu	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	Yêu cầu (các) sản phẩm có locator đã cho
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	ALL_PRODUCT	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	Yêu cầu (các) sản phẩm được đề xuất.
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

Cú pháp		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 ():

id: Nhận dạng hệ thống CA cấp cho việc mua, 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. Khi một yêu cầu mua được thực hiện thì trường này có thể là chuỗi rỗng cho đến khi được hệ thống CA cấp cho.

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
dtid_recharge() {			4	bslbf
	reserved		4	uimsbf
	request_type		*	string()
	phone		*	string()
	user		*	string()
	password		*	string()
	ip_address		*	string()
	port
	if (request_type == CREDIT_CARD_MODE) {
		surname	*	string()
		name	*	string()
		card_number	*	string()
		start_date	16	bslbf
		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

Giá trị	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	SCRATCH_CARD_MODE	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.

sur name: Tên họ chủ thẻ tín dụng.

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

Trạng thái thông báo về việc nạp tiền từ hệ thống CA. Định dạng chung của dữ liệu sự kiện nạp tiền phải được chuyển về định dạng trong Bảng M.102.

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	8	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ụ

Cú pháp

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.

M.6.24. Khe cắm

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() {
	slot_id	8	uimsbf
	slot_status	8	uimsbf
}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_slot ():

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.
0x01	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	SLOT_STATUS_CARD_MUTED	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	Trạng thái chưa biết, trạng thái của khe cắm chưa nhận được
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

Cú pháp		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_status: Trạng thái khe cắm, các giá trị được quy định trong Bảng M.105.

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		Số bit	Kiểu
dtid_smartcard() {
	id	*	string()
	status	8	uimsbf
	slot_id	8	uimsbf
	expiry_date	*	time()
	id_number	*	string()
	version	*	string()
	provider_name	*	string()
	service_provider_name	*	string()
	user_data	*	string()
	num_pin_codes for (i=0; i<num_pin_codes; i++) {	8	uimsbf
	pin_id } num_wallets	*	string()
	pin_id } num_wallets	8	uimsbf
	for (i=0; i<num_wallets; i++) {	8	uimsbf
	wallet_id } current_wallet	*	string()
	wallet_id } current_wallet	*	string()
	additional_info	*	properties()
	private_data	*	string()
}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_smartcard ():

id: Nhận dạng hệ thống CA cấp cho các thẻ thông minh, 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 thẻ thông minh. Đây là một chuỗi văn bản có độ dài biến đổi.

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	SCS_INVALID	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	Thông báo thẻ thông minh bị treo. 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.
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.
0x08	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	Không áp dụng	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).

service_provider_name: Tên của nhà cung cấp dịch vụ cung cấp thẻ.

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

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 thẻ thông minh phải được chuyển về định dạng trong Bảng M.109.

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	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_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.

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.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ị	Kiểu	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	Thẻ thông minh nằm trong khe cắm xác định.
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

Cú pháp

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

Ví tiền thể hiện chi tiết lượng tiền được đăng ký với hệ thống (thường là thẻ thông minh). Định dạng chung của ví tiền phải được chuyển về định dạng như trong Bảng M.113.

Bảng M.113 – Cú pháp trường Wallet

Cú pháp		Số bit	Kiểu
dtid_wallet() {
	product_type	8	uimsbf
	id	*	string()
	name	*	string()
	balance	*	money()
	expiry_date	*	time()
	transaction_count	16	uimsbf
	transaction_remain	8	uimsbf
}

Ngữ nghĩa dành cho cú pháp loại dữ liệu dtid_wallet ():

id: Nhận dạng hệ thống CA được cấp cho ví tiền, 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 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

Số bit

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 cung cấp một danh sách MHP API và các lệnh Cl Plus.

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
		open_session_request()	APDU
		open_session_response()	APDU
		close_session_request()	APDU
		close_session_response()	APDU
		SAS_connect_rqst()	APDU
		SAS_connect_cnf()
CAManager	getCAProvider() getCARevision() getCAVersion() getSlots()	CMD_CAPABILITIES_REQUEST
CAManager	getCurrentProducts() getNextProducts()	CMD_PRODUCT_GET_REQUEST
CAManager	getParentalControlLevel()	CMD_PARENTAL_LEVEL_GET_REQUEST
CAManager	setParentalControlLevel()	CMD_PARENTAL_LEVEL_SET_REQUEST
CAManager	getPins()	CMD_PIN_GET_REQUEST
PIN	setRequired() reset() change()	CMD_PIN_SET_REQUEST
PIN	check()	CMD_PIN_CHECK_REQUEST
PIN	isRequired() getRetriesRemaining() isValidated()	Xem CAManager::getPins()
Khe cắm	getStatus()	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()	CMD_SMARTCARD_GET_REQUEST
Thẻ thông minh	setUserData() setUsedWallet()	CMD_SMARTCARD_SET_REQUEST
CAAcessEvent	CAAdapter() getType()	CMD_ACCESS_EVENT
CAProductEvent	CAProductEvent	CMD_PRODUCT_EVENT
CreditsEvent		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		CMD_SMARTCARD_EVENT
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	getSlicePrice() getSliceDuration() getType()	CMD PRODUCT_GET_REQUEST
PPVPackage	isFree() getType()	CMD PRODUCT_GET_REQUEST
Subscription	getSubscriptionStart() getSubscriptionEnd() getServices() isFree() getType()	CMD PRODUCT_GET_REQUEST
request	BuyRequest()	CMD_PURCHASE_SET_REQUEST
request.CARequest	cancel()	CMD_PURCHASE_CANCEL_REQUEST
request.CARequest	setPrivateData()	CMD_PURCHASE_SET_REQUEST
request.CARequest	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	buyResponseEvent()	CMD_PURCHASE_SET_RESPONSE
FailureResponseEvent	FailureResponseEvent() getErrorCode()	CMD_*_RESPONSE
HistoryResponseEvent	HistoryResponseEvent() getHistory()	CMD_HISTORY_GET_RESPONSE
HistoryUpdateRequest	HistoryUpdateRequest() getHistory()	CMD_HISTORY_SET_REQUEST
HistoryUpdateResponseEv	HistoryUpdateResponseEvent()	CMD_HISTORY_SET_RESPONSE
ProductlnfoRequest	ProductlnfoRequest() getProduct()	CMD_PRODUCT_INFO_GET_REQUEST CMD_PRODUCT_INFO_GET_RESPONSE
RcRechargeRequest	RcRechargeRequest() getRcParameter()	CMD_RECHARGE_REQUEST
RcRechargeResponse	RcRechargeResponse() getRechargeValue() getWallet	CMD_RECHARGE_RESPONSE
R.Offered Products	RetrieveOfferedProductsRequest()	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.

N.1. Thông tin dịch vụ

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	Kiểm soát ngăn chặn máy chủ của Cl Plus.
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 các thông số truyền thay đổi.

• 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	Thực hiện	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	0xcb	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	Phải được đặt trước bằng một nhãn xác định dữ liệu riêng Cl Plus.
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	Ob/Or	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	0x5f	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	Một biểu tượng hình ảnh của nhà điều hành dịch vụ có thể được máy chủ tùy chọn sử dụng trong bất kì phần lựa chọn mạng, băng chương trình và EPG
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.

Máy chủ phải bao gồm tất cả các dịch vụ trong danh sách kênh logic được nhãn mô tả này quy định, bất kể là máy chủ có thể hiển thị service_type này. CICAM phải tạo hồ sơ các dịch vụ này dựa trên thông báo service_type của máy chủ và những hạn chế hoạt động theo quy định của nhà điều hành dịch vụ (có thể yêu cầu các loại dịch vụ không được hỗ trợ có trong danh sách kênh logic của máy chủ).

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	16	uimsbf
	service_type	8	uimsbf
	visible_service_flag	1	bslbf
	selectable_service_flag	1	bslbf
	logical_channel_number	14	uimsbf
	service_provider_name_length	8	uimsbf
	for (i=0; i<N; i++} {
	char	8	uimsbf
	} service_name_length	8	uimsbf
	for (i=0; i<N; i++) {	8	uimsbf
	char }
}

Trong đó các trường được quy định như sau:

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.

service_name_length: trường 8-bit này xác định số byte tiếp theo trường service_name_length để mô tả các ký tự của tên dịch vụ.

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	// Chồng lên tên nhóm chung phải xuất hiện sau các nhãn cụ thể
	// 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(){
descriptor_tag	8	uimsbf
descriptor_length	8	uimsbf
content_byte_min	8	uimsbf
content_byte max	8	uimsbf
ISO_639_language_code	24	bslbf
for (i=0; i<N; i++} {
label_char	8	uimsbf
} }

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.

endif.

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ẻ	Thực hiện	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
private_data_specifier_descriptor	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à

SDT:: EIT_schedule_flag đã bị bỏ lỡ thông báo. Tính sẵn có của thông tin EIT sẵn có dành cho máy chủ có thể được xác định từ các trường eit_schedule_usage và operator_info () APDU eit_present_following_usage.

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)

N.2.1. Tổ chức danh sách kênh logic

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ụ

Các dịch vụ phải được bổ sung vào danh sách kênh tuân theo các quy tắc của ciplus_service_descriptor; tất cả các dịch vụ được yêu cầu một cách rõ ràng trong danh sách kênh phải được nhãn mô tả này thông báo. Dịch vụ này phải được bao gồm không phân biệt máy chủ có thể giải mã được loại dịch vụ này, CICAM được thông báo về các loại dịch vụ được máy chủ nhận biết và có thể dò kênh danh sách dịch vụ theo thông tin này của máy chủ và các yêu cầu của nhà điều hành 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).

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Ố – YÊU CẦU KỸ THUẬT ĐỐI VỚI GIAO DIỆN CHUNG MỞ RỘNG (CI PLUS)
Số, ký hiệu văn bản	TCVN11819:2017	Ngày hiệu lực
Loại văn bản	Tiêu chuẩn Việt Nam	Ngày đăng công báo
Lĩnh vực	Giao dịch điện tử Điện lực	Ngày ban hành	01/01/2017
Cơ quan ban hành		Tình trạng	Còn hiệu lực

Các văn bản liên kết

Văn bản được hướng dẫn		Văn bản hướng dẫn
Văn bản được hợp nhất		Văn bản hợp nhất
Văn bản bị sửa đổi, bổ sung		Văn bản sửa đổi, bổ sung
Văn bản bị đính chính		Văn bản đính chính
Văn bản bị thay thế		Văn bản thay thế
Văn bản được dẫn chiếu		Văn bản căn cứ

Tải văn bản

Tải văn bản về Bản PDF/Bản gốc