IPTV System Design
BLANKOM Engineering Guide Series
GUIDE 01 / 12
REQUIREMENTS · ARCHITECTURE · PROJECT SCOPE
Plan an IPTV System:
Requirements and Architecture
Start with the services your viewers need, the sources that carry them and the receiving equipment—not a channel count alone. Define the reception, processing, network, user experience and operating requirements before selecting an IPTV headend or requesting a quotation.
01 · DEFINE THE TASK
What are you designing—and what must it deliver?
This guide addresses a new IPTV installation or the migration of an existing satellite, SMATV or CATV distribution system to managed IP television. Its original application context is hospitality. The planning method is also useful for comparable building and site networks, provided their particular requirements are recorded rather than assumed.[1, pp. 3–7]
The primary task is LAN Distribution of selected live TV and radio services. Interactive services, public-internet delivery, recording and integration with other systems are separate decisions. They may form part of the project, but they should not be silently included in the word “IPTV”.
THE VIEWER
What must be available?
Required TV and radio services, languages, programme information, picture and sound, channel selection and any additional user functions.
THE SIGNAL CHAIN
How will it arrive?
Reception or IP ingest, access to encrypted services where needed, stream processing, distribution and compatible receiving devices.
THE OPERATOR
Who keeps it working?
Installation responsibilities, configuration, monitoring, recovery, documentation, maintenance and a realistic expansion plan.
At the end of planning, the project should have a service list, a source/reception schedule, an architecture drawing and a written statement of inclusions, exclusions and open questions. Use them to define the basis of the equipment specification.
02 · COLLECT THE INPUTS
The information needed before equipment selection
Ralf’s planning guide asks for the actual reception, service, access, processing and integration requirements before a system is priced. The table below reorganises those questions into a project brief. It adds explicit responsibility and procurement fields so the same information can be used in a quotation.[1, pp. 28–30, 65–66]
| Planning area | Information to collect | Why it changes the design |
|---|---|---|
| Site and existing installation | Installation country and location; new build or migration; buildings, floors and rooms; equipment and cabling to retain. | Defines the installation boundary, source availability, infrastructure work and migration scope. |
| Required TV and radio services | A named service list, including language, source and free-to-air or encrypted status. Identify essential services and optional additions. | A service count alone does not identify reception, access or processing requirements. |
| Reception and source schedule | For satellite: orbital position, frequency, polarisation, band and tuning details for each required transponder. Also identify terrestrial, cable, local video and external IP sources. | Allows reception inputs, RF distribution and source interfaces to be planned. Verify site reception rather than relying on a service name alone. |
| Encrypted content and provider conditions | Provider-approved access method; availability of appropriate CAMs, smartcards or receivers; any required protection of the distributed content. | May change the headend, receiver and encoding path. Provider approval and technical compatibility are separate checks. |
| Programme guide and service information | Whether a programme guide is required; now/next or schedule expectations; required languages and the TV, STB or middleware expected to display it. | EPG delivery is a defined end-to-end requirement, not something established merely by successful picture and sound. |
| Local video and media processing | Number of local sources and their interfaces; video/audio formats, frame rates and audio sample rates; required output format. For transcoding, specify the intended codec, resolution or bitrate change. | Separates source addition from processing, hardware/software capacity, picture-quality and integration work. Identify any applicable third-party licensing dependencies. |
| Network and receiving devices | Network topology and link capacities; multicast handling; number and distribution of endpoints; exact TV/STB models and software where known. | Connects the stream plan to the distribution network and to the devices that must receive and present it. |
| Additional services and integration | Digital signage, interactive information, PMS/building-system interfaces, VoD, PVR, timeshift or multiscreen/OTT—each marked required, optional or outside scope. | Defines additional platforms, storage, interfaces and support work instead of treating them as automatic headend features. |
| Availability, operation and growth | Critical services, acceptable interruption, recovery expectations, monitoring responsibility, power arrangements and future expansion. | Defines which parts of the chain need protection and which capacity or compatibility should be reserved. |
| Procurement and delivery boundary | Quantity, project timing, delivery location and who supplies cabling, switches, servers, TVs/STBs, installation and commissioning. | Makes quotations comparable and prevents a supply-only offer from being mistaken for a complete installed system. |
Use confirmed, assumed or to be confirmed against each project input. An assumption can support an initial budget proposal, but it must remain visible until verified.
03 · CHOOSE THE SERVICE MODEL
Select the required functions, not a marketing tier
The planning guide distinguishes basic linear TV, systems with middleware and additional services, and a hybrid DVB-C/IP approach. Specify these functions directly rather than using a hotel star rating as a technical requirement. Choose the simplest architecture that meets the documented requirement and the intended expansion path.[1, pp. 65–66]
| Architecture | Required outcome | Selection consequence |
|---|---|---|
| A · Basic linear IPTV | Live TV/radio reception and channel selection on compatible endpoints. | Begin here when the requirement is television distribution. A separate interactive middleware server is not inherently required; channel-list provisioning and the required EPG behaviour still need to be defined. |
| B · Linear IPTV with managed services | Live television plus specifically required information pages, management functions or system interfaces. | Select the platform and endpoint integration together. Define each additional service; an information channel by itself does not establish a need for a middleware server. |
| C · Extended service platform | Recording, VoD, timeshift, multiscreen or OTT functions where required. | Scope the relevant server, storage, delivery, endpoint and integration requirements separately. These functions are not implied by a DVB-to-IP gateway. |
| D · Hybrid RF and IP | Retained or new DVB-C/RF distribution alongside IPTV and its additional services. | Define which services use each path, the receiving devices and the equipment at the RF/IP boundary. Reuse of existing infrastructure must be assessed, not assumed. |
ORIGINAL REFERENCE · SOURCE FIGURE
A linear-IPTV architecture without a mandatory middleware server
The original drawing connects receiver/streamers and local encoders through a network switch to compatible televisions or STBs. Its accompanying text describes a basic live-TV system with local channel selection, while treating additional management and signage functions separately.[1, p. 70]
Historical illustration—not a current bill of materials. Original equipment names, capacities and notes have been preserved. Use current product documentation to specify any new installation.
Figure 1. Original linear-IPTV architecture, reproduced in the IPTV Headend Planning Guide, 2nd edition (2026), Figure 23.4, p. 70. Open the image to inspect its original labels. Native source resolution: 525 × 725 pixels; enlargement cannot restore missing detail.
Acquisition
Identify the RF or local video sources and the processing needed to make them available as streams.
Distribution
Specify the network path between the headend and the receiving endpoints; it is part of the engineered system.
Presentation
Verify how the actual endpoints obtain their channel list, display the services and provide the required user experience.
04 · ASSESS THE INSTALLATION
Treat migration and the network as engineering work
IPTV is not automatically the least-cost replacement for a functioning coaxial TV system. The planning guide’s economic argument is to consider the whole installation: parallel cabling, distances, distribution equipment, the network already planned and future operation—not only the purchase price of a headend.[1, pp. 6–7]
For an existing installation, record which reception equipment, cable routes, switches and receiving devices will remain. For a new build or major renovation, compare the complete distribution design before committing to the last-metre cabling. A hybrid RF/IP solution may be more appropriate than replacing every existing path.[1, pp. 7, 24, 65–66]
MIGRATION QUESTIONS
What are we retaining?
- The available sources and existing reception equipment.
- Usable cable routes, network links and receiving devices.
- The services that must remain available during changeover.
- Configuration records and the responsibility for the transition.
NEW INFRASTRUCTURE QUESTIONS
What must the network provide?
- A documented topology from headend to endpoints.
- Link capacity matched to the intended stream delivery.
- The required multicast handling and management access.
- Installation, testing and maintenance responsibilities.
A fibre backbone is an option—not a complete network specification
The original floor-distribution drawing illustrates an Ethernet/IP backbone using optical trunks and floor switches. It is a useful starting point for a building architecture, but it does not establish the required capacity, redundancy or switch configuration for a new project.[1, p. 24]
Figure 2. Original headend-to-floor Ethernet/IP fibre-backbone drawing, reproduced in the IPTV Headend Planning Guide, 2nd edition (2026), Figure 8.7, p. 24. Switch models are historical examples. All original paths and labels are retained.
Do not assume that an existing Wi-Fi network can carry the same multicast-TV design without further engineering. Record wireless viewing or multiscreen requirements separately and verify the actual delivery method, network and clients. This is a design caution, not a claim that all video over Wi-Fi is impossible.[1, pp. 6–7, 24]
05 · DEFINE SUCCESS
Specify quality, availability and growth in usable terms
Ralf’s selection criteria include reception, stability, picture quality, channel switching, maintenance, EPG and additional services. The same requirement discipline applies to redundancy: decide what must be protected and at what cost instead of treating “redundant” as a complete specification.[1, pp. 8–9, 28, 65–66]
| Requirement | What the project must decide | Boundary to keep visible |
|---|---|---|
| Picture, sound and channel change | Required audiovisual formats and the intended viewing experience; how channel switching will be assessed on the actual endpoint. | Use project-specific criteria. Do not convert a headend feature name or a legacy example into a universal performance guarantee. |
| EPG and service behaviour | Required programme information and languages; receiver/platform support; guide updates and any time-dependent service changes. | Define the required behaviour through the whole chain. A working picture is not evidence that the guide and service information are correct. |
| Availability and recovery | Which services are critical, which failures are covered, acceptable interruption and the recovery responsibility. | Receiver, power and network redundancy protect different failure domains. A duplicated device does not establish protection of the entire chain. |
| Future services and capacity | Likely changes in services, reception inputs, sources, endpoints and interactive functions. | Reserve only justified capacity. Check the future endpoint/platform compatibility before promising an upgrade path. |
Specify transcoding only after identifying a format, bitrate or receiving-system requirement that makes it necessary. State the number of streams and the required input-to-output conversion. Likewise, protection or re-encryption of distributed content is a separate requirement to be agreed with the content provider and checked against the selected implementation.[1, pp. 30, 56–57]
A phased installation can begin with basic linear television and add selected services later. That is a planning strategy, not an assurance that every endpoint or platform can be upgraded. The planning guide explicitly warns that an unsuitable TV/STB choice at the outset can make later middleware integration difficult.[1, pp. 64–66]
06 · REVIEW THE DESIGN
A five-stage planning and verification sequence
The following sequence is an editorial planning method developed from the source’s requirements discussion. It is not a report of a completed installation or a substitute for device-specific commissioning instructions.
-
Agree the service brief
Record the required viewing outcome, named services and additional functions. Separate must-have requirements from optional improvements.
-
Map sources and access
Associate each service with its source. Collect reception details and confirm the proposed access route for encrypted services before selecting the processing chain.
-
Choose the architecture
Decide between the documented linear, managed, extended-service or hybrid approach. Draw the main path from acquisition to endpoints and identify optional branches.
-
Check the boundaries
Review input and output formats, link capacity, endpoint/software compatibility, programme information and the responsibilities between suppliers.
-
Freeze the quotation basis
Record inclusions, exclusions, assumptions and verification tasks. An initial budget configuration can remain conditional; unresolved details must not look confirmed.
Ready for a project-specific equipment proposal?
Use this review checklist before treating the configuration as settled.
- The service list and the source/reception schedule are separate and internally consistent.
- The chosen architecture is justified by required functions, not by a generic IPTV label.
- Content-access, EPG, local-source and transcoding requirements are explicit.
- The network and endpoint responsibilities have named owners.
- Acceptance questions and expansion assumptions are written down.
- The quotation distinguishes confirmed scope from options, exclusions and open points.
CUSTOMER REFERENCE
Use this guide to explain the proposal—not to replace it
A quotation can link to the relevant requirements, architecture or infrastructure section so the customer can understand the engineering basis of the offer. The quotation itself should still state the selected models, quantities, options, delivery scope and project-specific conditions.
The “Section link” beside each heading is a permanent reference. Right-click it, or long-press it on a touch device, to copy the link into a quotation or email.
“The proposed configuration covers the linear-IPTV functions and project inputs stated in our quotation. Please refer to the architecture section of BLANKOM Engineering Guide 01 for the distinction between basic television distribution and separately scoped interactive services.”
07 · TURN REQUIREMENTS INTO AN ENQUIRY
What to include in your IPTV RFQ
Send the service list and project outline you already have. Where a value is unknown, mark it “to be confirmed” rather than guessing.
The most useful enquiry explains what you want to receive, what you want to deliver, where the system will operate and which parts of the installation need to be included.
Copy the outline into your written request and add a service schedule or topology where available. This is a drafting aid, not an additional web form. The enquiry button opens our existing RFQ page.
The request opens the existing IRENIS / BLANKOM enquiry page. The quoted equipment and included services will be confirmed for your project.
Project brief outline
IPTV PROJECT BRIEF Country / installation location: New installation or migration: Buildings / rooms / receiving endpoints: Required TV and radio services: Sources / satellites / transponder details: Encrypted services and provider access method: Existing network and equipment to retain: TV / STB models and software: EPG, languages and channel-list requirements: Local video sources and required processing: Additional services required / optional: Critical services and recovery expectations: Future expansion: Supply / installation responsibilities: Quantity / timing / open questions: Reference: IPTV System Design — Guide 01, BLANKOM
PRACTICAL QUESTIONS
IPTV system planning FAQ
Can you size a system from the number of TV channels?
Not reliably. Identify the named services, their source multiplexes/transponders, encrypted-content access and any required processing. The number of receiving endpoints is another independent input. [1, pp. 29–31]
Does basic linear IPTV require a middleware server?
Not inherently. A compatible headend, network and receiving system can provide linear television without a separate interactive middleware server. Channel provisioning, EPG and any additional functions must still be specified for the actual endpoints. [1, pp. 65–66, 70]
Must a coaxial distribution system be replaced completely?
Not necessarily. Assess the retained installation and required services; the planning guide also describes a hybrid DVB-C/IPTV approach. Compare the complete migration scope rather than the headend price alone. [1, pp. 6–7, 65–66]
Will a larger system automatically provide a better programme guide?
No. State the required guide behaviour and verify the source data, processing and receiver or middleware path. Physical size and a headline service count do not establish the required EPG outcome. See the related EIT Technical Paper for the processing distinction.
Can interactive functions always be added later?
Only where the selected endpoints, platform and integration path support them. Record the future requirement now; the planning guide warns against assuming that standalone receivers can always be incorporated into a later middleware system. [1, pp. 64–66]
SOURCE BASIS
Original engineering work and editorial additions
This guide reformulates the requirements and architecture discussion in Ralf Riedel’s IPTV Headend Planning Guide, 2nd edition (2026). The original hospitality context and the two source illustrations have been retained. The requirements register, planning sequence, review checklist and enquiry outline are editorial tools developed for this series.
Historical product labels in the illustrations are not current specifications. Device selection, software compatibility, content-provider conditions and project acceptance must be checked for the proposed system.
- Ralf Riedel — IPTV Headend Planning Guide, 2nd edition (2026)IRENIS / BLANKOM. Core scope: Chapters 1–2 (pp. 3–7), Chapter 10 (pp. 28–30) and Chapters 21–22 (pp. 62–66). Supporting discussion: Chapter 3 (pp. 8–9), Chapter 8 (p. 24), Chapter 11 (pp. 31–35) and Chapter 19 (pp. 56–58). Retained illustrations: Figure 23.4, p. 70 (Figure 1 on this page), and Figure 8.7, p. 24 (Figure 2 on this page). Page references use the printed pagination of the second edition, not the PDF viewer’s page counter.
- IETF RFC 9317 — Operational Considerations for Streaming MediaSections 2 and 6 support the clarification that internet streaming is not restricted to UDP and may use HTTP over TCP or QUIC. This is external technical context, not evidence of a BLANKOM model feature.
Document reference: BLANKOM-EG-IPTV-01 · Web revision 1.1
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.
