Telecommunication (Broadcasting And Cable)
Services Interconnection (Addressable Systems) (Fifth Amendment) Regulations,
2023
[14th September 2023]
In
exercise of the powers conferred by section 36, read with subclauses (ii),
(iii) and (iv) of clause (b) of sub-section (1) of section 11, of the Telecom
Regulatory Authority of India Act, 1997 (24 of 1997), read with notification of
the Central Government, in the Ministry of Communication and Information
Technology (Department of Telecommunications), No. 39, -
(a)
issued,
in exercise of the powers conferred upon the Central Government under clause
(d) of sub-section (1) of section 11 and proviso to clause (k) of sub-section
(1) of section 2 of the said Act, and
(b)
published
under notification No. S.O.44 (E) and 45 (E) dated the 9th January, 2004 in the
Gazette of India, Extraordinary, Part II, Section 3,- the Telecom Regulatory
Authority of India hereby makes the following regulations further to amend the
Telecommunication (Broadcasting and Cable) Services Interconnection
(Addressable Systems) Regulations, 2017 (1 of 2017), namely:-
Regulation - 1. Short title, extent, and commencement
(1)
These
regulations may be called the Telecommunication (Broadcasting and Cable)
Services Interconnection (Addressable Systems) (Fifth Amendment) Regulations,
2023 (4 of 2023).
(2)
These
regulations shall apply throughout the territory of India.
(3)
These
regulations shall come into force from the date of their publication in the
Official Gazette.
Provided
that for the existing systems, the provisions of these regulations shall apply
after three months from the date of their coming into force.
Regulation - 2.
In
regulation 10 of the Telecommunication (Broadcasting and Cable) Services
Interconnection (Addressable Systems) Regulations, 2017 (hereinafter referred
to as the "principal regulations"),-
(a)
in
sub-regulation (6), after the words "Schedule III", the words
"or the Schedule X or both, as the case may be" shall be inserted;
(b)
in
sub-regulation (7), for the words "Schedule III", the words
"Schedule III or the Schedule X or both, as the case may be" shall be
substituted;
(c)
in
proviso to sub-regulation (7), after the words "Schedule III", the
words "or the Schedule X or both, as the case may be" shall be
inserted.
Regulation - 3.
In
regulation 15 of the principal regulations,-
(a)
in
sub-regulation (2), for the words "Schedule III", the words
"Schedule III or the Schedule X or both, as the case may be" shall be
substituted;
(b)
in
third proviso to sub-regulation (2), after the words "Schedule III",
the words "or the Schedule X or both, as the case may be" shall be
inserted.
Regulation - 4.
In
Schedule II of the principal regulations,-
(a)
in
item 17, for the words "Schedule III", the words "Schedule III
or the Schedule X or both, as the case may be," shall be substituted;
(b)
in
declaration, for the words "Schedule III", the words "Schedule
III or the Schedule X or both, as the case may be," shall be substituted.
Regulation - 5.
After
Schedule IX to the principal regulations, the following schedule shall be
inserted, namely:-
"Schedule X
(Refer sub-regulation (6) of the
regulation 10, sub-regulation (7) of the regulation 10 and sub-regulation (2)
of the regulation 15)
Scope and Scheduling of Audit
(A)
Scope:
The annual Audit caused by distributor shall include the Audit to validate
compliance with this Schedule and the Subscription Audit, as provided for in
these regulations.
(B)
Scheduling:
The annual Audit as caused by distributor under regulation 15(1) shall be
scheduled in such a manner that there is a gap of at-least six months between
the audits of two consecutive calendar years. Further, there should not be a
gap of more than 18 months between audits of two consecutive calendar years.
Digital Rights Management (DRM) System Requirements The term DRM, herein,
refers to the management of the encryption systems for, inter-alia, providing
the functionality of CAS for the Internet Protocol Television (IPTV) service
provider under these regulations.
(C)
DRM
Requirements in so far as they relate to subscriber management systems (SMS)
for IPTV services:
Table 1
|
Sl. No.
|
Proposed DRM requirements for SMS
|
|
1.
|
There
shall not be any data mismatch between DRM and SMS. Maximum mismatch based on
subscription base may be allowed as mentioned below:
(4) Must
be less than 0.20% for subscriber base up to 100000 subs (0 to 200 for
subscriber base of up to 100000)
(5) Must
be less than 0.04% for subscriber base up to 1000000 subscribers (0 to 400
for subscriber base of up to 1000000)
(6) Must
be less than 0.01% for subscriber base above 10000000 subscribers (0 to 1000
for subscriber base of up to 10000000)
The data
between both the systems shall be reconciled on a monthly basis. The
reconciliation report shall be stored along with the system data for a
minimum of three (3) years or at least three audit cycles, or as per Schedule
III whichever is later.
|
|
2.
|
Password
Policy Creation for Users: SMS shall have a defined password policy,
with minimum length criteria and composition (upper and lower-case
characters, numeric, alphabets or special characters), forced password
changes or any other appropriate mechanisms or combinations thereof or
alternatively user account has to be locked/paired to the Mac Id of the set
top box (STB) /unique consumer subscription or the customer premises
equipment (CPE)/device.
|
|
3.
|
After-Sales
Service Support: The required software and hardware support should be
available to the distributor of the television channels‘ installations from
the SMS vendor‘s support teams located in India. The support should be such
as to ensure the SMS system with 99.99% uptime and availability. The systems
should have sufficient provisions for backup systems to ensure quality of
service and uptime
|
|
4.
|
All
activation and deactivation of STBs/unique consumer subscription shall be
done in such a way that SMS and DRM are always integrated and synchronised on
real time basis.
|
|
5.
|
Necessary
and sufficient methods shall be put in place so that each activation and
deactivation of STBs/unique consumer subscription is reflected in the reports
generated from the SMS integrated with the DRM and vice versa
|
|
6.
|
DRM and
SMS should be able to activate or deactivate services and/or STBs/unique
consumer subscription of the subscriber base of the distributor within 24
hours.
|
|
7.
|
The SMS
shall be independently capable of generating, recording, and maintaining
logs, for the period of at least immediately preceding three (3) consecutive
years, corresponding to each command executed in the SMS including but not
limited to activation and deactivation commands.
|
|
8.
|
The SMS
should be computerized and capable of recording all logs including
information and data concerning the subscribers such as:
(a) Unique
customer identification (ID)
(b)
Subscription contract number
(c) Name
of the subscriber
(d)
Billing address
(e)
Installation address
(f)
Landline telephone number
(g) Mobile
telephone number
(h) E-mail
address
(i)
Channels, bouquets and services subscribed
(j) Unique
STB number/unique consumer subscription ID attached to a specific unique MAC
ID.
(k) Unique
VC number or MAC ID.
|
|
9.
|
The SMS
should be capable of:
(a)
Viewing and printing of historical data in terms of the activations and the
deactivations of STBs/unique consumer subscription.
(b)
Locating each and every STB/unique consumer subscription and VC/MAC ID
installed at city and state level.
(c) Generating
historical data of changes in the subscriptions for each subscriber and the
corresponding source of requests made by the subscriber.
|
|
10.
|
The SMS
should be capable of generating reports, at any desired time including about:
(a) The
total number of registered subscribers.
(b) The
total number of active subscribers.
(c) The
total number of temporary suspended subscribers.
(d) The
total number of deactivated subscribers.
(e) List
of blacklisted STBs/unique consumer subscription in the system.
(f)
Channel and bouquet wise monthly subscription report in the prescribed
format.
(g) The
names of the channels forming part of each bouquet.
(h) The
total number of active subscribers subscribing to a particular channel or
bouquet at a given time.
(i) The
name of a-la carte channel and bouquet subscribed by a subscriber.
(j) The
ageing report for subscription of a particular channel or bouquet.
|
|
11.
|
The
distributor shall ensure that the SMS vendor has the technical capability in
India to maintain the systems on 24×7 basis throughout the year.
|
|
12.
|
DPO shall
declare the details of the DRM and the SMS deployed for distribution of
channels. In case of deployment of any additional DRM/SMS, the same shall be
notified prior to commissioning of the system, to the broadcasters by the
distributor.
|
|
13.
|
If there
is active infrastructure sharing (as and when permitted by MIB) then, DPO
shall declare the sharing of the DRM and the SMS deployed for distribution of
channels. In case of deployment of any additional DRM/SMS, the same should be
notified to the broadcasters by the distributor.
|
|
14.
|
SMS shall
have a provision to generate synchronization report, with date and time, with
the minimum fields as listed below:
(a)
STB/unique consumer subscription Number (or in case of card-less system, chip
ID or MAC ID number of the STB)
(b)
Product Code pertaining to a-la-carte channels and bouquets available on the
platform
(c) Start
Date of entitlement
(d) End
Date of entitlement
(e) Status
of STB/unique consumer subscription (active/Inactive)
|
|
15
|
The file
output of DRM shall be processed by SMS system to compare and generate a 100%
match or mismatch error report.
|
|
16.
|
Channel/Bouquet
management: SMS shall, in synchronisation with DRM on real time basis,
support the following essential requirements:
(a) Create
and manage relevant product ID for all channels and bouquets along with the
relevant details such as name, tariff, broadcaster, or DPO bouquet, etc.
(b) Manage
changes in the channel/bouquet, as may be required, from time to time.
(c) Link
the Products IDs for a-la-carte channels and bouquets (Single and Bulk)
created in DRM with the product information being managed in SMS, for smooth
working of SMS and DRM integration.
(d)
Management of historical Data of Product name, i.e., Broadcasters (name),
maximum retail price (MRP), distributor retail price (DRP).
|
|
17
|
Network
Capacity Fee (NCF) Policy Creation: SMS shall support all NCF related requirements
mandated by the applicable tariff order.
|
|
18.
|
Bill/Invoice
Generation:
SMS shall be capable of generating proper subscriber bill/invoice with
explicit details of NCF charges, pay channels charges (with clear itemized
details of à -la-carte channel cost and bouquet costs), rental charges
for STB/unique consumer subscription (if any), other applicable charges,
including Goods and Services Tax (GST).
|
|
19.
|
Management
of Logs:
(a) SMS
shall have the facility to provide user detail logs with the ID of users on
each login event.
(b) SMS
shall have the provision of generating the user activity log report to enable
tracking users‘ work history. It shall not be allowed to delete the records
from the log.
(c) All
logs shall be stamped with date and time and the system shall not allow
altering or modifying any logs.
(d) The
logs shall be maintained for a period as specified in Schedule III or at
least three audit cycles, whichever is later.
(e)
Channel subscription report: SMS shall be able to provide broadcaster wise
total counts of monthly subscribers of channels including both a la carte and
bouquet subscriptions as per format that may be prescribed by TRAI.
(f) DRM
and SMS should be running on separate and independent servers.
|
|
20.
|
SMS
Database and tables:
(a) There
shall not be any active unique subscriber outside the database tables
declared by the Vendor
(b) SMS
shall not provide an option to split SMS database or for creation of more
than one instance.
(c) SMS
shall have the provision to enable or disable channel (a-la-carte channel or
bouquet of channels) selection by subscribers either through website or an
application through interface provided by the distributor platform operator.
(d) SMS
shall be capable of capturing the following information required for audit or
otherwise:
i. Bouquet
a la carte status change history
ii.
Bouquet composition change history
iii.
Change in status of connection (primary to secondary and vice versa)
|
|
21.
|
SMS shall
be accessed through a Firewall
|
|
22.
|
STB/unique
consumer subscription and MAC ID shall be paired from the SMS to ensure
security of channel (applicable for DRM with pairing facility).
|
|
23.
|
The SMS
shall be capable of individually addressing subscribers, for the purpose of
generating the reports, on channel by channel and STB/unique consumer
subscription by STB/unique consumer subscription basis.
|
|
24.
|
SMS should
have a facility to carry out monthly reconciliations of channels/a-la-carte
and bouquet (with their respective ID created in SMS with DRM) and the
variance report should be available from the DRM and SMS logs and made
available during audits.
|
|
25.
|
SMS should
have a provision of generating the following reports pertaining to STB/unique
consumer subscription/MAC ID.:
(a) White
list of STB/unique consumer subscription /MAC ID along with active/inactive
status
(b) Faulty
STB/unique consumer subscription/MAC ID – repairable and beyond repairable
(c)
Warehouse fresh stock
(d) In
stock at local cable operator (LCO) end
(e)
Blacklist
(f)
Deployed with activation status
(g) Testing/demonstration
STB/unique consumer subscription /MAC ID with location
|
|
26.
|
Audit-related
requirements:
SMS should
have the capability to capture below-mentioned information that may be
required for audit and otherwise:
(a)
Subscriber related:
(i)
Subscriber contact details change history
(ii)
Connection count history
(iii)
Transition of connection between Disconnected/Active/Temporary Disconnected
(iv)
Subscription change history
(b)
Product (Bouquet/a-la-carte channel) related:
(i)
Broadcaster à -la-carte relation
(ii)
Bouquet name change history
(iii) a la
carte name change history
(iv)
Bouquet/a-la-carte channel rate change history
(c)
STB/unique consumer subscription related:
(i) Change
in location history
(ii)
Change in status (Active/Damaged/Repaired/Replaced)
|
|
27.
|
User
Authentication:
SMS should have the capability to authenticate its subscribers through
registered mobile number (RMN) through one-time password (OTP) system
|
|
28.
|
SMS should
have the provision to support the following additional requirements:
(a) List
of à -la-carte channels and bouquets, digital headend (DHE): Provision
to support/ SubHeadend-wise list of à -la-carte channels and bouquets,
in sync with the list available in DRM.
(b)
Product (Ã -la-carte channels and bouquets)-wise Renewal and Reversal
setting for the Subscriber Account: Provision to allow renewal of a product
to a subscriber after the expiry date of a product, and provision to
auto-calculate and refund the amount to a subscriber if he discontinues a
product midterm. These requirements may be configurable on selective
products, as required by the DPOs as per their business plans.
(c)
Product (Ã -la-carte channels and bouquets)-wise Reversal setting for
LCO Account:
Provision
to calculate and refund the amount due to LCO, if he or the subscriber
discontinues a product midterm. Product (Ã -la-carte channels and
bouquets) Tenure-wise LCO and Subscriber Discount Scheme/Free Days Scheme:
Provision to create Discount Scheme and Free-day scheme for LCO and
Subscriber, based on the duration (Tenure) of the product subscription.
(d)
Calendar/Activity Scheduling: Provision to auto-schedule activities like
STB/unique consumer subscription activation/deactivation, Ã -la-carte
channels and bouquets addition/removal, channel/bouquet composition
modification, etc.
(e) Bulk
Channel/Bouquet Management: Provision to perform bulk activity of
à -la-carte channels and bouquets addition and removal on all or a
designated group of STBs/unique consumer subscription.
(f)
Token-number-based reports: Provision to download multiple generated reports
with the help of token number, such as audit reports with different
intervals.
(g)
Third-Party Integration: Provision to support integration with relevant
third-party systems, such as, payment gateway integrations, interactive voice
response (IVR) Integrations, SMS Gateway Integrations, etc.
(h) Bill
payment and reconciliation feature: Provision for bill payment and
reconciliation (in case a DPO is running service in post-paid mode).
(i)
Generation of Reports:
Provision
to generate the following reports for operational purpose:
(i) All,
selective and single boxes‘ current status with their first-time activation
date.
(ii) Total
number of à -la-carte channels and bouquets and STB/unique consumer
subscription expiring detail till given future date on the dashboard,
according to the permission.
(iii)
Today‘s fresh activation count, de-activation count, re-activation count,
à -la-carte channels and bouquets addition/ removal count on dashboard,
according to the permission.
(iv) Total
active and inactive subscriber‘s details with multiple criteria (network-wise,
à lacarte channels and bouquets-wise, state-city wise and
broadcaster-wise).
|
|
29.
|
It shall
be mandatory for SMS to have backup servers and logs of all activities
carried out in main server shall be concurrently copied into the backup
servers, in an automated manner without any manual intervention.
Provided that a log of all such instances shall be maintained along with date
and time stamp, where the backup server has been used as the main server:
Provided further that the main and backup server shall always be in sync with
regard all data, such as subscription data, STB/unique consumer subscription
UA/MAC ID details, entitlement level information, etc.
|
(D)
DRM
Requirements for conditional access by subscribers and encryption for IPTV services
Table 2
|
Sl. No.
|
Proposed DRM Requirements for
conditional access by subscribers and encryption
|
|
1.
|
DPO shall
ensure that the current version of the DRM in use do not have any history of
hacking. A written declaration from the DRM vendor shall be required to be
furnished on an annual basis as compliance of this requirement.
|
|
2.
|
DRM shall
ensure all logs are un-editable, stamped with date and time of all
transactions (all activations, deactivation, channel authorization/assignment
and un-authorization / de-assignments and change in MAC ID/STB/unique
consumer subscription). The DRM shall not allow altering or modification of
any logs. There shall be no facility for the distributor/users to purge logs.
|
|
3.
|
DRM
deployed do not have facility to activate and deactivate a Set Top Box (STB)
/unique consumer subscription directly from the Graphical User Interface
(GUI) terminal of DRM. All activation and deactivation of STBs/unique
consumer subscription shall be done with the commands of the SMS (provided
that such feature may be available only for specific testing. The command or
access for such feature may be available with the highest system
administration password. In all such cases a separate log file of such
commands has to be maintained) integrated with DRM. The DRM shall be
integrated with the SMS in a manner that ensures security of the channel.
|
|
4.
|
The SMS
and the DRM should be integrated in such manner that activation and
deactivation of STB/unique consumer subscription happen simultaneously in
both the systems.
Explanation: Necessary and sufficient methods shall be put in place so that
each activation and deactivation of STBs/unique consumer subscriptions is
reflected in the reports generated from the DRM.
|
|
5.
|
DRM deployed
should be able to support two-way networks only.
|
|
6.
|
The DRM
deployed should be able to support both carded as well as card-less
STBs/unique consumer subscription for any provisioning.
|
|
7.
|
The DRM
deployed should be able to generate, record, maintain independent reports and
logs for verification purpose during audits corresponding to each command
executed in the DRM issued by the SMS integrated with the DRM for last three
(3) years minimum. The reports must have date and time stamp. Proposed
reports should include:
(a) Unique
active STB/unique consumer subscription count as well as MAC ID wise on any
desirable date
(b) Unique
bouquet/channel active for a specific STB/unique consumer subscription on any
desirable date
(c) MAC
ID/User ID wise activation-deactivation report for service requests
(d) Any
alteration in bouquet and/or channels configured in DRM
(e)
Blacklist STB/unique consumer subscription report (desirable not mandatory
feature)
(f)
Product code pertaining to channels/ bouquets available on the platform
(g)
Channel/bouquet authorization/assignment to STB/unique consumer subscription
along with start date and end date of entitlement
(h)
STB/unique consumer subscription -VC pairing / de-pairing or User id- Mac-id
Pairing / depairing (if applicable) in SMS/DRM
(i)
STB/unique consumer subscription activation / de-activation
(j)
Channels assignment to STB/unique consumer subscription
(k) Report
of the activations or the deactivations of a particular channel for a given
period
(l) The
total number of registered subscribers
(m) The
total number of active subscribers
(n) The
total number of temporary suspended subscribers
(o) The
total number of deactivated subscribers
(p) List
of blacklisted STBs/unique consumer subscription in the DRM (desirable not
mandatory feature)
(q)
Channel and bouquet wise monthly subscription report in the prescribed
format.
(r) The
names of the channels forming part of each bouquet
(s) The
total number of active subscribers subscribing to a particular channel or
bouquet at a given time
(t) The
name of a-la carte channel and bouquet subscribed by a subscriber
(u) The
ageing report for subscription of a particular channel or bouquet
|
|
8.
|
DRM
deployed should be able to tag and blacklist the STB/unique consumer
subscription in case of any piracy.
|
|
9.
|
DRM
deployed should have the technical capability in India to maintain the
systems on 24x7 basis throughout the year.
|
|
10.
|
The DRM
and SMS should be integrated in such manner that upon deactivation of any
subscriber from the SMS, all program/services shall be denied to that
subscriber.
|
|
11.
|
The DRM
should be capable of generating, recording and preserving unedited data /
logs for at least three consecutive years for each command executed through
the DRM, including logs of each command of the SMS integrated with the DRM.
|
|
12.
|
DRM
deployed should be capable to support both software base as well as hardware
base security.
|
|
13.
|
DRM shall
be capable of adding/modifying channels/bouquets as may be required on real
time basis in line with the activity performed in SMS.
|
|
14.
|
DRM should
be so configured for specific type of STB/unique consumer subscription, that
are procured and configured by the DPO. The DRM should not enable
working/operation of any other type/brand/make of STB/unique consumer
subscription, in the network.
|
|
15.
|
When
infrastructure sharing (as and when permitted by MIB) is available, in such
cases DRM shall be capable to support multiple DPOs.
|
|
16.
|
DRM should
support content protection.
|
|
17.
|
DRM should
support key rotation, i.e., periodic changing of security keys
|
|
18.
|
In case
DPO has deployed hybrid STBs (hybrid STB for the purpose of this regulation
means a STB that uses multiple methods of receiving transmission signals with
video and audio content, however in a single instance such STB provides only
one type of service), DRM shall ensure that the over-the-top (OTT) App and
any browser does not get access to the linear television channels offered by
the DPO from its own system, and similarly, DRM for IPTV service should not
get access to channels delivered through OTT platform. Provided that, all the
mandatory requirements for DRM shall be complied by hybrid STBs.
|
|
19.
|
There
shall not be any active unique subscriber outside the database tables.
Further, there shall not be an option to split DRM database for creation of
more than one instance by a DPO or a vendor.
|
|
20.
|
It must
support the following options with reference to uploading of unique access
(UA)/MAC ID details in DRM database:
(a) A
secure un-editable file of MAC ID details, as purchased by the distributor,
to be uploaded by the DRM vendor on the DRM server directly,
(b) If it
is uploaded in any other form, UA/MAC ID in DRM database shall be captured in
logs,
(c)
Further, DRM shall support an automated, application programming interface
(API)-based mechanism to populate such UA/MAC ID details in the SMS, without
any manual intervention.
|
|
21.
|
It shall
be mandatory to have backup servers and logs of all activities carried out in
main server shall be concurrently copied into the backup servers:
Provided that a log of all such instances shall be maintained along with date
and time stamp, where the backup server has been used as the main server:
Provided
further that the main and backup server shall always be in sync with regard
all data, such as subscription data, STB/unique consumer subscription UA/MAC
ID details, entitlement level information, etc
|
|
22.
|
DRM and
SMS shall ensure that the access to database is available to authorized users
only, and in
"read only" mode only. Further, the database audit trail shall be
permanently enabled.
Explanation: Database
here refers to the database where data and log of all activities related to
STB/unique consumer subscription activation, deactivation, subscription data,
STB/unique consumer subscription UA/MAC ID details, entitlement level
information, etc., is being stored.
|
|
23.
|
Provision
of à -la-carte channels or bouquet:
(a) DRM
(and SMS) shall be able to handle all the channels, made available on a
platform, in à la carte mode.
(b) DRM
(and SMS) shall have the capability to handle such number of broadcaster/DPO
bouquets, as required by the DPO.
|
|
24.
|
DRM and
SMS applications, along with their respective databases, shall be stored in
such a way that they can be separately identified.
|
|
25.
|
DRM shall
have a provision to export the database/report for reconciliation with the
SMS database. Further, there shall be a provision of reconciliation through
secure APIs/secure scripts.
|
|
26.
|
There
shall be unique license key required for viewing, the encryption period for a
specific key should be configurable to change at periodic interval in DRM
deployed by DPO.
|
|
27.
|
For every change
in channels, fresh license keys should be issued by the DRM. License keys
issued by DRM should be secure and encrypted. DRM must ensure that the
authorization keys are not received by the STB/unique consumer subscription
from any other source other than the one specified by the IPTV system.
|
|
28.
|
DRM
servers should comply with extant Rules and Regulations including relevant
clause under extant provisions (if any) relating to data localisation, data
security and privacy. It should not be allowed to connect main DRM server to
some other location (India or other country) with some proxy or another
server to integrate with SMS and DPO system.
|
|
29.
|
IPTV
service delivery may conform to multicast and/or unicast mode. The system
configuration should ensure that every television channel is available to
every customer on selection to view, irrespective of the mode of delivery or
the number of viewers seeking such channel at any point of time. STBs/unique
consumer subscription with facilities for recording programs shall have a
copy protection system (i.e., a feature which prevents reproduction of
content and/or unauthorized copying and distribution of content) and such
recorded content should not be transferrable to any other device or delivered
to any other network in any manner whatsoever.
|
|
30.
|
IPTV
system should not be allowed to deliver linear content to any other device
except STB/unique consumer subscription which has been transparentlisted in DRM.
|
|
31.
|
The DRM
should have following features:
(a) It
should restrict user to editing.
(b) It
should restrict user from sharing or forwarding or mirroring the content from
the STB/unique consumer subscription.
(c) It
should disallow user to take screen shots or screen grabs or
screen-recording, if technically feasible.
(d) It
should lock access to authorized STBs/unique consumer subscriptions only.
(e) It
should have Geo blocking feature.
(f) It
should be able to set expiry date to recorded content at STB/unique consumer
subscription end based on various policies.
|
|
32.
|
The DRM
should have the capability of being upgraded over-the-air (OTA) so that the
connected STBs/unique consumer subscription always have the most upgraded
version of the DRM.
|
|
33.
|
The DPO
shall ensure that the DRM is up to date by installing necessary patches,
error corrections, additions, version releases, etc. so as to ensure
protection of channels and content at all times
|
|
34.
|
No such
functionality should be added to or removed from the DRM which compromises
security of channels. DPO shall be responsible for encryption of channels‘
signals before their delivery through its IPTV platform using DRM hybrid
STBs/unique consumer subscription. All costs / expenses (by whatever name
called) that are required to be incurred or become payable for such
upgradation and for delivery/distribution of multi channel television
programmes to subscribers shall be borne solely by such DPO. The DPO shall
employ all reasonable security systems and procedures to prevent any loss,
theft, piracy, un-authorized use, reception or copying of channels or any
part thereof and shall notify broadcasters as soon as practicable after it
becomes aware that such an event has occurred
|
|
35.
|
The DRM
should not in any way interfere with / invalidate fingerprinting.
|
|
36.
|
DPO shall
promptly, and at it sole cost and expense, correct any issues with the DRM
(such as bugs, defects, omissions or the like) that prevents subscribers from
accessing the DRM hybrid STBs/unique consumer subscription or channels
through the DRM hybrid STBs/unique consumer subscription.
|
|
37.
|
DPO shall
provide broadcasters with video and audio codecs supported by the DRM hybrid
STBs/unique consumer subscription. The DPO shall ensure that no such
changes/modifications are made to such codecs parameters that will require
broadcasters to incur any expense for delivery of channels / content that are
free from viewer discernible problems (including, without limitation, video
with no audio, audio with no video or significant signal distortion
|
|
38.
|
DRM should
ensure that the hybrid STBs/unique consumer subscription are verifiably
located within India by reference to internet protocol address and service
address. DRM must ensure and lock the viewership to single device by single
STB/unique consumer subscription or any device by ensuring MAC ID based
authentication. The DRM must use industry-standard means (including
IP-address look-up technology with screening and blocking of proxies
(including anonymizing and spoofed proxies)) to prevent delivery of channels
to IP addresses outside of India or to proxies.
|
|
39.
|
DRM should
ensure that television channels are accessible on STBs/unique consumer
subscription of only such subscribers who are then-current, valid subscribers
of the DPO, and such confirmation must take place prior to the DRM delivering
(or authorizing the delivery of) television channel to the STBs/unique
consumer subscription of such subscribers.
|
|
40.
|
Upon
deactivation of any subscriber from the SMS, the DRM shall restrict delivery
of all programme/services to that subscriber.
|
|
41.
|
The DRM
should not have any feature to insert any content (including advertisement,
banner on portion of screen, etc) by itself. However, ticker messages for
consumer information as regards their services from DPO shall be permitted.
|
|
42.
|
The DRM
should not mask/remove any copyright, trademark or any other proprietary
information on the channels at the time of their delivery.
|
The
service providers shall ensure that they seek provisioning of after sales
services and support through a local entity so as to inter-alia provide quick
resolution to any technical and piracy related issues, from DRM equipment
supplier, while procuring DRM equipment.
(E)
DRM
Requirements in so far as they relate to fingerprinting for IPTV services
Table 3
|
Sl. No
|
Fingerprinting requirements under
DRM
|
|
1.
|
The DPO
shall ensure that it has systems, processes and controls in place to run
fingerprinting at regular intervals
|
|
2.
|
The
STB/unique consumer subscription should support both visible and covert types
of finger printing.
|
|
3.
|
The
fingerprinting should not get invalidated by use of any device or software.
|
|
4.
|
The
fingerprinting should not be removable by pressing any key on the remote of
STB/unique consumer subscription.
|
|
5.
|
The finger
printing should be on the topmost layer of the video.
|
|
6.
|
The finger
printing should be such that it can identify the unique STB/unique consumer
subscription number or the unique VC number or the MAC ID.
|
|
7.
|
The finger
printing should appear on the screens in all scenarios, such as menu,
Electronic Programme Guide (EPG), settings, blank screen, and games etc.
|
|
8.
|
The
location, font color and background color of fingerprint should be changeable
from head end and should be random on the viewing device.
|
|
9.
|
The finger
printing should be able to give the numbers of characters as to identify the
unique STB/unique consumer subscription and/or the MAC ID.
|
|
10.
|
The finger
printing should be possible on global as well as on the individual STB/unique
consumer subscription basis.
|
|
11.
|
The overt
fingerprinting/watermarking should be displayed by the DPO without any
alteration with regard to the time, location, duration and frequency.
|
|
12.
|
The DRM deployed
should be able to generate fingerprinting/watermarking both global
fingerprinting as well as targeted channel fingerprinting/watermarking.
|
|
13.
|
The DRM
shall support and enable forensic watermarking at STB/unique consumer
subscription level.
|
|
14.
|
The DRM
shall have the capability to run fingerprinting with at least one
fingerprinting every ten
(10) minutes on a 24x7x365 basis. DRM should have a feature to publish report
of fingerprinting schedule for defined interval. The DPO shall make such
report available to broadcaster on request.
|
(F)
DRM
Requirements in so far as they relate to STBs/unique consumer subscription
Table 4
|
Sl. No.
|
STB/unique consumer
subscription Requirements
for DRM for IPTV services
|
|
1.
|
All
STBs/unique consumer subscription should have a DRM content protection.
|
|
2.
|
The
STB/unique consumer subscription deployed should be
capable to support content decryption, decoding and DRM license evaluation.
|
|
3.
|
The
STB/unique consumer subscription should be capable of displaying
fingerprinting inserted from Headend through DRM/SMS. The STB/unique consumer
subscription should support both targeted channel fingerprinting as well as
all global fingerprinting.
|
|
4.
|
The
STB/unique consumer subscription should be individually addressable from the
Head-end.
|
|
5.
|
The
STB/unique consumer subscription should be able to receive messages from the
Head-end.
|
|
6.
|
The
messaging character length should be minimal of upto120 characters.
|
|
7.
|
There
should be provision for global messaging, group messaging and the individual
STB/unique consumer subscription messaging.
|
|
8.
|
The
STB/unique consumer subscription must be compliant to the applicable Bureau
of Indian Standards
|
|
9.
|
The
STBs/unique consumer subscription should be addressable over the air to
facilitate OTA software upgrade.
|
|
10.
|
The
STBs/unique consumer subscription with
facilities for recording the programs shall have international standard copy
protection system
|
|
11.
|
The
STB/unique consumer subscription should have a provision that fingerprinting
is never disabled.
|
|
12.
|
The
watermarking network logo for all pay channels shall be inserted at encoder
end only.
|
|
13.
|
DRM/SMS
deployed should be able to send scroll messaging which should be only
available in the lower part of the screen.
|
|
14.
|
DRM
deployed should be able to geo tag STB/unique consumer subscription deployed
in the network for security.
|
|
15.
|
STB/unique
consumer subscription should take all commands
directly from DRM not from any intermediate servers.
|
|
16.
|
STB/unique
consumer subscription while using IPTV infrastructure should not have feature
to download (direct or side download) any 3rd party App/APK and should not
have access to any browser.
|
|
17.
|
STB/unique
consumer subscription should not be able to access the authorization keys
from any other source except from the IPTV system through the IPTV closed
network. DRM must ensure that the authorization keys are not received by the
STB/unique consumer subscription from any other source other than the one
specified by the IPTV system
|
|
18.
|
No play
store should be accessible for enabling download, etc. when STB/unique
consumer subscription, is functioning in the IPTV network.
|
|
19.
|
STB/unique
consumer subscription should have copy protection.
|
|
20.
|
DPO system
should have capability to maintain un-editable logs of all activity and
configurations including download or upgrade of IPTV services App (if any) at
STB/unique consumer subscription end
|
|
21.
|
The DRM
should not allow delivering linear TV channels on Internet. The delivery of
multi channel television programmes should remain in a closed network within
the device.
|
|
22.
|
The
STB/unique consumer subscription should have forced messaging capability
including forced finger printing display.
|
|
23
|
The DRM
hybrid STBs/unique consumer subscription should be tested for the following
prior to their seeding in the subscribers‘ premises:
(a) System
down testing
(b) Error
messaging
(c)
Negative user journey testing
(d) Device
variance testing
(e)
Destructive testing
(f)
Application monitoring testing
(g) In-app
monitoring testing
|