IPTV System Design
BLANKOM Engineering Guide Series
GUIDE 05 / 12
PAY-TV · CI/CAM · DESCRAMBLING · RE-ENCODING
Plan Pay-TV Integration:
CAMs, Descrambling and Re-encoding
Start with the content provider’s approved access method. Decide whether protected services will be decrypted in the room, descrambled in the headend with professional CAMs, or received through operator set-top boxes and re-encoded. Then size the interfaces, simultaneous services and downstream protection around that approved path.
01 · DEFINE THE PAY-TV BOUNDARY
Protected content changes both the commercial and technical architecture
The source guide starts with the pay-TV operator’s business model: protected content remains under contractual control, and hospitality or institutional distribution normally requires an operator-approved arrangement rather than a consumer subscription being treated as a headend licence.[1, pp. 10–11]
For system design, this means that the access route is an input to the engineering process. Do not select a receiver, CI slot count or encoder first and then ask whether the provider will support it. Establish what the operator permits and supplies, then build the headend around that path.
02 · CHOOSE THE ACCESS PATH
Three practical ways to integrate protected services
| Path | What happens | What must be confirmed |
|---|---|---|
| A · Decryption in the room | The operator’s own or certified STB/TV access method remains at each endpoint. | Endpoint quantity, subscription model, room cabling, user experience and whether the operator’s equipment is mandatory. |
| B · Descrambling in the headend | A professional multi-service decryption CAM is used in a compatible headend CI slot, subject to operator approval. | Operator-supplied CAM/smart card, permitted simultaneous services, receiver/CAM compatibility, CI capacity and contractual redistribution conditions. |
| C · Operator STB + re-encoding | Where headend CAM access is not available, an authorised operator receiver/STB decrypts a service and its output is encoded again for the internal IPTV system. | Number of simultaneous services, approved output path, physical A/V interface, output format and the encoder resources required for every selected service. |
The source guide explicitly identifies room decryption and professional headend CAMs, and states that if the operator does not provide an MSD CAM, decryption with operator set-top boxes or re-encoding their outputs remains an alternative path.[1, pp. 10–11]
03 · HEADEND DESCRAMBLING
Use professional CAMs only within a verified operator-approved design
Riedel’s guide distinguishes consumer CI+ modules from professional headend multi-service decryption CAMs (MSD CAMs). In the source architecture, consumer CI+ remains a room/consumer function, while the professional headend path uses an MSD CAM in a CI slot and produces multiple IP services.[1, pp. 10–11]
Figure 1. Consumer-room and professional-headend access paths, reproduced from Figure 4.2, IPTV Headend Planning Guide, 2nd edition (2026), p. 11. The source figure illustrates the architectural distinction; current CAM capacity and compatibility must be confirmed for the selected operator and equipment.
Capacity must be stated as a project requirement
The source uses “multi-service” to distinguish professional CAMs from consumer use, but it does not provide a universal service count for every operator/CAM combination. Record the exact encrypted services that must be available simultaneously and obtain the supported CAM/service capacity from the relevant provider and equipment documentation.
04 · KEEP ACCESS AT THE ENDPOINT
Room decryption can preserve the operator’s subscriber model
The source guide describes pay-TV operators as commonly supplying their own or certified receiving equipment with embedded decryption or consumer CI+ access. In that architecture, the operator retains control per subscriber or endpoint rather than releasing clear services at the headend.[1, pp. 10–11]
For an IPTV project, this may simplify the content-rights boundary but creates a different system: room equipment, subscription handling and endpoint operation become part of the project. It is therefore not a drop-in substitute for central headend descrambling.
ADVANTAGE
Operator control stays at the endpoint
The protected service remains within the access method approved by the operator. This can be appropriate when central descrambling is not offered.
DESIGN CONSEQUENCE
Every room becomes part of the access system
Confirm device quantity, cabling, installation, remote-control behaviour, subscription logistics and how the operator equipment coexists with the rest of the television system.
05 · WHEN CAM ACCESS IS NOT AVAILABLE
Re-encoding an authorised receiver output is a separate signal path
The source guide states that when the operator does not provide an MSD CAM, one remaining route is to decrypt with the operator’s set-top box and re-encode its output in the headend.[1, p. 11] This is not the same as DVB service demultiplexing: the protected service is first decoded by an authorised receiver and then enters a new encoding stage.
-
List the protected services required simultaneously
Every simultaneously needed service needs an approved access path. Do not size this route from the total package size if only a defined subset is required.
-
Confirm the operator receiver and its usable output
Record the exact STB/receiver, the approved output route and the physical A/V interface available to the project. Treat any unresolved content-protection condition as “to be confirmed”.
-
Specify the encoder input and output requirement
Define the required input interface, video/audio format, intended IPTV output and the number of simultaneous encoder channels. These are project inputs; they are not inferred from the pay-TV service name.
-
Document the operational consequence
A receiver-plus-encoder path adds equipment and configuration to each protected service path. Include restart behaviour, channel locking, monitoring and maintenance responsibility in the design review.
06 · KEEP PROTECTION REQUIREMENTS SEPARATE
Descrambling does not answer the downstream security question
Chapter 10 of the source asks separately whether re-encryption is required after reception and processing. That is an important boundary: obtaining clear content at one point in the system does not establish what protection the provider requires for the downstream IPTV distribution.[1, p. 30]
| Requirement | Question to answer | Do not assume |
|---|---|---|
| Reception | Which satellite/transponder/service carries the protected content? | That an encrypted service can be handled by every receiver. |
| Conditional access | Where and with which provider-approved method is the service decrypted? | That consumer CI+, professional CI/CAM and embedded STB access are interchangeable. |
| Service capacity | How many protected services must be available simultaneously? | A universal CAM service count. |
| Re-encoding | If an authorised receiver output is used, what interface and encoder capacity are required? | That receiver output or re-encoding is permitted or technically identical across operators. |
| Downstream protection | Does the provider require re-encryption or another protected delivery method inside the IPTV network? | That successful descrambling removes later protection obligations. |
07 · REVIEW BEFORE MODEL SELECTION
Pay-TV integration checklist
- Pay-TV operator and required package/services are identified.
- The redistribution/business arrangement for the project type is confirmed or explicitly marked pending.
- The approved decryption location is defined: room, headend or operator receiver/STB.
- If headend descrambling is planned, the exact professional CAM and smart-card arrangement is known.
- The number of simultaneously required encrypted services is documented.
- Receiver/CAM/CI compatibility and capacity are verified for the proposed model and operator.
- If re-encoding is used, every required receiver output and encoder input path is documented.
- Any downstream re-encryption or content-protection requirement is separately stated.
- Monitoring, recovery and maintenance responsibility are included in the project scope.
- Unresolved operator conditions remain visible as “to be confirmed” in the quotation.
CUSTOMER REFERENCE
Explain why the pay-TV path changes the proposed headend
Use this guide in a quotation when the customer needs to understand why CI/CAM availability, operator receivers or re-encoding materially change the equipment list. The quotation must still identify the actual models, quantities, options and assumptions for that project.
“The pay-TV portion of the proposed system is based on the operator-approved access method stated in our quotation. Please refer to BLANKOM Engineering Guide 05 for the distinction between room decryption, professional headend CAM processing and receiver-output re-encoding.”
08 · SEND THE ACCESS REQUIREMENTS
What to include in your Pay-TV / IPTV RFQ
Send the protected-service list together with the operator’s approved access information. Where a contract, CAM or output condition is not yet confirmed, mark it clearly instead of guessing.
The most useful enquiry tells us which services are protected, who the provider is, where decryption is permitted and how many services must be available simultaneously.
The request opens the existing IRENIS / BLANKOM enquiry page. Final compatibility and the supplied access method must be confirmed for the operator and project.
Project brief outline
PAY-TV / IPTV PROJECT BRIEF Country / installation location: Pay-TV operator / content provider: Required encrypted TV/radio services: Project type / number of rooms or endpoints: Approved hospitality/institutional distribution arrangement: Decryption location: room / headend / to be confirmed: Professional MSD CAM available: yes / no / pending: CAM model / smart-card arrangement: Simultaneous encrypted services required: Proposed receiver / gateway and CI slots: If operator STBs are used: model / quantity: STB output interface and format: Re-encoding channels required: Downstream re-encryption/protection required: Redundancy / monitoring requirement: Project timing / open questions: Reference: IPTV System Design — Guide 05, BLANKOM
PRACTICAL QUESTIONS
Pay-TV headend planning FAQ
Can a consumer CI+ module simply be installed in a professional headend?
The 2026 source explicitly separates consumer CI+ use from professional headend CI/CAM use and states that consumer CI+ modules are not intended for headend receiver CI slots. Verify the actual professional CAM and receiver combination with the operator and current equipment documentation.[1, pp. 10–11]
How many services can one professional CAM decrypt?
The source characterises MSD CAMs as multi-service devices but does not establish one universal capacity for every operator and CAM. Treat simultaneous service capacity as a project-specific value requiring confirmation.
What if the operator does not provide a professional CAM?
The source identifies two remaining approaches: keep decryption at the room endpoints with operator equipment, or use authorised operator receivers/STBs and re-encode their outputs in the headend.[1, p. 11]
Does descrambling in the headend mean the IPTV network can carry the content unprotected?
Not necessarily. The source separately asks whether re-encryption is required. The operator’s contractual and technical conditions determine the downstream protection requirement.[1, p. 30]
Can we quote the pay-TV part before the operator confirms the access method?
A budgetary quotation can state assumptions, but the access method should remain explicitly conditional. Do not present CAM compatibility, service capacity or re-encoding permission as confirmed until the relevant provider/equipment information is available.
IPTV SYSTEM DESIGN
BLANKOM Engineering Guide Series
This is Guide 05 of the twelve-part web series. Each guide owns a separate engineering task so it can be referenced independently in quotations and project discussions.
View the twelve-guide programme
- Plan an IPTV System: Requirements and ArchitecturePublished
- Plan Satellite Reception: Services, Transponders and Tuner CountsPublished
- Engineer SAT-IF Distribution: Coax, Fibre and MultiswitchesPublished
- Select an IPTV Headend: Capacity, Interfaces and ExpansionPublished
- Plan Pay-TV Integration: CAMs, Descrambling and Re-encodingYou are here
- Validate DVB Transport Streams: PSI/SI, PCR and Dynamic PMTPlanned
- Preserve EPG in IPTV: EIT Processing and Receiver ValidationPlanned
- Design an IPTV Multicast Network: Bandwidth, IGMP and SwitchingPlanned
- Plan IPTV Stream Delivery: Multicast Addresses, UDP/RTP Ports and IP GatewaysPlanned
- Integrate Local Video Sources: Encoding, Transcoding and IP DecodingPlanned
- Select IPTV Endpoints and Services: TVs, STBs, Middleware and SignagePlanned
- Plan IPTV Resilience and Operations: Redundancy, Monitoring and HandoverPlanned
SOURCE BASIS
Primary engineering source
This guide reformulates Ralf Riedel’s pay-TV and conditional-access discussion. The source defines the consumer/headend distinction, professional MSD CAM concept and the alternative of operator-STB decryption followed by re-encoding. The decision tables, checklists and RFQ structure are editorial tools added for this web series.
Any current operator contract, CAM capacity, smart-card behaviour, CI interoperability, receiver compatibility, permitted output method or downstream protection requirement must be verified for the actual project.
- Ralf Riedel — IPTV Headend Planning Guide, 2nd edition (2026)
Primary scope: Chapter 4, pp. 10–11 — pay-TV business model, consumer CI+, professional MSD CAMs and re-encoding alternative. Supporting scope: Chapter 10, pp. 29–30 — access questions, re-encoding and downstream re-encryption as headend-design inputs.
Document reference: BLANKOM-EG-IPTV-05 · Web revision 1.0
IPTV System Design · BLANKOM Engineering Guide Series
- Requirements and ArchitectureGuide 01
- Services, Transponders and Tuner CountsGuide 02
- SAT-IF DistributionGuide 03
- IPTV Headend SelectionGuide 04
- Pay-TV IntegrationGuide 05
- DVB Transport Stream ValidationGuide 06
- EPG / EIT Processing and Receiver ValidationGuide 07
- IPTV Multicast Network DesignGuide 08
- IPTV Stream DeliveryGuide 09
- Local Video SourcesGuide 10
- IPTV Endpoints and ServicesGuide 11
- Resilience and OperationsGuide 12
© 2026 IRENIS GmbH. All rights reserved. Unless otherwise stated, the original text, diagrams, tables and illustrations in this publication are protected by copyright. Except where permitted by applicable law, they may not be reproduced, republished, distributed, translated, adapted or used commercially, in whole or in part, without the prior written permission of IRENIS GmbH. Any permitted quotation or reference must clearly identify IRENIS GmbH as the source and, for online use, include a link to the original publication. Third-party trademarks and credited materials remain the property of their respective owners.
