TCVN TIÊU CHUẨN QUỐC GIAenglish.mic.gov.vn/.../Du-thao-TCVN-CI-Plus-TCVN--Final.docx · Web viewTCVN xxxx : 2016 do Viện Khoa học Kỹ thuật Bưu Điện biên soạn,

TCVN T I Ê U C H U Ẩ N Q U Ố C G I A

TCVN xxxx : 2016Xuất bản lần 1

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)

HÀ NỘI - 2016

3

Mục lục

1 Phạm vi áp dụng.................................................................................................................................10

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

3 Định nghĩa, ký tự và chữ viết tắt.......................................................................................................14

3.1 Định nghĩa......................................................................................................................................14

3.2 Ký tự...............................................................................................................................................15

3.3 Chữ viết tắt.....................................................................................................................................15

4 Tổng quan hệ thống .........................................................................................................................18

4.1 Giới thiệu........................................................................................................................................18

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

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

4.4 Chứng thực thiết bị.........................................................................................................................20

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

4.6 MMI nâng cao.................................................................................................................................21

4.7 Các mở rộng của CI Plus...............................................................................................................21

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

5.1 Kiến trúc..........................................................................................................................................22

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

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

5.4 Triển khai mô-đun...........................................................................................................................29

5.5 Giới thiệu phương pháp thu hồi ....................................................................................................37

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

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

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

5.9 Tổng quan chứng thực...................................................................................................................62

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

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

5.12 Ghi lại............................................................................................................................................71

5.13 Cung cấp SRM.............................................................................................................................73

6 Cơ chế chứng thực............................................................................................................................77

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

6.2 Giao thức chứng thực.....................................................................................................................81

6.3 Chứng thực lại khi bật nguồn điện.................................................................................................92

TCVN xxxx :20167 Kênh được chứng thực an toàn.......................................................................................................93

7.1 Hoạt động CI SAC..........................................................................................................................95

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

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

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

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

8 Các tính toán mã khóa nội dung.....................................................................................................108

8.1 Giao thức làm mới mã khóa kiểm soát nội dung..........................................................................108

9 Chi tiết giấy chứng nhận và PKI.....................................................................................................113

9.1 Giới thiệu......................................................................................................................................113

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

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

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

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

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

10.2 Nhận được tin cậy......................................................................................................................125

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

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

11 Giao diện lệnh.................................................................................................................................130

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

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

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

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

12 MMI cấp ứng dụng CI Plus............................................................................................................159

12.1 Phạm vi.......................................................................................................................................159

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

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

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

12.5 Ký tự của công cụ.......................................................................................................................166

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

12.7 Ánh xạ tên...................................................................................................................................170

12.8 Các phần mở rộng VOD.............................................................................................................171

12.9 Hướng dẫn và quy định thực hiện MHEG-5...............................................................................173

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

4

TCVN xxxx : 201613.1 MMI cấp thấp..............................................................................................................................175

13.2 MMI cấp cao...............................................................................................................................175

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

13.4 Trình đơn CICAM.......................................................................................................................175

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

14.1 Tài nguyên truyền tốc độ thấp phiên bản 3................................................................................177

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

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

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

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

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

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

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

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

Phụ lục B - Giao thức ID thiết bị (quy định)....................................................................................246

B.1 Bản quy định kỹ thuật ID thiết bị.............................................................................................246

Phụ lục C - Các thuật toán kiểm tra tổng dành cho các ID thiết bị và ARC (quy định)...............247

C.1 Thuật toán kiểm tra tổng dành cho các ID thiết bị.................................................................247

C.2 Kiểm tra tổng ARC....................................................................................................................249

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

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

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

E.1 Khởi tạo......................................................................................................................................252

E.2 CA_PMT rõ ràng........................................................................................................................252

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

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

E.5 MMI tức thời...............................................................................................................................253

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

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

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

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

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

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

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

5

TCVN xxxx :2016E.13 Các yêu cầu vật lý..................................................................................................................256

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

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

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

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

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

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

E.20 Cung cấp CA PMT..................................................................................................................259

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

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

E.23 Các lệnh ca_pmt....................................................................................................................260

E.24 O pen_session_response ......................................................................................................260

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

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

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

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

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

G.2 Chế độ ngắt................................................................................................................................266

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

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

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

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

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

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

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

Phụ lục K - Bản quy định kỹ thuật điện (quy định).........................................................................276

K.1 Bản quy định kỹ thuật điện......................................................................................................276

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

L.1 ID tài nguyên..............................................................................................................................295

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

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

M.1 Giới thiệu (tham khảo)..............................................................................................................301

M.2 Định dạng bản tin (quy định)....................................................................................................304

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

6

TCVN xxxx : 2016M.4 Các loại bản tin..........................................................................................................................315

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

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

M.7 Ánh x ạ MHP API........................................................................................................................361

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

N.1 Thông tin dịch vụ (quy định)....................................................................................................365

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

7

TCVN xxxx :2016

Lời nói đầu

TCVN xxxx : 2016 được xây dựng trên cơ sở tham khảo tiêu chuẩn CI Plus Specification v1.3 (2011-01) của CI Plus LLP.

TCVN xxxx : 2016 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ố.

8

TCVN xxxx : 2016

9

TCVN xxxx :2016

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)

1 Phạm vi áp dụng

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

Tiêu chuẩn này mô tả một hệ thống như vậy, bao gồm tất cả các quy tắc để chứng 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ủ. Phạm vi này không liên quan đến một hệ thống CA cụ thể và mở rộng vượt ra ngoài máy chủ. Phạm vi này cũng không giới hạn ở một loại giao diện cụ thể nào, tuy nhiên hiện tại 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.

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 CI Plus. Tiêu chuẩn này được dựa trên, và mở rộng, các tiêu chuẩn CI hiện có; EN 50221 [7] và TS 101 699 [8].

Để đảm bảo an ninh tối ưu trong một môi trường có các cá nhân sẵn sàng dành thời gian và công sức trong việc phá vỡ hệ thống như vậy, 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à chứng thực thiết bị và bản tin.

Việc chứng thực giữa CICAM và máy chủ cung cấp sự xác nhận đối với CICAM rằng nó đang hoạt động với một máy chủ hợp pháp; tương tự như 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 độc lập và thông tin đi qua giao diện chung không đủ để một thiết bị thứ ba 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 không 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 quá trình cấp giấy chứng nhận phù hợp, và tùy thuộc vào sự tuân thủ phù hợp của nhà sản xuất đối với Các nguyên tắc mạnh mẽ CI Plus [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.

T I Ê U C H U Ẩ N Q U Ố C G I A TCVN xxx:2016

10

Hp4530, 09/10/14,

key generation

TCVN xxxx : 20162 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/fips180-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 . FIPS PUB 197: 26 tháng mười một năm 2001. Bản quy định kỹ thuật dành cho chuẩn Mã hóa nâng cao (AES), Viện của Tiêu chuẩn và Công nghệ quốc gia. 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

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

11

http://pda.etsi.org/pda/queryform.asp




http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://www.ci-plus.com/

http://www.ci-plus.com/

http://www.scte.org/documents/pdf/ANSISCTE412004.pdf

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

TCVN xxxx :2016SHS 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

ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions – Part 1: Country codes . ISO 3166-1: 1997. Mã dành cho các tên quốc gia và các khu vực trong quốc gia đó - Phần 1: Các mã quốc gia

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.

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

12

http://www.dtg.org.uk/publications/books.html

http://www.ietf.org/rfc/rfc4055.txt

http://www.ietf.org/rfc/rfc3280.txt

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm

TCVN xxxx : 2016và 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

CI Plus Licensee Specification, available under licence from the CI Plus Trust Authority. Bản quy định kỹ thuật cấp giấy phéo CI Plus, có sẵn theo giấy phép của Tổ chức tin cậy CI 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

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

13

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22b.pdf

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22b.pdf

ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

http://translate.google.com/translate?hl=vi&prev=_t&sl=en&tl=vi&u=http://www.cenelec.org/Cenelec/Homepage.htm

TCVN xxxx :2016ITU-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

RFC1123; 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:

Chứng thực: Một thủ tục để xác nhận một cách an toàn rằng một máy chủ hoặc CICAM có giấy chứng nhận chính hãng và giấy chứng nhận chưa bị thu hồi. Ngoài ra, là một phương pháp để xác nhận một cách an toàn rằng bản tin có nguồn gốc từ một nguồn đáng tin cậy.

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

Chế độ by-pass : 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.

Băng truyền: 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.

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

Nội dung được kiểm soát: nội dung được kiểm soát có nghĩa là nội dung đã được truyền từ Headend 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).

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

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

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

Head-end: thiết bị đầu cuối.

Máy chủ/Thiết bị chủ/ chính: thiết bị có khe CAM tuân thủ CI Plus.

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

Mã hóa: 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")

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.

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

Xáo trộn lại: Chế độ của CICAM có nội dung CA-descrambling và CC-scrambling

Kênh được chứng thực an toàn: đường truyền an toàn giữa máy chủ và CICAM.

Xáo trộn: 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")

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

14

TCVN xxxx : 2016Nội dung không kiểm soát: Nội dung được chỉ ra bởi giá trị EMI = 00.

Xác nhận: Quá trình thông báo HOST_ID đến nhà điều hành hệ thống, kiểm tra nó với một danh sách thu hồi, thông báo HOST_ID xác nhận trở lại CICAM, và CICAM xác nhận nó phù hợp với HOST_ID được lưu trữ.

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) Chứng thực của bản tin 'M' với khóa 'K'

VK (M) Kiểm tra bản tin 'M' với khóa 'K'

AB Toán tử XOR của 'A' và 'B'

A | B Toán tử OR của 'A' và 'B'

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

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 tiên

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

15

TCVN xxxx :2016

CI Common Interface Giao diện chung

CICAMCommon 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 TokenBit nhận biết sử dụng nén đối với nội dung số

DSM-CCDigital 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_IDHost device unique identification number

Số nhận dạng duy nhất thiết bị máy chủ

ICT Image Constraint Token Bít nhận biết nén hình ảnh

IV Initialisation Vector Vector 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ã chứng 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

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

16

TCVN xxxx : 2016

PCMCIAPC 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

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)

RSARivest 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 chứng thực an toàn

SAK SAC Authentication Key Mã khóa chứng 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 Vector Vec tơ khởi tạo SAC

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

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

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

SMSShort 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 chứng 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 Số nguyên không dấu bit quan trọng nhất

17

TCVN xxxx :2016

first đầ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. Hàm lượng giá trị cao có thể được bảo vệ từ head-end đế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.

MUX/ bộ điềuchế củaHead-end

Hệ thống CAECM/EMM

Hệ thống CABộ tạomã khóa

Hệ thống CABộ tạo mãmã khóa

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

Bộ dò kênh Giải mã CC

Bộ giảighép kênh

Bộ giảiđiều chế

CICAM

Giao diện chung

Nhà cung cấpnội dung

CICAM Pass Through

Máy chủPassby

Hệ thống CABộ giải mãmã khóa

Hệ thống CATính mã khóa

Hệ thống CCCác công cụmã hóa

Mã hóa CC

Thẻ thông minh

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

18

TCVN xxxx : 20164.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 CI 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ị CI 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ủ

CI CI Plus

CICAM

CI

Hành vi CI 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 CI 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 CI CAM giải mã không được mã hóa lại trên giao diện chung.

CI 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ội dung được kiểm soát không được hiện thị trừ khi CICAM và máy chủ đã

19

TCVN xxxx :2016

đến máy chủ dưới sự kiểm soát của hệ thống CA.

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

chứng thực và máy chủ hỗ trợ các thuật toán mã hóa được CI 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 chứng thực và tin cậy.

5.1.1 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 giao diện chung thuộc các phiên bản không là CI Plus, nội dung được truyền đến máy chủ rõ ràng qua kết nối CI bỏ ngỏ nội dung này mở để chặn và sao chép. 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ó chứng thực độ tin cậy của máy chủ mà nó đã được ghép vào. Nếu CICAM chứng 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.

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

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

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

Chứng 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 Head-end (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ủ.

5.3 Chứng thực thiết bị

Hệ thống kiểm soát nội dung yêu cầu chứng 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ó.

20

Hp4530, 09/15/14,

compromised

Hp4530, 09/29/14,

Implementation Outline

TCVN xxxx : 2016Việc chứng 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 chứng thực.

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

5.5 MMI nâng cao

CI Plus giới thiệu một công cụ trình bày tiêu chuẩn vào hồ sơ CI để 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 CI Plus" được mô tả trong mục 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 mục 13.

5.6 Các mở rộng của CI Plus

CI 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 mục 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.

21

TCVN xxxx :2016Các yêu cầu an toàn CI Plus và các mở rộng CI Plus yêu cầu truyền nhanh hơn qua liên kết CI đượ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.

5.6.1 Các mở rộng của CI Plus 1.3

CI Plus 1.3 giới thiệu một số cải tiến các tài nguyên trong CI Plus 1.2 và DVB-CI và thêm vào một số tài nguyên mới được mô tả trong mục 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 CI 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ủ CI 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.

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

Chứng 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 chứng 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.

6.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ừ head-end đến máy chủ bao gồm cả CICAM. Hướng lên của Head-end 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ỳ.

22

TCVN xxxx : 2016

Thiết bị đầu cuối Máy chủ Thiết bị khác

Ghi chú

Nằm ngoài phạm vi tiêu chuẩn này

Được CA bảo vệ

Được CC bảo vệCICAM

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

6.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 chứng 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 CI Plus hợp pháp thì một kênh chứng 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 chứng 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.

23

TCVN xxxx :2016

CICAM Máy chủ

Bước1 [1CICAM kích hoạt quá trình chứng thực.[2] Máy chủ tham gia quá trình chứng thực tương hỗ.

Bước2 [3] CICAM kích hoạt máy chủ để hiện thị MMI (chỉ dành cho chế độ đăng kýdịch vụ) [4] ok

Bước3 [5] CICAM yêu cầu mã khóa chứng thựccủa máy chủ. [6] máy chủ xác nhận mã khóa chứng thực

Bước4 [7] Thiết lập SAC[8] Thiết lập SAC

Bước5 [9] Thiết lập mã khóa giải xáo trộn/ xáo trộn lại nội dung[10] Thiết lập mã khóa giải xáo trộn/ xáo trộn lại nội dung

Bước6 [11] CICAM khởi tạo việc truyền URI info [12] Máy chủ áp dụngcác thiết lập của URI

[13] Máy chủ xác nhận

Ghi chú: Lưu đồ này 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

6.2.1 Ghi chú: bước # 1 khởi tạo (chứng thực) – kiểm tra giáy chứng nhận và trao đổi mã khóa DH

6.2.2

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

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

Mục 6

2 Máy chủ tham gia quá trình chứng 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 chứng thực tương hỗ.

Mục 6

Ghi chú: bước # 2 (chứng thực) – báo cáo lại (chỉ dành cho chế độ đăng ký dịch vụ)

6.2.3

3 CICAM kích hoạt máy chủ để hiện thị MMI (chỉ dành cho chế độ đăng ký dịch vụ).

Mục 5.4.2

4 CICAM có thể kích hoạt máy chủ để hiện thị MMI. Điều này làm hiện thị thông tin có thể được thông báo cho nhà điều hành, nhận dạng bằng tổ hợp của CICAM ID và Host ID (và ID của thẻ thông minh nếu yêu cầu). Nhà điều hành có thể sử dụng thông tin này để quyết định việc cho phép truy nhập đến dịch vụ đối với CICAM và máy chủ (và thẻ thông minh nếu yêu cầu).

24

TCVN xxxx : 2016


6.2.5 Ghi chú: bước # 3 khởi tạo (chứng thực) – kiểm tra mã khóa chứng thực

6.2.6

5 CICAM yêu cầu mã khóa chứng thực của máy chủ. Mục 6

6 CICAM yêu cầu mã khóa chứng thực (AKH) của máy chủ để xác định xem cả CICAM và máy chủ đã tính ra cùng một mã khóa. Máy chủ trả lời yêu cầu này bằng một mã khóa được nó tính ra.

6.2.8 Ghi chú: bước # 4 khởi tạo – thiết lập SAC 6.2.9

7 Thiết lập SAC.

Sau khi chứng 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à chứng 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.

Mục 7

8

6.2.12 Ghi chú: bước # 5 khởi tạo – thiết lập mã khóa CC 6.2.13

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

Sau khi chứng 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.

Mục 8

10

6.2.16 Ghi chú: bước # 6 khởi tạo – truyền và sử dụng kiểm soát sao chép nội dung

6.2.17

11 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 ghi chú 2.

Mục 5.7.4

12 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

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]

Mục 5.7.5.4

13

Ghi chú:

1. Tham chiếu các đến các mục 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

25

TCVN xxxx :20166.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.

DH_p DH_pDH_gDH_gHDQMDQ

PRNG_seed PRNG_seedGiấy chứng nhận gốcGiấy chứng nhận gốc

Giấy chứng nhận nhà sản xuất Giấy chứng nhận nhà sản xuấtGiấy chứng nhận thiết bịGiấy chứng nhận thiết bị

HOST_IDCICAM_ID

Lớp chứng thực

DHY (DH nonce y) DHY (DH nonce x)

DHPHDHPM

DHSKDHSK

AKM AKH

SAKSEK

SAKSEK

trao đổi

trao đổi

kiểm tra

Ns_Module (nonce từ mô đun) Ns_Host (nonce từ máy chủ)

SIVSIV

Lớp SAC

Lớp kiểm soát nộidung

Kp_moduelle (nonce từ mô đun)

CCKCIV

CCKCIV

Lớp chứng nhận

CICAM Máy chủ

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 certGiấ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ế)

26

TCVN xxxx : 2016

Mã khóa Mô tả Được lưu trữ hoặc thay đổi

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

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


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)


DH_q Hằng sô Diffie-Hellman Sophie Germain

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


MDQ Mã khóa riêng của mô đun được lưu trữ (hằng số giấy phép)


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)


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 chứng thực của mô đun được lưu trữ (trên mô đun)


AKH Mã khóa chứng 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 chứng 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)


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ộ

27

TCVN xxxx :20166.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 chứng 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.

6.3.2 Các mã khóa trên lớp chứng 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 chứng thực. Việc chứng 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 mục 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 mục 9.4 và mục 9 để biết chi tiết.

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

DHSK và AKM hoặc AKH được lớp chứng 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 chứng 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.

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

Lớp SAC sử dụng các mã khóa để chứng 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 chứng thực SAC (SAK) được sử dụng để chứng 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 mục 7 để biết chi tiết.

28

TCVN xxxx : 2016

Lớp chứng thực

Lớp chứng nhận

chứng nhận chứng nhận

Chứngthựcvà

kiểm tra

Chứngthựcvà

kiểm tra

Chứng thựcDHSKAKM

DHSKAKM

Traođổivà

xác nhận

Traođổivà

xác nhận

nonce

Bản tin SAC được chứng thực và mã hóa

Lớp SAC

m mESEK(m)ASAK(m)

DSEK(m)VSAK(m)

SEKSAK

SEKSAK

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

6.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 mục 8 để biết chi tiết.

Lớp kiểm soát nội dung

CCK(CIV)

CCK(CIV)

Truyềnvà

xác nhận

Truyềnvà

xác nhận

DCCK(C)ECCK(C)C CLưu lượng MPTS được mã hóa

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

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

6.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 chứng 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 chứng thực

3) Báo cáo trả về head-end

29

TCVN xxxx :2016Cả hai dịch vụ chế độ hỗ trợ giai đoạn chứng thực 1 và 2. Chỉ có chế độ đăng ký dịch vụ hỗ trợ giai đoạn chứng thực thứ ba: Báo cáo trả về head-end (xem Bảng 5.3).

Bảng 5.3 - Các giai đoạn chứng 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 chứng thực

Báo cáo trả về Head-end

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

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ệ CI Plus được giải xáo trộn CA.

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

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

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

Chứng thực lại khi bật nguồn điện (xem mục 6.3)

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

Kiểm tra mã khóa chứng thực (xem mục 6.3)

Thiết lập kênh chứng thực an toàn (SAC) (xem mục 7)

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

30

TCVN xxxx : 2016

Bắt đầu (1)

CICAMTương tác MMIthông báo lỗi (3)

A

A Hoạt độnghạn chế (10)

Hoạt độnghoàn toàn(9)

Kiểm tra mãkhóa chứngthực (6)

Thiết lập mãkhóa CC (8)

Thiết lậpSAC (7)

Kiểm tra giấychứng nhận vàtrao đổi mãkhóa DH (5)

Có

Có

Không

Chứng thựclại khi bậtnguồn điện (4)

Có tương thíchCI Plus củamáy chủ (2)

Không

Hình 5.6 – Quá trình chứng 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 chứng 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 CI Plus. Máy chủ tương thích CI 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 mục 12.3 và EN 50221 [7] mục 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 CI Plus máy chủ sẽ kiểm tra xem có thể chứng thực lại khi bật nguồn điện (4). Chứng 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 chứng thực (6)

31

TCVN xxxx :2016có 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 mục 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 mục 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 CI Plus CICAM bảo vệ và giải mã các dịch vụ được CI 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).

Không

Không

Không

Có

Có

KhôngCó

Có

Hoạt độnghạn chế (8)

Hoạt độnghoàn toàn (1)

Làm mớiSAC (2)

Làm mớimã khóa CC (4)

Thiết lậpmã khóa CC (5)


Thời gianchờ SAC

(6)

Thời gianchờ mãkhóa CC

(7)

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 Head-end 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 mục 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 mục 5.5 để biết chi tiết về cơ chế thu hồi CI Plus.

7.1.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 bao gồm một kênh truyền thông tin hai chiều. Kênh trả về có thể trực tuyến (ví dụ như modem cáp) hoặc ngoại tuyến (ví dụ như dịch vụ nhắn tin văn bản). Kênh trả về và các bản tin này nằm ngoài phạm vi tiêu chuẩn này.

32

TCVN xxxx : 2016Hình 5.8 đưa ra tổng quan của quá trình chứng thực trong chế độ đăng ký dịch vụ. Nó thực chất là một quá trình tương tự như mô tả trong hình 5.6 đối với chế độ dịch vụ cơ bản và sự khác biệt được nêu chi tiết trong mục này.

Nếu chứng thực lại khi bật nguồn điện (4) thành công, CICAM phải kiểm tra xem liên kết của nó được Head-en xác nhận (9) từ một yêu cầu đăng ký (7) trước đó. Trong trường hợp liên kết này được Head-end xác nhận thì nó có thể hoàn thành quá trình chứng thực bằng cách thiết lập một SAC (10) và mã khóa CC (11). Sau đó, CICAM trở thành hoạt động hoàn toàn (12), nếu không CICAM trở thành hoạt động hạn chế (13).

Nếu chứng thực lại khi bật nguồn điện (4) thất bại, trước tiên CICAM phải hoàn thành các bước kiểm tra giấy chứng nhận và trao đổi mã khóa DH (5) và kiểm tra mã khóa chứng thực. Khi hai bước được thực hiện thành công thì CICAM và thiết bị máy chủ chứng thực lẫn nhau, CICAM (và thiết bị máy chủ) phải tự đăng ký với Head-end (7). Khi đăng ký được thực hiện ngoại tuyến, CICAM sử dụng MMI cấp cao hoặc MMI ứng dụng để gửi một bản tin thông báo đăng ký (xem mục 5.4.2.1). Các nhà điều hành dịch vụ quyết định, dựa trên dữ liệu trong yêu cầu đăng ký, nếu CICAM và thiết bị máy chủ là hợp lệ thì gửi một bản tin trả lời, trong đó có ít nhất một số đăng ký, số nhận dạng thiết bị máy chủ và CICAM. Cú pháp bản tin, bảo vệ và truyền tải của nó nằm ngoài phạm vi của tiêu chuẩn này. CICAM đợi cho đến khi nhận được bản tin trả lời (8). Khi bản tin trả lời từ Head-end đến, CICAM xác nhận sự thành công của liên kết CICAM và máy chủ (9). Khi liên kết này thành công CICAM hoàn thành quá trình chứng thực bằng cách thiết lập một SAC (10) và mã khóa CC (11). CICAM trở thành hoạt động hoàn toàn (12), nếu không CICAM trở thành giới hạn hoạt động hạn chế (13). Đăng ký trực tuyến nằm ngoài phạm vi tiêu chuẩn này.

Quá trình làm mới lại SAC và mã khóa CC đối với chế độ đăng ký dịch vụ tương tự chế độ dịch vụ cơ bản (xem hình 5.7).

33

TCVN xxxx :2016

Bắt đầu (1)

Có tương thíchCI Plus củamáy chủ (2)

Chứng thựclại khi bậtnguồn điện (4)

Thiết bị đầu cuốicó hợp lệ

Bản tin củathiết bị đầu cuốicó nhận được

A

Kiểm tra giấychứng nhận vàtrao đổi mãkhóa DH (5)

Kiểm tra mãkhóa chứngthực (6)


CICAMTương tác MMIthông báo lỗi (3)

Yêu cầuđăng ký (7)

Thiết lậpmã khóa CC (11)

Hoạt độnghoàn toàn (12)

Hoạt độnghạn chế (13)

Không

Không

Không

Có

Có

Có

Có

A

Không

Hình 5.8 – Quá trình chứng thực trong chế độ đăng ký dịch vụ

34

TCVN xxxx : 20167.1.2.1 Các bản tin đăng ký

CICAM phải đăng ký với Head-end khi CICAM ở chế độ đăng ký dịch vụ (RSM). Bản tin thông báo đăng ký (xem hình 5.9) được hiển thị trên thiết bị máy chủ bằng cách sử dụng MMI cấp cao hoặc MMI ứng dụng sau khi giao thức chứng thực đã kết thúc thành công. Bản tin thông báo đăng ký chứa các thông tin sau:

Hướng dẫn cách thực hiện thủ tục đăng ký.

Nhãn định danh thiết bị duy nhất của CICAM (CICAM_ID).

Nhãn định danh thiết bị duy nhất của máy chủ (HOST_ID).

Nhãn định danh thiết bị duy nhất thẻ thông minh (Smartcard_ID). (Tùy chọn).

Để hiển thị HOST_ID hoặc CICAM_ID, trường 64-bit được lấy từ giấy chứng nhận và các bit nhị phân được chuyển đổi thành 20 chữ số. (Tùy chọn) số của thẻ thông minh có thể ít hơn 20 chữ số.

Để phát hiện lỗi trong quá trình truyền với các nhà điều hành mạng verbal (có thể bằng lời nói), kiểm tra tổng được thêm vào các ID của thiết bị, tạo thành một "mã". Thuật toán kiểm tra tổng ID của thiết bị yêu cầu đầu vào 20 chữ số. Bất kỳ ID của thiết bị có ít hơn 20 chữ số sẽ được thêm vào phía trước các số 0 (số không). (Xem Chuẩn cấp giấy phép CI Plus [33] đối với định dạng ID của thiết bị, Phụ lục C.1 đối với thuật toán kiểm tra tổng ID của thiết bị và Bảng 5.4 đối với quy định bản tin đăng ký thông báo).

Bảng 5.4 - Bản tin yêu cầu đăng ký

Trường Độ dài (số/ký tự) bao gồm cả kiểm tra tổng

RSM_CICAM_code 23

RSM_Host_code 23

RSM_Smartcard_code (tùy chọn) 23

RSM_Instruction 256

Kết thúc thủ tục đăng ký (tức là một bản tin thông báo đăng ký) các nhà điều hành mạng gửi CICAM một bản tin trả lời đăng ký. Cú pháp và bảo vệ bản tin trả lời đăng ký và truyền tải bản tin này từ nhà điều hành dịch vụ đến CICAM nằm ngoài phạm vi tiêu chuẩn này, điều này thường được một EMM thực hiện được hệ thống CA mạng bảo vệ.

Bản tin trả lời đăng ký bao gồm một số đăng ký và có thể được sử dụng trong tất cả các bản tin thông báo trong tương lai (xem mục 5.4.2.2).

Hình 5.9 đưa ra một ví dụ về một bản tin thông báo đăng ký. Một bản tin thông báo đăng ký có thể lựa chọn không hiển thị số không dẫn đầu.

35

TCVN xxxx :2016

Registration of your CI module is required.

Please send a text message to theregistration-desk at number 040-1234567containing the following codes:

XXXX XXXX XXXX XXXX XXXX XXXXXXX XXXX XXXX XXXX XXXX XXX XXXX XXXX XXXX XXXX XXXX XXX

Hình 5.9 - Ví dụ chụp từ màn hình của bản tin thông báo đăng ký

Hình 5.10 đưa ra một ví dụ về một bản tin trả lời đăng ký được CICAM hiển thị trong trường hợp có lỗi trong quá trình RSM. Trong trường hợp có một lỗi, bản tin trả lời đăng ký không chứa số đăng ký.

There was a technical problem during theauthorization process.

This product may have some componentfailure or is not designed to be compatiblewith digital TV services.

Please contact the help-desk at number040-7654321.

OK

Hình 5.10 - Ví dụ về thông báo lỗi của bản tin trả lời đăng ký

7.1.2.2 Các bản tin thông báo

Các bản tin thông báo được CICAM tạo ra trong chế độ đăng ký dịch vụ và được dựa trên các sự kiện hoặc lỗi được phát hiện. Các bản tin thông báo được thiết bị máy chủ hiển thị bằng cách sử dụng MMI cấp cao hoặc MMI ứng dụng. Các bản tin này sử dụng một mẫu chuẩn đối với tất cả các mã yêu cầu hành động:

Hướng dẫn cách thực hiện thông báo

Số đăng ký (xem mục 5.4.2.1)

Mã hành động (xem mục 5.4.3)

Kiểm tra tổng (tính cả số đăng ký và mã hành động)

Để phát hiện lỗi trong quá trình truyền với các nhà điều hành mạng (có thể bằng lời nói), kiểm tra tổng được thêm vào bản tin thông báo. Kiểm tra tổng ARC được tính toán trên số đăng ký nối tiếp với mã hành động (xem phụ lục C.2 đối với các thuật toán kiểm tra tổng ARC và Bảng 5.5 đối với quy định bản tin thông báo).

Hướng dẫn cách thực hiện thủ tục thông báo là một phần của mẫu bản tin thông báo. Ánh xạ các mã yêu cầu hành động vào các sự kiện hoặc lỗi tùy thuộc hệ thống CA và/hoặc nhà điều hành mạng cụ thể, do đó nằm ngoài phạm vi tiêu chuẩn này.

Bảng 5.5 - Mẫu bản tin thông báo

Trường Độ dài (số/ký tự)

36

TCVN xxxx : 2016

ARC_Reg_Number 8

ARC_Action_Code 2

ARC_Checksum 2

ARC_Instruction 256

Một ví dụ của mã yêu cầu hành động mà yêu cầu khách hàng liên hệ với các nhà điều hành mạng là "máy chủ bị thu hồi. Bản tin thông báo này thông báo cho khách hàng và hướng dẫn họ gọi đến một số dịch vụ và truyền ARC_Reg_Number, ARC_Code, và ARC_Checksum bộ phận hỗ trợ.

Your host device is revoked for use withthe inserted CI module.

Please contact the help-desk at number040-7654321 and provide the followingcodes:

XXXX XXXX XXXX

OK

Hình 5.11 - Ví dụ chụp màn hình của bản tin thông báo thu hồi máy chủ

Hình 5.9, 5.10 và 5.11 không quy định về trình bày mà chỉ ra một trình tự của các lĩnh vực được quy định. Các trường số phải được bao gồm như được định nghĩa ở trên. Mã yêu cầu hành động chỉ được hiển thị sau khi đăng ký lần đầu khi thông tin này có sẵn để hiển thị.

7.1.3 Báo cáo lỗi chung

Chế độ dịch vụ cơ bản và đăng ký dịch vụ đều hỗ trợ chức năng thông báo lỗi bắt buộc. Các lỗi có thể được CICAM hoặc máy chủ phát hiện và thông báo. Khi một lỗi được CICAM phát hiện thì nó phải sử dụng MMI cao cấp hoặc MMI ứng dụng để hiển thị một mã lỗi được xác định trước. Khi thiết bị máy chủ phát hiện một lỗi thì nó có thể sử dụng một phương pháp của thiết bị máy chủ cụ thể để hiển thị mã lỗi được xác định trước. Mã lỗi này có thể kèm theo văn bản mô tả và phải được sự tương tác của người sử dụng xác nhận. Phụ lục F quy định 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ụ, các nhà cung cấp CA hoặc nhà điều hành dịch vụ có thể định nghĩa một ánh xạ giữa mã hành động và mã lỗi. Các nhà cung cấp CA hoặc nhà điều hành dịch vụ phải quy định các mã hành động được hỗ trợ trong một chế độ đăng ký dịch vụ và nội dung này nằm ngoài phạm vi của tiêu chuẩn này.

Một ví dụ về một ánh xạ mã yêu cầu hành động là "Giấy chứng nhận của máy chủ không hợp lệ", Phụ lục F.1 quy định trạng thái lỗi này là Mã lỗi 16, có thể được nhà cung cấp CA và nhà điều hành dịch vụ ánh xạ tới một mã yêu cầu hành động bất kỳ. Bản tin thông báo thu được cung cấp thông tin cho khách hàng và cũng có thể cung cấp các hướng dẫn để gọi một số dịch vụ và truyền ARC (Số đăng ký, mã hành động, và kiểm tra tổng) đến bộ phận trợ giúp.

7.2 Giới thiệu phương pháp thu hồi

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ủ

37

Hp4530, 09/15/14,

help-desk

TCVN xxxx :20162) 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 mục 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 mục này mô tả cơ chế thu hồi máy chủ, chuẩn giấy cấp phép CI Plus quy định các yêu cầu để thực hiện thu hồi máy chủ.

7.2.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 CI 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 CI 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 CI 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 CI 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 CI 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 mục 9).

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

38

Hp4530, 09/15/14,

cycle constraint

Hp4530, 09/15/14,

counter

Hp4530, 09/15/14,

timestamp

TCVN xxxx : 20162) 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.

7.2.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 CI 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 CI Plus [33].

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.

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

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

39

Hp4530, 09/15/14,

time-out

TCVN xxxx :2016 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 CI 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.

40

TCVN xxxx : 2016

Bắt đầu (1)

Tải vềRSD (2)

Thời gianchờ t ải vềRSD (3)

Tải vềSOPKC (4)

SOPKCKhông có sẵn

(5)

RSD cóhợp lệ ? (6)

Tải về SOCRL(7)

Thời gianchờ tải vềSOCRL(8)

Xử lý SOCRL(9)

SOCRLcó hợp lệ (10)

SOCWL có đượcthông báo

trong RSD (11)

Tải về SOCWL(12)

Xử lý SOCWL(13)

SOCWLcó hợp lệ

(14)

Thiết bị máychủ trong SOCWL

(15)

Thiết bị máychủ trong SOCRL

(16)

Các thiết bị máy chủbị thu hồi đượccập nhật tronglịch sử liên kết (19)

Bỏ thu hồi:CICAM hoạt động

hoàn toàn (17)

Thu hồi:CICAM hoạt động

hạn chế (18)

Thu hồi tạp thờiCICAM hoạt động

hạn chế (20)

Có

Có

Có

Có

Có

Có

Có

Có

Không

Không

Không

Không

Không

Không

Không

Không

Hình 5.12 - Sơ đồ tải về SOCRL và SOCWL

SOCRL hợp lệ (10). Việc xử lý SOCWL có thể bắt đầu nếu đóng dấu kỹ thuật số của SOCRL được chứng thực và số phiên bản SOCRL bằng số phiên bản trong RSD nếu không máy chủ tạm thời bị thu hồi (20).

41

TCVN xxxx :2016 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:

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

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

o Đóng dấu kỹ thuật số SOCWL trong SOCWL được chứng thực

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

o 'Số phiên bản CRL' thuộc SOCWL bằng 'số phiên bản CRL'

o 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 CI 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 CI 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:

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

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

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

42

Hp4530, 11/25/14,

non-volatile

TCVN xxxx : 20167.2.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.13 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)

Lựu chọndịch vụ (2)

Dịch vụđược CI Plus

bảo vệ (3)

Thiết bị máychủ bị thù hồi (4)

Dịch vụ được CAgiải xáo trộn (5)

Dịch vụ được CAgiải xáo trộn vàđược CI Plus xáo trộn lại (6)

Đầu ra đến thiếtbị máy chủ (7)

Không Không

Có Có

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

Bắt đầu. Sau khi CICAM và máy chủ đã liên kết thành công, việc giải xáo trộn các dịch vụ được CA bảo vệ và xáo trộn lại các dịch vụ được CI Plus bảo vệ có thể bắt đầu.

Lựa chọn dịch vụ. Người sử dụng lựa chọn một dịch vụ và máy chủ dò đến dịch vụ được yêu cầu này. Trước tiên CICAM kiểm tra xem dịch vụ được lựa chọn này là được CI Plus bảo vệ trước khi việc CA bảo vệ có thể được gỡ bỏ (3).

Dịch vụ được CI 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 CI Plus bảo vệ. Nếu yêu cầu được CI 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).

43

TCVN xxxx :2016 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 CI 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 CI Plus xáo trộn lại. Dịch vụ được lựa chọn này là một dịch vụ được CI 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 CI Plus xáo trộn lại. Dịch vụ được CI 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ệ CI Plus được thêm vào).

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

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

Bảng 5.6 - Đị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ợ

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

Xs Xs Xs

Được xáo trộn,sử dụng mã khóa A,TSC là lẻ

Được xáo trộn,sử dụng mã khóa C,TSC là lẻ

Được xáo trộn,sử dụng mã khóa B, TSC là chẵn

Mã khóa CC A Mã khóa CC C Mã khóa CC CMã khóa CC A

Mã khóa CC B Mã khóa CC DMã khóa CC BTrống

t

t 0 t 1 t 2 t 3 t 4

lẻ

chẵn

Các thanh ghibộ giải xáo trộn

TS mã khóa kép

Ghi chú : Thanh ghi hoạt động được gạch chân.

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

44

TCVN xxxx : 2016Chương trình thay đổi B.CICAM mã hóa nội dung.Máy chủ thiết lập URI về mặc định.CICAM khởi tạo việc làm mới URI(tức là CC_SAC_data_req)

Chương trình thay đổi A.CICAM mã hóa nội dung.Máy chủ thiết lập URI về mặc định.CICAM khởi tạo việc làm mới URI(tức là CC_SAC_data_req)

Truyền URI được xác nhận < 1 giây

Máy chủ áp dụng URIcho giao diện bên ngoài < 1 giây

Máy chủ ápdụng URI chogiao diện bênngoài ≤ 1 giây

Máy chủ xác nhậnbằng CC_SAC_data_cnftrước khi timer = 1

0 1 2 0 1 2

0 1 8 9 10

Chương trình với EMI = 00Nội dung rõ ràng

Chương trình vớiEMI > 00 được mã hóasử dụng CCK-1 ‘cũ’

Chương trình vớiEMI > 00 được mã hóasử dụng CCK-2 ‘mới’

Thời gian dành choMax_key_session_period

Thời gian dành chokey refresh period

Thời gian dành choMax_key_session_period

CICAM và máy chủ tínhCCK ‘mới’ trước khi timer = 9

Bắt đầu tính CCKMáy chủ trả lời bằngCC_SAC_data_cnftrước khi timer = 1

Max_key_session_period hết hạn. CICAM bắt đầu làm mới mã khóa(tức là CC_SAC_data_req) và khởi tạo bộ đếm làm mới mã khóa 10 giây

CICAM bắt đầu mã hóa CC bằng mã khóa ‘mới’ CCK-2và cập nhật các bit TSC. Máy chủ phát hiện TSC thay đổivà chuyển đến thanh ghi mã khóa được chỉ ra.

Máy chủ trả lời bằng xác nhận đồng bộ(tức là CC_SAC_sync_cnf) trước khi timer = 10

CICAM gửi yêu cầu đồng bộ(tức là CC_SAC_sync_req)

Khoảng thời gian sống của mã khóa CCK-2Khoảng thời gian sống của mã khóa CCK-1

Nội

dung

Ghi chú :

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

2. Tham chiếu mục 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 mục 11.3.1 để biết thông tin chi tiết về các APDU. DĐối ới khoảng thời gian sống

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.15 – Làm mới mã khóa kép 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.14 để 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à

45

Hp4530, 11/25/14,

dual-key

TCVN xxxx :2016chuyể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.15 để biết chi tiết.

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

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

7.3.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.8 mô tả các khả năng bắt buộc của máy chủ và CICAM.

Bảng 5.7 - Các khả năng của máy chủ và CICAM

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

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 chứng thực, thì mã hóa được thương lượng trước đây phải được sử dụng (xem Mục 6.3).

Bảng 5.8 - Các quy tắc lựa chọn mã hóa xáo trộn

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

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

AES DES Xáo trộn lại TS đầu ra có thể sử dụng DES. Xem ghi chú 3

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

Ghi 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. T S đầ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 CI Plus tuân thủ các quy tắc xáo trộn sau đây:

46

TCVN xxxx : 2016 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 CI 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 CI 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 CI 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ủ 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 CI 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 CI 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 CI Plus xáo trộn lại.

Kiểm soát nội dung CI 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], mục 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], mục 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.)

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

7.3.5.2 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 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.16 chỉ ra định dạng cấp cao của một gói TS (xem ISO 13818-1 [13]).

47

TCVN xxxx :2016

0 4 188

hdr

hdr

hdr Trường thích ứng

Trường thích ứng

Tải

Tải

Hình 5.16 – Gói tin TS

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

7.3.5.2.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 = EAES-128-CBC CCK (b), trong đó mã khóa kiểm soát nội dung ( CCK, được quy định trong mục 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:

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

Eq.5.2

Trong đó:

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

Vector 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à vector khởi tạo giống nhay. 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.

48

Hp4530, 09/16/14,

engine

TCVN xxxx : 20167.3.5.2.2 Khối ngắn cuối cùng:

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.17 để biết chi tiết.

Các phần mào đầuvà trường thích ứng

Tải dữ liệu

Gói tin MPEG2 TS

Khối ngắncuối cùng

b(1) b(2) b(3) b(4)

s(3)s(2)s(1)

mã khóa mã khóa mã khóaAESAESAES

IV

mã khóa

rõ ràng

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

7.3.5.2.3 Khối ngắn đơn độc:

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.18 để biết chi tiết.

Các phần mào đầuvà trường thích ứng Tải dữ liệu

b(1) Khối ngắnđơn độc

rõ ràng

Gói tin MPEG2 TS

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

7.3.5.2.4 Giải 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-128-CBC CCK (s), trong đó mã khóa kiểm soát nội dung ( CCK, được quy định tại mục 8.1.4) được sử dụng để giải

49

TCVN xxxx :2016mã/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:

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:

Eq. 5.4

Trong đó:

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

Các phần mào đầuvà trường thích ứng

Tải dữ liệu

Gói tin MPEG2 TS

Khối ngắncuối cùng

s(1) s(2) s(3) b(4)

rõ ràng‘b(4)’b(3)b(2)b(1)

AES AES AESmã khóamã khóamã khóa

IV

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

50

TCVN xxxx : 2016

Các phần mào đầuvà trường thích ứng Tải dữ liệu

b(1) Khối ngắnđơn độc

rõ ràng

Gói tin MPEG2 TS

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

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

7.4.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ừ head-end 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ủ.

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

7.4.3 Truyền URI – từ Head-end đến CICAM

URI có thể được truyền từ DVB h ead -end đế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ừ head-end đến CICAM nằm ngoài phạm vi tiêu chuẩn này.

7.4.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 mục 5.7.5.2.

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

Bảng 5.9 – Các giá trị mặc định dành cho CI Plus URI phiên bản 1

Trường Giá trị khởi tạo mặc định

protocol version 0x01

51

TCVN xxxx :2016


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.10 – Các giá trị mặc định dành cho CI Plus URI phiên bản 2


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

7.4.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 mục 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.

52

TCVN xxxx : 2016CICAM 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.21.

headend CICAM Máy chủ

[1] kết hợp URI với chương trình

[2] cung cấp URI ví dụ trongEMM (nằm ngoài phạm vi tiêuchuẩn này) [3] tạo bản tinURI

[4] khởi tạo thời gian chờ 1 giây[5] truyền bản tin SAC (URI_message+program_nr) [6] kiểm tra bản tin

[7] xác nhận bản tin SAC(uri_confirm)

[8] kiểm tra xác nhận của máy chủ [9] sử dụng cácthiết lập kiểmsoát sao chép

Ghi 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.21 – Giao thức làm mới URI

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

Bảng 5.11 - Hành vi giao thức URI


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.

7.4.6

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.

7.4.7

3 CICAM tạo bản tin URI.

CICAM tính u r i_ c o n f i rm để chứng thực xác nhận của máy chủ đã nhận được (Ghi chú 5), vì:

Mục 5.7.5.1

53

TCVN xxxx :2016


uri _ c o n f i r m S H A 256 (uri _ m e ss a g e || UCK)

trong đó:

UCK = SHA256 (SAK)

Giá trị ur i _ c o nf i r m đượ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:

u r i _ m es s a g e ,

pr o gra m _ n u m b e r

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. (Ghi chú 1)

Hình 5.15

5 CIC A M 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ủ. (Ghi chú 2).

Mục 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.4.8

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. (Ghi chú 2)

Máy chủ tính uri_confirm 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 (Ghi chú 3 & 4).

Mục 7.3 và

11.3.1

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

CICAM soanhs 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 (Ghi 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.

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

54

TCVN xxxx : 2016


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 mục 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 mục 5.7.4.

4. Tham chiếu mục 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].

7.4.10.1 Giao thức thương lượng phiên bản URI

CICAM Máy chủ

[1] yêu cầu các phiên bản URI được máychủ hỗ trợ

[2] xác nhận (các) phiên bản URI

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

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 mục 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.

7.4.10.2 Định dạng của bản tin URI

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

Bảng 5.12 - Cú pháp bản tin URI phiên bản 1

Trường Độ dài Kiểu

uri_message() 7.4.11

8

8

ui m s bf protocol_version

aps_copy_control_info 2 uimsbf

emi_copy_control_info 2 uimsbf

ict_copy_control_info 1 uimsbf

55

TCVN xxxx :2016

rct_copy_control_info 1 uimsbf

reserved for future use 4 uimsbf

rl_copy_control_info 6 uimsbf

reserved for future use 40 uimsbf

Bảng 5.13 - Cú pháp bản tin URI phiên bản 2

Trường Độ dài Kiểu

uri_message() protocol_version aps_copy_control_info emi_copy_control_info ict_copy_control_info

if (emi_copy_control_info == 00) rct_copy_control_info

else

reserved = 0

reserved for future use

if (emi_copy_control_info == 11) dot_copy_control_info rl_copy_control_info

else

reserved = 0x00

reserved for future use

8.1.5

8

2

2

1

9

1

10

11

1

12

1

13

1

8

14

15

9

16

40

17

uimsbf uimsbf uimsbf uimsbf

17.1.1

uimsbf

17.1.2

uimsbf uimsbf uimsbf

uimsbf

17.1.3

17.1.4

uimsbf uimsbf

17.1.4.1 Mã hóa và ngữ nghĩa của các trường

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

Bảng 5.14 – Các giá trị cho phép của protocol_version

Nội dung 17.1.5 Ý nghĩa Diễn giải

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

56

TCVN xxxx : 2016

0x01 Giao thức URI phiên bản 1 Bản quy định kỹ thuật CI Plus phiên bản 1.2

0x02 Giao thức URI phiên bản 2 Tiêu chuẩn này

0x03-0x FF Dự phòng 17.1.7

Ghi 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.15:

Bảng 5.15 – Các 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á trinh AGC , tắt chia tách cụm

0x2 10 Bật quá trinh AGC , bật chia tách cụm 2 đường

0x3 11 Bật quá trinh 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 CI 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.16:

Bảng 5.16 – Các giá trị cho phép của emi_copy_control


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

Bảng 5.17 – Các giá trị cho phép của ict_copy_control_info


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

57

TCVN xxxx :2016Bảng 5.18: Giá trị cho phép rct_copy_control_info


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.19. 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.19 – Các giá trị cho phép của dot_copy_control_info


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

58

TCVN xxxx : 2016

20:00Hiện tại

19:00Bắt đầusự kiện

21:00Kết thúcsự kiện

1 giờ cho phépxem sự kiện Bộ đệm trống

18:00 23:00

20:3019:00Bắt đầusự kiện

21:00Hiện tại Kết thúc sự kiện

90 phútcho phépxem sự kiện Bộ đệm trống

21:00Hiện tại



90 phút cho phépxem sự kiện

18:00 23:00

21:30Hiện tại



1 giờ cho phépxem sự kiện

18:00 23:00

22:30Hiện tại



nội dung bị xóa

18:00 23:00



Giới hạn duy trì 90 phút





Sự kiện dài 2 giờ





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

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


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ờ


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ị nhi phân

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


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

59

TCVN xxxx :2016



0x03-0x FE 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ị nhi 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 (237 ngày)

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

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

17.2 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ủ CI Plus phải hoạt động bình thường. Máy chủ phải nhận ra rằng CI là DVB CI và sử dụng các tài nguyên của DVB CI. Nếu CI Plus CAM được ghép vào một máy chủ DVB CI, máy chủ phải nhận ra máy chủ là một thiết bị DVB CI 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.22 – 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

CI Plus DVB CI 17.2.1 DVB CI (Ghi chú 1) DVB CI

DVB CI CI Plus 17.2.2 Không giải xáo trộn (Ghi chú 2)

DVB CI (Ghi chú 4)

CI Plus CI Plus Đã chứng thực Giải xáo trộn + CC (Ghi chú 4)

Giải xáo trộn

CI Plus CI Plus SAC không thành công

Không giải xáo trộn DVB CI (Ghi chú 4)

CI Plus CI Plus CCK không thành công

Không giải xáo trộn DVB CI (Ghi chú 4)

CI Plus CI Plus CICAM bị hủy bỏ Không giải xáo trộn Không giải xáo trộn

CI Plus CI Plus Máy chủ bị hủy bỏ CICAM Pass-through (Ghi chú 3)

CICAM Pass-through (Ghi chú 3)

CI Plus CI Plus Chứng thực không thành công

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

Ghi chú:

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

60

TCVN xxxx : 20162. 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 dụng để giải xáo trộn nội dung sang thiết bị DVB CI

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

Một máy chủ tuân thủ CI Plus có thể hỗ trợ tối đa 5 khe CI Plus. Mỗi khe có thể ghép một DVB CICAM hoặc một CI 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.23. Đố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.

CICAM 1

Máy chủ CICAM 2, ..., N-1

CICAM N

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

Máy chủ và một CICAM đơn lẻ phải có khả năng giải mã một dịch vụ, và có thể xáo trộn lại nó tuân theo tiêu chuẩn này. Trường hợp có 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 máy chủ và CICAM thực hiện tùy chọn.

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

Lúc khởi tạo, trước tiên một CI Plus CAM thực hiện việc kiểm tra mã khóa chứng thực của máy chủ (AKH). Nếu điều này thành công, giao thức chứng thực hoàn toàn có thể được bỏ qua. Mục 6.3 giải thích thủ tục này. Khi một CICAM mở một phiên đối với một tài nguyên, máy chủ có thể bận rộn vì nhiều lý do thì CICAM phải nhận được phản hồi "tài nguyên bận".

CICAM tuân thủ tiêu chuẩn này phải hỗ trợ hoàn toàn tài nguyên CA được quy định trong EN 50221 [7]. Khi một dịch vụ được giải xáo trộn, máy chủ có thể gửi lệnh ca_pmt với ca_pmt_cmd_id là ‘query’ cho tất cả các CICAM được ghép vào. Mỗi CICAM kiểm tra xem nó có thể giải xáo trộn dịch vụ này. Đối với việc kiểm tra này, CICAM xem dữ liệu riêng từ hệ thống CA. Sau khi nhận được ca_pmt_reply từ mỗi CICAM, máy chủ có thể chọn một CICAM để giải xáo trộn bằng cách gửi một ca_pmt với ca_pmt_command_id được thiết lập là ‘ok_descrambling’ đến CICAM này. Một CICAM mà không được chọn cho giải xáo trộn phải truyền không làm thay đổi TS này.

61

Hp4530, 09/18/14,

daisy-chain

TCVN xxxx :2016Một CI 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.

17.2.4 CICAM duy nhất với sự hỗ trợ của nhiều hệ thống CA

17.2.4.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 CI Plus.

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

17.2.4.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 mục 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 mục 8.1.2.

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

17.3 Tổng quan chứng thực

Tiêu chuẩn này yêu cầu chứng 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 chứng 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 mục 5.4.2.

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

62

TCVN xxxx : 2016Quá trình này được mô tả chi tiết trong mục 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 chứng 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 chứng 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 chứng 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ế chứng 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 chứng thực CI 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.25.

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 rai 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 mục 6 để biết chi tiết về các cơ chế chứng thực hợp lệ.

63

TCVN xxxx :2016

CICAM Máy chủ

[1] tạo nonce

[2] gửi (nonce)[3] tạo x ngẫu nhiên

[4] DH Public key Host = gx mod p

[5] gửi(DH Public key Host)

[6] tạo y ngẫu nhiên

[7] DH Public key Module = gy mod p

[8] gửi(DH Public key Module)

[9] DH private key = (gx)y mod p[10] DH private key = (gy)x mod p

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

17.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 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 mục 11.3.1.3 và 11.3.1.4.

17.4.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 mục 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 timeshift. 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.

64

Hp4530, 09/19/14,

live viewing

Hp4530, 09/19/14,

parental control

Hp4530, 09/19/14,

unattended recording

TCVN xxxx : 201617.4.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 mục 11.3.4.1 để biết cụ thể hơn.

17.4.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 mục 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.

17.4.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 mục 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.

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

65

TCVN xxxx :2016củ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 timeshifting 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.

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ị CI Plus [6].

17.5.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 mục 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.

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

66

TCVN xxxx : 201617.5.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.

17.5.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 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à đú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.

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

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

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. Nội dung yêu cầu này giống như trong mục 5.11.1.4.

67

TCVN xxxx :2016Má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.

17.5.2 Mã CICAM PIN

cc_PIN_capabilities_req()

CAM được phát hiện

CICAMMáy chủNgườisử dụng

cc_PIN_capabilities_reply()Capability_f ield == “03” or “04”Thiết lập sự kiện ghi lại

với PIN tùy chọn

Thời gian ghi lại bắt đầu:Máy chủ dò kênh đến dịch vụ

cc_PIN_cmd()

cc_PIN_req()


cc_PIN_capabilities()Capability_f ield == “03” or “04”

Record Start messageoperating_mode == “02"

cc_PIN_event()

cc_PIN_event()

Bản tin dừng ghi lại

Mức kiểm soát củacha mẹ được cập nhật

(tùy chọn) xác nhận PINlà đúng tại thời điểmthiết lập sự kiện ghi lại

CICAM kiểm tra xem mứckiểm soát của cha mẹ cócao hơn mức trên CAS/CICAM.Nếu cao hơn, CICAM hiện thị MMI

Máy chủ phải làm trống AVđến người sử dụng cho tớiPIN_reply đồng ý tiếp theo


cc_PIN_playback()

cc_PIN_reply()

cc_PIN_reply()

cc_PIN_playback()

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

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.

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 timeshift. CICAM phải xác nhận mã PIN bằng cách sử dụng một cc_PIN_reply ().

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

68

TCVN xxxx : 2016tá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ủ.




cc_PIN_capabilities_reply()Capability_f ield == “03” or “04”

Record Start messageoperating_mode == “00"

Lựa chọn/ thay đổi kênh

cc_PIN_event()

cc_PIN_event()

cc_PIN_event()

cc_PIN_event()

cc_PIN_event()

cc_PIN_reply()

cc_PIN_reply()

cc_PIN_reply()

cc_PIN_reply()

cc_PIN_playback()

cc_PIN_playback()

Bản tin dừng ghi lại

Bản tin bắt đầu ghi lạioperating_mode == “00"

Bản tin thay đổi chế độ hoạt độngoperating_mode == “01"

Bắt đầu Timeshif tDừng/ tua

Bắt đầu xem

Việc xem bị hủy bỏ


CICAM cung cấp một MMIdành cho PIN nếu nội dung này yêu cầu. CICAM tiếp tục

giải xáo trộn nội dung này



Trong chế độ nàyCICAM sẽ không cung cấp

MMI này dành cho PIN

CICAM kiểm tra xem mứckiểm soát của cha mẹ cócao hơn mức trên CAS/CICAM.Nếu cao hơn, CICAM hiện thị MMI

Máy chủ phải làm trống AVđến người sử dụng cho tớiPIN_reply đồng ý tiếp theo

Hình 5.27 - Biểu đồ trình tự timeshift

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

69

TCVN xxxx :2016giữa nhận được "pin_event" trong quá trình ghi lại và nhận được cc_PIN_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.

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




cc_PIN_capabilities_reply()Capability_f ield == “02” or “04”

cc_PIN_MMI_req()

MMI

Trả lời MMI

MMI

Trả lời MMI

cc_PIN__reply()

--- EIT với mức tuổi

MMI

MMI _ _ _ _

PIN được nhập vào

PIN được nhập vào

Hình 5.28 – PIN dành cho FTA

70

Hp4530, 10/17/14,

flicker

TCVN xxxx : 201617.5.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.27 được cung cấp để tham khảo:

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

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

cc_PIN_playback APDU, xem mục 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.

17.6 Ghi 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 CI 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 qua 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.

71

TCVN xxxx :2016 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.28 đã 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.28, 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.

Sự kiện 1

Sự kiện 2

Sự kiện 3

00:00:00:000 URI #1, License #1

00:01:00:000 PIN #1

01:30:00:000 URI #201:30:00:000 PIN #2

02:00:00:000 URI #3, License #2

03:00:00:000

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

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

72

Hp4530, 09/22/14,

include the concept of a session

TCVN xxxx : 2016Cá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 dụng đượ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 CI 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 CI 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á.

17.7 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

73

Hp4530, 09/23/14,

URI region

TCVN xxxx :2016nă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ủ CI Plus phải phù hợp với Bản quy định kỹ thuật giấy phép CI Plus [33]. Máy chủ CI 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 đó.

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

17.7.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.29:

headend CICAM Máy chủ

[1] gán SRM đúng (nằm ngoài phạm vị tiêu chuẩn này

[3] tạo bản tin

[4] khời tạo thời gian chờ 10 giây

[5] truyền bản tin SAC (dataf ile) [6] kiểm tra bản tin

[7] xác nhận bản tin SAC(status+datafile_confirm)

[8] kiểm tra xác nhận của máy chủ

[2] cung cấp SRM (nằm ngoài phạm vị tiêu chuẩn này

[9] áp dụng dữ liệuSRM (nằm ngoàiphạm vị tiêu chuẩn này

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

Bảng 5.23 – Hành vi giao thức truyền tập tin dữ liệu SRM


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.

17.7.2

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.

17.7.3

3 CICAM tạo bản tin.

CICAM tính d ata f il e _ c o n f i rm để chứng thực xác nhận của máy chủ đã nhận được (Ghi chú 3) :

da t a f i l e _ con f i r m S H A 256(datafile || UCK)

trong đó:

datafile là tập tin SRM ,

mục 11.3.5

74

TCVN xxxx : 2016


UCK = SHA256 (SAK).

Giá trị da t af i le _ c on f irm được lưu trữ nội bộ để so sánh trong bước 8.

CICAM phải tạo c c _ s a c _ dat a _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 (d ata t y p e _ i d = s r m _d ata ).

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. (Ghi chú 1)

17.7.4

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ủ. (Ghi chú 2).

mục 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).

mục 7.4

7 Máy chủy 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 (d ata t y p e _ id = d atat r a ns f e r_ c on f i r m )

trạng thái

và sử dụng SAC để truyền bản tin này đến CICAM. (Ghi 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 (Ghi chú 1).

mục 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. (Ghi 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.

Ghi 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 mục 7.2 để biết cách dữ liệu SRM được đóng gói vào bản tin SAC.

75

TCVN xxxx :2016



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

(1) Bắt đầu truyền tập tin dữ liệu

(2) CICAM phát hiện tập tin (SRM)

(3) CICAM gửi tập tin(SRM) đến máy chủ

(4) Máy chủ trả lời trong khoảng thời

gian chở

Không

Có

(3) Trạng tháitrả lời của máy chủ có yêu cầu

dataf ile

(6) Theo dõi (nằm ngoài phạm vị tiêu chuẩn này)

Không

Ok / máy chủ bận

Ghi chú: thời gian chờ được quy định là 10 giây.

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

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.30 trình bày hoạt động truyền tập tin dữ liệu của CICAM.

76

TCVN xxxx : 2016

18 Cơ chế chứng thực

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

Việc đăng ký và liên kết CIAM đượ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 chứng 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.

18.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 chứng 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 chứng 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 chứng 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-Helman. 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-Helman, 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 mục 5.4.3 để biết chi tiết về các bản tin lỗi và EN 50221 [7], mục 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.

18.1.2 Kiểm tra mã khóa chứng thực

CICAM và máy chủ lấy được mã khóa chứng 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 chứng thực. Mã khóa chứng 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 mục 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 chứng 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 chứng thực được yêu cầu. Sau khi nhận, CICAM so sánh mã khóa chứng 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 chứng 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 chứng thực này trong bộ nhớ ổn đinh để nó có sẵn để tính toán mã khóa dành cho SAC và CC. Tham khảo mục 7 (SAC) và mục 8 (Mã khóa kiểm soát nội dung) để biết chi tiết.

77

TCVN xxxx :2016Nếu một mã khóa chứng 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.

18.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 mục 5.4.2 để biết chi tiết.

Khi ở chế độ đăng ký dịch vụ, CICAM yêu cầu head-end 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 mục 5.5.

18.1.4 Hoạt động hệ thống CC

Hình 6.1 trình bày cách chứng 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 chứng 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 CI.

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

3) CICAM phải cho phép giải mã CA các chương trình với giá trị EMI là 00 khi tài nguyên kiểm soát nội dung đã được thông báo.

4) Một phiên dành cho tài nguyên kiểm soát nội dung được CICAM mở, mục 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 mục 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 mục 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).

5) CICAM kiểm tra xem có một mã khoá chứng thực được lưu trữ trong bộ nhớ ổn định. Nếu CICAM chứa một mã khóa chứng thực hợp lệ (AKM) thì nó phải yêu cầu máy chủ để gửi mã khóa chứng 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 (8).

6) CICAM yêu cầu máy chủ gửi mã khóa chứng 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ệ.

7) 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 chứng thực này phù hợp thì việc chứng 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 chứng 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 chứng thực không phù hợp thì hệ thống được yêu cầu chứng thực và

78

TCVN xxxx : 2016phả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 mục 6.3.

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

9) 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 chứng thực dựa trên DH chính xác được mô tả trong hình 6.2 bước (1).

Chứng thực (lại) và/ hoặc khởi động (lại) và/ hoặc ghép lại thành công

(1) CICAM được cấpnguồn điện từ máy chủ

(2)Tài nguyên CCđược máy chủ

thông báo?

Có(3) Cho phép mạng CA giải mã

nội dung đối với EMI = 00

(24) CICAM là CIv1 và hoạtđộng với các giới hạn của CIv1.

Không

(4)Mở tài nguyên

CC thành công ?

Có(5)

CICAM lưu trữAKM hợp lệ ?

Có

(6) CICAM yêu cầu máy chủ gửiAKH trong khoảng thời gian 5 giây

(25) Thiết lập lại.

(15) Bản tin hợp lệcó nhận được?

(tùy chọn)

(7)AKH có giống AKM

được lưu trữ?

Không(8) Thiết lập backoffice từ hợp lệ sang false trong NVM

Có

(9) CICAM kích hoạt giao thứcDH 3 pass

(16) Thiết lập backoffice hợplệ sang true trong NVM

(10) Giao thứcDH thực hiện thành công?

(17) Cho phép mạng CA giải mã nội dung đối với tất

cả các thiết lập EMICó

(11) CICAM yêu cầu máy chủ gửiAKH trong khoảng thời gian 5 giây

(20) Thiết lập backoffice từhợp lệ sang false trong NVM

(12) AKHcó giống

AKM được tính?(18) CICAM cóđược sử dụng ? (21) Vô hiệu tất cả mã hóa

của mạng CA

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

có được sửdụng ?

(22) CICAM khởi tạo tương tácMMI với người sử dụng đầu cuối

CóCó

Không(14) Báo cạo các ID của thiết bị (Chỉ

dành cho chế độ đăng ký dịch vụ)

(19) Hoạt động hoàn toànđối với nội dung rõ ràng và

được mạng mã hóa

(23) Bị giới hạn xử lý nộidung rõ ràng

Không(trả lời vượt quáthời gian chờ)

Không

Có

Không

KhôngKhông

Không

Không(ID của mạng sai)

Có

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

10) 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 (11). 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 (20).

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

79

TCVN xxxx :201612) CICAM phải so sánh mã khóa chứng 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 mục 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 chứng thực này (DHSK và AKM/AKH) vào bộ nhớ ổn định.

13) CICAM kiểm tra chế độ triển khai này. Nếu được triển khai trong chế độ dịch vụ cơ bản thì tiếp tục với bước (15). Nếu CICAM được triển khai trong chế độ đăng ký dịch vụ, hệ thống phải tiếp tục với bước (14).

14) CICAM khởi tạo một tương tác đăng ký theo quy định tại mục 5.4.2 để thông báo lại các ID của thiết bị. Các ID của thiết bị có thể được thông báo bằng các phương tiện khác, ví dụ như điện thoại, tin nhắn SMS, internet. Cơ chế chính xác này được sử dụng để thông báo lại các ID của thiết bị này nằm ngoài phạm vi của tiêu chuẩn này.

15) (bước tùy chọn của head-end) CICAM phải sử dụng hệ thống CA mạng của nó chỉ để giải mã những dịch vụ có giá trị EMI là 00 cho đến khi xác nhận hoàn thành. Trong chế độ đăng ký dịch vụ, việc ghép giữa HOST_ID và CICAM_ID được nhà điều hành dịch vụ ghi lại. Nhà điều hành dịch vụ có thể thực hiện việc kiểm tra các ID của thiết bị được ghi lại, cơ chế chính xác này nằm ngoài phạm vi tiêu chuẩn này. Sau khi xác nhận việc ghép, hệ thống CAS mạng có thể gửi bản tin xác nhận đến CICAM chứa HOST_ID và CICAM_ID; cách bước tùy chọn này được thực hiện cũng nằm ngoài phạm vi tiêu chuẩn này. Bước này có thể xảy ra trong thời điểm mà CICAM_ID và HOST_ID được thông báo cho nhà điều hành dịch vụ hoặc tại một thời điểm trong tương lai. Khi CICAM nhận được bản tin này, CICAM phải kiểm tra xem các ID của thiết bị nhận được có phù hợp với các ID của thiết bị từ giấy chứng nhận được trao đổi trong hệ thống xử lý chứng thực DH và nếu đúng thì hệ thống phải tiếp tục với bước (16). Không phù hợp với ID phải làm cho CICAM chỉ giải mã CA các dịch vụ có giá trị EMI là 00 và hệ thống phải tiếp tục với bước (15).

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

17) Ứng dụng CA mạng trên CICAM được phép xử lý nội dung mạng được mã hóa đối với tất cả các thiết lập EMI, miễn là giải mã của máy chủ và CICAM đáp ứng các yêu cầu của nhà điều hành mạng đối với dịch vụ này, xem bảng 5.9, ghi chú (1).

18) Độc lập với quá trình chứng thực, hệ thống CA mạng gửi EMM đến CICAM để cho phép ứng dụng CA mạng giải mã các dịch vụ thích hợp. Những dịch vụ này có thể có giá trị EMI khác nhau. Các dịch vụ có giá trị EMI là 01, 10 hoặc 11 không được ứng dụng CA này của CICAM giải xáo trộn cho đến khi việc cho phép được hoàn thành.

19) 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 mục 7) và các mã khóa CC (xem mục 8), máy chủ sẽ có thể hiển thị nội dung.

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

21) Ứng dụng CA mạng trên CICAM bị cấm giải mã nội dung được mã hóa mạng đối với tất cả các thiết lập EMI.

22) CICAM có thể khởi tạo một tương tác MMI, xem mục 5.4.2.2.

23) Hệ thống này bị giới hạn chỉ xử lý nội dung rõ ràng.

24) Hoạt động hệ thống này bị giới hạn trong chức năng DVB CICAM.

25) CICAM phải yêu cầu thiết lập lại (xem mục 11.1.2).

80

TCVN xxxx : 201618.2 Giao thức chứng thực

Mục 6.2.1 trình bày các bản tin của giao thức chứng thực được trao đổi quacác giao diện bên ngoài. Mục 6.2.2 trình bày các điều kiện chứng thực. Mục 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 chứng thực.

CICAM không nên cố chứng 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], mục 8.5.2.

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

Chứng thực được thực hiện theo ba bước:

CICAM Nhà cung cấp Máy chủ

[1] open_session_request()Chứng thựcBước 1 [2] open_session_response()

[3] cc_open_req()[4] cc_open_cnf()

[5] cc_data_req(nonce)[6] cc_data_cnf(DHPH+signature_A+host_dev_cert+host_brand_cert)

Các đóng dấu hợp lệtrên dữ liệu giaothức và giấy chứngnhận

Các đóng dấu hợp lệtrên dữ liệu giaothức và giấy chứngnhận

[7] cc_data_req(DHPM+signature_B+CICAM_dev_cert+CICAM_brand_cert)[8] cc_data_cnf(status)

[9] cc_data_req(AKH)Chứng thựcBước 2 [10] cc_data_cnf(AKH)

[11] compare AKM=AKH

Chứng thựcBước 3(tùy chọn) [14] thông báo các ID của thiết bịCơ chế chính xác để

kiểm tra CRL, sử dụng, thu hồi nằm ngoàiphạm vi tiêu chuẩn này

[16] kiểm tra ID của thiết bị trong CRL?[17] sử dụng hoặc thu hồi

[12] display_MMI (chỉ dành cho chế độ đăng ký dịch vụ

Ghi 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 chứng thực

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

Bảng 6.1 – Trao đổi chứng thực


1 CICAM phải mở một phiên dành cho tài nguyên kiểm soát nội dung mục 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

mục 11.3

3 CICAM phải gửi cc _ o pen_r e q APDU đến máy chủ. mục 11.3.1.1

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

81

TCVN xxxx :2016


cc _ s y s te m _ i d _ b i t m a s k

5 CICAM phải gửi cc _ d ata _ r e q APDU đến máy chủ, bao gồm:

nonce (tức là a ut h _ n o nce ).

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 mục tham chiếu đến ở cột bên.

mục 11.3.3.2

6 Máy chủ phải xác nhận bằng c c _da t a _ c nf APDU, bao gồm:

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

Đóng dấu A (tham chiếu đến mục 6.2.3),

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

Giấy chứng nhận thiết bị của máy chủ (Host_DevCert, tham chiếu đến mục 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 (ghi chú 2).

mục 11.3.3.2

7 CICAM phải theo dõi bằng c c _ dat a _req APDU, bao gồm:

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

Đóng dấu B (tham chiếu đến mục 6.2.3),

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

Giấy chứng nhận thiết bị của CICAM (CICAM_DevCert, tham chiếu đến mục 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 mục 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ủ (ghi chú 2).

mục 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 (ghi chú 2).

mục 11.3.3.2

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

mục 11.3.3.3

82

TCVN xxxx : 2016


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

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 mục 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 (ghi chú 2).

mục 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 dụng không thành công (ghi 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ý. mục 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 mục 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 chứng 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ủ mục 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ệ.

Ghi 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 mục 6.1 và hình 6.1, bước 20.

Tham chiếu đến mục 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.

18.2.5 Các điều kiện chứng 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 chứng 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 hợp lệ 3

Các điều kiện chứng 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 chứng 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ới hạn cố thử (xem Bảng 6.2). Nếu đạt giới hạn cố thử thì việc chứng thực thất bại và CICAM tiếp tục với bước 25.

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.

83

Hp4530, 10/17/14,

retry

TCVN xxxx :20165) 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 chứng thực thất bại và CICAM tiếp tục với bước 25.

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 chứng thực thất bại và CICAM tiếp tục với bước 25.

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 mục 6.2.3.2. Nếu không hợp lệ, việc chứng thực thất bại và CICAM tiếp tục với bước 25.

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 mục 6.2.3.2. Nếu không hợp lệ, việc chứng thực thất bại và CICAM tiếp tục với bước 25.

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 chứng 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 mục 6.2.3.3 và 6.2.3.4. Nếu không hợp lệ, việc chứng thực thất bại và CICAM tiếp tục với bước 25.

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 chứng thực thất bị và CICAM tiếp tục với bước 25.

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 chứng thực không thành công, CICAM tiếp tục với bước 25.

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 chứng thực thất bại và CICAM tiếp tục với bước 25.

22) CICAM kiểm tra xem nó trong chế độ dịch vụ cơ bản hay chế độ đăng ký dịch vụ.

23) Khi được triển khai trong chế độ đăng ký dịch vụ, CICAM có thể khởi tạo một tương tác MMI đăng ký.

24) CICAM hoàn thành việc chứng thực thành công.

25) CICAM có thể bắt đầu một tương tác MMI, xem mục 5.4.2.2.

26) Chứng thực thất bại.

84

TCVN xxxx : 2016

(1) Tài nguyên và phiên CCđược mở

(2) Khởi tạo nonce

Không(hết số lần cố thử)

(4) Gửi nonce đến máychủ để yêu cầu lại dữ liệu

(5) Nhận được xác nhận từmáy chủ với dữ liệu yêu cầu

(15) Trạng tháimáy chủ ok?(6) Các đóng dầu

của giấy chứngnhận có hợp lệ?

(16) Tính DHSK & AKM

(7) Đóng dấu A hợp lệ ?

(17) Mãkhóa có hợp

lệ ?

(8) DHPHcó hợp lệ ?

(18) Gửi yêu cầuAKH đến máy chủ

(9) Tạo DHY ngẫu nhiên(19)

Nhận AKH ≤ 5 giây ?

(10) Tính DHPM

(20) AKH có hợp lệ?(11) DHPM

có hợp lệ ?

(21) AKH = AKM ?(12) Tạo đóng dấu B

(13) Gửi dữ liệu+ đóngdấu B đến máy chủ

(22) Chế độ đăngký dịch vụ ?(14) Nhận xác nhận từ máy

chủ với dữ liệu trạng thái

(23) Kích hoạt tươngtác đăng ký MMI

(24) Chứng thực thành công (26) Chứng thực khôngthành công

khởi động (lại) và/ hoặc ghép lại

(3) Nonce có

hợp lệ

Không(số lần cố thử < giới hạn)

Có

Không

Không

Không

Không

Không

Không

Không

Không

Không

Có

Có

Có

Có

Có

Có

Có

Có

Có

Có

Không

(25) Tương tác thôngbáo lỗi (tùy chọn)

Có

Ghi 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 chứng thực phía CICAM .

85

TCVN xxxx :2016

(2) Nhận nonce từ CICAMvới yêu cầu dữ liệu

(3)nonce có hợp

lệ ?

(4) Tạo DHX ngẫu nhiên

(5) Tính DHPH (15) Trạng thái máy chủ = ok

(16) Gửi xác nhận với trạng tháicủa máy chủ đến CICAM(6)

DHPH có hợplệ ?

(17) Tính DHSK & AKH

(7) Tạo đóng dấu A

(18) Các mãkhóa cóhợp lệ ?

(8) Gửi xác nhận với dữ liệuđược yêu cầu đến CICAM

(9) Nhận dữ liệu từ CICAM vớiyêu cầu trạng thái của máy chủ

(14) Gửi xác nhận với trạng tháicủa máy chủ đến CICAM (19) Chứng thực thành công (20) Chứng thực không thành công

(10) Trạng thái máy chủ = error

(21) Nhận yêu cầuAKH từ CICAM

(11) Các đóng dấucủa giấy chứngnhận có hợp lệ?

(22) Gửi xác nhận với AKH

(12) Đóng dấuB có hợp lệ ?

(13) DHPM cóhợp lệ ?

(24) Chứng thực hoàn thành

khởi động (lại) và/ hoặc ghép lại

(1) Tài nguyên và phiên CCđược mở

Không

Không

Không

Không

Không

Không

Có

Có

Có

Có

Có

Có

Có

(23) Nhận yêu cầu đối với tươngtác đăng ký MMI (tùy chọn)

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

Các điều kiện chứng 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.

86

TCVN xxxx : 20163) 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 chứng 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 mục 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ầ để hoàn thành việc chứng 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 mục 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 mục 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 chứng 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 chứng thực phải có nghĩa là việc chứng 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) (bước không bắt buộc). Khi CICAM được triển khai trong chế độ đăng ký dịch vụ, CICAM có thể gửi các yêu cầu MMI để đưa ra một tương tác đăng ký.

24) Việc chứng thực được xem là hoàn thành đối với máy chủ khi tương tác đăng ký (bước 23) đã được đóng (tức là được người sử dụng xác nhận).

18.2.6 Các tính toán mã khóa chứng thực

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

87

TCVN xxxx :2016

CICAM Host

[1] tạo nonce

[2] gửi nonce[3] kiểm tra các thông số

[4] tạo x ngẫu nhiên

[5] tính DHPH

[6] tạo đóng dấu A

[7] gửi (DHPH + signature A) đến CICAM

[8] kiểm tra các thông số

[9] tạo y ngẫu nhiên

[10] tính DHPM

[11] tạo đóng dẫu B

[12] gửi (DHPM+signature B) đến máy chủ[13] kiểm tra các thông số

[14] xác nhận

[15] tính DHSK và AKM

[16] tính DHSK và AKH

[17] yêu cầu AKH[18] xác nhận AKH

[19] so sánh AKM=AKH

Ghi chú: Lưu đồ này 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 chứng 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 chứng thực


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ệ. mục 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

88

TCVN xxxx : 2016


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.

mục 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). mục 6.2.3.2

6 Máy chủ phải tạo đóng dấu A trên a uth _ no n c e an d DHPH này, sao cho:

message _ A (version || m s g _ l a be l || a u t h _ nonce || DHPH)

s i g n a t ur e _ A R S A SS A P S S S I G N (HDQ, message _ A)

trong đó:

RSASSA-PSS phải được sử dụng như được tham chiếu trong ghi chú 2.

HDQ là mã khóa riêng của thiết bị được quy định trong mục 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.

mục 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 P S S VER I F Y (HDP, message _ A, signature_ A) TRUE

trong đó:


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


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 a n d DHPH DH _ q m o d DH _ p 1

mục 9.4

89

TCVN xxxx :2016


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). mục 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 đó:


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


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

Phụ lục I

mục 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.

mục 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 ghi 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 để: 1DHPMDH _ p và DHPM DH _ q mod DH _ p1

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

mục 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.

mục 11.3.3.2

90

TCVN xxxx : 2016


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

mục 6.2.3.3

mục 6.2.3.4

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

mục 6.2.3.3

mục 6.2.3.4

17 CICAM phải bắt đầu việc kiểm tra chứng thực (bước 2 trong quá trình chứng thực) bằng cách gửi một yêu cầu mã khóa chứng 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.

mục 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.

mục 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 chứng thực không thành công (ghi 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 để chứng 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 mục 6.1 và hình 6.1.

Tham chiếu đến mục 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.

18.2.12.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 Bản quy định kỹ thuật giấy phép CI Plus [33].

18.2.12.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 chứng thực.

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

Eq.6.1

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

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 chứng thực. Giá trị của g và p được quy định trong Bản quy định kỹ thuật giấy phép CI 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.

91

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

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

Eq. 6.3

18.2.12.4 Tính mã khóa chứng thực (AKH và AKM)

Mã khóa chứng thực AKH/AKM phải được sử dụng để tính toán mã khóa SAC (xem mục 7.1.3) và mã khóa kiểm soát nội dung (CCK) (xem mục 8.1.4). Việc tạo mã khóa chứng 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 chứng 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 ổn định. Các mã khóa này phải được tính như sau:

) 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 chứng thực.

mục 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ủ.

mục 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.

mục 9.3.6

Ghi chú:


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

18.3 Chứng 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 chứng 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 chứng thực lại là không cần thiết.

Các trường hợp chứng thực có chứa dữ liệu được yêu cầu để kiểm tra mã khóa chứng thực và khởi tạo với chứng 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

92

TCVN xxxx : 2016Máy chủ phải lưu trữ 5 trường hợp chứng thực này. CICAM phải hỗ trợ ít nhất một trường hợp chứng thực và có thể hỗ trợ nhiều trường hợp chứng thực khác.

Nếu CICAM có một trường hợp chứng 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 chứng 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 chứng thực của nó và gửi lại các AKH tương ứng. Khi có phù hợp, chứng 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 chứng 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 chứng thực.

Việc thực hiện trên CICAM và máy chủ nên cố gắng hạn chế tối đa các trường hợp này khi có yêu cầu chứng thực đầy đủ.

19 Kênh được chứng thực an toàn

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

Kiểm soátSAC

Kiểm soátSAC

Các mã khóa, v.v..

Các mã khóa, v.v..

Dữ liệu Dữ liệuGiảimã hóa

Chứngthực & mã hóa

Khởi tạo và đồng bộ

Ống truyền an toàn

Ghi chú: CI 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:

93

TCVN xxxx :2016

Tài nguyên CC của CI SAC của CI PCMCIA SAC của máy chủ Tài nguyên CC củamáy chủ

[1] giao thức chứng thực[2] giao thức chứng thực

[3] khởi tạo SAC[4] ok

[5] khởi tạo SAC[6] ok

[7] APDU yêu cầuđồng bộ SAC [8] APDU xác nhận

đồng bộ SAC

[9] tạo dữ liệu

[10] truyền dữ liệu[11] ok

[12] kiểm tra trạng thái

[13] tạo bản tin

[14] gửi bản tin[15] ok

[16] nhận bản tin[17] ok

[18] kiểm tra trạng thái

[19] xử lý bản tin

[20] truyền dữ liệu[21] ok


Hình 7.2 - Biểu đồ trình tự CI SAC


Bảng 7.1 - Tổng quan theo ngữ cảnh của CI SAC


1

2

Giao thức chứng thực.

CICAM và máy chủ phải hoàn thành thành công giao thức chứng thực tương hỗ này.

mục 6.2

3 Khởi tạo SAC.

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.

mục 7.1.1

..

6

7 Yêu cầu đồng bộ SAC và xác nhận đồng bộ SAC.

Nếu CICAM đã khởi tạo đúng CI 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.

mục 7.1.1

8

9 Tạo và truyền bản tin SAC. mục 7.3

94

TCVN xxxx : 2016


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, trường chứng thực và mã hóa tùy chọn

..

15

16 Nhận và kiểm tra bản tin SAC.

Khi nhận được bản tin SAC, nó phải được kiểm tra và nếu hợp lệ, tải của nó có thể được xử lý tiếp.

mục 7.4

..

21

Ghi chú:

1. CI SAC có thể gửi và nhận các bản tin cả hai chiều.

2. Tham chiếu đến mục 7.5 để biết cách SAC được ghép trong kiến trúc CI 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.

19.2 Hoạt động CI SAC

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

CICAM Máy chủ

[1] mã khóa (lại) SAC được yêu cầu

[2] tạo Ns_module

[3] gửi cc_data_req(Ns_module+CICAM_ID)[4] tạo Ns_Host

[5] xác nhận cc_data_cnf(Ns_Host+Host_ID)

[6] lấy SAK&SEK và thiết lập lại trạng thái SAC

[7] lấy SAK&SEK và thiết lập lại trạng thái SAC

[8] gửi cc_sync_req()[9] xác nhận cc_sync_cnf()


Hình 7.3 - Biểu đồ trình tự tính toán mã khóa SAC


Bảng 7.2 - Tính toán mã khóa SAC


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 mục tham chiếu ở cột bên.

mục 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. mục 7.1.3

95

TCVN xxxx :2016


3 CICAM phải gửi cc_data_req APDU đến máy chủ, bao gồm các thông số sau:

nonce Ns_module.

CICAM_ID được lấy từ giấy chứng nhận thiết bị của CICAM.

mục 11.3.3.5

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 . mục 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 c c _da t a_ c nf 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.

mục 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 ghi 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.

mục 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 ghi 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.

mục 7.1.3

8 CICAM phải gửi c c _ s y n c _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.

mục 11.3.3.5

9 Máy chủ phải xác nhận bằng a c c _ s yn c _ c nf 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 ghi chú 3

mục 11.3.3.5

Ghi 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 mục 6.3

3. Tham chiếu đến mục 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.

19.2.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 chứng thực (lại); khi không có AKM hợp lệ được lưu trữ trong bộ nhớ, phiên chứng 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 chứng thực (lại) tiếp theo.

96

Hp4530, 09/24/14,

reboot

TCVN xxxx : 2016 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.


(1) Khởi tạo SAC

(2) CICAM khởi tạo đồng hồlàm mới mã khóaSAC về 0 giây

(3) CICAM gửi CICAM nonce ‘ns_module’

(4) CICAM nhận nonce của máychủ ‘ns_host’

(5) CICAM tính SAK và SEK

(6) Đồng hồlàm mới

SAC ≤ 9 giây

(7) CICAM gửi yêu cầu đồng bộ

(8) CICAM có nhậnđược xác nhận đồngbộ trong thời gian chờ ?

(6) Đồng hồlàm mới

SAC ≤ 10 giây

(10) Đợi 1 giây

Không((số lần cố thử nhở hơn giới hạn)

(11) CICAM cho phép hoạtđộng SAC

(12) CICAM khởi tạo bộ đếmbản tin max_msg_counter = 1

(13) CICAM gửi bản tin: max_msg_counter + 1

(14) max_msg_countercó vượt quá mức

Không

Không

Có

Có

Có

KhôngCó

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

97

Hp4530, 09/24/14,

overrung

TCVN xxxx :2016

(1) Máy chủ nhận CICAMnonce “ns_module”

(2) Máy chủ trả lời bằng nonce của máy chủ “ns_host”

(4) Máy chủ nhận yêu cầuđồng bộ

(5) Máy chủ xác nhận dđồngbộ và bắt đầu sử dụng cácmã khóa SAC mới được tính

(3) Máy chủ tính SAK và SEK

Hình 7.5 - Lưu đồ - phiên làm mới mã khóa SAC của máy chủ

19.2.3 Tính toán mã khóa SAC

SAC yêu cầu hai mã khóa để hoạt động: mã khóa chứng 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:

Eq. 7.1

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

Eq. 7.2

Trong đó:

Ks CICAM = Ks host

Các thông số đầu vào được quy định tại Bảng 7.3:

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




DHSK 128 Các bit LSB của mã khóa mật DH từ quá trình chứng thực. Xem ghi chú 3

mục 6.2.3.3

AKH / AKM 256 Các mã khóa chứng thực từ quá trình chứng thực.

mục 6.2.3.4

98

Hp4530, 09/24/14,

seed

TCVN xxxx : 2016




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

Ghi chú:


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:

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ừ Bản quy định kỹ thuật giấy phép CI PLus [33].

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

99

TCVN xxxx :2016

(1) SAC được khởi tạo

(2) Nhận bản tin

(3) Bộ đếm bản tincó hợp lệ ?

(4) Tăng bộ đếm bản tin của thiết bị thu

Bộ đếm bản tin được thiết lập

(5) Giải mãcó ok ?

(6) Kiểm tra bản tincó ok ?

(7) Xử lý tảii (8) Bỏ qua bản tin

Không(kiểm tra bản tin lỗi)

Không(giải mã bản tin lỗi)

Không(thứ tự bản tin lỗi)

Khởi tạo lại SACCó

Có

Có

Hình 7.6 - Xử lý trạng thái SAC.

100

TCVN xxxx : 201619.3 Định dạng của bản tin SAC

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

Kích thước được cố định vàchỉ ra trong phần mào đầu

Tải thay đổi (ví dụ: APDU)

Phần mào đầu với kích thướcđược cố định và chỉ ra

Bộ đếm với kích thước đượccố định

Bộ đếm bản tin Phầnmàođầu

Tải Chứng thực

Kiểm tra(tùy chọn) bảo vệPhần mào đầu

Bản tin SAC

Ghi chú: SAC được chứng 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

/* message header starts here */ protocol_version authentication_cipher_flag payload_encryption_flag encryption_cipher_flag

reserved for future use length_payload

/* message header ends here */

/* message body starts here */

if (payload_encryption_flag == MSG_FLAG_TRUE) encrypted_payload

else if (payload_encryption_flag == MSG_FLAG_FALSE) payload

authentication

19.3.1

32

20

4

3

1

3

5

16

21

22

23

leng t h_pa yl oad * 8 + 128

24

25

uimsbf

26

uimsbf

uimsbf

b s l b f u

i m s bf

bslbf

uimsbf

27

28

29

bslbf

101

TCVN xxxx :2016

Trường Số bit Kiểu

/* message body ends here */

length_payload * 8

128

30

31

bslbf

bslbf

31.1.1

31.1.2 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

31.1.3 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 mục 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 chứng 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] (ghi chú 2)

0x1-0x7 Dự phòng 31.1.4

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

102

TCVN xxxx : 2016encryption_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 chứng 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à chứng thực. Tham khảo mục 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 chứng thực của bản tin. Tham khảo mục 7.3.1 dành cho mô tả về thủ tục chứng 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 mục 7.3.2 để biết chi tiết.

Bản tin Bản tin

SAC củamáy chủ

Giải mã&

kiểm tra

Chứngthực

& mã hóa

CI SAC#1

CI SAC#2

Chứngthực

& mã hóa

Đồng bộĐồng bộ

APDU

APDUAPDU

SAC

#1

SAC

#2

Ghi chú: CI 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_flag

Nội dung Ý nghĩa Diễn giải

0x0 AES-128 in CBC m o de

AES-128 tuân theo FIPS 197 [4] trong chế độ CBC tuân theo 800-38A [25]

0x1-0x7 Dự phòng 31.1.5

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

31.2 Truyền các bản tin SAC

Một bản tin dữ liệu được gửi đến CI 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 mục 7.2.2 để biết chi tiết.

103

Hp4530, 09/24/14,

exhaustion

Hp4530, 10/17/14,

padding

TCVN xxxx :20162)Tính toán chứng thực của bản tin. Tham khảo mục 7.3.1 để biết chi tiết.

3) Ghép chứng thực và tải và (tùy chọn) mã hóa bản tin này. Tham khảo mục 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 | phần bản tin thu được từ bước 3). Tham khảo mục 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 mục 7.1.4 để biết chi tiết.

31.2.1 Chứng thực bản tin

Bản tin dữ liệu trên CI SAC được một trường chứng thực bảo vệ. Trường chứng thực này được tính như sau:

Eq. 7.4

Trong đó:

MAC là thuật toán được authentication_cipher_flag quy định, xem mục 7.2.2.

SAK một khóa 128 bit, theo quy định tại mục 7.1.3.

Việc chứng thực được thực hiện trên toàn bộ bản tin, ngoại trừ trường chứng thực. Các thông số này được sử dụng trong tính toán trường chứng 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

leng t h_ h i 8 uimsbf

i 32 uimsbf

heade r _ h i length_hi * 8 bslbf

pa y loa d _ p i y * 8 bslbf

i - Trường này chứa giá trị message_counter từ bản tin này. Tham khảo mục 7.2.2 dành cho mô tả của trường này.

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

header_hi - 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_pi - Thông số này chứa tải của bản tin. Để tính toán trường chứng thực này, tải không được mã hóa ban đầu phải được sử dụng.

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

Eq. 7.5

Trong đó:

E là thuật toán được encryption_cipher_flag quy định, xem mục 7.2.2.

SEK là mã khóa 128 bit. Tham khảo mục 7.1.3 để biết chi tiết.

104

Hp4530, 09/24/14,

keyset

Hp4530, 09/24/14,

construct

TCVN xxxx : 2016 SIV là cố định, dài 128 bit và một hằng số của giấy phép, tham khảo Bản quy định kỹ thuật giấy

phép CI Plus [33]. SIV phải được sử dụng ở phần đầu của mỗi bản tin SAC.

Chứng thực ai phải được tính như mô tả trong mục 7.3.1.

Chú ý: Nếu payload_pi 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.

31.3 Nhận các bản tin SAC

Một bản tin dữ liệu được CI 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 mục 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 mục 7.4.2 để biết chi tiết chính xác.

3) Tính toán lại trường chứng thực và kiểm tra tính toàn vẹn của bản tin. Tham khảo mục 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 mục 7.1.4 để biết chi tiết.

31.3.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ừ CI 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 mục 7.1.4

Các giới hạn của bản tin:

Số bản tin bị giới hạn ở 2 32-1 bản tin. Trường hợp số bản tin vượt quá, thiết bị phải dừng sử dụng các mã khóa hiện tại và thương lượng các mã khóa mới (xem mục 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 mục 7.1.4.

31.3.2 Giải mã bản tin

Bản tin dữ liệu trên CI SAC có thể được mã hóa. Việc giải mã được thực hiện như sau:

Eq. 7.6

Trong đó:

D là thuật toán được encryption_cipher_flag quy định, xem mục 7.2.2.

105

Hp4530, 09/24/14,

out of order

Hp4530, 09/24/14,

locally

Hp4530, 09/24/14,

block cipher size

TCVN xxxx :2016 SEK là mã khóa 128 bit. Tham khảo mục 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 Bản quy định kỹ thuật giấy phép CI Plus [33]. SIV phải được sử dụng ở phần đầu của mỗi bản tin SAC.

Việc giải mã một bản tin không chính xác gây ra một "lỗi giải mã bản tin"; Điều này được xử lý như trong mục 7.1.4

Chú ý: authentication_a i được tách ra từ payload_p i nơi độ dài của authentication_a i có thể được suy ra từ giá trị của authentication_cipher_flag.

Dữ liệu đầu vào SAC ban đầu = payload_p i thu được - authentication_ a i.

Nếu payload_p i không là bội số của kích thước khối mã (tức là 128 bit) thì bản tin này được đệm bằng cách thêm 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.

31.3.3 Kiểm tra bản tin

Bản tin dữ liệu trên CI SAC chứa một trường chứng thực. Việc chứng thực phải được xác nhận như:

Eq. 7.7

Trong đó:

MAC là thuật toán được authentication_cipher_flag quy định, xem mục 7.2.2.

SAK một khóa 128 bit, theo quy định tại mục 7.1.3.

Để mô tả các thông số còn lại tham khảo mục 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 chứng 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 mục 7.1.4.

31.4 Tích hợp SAC vào CI 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.

106

TCVN xxxx : 2016

Dữ liệu tùy ý(vídụ: cấu trúc đối tượng

Dữ liệu SAC được mã hóa

Phần đệmTải SACPhần màođầu SAC

Chứngthực SAC

Phầnmào đầu

SAC

Độ dàiAPDU

ThẻAPDUBước 3

Bước 2

Bước 1

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


1 Hệ thông thu thập các đối tượng dữ liệu tạo thành tải SAC. mục 11.3.1.7

2 Hệ thống chứng 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).

mục 7.3

3 Tải SAC và chứng 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.

mục 7.5

Ghi chú: Tham chiếu bảng 11.10 dành cho các bản tin được truyền qua SAC

107

TCVN xxxx :2016

32 Các tính toán mã khóa nội dung

32.1 Giao thức làm mới mã khóa kiểm soát nội dung

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

Hình 8.1 được sử dụng để tham khảo:

CICAM Máy chủ

[1] Mã khóa (lại) CCK được yêu cầu

[2] tạo mã khóa Kp

[3] lấy CIV và/ hoặc CCK

[4] gửi CC_sac_data_req(Kp+CICAM_ID+keyregister)[5] kiểm tra CICAM_ID

[6] xác nhận CC_sac_data_cnf(Host_ID+status)

[7] kiểm tra HOST_ID

[8] lấy CIV và/ hoặc CCK

[9] gửi CC_sac_sync_req()[10] xác nhận CC_sac_sync_cnf(trạng thái)


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


Bảng 8.1 - Tính toán CCK


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 mục tham chiếu ở cột bên.

mục 8.1.2

2 CICAM tạo nonce để tạo Kp như sau:

Kp SHA 256 (nonce)

mục A.1

3 CICAM có thể ngay lập tức bắt đầu tính CIV và/ hoặc CCK. mục 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.

mục 11.3.3.4

108

TCVN xxxx : 2016


Lựa chọn thanh ghi chẵn hoặc lẻ.

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

mục 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.

mục 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 đó (ghi 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 ghi chú 6.

mục 8.1.4

8 Máy chủ có thể tính CIV và/ hoặc CCK. mục 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 đã hoatjn 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.

mục 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 ghi chú 6.

mục 11.3.3.4

Ghi 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 mục 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 mục 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 mục 7.

5. HOST_ID / CICAM_ID được lưu trữ trước đó trong 'Authentication Context'. Tham chiếu đến mục 6.3

6. Tham chiếu đến mục 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.

32.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à chứng thực đã hoàn thành thành công.

Khi được CAS kích hoạt.

109

TCVN xxxx :2016 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 mục 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.

(22) CICAM vô hiệu việcgiải xáo trộn của mạng CA

(1) Khởi tạo CC

Không (>30s.)

(15) Đồng hồ làmmới mã khóa:

10 > t > 30 giây?Có (từ 10 đến30 giây.)

KhôngKhông(<10s.)

(3) CICAM gửi mãkhóa Kp.

(14) CICAM đãnhận được xácnhận đồng bộ ?

(16) CICAM vô hiệu việcgiải xáo trộn của mạng CA(4) CICAM bắt đầu tính

CIV và/ hoặc CCK.

Có(5) CICAM nhận xácnhận của máy chủ

(17) CICAM cho phép hoạt độngxáo trộn CC và giải xáo trộn của CA

(6) Chu kỳKey_lifetime

ban đầu?Không

(18) CICAM khởi tạoblock_counter = 1.Có

Không(12) Đồng hồlàm mới mã

khóa ≤ 9 giây ?

(7) Đồng hồlàm mới mã

khóa ≤ 9 giây ?

Không (số lần cốthử < giới hạn) (19) CA có yêu

cầu làm mớimã khóa ?

CóKhông

CóCó Không

(20) key_lifetime

hết ?

(8) CICAM gửiyêu cầu đồng bộ

(13) CICAM gửiyêu cầu đồng bộ

(11) Đợi 1 gây Có

Có Không

(9) CICAM đã nhận đượcxác nhận đồng bộ trong

thời gian chờ`?

(21) block_counter

hết?

(10) Đồng hồlàm mới mãkhóa ≤ 10 giây?

Có

KhôngCó

(2) CICAM khởi tạo đồng hồlàm mới mã khóa về 0 giây

Không


Ghi 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 mục 8.1.33. Giới hạn bộ đếm khối được quy định trong bảng 8.24. 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 232 33

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

110

Hp4530, 09/25/14,

lifetime

TCVN xxxx : 2016

Hình 8.3 giải thích hoạt động của máy chủ khi làm mới CCK.

(1) Đợi việc lầm mới mãkhóa của CICAM

(2) Máy chủ nhận mãkhóa Kp

(3) Máy chủxác nhận

(5) Máy chủ nhận yêu cầuđồng bộ

(6) Máy chủ xác nhận vàbắt đầu sử dụng các mãkhóa CC (mới) được tính


(4) Máy chủ tính CIV và/ hoặc CCK

Hình 8.3 - Hoạt động của máy chủ khi làm mới CCK

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

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

111

Hp4530, 09/25/14,

precursor

Hp4530, 09/25/14,

countdown

TCVN xxxx :2016

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




nonce 256 Nonce 256 bit ngẫu nhiên được CICAM tạo ra. Phụ lục A

Ghi chú:


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:

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 Bản quy định kỹ thuật giấy phép CI Plus [33].

Sau khi chứng 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 mục 6). Mã kiểm soát nội dung (CCK) và vector 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.

33.1.3 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 mục 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:

Eq. 8.3

Chú ý: Tham khảo mục 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.

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

Eq. 8.4

Trong đó:

CCK AES phải thay đổi theo quy định tại mục 5.6.1. Ngoài ra, CCK AES phải được thay đổi sau khi xử lý 2 32 khối AES.

CIV là cố định đối với mỗi giai đoạn thời gian sống của mã khóa và phải thay đổi khi CCK thay đổi. CIV hiện tại phải được sử dụng lại ở phần đầu của mỗi gói tin MPEG2 TS.

112

TCVN xxxx : 2016Chú ý: Tham khảo mục 5.6.2.3 dành cho đặc điểm chi tiết của bộ xáo trộn (lại) AES.

34 Chi tiết giấy chứng nhận và PKI

34.1 Giới thiệu

Việc chứng thực giữa một máy chủ CI Plus và mô-đun bao gồm việc trao đổi giấy chứng nhận. Giấy chứng nhận thiết bị của một máy chủ hoặc mô-đun phục vụ ba mục đích:

chứng minh rằng thiết bị tuân thủ Bản quy định kỹ thuật CI 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 chứng 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ụ CI 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.

34.2 Kiến trúc quản lý giấy chứng nhận

Hệ thống phân cấp tin cậy CI 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 CI Plus, xem Hình 9.1.

Gốc tin cậy

Thương hiệu A Nhà cung cấp dịch vụ

Máy chủ X Máy chủ Y

Thương hiệu B

Mô đun Z

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

113

TCVN xxxx :2016 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ấy 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 CI Plus


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.

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

Tất cả các giấy chứng nhận CI 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], mục 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], mục 4.1, được trình bày dưới đây để tham khảo:

Certificate ::= SEQUENCE

tbsCertificate TBSCertificate,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING

TBSCertificate ::= SEQUENCE

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version MUST be v2 or v3

114

TCVN xxxx : 2016subjectUniqueID[2] IMPLICIT UniqueIdentifier 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

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= 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.

34.3.1 Phiên bản

CI Plus phải sử dụng X.509 phiên bản 3.

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

34.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], mục 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

115

TCVN xxxx :2016

saltLength 20 byte

trailerField 1 byte: 0x bc

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

34.3.4 Tổ chức phát hành

Các giấy chứng nhận CI 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 CI Plus>

OU: “đo thử ” hoặc “sản xuất”

CN: "Giấy chứng nhận CA gốc CI PLus"


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


Giấy chứng nhận thiết bị C: <quốc gia nơi thương hiệu nằm> ST: <bang/ tỉnh nơi thương hiệu nằm> L: <thành phố nơi thương hiệu nằm>

116

TCVN xxxx : 2016

Loại giấy chứng nhận Tổ chức phát hành

O: <tên của thương hiệu >


CN: "CI Plus ROT for" <tên của 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>




Các thuộc tính X.501 được CI 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], mục 4.1.2.4. Tất cả cả các giá trị thuộc tính có thể được mã hóa theo PrintableString hoặc UTF8String.

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

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



117

Hp4530, 09/25/14,

validity

TCVN xxxx :2016

Loại giấy chứng nhận Đối tượng



C: <quốc gia nơi thương hiệu nằm> ST: <bang/ tỉnh nơi thương hiệu nằm> L: <thành phố nơi thương hiệu nằm>

O: <tên của thương hiệu>


CN: "CI 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ị>


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 Bản quy định kỹ thuật giấy phép CI 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 mục 3.1.4 của Bản quy định kỹ thuật bổ sung CI Plus [37].

34.3.7 subjectPublicKeyInfo

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], mục 4.1.2.7 dành cho mã hóa khóa công khai.

118

TCVN xxxx : 201634.3.8 issuerUniqueID và subjectUniqueID

Các thông số issuerUniqueID và subjectUniqueID được định nghĩa trong RFC 3280 [19], mục 4.1.2.8. Các giấy chứng nhận CI Plus không được sử dụng các nhãn định danh duy nhất.

34.3.9 Phần mở rộng

Các giấy chứng nhận dành cho CI 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 CI 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


Giấy chứng nhận thiết bị sử dụng mã khóa



sc r a m b l er c ap a bi l it i e s

Thông tin CI Plus (tùy chọn)

Nhãn nhận dạng thương hiệu CICAM (CIC A M onl y )


sử dụng mã khóa



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

34.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], mục 4.2.1.2.

34.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], mục 4.2.1.1. Trường keyIdentifier phải được tính theo đề xuất (1) trong RFC 3280 [19], mục 4.2.1.2.

119

Hp4530, 09/26/14,

proposal (1)

TCVN xxxx :201634.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], mục 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

34.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], mục 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 -

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

120

TCVN xxxx : 2016

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 Bản quy định kỹ thuật giấy phép CI Plus [33] để biết thêm chi tiết.

34.3.9.6 CI Plus info

Phần mở rộng riêng tùy chọn của CI Plus info truyền thông tin bổ sung về thiết bị CI 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-ciplusInfo OBJECT IDENTIFIER ::= id-pe 26

id-pe ::=



CiplusInfo ::= BIT STRING

Nội dung của CiplusInfo 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.

34.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ị CI 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 mục 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-cicamBrandId OBJECT INDENTIFIER ::= id-pe 27 id-pe ::=



CicamBrandId ::= INTEGER (1..65535)

34.3.10 signatureAlgorithm

Trường này giống Đóng dấu trong mục 9.3.3

34.3.11 signatureValue

Trường này được định nghĩa trong RFC 3280 [19], mục 4.1.1.3

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

Trong quá trình chứng thực (xem mục 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.

121

TCVN xxxx :2016Giấy chứng nhận gốc CI Plus được lưu trữ trong mỗi thiết bị, trong quá trình chứng 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.

34.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 KeyIdentifier 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 KeyIdentifier 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], mục 8.1.2.

Bảng 9.8 - Kiểm tra giấy chứng nhận thương hiệu


Mã khóa công khai RSA của đóng dấu

subjectPublicKeyInfo 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], mục 4.1)

Đóng dấu được kiểm tra signatureValue của giấy chứng nhận thương hiệu

34.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 mục 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 phải thất bại 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 KeyIdentifier 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 KeyIdentifier 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.

122

TCVN xxxx : 20165) 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], mục 8.1.2.

Bảng 9.9 - Kiểm tra giấy chứng nhận thiết bị



subjectPublicKeyInfo 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], mục 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 Bản quy định kỹ thuật giấy phép CI Plus [33].

34.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 mục 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 KeyIdentifier 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 KeyIdentifier 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], mục 8.1.2.

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



subjectPublicKeyInfo 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], mục 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.

123

Hp4530, 09/26/14,

multiplex

TCVN xxxx :2016

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

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

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

Cú pháp Số bit Kiểu

ci_protection_descriptor() descriptor_tag descriptor_length free_ci_mode_flag match_brand_flag reserved_future_use if(match_brand_flag == 1)

number_of_entries for(i=0; i<n; i++)

cicam_brand_identifier

for(i=0; i<n; i++) private_data_byte

35.1.2

8

8

1

1

6

36

8

37

16

38

39

40

8

41

ui m s bf ui m s bf b s l b f b s l b f b s l b f

42

uimsbf uimsbf

43

44

uimsbf

124

Hp4530, 09/26/14,

specifier

TCVN xxxx : 201644.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ó cicamBrandId 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.

44.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 Bản quy định kỹ thuật giấy phép CI Plus [33].

44.2 Nhận được 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 truyền trực tiếp đến demux máy chủ.

2) chế độ pass-through; MPEG-2 TS được định tuyến thông qua CICAM đến demux 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.

125

TCVN xxxx :2016Trườ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ủ có thể tin cậy vào MPEG2 TS nhận được từ CI Plus CICAM và chế độ pass-through có thể được 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ự.

Chế độ by-pass của máy chủBộ dò kênh

Bộ giải ghép kênh

Chế độ CICAM pass-through

CICAM1..n

Chuyển nguồn

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 Actual

phù hợp. Việc lưu trữ 7 ngày chỉ ra rằng một máy chủ có thể mất đến 7 ngày để phản ứng với sự thay đổi trạng thái CI Plus trong mạng.

44.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 ghi chú 1) DVB CI và CI Plus không hoạt động

ci_protection_descriptor sẵn có và fre e _CI_ m ode 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"

44.3.1

CI Plus

45

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

46

hoạt động

ci_protection_descriptor sẵn có, free_CI_mode là "1", match_brand_flag = "1" và number_of_entries ≠ "0" và

46.1.1 47

126

TCVN xxxx : 2016

Thông báo Loại CICAM Chế độ hoạt động ngăn chặn dịch vụ

nhãn nhận dạng thương hiệu CICAM giống nhau CI Plus không hoạt động

Ghi chú:

1. Không thu được SDTActual trong chế độ nhận được t in 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

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

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

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

127

Hp4530, 10/17/14,

Active

Hp4530, 10/17/14,

In-active

TCVN xxxx :2016hoạ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.

Dữ liệu đượclưu trữ cótồn tại ?(3)

Thời gian chờ5 giây đối với

SDT ? (6)Có

Dữ liệu ngănchặn có tồn

tại ? (7)

Ngăn chặn dịch vụchưa hoạt động

Bắt đầu (1)

Lựa chọn dịch vụ (2)

Ngăn chặn dịch vụhoạt động (4)

Yêu cầu bảngSDT (5)

Dữ liệu thươnghiện có tồn tại

? (9)

ID của thươnghiện có giống

nhay ? (13)

Ngăn chặndịch vụ chưa

hoạt động (14)

CICAM cótrong chế độ CI

Plus ?(10)

Ngăn chặndịch vụ chưa

hoạt động (11)

Ngăn chặndịch vụ hoạt

động (12)

Cókhông

không

Có

Có

Có Có

Không

Không

Không

Không

128

TCVN xxxx : 2016Ghi 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 ?

Ghi 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

129

TCVN xxxx :2016

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

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

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

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

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


request_cicam_reset()

request_cicam_reset_tag

length_field() = 0

48.1.3

24

49

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.

length_field: Độ dài của tải APDU trong định dạng ASN.1 BER, xem EN 50221 [7], mục 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.

49.1.1.1 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

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

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

130

TCVN xxxx : 201650.1.1.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


data_rate_info() 50.1.2

24

51

uimsbfdata_rate_info_tag

length_field() = 1 51.1.3 51.1.4

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

96 Mbit/s

Dự phòng

00

01

các giá trị khác

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

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

131

Hp4530, 09/29/14,

menu

TCVN xxxx :201651.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


Host_country_enq() Host_country_enq_tag length_field() = 0

51.2.2

24

52

uimsbf

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

52.1.1.1 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


Host_country() 52.1.2

24

53

uimsbfHost_country_tag

length_field() = 3 53.1.3 53.1.4

iso_3166_country_code 24 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 ISO 3166-1 alpha 3, [17]. Mỗi ký tự được mã hoá 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.

53.1.6.1 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


Host_language_enq() Hos t _language_enq_tag length_field () = 0

53.1.7

24

54

uimsbf

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

132

TCVN xxxx : 201654.1.1.1 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


Host_language() 54.1.2

24

55

uimsbfHost_language_tag

length_field() = 3 55.1.3 55.1.4

iso_639.2_language_code 24 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ã hoá 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.

55.2 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ư chứng 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], mục 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.

55.2.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. Mục 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 Chứng thực

133

Hp4530, 09/30/14,

resource manager protocol

TCVN xxxx :2016

APDU_Tag Chiều APDU được sử dụng để

Kiểm tra khoá chứng thực

Tính khoá SAC

cc_data_cnf CICAM HOST Chứng thực

Kiểm tra khoá chứng thực

Tính khoá SAC

cc_sync_req CICAM HOST Tính khoá SAC

cc_sync_cnf CICAM HOST Tính khoá SAC

cc_sac_data_req CICAM HOST Tính khoá 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 khoá 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 khoá CC

cc_sac_sync_cnf CICAM HOST Tính khoá 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], mục 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.

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

134

TCVN xxxx : 2016


cc_open_req() cc_open_req_tag length_field()=0

55.2.2

24

56

Uimsbf

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

56.1.1.1 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


cc_open_cnf() 56.1.2

24

57

uimsbfcc_open_cnf_tag

length_field() 57.1.3 57.1.4

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

57.1.6.1 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 mục 11.3.2. cc_data_req được sử dụng dành cho dữ liệu không cần phải được chứng thực hoặc mã hóa. Đối với dữ liệu phải được chứng 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() cc_data_req_tag length_field() cc_system_id_bitmask send_datatype_nbr

for (i=0; i<send_datatype_nbr; i++) datatype_id

datatype_length

data_type

request_datatype_nbr

57.1.7

24

58

8

8

59

8

16

uimsbf bslbf

uimsbf

60

uimsbf uimsbf bslbf

61

uimsbf

135

TCVN xxxx :2016


for (i=0; i<request_datatype_nbr; i++) datatype_id

8*datatype_length 8

8

uimsbf

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

cc_system_id_bitmask: xem mục 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.

61.1.1.1 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. Ddữ liệu chính xác với các giao thức này được quy định trong mục 5.

cc_data_cnf được sử dụng dành cho dữ liệu không cần phải được chứng 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() cc_data_cnf_tag length_field() cc_system_id_bitmask send_datatype_nbr


datatype_length data_type

61.1.2

24

62

8

8

63

8

16

8*datatype_length

uimsbf

64

bslbf

uimsbf

65

uimsbf uimsbf bslbf

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


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ế

136

TCVN xxxx : 201665.1.1.1 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


cc_sync_req()

cc_sync_req_tag length_field()=0

65.1.2

24

66

uimsbf

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

66.1.1.1 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 mục 11.3.2 bên dưới.

Bảng 11.16 - Cú pháp cc_sync_cnf APDU


cc_sync_cnf() 66.1.2

24

67

uimsbfcc_sync_cnf_tag

length_field()=1 67.1.3 67.1.4

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

67.1.6.1 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 chứng 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

137

TCVN xxxx :2016


cc_sac_data_req()

cc_sac_data_req_tag

length_field()

sac_message()

67.1.7

24

68

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 mục 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 mục 11.3.2.

Bảng 11.19 – Tải cc_sac_data_req



send_datatype_nbr 8 uimsbf

for (i=0; i<send_datatype_nbr; i++) 68.1.1 68.1.2

datatype_id 8 uimsbf

datatype_length 16 uimsbf

data_type 8*datatype_length bslbf

68.1.3 68.1.4

request_datatype_nbr 8 uimsbf

for (i=0; i<request_datatype_nbr; i++) 68.1.5 68.1.6




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.

68.1.8.1 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 chứng thực và mã hóa. Mục 7 mô tả chi tiết về dữ liệu của

138

TCVN xxxx : 2016giao 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


cc_sac_data_cnf()

cc_sac_data_cnf_tag

length_field()

sac_message()

68.1.9

24

69

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 mục 7, Hình 7.7 và Bảng 7.4.

payload_encryption_flag 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 mục 11.3.2.

Bảng 11.21 – Tải cc_sac_data_cnf



send_datatype_nbr 8 uimsbf

for (i=0; i<send_datatype_nbr; i++) 69.1.1 69.1.2


datatype_length 16 uimsbf

data_type 8*datatype_length bslbf



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ế

69.1.4.1 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


cc_sac_sync_req()

cc_sac_sync_req_tag

length_field()

69.1.5

24

70

uimsbf

139

TCVN xxxx :2016

sac_message()

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 mục 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.

70.1.1.1 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


cc_sac_sync_cnf() 70.1.2

24

71

uimsbfcc_sac_sync_cnf_tag

length_field() 71.1.3 71.1.4

sac_message() 8 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 mục 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à 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


OK 0x00

Không hỗ trợ CC 0x01

Máy chủ bận 0x02

Không được yêu cầu 0x03


71.1.7 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 đó.

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


140

TCVN xxxx : 2016

cc_PIN_capabilities_req() cc _ PIN_capabilities_req_tag length_field() = 0

71.1.8

24

72

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


cc_PIN_capabilities_reply() 72.1.1

24

73

uimsbfcc_PIN_capabilities_reply_tag

length_field() 73.1.3 73.1.4

capability_field 8 uimsbf

pin_change_time_utc 40 bslbf

rating 8 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 CASvà 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 CASvà PIN nội dung không được điều khiển bởi PIN(với các PIN lưu trong CICAM)

0x04


Việc phân tích các giá trị capability_field được mô tả chi tiết hơn trong mục 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 MJDvà tiếp theo 24-bit được mã hoá 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

141

TCVN xxxx :2016trong 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.

73.1.6.1 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


cc_PIN_cmd()

cc_PIN_cmd_tag

length_field()

for (i=0; i<n; i++)

PINcode_data_bytes

73.1.7

24

74

75

8

76

uimsbf

uimsbf

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

PINcode_data_bytes: tải dành cho mã PIN, một byte được sử dụng cho mỗi số của mã PIN theo định dạng ASCII.

76.1.2.1 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


cc_PIN_reply() 76.1.3

24

77

uimsbfcc_PIN_reply_tag

length_field() 77.1.3 77.1.4

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

142

Hp4530, 09/30/14,

exert

TCVN xxxx : 2016

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


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.

77.1.6.1 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 mục 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


cc_PIN_event() 77.1.7

24

78

uimsbfcc_PIN_event_tag

length_field() 78.1.3 78.1.4

program_number 16 uimsbf

PINcode_status_field 8 uimsbf

rating 8 uimsbf

pin_event_time_utc 40 uimsbf

pin_event_time_centiseconds 8 uimsbf

143

TCVN xxxx :2016

private_data 8x15 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 MJDvà tiếp theo 24-bit được mã hoá 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.

78.1.6.1 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


cc_PIN_playback() 78.1.7

24

79

uimsbfcc_PIN_playback_tag

length_field() 79.1.3 79.1.4

rating 8 uimsbf

private_data 8 x 15 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.

79.1.6.1 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 mục 5.11.3.

144

TCVN xxxx : 2016Bảng 11.33 - Cú pháp cc_PIN_MMI_req APDU


cc_PIN_MMI_req()

cc_ PIN _ MM I _req_tag

length_field()

for (i=0; i<n; i++)

PINcode_data_bytes

79.1.7

24

80

81

8

82

uimsbf

uimsbf

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

PINcode_data_bytes: Tải dành cho mã PIN, một byte được sử dụng cho mỗi số của mã pin theo định dạng ASCII.

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

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

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

cc_open_req 82.1.4

2 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

82.1.4.1 Chứng thực

Chứng thực được mô tả trong mục 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 - Chứng thực

Bước Thực hiện APDU 82.1.5 82.1.6 Nội dung 82.1.7

1 CICAM gửi một nonce cc_data_req send_datatype_nbr =1 82.1.8 82.1.9

145

TCVN xxxx :2016

tới máy chủ82.1.10 82.1.12 i datatype_id 82.1.13 datatype_len

82.1.14 82.1.16 0 19(nonce) 82.1.17 256 b its

82.1.18 82.1.20 request_datatype_nbr= 4

82.1.21 82.1.23 i datatype_id82.1.24 82.1.25

82.1.26 82.1.28 0 13 (DHPH) 82.1.29 82.1.30

82.1.31 82.1.33 1 17 (Signature_A) 82.1.34

82.1.35 82.1.37 2 15 (Host_DevCert) 82.1.38

82.1.39 82.1.41 3 7 (Host_BrandCert) 82.1.42

2 Host gửi một nonce, mã khoá 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

82.1.43 i datatype_id 82.1.46 82.1.47

82.1.48 0 13 (DHPH) 82.1.51 2048bits

82.1.52 1 17 (Signature_A) 2048bits

82.1.55 2 15 (Host_DevCert) độ dài thay đổi được

82.1.58 3 7 (Host_BrandCert) độ dài thay đổi được

3 CICAM gửi mã khoá 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

82.1.61

cc_data_req send_datatype_nbr =4

82.1.62 i datatype_id 82.1.65 datatype_len

82.1.66 0 14 (DHPM) 82.1.69 2048bits

82.1.70 1 18 (Signature_B) 2048bits

82.1.73 2 16 (CICAM_DevCert) độ dài thay đổi được

82.1.76 3 8 (CICAM_BrandCert) độ dài thay đổi được

82.1.79 request_datatype_nbr= 1

82.1.82 30 status_field 82.1.85 82.1.86

4 Máy chủ gửi một xác nhận

cc_data_cnf send_datatype_nbr =1 82.1.87 82.1.88

82.1.89 i datatype_id82.1.92 datatype_len

82.1.93 0 30(status_field)

(Xem ghi chú 2)

8 bits

Ghi 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 chứng thực không thành công, xem Bảng11.17

82.1.95.1 Kiểm tra mã khóa chứng thực

Kiểm tra mã khóa chứng thực được thực hiện lúc khởi tạo và sau khi hoàn thành giao thức chứng thực (xem mục 6.2 và 11.3.3.2). CICAM kiểm tra xem cả hai phía có mã khóa chứng thực được lưu trữ giống nhau (AKH và AKM).

Bảng 11.36 - Kiểm tra mã khóa chứng thực


146

TCVN xxxx : 2016

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

cc_open_req 82.1.96

2 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

82.1.96.1 Tính mã khóa CC

Giao thức này được sử dụng để tính mã khóa CC mới, xem mục 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


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 (k eyreg i s ter )

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


0 5 (HOST_ID) 64 bits

1 30 (Status_field)

(Xem ghi chú 2)

8 bits

3 CICAM báo máy chủ biết đã hoàn thành tính mã khoá CC mới

cc_sac_sync_req 82.1.130

4 Máy chủ báo CICAM biết đã hoàn thành tính mã khoá CC mới

cc_sac_sync_cnf Status_field (xem Bảng11.17)

Ghi 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ảng11.17

3: Tất cả các bản tin SAC được mã hoá và chứng thực

147

TCVN xxxx :2016

82.1.130.1 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


1 CICAM gửi CICAM_ID và một nonce cc_data_req send_datatype_nbr =2


0 6 (CICAM_ID) 64bits

1 21 (Ns_module)

64 bits


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


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ã khoá SAC mới

cc_sync_req 82.1.161

4 Máy chủ báo CICAM biết đã hoàn thành tính mã khoá SAC mới

cc_sync_cnf status_field (xem Bảng11.20)

Ghi chú: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

82.1.161.1 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 mục 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 ỦRI cc_sac_data_req send_datatype_nbr =2

148

TCVN xxxx : 2016

tới máy chủ i datatype_id datatype_len

0 25 (uri_message) 64 bits

1 26 (program_number)

16 bits


i datatype_id

0 27(uri_confirm)

2 Máy chủ gửi một xác nhận tới CICAM



0 27(uri_confirm) 256 bits

Ghi chú:



82.1.185.1 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 mục 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(ur i _ v er s i on s )

2 Máy chủ gửi mặt nạ bit của các phiên bản URI được hỗ trợ



0 29(uri_versions) 256 bits

Ghi chú:



82.1.199 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

149

TCVN xxxx :2016thờ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.

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

83 84 Nội dung 84.1.1

1 CICAM cung cấp giấy phép nội dung cho máy chủ

cc_sac_data_req send_datatype_nbr =3or 4

i datatype_id 84.1.5 datatype_len

0 26 (program_number) (Xem ghi chú 3)

16 bits

1 34 (l i c e n s e _ s t atu s )(Xem ghi chú 4)

8 bits

2 25 (uri_message)

84.1.15 64 bits

3 33 (c i c a m _ l i c en s e )

84.1.19 variable


i datatype_id 84.1.26 84.1.27

84.1.29 84.1.30 0 35(l i c e n s e _r c v d _ s ta t u s ) 84.1.31

2 Máy chủ xác nhận đã nhận được

cc_sac_data_cnf send_datatype_nbr =1 84.1.32 84.1.33

84.1.34 84.1.35 84.1.36 i datatype_id 84.1.37 datatype_len

84.1.38 84.1.39 84.1.40 0 35 (license_rcvd_status)(Xem ghi chú5)

8 bits

Ghi chú:



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

150

TCVN xxxx : 2016

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


84.1.40.1 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 85 86 Nội dung 86.1.1

1 Máy chủ cung cấp giấy phép CICAM

cc_sac_data_req send_datatype_nbr =2 86.1.2 86.1.3


86.1.8 0 26 (program_number) 16 bits

86.1.11 1 36(Host_license) 86.1.14 variable

86.1.15 request_datatype_nbr=4

86.1.18 i datatype_id 86.1.21 86.1.22

86.1.23 0 26 (program_number) 86.1.26

86.1.27 1 34 (license_status)86.1.30 86.1.31

86.1.32 2 25 (uri_message) 86.1.35 86.1.36

86.1.37 3 33(cicam_license) 86.1.40 86.1.41

2 CICAM trả lời bằng cc_sac_data_cnf send_datatype_nbr =4

151

TCVN xxxx :2016

giấy phép và URI mới


86.1.46 0 26 (program_number) 16 bits

86.1.49 1 34 (license_status)(Xem ghi chú3) 8 bits

86.1.52 2 25 (uri_message) 86.1.55 64 bits

86.1.56 3 33 (cicam_license) 86.1.59 variable

Ghi chú:




86.1.59.1 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 87 88 Nội dung 88.1.1

1 Máy chủ cung cấp giấy phép CICAM

cc_sac_data_req send_datatype_nbr = 1 88.1.2 88.1.3


88.1.8 0 36 (Host_license) 88.1.11 variable

88.1.12 request_datatype_nbr = 2

88.1.15 i datatype_id 88.1.18 88.1.19

88.1.20 0 34 (license_status)88.1.23 88.1.24

88.1.25 1 37 (play_count) 88.1.28 88.1.29

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


88.1.34 0 34 (license_status) (Xem ghi chú 3) 8 bits

88.1.37 1 37 (play_count) 88.1.40 8 bits

Ghi chú:




Bảng 11.45 - Các giá trị license_status

152

TCVN xxxx : 2016

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ểmt tra trạng thái) 0x03

Số lượt phát lại vượt quá (xem & kiểmt tra trạng thái) 0x04

Giới hạn lưu giữ vượt quá (xem & kiểmt tra trạng thái) 0x05

Giấy phép không hợp lệ (xem & kiểmt tra trạng thái) 0x06


88.1.40.1 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


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


0 38 (o p erat i n g _ m o d e ) 8 bits

1 26 (program_number)

16 bits

2 39 (PIN c ode data ) variable (tùy chọn)

153

TCVN xxxx :2016

Bước


request_datatype_nbr = 1

i datatype_id

0 40 (r e c ord _ s ta r t _ s tat u s )

2 CICAM gửi xác nhận đến máy chủ



0 40 (record_start_status)

(Xem ghi chú 4)

8 bits

Ghi chú:




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

Timeshift 0x01

Ghi lại tự động (Unattended_Recording) 0x02


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

154

TCVN xxxx : 2016CICAM. 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.

88.1.64.1 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


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


0 38 (operating_mode) 8 bits

1 26 (program_number) 16 bits


i datatype_id

0 41 (m ode _ c h a ng e _s t at u s )

2 CICAM gửi xác nhận đến máy chủ



0 41 (mode_change_status) 8 bits

Ghi chú:




4: Bảng 11.17chứa các giá trị cho phép của trường này

88.1.88.1 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


1 Máy chủ thông báo cho CICAM rằng việc ghi lại đã bị dừng



0 26 (program_number) 16 bits


i datatype_id

0 42 (r e c ord _ s t o p_ s tat u s )

2 CICAM gửi xác nhận cc_sac_data_cnf send_datatype_nbr = 1

155

TCVN xxxx :2016

đến máy chủ i datatype_id datatype_len

0 42 (record_stop_status)

(Xem ghi chú 3)

8 bits

Ghi chú:



3: Bảng 11.17 chứa các giá trị cho phép của trường này

88.1.110 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


1 CICAM gửi SRM đến máy chủ


i datatype_id 88.1.114

0 31 (s r m _ d ata ) 88.1.118


i datatype_id

0 30 (status_field)

1 32 (da t atr a n s fe r _ c onf i r m )

2 Máy chủ gửi xác nhận đến CICAM



0 30 (status_field)

(Xem ghi chú 3)

8 bits

1 32 (datatransfer_confirm) 256 bits

Ghi chú:



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ảng11.24

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

156

TCVN xxxx : 2016Tà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.

TV/STB Truyềntải XLET

CI MHP APICICAM

Hệ thống CAAPI của ứngdụng CA

Tuyến SAS

Hình 11.2 - 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], mục 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 mục 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.

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

157

TCVN xxxx :2016

158

TCVN xxxx : 2016

89 MMI cấp ứng dụng CI Plus

89.1 Phạm vi

TS 101 699 [8] mục 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.

Mô đun Máy chủCáctậptin

Hiển thị

Công cụ trình bàyứng dụng CI Plus

Xử lý có sửdụng MMI

Tài nguyênMMI ứng dụng

Hành độngcủa ngườisử dụng

Cácyêu cầutập tin

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

CI Plus

MMI ứng dụngtrình duyệt CI Plus

DVB CI

MMIcấp cao

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

159

TCVN xxxx :2016cung cấp cho máy chủ trực tiếp thông qua tài nguyên MMI ứ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.

(Các) màn hình đồ họa riêngMàn hình MMI ứng dụng CI Plus

(Các) màn hình ứng dụng tùy chọnCác màn hình videoMàn hình nền

Người xem

Các màn hình hiện thị

Hình 12.3 – Các màn hình hiển thị

Hình 12.3 chỉ là tham khảo và bao gồm cả màn hình lô gíc và vật lý, việc thực hiện của máy chủ phải xác định ánh xạ vật lý phù hợp nhất dành cho một kiến trúc máy chủ nhất định. MMI ứng dụng phải hỗ trợ video đầy đủ cho phép ký tự và đồ họa được phủ trong suốt trên video (và có thể là trên bất kỳ màn hình ứng dụng riêng nào). MMI ứng dụng có độ phân giải SD gốc 720x576 pixel và phải được mở rộng toàn màn hình để phù hợp với khuôn dạng hình ảnh hiện tại trong cả hai môi trường SD và HD.

Việc cung cấp kiểm soát bị hạn chế trên các bộ giải mã MPEG cho phép video và âm thanh của dịch vụ hiện tại này được trình bày là bắt buộc đối với MMI ứng dụng, có thể sử dụng bổ sung một I-frame có khung hình đầy đủ để cung cấp nền đồ họa phong phú. MMI ứng dụng có thể từ chối việc kiểm soát MMI ứng dụng của bộ giải mã MPEG nếu một xung đột tài nguyên xảy ra.

Hồ sơ MMI ứng dụng bao gồm một phần mở rộng tùy chọn dành cho phông chữ phác thảo TrueType và OpenType tự động nạp cho phép các bộ ký tự quốc tế được ứng dụng này sử dụng. Phông chữ tự động nạp có thể không có sẵn trong tất cả các máy chủ và ứng dụng này có thể kiểm tra sự hỗ trợ của máy chủ từ bên trong ứng dụng.

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.

160

TCVN xxxx : 201689.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, mục 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.

89.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] Mục 13. Miền ứng dụng của CI Plus được gọi là " CIEngineProfile1 ".

89.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 ghi chú)

Nghệ thuật đường thẳng động Không bắt buộc.

HyperText Không bắt buộc.

Ghi chú: Xem D-Book[23] a n d mục 12.5.1Cá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.

89.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], mục 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-Bookvà 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

161

TCVN xxxx :2016CI 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.

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

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

89.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 mục 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.

89.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 mục 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.

162

TCVN xxxx : 201689.2.4 GetEngineSupport

Các "tính năng" của GetEngineSupport trong D-Book 5.0 [23] mục 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

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.

90.1 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], mục 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.

90.1.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ề"

90.1.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] mục 13.5.3.

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

90.1.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] mục 13.8, ngoại trừ các sự kiện của dòng sau đây không được CIEngineProfile1 yêu cầu.

163

TCVN xxxx :2016

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

90.1.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] mục 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.

90.1.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] mục 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_TuneIndex Tin Không bắt buộc

SI_TuneIndexInfo TII Không bắt buộc

GetBootInfo 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 mục 12.3.6.1

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

164

TCVN xxxx : 2016

ra 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] mục 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.

90.2 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 720x576 pixel. Màn hình đồ họa này phải phù hợp với độ phân giải và khuôn dạng hình ảnh hiện tại. Trường hợp video có độ nét cao thì màn hình đồ họa phải bị thu nhỏ để phù hợp với độ phân giải và khuôn dạng hiện tại.

Màn hình đồ họa CI Plus phải ở trên (các) màn hình video và bất kỳ màn hình phụ đề nào. Bất kỳ màn hình trung gian giữa màn hình đồ họa CI Plus và các màn hình video (và phụ đề) có thể tùy chọn bị tắt hoặc làm trong suốt, tức là trong một môi trường ứng dụng, màn hình đồ họa ứng dụng có thể được hiển thị nếu màn hình ứng dụng CI Plus là trong suốt.

Việc trình bày không gian màu sắc và bảng màu tối thiểu được D-Book 5.0 [23], mục 14 xác định. truecolour với số bit tối thiểu là 16 bit được khuyến nghị thực hiện.

90.2.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], mục 14.5.

90.2.2 Các PNG bitmap

Các PNG bitmap phải tuân thủ D-Book 5.0 [23], mục 14.7.

90.2.3 MPEG Stills

MPEG stills hoặc I-frame phải tuân thủ D-Book 5.0 [23], mục 14.8.

90.2.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], mục 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.

165

Hp4530, 10/02/14,

aspect ratio

TCVN xxxx :201690.2.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 mục 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] mục 12.11 và các mục có liên quan.

90.2.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] mục 11.4.1.

90.3 Ký tự của công cụ

CIEngineProfile1 phải tuân thủ hoàn toàn D-Book 5.0 [23], mục 15, ngoại trừ các trường hợp sau đây. Các mục sau đây thay thế mục 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ợ.

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

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

166

TCVN xxxx : 2016Tậ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], mục 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, out l i neR e s ol u t i o n

Trường unitsPerEm, được định nghĩa ở bảngFontHead e r („head‟)

advanceWidth, c harS e t W i d t h

Các giá trị ad v an c e W i d t h ,được định nghĩa ở bảngHorizontal Metrics ('htmx'). Xem ghi chú

xMin, y M in , y M a x được định nghĩa ở bảng Font Header ('head')

Kern Giá trị, được định nghĩa ở bảngKer n ing ('kern') t a ble

Ghi 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

90.3.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] mục 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.

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

167

Hp4530, 10/02/14,

kern

TCVN xxxx :2016 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.

90.4 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] mục 16, trừ những thay đổi cụ thể được trình bày trong trong phần này.

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

90.4.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 tại động "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.

90.4.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], mục 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

R

SSM=0

Các phụ đề (RTGraphics) phải được tắt trước khi bắt đầu CI PlusApplication, các tiêu đề phải được trả lại trạng thái trước đó sau khi chấm dứt CI PlusApplication

168

TCVN xxxx : 2016

Tên Giá trị tùy chọn

Ghi chú

TGraphics State

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 PlusApplicationkhông được phép bắt đầu.

SSM=2

Các phụ đề (RTGraphics)phải được tuỳ 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. Tuỳ chọn này là trạng thái mặc định phải được giả thiết khi tuỳ chọn SSM bị bỏ ra khỏi bộ xác định miền ứng dụng.

90.4.4.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], mục 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ể.

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

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

90.4.4.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] mục 16.7. Lưu trữ thường trực có thể được thực hiện trong bộ nhớ dễ thay đổi.

90.4.5 Mẫu tài nguyên máy chủ

Theo D-Book 5.0 [23] các mục 16.8 và 16.9 với những giới hạn sau đây.

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

169

TCVN xxxx :2016ứ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.

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

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

90.4.5.4 Xếp chồng ứng dụng

Xếp chồng ứng dụng theo mục 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.

90.5 Ánh xạ tên

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

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

90.5.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] mục 18.3.1 được áp dụng ngoại trừ các đối tượng DSM-CC.

90.5.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] mục 18.3.2 được áp dụng với những lưu ý sau đây:

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

170

Hp4530, 10/02/14,

scene

TCVN xxxx : 201690.5.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:".

90.5.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" (CCP0) 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 dùng 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ữ.

Ghi 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 trx 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 huỷ và phải được lấy lại một cách rõ ràng từ CICAMvới RequestType=File.

RequestType=File

171

TCVN xxxx :2016

Ưu tiên nhớ đệm

Ý nghĩa Phương pháp truy tìm nhớ đệm

RequestType=FileHash không được sử dụng cho CPP0.

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

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

TestInputMask TIM Quản lý mã khoá VOD – Sách trắngD T G

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.

90.6.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ợ SetInputMask (NewInputMask) của hành động thành phần.

90.6.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/ Kiểu Tên Diễn giải

172

TCVN xxxx : 2016

ra

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 () và phụ đề sẽ vẫn bị vô hiệu trong khi ứng dụng này đang chạy.

90.7 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] mục 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

173

TCVN xxxx :2016HD 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 720và 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 (mục 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 mục 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ự

174

Hp4530, 10/03/14,

manual line feeds

Hp4530, 10/03/14,

authors

TCVN xxxx : 2016cho 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ày 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 mục 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.

175

Hp4530, 10/20/14,

application author

TCVN xxxx :2016

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

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

91.2 MMI cấp cao

Tiêu chuẩn này không làm thay đổi EN 50221 [7] mục 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.

Tiêu đề

Phụ đề

Dòng 1

Dòng dưới cùng

Dòng 2

Dòng 3

Dòng 4

Dòng 5

Hình 13.1 - Trình bày MMI cấp cao

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

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

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

176

TCVN xxxx : 2016 Số lượng tối đa của các cấp để truy nhập vào menu CICAM là nhỏ hơn 3.

177

TCVN xxxx :2016

93 Các phần mở rộng CI khác

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

93.1.1 Sửa đổi 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


comms_cmd() descriptor_tag length_field() comms_command_id

if (comms_command_id == Connect_on_Channel) connection_descriptor()

retry_count timeout

if (comms_command_id == Set_Params) buffer_size

reception_timeout

if (comms_command_id == Get_Next_Buffer)

comms_phase_id

93.1.2

24

94

8

95

96

97

98

99

8

8

100

101

102

103

104

16

8

107

uimsbf uimsbf

107.1.1

107.1.2

107.1.3

107.1.4

107.1.5

107.1.6

uimsbf uimsbf

107.1.7

107.1.8

107.1.9

107.1.10

107.1.11

uimsbf uimsbf

107.1.12

107.1.13

178

TCVN xxxx : 2016

105

106

8

uimsbf

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.

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

179

TCVN xxxx :2016107.1.15 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.

180

TCVN xxxx : 2016

CICAM Máy chủ

[1] comms_cmd(Get_Next_Buffer, comms_phase_id = 15)

[2] đọc dữ liệu

[3] comms_rcv(comms_phase_id = 0, dữ liệu)[4] xử lý dữ liệu từ bộ đệm 0



[7] comms_rcv(comms_phase_id = 1, dữ liệu) [8] comms_rcv(comms_phase_id = 2, dữ liệu) [9] comms_rcv(comms_phase_id = 3, dữ liệu)

[10] comms_rcv(comms_phase_id = 4, dữ liệu)[11] xử lý dữ liệu từ bộ đệm 1

[12] comms_cmd(Get_Next_Buffer, comms_phase_id = 1) [13] xử lý dữ liệu từ bộ đệm 2



[16] comms_rcv(comms_phase_id = 5, dữ liệu)

[17] xử lý dữ liệu từ bộ đệm 3


[19] xử lý dữ liệu từ bộ đệm 4 & 5


Hình 14.1 – Kiểm soát dòng của CICAM

Bảng 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:

181

TCVN xxxx :2016Bảng 14.3 - Tính sẵn có của bộ đệm trong hình 14.1

Buffer Id

Bước

[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






"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

182

TCVN xxxx : 20165) 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


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





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




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



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

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

183

TCVN xxxx :2016

CICAM Máy chủ

[1] comms_send(comms_phase_id = 0, dữ liệu)















[1] comms_send(comms_phase_id = 15, dữ liệu)[2] gửi dữ liệu đối vớiPhase Id 0 & 1

[3] comms_reply(Send_Ack, return_value = 1)

[4] gửi dữ liệu đối vớiPhase Id 2 to 12



[7]gửi dữ liệu 13 to 0


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.

184

TCVN xxxx : 2016CICAM 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


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


108.1.2 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

108.1.3 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 mục 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.

108.1.4 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

185

TCVN xxxx :2016đượ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.

108.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, mục 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] mục 8.7.

Các nội dung của tải phải theo Network Byte Order.

Phần mào đầuAPDU

Tải

Tải

Tải IP

Phần mào đầuTCP hoặc UDP

Phần mào đầuIP

CICAM

Máy chủ

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.

186

TCVN xxxx : 2016Trê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.

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


connection_descriptor() connection_descriptor_tag /* see EN 50221 [7] */ length_field()

connection_descriptor_type

if (connection_descriptor_type == SI_Telephone_Descriptor) telephone_descriptor() /* see EN 300 468 [10] */

if (connection_descriptor_type == Cable_Return_Channel_Descriptor) channel_id

if (connection_descriptor_type == IP_Descriptor) IP_descriptor()

if (connection_descriptor_type == Hostname_descriptor) Hostname_descriptor()

108.2.2

24

109

8

110

111

112

113

8

114

uimsbf uimsbf

114.1.1

114.1.2

114.1.3

uimsbf

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

SI_Telephone_Descriptor 01

Cable_Return_Channel_Descriptor 02

IP_Descriptor 03

Hostname_descriptor 04

187

Hp4530, 10/06/14,

datagram

TCVN xxxx :2016

Tất cả các giá trị khác được dự phòng

114.1.4

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


IP_descriptor() 114.1.5

8

115

uimsbfdescriptor_tag

descriptor_length 8 uimsbf

IP_protocol_version 8 uimsbf

IP_address 128

uimsbf

destination_port 16 uimsbf

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


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

188

TCVN xxxx : 2016


0x03-0xFF

115.1.4.1 Comms Cmd Hostname_descriptor

Bảng 14.9 - Hostname_descriptor


Hostname_descriptor()

descriptor_tag

descriptor_length

protocol_type destination_port

for (i=0; i<n; i++)

Hostname_byte

115.1.5

8

8

8

16

116

8

117

uimsbf

uimsbf

uimsbf

uimsbf

117.1.1

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], mục 2.1.

117.1.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 device no.

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

189

TCVN xxxx :2016


Ghi chú: Bảng này thay thế mục 8.8.1.1trong tài liệu E N 50221[7]

device no. phải là 0 đối với loại thiết bị kết nối IP.

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

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

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

190

TCVN xxxx : 2016khô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.

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

Bước 1:Chờ tín hiệu kích hoạtnâng cấp

(1) Bắt đầu quá trình

(2) CICAM nhận thông báocụ thể

Bước 2:Chờ lựa chọn dịch vụ của CA (3) CICAM rnhận CA-PMT với

ID của hệ thống CA phù hợp

Bước 3:Khởi tạo tài nguyên nângcấp CICAM và đợi trả lờicủa máy chủ

(5) CICAM gửi bản ti n nângcấp phần mềm đến máy chủ

(6) CICAM nhận trả lời nângcấp phần mềm từ máy chủ

Bước 4:Thực hiện quá trình nâng cấp

(7) Có tảivề ngay ?

(8) Thực hiện quátrình tải về ngay

(9) Thực hiện quátrình tải về chậm

Kích hoạt nâng cấp

(4) Mở phiên dành chotài nguyên nâng cấp CICAM

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

191

TCVN xxxx :20164) 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.

(1) Bắt đầu nâng cấp bị trì hoãn

(2) Máy chủcó trả lời ?Có không

Hỏi người sử dụng

(3) Hiện thị MMI phản hồi

(4) Đợi phản hồicủa người sử dụng

(9) Đóng phiên cam_upgradeHủy bỏ

Chấp nhận

(5) Thực hiện việcnâng cấpphần mềm của CICAM 0%

(6) Dò kênh đến tần sốphù hợp

(7) Thực hiện việc nâng cấpphần mềm của CICAM n 0%

(8) Việc nâng cấp hoàn thành

Hình 14.6 - Quá trình bị trì hoãn

117.2.3.1 Quá trình bị trì hoãn

Khi việc nâng cấp bị trì hoãn được Head-end 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

192

TCVN xxxx : 2016Nế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).

117.2.3.2 Quá trình ngay lập tức

(1) Bắt đầu nâng cấp ngay lập tức

(2) Dừng việc giải xáo trộn

(3) Máy chủcó trả lời ?

(4) Hiện thị MMI phản hồi

(5) Đợi phản hồicủa người sử dụng

(6) Thực hiện việc nâng cấpphần mềm của CICAM 0%

(7) Dò kênh đến tần sốphù hợp

(8) Thực hiện việc nâng cấpphần mềm của CICAM n 0%

(9) Việc nâng cấp hoàn thành

Chấp nhận

Hủy bỏ

Hỏi người sử dụng

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 head-end 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ừ

193

TCVN xxxx :2016chố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.

117.2.4 Giao thức nâng cấp CAM

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

194

Hp4530, 12/09/14,

progress indicator

TCVN xxxx : 2016- Bước 2-Đợi dịch vụ CA sẵn sàng

CAMCI Plus

Máy chủCI Plus TS

-Bước 3- Bắtđầu quá trìnhCAM_Upgrade

CAPMT chứa nhãn mô tả CAID

- Bước 1-Tín hiệu kích hoạttải về phần mềm từsự kiện bên ngoài Yêu cầu mở phiên

Xác nhận mở phiên-Bước 4-Nếu trả lời của máy chủ là ‘hỏi’ thìgửi bản tin MMI đến người sửdụng đầu cuối để nhận phản hổi

cam_firmware_upgrade

cam_firmware_upgrade_reply

Bản tin MMI để hỏingười sử dụng -Bước 5-

Nếu phản hồi của người sử dụnglà OK thì dò kênh đến dịch vụ tảivề bằng cách sử dụng giao thứctài nguyên kiểm soát máy chủ

Bản tin trả lời MMI_Reply với phản hồicủa người sử dụng

cam_firmware_upgrade_progress 0%

Tài nguyên kiểm soát máy chủPhiên bản phầnmềm mới sẵncó cam_firmware_upgrade_progress

10, 20, …100 % - Bước 6-Đợi kết thúc quátrình trưới khikhởi động lại

cam_firmware_upgrade_complete

Hình 14.8 - Giao thức nâng cấp bị trì hoãn

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

195

TCVN xxxx :2016bản tin cam_firmware_upgrade_progress. Khi quá trình nâng cấp đã hoàn thành thì CICAM gửi cam_firmware_upgrade_complete APDU.

Nếu việc nâng cấp này không được chấp nhận thì nó có thể cố thử lại lần tiếp theo, máy chủ lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp. CICAM không được cố thử lại một nâng cấp trước thời điểm này. CICAM có thể lựa chọn để trì hoãn một nỗ lực nâng cấp cho đến một thời gian sau khi máy chủ một lần nữa lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp.

cam_firmware_upgrade_complete APDU chỉ ra cho HOST xem có yêu cầu thiết lập lại CICAM để hoàn thành quá trình nâng cấp. Khi nhận được cam_firmware_upgrade_complete APDU, máy chủ phải thực hiện bất kỳ việc thiết lập lại được yêu cầu và có thể lấy lại việc kiểm soát bộ dò kênh.

- Bước 2-Đợi dịch vụ CA sẵn sàng

CAMCI Plus

Máy chủCI PlusINBAND

-Bước 3- Bắtđầu quá trìnhCAM_Upgrade

CAPMT chứa nhãn mô tả CAID

Yêu cầu mở phiên

Xác nhận mở phiên

cam_firmware_upgrade

cam_firmware_upgrade_Reply

Bản tin MMI để hỏingười sử dụng

Bản tin trả lời MMI_Reply vớiphản hồi của người sử dụng

cam_firmware_upgrade_progress0%

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

cam_firmware_upgrade_progress1, 10, 23,…100%


- Bước 1-Tín hiệu kích hoạttải về phần mềm từsự kiện bên ngoài

Phiên bản phầnmềm mới sẵncó

-Bước 4-Nếu trả lời của máy chủ là ‘hỏi’ thìgửi bản tin MMI đến người sửdụng đầu cuối để nhận phản hổi

-Bước 5-Nếu phản hồi của người sử dụnglà OK thì dò kênh đến dịch vụ tảivề bằng cách sử dụng giao thứctài nguyên kiểm soát máy chủ

- Bước 6-Đợi kết thúc quátrình trưới khikhởi động lại

Hình 14.9 - Giao thức nâng cấp ngay lập tức

196

TCVN xxxx : 2016Má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ủ.

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

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

117.2.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 bản tin 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.

197

TCVN xxxx :20166) 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.

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

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

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


CICAM HOST

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


cam_firmware_upgrade() 117.2.6

24

118

uimsbfcam_firmware_upgrade_tag

198

TCVN xxxx : 2016

length_field() 118.1.3 118.1.4

upgrade_type 8 uimsbf

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

118.1.6.1 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


cam_firmware_upgrade_reply() 118.1.7

24

119

uimsbfcam_firmware_upgrade_reply_tag

length_field() 119.1.3 119.1.4

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

119.1.6.1 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

199

TCVN xxxx :2016


cam_firmware_upgrade_progress() 119.1.7

24

120

uimsbfcam_firmware_upgrade_progress_tag

length_field() 120.1.3 120.1.4

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

120.1.6.1 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


cam_firmware_upgrade_complete() 120.1.7

24

121

uimsbfcam_firmware_upgrade_complete_tag

length_field() 121.1.3 121.1.4

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

Ghi chú: Nếu CICAM muốn hủy bỏ việc nâng cấp firmware, nó có thể gửi cam_firmware_upgrade_complete APDU với yêu cầu không thiết lập lại. Hoạt động bình thường phải tiếp tục nếu máy chủ nhận được APDU này.

200

TCVN xxxx : 2016121.2 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".

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

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


FileReq() FileReqTag length_field()

RequestType

if (RequestType == 0)

for (i=0; i<(n-1); i++) FileNameByte

121.2.3

24

122

8

129

uimsbf

bslbf

129.1.1

201

Hp4530, 10/07/14,

pipe

TCVN xxxx :2016

if (RequestType == 1)

for (i=0; i<(n-1); i++) DataByte

123

124

8

125

126

127

128

8

bslbf

129.1.2

129.1.3

129.1.4

129.1.5

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.

129.1.6 FileAcknowledge

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


FileAck()

FileAckTag

length_field()

Reserved

FileOK

RequestType

if (RequestType == File)

FileNameLength

for (i=0; i<FileNameLength; i++)

FileNameByte

129.1.7

24

130

7

1

8

131

8

132

8

137

uimsbf

138

bslbf

bslbf

bslbf

139

uimsbf

140

bslbf

202

TCVN xxxx : 2016

FileDataLength

for (i=0; i<FileDataLength; i++)

FileDataByte

if (RequestType == Data)

for (i=0; i<(n-1); i++)

DataByte

133

32

134

8

135

136

8

141

uimsbf

142

143

bslbf

144

145

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

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

203

TCVN xxxx :2016CICAM 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 Huỷ 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 Huỷ bỏ bởi hệ thống– Hệ thống xoá miền ứng dụng để thực hiện nhiệm vụ khác.

0x03-0xff Dự phòng.

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

145.2.1 FileRequest v 2

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

204

Hp4530, 10/07/14,

hash

TCVN xxxx : 2016cầ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ú phá Ki p

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

145.2.2

24

146

8

147

148

8

149

150

8

151

128

152

153

154

155

156

8

157

uimsbf

157.1 .1

bslbf

157.1.2

157.1.3

bslbf

157.1.4

157.1.5

bslbf

157.1.6

bslbf

157.1.7

157.1.8

157.1.9

157.1.10

157.1.11

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 mục 14.4.4, Khôi phục loại yêu cầu v2.

Bảng 14.24 – Các giá trị RequestType

RequestType 157.1.12 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 0x02

205

TCVN xxxx :2016

bị hỏng.

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.

157.1.13 FileAcknowledge v 2

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

FileAck()

FileAckTag

length_field()

Reserved_zero

RequestOK

FileOK

RequestType

if (RequestType == File) || (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++)

157.1.14

24

158

6

1

1

8

159

160

8

161

8

162

32

163

8

169

uimsbf

170

bslbf

bslbf

bslbf

uimsbf

171

172

uimsbf

173

bslbf

174

uimsbf

175

bslbf

206

TCVN xxxx : 2016

DataByte

if (RequestType == ReqTypes) for (i=0; i<(n-1); i++)

ReqTypeByte

164

8

165

166

167

168

8

176

bslbf

177

178

179

180

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 FileHash 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ệukhô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ữ

207

TCVN xxxx :2016

RequestType

Request FileOK=0 FileOK=1

liệu có thể được gộp vào trong bản tin xác nhận.

0x02 FileHash Khi RequestOK=1các nội dụng file chưa thay đổi và phù hợp với f i le ha s h .

Khi RequestOK=0yê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 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.

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

208

TCVN xxxx : 2016Để 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.

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

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

180.2.2 Các APDU của kiểm soát máy chủ DVB phiên bản 2

180.2.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.28 - Cú pháp tune_broadcast_req APDU


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

180.2.3

24

181

7

1

16

4

12

182

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

209

TCVN xxxx :2016pmt_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_id: 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.33 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.

182.1.1.1 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 mục 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.29 - Cú pháp tune_reply APDU


tune_reply () 182.1.2

24

183

uimsbftune_reply_tag

length_field() 183.1.3 183.1.4

status_field 8 uimsbf

status_field : trường 8-bit này xác định trạng thái dò kênh theo Bảng 14.30.

Bảng 14.30 - Các giá trị trạng thái tune_reply


Trạng thái OK –Dò kênh thành công (Xem ghi 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 khoá 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 ghi chú2) 0x04

Lỗi –Không tìm thấy dịch vụ 0x05

Lỗi –Không xác định 0x06

210

TCVN xxxx : 2016


Ghi 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ảngTable 14.28

183.1.6.1 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 qui định tại mục 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.

183.1.6.2 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.31 - Cú pháp Tune Release Reply APDU


ask_release_reply() 183.1.7

24

183.1.8

uimsbfask_release_query_tag

length_field() 183.1.11 183.1.12

release_reply 8 uimsbf

release_reply : trường 8-bit này chỉ ra trạng thái dò kênh theo Bảng 14.32

Bảng 14.32 - 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


183.1.15 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ị head-end, thường là thông qua tài nguyên truyền tốc độ thấp.

211

TCVN xxxx :2016Ngườ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.

183.1.16 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 EITpf 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.33 – 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 ghi chú

satellite_delivery_ system_descriptor 0x43

S2_satellite_delivery_system_descriptor

0x79

cable_delivery_ system_descriptor 0x44

C2_delivery_system_descriptor 0x7F, 0x0D Xem ghi chú

service_descriptor 0x48 Thông tin tuỳ 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

Ghi chú: T2_delivery_system_descriptorvà C2_delivery_system_descriptor là các bộ mô tả DVB mở rộng, xem

212

TCVN xxxx : 2016

Descriptor Giá trị thẻ DVB Diễn giải

EN 300 468 [10],mục6.2.16 và mục 6.3.

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

(1) Bắt đầu

(2) Các thôngsố có OK ?

(5) Dò kênhcó thành công?

(6) PMT cótrong yêu cầu

dò kênh ?

Có

(14) Có PMT không ?

Dò kênh thành công

(3) Hệ thốngcung cấp cóđược hỗ trợ ?

Nhận được tune_broadcast_req()

(10) Máy chủ gửi tune_reply() với Error 04(các thông số thiếu hoặc không phù hợp) Dò kênh không thành công

(11) Máy chủ gửi tune_reply() với Error 01(hệ thống cung cấp không hỗ trợ) Dò kênh không thành công(4) Máy chủ dò kênh qua

dòng truyền tải được mô tả

(12) Máy chủ gửi tune_reply() với Error 02(bộ dò kênh không khóa) Dò kênh không thành công

(13) Máy chủ lấy PMT từ dòngtruyền tải được dò kênh

(15) Máy chủ gửi tune_reply() với Error 05(dịch vụ không tìm thấy)

Dò kênh không thành công

(7) Máy chủ gửi tune_reply() với trạng thái OK

(8) Máy chủ sử dụng PMT để chọn dòng thành phần

(9) Máy chủ gửi ca_pmt()

Có

Có

Có

Có

Không

Không

Không

Không

Không

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

213

TCVN xxxx :20162) 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)

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

214

TCVN xxxx : 2016

(7) Máy chủ thực hiện tươngtác của người sử dụng

(1) Phiên kiểm soát máy chủDVB được mở

(2) Máy chủ phát hiện tươngtác của người sử dụng

(3) Máy chủ gửiask_release()

(4) Máy chủ nhậnask_release_reply()

(2) CICAM xử lýyêu cầu giải phóng

(5) Giải phóng cóđược chấp nhận ?

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

Có

Không

Hình 14.11 - Quá trình dò kênh với kiểm soát máy chủ phiên bản 2

215

TCVN xxxx :2016190.2 Hồ sơ nhà điều hành

190.2.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ừ head-end đế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ụ.

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

216

TCVN xxxx : 2016Hình 14.12 chỉ ra hoạt động của tài nguyên hồ sơ nhà điều hành khi chạy trong một chế độ cung cấp CICAM NIT.

CICAM Máy chủ

Lưu trữliên tục operator_stat- us_req()

CAS/thẻ

thôngminh

NIT đượcxây dựng

Danhsáchkênh

CICAMNIT

Các phầnriêng

… cácbảng khác

SDT NIT SDTNIT / BAT

GiảimãA/V

Giải ghép kênh

Bộ giải xáo trộn mạng/ bộ xáo trộn CI Plus

Kiểm soát ngăn chặn máy chủTS vào TS hoặc TS được CI Plus xáo trộn

CICAMNIT

Giải ghép kênh

Bộ giải xáo trộn CI Plus

Phần mềm truyền hình kỹthuật số của máy chủ

Lựa chọnCICAM NIT hoặc NIT lưu trữ

operator_status() operator_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ì

217

TCVN xxxx :2016CICAM 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 EITsch

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

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

Lựa chọn mạng

Mạng CICAM 1

Mạng CICAM 2

Mạng cáp khác

Truyền hình số mặt đất

Truyền hình tương tự

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ủ phai 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 chứng 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ữ.

218

Hp4530, 10/21/14,

barker

TCVN xxxx : 2016Thô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.

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

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

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

190.2.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ê được giữ lại cho đến khi người sử dụng xóa nó hoặc bất kỳ cặp chứng 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.

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

219

TCVN xxxx :2016

operator_status (1)

operator_info_req(2) operator_info(3)

operator_search_start(4) operator_tune (5) operator_tune_status(6) operator_tune(5) operator_tune_status(6) operator_search_status (7)

operator_nit_req(8) operator_nit (9)

Khi khởi tạo, CICAM gửi trạng thái hồsơ hiện tại được CICAM sử dụng

CICAM trả về thông tin hồ sơ nàycho máy chủ

CICAM thực hiện tìm kiểm hồ sơ này. Khi việc tìm kiếm hoàn thành, hồ sơ NIT được cập nhật. CICAM phải tiếp tụcthông báo cho người sử dụng quá trìnhnày bằng cách sử dụng MMI ứng dụnghoặc MMI cấp cao của CICAM khi máychú trong chế độ tương tác

CICAM trả về CICAM NIT mới nhấtkhi máy chủ yêu cầu

Không được yêu cầu máy chủ xử lý ngayoperator_status. Máy chủ phải xác định xem hồ sơnày đã được cài đặt hay là hồ sơ mới cần xử lý.

Máy chủ yêu cầu thông tin gần tĩnh của mạng bằngcách sử dụng operator_info_req() APDU. Điều nàyhợp lệ đối với các hồ sơ loại 0 và 1

Máy chủ khởi tạo việc tìm kiếm nếu trạng thái hồsơ chưa được khởi tạo và trong trạng thái lỗi

CICAM đã hoàn thành việc tìm kiếm khioperator_search_status APDU được trả về

Máy chủ yêu cầu CICAM NIT và xây dựng danhsách kênh bằng cách sử dụng thông tin của bảngnày đối với loại = 1

Nếu quá trình này thành công thì hồ sơ nhà điềuhành dịch vụ được cài đặt làm một danh sách kênhlô gisc riêng sandbox với nhãn văn bản đượcqui định trong operator status APDU

CICAM Máy chủ

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ồ

220

TCVN xxxx : 2016sơ 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.

190.2.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 chứng 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 chứng thực kiểm soát nội dung.

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

221

TCVN xxxx :2016

operator_status (1)

operator_status_req(2) operator_status (3)

operator_exit(4)

operator_status_req(5) operator_status (6)

Khi khởi tạo, operator_status() APDUđược gửi

CICAM Máy chủ

Hồ sơ nhà điều hành được kích hoặckhi nhận operator_status_req()

CICAM nhận biết rằng không phải tấtcả các dòng truyền tải truyền qua CICAM thuộc về môi trường nhà điềuhành này

Hồ sơ nhà điều hành được kích hoặckhi nhận operator_status_req()

Máy chủ chuyển đến môitrường hồ sơ nhà điều hành

Máy chủ thông báo cho ngườisử dụng về thay đổi quyền

Máy chủ thông báo choCICAM rằng nó đã rời khỏimôi trường nhà điều hànhnày

Máy chủ thông báo choCICAM rằng nó đã vào môitrường nhà điều hành này

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.

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

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

222

TCVN xxxx : 2016

operator_status (1)


operator_entitlement_ack(4) operator_status(5)

CICAM Máy chủ

Máy chủ thông báo cho ngườisử dụng về thay đổi quyền

Máy chủ yêu cầu CICAM NIT và cập nhật danh sách kênh

Máy chủ thông báo choCICAM rằng việc thayđổiquyền đã được xử lý và danhsách kênh đã được cập nhật

CICAM phát hiện việc thay đổiquyền và đánh giá lại CICAM NIT nếu cần và tiếp theo thông báo sựthay đổi nàycho máy chủCICAM gửi phiên bản mới nhất củaNIT đến máy chủ khi được yêu cầu

CICAM xóa cờ thay đổi quyền khimáy chủ đã xác nhận

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.

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

223

TCVN xxxx :2016

operator_status (1)

operator_search_start(2) operator_tune(3) operator_tune_status(4) operator_tune (3) operator_tune_status(4) operator_search_status (5)


operator_entitlement_ack(8) operator_status(9)

Máy chủ thông báo cho người sử dụng vềthay đổi quyền và xác nhận với người sửdụng rằng xử lý ngay việc thay đổi quyềnnàyMáy chủ dò kênh theo yêu cầu của CICAM

CICAM đã hoàn thành việc tìm kiếm khitrạng thái tìm kiếm được trả về. Cờ thay đổiquyền vẫn phải được thiết lập

Máy chủ yêu cầu CICAM NIT mới và cậpnhật danh sách kênh

Máy chủ xác nhận việc thay đổi quyền khidanh sách kênh đã đượccập nhật

CICAM phát hiện việc thay đổi quyềnvà đánh giá lại CICAM NIT nếu cầnvà tiếp theo thông báo sự thayđổinày cho máy chủCICAM thực hiện việc tìm kiếm hồ sơvà dò kênh. Khi việc tìm kiếm hoànthành thì hồ sơ NIT được cập nhật. CICAM phải duy trì sự thông báo chongười sử dụng về tiến độ bằng cáchsử dụng MMI ứng dụng hoặc cấp caotrong chế độ có máy chủ thamgia

CICAM trả về cho máy chủ CICAMNIT được lưu trữ

CICAM xóa cờ thay đổi quyền

CICAM Máy chủ

Hình 14.17 - Trình tự APDU thay đổi quyền tìm kiếm


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

224

TCVN xxxx : 20169. 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.

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

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

225

TCVN xxxx :2016

operator_status (1)

operator_search_start(2) operator_tune (3) operator_tune_status(4) operator_tune (3) operator_tune_status(4) operator_search_status (5)

operator_nit_req (6)operator_nit (7)

Máy chủ có thể bắt đầu việc tìm kiếm hồ sơdựa vào CICAM operator_status() refresh_request_flag được yêu cầu hoặckhông được yêu cầuMáy chủ dò kênh theo yêu cầu của CICAM

CICAM đã hoàn thành việc tìm kiếm khitrạng thái tìm kiếm được trả về. Cờ thay đổiquyền có thể được thiết lập khi quyền đãthay đổi. Cờ yêu cầu làm mới phải đượccập nhậtMáy chủ yêu cầu CICAM NIT mới nếu phiênbản này thay đổi dẫn đến việc cập nhậtdanh sách kênh khi có thayđổi NIT

CICAM có thể tùy chọn yêu cầu hoạt độngdò kênh bằng cách thiết lậprefresh_request_flag() và gửioperator_status() APDU đến máy chủ

CICAM nhận được yêu cầu tìm kiếm hồ sơvà có thể dò kênh. Khi việc tìm kiếm hoànthành thì NIT được tùy chọn cập nhật vàyêu cầu làm mới bị xóa. CICAM phải duy trìsự thông báo cho người sử dụng về tiến độtìm kiếm trong chế độ có máy chủ tham giabằng cách sử dụng MMI ứng dụng hoặccấp caoCICAM gửi CICAM NIT mới nhất đến máychủ

CICAM Máy chủ

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


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.

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

226

TCVN xxxx : 2016Việ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.

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

190.2.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 để

227

TCVN xxxx :2016có đượ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ợ.

190.2.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.34 – Các APDU hồ sơ nhà điều hành

APDU hồ sơ nhà điều hành

Chiều Mô tả

operator_status_req HOSTCICAM

Nhập vào hồ sơ p r o f ile và/ hoặc yêu cầu thông tin hồ sơ hiện thời.

operator_status CICAMHOST

Thông tin trạng thái hồ sơ hiện thời.

operator_nit_req HOSTCICAM

Yêu cầu các phần CICAM NIThiện thời.

operator_nit CICAMHOST

Các phần CICAM NIThiện thời.

operator_info_req HOSTCICAM

Yêu cầu thông tin nhà khai thác.

operator_info CICAMHOST

Thông tin nhà khai thác.

operator_search_start HOSTCICAM

Máy chủ cho phép khởi đầu việc tìm mạng.

operator_search_status CICAMHOST

CICAM thông báo rằng việc tìm mạng đã hoàn thành.

operator_exit HOSTCICAM

Máy chủ đã để lại hồ sơ nhà khai thác dịch vụ.

operator_tune CICAMHOST

Yêu cầu chỉnh kênh tới một vị trí ghép cụ thể.

operator_tune_status HOSTCICAM

Yêu cầu dò kênh của máy chủ đã hoàn thành.

operator_entitlement_ack HOSTCICAM

Xác nhận rằng việc thay đổi quyền đã được thực thi.

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

228

TCVN xxxx : 2016Bảng 14.35 - Cú pháp operator_status_req APDU


operator_status_req()

operator_statu s _re q _tag

length_field()

190.2.6

24

191

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.

191.1.1.1 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.36 - Cú pháp operator_status APDU

Cú pháp

192

Số bit Kiểu

operator_status()

operator_status_tag

length_field()

operator_status_body()

192.1.1

24

193

uimsbf

Trong đó operator_status_body () được xác định theo quy định tại Bảng 14.37

Bảng 14.37 - Cú pháp operator_status_body


operator_status_body() 193.1.1

3

194

uimsbfinfo_version

nit_version 5 uimsbf

profile_type 2 uimsbf

initialised_flag 1 bslbf

entitlement_change_flag 1 bslbf

entitlement_valid_flag 1 bslbf

reserved 1 bslbf

refresh_request_flag 2 uimsbf

229

TCVN xxxx :2016

error_flag 4 uimsbf

delivery_system_hint 4 bslbf

refresh_request_date 16 uimsbf

refresh_request_time 8 uimsbf


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.38 – Các giá trị profile_type

Giá trị Mô tả

0 CICAMkhô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 DVB C I

1 Hồ sơ là một mạng cá nhân sử dụng một C I C A MNIT 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á trị "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.39 – 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

230

TCVN xxxx : 2016

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

194.1.6

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.

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

Bảng 14.40 – 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-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.41.

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

Giá trị Mô tả

0 Không xác định và bắt buộc phải thẩm vấn rõ ràng.

1 Đây mà một mạng cáp và có thể là DVB-C và/ hoặc DVB-C2

2 Đây là một mạng vệ tinh và có thể là DVB-S và/ hoặc DVB -S2

3 Đây là một mạng mặt đất và có thể là DVB-Tvà/ hoặc DVB-T2

4-15 Dự phòng.

231

TCVN xxxx :2016refresh_request_date: trường 16-bit này chỉ ra ngày của chu kỳ làm mới theo lịch tiếp theo được CICAM yêu cầu. Ngày được quy định theo MJD trong EN 300 468 [10], Phụ lục C. Giá trị 0x0000 chỉ ra rằng không yêu cầu làm mới theo lịch.

refresh_request_time: trường 8-bit này chỉ ra thời gian của chu kỳ làm mới theo lịch tiếp theo được CICAM yêu cầu. Thời gian được quy định theo UTC là một giá trị số nguyên với mỗi bước thời gian là 6 phút tính từ nửa đêm và có giá trị trong phạm vi từ 0 đến 239. Trường này chỉ được phân tích khi refresh_request_date khác không. Khi refresh_request_flag là số không thì trường này cũng phải là số không.

Ví dụ: 0 00:00 – nửa đêm

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

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

194.1.6.1 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.42 - Cú pháp operator_nit_req APDU


operator_nit_req()

operato r _ni t _re q _tag

length_field()

194.1.7

24

195

uimsbf


operator_nit_req_tag: Xem bảng L.1 tại Phụ lục L.

195.1.1.1 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.43 - Cú pháp operator_nit APDU


operator_nit ()

operato r _ni t _tag

length_field()

nit_loop_length

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

nit_section_byte

195.1.2

24

196

197

16

198

8

199

uimsbf

uimsbf

uimsbf

232

TCVN xxxx : 2016


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

199.1.3.1 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


233

TCVN xxxx :2016

operator_info_req()

operato r _inf o _re q _tag

length_field()

199.1.4

24

200

uimsbf


operator_info_req_tag: Xem bảng L.1 tại Phụ lục L.

200.1.1.1 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


operator_info ()

operato r _info_tag

length_field()

reserved

info_version

original_network_id

operator_id reserved

character_code_table

if (character_code_table == 0x1f)

encoding_type_id

else if (character_code_table == 0x10)

second_byte_value

third_byte_value

sdt_running_status_trusted

eit_running_status_trusted eit_present_following_usage

eit_schedule_usage

extended_event_usage

sdt_other_trusted

200.1.2

24

201

5

3

16

16

16

8

202

8

203

8

8

1

204

1

2

3

1

1

205

uimsbf

206

bslbf

uimsbf

uimsbf

uimsbf

bslbf

uimsbf

207

uimsbf

208

uimsbf

uimsbf

uimsbf

209

uimsbf

uimsbf

uimsbf

bslbf

bslbf

234

TCVN xxxx : 2016

eit _ event_trigger

reserved

ISO_639_language_code profil e _name_length

for (i=0; i< profile_name_length ; i++)

profile_name_byte;

1

6

24

8

8

bslbf

bslbf

bslbf

uimsbf

uimsbf


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

original_network_id: trường 16-bit này xác định original_network_id của nhà điều hành dịch vụ truyền hình trong mạng. Trường này có thể khác với operator_id được thông báo trong APDU này do sự phát triển lịch sử của mạng.

operator_id: trường 16-bit này xác định rõ ràng danh tính original_network_id của nhà điều hành dịch vụ. 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.

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àyvà/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ã hoá 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".

235

TCVN xxxx :2016eit_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.46. Hoạt động máy chủ mặc định thu được từ bộ ghép kênh nội bộ (1).

Bảng 14.46 – 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 EITtrên mạng. Bảng EITkhô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 đầy 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 EITtrê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.47. 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.47 – 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 EITtrên mạng. Bảng EITkhô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 đầy 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 l in k a g e _ t y p e 0x02(EPGService)trong vòng đầu tiên của NI T .

4 Thông tinElectronicProgrammeGuideinformationđược phân phối sử dụng một ứng dụng.

5-7 Dự phòng.

236

Hp4530, 10/24/14,

Barker

TCVN xxxx : 2016extended_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.48.

Bảng 14.48 – 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 e x t e n d e d_ e v e n t_ d escriptor 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. s h o rt_e v e n t _d escriptor đượ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 actual chỉ 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 EITp/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.

209.1.1.1 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

237

TCVN xxxx :2016tì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.49 - Cú pháp operator_search_start APDU


operator_search_start()

operator_searc h _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;

209.1.2

24

210

1

7

211

8

212

8

213

8

214

8

215

8

216

uimsbf

216.1.1

bslbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

operator_search_start_tag: Xem bảng L.1 tại Phụ lục L.

unattended_flag: trường 1-bit này xác định xem máy chủ có đang hoạt động trong chế độ không tham gia (tức là không có mặt người sử dụng). Giá trị "1" chỉ ra rằng không có mặt người sử dụng và máy chủ là không thể sử dụng bất kỳ các yêu cầu tương tác. Khi máy chủ là không tham gia thì CICAM phải tránh sử dụng MMI cấp cao hoặc ứng dụng vì chúng có thể không được sử dụng. Giá trị "0" chỉ ra rằng người sử dụng có mặt và màn hình tương tác có thể được CICAM sử dụng.

service_type_loop_length: trường 7-bit này xác định số byte tiếp theo ngay sau trường này xác định danh sách service_type của máy chủ có thể sẵn có.

service_type: trường 8-bit này quy định loại dịch vụ mà máy chủ có thể sẵn có. Các giá trị loại dịch vụ được xác định bởi trường service_type trong service_descriptor được mô tả trong EN 300 468 [10].

Ví dụ: 0x0102 Các dịch vụ truyền hình MPEG-2 (0x01) và phát thanh Layer-II (0x02), MPEG-1 được hỗ trợ.

238

TCVN xxxx : 2016

216.1.7 0x01020c Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-II (0x02), MPEG-1 và dữ liệu được trường application_capability_byte (0x0c) xác định được hỗ trợ.

216.1.8 0x0102030a16 Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-II (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ợ

216.1.9 0x0102030a101619 Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-II (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.

216.1.10 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ủ chi 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

216.1.11 0x0106 Máy chủ hỗ trợ truyền hình hồ sơ MHEG-5

216.1.12 0x01230107 Hỗ trợ máy chủ truyền hình HbbTV và Open TV

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

Bảng 14.50 - Cú pháp operator_profile APDU

239

TCVN xxxx :2016


operator_search_status()

operator_search_status _ tag

length_field()

operator_status_body()

216.1.13

24

217

uimsbf


operator_search_status_tag: Xem bảng L.1 tại Phụ lục L.

operator_status_body (): Xem Bảng 11.37 trong phần 14.7.5.3.

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

// Initialise

tuner_information = not found; desc_num = 0;

// Loop over all of the descriptors in the APDU while (descriptor[desc_num] is present in descriptor loop)

current_location_info = descriptor [desc_num]; desc_num++; while (descriptor [desc_num] present and additionally describes the current_location) current_location_info += descriptor [desc_num]; desc_num++;

// Check the tuning parameters quit if these descriptors are not supported and

// the CICAM may then re-build the list excluding this delivery location.

if (current_location_info has bad parameters OR is invalid OR is not supported)

current_location_info = descriptor information + error codes.

240

TCVN xxxx : 2016break;

// All of the descriptors that identify this tuning location have been found.

// Initiate a tune. tune_status = tune (current_location_info);

// If a data carrier is found then save the tuner information and quit loop.

if (tune_status == signal present AND signal viable AND is a data carrier) tuner_information = current tuner location information; break;

// If nothing has been found we have reached the end of the loop

if (tuner_information == not found) desc_num = 0xff;

// Stay at the tuned location and send the tune status back to the CICAM.

send APDU operator_tune_status (desc_num, tuner_information)

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.51 - Cú pháp operator_tune APDU


operator_tune ()

operator_tune_ tag

length_field()

reserved

descriptor_loop_length

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

descriptor()

217.1.2

24

218

4

12

219

8

220

uimsbf

220.1.1

bslbf

uimsbf

uimsbf


operator_tune_tag: Xem bảng L.1 tại Phụ lục L.

length_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

241

TCVN xxxx :2016đị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.

220.1.2.1 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.52 - Cú pháp operator_tune_status APDU


operator_tune_status()

operator_tune_statu s _tag

length_field()

descriptor_number

signal_strength

signal_quality

status

descriptor_loop_length

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

descriptor()

24

221

8

8

8

4

12

222

8

223

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf


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.53 – 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ị khoá 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 de s c rip t or_n u m b er phải là số chưa được xử lý tiếp theo.

Trường s ig n al _ s tre n gth phải khác không.

Trường s ig n al _ quality phải khác không.

Trường de s c rip t or s () 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ủ.

242

TCVN xxxx : 2016

Giá trị Mô tả

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 de s c rip t or_l o op 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 de s c rip t or_l o op 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ằng0xff vì danh sách bộ mô tả đã được dò hết.



Trường d e s c rip t or_l o op _ le n gth 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ả.

243

TCVN xxxx :2016223.1.2.1 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.54 - Cú pháp operator_entitlement_ack APDU


operator_entitlement_ack()

operator_entitlement_ac k _tag

length_field()

223.1.3

24

224

uimsbf


operator_entitlement_ack_tag: Xem bảng L.1 tại Phụ lục L.

224.1.1.1 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 = 1và đ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.55 - Cú pháp operator_exit APDU


operator_exit()

operator_exit_tag

length_field()

224.1.2

24

225

uimsbf


operator_exit_tag: Xem bảng L.1 tại Phụ lục L.

244

TCVN xxxx : 2016

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 A.1 - 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 chứng 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], mục 4.6.

Chú ý: Giá trị nhân duy nhất được tạo ra là prng_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:

245

TCVN xxxx :2016

DT i

AES-128

AES-128

AES-128

I i I i

R iS i

R i S i+1

kk

k

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ư vector 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:

Eq.A.1

Eq.A.2

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.

246

TCVN xxxx : 2016

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ừ Bản quy định kỹ thật cấp giấy phép CI Plus [33].

247

TCVN xxxx :2016Phụ lục C

(quy định)

Các thuật toán kiểm tra tổng dành cho các ID thiết bị và ARC

C.1 Thuật toán kiểm tra tổng dành cho các ID thiết bị

Khả năng bị lỗi trong giao tiếp của con người theo một nghiên cứu thực nghiệm của Verhoef: 1969 được trình bày trong Bảng C.1.

Bảng C.1 - Khả năng bị lỗi trong giao tiếp của con người

TT

LTo Thon ngư Xhon uất %

1 Thay thế đơn. a => b 60 to 95

2 Biến đổi đơn kề ab => ba 10 to 20

3 Các lỗi kép aa => bb 0,5 to 1,5

4 Thay đổi bước nhảy (bước nhảy xa còn hiếm hơn) acb => bca 0,5 to 1,5

5 Lỗi ngữ âm (ngữ âm, bởi vì trong một số ngôn ngữ hai có cách phát âm tương tự, ví dụ, ba mươi và mười ba)

a0 => 1a

trong đó a=2,..,9

0,5 to 1,5

6 Thêm hoặc bỏ sót chữ số. 225.1.2 10 to 20

Ghi chú: a và b là các chữ số thập phân khác nhau, trong khi c có thể là bất kỳ chữ số thập phân nào.

Các lỗi phổ biến nhất là 1, 2 và 6. Lỗi 6 có thể dễ dàng phát hiện, các mục sau đây xác định một phương pháp để phát hiện các lỗi khác.

A.1.1 Định nghĩa kiểm tra tổng ID thiết bị

Kiểm tra tổng ID thiết bị phải được tính theo cách sau.

Sử dụng các mã trên Zp, các số nguyên modulo p, trong đó p = 11. Từ mã là những chuỗi với các đầu vào từ 0, 1, …. p-1. xem xét các mã có độ dài n được xác định bởi phương trình chẵn lẻ r: một chuỗi c 1,c 2..., cn với các phần từ từ Zp là một từ mã khi và chỉ khi thỏa mãn các phương trình sau đây.

Eq.C.1

Chúng ta mô tả một mã [23,20], được xác định trên 23 biểu tượng từ Z11 sử dụng ba phương trình kiểm tra được quy định trong ma trận H3 dưới đây:

Lấy n = 20, r = 3 và p = 11 Chúng ta xem xét mã này được định nghĩa bởi phương trình kiểm tra r = 3 sau.

Eq.C.2

Eq.C.3

Eq.C.4

Nói cách khác, một chuỗi ( c 1 , c 2 ,..., c 23) với các phần tử từ Z11 là một từ mã khi và chỉ khi nó có tích bên trong không (modulo 11) với các hàng của ma trận H3, xem Bảng C.2.

248

TCVN xxxx : 2016Bảng C.2 – Ma trận H3

n1

n2 n3 n4 n5 n6 n7 n8 n9 n10 n11 n12 n13 n14 n15 n16 n17 n18 n19 n20 n21 n22 n23

225.1.3

H3

1 0 1 0 1 0 1 0 1 0 1 2 3 4 5 7 8 9 10 0 1 0 0

0 1 0 1 0 1 0 1 0 1 0 1 2 3 4 6 7 8 9 1 0 1 0

10

1 9 2 8 3 7 4 6 5 4 5 7 10 3 2 8 4 1 7 0 0 1

Phát hiện lỗi xảy ra bằng cách kiểm tra khi từ nhận được r = (r1, r2,..., r23) có thỏa mãn ba phương trình kiểm tra chẵn lẻ.

Việc mã hóa có thể được thực hiện như sau: chọn c1, c2,..., c20 theo một cách bất kỳ. Nếu chúng ta định nghĩa

Eq.C.5

Eq.C.6

Eq.C.7

thì (c1, c2,..., c23) là một từ mã. Chúng ta có thể xem c21, c22 và c23 là những số kiểm tra chẵn lẻ.

Chú ý: Chúng ta có thể hạn chế c1, c2,..., c20 là bất kỳ những con số 0, 1, 2..., 9. Một số bất kỳ trong 3 số kiểm tra chẵn lẻ có thể là '10'. '10' có thể được đại diện bởi một ký tự khác 0, 1,..., 9, ví dụ như X hoặc Z.

Để phát hiện lỗi, chúng ta tính 3 tổng có trọng số của các số nhận được như được quy định thông qua ma trận H3, hay tương đương, trong phương trình C2, C3 và C4. Nếu một hoặc nhiều tổng này là không, một lỗi được phát hiện

Eq.C.8

Eq.C.9

Eq.C.10

Các mã được định nghĩa với H3 phát hiện tất cả các lỗi của bất kỳ các loại sau.

Các lỗi thay thế đơn và kép.

Các lỗi chuyển vị đơn và kép.

Kết hợp bất kỳ của một lỗi thay thế đơn và một lỗi chuyển vị đơn.

Tất cả ba lỗi thay thế liên tiếp.

Trường hợp chuyển vị là ab => ba và thay thế là a => b.

Ví dụ sau đây, hình C.2, minh họa việc sử dụng thuật toán này đối với ID thiết bị hợp lệ là số đầu vào.

249

TCVN xxxx :2016

Lựa chọn một số (0 ..9)

C21 & S21C22 & S22C23 & S23

109

000

checkdigit = -sum(n1..n20) mod 11

checkdigit = +sum(n1..n21 or n22 or n23) mod 11

C21C22C23

S21S22S23

Giải mã

Từ mã

Mã hóa

Ma trận H3

Số đầu vàoVị trí (n)

8 5 6 2 8 7 0 1 2 1 5 3 2 9 6 6 7 8 8 3 1 0 9

Ghi chú: Giá trị số kiểm tra tổng C22 bằng “10” có thể được trình bày bằng một ký tứ khác các số từ 0 đến 9, ví dụ là X hoặc Z.

Hình C.2 - Ví dụ tính toán kiểm tra tổng của ID thiết bị

A.1 Kiểm tra tổng ARC

A.1.1 Định nghĩa kiểm tra tổng ARC

Kiểm tra tổng ARC được tính như sau.

Lấy n = 12, r = 2 và p = 11 Chúng ta xem xét mã được định nghĩa bởi phương trình kiểm tra r = 2 sau đây.

Eq.C.11

Eq.C.12

Nói cách khác, một chuỗi ( c 1 , c 2 ,..., c 12) với các phần từ từ Z11 là một từ mã khi và chỉ khi nó có tích bên trong là không (modulo 11) với cả hai hàng của ma trận H1 sau, hãy xem Bảng C.3:

Bảng C.3 - Ma trận H1

n1 n2 n3 n4 n5 n6 n7 n8 n9 n10 n11 n12

H1

8 8 6 5 10 5 6 4 1 4 1 0

3 6 4 2 6 8 2 1 2 4 0 1

Việc phát hiện lỗi xảy ra bằng cách kiểm tra nếu từ nhận được r = (r1, r2,..., r12) có thỏa mãn hai phương trình kiểm tra chẵn lẻ.

Ví dụ, việc mã hóa có thể được thực hiện như sau: chọn c1, c2,..., c10 theo cách bất kỳ. Nếu chúng ta định nghĩa

Eq.C.13

Eq.C.14

250

TCVN xxxx : 2016thì (c1, c2,..., c12) là một từ mã. Chúng ta có thể xem C11 và c12 là những số kiểm tra chẵn lẻ.

Chú ý: Chúng ta có thể hạn chế c1, c2,..., c10 là một số bất kỳ của những con số 0, 1, 2..., 9. Một số bất kỳ của những số kiểm tra chẵn lẻ có thể '10'. '10' có thể được đại diện bởi một ký tự khác 0, 1,..., 9, ví dụ như X hoặc Z.

Việc giải mã được thực hiện bởi:

Eq.C.15

Eq.C.16

Từ đây, chúng ta có thể rút ra những kết luận sau đây:

Tất cả các lỗi thay thế đơn và kép được phát hiện.

Tất cả các lỗi chuyển vị đơn và kép được phát hiện.

Kết hợp bất kỳ của một lỗi thay thế ở vị trí 12, và một lỗi chuyển vị ở các vị trí không liên quan đến vị trí 12 được phát hiện.

Một lỗi thay thế không ở vị trí 12 "khớp" chính xác một lỗi chuyển vị. Tỷ lệ không được phát hiện khoảng 1%.

Trường hợp chuyển vị là ab => ba và thay thế là a => b.

Ví dụ sau đây, Hình C.3, minh họa việc sử dụng thuật toán này đối với một ARC hợp lệ là số đầu vào.

Vị trí (n)

Số đầu vào

Ma trận H1

Mã hóa

C11C12

Từ mã

Giải mã

Lựa chọn mộtsố (0 ..9)

C11 & S11C12 & S12

checkdigit = -sum(n1..n10) mod 11

checkdigit = +sum(n1..n11 or n12) mod 11

99

00

S11S12

Hình C.3 - Ví dụ tính ARC

251

TCVN xxxx :2016

Phụ lục A

(quy định)

Các khả năng SD và HD

A.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ềng 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.

252

TCVN xxxx : 2016Phụ lục B

(quy định)

Kiểm tra các trường hợp sử dụng DVB-CI

B.1 Khởi tạo

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

Tiêu chuẩn PCMCIA định nghĩa trong tập 2, mục 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).

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

B.2 CA_PMT rõ ràng


Bản quy định kỹ thuật DVB-CI xác định trong "Hướng dẫn thực hiện và sử dụng giao diện chung dành cho các ứng dụng bộ giải mã DVB (R206-001: 1998)" [24] rằng máy chủ phải gửi đối tượng ca_pmt ngay cả khi chương trình được lựa chọn là rõ ràng. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

CA_PMT được máy chủ gửi ngay cả khi chương trình rõ ràng được người sử dụng lựa chọn (thường là một chương trình không có CA_descriptor trong PMT). Trong trường hợp này, máy chủ phải gửi CA_PMT mà không có bất kỳ CA_descriptor (ví dụ: CA_PMT với program_info_length == 0 và ES_info_length == 0).

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

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


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]; mục 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:

253

TCVN xxxx :20161. Sự thay đổi này không được thông báo trong PMT, nhưng lại có trong trường TSC của phần mào đầu gói tin hoặc trong trường PES_SC của phần mào đầu PES. Trong trường hợp này, máy chủ không gửi một CA_PMT mới. Ứng dụng CA phải phát hiện ra sự chuyển đổi đó.

2. Thay đổi này dẫn đến sự thay đổi của PMT (ví dụ: các CA_descriptor bị loại bỏ). Trong trường hợp này, một CA_PMT được máy chủ gửi.

Chú ý: Trong cả hai trường hợp, ứng dụng CA nên tạo ra một tương tác với người sử dụng để thông báo cho người sử dụng.

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

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


R206-001 [24] (mục 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 đó.


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.

B.5 MMI tức thời


R206-001 [24] (mục 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 đó.

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

254

TCVN xxxx : 2016B.6 Dòng truyền tải đến CICAM


Bản quy định kỹ thuật DVB-CI trong EN 50221 [7] (mục 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.

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

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


Bản quy định kỹ thuật DVB-CI trong EN 50221 [7] (mục 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.


Trả lời đối với đối tượng yêu cầu hồ sơ.

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

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

255

TCVN xxxx :2016B.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.

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

EN 50221 [7] mục 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 10305 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.

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


Tài nguyên kiểm soát máy chủ 00x200041 là bắt buộc đối với một máy chủ CI 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 mục 14.3 và các ứng dụng loại Video on Demand.


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

B.11 Trả lời CA-PMT


Bản quy định kỹ thuật DVB-CI định nghĩa trong EN 50221 [7] (mục 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).


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

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


Tài nguyên CC trong CI 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 mục 5.7, các phần mở rộng trong DVB TS 101 699 [8], mục 6.6, cung cấp tài

256

TCVN xxxx : 2016nguyê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.


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

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

B.13.1 Giao diện dữ liệu

EN 50221 [7] mục 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 mục 11.1.3 để biết thêm thông tin về các yêu cầu tốc độ dữ liệu CI Plus.

B.13.2 Giao diện lệnh

EN 50221 [7] mục 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.

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


Trong mục 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.


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.

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


Mục 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.


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

257

TCVN xxxx :2016B.16 Đối tượng dò kênh kiểm soát máy chủ DVB


Mục 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ả.


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.

Ghi 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

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


EN 50221 [7], mục 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], mục 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.

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

258

TCVN xxxx : 2016Má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.

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

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


En 50.221 [7], mục 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ó.

B.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 mục E.19.

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


En 50.221 [7], mục 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.

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

259

TCVN xxxx :2016củ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.


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.

B.20 Cung cấp CA PMT

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


EN 50221 [7], mục 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], mục 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

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

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


EN50221: 1997 [7], mục 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.

260

TCVN xxxx : 2016ITU-T J.96: 2001 [39], mục 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.

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

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


EN-50221: 1997 [7], mục 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], mục 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.


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


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

B.23 Các lệnh ca_pmt


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


CICAM phải hỗ trợ tất cả các giá trị ca_pmt_cmd_id được liệt kê trong EN 50221 [7], mục 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.

B.24 open_session_response


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.


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.

261

TCVN xxxx :2016B.25 Mã hóa ký tự


Tuân theo EN50221 [7], mục 8.6.2.3 và sửa đổi theo R206-001 [24], mục 9.8.5.


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

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

262

TCVN xxxx : 2016

Phụ lục C

(quy định)

Định nghĩa và xử lý mã lỗi

C.1 Các mã lỗi

Bảng F.1 – Các mã lỗi ARC

MRCác +

ĐRCác mã lỗi Thiác mã lỗi , ISO/IE

Mhiác mã lỗi iện Mhiác mã lỗi iệnSO/IEC

Diiác mã

00 Khiác Khiác mã lỗi

Khiác Khiác 228.1.2

01 M1iác mã lỗi iện CICAM KhCAM CICAM chuyển sang chế độ pass-through (Ghi chú 1)

228.1.3

02 M2Ghi chú 1)h iệnS CICAM 228.1.4 - CICAM chuyển sang chế độ pass-through (Ghi chú 1)

- Một bản tin thông báo thu hồi được hiển thị.

03 SAC khhiển thị.hồiO/ CICAM/Host

228.1.5 - Nếu EMI>0 CICAM chuyển sang chế độ pass-through, nếu không chuyển qua chế độ DVB CI.

- Một bản tin thông báo lỗi được hiển thị.

Cột bản tin thông báo lỗi được hiển thịtrợ. ặc định (theo ISO u kiện để giải xáo trộn khi hoạt động ở chế độ DVB CI.

04 CCK khn tin thông bá CICAM/Host

228.1.6 - Nếu EMI>0 CICAM chuyển sang chế độ pass-through, nếu không chuyển qua chế độ DVB CI.

- M nếu không chuyển qua

C nếu không chuyển qua chế độ DVB CI.hể chọn dựa

263

TCVN xxxx :2016

MRCác +



Diiác mã

chế độ DVB CI.hị.

vào những điều kiện để giải xáo trộn khi hoạt động ở chế độ DVB CI.

05 C5nếu không chuyển qua chế độ DVB CI.hể

- Bootloader

CICAM KhCAM Đề Nghị:

- CICAM thử lại tải về 2 lần.


06 C6t bản tin thông báo lỗkhông thành công

- L t bản ti

CICAM KhCAM Đề Nghị:



07 C7p nhbản tin thông báo lỗi được hiển th

- L nhbản tin thông báo lỗi

CICAM KhCAM Recommended:



08 Chứhg thbản tin thông báo lỗ- Retries Exhausted

CICAM KhCAM - CICAM chuyExhaustedhICAM chuyExhauste.

09 Chứhg thM chuyExhaustedc thM- KithM chuyExhaustedhithM chuyExhau

CICAM/Host

MICAM/Hostm dAM/HostAM.

- CICAM chuyểI sang chế độ pass-through.

10 Chứhg thang chế độ pass-thro- Kithang chế độ pass-throughược hiển thịgchọn

CICAM/Host


- CICAM chuyểICAM chuyếICAM

264

TCVN xxxx : 2016

MRCác +



Diiác mã

chuythrough.

11 Chứhg thughhuyng thghhuyôg t- T thghhuyó thghhuyh thghhu

CICAM/Host


- CICAM chuyểICAM chuyếICAM chuythrough.

12 Chứhg thughhuyng thghhuyôg t- DH khghhuyhH khghhu

CICAM/Host


- CICAM chuyểICAM chuyếICAM chuythrough.

13 Giấi choughhuyn CICAM khô CICAM kh

- C CICAM khi

Host MostCAM khm dtCAM khAM.

KhdtCA

14 Giấi chtCAM khn CICAM khô CICAM kh

- H CICAM

Host Mostchstchuyểhuyang chM kh DVB-CI. (Ghi chh 2)

Kh)ng 228.1.7

15 Giấi chứch nhậnhCICAM khCAM khhhlh

- KiCAM khhhóiCAM khhhôiCAM khhhciCA

Host Mostchstthstdhst CICAM.

KhICAM

16 Giấi chCAMkhhhn mCAMkhhhkhmCAMkhhhlh

- C mCAMkhhhi

CICAM KhCAM - CICAM chuyểICAM chuyếICAM chuythrough.

- M roughhuyn thughhuyo lhughhuy hihughhu.

17 Giấi chhughhuyn mhughhuykhmhughhuylh

- H mhugh

CICAM KhCAM - CICAM chuyểICAM chuyếICAMDVB-CI (Ghi ch pas


18 Giấi ch bản tin thông báo lỗi được h

- Kih bản tin thông báo lỗi được hiể

CICAM KhCAM - CICAM chuyn thông báo lỗi được hiển t.

265

TCVN xxxx :2016

MRCác +



Diiác mã

- M CAM chuyn thông báo lỗi được hiển thị.

19 Giấi chAM chuyn thông báo lỗi được hiểnnvalid

- C hAM chuyn

CICAM KhCAM - CICAM chuyn thông báo lỗi được hiểnnv DVB-CI (Ghi chng b

- MDVB-CI (Ghi chng báo lỗi được hiểnnval.

20 Giấi chB-CI (Ghi chng báo lỗi được hiểnnvalidh- H hB-CI

CICAM KhCAM - CICAM chuyhi chng báo lỗi được hiểnnv DVB-CI (Ghi chú 3)

- MDVB-CI (Ghi chú 3)áo lỗi được hiểnnvalidhọn dự.

21 Giấi chB-CI (Ghi chú 3)áo lỗi được hiểnnvalidh- KihB-CI (Ghi chú 3)áo lỗi được hiể

CICAM KhCAM - CICAM chuyhi chú 3)áo lỗi được hiểnnv DVB-CI (Ghi chú 3)

- MDVB-CI (Ghi chú 3)áo lỗi được hiểnnval.

22 CICAM y (Ghi chú 3)áo CICAM KhCAM - CICAM chuyhi chú 3)áo lỗi được hiểnnv

- MICAM chuyhi chú 3)áo lỗi được hiểnnval.

23 AM127

D27ph7ng for CI Plus CICAM KhCAM - M CAMả CAMn thMng bMo lbM lbM hibM thb.

128 M

255

S55d55g dà d riing cho nh Plusu hcho nh Plvụ

CICAM KhCAM - M CAMả CAMn thMng bMo lbM đưlbMhilbMthl.

266

TCVN xxxx : 2016

MRCác +



Diiác mã

Ghi 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ụ CI 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ộng các dịch vụ không yêu cầu được CI Plus bảo vệ (chế độ trở về DVB-CI)

267

TCVN xxxx :2016

Phụ lục A

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

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

A.2 Chế độ ngắt

CI 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 bit 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ủ CI Plus.

Một CAM tuân thủ CI 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 CI 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], mục 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

268

TCVN xxxx : 2016

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 CI 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], mục 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], mục 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], mục 4.3.3 để biết thêm thông tin về ngắt điều khiển hoạt động.

Mô-đun CI 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.

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

Một CI Plus CICAM (và tùy chọn bất kỳ CICAM khác mà không nhất thiết phải là CI Plus nhưng có thể hoạt động một cách chính xác trong một máy chủ CI Plus) phải thông báo khả năng tương thích CI Plus trong thông tin CIS. Một CICAM phải thông báo khả năng tương thích CI Plus trong bộ dữ liệu CISTPL_VERS_1. Trong TPLLV1_INFO, một CICAM tuân thủ CI Plus phải bao gồm một chuỗi thông báo khả năng tương thích CI 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> ::= "-"|"+"|"*"

<label> ::= <word>

<identity> ::= <word>

<word> ::= <char> <char>

<char> ::= "a"-"z"|"A"-"Z"|"0"-"9"|"."|"_"


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

269

Hp4530, 11/05/14,

tuple

TCVN xxxx :2016cuố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 CI 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 $CoMpAtIbLe[AcMe=+ThIs CIplus=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 CI 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ủ CI 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 CI Plus của nó trong thông tin CIS đối với CI Plus CICAM là bắt buộc.

Máy chủ CI Plus có thể tùy chọn xử lý thông tin khả năng tương thích CIS. Máy chủ CI 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 CI 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 CI Plus hoặc dừng sử dụng các CI Plus APDU cụ thể. Loại bỏ các CI 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 CI Plus. Việc thông báo các tài nguyên CI 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ủ CI Plus là bắt buộc.

270

TCVN xxxx : 2016A.3.1 Xác định CI Plus

Một CI Plus CICAM phải thông báo việc hỗ trợ CI 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 CI 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 CI Plus CICAM (hoặc một CICAM đã được kiểm tra với một máy chủ CI 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 CI 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.

A.3.2 Xác định tính năng CI Plus bổ sung

CICAM phải thông báo việc hỗ trợ các tính năng CI 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 CI 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 CI 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ạ bit Ghi chú

Tài nguyên hồ sơ nhà điều hành 0x00000001 Xem mục 14.7.4.1.4

Dự phòng 0x00000002 – 0x80000000

228.1.8

271

TCVN xxxx :2016Ví 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 CI Plus trừ khi CICAM đã hoàn toàn được kiểm tra với một máy chủ CI Plus. Việc chỉ ra khả năng tương thích CI Plus và các tính năng trong thông tin CIS đối với CI Plus CICAM là bắt buộc.

Máy chủ CI Plus có thể tùy chọn xử lý thông tin các tính năng CI 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.

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

272

TCVN xxxx : 2016

Phụ lục B

(quy định)

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

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

Mã kh APDU trong th

Kkh APDU trong

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 Ghi chran Giấy chứng nhận thương hiệu máy chủ 7

CICAM_BrandCert Ghi chBra

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

Diấy chứ - - 9

Diấy chứ - - 10

D0ấy chứ - - 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 Ghi chevC

Dữ liệu giấy chứng nhận thiết bị máy chủ 15

CICAM_DevCert Ghi chDev

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 chứng 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

273

TCVN xxxx :2016


Kkh APDU trong


AKH 256 Mã khóa chứng thực máy chủ 22

AKM 256 Mô đun mã khóa chứng 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 Note 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 (Ghi 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. (Ghi 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

Ghi chú:

1. Độ dài giấy chứng nhận 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.

274

TCVN xxxx : 2016


Kkh APDU trong


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.

275

TCVN xxxx :2016

Phụ lục C

(quy định)

Sử dụng PKCS # 1

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

276

TCVN xxxx : 2016Phụ lục D

(quy định)

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

D.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 chứng thực (xem mục 6). Một mục trong đóng dấu được xác định bởi cú pháp sau:

<tag> <length><signature_item>

<tag> - một trường 8 bit có một giá trị duy nhất (uimsbf) dành cho mục dữ liệu được quy định tại Bảng J.1. Thẻ được mã hoá là giá trị nhị phân. Các giá trị thẻ sau được xác định và phải được sử dụng.

Bảng J.1 - Định nghĩa thẻ và độ dài

Giá trị thẻ (8 bit) Tên thẻ Diễn giải Độ dài (16 bit)

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 chứng 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-0xFF 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= 216 -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

277

TCVN xxxx :2016

0000 1000 0000 0000

(tiếp theo là 2048 bit dữ liệu ngẫu nhiên)

278

TCVN xxxx : 2016Phụ lục E

(quy định)

Bản quy định kỹ thuật điện

E.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 CI Plus. Không có các yêu cầu kỹ thuật điện mới dành cho CI 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].

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

E.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 trước khi thay đổi

Chân Tín hiệu I/O Diễn giải 228.1.9 Chân Tín hiệu I/O Diễn giải

1 GND 228.1.10 ĐND 35 GND 228.1.12 228.1.13

2 D3 I/O Bit dgiải t 3 36 CD1# 228.1.15 Ph1#dgiải trư 1

3 D4 I/O Bit dgiải t 4 37 D11 I/O TrO dgiải trư




7 CE1# I Cho phiải tr 1 41 D15 I/O TrO phiải trư

8 A10 I Bit phiải t 10 42 CE2# I Cho phiải tr 2

9 OE# I Cho phiải trước 43 VS1# O Sen shiải trướ 1

10 A11 I Bit shiải t 11 44 RFU 228.1.24 228.1.25

11 A9 I Bit shiải t 9 45 RFU 228.1.27 228.1.28

12 A8 I Bit shiải t 8 46 A17 I Tr7 shiải cao

13 A13 I Bit shiải c 13 47 A18 I Tr8 shiải cao

14 A14 I Bit shiải c 14 48 A19 I Tr9 shiải cao

15 WE# I Cho phiải ca 49 A20 I Tr0 phiải cao

16 Ready O Seadyhiả 50 A21 I Tr1dyhiải cao

279

TCVN xxxx :2016

Bổ trí các chân trước khi thay đổi

17 VCC 228.1.34 Ngudyhiải 51 VCC 228.1.36 Ngudyhiải

18 VPP1 228.1.37 ĐPP1yhiải cang trình1 52 VPP2 228.1.39 ĐPP2yhiải cang trình2

19 A16 I Tr62yhiải can 53 A22 I Tr22yhiải can

20 A15 I Tr52yhiải can 54 A23 I Tr32yhiải can

21 A12 I Bit yhiải c 12 55 A24 I Tr4 yhiải can

22 A7 I Bit yhiải c 7 56 A25 I Tr5 yhiải can

23 A6 I Bit yhiải c 6 57 VS2# O Sen shiải cang 2

24 A5 I Bit shiải c 5 58 RESET I ThiEThiải cang tr

25 A4 I Bit Thiải c 4 59 WAIT# O TAIT#hiải cang chiT#hiải

26 A3 I Bit #hiải c 3 60 RFU 228.1.48 228.1.49

27 A2 I Bit #hiải c 2 61 REG# I LEG##hiải cang trì

28 A1 I Bit #hiải c 1 62 BVD2 O 228.1.52

29 A0 I Bit #hiải c 0 63 BVD1 O 228.1.54

30 D0 I/O Bit dhiải c 0 64 D8 I/O TrO dhiải can



33 WP O BPO dhiải 67 CD2# 228.1.59 Ph2#dhiải can 2

34 GND 228.1.60 228.1.61 68 GND 228.1.63 228.1.64

Ghi chiả

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.

280

TCVN xxxx : 2016Bả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 228.1.65 Chân Tín hiệu I/O Diễn giải

1 GND 228.1.66 ĐND 35 GND 228.1.68 228.1.69

2 D3 I/O Bit dgiảic 3 36 CD1# 228.1.71 Ph1#dgiảic ch 1

3 D4 I/O Bit dgiảic 4 37 MDO3 O DDO3dgiảic ch 3




7 CE1# I Cho phiảic c 1 41 MDO7 O DDO7phiảic ch 7

8 A10 I Bit phiảic 10 42 CE2# I Cho phiảic c 2

9 OE# I Cho phiảic chân 43 VS1# O Sen shiảic châ 1

10 A11 I Bit shiảic 11 44 IORD# I ĐORD#hiảic chân s

11 A9 I Bit #hiảic 9 45 IOWR# I Ghi vhiảic chân s

12 A8 I Bit vhiảic 8 46 MISTRT I BISTRTiảic

13 A13 I Bit RTiảic 13 47 MDI0 I DDI0RTiảic châ 0

14 A14 I Bit RTiảic 14 48 MDI1 I DDI1RTiảic châ 1

15 WE# I Cho phiảic c 49 MDI2 I DDI2phiảic châ 2

16 IREQ# O YREQ#hiảic c 50 MDI3 I DDI3#hiảic châ 3

17 VCC 228.1.86 Ngu3#hiảic 51 VCC 228.1.88 Ngu3#hiảic

18 VPP1 228.1.89 ĐPP1#hiảic chân sau 1 52 VPP2 228.1.91 ĐPP2#hiảic chân sau 2

19 MIVAL I MP khhiảic chân 53 MDI4 I DDI4hhiảic châ 4

20 MCLKI I MP clock input 54 MDI5 I DDI5thiảic châ 5

21 A12 I Bit thiảic 12 55 MDI6 I DDI6thiảic châ 6

22 A7 I Bit thiảic 7 56 MDI7 I DDI7thiảic châ 7

23 A6 I Bit thiảic 6 57 MCLKO O Xung nhảic chân

24 A5 I Bit nhảic 5 58 RESET I ThiETnhảic chân s

25 A4 I Bit Tnhảic 4 59 WAIT# O TAIT#nhảic chân sau khi

26 A3 I Bit #nhảic 3 60 INPACK# O In Port Ack.

27 A2 I Bit ort ic 2 61 REG# I LEG#ort ic chân sa

28 A1 I Bit ort ic 1 62 MOVAL O MP ra h ic c

29 A0 I Bit a h ic 0 63 MOSTRT O BOSTRTh ic ch

30 D0 I/O Bit dTh ic 0 64 MDO0 O DDO0dTh ic ch 0



33 IOIS16# 228.1.106 16 bit vic chân sau 67 CD2# 228.1.108 Ph2#it vic ch 2

281

TCVN xxxx :2016

Bổ trí các chân sau khi thay đổi

34 GND 228.1.109 228.1.110 68 GND 228.1.112 228.1.113

Ghi ch v

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 CI đơn, là bắt buộc đối với các CICAM

A.1.1 Các chân cấu hình

A.1.1.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".

Máy chủ

Vcc

≥ 10 k

Vcc

CD1#

CD2#

GND

GND

Thẻ CI

Cổng kết nối CI

≥ 10 k

Pháthiện lô gíc

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

o CICAM chưa được cắm đúng hoặc hoàn toàn

o Thẻ được cắm là một loại không được giao diện chung hỗ trợ.

A.1.1.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ủ CI Plus phải hỗ trợ 5V và tùy chọn 3.3V.

CI Plus CICAM chỉ phải hỗ trợ cung cấp 5V.

282

TCVN xxxx : 2016 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.

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

A.1.2 Bản quy định kỹ thuật cung cấp nguồn điện

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

Vcc 4.75 5.25 V Xem 1.

Vpp 4.75 5.25 V Xem 1.

Icc + Ipp - 300 mA Xem 2.

Ipp 228.1.114 50 mA hAp pgiảiính DC của thẻ

Icc + Ipppower up 228.1.115 100 mA Xem 4.

Icc + Ipppeak 228.1.116 500 mA Xem 3.

Ptotal 228.1.117 1.5 W Xem 2.

Ghi chiả

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

283

TCVN xxxx :2016

Các Các đặc tính cung cấp

T L Các đ

Nh Các đ

Đơ Các Di Các đặ

Vcc 4.75 5.25 V Xem 1.

Vpp 4.75 5.25 V Xem 1.

Icc 330 228.1.118 mA Xem 2.

Ipp 55 228.1.119 mA 228.1.120

Icc + Ipppeak 500 228.1.121 mA Xem 3.

Ghi 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ó ghi 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ẻ.

A.1.1.1 Sơ đồ thời gian bật nguồn điện cung cấp cho máy chủ

Vcc 90%

Vcc 10%

0,1 – 100 ms

> 20 ms

Điện áp cung cấp trên chân Vcc và Vpp

Tín hiệu trên chân RESET

Tín hiệu trênchân CE1#

> 1 ms> 10 s

Mức tín hiệu ‘trở kháng cao’Mức tín hiệu ‘cao’

Mức tín hiệu ‘thấp’

Mức tín hiệu ‘cao’


2 V

Hình K.2 - Sơ đồ thời gian bật nguồn điện cung cấp cho máy chủ

284

TCVN xxxx : 2016A.1.1.2 Sơ đồ thời gian tắt nguồn điện cung cấp cho máy chủ

Vcc 90%

Vcc 10%

3 – 300 ms

> 20 ms

Điện áp cung cấptrên chân Vcc và Vpp

Tín hiệu trên chân RESET

Tín hiệu trên chân CE1#

> 0 s

Mức tín hiệu ‘trở kháng cao’Mức tín hiệu ‘cao’


Mức tín hiệu ‘cao’


2 V

Hình K.3 - Sơ đồ thời gian tắt nguồn điện cung cấp cho máy chủ

A.1.2 Bản quy định kỹ thuật mức tín hiệu

A.1.2.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 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# IOWR#

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

228.1.122 228.1.123

Tải điện dung 50pF 228.1.125 228.1.126

OE# WE#

Đưa lên VCC 10KΩ 228.1.127 228.1.128

Tải điện dung 50pF 228.1.130 228.1.131

RESET Đưa lên VCC 100KΩ 228.1.132 228.1.133

Tải điện dung 50pF 228.1.135 228.1.136

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


READY 228.1.137 Đưa lên VCC 10KΩ 228.1.138

285

TCVN xxxx :2016

INPACK# WAIT#

WP = IOIS16#

228.1.140 Tải điện dung 50pF 228.1.141

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 các tín hiệu địa chỉ và dữ liệu


A[14:0] Đưa xuống GND 100KΩ 228.1.142 228.1.143

Tải điện dung 100pF 228.1.145 228.1.146

D[7:0] Đưa xuống GND 100KΩ 228.1.147 228.1.148

228.1.149 Tải điện dung 50pF 228.1.150 228.1.151

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


MDI[7:0] MISTRT MICLK MIVAL

Đưa xuống GND 100KΩ 228.1.152 228.1.153

T00KΩuốn dung gi0K 5 v i 25 pF

228.1.155 228.1.156

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


MDO[7:0] MOCLK MOVAL

Đưa xuống GND 100KΩ 228.1.157 228.1.158

Tải điện dung 50pF 228.1.160 228.1.161

Ghi chi: Ci chiện dunđối với tải có thể áp dụng đối với từng thẻ đơn.

A.1.1.1 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 = “ H v Đ H vịấ cao đầu vào 2.4 "Vcc" + 0.25 V

VOH = “ H " Đ H "ịấ cao đầu và 2.8 "Vcc" V

VIL = “ Lc"ị Đ Lc"ịấ cao đầu vàot 0.0 0.8 V

VOL = “ Lc"ị Đ Lc"ịấ cao đầu và 0.0 0.5 V

T.5c"ịấ cao đầu vàotIIH

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 mục K.1.5.1.

228.1.162 150 μA

TA01.5.1.ụcầu vào caIOH

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 228.1.163 μA

286

TCVN xxxx : 2016

Tên Thông số Nhỏ nhất Lớn nhất Đơn vị

TA0h cho các điều k IIL

DILh cho các điều kiện tải lớn nhất được quy địnhlớn nhất được quy định đtối vh cmỗi thẻ xem mục K.1.5.1.

228.1.164 700 μA

TA0h cmỗi thẻ xem m IOH


1400 228.1.165 μA

TA00 điện đầu ra caoIIH

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 mục K.1.5.1.

228.1.166 100 μA

TA0g điện đầu vào caIOH


100 228.1.167 μA

TA0g điện đầu ra caoIIL

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 mục K.1.5.1.

228.1.168 400 μA

TA0g điện đầu vào caIOH

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 228.1.169 μA

TA0g điện đầu vào cao dành cho

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

TA0.5.1.K \l "_bookmark159"cho

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 228.1.170 μA

TA0g điện đầu ra cao dành chIIL

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

TA0.5.1.K \l "_bookmark159" cho

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 228.1.171 μA

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

A.1.1 Mô tả các tín hiệu của giao diện chung

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

287

TCVN xxxx :2016Bộ 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.

288

TCVN xxxx : 2016 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].

289

TCVN xxxx :2016 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.

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

290

TCVN xxxx : 2016 Tín hiệu này hoạt động để chỉ ra byte hợp lệ của một gói tin truyền tải MPEG trên MDO [7: 0].

Trong giai đoạn mà giao diện này liên tục được chạy thì yêu cầu có và sử dụng tín hiệu này để nhận dạng dữ liệu không hợp lệ giữa và trong các lần truyền gói tin dòng truyền tải MPEG.

Xung nhịp đầu ra MPEG MCLKO

Tín hiệu này là một xung nhịp đầu vào liên tục chạy sau khi thay đổi chân trong trường hợp chuyển mạch đổi hướng dòng truyền tải này được thiết lập là truyền qua mô-đun. "Dẫn đến trường hợp này là việc dòng truyền tải được định tuyến qua CICAM ".

Nhiều CICAM có thể nối MCLKO với một thẻ có MCLKI của một thẻ tiếp theo khác miễn là tuân theo các thông số kỹ thuật về thời gian.

A.1.1.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ừ Vhmin sang Vlmax được quy định tại mục K.1.5.

Thời gian tăng được định nghĩa là thời gian chuyển tiếp từ Vlmax sang Vhmin được quy định tại mục 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 mục 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.

A.1.2 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 mục K.1.6.1

291

TCVN xxxx :2016A.1.2.1 Sơ đồ đọc bộ nhớ thuộc tính của giao diện chung

ta(A)(2)

ta(CE#)(2)

ta(OE#)(2)

ten(OE#)

tv(WT-OE#)(3)

tsu(A)

tsu(CE#)

CE#

[14:0]REG#

OE#

WAIT#

D[7:0]

tc(R)

tw(WT)(3)

tv(WT) tdis(OC#)

tdis(CE#)

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

th(A)

th(CE#)

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

Nhỏ nhất Lớn nhất

Kho nhấtnhi gian tnh tcR 300 228.1.174

Khoian tnhi gian truy nhố quy định ta(A) 228.1.175 300

Khoian truy nhố quy định thời gian đọcnhmáy chủ ta(CE#) 228.1.176 300

Kho#)n truy nhố quy định thời gian đọcnhmáy chủ ta(OE#) 228.1.177 150

Kho#)n truy nhố quy định thời gian đọcnhmáy chủ đi OE#

tdis(OE#) 228.1.178 100

Kho#)n truy gian tín hiệu cho phép ra tính từ OE# ten(OE#) 5 228.1.179

DOE#)n truy gian tín hiệu cho phép ra tính từhủ tv(A) 0 228.1.180

Kho#)n truy gian tín hiệu cho phép 1 tsu(A) 100 228.1.181

Kho#)n truy gian tín hiệu ch 1 th(A) 35 228.1.182

Kho#)n truy gian tín hiệu cho phép ra tính từhủ 1 tsu(CE#) 0 228.1.183

Kho#)n truy gian tín hiệu cho phép ra tính 1 th(CE#) 35 228.1.184

292

TCVN xxxx : 2016

WAIT# htruy gian tín OE# 1 tv(WT- OE#)

228.1.185 100

Đ00) htruy gian t 6 tw(WT) 228.1.186 12 μs

Kho) htruy gian tín hiệu cho phép ra tính từhủ đi gian tăn tv(WT) 0 228.1.187

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

A.1.1.1 Sơ đồ ghi bộ nhớ thuộc tính của giao diện chung

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

CE#

A[14:0]REG#

WE#

WAIT#

DOUT[15:0]#

DIN[15:0]#

OE#

tc(W)

tsu(CE#-WE#)

tsu(A-WE#)

tw(WE#)

tw(WT)

tsu(D-WE#)

tsu(CE#)

tsu(A)

tsu(OE#-WE#) tv(WT-WE#) tv(WT)

tdis(WE#)tdis(OE#)

ten(WE#)ten(OE#)

th(D)

th(OE#-WE#)

trec(WE#)

th(CE#)

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

Nhỏ nhất

Lớn nhất

Kho nhấti bộ nhớ thu tc(W) 250 230.1.1

Đ50 nhấti bộ nhớ tw(WE#) 150 230.1.2

Kho#)hấti bộ nhớ thuộc tínhđho#)hấ 1 tsu(A) 30 230.1.3

Kho#)hấti bộ nhớ thuộc tínhđho#)hấ dho#)hất WE# 1 tsu(A-WE#) 180 230.1.4

KhoWE#)ti bộ nhớ thuộc tínhthoWE#)ti bộ nhớ thuộc tsu(CE#-WE#) 180 230.1.5

293

TCVN xxxx :2016

tínhcho WE#

Kho#-WE#) bộ nhớ thuộc tínhdho#-WE#) bộ nhớ WE# t(D-CE#) 80 230.1.6

Kho-CE#)) bộ nhớ thuộc tínhu th(D) 30 230.1.7

Kho-CE#)) bộ nhớ thuộc tínhghi trec(WE#) 30 230.1.8

Kho#)E#)) bộ nhớ thuộc tínhhông cho phép ra tính từ WE# tdis(WE#) 230.1.9 100

Kho#)E#)) bộ nhớ thuộc tínhhông cho phép ra tính từ OE# tdis(OE#) 230.1.10 100

Kho#)E#)) bộ nhớ thuộc tínhhông cho phép ra t WE# ten(WE#) 5 230.1.11

Kho#)E#)) bộ nhớ thuộc tínhhông cho phép ra t OE# ten(OE#) 5 230.1.12

Kho#)E#)) bộ ian thiết lập tín hiệu cho phép ra tính từ WE# tsu(OE#-WE#) 10 230.1.13

Kho#-WE#) bộ ian thiết lập tín hiệu cho phép ra t WE# th(OE#-WE#) 10 230.1.14

Kho#-WE#) bộ ian thiết lập tín hiệu cho phép ra 2 tsu(CE#) 0 230.1.15

Kho#)WE#) bộ ian thiết lập tín hiệu cho ph 2 th(CE#) 20 230.1.16

WAIT# h#) bộ ian thiếWE# 2 tv(WT-WE#) 230.1.17 35

Đ5T-WE#)) bộ ian t 4 tw(WT) 230.1.18 12 μs

TsT)WE#)) bộ ian thiết lập tín hiệu cho phép ra 3 tv(WT) 0 230.1.19

Ghi ch#)

1. Định thời tín hiệu REG# giống định thời tín hiệu địai chỉ.

2. Các thời gian này được quy định dành cho máy chủ và CICAM có hỗ trợ tính 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ẻ CI. Các độ lệch và độ trễ từ thiết bị thu đến thẻ CI phải được tính.

5. Các thời gian được tính theo ns khi không được ghi rõ đơn vị.

294

TCVN xxxx : 2016A.1.1.1 Thời gian đọc I/O của giao diện chung

CE#

A[14:0]

REG#

IORD#

WAIT#

D[7:0]

INPACK#

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

tsu(REG#)

tsu(CE#)

tsu(A)

tdf(INPACK#) tdr(INPACK#)

tdf(WAIT#) tw(WAIT#) tdr(WAIT#)

tsu(D) th(D)

th(CE#)

th(REG#)th(A)

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 Nhỏ nhất Lớn nhất

Thn nhấthôtrn nh li nhấth IORD# tsu(D) 230.1.20 100

Th0D#hấthông số quy định thời IORD# th(D) 0 230.1.21

ĐD)D#hấthông số quy đị tw(IORD) 165 230.1.22

KhoRD)ấthông số quy định thời gian đọc đ IORD# tsu(A) 70 230.1.23

Th)D#)ấthông số quy định thời IORD# th(A) 20 230.1.24

KhoD#)ấthông số quy định thời gian đ IORD# tsu(CE#) 5 230.1.25

Kho#))ấthông số quy định thời gi IORD# th(CE#) 20 230.1.26

Khoảng thời gian thiết lập REG# trước IORD# tsu(REG#) 5 230.1.27

KhoG#) thời gian thiết lập REG# t IORD# th(REG#) 0 230.1.28

KhoG#) thời gian thiết lập REG# trướcc đến thẻ CI IORD# df(INPACK#) 0 45

KhoPACK#)ời gian thiết lập REG# trướcc đến thẻ CI IORD#

dr(INPACK#)230.1.29 45

KhoPACK#)ời gian thiết lập REG# trướcc đến thẻ C IORD# tdf(WAIT#) 230.1.30 35

KhoIT#)#)ời gian thiết lập REG# trướcc đến thẻ CI phải đ tdr(WAIT#) 230.1.31 0

295

TCVN xxxx :2016

Mục Ký hiệu Nhỏ nhất Lớn nhất

ĐWAIT#)#)ời gian t tw(WAIT#) 230.1.32 12000

Ghi ch)#)ời gian thiết lập REG# trướ

A.1.1.1 Thời gian ghi I/O của giao diện chung

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL maxA[14:0]

REG#

CE#

IORD#

WAIT#

D[7:0]

tsu(REG#)

tsu(CE#)

tsu(A)

tdf(WAIT#) tw(WAIT#) tdr(WAIT#)

tsu(D) th(D)

th(CE#)

th(REG#)th(A)

tw(IOWR)

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 ghi I/O

Mục Ký hiệu Nhỏ nhất

Lớn nhất

Kho nhất4 – Các thông số quy định IOWR# tsu(D) 60 230.1.33

Th)R#hất4 – Các thông số quy IOWR# th(D) 30 230.1.34

Đ0)R#hất4 – Các thông tw(IOWR) 165 230.1.35

KhoWR)ất4 – Các thông số quy định thời g IOWR# tsu(A) 70 230.1.36

Th)R#)ất4 – Các thông số quy IOWR# th(A) 20 230.1.37

KhoR#)ất4 – Các thông số quy định th IOWR# tsu(CE#) 5 230.1.38

Kho#))ất4 – Các thông số quy địn IOWR# th(CE#) 20 230.1.39

Kho#))ất4 – Các thông số quy địnhrước IOWR# tsu(REG#) 5 230.1.40

KhoG#)ất4 – Các thông số quy định IOWR# th(REG#) 0 230.1.41

KhoG#)ất4 – Các thông số quy địnhrướci gian ghi IOWR#

tdf(WAIT#)230.1.42 35

296

TCVN xxxx : 2016

Mục Ký hiệu Nhỏ nhất

Lớn nhất

T5AIT#)t4IOWR# cao tWR# cao – Các thWAIT# cao

tdr(WAIT#)

0 230.1.43

ĐWAIT#)ao – Các th tw(WAIT#) 230.1.44 12000

Ghi ch)aoCác thời gian tính theo ns.

A.1.1.1 Định thời tín hiệu MPEG của giao diện chung

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

VIH min

VIL max

MCLKI

MDI[7:0]MISTRMIVAL

MCLKO

MD0[7:0]M0STRM0VAL

tclkp

tclkh tclkl

tsu th

tclkp

tclkh tclkl

tosu toh

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

Thời gian tối thiểu

72 Mbits/s

96 Mbits/s

Chu kgian tối th tclkp 111 83

Khopkgian tối thiểuđịnh thxung nhan tối tclkh 40 20

Khoh nhan tối thiểuđịnh thxung nhan tối tclkl 40 20

Khol nhan tối thiểuđịnh thời gian tín tsu 15 10

Khol nhan tối thiểuđịnh thời vol th 10 10

Khol nhanời gian thiết lập dữ liệu ra tosu 20 10

Khol nhanời gian thiết lập d ra toh 15 10

Ghi chn: Ti chnhanời gian thiết lập dữ.

297

TCVN xxxx :2016

298

TCVN xxxx : 2016

Phụ lục A

(quy định)

Tóm tắt tài nguyên

A.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, mục 8.2.2, phiên bản 2 được quy định trong TS 101 699 [8] mục 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], mục 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], mục 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], mục 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], mục 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.

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

Bảng L.1 - Tóm tắt tài nguyên

Tài nguyên Đối tượng ứng dụng Chiều

Tên Nhãn nhận dạng tài nguyên

Lớp Loại Phiên bản

Thẻ APDU Giá trị thẻ

Máy chủ

CAM

Bắt buộc

Tài liệu

Qui liệuthẻạng tài

00 01 00 41 1 1 1 profile_enq 9F 80 10

Có (phi80le_enqạng tài nguyên0 ản 1 hoặc 2[8], ng đối v)

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 3

module_id_command 9F 80 14 4

Th 80e_id_co

00 02 00 41 2 1 1 application_info_enq 9F 80 20 0C0

EN 50221

299

TCVN xxxx :2016





Máy chủ

CAM

Bắt buộc

Tài liệu

mmandi

application_info 9F 80 21 1

enter_menu 9F 80 22 2


TS 101 699




CI Plus



request_cicam_reset 9F 80 23 3

data_rate_info 9F 80 24 4

H4 80rate_inforesetqguyên0 ản

00 03 00 41 3 1 1 ca_info_enq 9F 80 30 0C0

EN 50221

ca_info 9F 80 31 1

ca_pmt 9F 80 32 2

ca_pmt_reply 9F 80 33 3

Đ3 80t_replyforese

00 20 00 41 32 1 1 tune 9F 84 00 0C0

EN 50221

replace 9F 84 01 1

clear_replace 9F 84 02 2

ask_release 9F 84 03 3

00 20 00 42 32 1 2 tune 9F 84 00 0C0

CI Plus 1.3

replace 9F 84 01 1

clear_replace 9F 84 02 2

ask_release 9F 84 03 3

tune_broadcast_req 9F 84 04 4

tune_reply 9F 84 05 5

ask_release_reply 9F 84 06 6

Ng 00 24 00 41 36 1 1 date_time_enq 9F 84 40 EN

300

TCVN xxxx : 2016





Máy chủ

CAM

Bắt buộc

Tài liệu

84elease_re

0C0

50221

date_time 9F 84 41 1

MMI 00 40 00 41 64 1 1 close_mmi 9F 88 00 0High level

only

EN 50221

display_control 9F 88 01 1

display_reply 9F 88 02 2

text_last 9F 88 03 3

text_more 9F 88 04 4

keypad_control 9F 88 05 5

keypress 9F 88 06 6

enq 9F 88 07 7

answ 9F 88 08 8

menu_last 9F 88 09 9

menu_more 9F 88 0A A

menu_answ 9F 88 0B B

list_last 9F 88 0C C

list_more 9F 88 0D D

subtitle_segment_last 9F 88 0E E

subtitle_segment_more 9F 88 0F F

display_message 9F 88 10 0

scene_end_mark 9F 88 11 1

scene_done 9F 88 12 2

scene_control 9F 88 13 3

subtitle_download_last 9F 88 14 4

subtitle_download_more 9F 88 15 5

flush_download 9F 88 16 6

download_reply 9F 88 17 7

Truy8oad_replyo

00 60 xx x 1 96 489.1.1 1 comms_cmd 9F 8C 00 FCF

EN 50221

301

TCVN xxxx :2016





Máy chủ

CAM

Bắt buộc

Tài liệu

ad_ F 8C 00dreplyoad_mv1.3 c.3C 00dreplyoad_moreyên

302

TCVN xxxx : 2016





Máy chủ

CAM

Bắt buộc

Tài liệu

connection_descriptor 9F 8C 01 F

comms_reply 9F 8C 02 F

comms_send_last 9F 8C 03 F

comms_send_more 9F 8C 04 F

comms_rcv_last 9F 8C 05 F

comms_rcv_more 9F 8C 06 F

00 60 xx x2 96 521.1.1 2 comms_cmd 9F 8C 00 FCF F

8C 00d_moreeriptv1.3

c.3C 00d_moreeriptoreyên

CI Plus







303

TCVN xxxx :2016





Máy chủ

CAM

Bắt buộc

Tài liệu

00 60 xx x3 96 553.1.1 3 comms_cmd 9F 8C 00 FCF F

8C 00d_morn bản

v1.3

c.3C 00d_morn bản

oreyên

CI Plus 1.3







Ki 8C 06v_moreerip

00 8C 10 01

140 64 1 cc_open_req 9F 90 01 1C1

CI Plus

304

TCVN xxxx : 2016





Máy chủ

CAM

Bắt buộc

Tài liệu

cc_open_cnf 9F 90 02 2

cc_data_req 9F 90 03 3

cc_data_cnf 9F 90 04 4

cc_sync_req 9F 90 05 5

cc_sync_cnf 9F 90 06 6

cc_sac_data_req 9F 90 07 7

cc_sac_data_cnf 9F 90 08 8

cc_sac_sync_req 9F 90 09 9

cc_sac_sync_cnf 9F 90 10 0

00 8C 10 02

140 64 2 cc_open_req 9F 90 01 1C1

CI Plus 1.3

cc_open_cnf 9F 90 02 2

cc_data_req 9F 90 03 3

cc_data_cnf 9F 90 04 4

cc_sync_req 9F 90 05 5

cc_sync_cnf 9F 90 06 6

cc_sac_data_req 9F 90 07 7

cc_sac_data_cnf 9F 90 08 8

cc_sac_sync_req 9F 90 09 9

cc_sac_sync_cnf 9F 90 10 0

cc_PIN_capabilities_req 9F 90 11 690

cc_PIN_capabilities_reply

9F 90 12 2

cc_PIN_cmd 9F 90 13 3

cc_PIN_reply 9F 90 14 4

cc_PIN_event 9F 90 15 5

cc_PIN_playback 9F 90 16 6

cc_PIN_MMI_req 9F 90 17 7

Ng 90N_MMI_reqk

00 8D 10 01

141 64 1 Host_country_enq 9F 81 00 0C0

CI Plus

305

TCVN xxxx :2016





Máy chủ

CAM

Bắt buộc

Tài liệu

ties_reply0 ản 1

Host_country 9F 81 01 1

Host_language_enq 9F 81 10 0

Host_language 9F 81 11 1

CAM_Upgrade

00 8E 10 01

142 64 1 cam_firmware_upgrade 9F 9D 01 FCF

CI Plus

cam_firmware_upgrade_reply

9F 9D 02 F

cam_firmware_upgrade_progress

9F 9D 03 F


9F 9D 04 F

HF 9D 04ware_upgrad

00 8F 10 01

143 64 1 operator_status_req 9F 9C 00 FCF

CI Plus 1.3

operator_status 9F 9C 01 F

operator_nit_req 9F 9C 02 F

operator_nit 9F 9C 03 F

operator_info_req 9F 9C 04 F

operator_info 9F 9C 05 F

operator_search_start 9F 9C 06 F

operator_search_status 9F 9C 07 F

operator_exit 9F 9C 08 F

operator_tune 9F 9C 09 F

operator_tune_status 9F 9C 0A F

operator_entitlement_ack

9F 9C 0B F

SAS 00 96 10 01 150 64 1 SAS_connect_rqst 9F 9A 00 0No

CI Plus

306

TCVN xxxx : 2016





Máy chủ

CAM

Bắt buộc

Tài liệu

SAS_connect_cnf 9F 9A 01 1

SAS_data_rqst 9F 9A 02

821

SAS_data_av 9F 9A 03

SAS_data_cnf 9F 9A 04

SAS_server_query 9F 9A 05

SAS_server_reply 9F 9A 06

SAS_async_msg 9F 9A 07

MMI A ync_ms

00 41 00 41 65 1 1 RequestStart 9F 80 00 0C0

TS 101 699

307

TCVN xxxx :2016





Máy chủ

CAM

Bắt buộc

Tài liệu

RequestStartAck 9F 80 01 1

FileRequest 9F 80 02 2

FileAcknowledge 9F 80 03 3

AppAbortRequest 9F 80 04

876

AppAbortAck 9F 80 05

00 41 00 42 65 1 2 RequestStart 9F 80 00 0Kh

80sđh

80stStartestymCh h 80stStCICAM

CI Plus 1.3

RequestStartAck 9F 80 01 1

FileRequest 9F 80 02 2

FileAcknowledge 9F 80 03 3

AppAbortRequest 9F 80 04

904

AppAbortAck 9F 80 05

308

TCVN xxxx : 2016

Phụ lục A

(quy định)

Định dạng bản tin ứng dụng MHP

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

A.1.1 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ệ thống CA Headend

Tuyến trả về

Gốc MHP Ứng dụng

Miền CA

Thẻthôngminh

Hệ thống CA it.dtt.ca Truyền tảiXLET

CA I/Fgốc

Nhà cung cấp CA Nhà sản xuất Nhà truyền tảiNhà sản xuấthoặcđối tác thứ 3

Hình M.1 - Môi trường nhúng CAS

A.1.2 Môi trường CI CAS

Trong một môi trường CI 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 (CI) để 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

309

TCVN xxxx :2016đó 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 CI).

CI CAM iDTV

CI CAM TuyếnCI

TV gốcMiền CA

it.dtt.c aCA I/F gốc

Hệ thống CA Headend

Ứng dụngMHP

Hệ thống CA

Thẻthôngminh

CI Plus gốc

Truyền tảiXLET

Nhà cung cấp CA Nhà sản xuấtCICAM

Nhà truyền tảiNhà sản xuấtiDTV hoặcđối tác thứ 3

Nhà sản xuấtiDTV

Tuyến trả về

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 CI đế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 CI 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 CI 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 CI CA đã biết.

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

310

TCVN xxxx : 2016

DVB CA API dànhcho MHP

CI Plus CAMMHP CA API

dành choCI Plus iDTV hoặc máy chủ CI Plus

Tập concụ thể CAS

Xếp chồng MHPỨng dụngcụ thể CAS

XLET

3Ứng dụngcụ thể MHPdành choCI Plus

Thiết lập truyền SAS 3Tàinguyên

SAS CAM

Tài nguyênSAS

máy chủ

Thư việnCAS 1

ID của ứng dụng đăngký với tài nguyên SAS của máy chủ

Yêu cầukỹ thuật

CI Plus API

Bắt đầu truyền giữacác ứng dụng cụ thể

Tài nguyên SAS chung có thểxử lý các phiên SAS khác

Các ứngdụng Java thường trú

2

Hình M.3 - Kết nối MHP và hệ thống CA thông qua SAS.

Trong đó:

private_host_application_ID phảil đượ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 CI 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 CI 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ể.

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

311

TCVN xxxx :2016 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 CI khác để biết thông tin.

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

A.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ằngi 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.

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


SAS_async_msg() 911.1.2

24

912

uimsbfSAS_async_msg_tag

length_field() * 913

message_nb 8 uimsbf

message_length 16 uimsbf

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


312

Hp4530, 11/06/14,

records

TCVN xxxx : 2016

message_byte()

command_id

ca_system_id

transaction_id

send_datatype_nbr


datatype_length data_type()

913.1.4

8

16

32

8

914

8

16

8 * datatype_length

915

uimsbf

uimsbf

uimsbf

uimsbf

915.1.1

uimsbf

uimsbf

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ô tảdạn 0x00 915.1.2 Dx phòng.

Dx phòng 0x01 915.1.3 Dx01hòng.

CMD_ATR_GET_REQUEST 0x02 H M Yêu c2ATR_GE m c2ATR gc2ATR_GET_REQUESTlệnh này, xác định loại được

CMD_ATR_GET_RESPONSE 0x03 H M Tr03ATR_GET_RES ATR Get Request ceq CICAM chICAMt_GET_RESATR cRCAMt_GET_RESPONSEệnh nàyhe cắm đã cho hoặc có nhận dạng đã cho

CMD_CANCEL_REQUEST 0x04 H M H M

Y H4CANCEL_R m H4CAN ho4C CICAM gCAMANCEL_REQUESTSEệnh nàyhe cắm đã giao dNCELxiao dNC, lo dNCEL_REQUESTSEệnh nàyhe cắm đã cho hoặc có nhận dạng đã choliệu bằng các.

CMD_CANCEL_RESPONSE 0x05 H M H M

TrH5CANCEL_RESP Cancel Request, t request,EL_RESPONSEEệnh nàyhe cắm đã transaction_id cra ransacti.

CMD_CAPABILITIES_REQUEST 0x06 H M Truy vPABCICAM thAMvPABILITIES_REQUESTnàyhe cắm đã cho ho.

CMD_CAPABILITIES_RESPONSE 0x07 H M Tr07CAPABILITIE CMD_CAPABILITIES_REQUEST tMD_CAPABILI mMD_CAP chD_CAPABILITIES_REQUESTEà.

CMD_HISTORY_GET_REQUEST 0x08 H M Yêu c8HISTOR m c8HIS

313

TCVN xxxx :2016


gc8HISTORY_GET_REQUESTTEàyhe c.

CMD_HISTORY_GET_RESPONSE 0x09 H M Tr09HISTORY_GET History Get Request tq CICAM chCAMthhCA tin quTORY_GET_RESPONSEEà.

CMD_HISTORY_SET_REQUEST 0x0a H M Yêu caHISTOR m caHIS gcaHISTORY_SET_REQUESTEEàyhe cắm đã .

CMD_HISTORY_SET_RESPONSE 0x0b H M Tr0bHISTORY_SET History Set Request tq CICAM.

CMD_NOTIFICATION_DISABLE 0x0c H M Kh0cNOTIFICATION_DISABLEEàyhe cắm đã cho hoặc có nhận dCICAM.

CMD_NOTIFICATION_ENABLE 0x0d H M Cho phTIFICATION_ENABLEEEàyhe cắm đã cho hoặc có nhận d

CMD_PARENTAL_LEVEL_GET_REQUEST 0x0e H M Yêu cePARE m cePAR đ cePARENTAL_LEVEL_GET_REQUESTcắm đã hiện tại.

CMD_PARENTAL_LEVEL_GET_RESPONSE

0x0f H M Tr0fPARENT CICAM đCIlCICAMR kiCAMRENTAL_LEVEL_GET_RESPONSEắm đã hiện tại có nhậ CMD_PARENTAL_LEVEL_GET_REQUEST.

CMD_PARENTAL_LEVEL_SET_REQUEST 0x10 H M Yêu c0PARE m c0PAR đ c0PARENTAm c0PARENTAL_LEVa cha mẹ hiện tại.

CMD_PARENTAL_LEVEL_SET_RESPONSE

0x11 H M Tr11PARENT CICAM CICAMRENTA mCICAMRENTAL_LEVEL_SET_R vCICAMRENTAL_LEVEL_SE CMD_SET_PARENTAL_LEVEL_REQUEST.

CMD_PIN_CHECK_REQUEST 0x12 H M Yêu c2PIN_CH m c2PIN gc2PIN_CHECK_RE thgc2PIN_CHEC.

CMD_PIN_CHECK_RESPONSE 0x13 H M Tr13PIN br13PIN Set PIN Request cRe CICAM đCICAMst HECK_RPIN đúNC.

CMD_PIN_GET_REQUEST 0x14 H M Truy vN_ CICAM thCAMN_GET_REQUESTNSE_REQUES.

CMD_PIN_GET_RESPONSE 0x15 H M Tr15PIN br15PIN_CMD_PIN_STATUS_REQUEST tD_PICAM chứa thông tin trạng thái của các PIN.

CMD_PIN_SET_REQUEST 0x16 H M Yêu c6PIN_SE m c6PIN gc6PIN_SET_REQU thgc6PIN_SET_ hi6PIN_S.

CMD_PIN_SET_RESPONSE 0x17 H M Tr17PIN br17PIN PIN Set Request cequCICAM chCAMthhCAMstt ET_ đưCAMstt ET_R CA nAAMstt Eiữ.

CMD_PRIVATE_DATA_REQUEST 0x18 H M H M

Yêu c8PRIVAT m c8PRI hoc8 CICAM gCAMRIVATE_DATA_REQUEST trạng t.

CMD_PRIVATE_DATA_RESPONSE 0x19 H M H M

TrH9PRI brH9PRI Private Data Request.

314

TCVN xxxx : 2016


CMD_PRODUCT_GET_REQUEST 0x1a H M Yêu caPRODUC m caPRO gcaPRể truy vấn thông tin sản phẩm hiện tại.

CMD_PRODUCT_GET_RESPONSE 0x1b H M Tr1bPRO br1bPRO Product Get Request c e q CICAM chCAMthCAMstDUCT_GET_RE chCAMstDUCT.

CMD_PURCHASE_CANCEL_REQUEST 0x1c H M Yêu ccPURCHA m ccPUR g ccPURCHASE_CANCEL_REQUES.

CMD_PURCHASE_CANCEL_RESPONSE 0x1d H M Tr1dPUR br1dPUR Purchase Get Request ceq CICAM chCA thCAMsteHASE_CANCE chCAMsteHAS.

CMD_PURCHASE_SET_REQUEST 0x1e H M Yêu ceP đưcePURCHASE_SET đư mua mURCHASE_SE.

CMD_PURCHASE_SET_RESPONSE 0x1f H M Tr1fPUR br1fPUR Purchase Set Request cqu CICAM chCA thCAMsteHASE_SET_R chC sCAMste.

CMD_RECHARGE_REQUEST 0x20 H M Yêu c0R đưc0RECHARGE_REQ đưc0RECHARGE_REQUESTPON.

CMD_RECHARGE_RESPONSE 0x21 H M Tr21REC br21REC Recharge Request cequCICAM chCAMkhCAMsteARGE_RESPONS sCAMiện nCAMiệnA.

CMD_SLOT_GET_REQUEST 0x22 H M Yêu c2S đưc2SLOT_GET_REQ đưc2SLOT_GETthc2SLOT_GET_REQU.

CMD_SLOT_GET_RESPONSE 0x23 H M Tr23SLO br23SLO Slot Get Request cequCICAM chCA thCAMstT_GET_RESP chCAMstT_GET_RESPONSEONSENSEản phẩm hiệ.

CMD_SMARTCARD_GET_REQUEST 0x24 H M Yêu c4S đưc4SMARTCARD_GE đưc4SMARTCARD_GET_REQUESTNSEản phẩm .

CMD_SMARTCARD_GET_RESPONSE 0x25 H M Tr25SMA br25SMA SmartCard Get Request cequCICAM chCAMstrdCARD_GET_RESPONSESEản phẩm hiện tạii có nhận dạng đã choliệu bằng .

CMD_SMARTCARD_SET_REQUEST 0x26 H M Yêu c6S đưc6SMARTCARD_SE đưc6SMARTCARD_SET_REQUESTESEản phẩm hiện tạii có nhận dạng đã choliệ.

CMD_SMARTCARD_SET_RESPONSE 0x27 H M Tr27SMA br27SMA SmartCard Set Request cequCICAM chCAMstrdCARD_SET_RESPONSESEản phẩm hiệ cắm đã cho hoặc có nhận dạng đã cho.

CMD_WALLET_GET_REQUEST 0x28 H M Yêu c8W đưc8WALLET_GET_R đưc8WALLET_GET_REQUESTONSESE.

CMD_WALLET_GET_RESPONSE 0x29 H M Tr29WAL br29WAL Wallet Get Request ceq CICAM.

CMD_PRODUCT_INFO_GET_REQUEST 0x30 H M Yêu cầu đưcầuRODUCT_INFO

315

TCVN xxxx :2016


đưcầuRODUCT_thcầuRODUCT_INFO_GET_REQUESTản phẩm hi.

CMD_PRODUCT_INFO_GET_RESPONSE 0x31 H M Tr31PRO br31PRO Product Info Get Request cequCICAM chCA thCAMstDUCT_INFO_GET_RESPONSE.

915.1.4 0x32-

0x3f

915.1.5 Dx3f-stD.

CMD_ACCESS_EVENT 0x40 H M Bản tin s tinCE ts CICAM đICAMnCESS_EVENT_GET_RESPONSEn phẩm hiệ cắm đã cho hoặc có nhận dạng đã chocách sử dụng SAS_async_msg () được sao chépề th.

CMD_CREDIT_EVENT 0x42 H M Bản tin s tin E tt CICAM vCAM EDIT_EVENT_GET_RESPONSEn phẩm hiệ.

CMD_MESSAGE_EVENT 0x44 H M Bản tin s tin S ttiCICAM thAM SSAGE_EVENTGET_RESPONSEn phẩm .

CMD_PIN_REQUEST_EVENT 0x46 H M Sự ki6P ti CICAM chCAMN_REQUEST_EVENTRES.

CMD_PIN_RESPONSE_EVENT 0x47 H M Tr47PIN b47PIN_RPin Request Event tv mventst ventst_RE chentst PIN sược yêPIN s

CMD_PRIVATE_DATA_EVENT 0x48 H M H M

Yêu c8P đưc8 mưc8PRI hoc8 CICAM gCAMRIVATE_DATA_EVENTESPONSEn phẩm hiệ cắm đã cho hoặc

CMD_PRODUCT_EVENT 0x4a H M Bản tin s tinRO t CICAM vICAMRODUCT_EVENTEVENTESPONSE.

CMD_PURCHASE_HISTORY_EVENT 0x4c H M Bản tin stinURC tstCICAM vICAMURCHASE_HISTORY_EVENTNSEn p.

CMD_RECHARGE_EVENT 0x4e H M Bản tin stinECH ts CICAM chAMECHARGE shAMECH nhAMECHARGE_EVENTRY_EV.

CMD_SLOT_EVENT 0x50 H M Bản tin stinLOT ts CICAM vICAMLOT_EVENTVENTRY_EVENTNSEn phẩm in 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 stinMAR ts CICAM vICAMMARTCARD_EVENTY_EVENTNSE.

915.1.6 0x54-

0x7f

915.1.7 Dx7f-MAR.

915.1.8 0x80-0xff 915.1.9 Đư80-0xffCARD_EVENTY_EVENTN.

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

316

TCVN xxxx : 2016bộ 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

Nhi dữ liệuCác nhận dạ datatype id Midat

916 0 Didatype.

dtid_access_event 31 Thid_access_eventận dạng l4.vhid_access_ev CA.

dtid_byte_data() 1 Byte ded_byte_data.

dtid_cas_information() 2 Nhid_cas_information()ng l4. thd_cas_information()ng .

dtid_cicam_information() 3 Nhid_cicam_information() l4. vid_cicam_information() l4.CAM.

dtid_credit_event() 4 Thid_credit_event()ion() l4. vid_credit_event()ion() l4.

dtid_error_status 5 Thid_error_status()ion()

dtid_history() 6 Btid_history()tus()ion() l4.nh.

dtid_history_event() 7 Thid_history_event()on() l4.hay _history_event()on() quá trình mua hoặc một bản tin mới tới từ hệ thống CA.

dtid_history_request() 8 Ytid_hi thd_history_request.

dtid_numeric_index() 9 Mtid_numeric_index()()() quá trình mu.

dtid_object_identity() 10 Nhid_object_identity()() quá trìnhCA c_o.

dtid_parental_level() 11 M1c cd_parental

dtid_pin_code() 12 M2 PIN.

dtid_pin_event() 13 Thôhg bd_pin_event() tbd_pin_event()yêtbd_p mb PIN nIN_pin_event()àn.

dtid_pin_information() 14 Thôhg tin vn_inform.

dtid_product() 15 B5n ghi coduct()phgh.

dtid_product_event() 16 Thôhg bd_product_evens bd_pro tbd_product_ev.

dtid_product_info() 30 Ban ghi than ghi tuct_info() sn ghi t record.

dtid_product_request() 17 Y7u cd_ thd_product_reques.

dtid_purchase() 18 B8n ghi vichase(.

dtid_recharge() 19 Y9u cd_ ncd_rech.

dtid_recharge_event() 20 Thôhg bd_recharge_event())i bd_recharge_even.

dtid_service_id() 21 Nhậh dạdg dd_serv.

dtid_slot() 22 Nhậh dạdg tr_slot()i cr_slot()ắ cr_slot()g minh.

dtid_slot_event() 23 Thôhg bd_slot_event()c b sbd_slo thd_slot_event()CA.

dtid_smartcard() 24 Thôhg tin cartcard())ng minh.

dtid_smartcard_event() 25 Thôhg bd_smartcard_event sbd_sma thd_smartcard_event()thhd_sma.

dtid_smartcard_request() 26 Y6u cd_ thd_smartcard_request()h.

317

TCVN xxxx :2016

Nhi dữ liệuCác nhận dạ datatype id Midat

dtid_user_data() 27 D7 lid_user_data()slid_us.

dtid_wallet() 28 B8n ghi cllet()a()n.

dtid_wallet_id() 29 Nhậh dạdg cd_wallet_i.

32-

127

D2-127ng.

128-255

Đư8-255ưư8-255dư8-255c 8-25.

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.

A.1 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 chungn được sử dụng trong các bản tin CI. 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.

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


money() 916.1.3

24

917

bslbfcurrency

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

318

TCVN xxxx : 2016num_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)

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

917.1.5

16

24

918

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

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


duration()

elapsed

918.1.2

24

919

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

319

TCVN xxxx :2016A.1.1 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

for (i=0; i<length; i++)

char

919.1.2

8

920

8

921

uimsbf

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.

A.1.1 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 lstring

Cú pháp

Số bit Kiểu

lstring()

length


char

921.1.2

16

922

8

923

uimsbf

923.1.1

bslbf

Ngữ nghĩa dành cho lstring () 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.


320

TCVN xxxx : 2016A.1.1 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


locator()

string_indicator

if (string_flag == 1) length


char

else

tsid_indicator

sid_indicator

event_indicator

reserved_zero

num_components

original_network_id

if (tsid_indicator == 1)

transport_stream_id

if (sid_indicator == 1)

service_id

for (i=0; i<num_components; i++)

component_tag

if (event_indicator == 1)

event_id

path_segments

923.1.2

1

924

7

925

8

926

1

1

1

1

3

16

927

16

928

929

16

930

931

8

932

933

16

934

935

*

936

bslbf

937

uimsbf

938

bslbf

939

bslbf

bslbf

bslbf

bslbf

uimsbf

uimsbf

940

uimsbf

941

942

uimsbf

943

944

uimsbf

945

946

uimsbf

947

string()

321

TCVN xxxx :2016Ngữ 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 CI 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ể 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-bit 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.

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

322

TCVN xxxx : 2016Ví 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.

A.1.2 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ẹ


parental_level() 8 uimsbf

Ngữ nghĩa dành cho parental_level () là:

parental_level: mức kiểm soat 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 Dhông áp.

0x01

PARENTAL_CONTROL_STRICT_MODE ChRENTAL_CONTROL_STRICTnhRENTAL_ PIN TAL_CONTROL_STRICT_MODE13. trị bí mật được mã hoá là 0xfffe. ủa chuỗi. Thô.

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ácl oạ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ácl oại sự kiện khác.

0x04-0x7f

Không áp dụng Dhông áp.

0x80-0xff

Không áp dụng Đưông áp dụngợc phân loại c.

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


323

TCVN xxxx :2016

properties()

num_properties

for (i=0; i<num_proper ties ; i++)

name

data

947.1.2

8

948

*

*

949

uimsbf

949.1.1

string() lstring()

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.

A.1 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:

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

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


dtid_error_status()

949.1.2

949.1.3

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.

324

TCVN xxxx : 2016

949.1.4

dtid_data_byte()

949.1.5

Dữ liệu được liên kết với ATR.

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


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


dtid_user_data() Một hoặc nhiều trường dữ liệu riêng.

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


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


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.

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

A.1.4 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à:

325

TCVN xxxx :2016command_id: CMD_CAPABILITIES_RESPONSE

ca_system_id: ca_system_id nhận được trong CAS_request_message ().


Bảng M.19 - Các loại dữ liệu bản tin trả lời các khả năng


dtid_error_status()

949.1.6

949.1.7

949.1.8

dtid_cas_information()

949.1.9

949.1.10

949.1.11

dtid_cicam_information()


949.1.12

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ợ

949.1.13

Khối dữ liệu đơn cung cấp thông tin về chính CICAM.

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



Bảng M.20 - Các loại dữ liệu bản tin History Get Request


dtid_history_request() Một hoặc nhiều mục xác định quá trình được yêu cầu.

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


Bảng M.21 - Các loại dữ liệu bản tin History Get Response


dtid_error_status()

949.1.14

949.1.15

949.1.16


326

TCVN xxxx : 2016


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.

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


Bảng M.22 - Các loại dữ liệu bản tin History Set Request


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.

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


Bảng M.23 - Các loại dữ liệu bản tin History Set Response


dtid_error_status()

949.1.17

949.1.18

949.1.19

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

A.1.1 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à:

327

TCVN xxxx :2016command_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

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


data_type (): Không

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


Bảng M.24 - Các loại dữ liệu bản tin Parental Level Get Response


dtid_error_status()

949.1.20

949.1.21

949.1.22

dtid_parental_level()


949.1.23

Thông tin mức cha mẹ hiện tại được cung cấp cho hệ thống.

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


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


dtid_parental_level() dtid_pin_code()

Mức cha mẹ mới được cung cấp cho hệ thống CA.

949.1.24

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.

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

328

TCVN xxxx : 2016ca_system_id: ca_system_id nhận được trong bản tin Parental Level Set Request.


Bảng M.26 - Các loại dữ liệu bản tin Parental Level Set Response


dtid_error_status()

949.1.25

949.1.26

949.1.27

949.1.28



949.1.29

Thông tin mức cha mẹ mớii được cung cấp cho hệ thống.

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



Bảng M.27 - Các loại dữ liệu bản tin yêu cầu kiểm tra PIN


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.

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


Bảng M.28 - Các loại dữ liệu bản tin trả lời kiểm tra PIN



A.1.3 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à:

329

TCVN xxxx :2016command_id: CMD_PIN_GET_REQUEST


data_type (): Dữ liệu được bỏ qua và phải là không.

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


Bảng M.29 - Các loại dữ liệu bản tin trả lời nhận PIN


dtid_error_status()

949.1.30

949.1.31

949.1.32

dtid_pin_information()


949.1.34

Thông tin mã PIN. Một hoặc nhiều mã PIN có thể được trả về.

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



Bảng M.30 - Các loại dữ liệu bản tin yêu cầu thiết lập PIN



dtid_pin_code()

Thông tin PIN được cập nhật phải chứa mã PIN hiện có.

949.1.36

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.

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

330

TCVN xxxx : 2016ca_system_id: ca_system_id nhận được trong bản tin yêu cầu thiết lập PIN.


Bảng M.31 - Các loại dữ liệu bản tin trả lời thiết lập PIN


dtid_error_status()

949.1.37

949.1.38

949.1.39

949.1.40



949.1.41

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.

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



Bảng M.32 - Các loại dữ liệu bản tin yêu cầu dữ liệu riêng



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


Bảng M.33 - Các loại dữ liệu bản tin trả lời dữ liệu riêng


dtid_error_status()

949.1.42

949.1.43

949.1.44

949.1.45

dtid_user_data()


949.1.46

Một hoặc nhiều trường dữ liệu riêng.

331

TCVN xxxx :2016A.1.1 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



Bảng M.34 - Các loại dữ liệu bản tin Product Get Request


dtid_product_request() Sản phẩm được truy vấn.

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


Bảng M.35 - Các loại dữ liệu bản tin Product Get Response


dtid_error_status()

949.1.47

949.1.48

949.1.49

dtid_product()


949.1.50

Dữ liệu sản phẩm, nhiều sản phẩn có thể được trả về trong một hoặc nhiều khối.

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



Bảng M.36 - Các loại dữ liệu bản tin nhận thông tin sản phẩm


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ẩn có thể được chứa trong một yêu cầu thông tin.

332

TCVN xxxx : 2016A.1.2 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.


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


dtid_error_status()

949.1.51

949.1.52

949.1.53

949.1.54

dtid_product_info()


949.1.55

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

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



Bảng M.38 - Các loại dữ liệu bản tin hủy bỏ mua


dtid_purchase () Nhận dạng mục để hủy.

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


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


dtid_error_status()

949.1.56

949.1.57

949.1.58


Thông tin việc mua.

333

TCVN xxxx :2016

dtid_purchase()

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



Bảng M.40 - Các loại dữ liệu bản tin yêu cầu thiết lập mua


dtid_purchase () Nhận dạng mục để mua.

A.1.2 Bản tin trả lời thiết lập mua

Trả lời bản tin yêu cầu thiết lập mua từ CICAM đưa ra chi tiết thông tin sản phẩm của sự kiện. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_PURCHASE_SET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu thiết lập mua.


Bảng M.41- Các loại dữ liệu bản tin trả lời thiết lập mua


dtid_error_status()

949.1.59

949.1.60

949.1.61

949.1.62

dtid_purchase()

949.1.63

dtid_product()


949.1.64

Dữ liệu việc mua.

949.1.65

Dữ liệu sản phẩm liên kết với việc mua.

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



Bảng M.42 - Các loại dữ liệu bản tin yêu cầu nạp tiền


334

TCVN xxxx : 2016

dtid_recharge () Thông tin yêu cầu nạp tiền.

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


Bảng M.43 - Các loại dữ liệu bản tin trả lời nạp tiền


dtid_error_status()

949.1.66

949.1.67

949.1.68

dtid_wallet()

dtid_recharge()


Dữ liệu ví tiền được cập nhật.

Chứa thông tin giao dịch ban đầu, bao gồm khoản tiền nạp.

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



Bảng M.44 - Các loại dữ liệu bản tin yêu cầu nhận khe cắm


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.

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


Bảng M.45 - Các loại dữ liệu bản tin trả lời nhận khe cắm


dtid_error_status()

949.1.69

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

335

TCVN xxxx :2016


949.1.70

949.1.71

949.1.72

dtid_slot()

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.

949.1.73

Thông tin khe cắm, có thể có nhiều khối nếu có nhiều khe cắm trong CICAM.

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



Bảng M.46 Các loại dữ liệu bản tin yêu cầu nhận thẻ thông minh


dtid_smartcard_request() Thẻ thông minh để truy vấn.

A.1.2 Bản tin trả lời nhận thẻ thông minh

Trả lời bản tin yêu cầu nhận thẻ thông minh từ CICAM đưa ra chi tiết thông tin thẻ thông minh của thẻ thông minh trong một khe cắm đã cho hay với một nhận dạng đã cho. Ngữ nghĩa dành cho cú pháp CAS_response_message () là:

command_id: CMD_SMARTCARD_GET_RESPONSE

ca_system_id: ca_system_id nhận được trong bản tin yêu cầu nhận thẻ thông minh.


Bảng M.47 Các loại dữ liệu bản tin trả lời nhận thẻ thông minh


dtid_error_status()

949.1.74

949.1.75

949.1.76

dtid_smartcard()


949.1.77

Một hoặc nhiều khối dữ liệu chứ thông tin thẻ thông minh.

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



336

TCVN xxxx : 2016Bả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


dtid_smartcard_request()

dtid_wallet_id()

949.1.79

dtid_user_data()

Thẻ thông minh để truy vấn.

949.1.81

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.

949.1.82

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.

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


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



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



Bảng M.50 - Các loại dữ liệu bản tin yêu cầu nhận ví tiền


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.

337

TCVN xxxx :2016A.1.3 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.


Bảng M.51 - Các loại dữ liệu bản tin trả lời nhận ví tiền


dtid_error_status()

949.1.83

949.1.84

949.1.85

949.1.86

dtid_wallet()


949.1.87

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.

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

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


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.


Bảng M.52 - Các loại dữ liệu bản tin sự kiện truy nhập


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.

338

TCVN xxxx : 2016A.1.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.


Bảng M.53: Các loại bản tin dữ liệu sự kiện tín dụng


dtid_credit_event()

949.1.88

949.1.89

949.1.90

dtid_wallet()

dtid_smartcard()

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.

949.1.92

Ví tiền được liên kết với sự thay đổi tín dụng.

949.1.93

Thẻ thông minh được liên kết với sự thay đổi tín dụng.

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


command_id: CMD_MESSAGE_EVENT



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


dtid_history_event()

949.1.94

949.1.95

dtid_history()

949.1.96

dtid_smartcard()

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.

949.1.97

Thông tin của bản tin.

949.1.98

Thẻ thông minh được liên kết với sự kiện bản tin này.

339

TCVN xxxx :2016A.1.1 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.


command_id: CMD_PIN_REQUEST_EVENT



Bảng M.55 - Các loại dữ liệu bản tin sự kiện yêu cầu PIN


dtid_pin_event()

949.1.99

949.1.100


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.

949.1.101

Thông tin PIN.

A.1.1 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ề.


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.


Bảng M.56 - Các loại dữ liệu bản tin sự kiện trả lời mã PIN


dtid_pin_information() Thông tin PIN. Một mã PIN hợp lệ phải được chứa trong trường pin_code.

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


Bảng M.57 - Các loại dữ liệu bản tin sự kiện dữ liệu riêng



340

TCVN xxxx : 2016A.1.3 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.


command_id: CMD_PRODUCT_EVENT



Bảng M.58 - Các loại dữ liệu bản tin sự kiện sản phẩm


dtid_product_event()

949.1.102

949.1.103

949.1.104

dtid_product()

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.

949.1.105

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.

A.1.1 Bản tin sự kiện quá trình mua

Một bản tin sự kiện từ CICAM khi có sự thay đổi của quá trình mua, thông báo này được gửi phải không đồng bộ bất cứ khi nào trạng thái của quá trình này thay đổi. Không có trả lời được trả về. Bản tin này chỉ được truyền khi thông báo được cho phép.


command_id: CMD_PURCHASE_HISTORY_EVENT



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

949.1.106

949.1.107

dtid_history()

949.1.108

dtid_smartcard()

Trạng thái quá trình mưa. 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.

949.1.109

Quá trình được liên kết với sự thay đổi quá trình mua này.

949.1.110

Thẻ thông minh được liên kết với sự kiện quá trình mua này.

341

TCVN xxxx :2016A.1.1 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



Bảng M.60: Các loại dữ liệu bản tin sự kiện nạp tiền


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.

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



Bảng M.61 - Các loại dữ liệu bản tin sự kiện khe cắm


dtid_slot_event() Trạng thái của khe cắm.

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



Bảng M.62 - Các loại dữ liệu bản tin sự kiện thẻ thông minh


dtid_smartcard_event()

949.1.111

Trạng thái của thẻ thông minh.

949.1.112

342

TCVN xxxx : 2016

dtid_smartcard() Thẻ thông minh được liên kết với sự kiện.

A.1 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:

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


dtid_access_event()

949.1.113

8

950

uimsbfaccess_status

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

343

TCVN xxxx :2016


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.

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

950.1.5

*

951

lstring()

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

A.1.1 Thông tin CAS

dtid_cas_information () 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ú Số bit Kiểu

344

TCVN xxxx : 2016

pháp

dtid_cas_information() 951.1.2

16

952

uimsbfca_system_id

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

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


dtid_cicam_information()

952.1.5

4

953

uimsbfslot_count

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

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

345

TCVN xxxx :2016revision: 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].

A.1.1 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() 953.1.5

8

954

uimsbfcredit_status




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


0x00 CREDIT_CHANGED Tín dụng của thẻ bị thay đổi.

0x01-0x7f

Không áp dụng Dự phòng.

0x80-0xff Không áp dụng Được người sử dụng xác định


object_id: Nhận dạng đối tượng CA tùy chọn liên quan đến sự kiện này.


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

346

TCVN xxxx : 2016

dtid_error_status()

error_code

message

954.1.5

8

*

955

uimsbf string()

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


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.


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.


347

TCVN xxxx :2016


100 GENERIC_ERROR Lỗi chưa xác định.


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.

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


dtid_history()

type

id

nid

cancelled

status

history_date

private_data

if (type == HISTORY_TYPE_PPV)

ppv_product_id

ppv_order_date

ppv_item_status

else if (type == HISTORY_TYPE_RECHARGE)

recharge_value

recharge_source

recharge_transaction_id

955.1.2

8

*

32

1

7

*

*

956

*

*

8

957

958

*

8

*

959

960

963

uimsbf

string()

uimsbf

bslbf

uimsbf

time()

lstring()

964

string()

time()

uimsbf

965

966

money()

967

string()

968

969

348

TCVN xxxx : 2016

else if (type == HISTORY_TYPE_MESSAGE)

message_subject

message_body

message_priority

message_date

else

properties

*

*

8

*

961

962

*

string()

lstring()

uimsbf

time()

970

971

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


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.


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


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- Không áp dụng Dự phòng.

349

TCVN xxxx :2016

0x3e

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


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.



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


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



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

350

TCVN xxxx : 2016message_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


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



message_date: Ngày khi bản tin này đã được lưu trữ ban đầu.

A.1.1 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() 971.1.2

8

972

uimsbfhistory_status




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


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


0x10 NEW_MESSAGE Bản tin mới đã tới.

351

TCVN xxxx :2016


0x01-0x7f



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.

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

request_type

if (request_type == ID_HISTORY)

history_id

else if (request_type == NID_HISTORY)

history_nid

private_data

972.1.5

4

4

973

*

974

32

975

*

976

bslbf

uimsbf

string()

uimsbf

string()

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

request_type: Các loại quá trình được yêu cầu theo quy định trong Bảng M.81:

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


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.

352

TCVN xxxx : 2016

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.

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

976.1.4

32

977

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.

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


dtid_object_identity()

identity

977.1.2

*

978

lstring()

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.

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

353

TCVN xxxx :2016


parental_level

978.1.2

*

979

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

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

979.1.2

*

980

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

A.1.1 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 PINn 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() 980.1.2

8

981

uimsbfpin_type




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.

354

TCVN xxxx : 2016object_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.

A.1.1 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() 981.1.5

*

982

string()id

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ả

355

TCVN xxxx :2016

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.

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


dtid_product()

product_type

id

name

description

xdescription

pw_start_time

pw_end_time

preview

cost

num_contained_products

for (i=0; i<num_products; i++)

contained_product_id

if (product_type == PPT)

ppt_locator

ppt_rating

ppt_slice_price

ppt_slice_duration

982.1.5

8

*

*

*

*

*

*

*

*

8

983

984

*

985

*

8

*

*

995

uimsbf

string()

string()

string()

lstring()

time()

time()

duration()

money()

uimsbf

996

997

string()

998

locator()

uimsbf

money()

duration()

356

TCVN xxxx : 2016


else if (product_type == PPE)

ppv_locator

ppv_rating

ppv_start_time

ppv_end_time

ppv_num_packages

for (i=0; i<ppv_num_packages; i++)

ppv_package

else if (product_type == SUB)

sub_start_time

sub_end_time

sub_num_services

for (i=0; i<sub_num_services; i++)

sub_service

private_data

986

987

*

8

*

*

8

988

*

989

990

*

*

16

991

992

*

993

994

*

999

1000

locator()

uimsbf

time()

time()

uimsbf

1001

string()

1002

1003

time()

time()

uimsbf

1004

1005

locator()

1006

1007

lstring()

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.

357

TCVN xxxx :2016id: 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.

358

TCVN xxxx : 2016A.1.1 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() 1007.1.2

8

1008

uimsbfproduct_status




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


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



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.


A.1.1 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() 1008.1.5

4

1009

bslbfpurchase_status

is_current_service 1 bslbf

359

TCVN xxxx :2016

reserved 3 bslbf

access_state 8 uimsbf

product_id * string()

private_data * lstring()

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


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


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ẩn đượ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.

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

360

TCVN xxxx : 2016


dtid_product_request()

reserved

request_qualifier

type

if (request_qualifier == PRODUCT_ID)

product_id

else if (request_qualifier == PRODUCT_LOCATOR)

locator

private_data

1009.1.6

3

2

3

1010

*

1011

*

1012

*

1013

bslbf uimsbf uimsbf

1014

string()

1014.1.1

locator()

1014 .1 .2

lstring()

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


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


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


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.

361

TCVN xxxx :2016A.1.1 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

product_id

cancelled

reserved

private_data

1014.1.3

*

* 1

7

*

1015

string()

string()

bslbf

bslbf lstring()

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.

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

reserved

request_type

phone

user

password

ip_address

port

if (request_type == CREDIT_CARD_MODE)

4

4

*

*

*

*

*

1016

1017

bslbf

uimsbf

string()

string()

string()

string()

string()

1019

1020

362

TCVN xxxx : 2016

surname

name

card_number

start_date

expiry_date

value

recharge_value

transaction

private_data

*

*

*

16

16

*

1018

*

*

*

string()

string()

string()

bslbf

bslbf

money()

1021

money()

lstring()

lstring()

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


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.

363

TCVN xxxx :2016gtransaction: 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.

A.1.1 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() 1021.1.2

8

1022

uimsbfrecharge_status



value * money()


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


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.


A.1.1 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_service_id()

service_locator

1022.1.5

*

1023

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.

A.1.1 Khe cắm

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

364

TCVN xxxx : 2016


dtid_slot()

slot_id

slot_status

1023.1.2

8

8

1024

uimsbf

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


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



A.1.1 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() 1024.1.2

8

1025

uimsbfslot_status

slot_id 8 uimsbf


365

TCVN xxxx :2016



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.



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


dtid_smartcard()

id

status

slot_id

expiry_date

id_number

version

provider_name

service_provider_name

user_data

num_pin_codes

for (i=0; i<num_pin_codes; i++)

pin_id

num_wallets

for (i=0; i<num_wallets; i++)

wallet_id

1025.1.5

* 8

8

*

*

*

*

*

* 8

1026

*

1027

8

1028

*

1029

*

*

*

1030

string()

uimsbf

uimsbf

time()

string()

string()

string()

string()

string()

uimsbf

1030.1.1

string()

1030.1.2

uimsbf

1030.1.3

string()

1030.1.4

string()

366

TCVN xxxx : 2016

current_wallet

additional_info

private_data

properties()

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


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ả

367

TCVN xxxx :2016


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.


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.

368

TCVN xxxx : 2016A.1.1 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() 1030.1.5

8

1031

uimsbfsmartcard_status




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.




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


dtid_smartcard_request()

reserved

request_qualifier

if (request_qualifier == SMARTCARD_ID)

smartcard_id

else if (request_qualifier == SMARTCARD_SLOT)

slot_id

private_data

1031.1.5

6

2

1032

*

1033

8

1034

*

1035

bslbf

uimsbf

1035.1.1

string()

1035.1.2

uimsbf

1035.1.3

string()

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

369

TCVN xxxx :2016request_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


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.


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.

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


dtid_user_data() byte_data

1035.1.4

*

1036

lstring()

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

A.1.1 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() 1036.1.2

8

1037

uimsbfproduct_type

id * string()

name * string()

balance * money()

expiry_date * time()

transaction_count 16

uimsbf

transaction_remain 8 uimsbf

370

TCVN xxxx : 2016

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ỉ rarằ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.

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

1037.1.5

*

1038

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.

A.1 Ánh xạ MHP API

Bảng M.115 cung cấp một danh sách MHP API và các lệnh CI 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() CMD_CAPABILITIES_REQUEST

371

TCVN xxxx :2016


getCARevision() getCAVersion() getSlots()

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() getMoreInfo() 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 getId() getPrivateData() CMD PRODUCT_GET_REQUEST

372

TCVN xxxx : 2016


getType() getName() getDescription()

getExtendedDescription() etPurchaseWindowStartTime() getPurchaseWindowEndTime() getContainedProducts() getPrice()

isFree() getPreviewTime()

PPVEvent getRating() getLocator() getPackages()

getStartTime() getEndTime() isFree() getType()

CMD PRODUCT_GET_REQUEST

PPTEvent getSlicePrice() getSliceDuration() getType()


PPVPackage isFree() getType() CMD PRODUCT_GET_REQUEST

Subscription getSubscriptionStart() getSubscriptionEnd() getServices()

isFree() getType()


request BuyRequest() CMD_PURCHASE_SET_REQUEST

request.CARequest cancel() CMD_PURCHASE_CANCEL_REQUEST

request.CARequest setPrivateData() CMD_PURCHASE_SET_REQUEST

request.CARequest isCancelled() getPrivateDate() CMD_PURCHASE_SET_REQUEST

HistoryRequest getHistoryLength() getItem() getItems() getPrivateData() isCancelled()

CMD_HISTORY_GET_REQUEST

HistoryRequest setItems() 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

373

TCVN xxxx :2016


HistoryUpdateResponseEv

HistoryUpdateResponseEvent()

CMD_HISTORY_SET_RESPONSE

ProductInfoRequest ProductInfoRequest() 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.OfferedProducts RetrieveOfferedProductsRequest()

CMP_PRODUCT_GET_REQUEST

OfferedProductsResponse

OfferedProductsResponseEvent() getProducts()

CMP_PRODUCT_GET_RESPONSE

374

TCVN xxxx : 2016

Phụ lục A

(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ủ CI 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ủ CI Plus.

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

A.1.1 CI Plus tin Descriptors

Các nhãn mô tả riêng được một thiết bị máy chủ CI 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 CI Plus chỉ được phân tích trong bối cảnh của giá trị quy định dữ liệu riêng CI Plus.

Bảng N.1 – Các nhãn mô tả riêng CI 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 CI 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ụ.

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

375

TCVN xxxx :2016Bả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

* 2nd 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 1st 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 CI Plus.

ciplus_service_descriptor

0xcc 2nd 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 CI Plus.

linkage_descriptor 0x4a 1st 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 1st Ob/Or Không áp dụng

Thông tin DVB-SSU với linkage_type 0x09 và 0x0A.

network_name_descriptor

0x40 1st 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 1st/2nd

Ob/Mr Không áp dụng

Giá trị của nhãn xác định dữ liệu riêng CI 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ácnh ãn mô tả riêng CI Plus.

image_icon_descriptor

0x7f/0x00 1st 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

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

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

A.1.2.2 linkage_descriptor

linkage_descriptor với thẻ 0x4a, được quy định trong ETSI EN 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

376

TCVN xxxx : 2016củ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ủ.

A.1.2.3 ciplus_service_descriptor

Nhãn mô tả dịch vụ CI 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 CI 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


ciplus_service_descriptor()

descriptor_tag

descriptor_length

service_id

service_type

visible_service_flag

selectable_service_flag

logical_channel_number

service_provider_name_length

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

char

1038.1.9

8

8

16

8

1

1

14

8

1039

8

1040

1042

uimsbf

uimsbf

uimsbf

uimsbf

bslbf

bslbf

uimsbf

uimsbf

1043

uimsbf

1043.1.1

377

TCVN xxxx :2016

service_name_length

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

char

8

1041

8

uimsbf

1043.1.2

uimsbf


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

378

TCVN xxxx : 2016A.1.1.1 ciplus_content_label_descriptor

Nhãn mô tả nhãn nội dung CI 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


ciplus_content_label_descriptor()

descriptor_tag

descriptor_length

content_byte_min

content_byte_max

ISO_639_language_code

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

label_char

1043.1.3

8

8

8

8

24

1044

8

1045

uimsbf

uimsbf

uimsbf

uimsbf

bslbf

1045.1.1

uimsbf


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

379

Hp4530, 11/12/14,

genre

TCVN xxxx :2016content_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.

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

A.1.1 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ủ CI 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 CI 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

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

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

380

TCVN xxxx : 2016running_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.

A.1.3 Cung cấp EIT

Hướng dẫn chương trình điện tử (EPG) của một máy chủ CI 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 CI Plus chứng 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.

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

Phần này mô tả hành vi của mạng CICAM (profile_type = 1)

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

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

381

TCVN xxxx :2016Cá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.

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

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

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

______________________________

382

Documents

TCVN TIÊU CHUẨN QUỐC GIAenglish.mic.gov.vn/.../Du-thao-TCVN-CI-Plus-TCVN--Final.docx · Web viewTCVN xxxx : 2016 do Viện Khoa học Kỹ thuật Bưu Điện biên soạn,