In-Depth Technical Sheet

Conditional Access & DVB SimulCrypt
How Scrambling, ECMs and Entitlements Actually Fit Together

Conditional access is two separate systems that people routinely discuss as one: a scrambling layer that encrypts packet payloads, and a messaging layer that distributes the keys. Get the split clear and the rest — CSA versus CISSA, even and odd keys, ECM against EMM, why one multiplex can carry four CA systems at once, why BISS exists for contribution — stops being folklore and becomes structure you can reason about.

Scrambling layer
ECM & EMM
SimulCrypt
BISS & BISS-CA
CI, CAM, DDCI

1. Scope and sources

This sheet describes the architecture of DVB conditional access as it is publicly specified: how the scrambling layer is signalled, how key-bearing messages are carried, how a head-end serves several CA systems from one multiplex, and where descrambling physically happens in a modern IP-based facility. Every structural claim is traceable to the standards listed in section 18.

What this sheet deliberately does not contain. No key material, no control words, no CA system identifiers tied to live services, and nothing about circumventing conditional access. The cryptographic cores of DVB-CSA v2 and v3 are not public — the XRC component of v3 is explicitly DVB-confidential, released only under NDA through the DVB Common Scrambling Algorithm Custodian. Where a value would be operator-specific it is written as a placeholder. This is head-end engineering documentation: the intended reader is someone building, monitoring or debugging a facility that carries scrambled services under a legitimate agreement with the rights holder.

The distinction that organises everything below appears in the standards themselves. ETSI TS 100 289 specifies the scrambling — one algorithm, fully interoperable, identical for every operator. ETSI TS 103 197 specifies the interfaces between a head-end and one or more conditional access systems — deliberately leaving the CA systems themselves as black boxes. Scrambling is standardised so that any receiver can descramble; conditional access is proprietary so that only authorised receivers get the chance.

2. Two layers, routinely conflated

A scrambled DVB service involves two independent mechanisms. They are specified in different documents, they fail in different ways, and they are diagnosed with different tools.

Property	Scrambling layer	Conditional access layer
What it does	Encrypts TS or PES payloads with a symmetric key	Delivers that key to receivers that are entitled to it
The key is called	Control word (CW), or session word in BISS	Carried inside an ECM, itself protected by CA-specific keys
Standardised?	Yes — one algorithm, fully interoperable	Only the interfaces. The system internals are proprietary
Specified in	ETSI TS 100 289 (CSA), TS 103 127 (CISSA)	ETSI TS 103 197 defines head-end interfaces only
Signalled by	`transport_scrambling_control` bits, `scrambling_descriptor`	CAT on PID 1, and `CA_descriptor` in the PMT
How many per service	Exactly one algorithm at a time	Several simultaneously — that is what SimulCrypt is for
Typical failure	Picture breaks up or freezes; PIDs still present	"No entitlement" or black screen; stream itself is intact

Why the split is designed this way. If scrambling were proprietary, every operator would need its own silicon in every receiver. If key distribution were standardised, an operator could not distinguish its subscribers from anyone else's. Standardising the cipher and leaving entitlement proprietary lets one chip descramble any DVB service in the world while still requiring a per-operator authorisation path. It is also what makes SimulCrypt possible at all — see section 8.

3. What is encrypted, and what is never encrypted

Scrambling is deliberately partial. Enough of the stream stays in the clear that a receiver can navigate it, find the CA messages and synchronise its clock without holding any key at all.

Element	State	Why
TS packet header (4 bytes)	Always clear	The PID and the scrambling-control bits themselves live here. Encrypting them would make the stream unparseable.
Adaptation field	Always clear	Carries the PCR. A receiver must lock its clock before it can present anything, entitled or not.
PES header	Clear, when PES-level scrambling is used	Required by ISO/IEC 13818-1. PTS and DTS must be readable for buffer management.
PSI and SI sections	Never scrambled	PAT, PMT, CAT, SDT, EIT must be readable to find services and CA streams in the first place.
ECM and EMM streams	Not TS-scrambled	They carry their own CA-specific encryption. Scrambling them with the CW they deliver would be circular.
Elementary stream payload	Scrambled	This is the content — audio, video, subtitles, data.
Null packets (PID 0x1FFF)	Never scrambled	Stuffing carries no information.

3.1 The remainder that stays in the clear

Both AES-based DVB scrambling algorithms operate on 16-byte blocks, and a TS payload is generally not a multiple of 16. CISSA resolves this explicitly: an integer number of contiguous 16-byte blocks is encrypted with CBC chaining, and any remaining 1 to 15 bytes are left in the clear at the end of the packet. A payload shorter than 16 bytes is not encrypted at all.

A practical consequence when reading hex. In a CISSA-scrambled packet the tail bytes are plaintext. This is not a weakness in any meaningful sense — a fragment under 16 bytes with no context yields nothing useful — but it does mean that "the last few bytes look like real data" is not evidence that a packet is unscrambled. Check the scrambling-control bits in the header instead; they are authoritative and always in the clear.

4. The scrambling algorithms

Four algorithms appear in DVB systems. They are not interchangeable, and a receiver must be told which one is in use.

Algorithm	Key	Construction	Where it appears
DVB-CSA v1	64-bit CW	Block cipher plus stream cipher. The default when no `scrambling_descriptor` is present.	Legacy broadcast, and BISS version 1
DVB-CSA v2	64-bit CW	As v1, with a revised key schedule	The long-standing broadcast workhorse
DVB-CSA v3	128-bit CW	Two block ciphers: AES′, a variant of AES-128 per NIST FIPS 197, and XRC (eXtended emulation Resistant Cipher), which is DVB-confidential. Encrypts blocks of any size over 16 bytes at 1-byte granularity.	Adopted by DVB in 2007; specified in TS 100 289
DVB-CISSA v1	128-bit CW	Straight AES-128 in CBC mode per FIPS 197 and NIST SP 800-38A, with a constant initialisation vector. Fully public.	DVB-IPTV (TS 103 127), and the scrambler in BISS2

Why CISSA exists alongside CSA v3. The name says it: software-oriented. CSA was designed for hardware descramblers, and its v3 construction includes a confidential component that cannot be implemented from public documentation. CISSA is plain AES-128-CBC, so it can be implemented in software by anyone, on any platform, with no NDA and no licensed core. For IP delivery — where scrambling and descrambling happen on general-purpose CPUs rather than in a set-top box ASIC — that matters more than the hardware efficiency CSA was optimised for. It is also why BISS2 replaced CSA1 with CISSA.

4.1 Signalling which algorithm is in use

The algorithm is carried in a scrambling_descriptor in the program map section. Its single 8-bit scrambling_mode field is coded as follows.

`scrambling_mode`	Meaning
0x00	Reserved for future use
0x01	DVB-CSA v1. The default, and what a receiver must assume when the descriptor is absent
0x02	DVB-CSA v2
0x03	DVB-CSA v3
0x04 – 0x05	User defined, for DVB-CSA v3
0x06 – 0x6F	Reserved for future use
0x70 – 0x7F	ATIS defined
0x80 – 0xFE	User defined
0xFF	Reserved for future use

Three rules govern mixing modes, and they are frequently violated by ad-hoc remultiplexing:

Different modes in one transport stream — allowed. It happens naturally when a TS is assembled by multiplexing two or more independent streams.
Different modes within one service at the same time — not allowed. Every scrambled component of a service must use the same mode concurrently.
Changing mode over time for a service — allowed, for instance between events or when inserting a local programme. The standard warns that transitions should not be expected to be seamless.

5. Even and odd keys, and the crypto period

The two scrambling-control bits in the TS packet header are the entire signalling of key state. MPEG-2 Systems defines only one of the four values; DVB defines the rest.

Bits	TS packet header	PES packet header
00	No scrambling of the payload — MPEG-2 compliant	No scrambling of the PES payload
01	Reserved for future DVB use	Reserved for future DVB use
10	Scrambled with the even key	Scrambled with the even key
11	Scrambled with the odd key	Scrambled with the odd key

Read the bits as two independent flags. The first says whether the payload is scrambled at all; the second selects even or odd. Note that 00 at the TS level does not prove the content is clear — scrambling may still be applied at the PES level. The two levels use deliberately similar coding so that one descrambler implementation can serve both.

5.1 Why two keys are needed

A crypto period is, in the words of TS 103 197, the period during which a particular control word is being used by the scrambler. Keys change on crypto period boundaries. If there were only one key register, the moment of change would be a race: the receiver would have to install the new key in exactly the gap between the last packet of one period and the first of the next, with no tolerance.

Two registers eliminate the race. While the scrambler is using the even key, the next control word is already being delivered and loaded into the odd register. The parity bit in each packet header tells the descrambler which register to use, so the handover is instantaneous and requires no timing precision from the receiver at all — it simply follows the bit. The control word for the next period must arrive before the parity flips, which is why the SimulCrypt timing parameters in section 11 exist.

The diagnostic that follows from this. If a service breaks up rhythmically — clean for a period, corrupt for a period, clean again — suspect a key delivery problem on one parity, not a signal problem. Signal impairment does not respect crypto period boundaries. A stream where only even-key packets descramble correctly points at the odd-key path: the ECM for that parity is arriving late, not at all, or is being filtered out somewhere in the chain.

6. Signalling conditional access: the CAT and the CA_descriptor

A receiver needs to answer two questions: which CA systems are present in this multiplex, and where are their messages? Two structures answer them.

The CAT — PID 0x0001

Conditional Access Table, table_id 0x01, on a reserved PID. It is a list of CA_descriptors, one per CA system present, each pointing at that system's EMM stream. The CAT is multiplex-wide: it describes subscriber management for the whole TS, not for one service.

The CA_descriptor — tag 0x09

An MPEG descriptor carrying CA_system_ID (16 bits, identifying the vendor system) and CA_PID (13 bits, where the messages are). Its meaning depends entirely on where it sits: in the CAT it points at EMMs; in a PMT it points at ECMs. Same tag, same structure, different referent.

Within a PMT the descriptor's position is significant again. In the first descriptor loop — the program-level loop — it applies to the whole service. In a component's descriptor loop it applies to that elementary stream alone, which is how a broadcaster can scramble video while leaving one audio track clear, or use different ECM streams for different components.

The consequence that bites in practice. Because CA information lives in the PMT and the CAT rather than in the packets themselves, stripping it changes what a downstream client believes about the stream without changing a single payload byte. That is exactly what SAT>IP Servers Pro's -t / --cleanpsi does: it removes all CA information from the PSI so that a successfully descrambled service is presented to the client as a clear one. Useful, because many client applications refuse to play a service whose PMT still advertises a CA system they cannot see — but it also means a PMT is not a reliable witness to whether content was ever scrambled.

7. ECM and EMM — what each one carries

Two message types do all the work. They are easy to keep straight once you see that they operate on completely different timescales.

	ECM — Entitlement Control Message	EMM — Entitlement Management Message
Carries	The control word for the current and next crypto period, encrypted under CA-system keys, together with the access criteria the receiver must satisfy	Subscriber entitlements — what this specific receiver or smartcard is allowed to decrypt, and until when
Addressed to	Every receiver watching this service	An individual receiver, or a defined group
Timescale	Seconds. Repeated continuously, tracking the crypto period	Hours to weeks. Cycled slowly through the whole subscriber base
Pointed to by	`CA_descriptor` in the PMT	`CA_descriptor` in the CAT
Scope	Per service, sometimes per component	Multiplex-wide
Generated by	ECMG, on demand, from control words supplied by the head-end	EMMG, from the CA system's subscriber database
If missing	Nothing descrambles, immediately	Works until the current entitlement expires, then stops

The logic chains: an EMM tells the secure module what this subscriber may watch. An ECM says here is the key for this service right now, and here are the conditions. The module compares the ECM's access criteria against the entitlements it holds from EMMs, and only if they match does it release the control word to the descrambler. Neither message alone is sufficient.

Why EMM problems are slow and confusing. Because entitlements persist, an EMM path that has been broken for days produces no symptom until something expires — and then services fail in an order determined by expiry dates rather than by anything happening at that moment. A facility that monitors ECM presence but not EMM continuity will discover the fault from customers rather than from its own alarms.

8. SimulCrypt — why one multiplex serves several CA systems

A platform operator has a problem. Its subscriber base holds set-top boxes from more than one generation, or it distributes the same multiplex to several affiliates, each with its own CA vendor. Scrambling the content twice is not an option: each copy would consume full bandwidth, and a receiver cannot descramble a stream twice.

SimulCrypt's answer follows directly from the two-layer split. The content is scrambled once, with one control word. That same control word is then handed to every participating CA system, and each generates its own ECM stream carrying it, protected under its own keys. The multiplex carries several parallel ECM streams and several parallel EMM streams — one set per CA system — all describing the same scrambled payload.

The cost of SimulCrypt is bandwidth in the signalling, not in the content. Each additional CA system adds its ECM and EMM streams — a small, roughly fixed overhead — rather than another copy of the video. A receiver reads the PMT, finds the CA_system_ID it recognises, ignores the others entirely, and takes the control word from its own ECM stream. Because all the systems deliver the same control word, they interoperate without ever being aware of one another.

ETSI TS 103 197, titled Head-end implementation of DVB SimulCrypt, exists to make this work between equipment from different vendors. It addresses interoperability between two or more conditional access systems at a head-end, specifying the architecture, the timing relationships, the message structures and the control.

9. The SimulCrypt head-end

TS 103 197 decomposes the head-end into named functional components with defined interfaces between them. The value of knowing these names is diagnostic: vendor logs and error messages use them directly.

Component	Full name	Role
SCS	SimulCrypt Synchronizer	The orchestrator. Opens connections to every ECMG, sets up channels and streams, allocates ECM stream IDs, obtains control words from the CWG, supplies them to the ECMGs, collects the resulting ECMs, synchronises them with their crypto periods, and hands the control word to the scrambler.
ECMG	Entitlement Control Message Generator	Supplied by the CA vendor. Receives a control word and access criteria, returns an ECM — or an error.
EMMG	Entitlement Management Message Generator	Supplied by the CA vendor. Produces EMMs from the subscriber database and pushes them to the multiplexer.
CWG	Control Word Generator	Generates the control words. One per crypto period, delivered to the SCS.
PDG	Private Data Generator	Injects CA-related private data into the multiplex over the same interface style as the EMMG.
C(P)SIG	Custom PSI/SI Generator	Lets a CA system influence PSI and SI generation — for example inserting its own descriptors.
EIS	Event Information Scheduler	Drives scrambling and access-criteria changes from the programme schedule.
ACG	Access Criteria Generator	Produces the access criteria that accompany each control word into the ECMG.
MUX	Multiplexer	Assembles the output transport stream, inserting ECM and EMM streams at the PIDs the SCS allocated.

Four interfaces are defined between these components. Three are mandatory: ECMG ⇔ SCS, EMMG ⇔ MUX and C(P)SIG ⇔ (P)SIG. The PDG ⇔ MUX interface is optional and, where implemented, follows the EMMG ⇔ MUX definition.

The architecture is not mandated, only the interfaces. TS 103 197 states plainly that the SCS and MUX could be built independently, and that neither architecture is mandated. In practice they are often one product. This is why two conformant head-ends can look nothing alike internally while still accepting the same vendor ECMG.

10. The SimulCrypt protocol on the wire

All the CA-to-head-end interfaces share one connection-oriented design built on TCP, with a channel-and-stream hierarchy: a channel is the association between two components, and streams within it correspond to individual ECM or EMM streams. Messages are type-length-value: a message type, a length, then parameters each carrying a 16-bit parameter_length and a variable-length parameter_value.

All three mandatory interfaces use protocol version 0x03. Message types are allocated in blocks per interface — a detail worth knowing when reading a packet capture, because the type value alone tells you which interface you are looking at.

Interface	Value	Message type
ECMG ⇔ SCS	0x0001	`channel_setup`
	0x0002	`channel_test`
	0x0003	`channel_status`
	0x0004	`channel_close`
	0x0005	`channel_error`
EMMG ⇔ MUX	0x0011 – 0x0015	The same five channel messages, in their own block
ECMG ⇔ SCS	0x0101	`stream_setup`
	0x0102	`stream_test`
	0x0103	`stream_status`
	0x0104	`stream_close_request`
	0x0105	`stream_close_response`
	0x0106	`stream_error`
EMMG ⇔ MUX	0x0117	`stream_BW_request`
EMMG ⇔ MUX	0x0118	`stream_BW_allocation`
ECMG ⇔ SCS	0x0201	`CW_provision` — the SCS delivers control words
ECMG ⇔ SCS	0x0202	`ECM_response` — the ECMG returns the ECM
EMMG ⇔ MUX	0x0211	`data_provision` — EMMs pushed to the multiplexer
C(P)SIG ⇔ (P)SIG	0x0301 – 0x031E	Channel and stream management, plus `table_request`, `table_response`, `descriptor_insert_request` and trigger messages

The two that carry the actual work are CW_provision and ECM_response. Everything else is session management. Note also stream_BW_request and stream_BW_allocation on the EMMG side: EMM bandwidth is explicitly negotiated with the multiplexer, because a CA system cycling a large subscriber base can demand a substantial and bursty share of the multiplex.

11. Timing — the parameters that decide whether it works

SimulCrypt is a real-time pipeline. A control word must reach the receiver before the parity bit flips to its register, which means the ECM must be generated, returned, inserted and transmitted inside one crypto period. TS 103 197 exposes this as explicit, negotiable parameters rather than leaving it to implementation.

Parameter	What it controls
`CP_duration`	The actual duration of a particular crypto period for a particular stream
`CP_number`	Identifies the crypto period a message is attached to
`CP_CW_combination`	The crypto period number concatenated with the control word itself. The parity of the CP number equals the parity of the key — which is how even and odd stay aligned end to end.
`delay_start` / `delay_stop`	When ECM transmission should begin and end relative to the crypto period boundary
`AC_delay_start` / `AC_delay_stop`	Replace the above for the first crypto period after, and the last before, an access-criteria change — the transition case, where the ordinary timing does not apply
`lead_CW`	How far ahead control words are supplied. Every provision message for period n carries the control words for a window of periods around n, each tagged with its own CP number.

Where this shows up as a fault. A CA system whose ECMG responds slowly, or a network path with jitter between SCS and ECMG, pushes ECM insertion past the parity flip. The symptom is not a clean failure: it is intermittent breakup that correlates with crypto period boundaries and gets worse under load. Shortening the crypto period — often reached for as a security improvement — makes this worse, because it reduces the time available for the whole round trip. The `lead_CW` window exists precisely so that a slow ECMG can still deliver in time.

12. BISS — the contribution answer

Everything so far describes distribution: one operator, many subscribers, individual entitlement management. Contribution — a feed from an event back to a broadcaster, or between broadcasters — has different requirements. There are a handful of known receivers, the link may exist for only a few hours, and there is no subscriber base to manage. Deploying a full CA system for a two-hour sports feed is absurd.

The EBU's Basic Interoperable Scrambling System answers this. BISS version 1 used CSA1 for transport stream scrambling and DES for session word encryption. BISS2, specified in EBU Tech 3292, replaces both: DVB-CISSA for scrambling and AES-128 for key encryption.

Mode	Mechanism	Key handling
Mode 0	No scrambling applied	—
Mode 1	Components scrambled with a session word (SW)	The SW is transmitted out of band — in practice, communicated to the receiving party by other means. Recommended for short-term events.
Mode E	Components scrambled with a session word	The SW is encrypted with a fixed session key (SK); the resulting encrypted session word (ESW) is transmitted out of band. Backward compatible with Mode 1.
Mode CA	Components scrambled with a session word	The SW is encrypted with a session key, and the ESW together with key management data travels in the stream itself, using ECMs and EMMs.

A signalling detail worth knowing. The CAT is required to be present in the multiplex for BISS Mode 1 and Mode E — but it shall be empty, because no entitlement messages exist in those modes. It carries real content only in Mode CA. An empty CAT on a BISS feed is correct, not a fault. Equipment supporting Mode CA is also required to support Modes 0, 1 and E.

13. BISS-CA — real-time entitlement without a CA vendor

Modes 1 and E share a structural weakness: the session word, encrypted or not, has to reach the receiver by some channel outside the stream — email, phone, a spreadsheet. That does not scale, it cannot be revoked quickly, and it means a leaked key stays valid for the life of the feed.

BISS-CA, published as EBU Tech 3292 Supplement 1, is built on top of Mode E and adds in-stream key exchange. It combines AES-128 for symmetric scrambling with RSA asymmetric cryptography for key delivery, which lets a rights holder grant and revoke reception rights for individual decoders in real time, with rolling keys, while the feed is running.

EKID

Entitlement Key ID. Identifies the key material a receiver must hold.

ESID

Entitlement Session ID. Identifies the entitlement session a receiver is being admitted to.

SW / ESW

The session word that scrambles the content, and its encrypted form as carried to receivers.

Why this matters commercially. BISS-CA is open, royalty-free and interoperable. It gives a contribution feed the property that previously required a commercial CA system — revoke a single decoder, immediately, without touching anything else — with no per-subscriber licensing and no vendor lock-in. It is the reason a modern contribution link no longer has to choose between a shared static key and a full CA deployment.

14. Where descrambling physically happens

The standards describe messages, not placement. In a real facility the secure module can sit in several places, and the choice has more operational consequence than any other decision in this sheet.

Placement	How it works	Trade-off
CI / CI+ slot in a tuner	A CAM in a Common Interface slot on the tuner card or receiver. The stream passes through the module, which descrambles in line.	Simple and self-contained, but the module must be physically at the tuner. Typically one or two services per CAM.
DDCI — decoupled CI	The CI slot is addressable independently of the tuner that received the stream, so a stream from one source can be routed to a CAM elsewhere.	Breaks the tuner-CAM adjacency requirement. This is the mechanism that makes the architecture in section 16 possible.
Professional multi-CAM / smartcard farm	Rack equipment holding many modules and cards, descrambling an incoming MPTS centrally.	Scales to many services and concentrates the secure hardware in one controlled location. Higher capital cost.
Software client to a card server	The head-end extracts ECMs and asks a card server for the control words over a control protocol, then descrambles in software.	Most flexible; no per-stream hardware. Requires a software descrambler and a reachable, trusted card server.

The point that is widely got wrong. Descrambling does not have to happen where the signal was received. Because the scrambled MPTS is just a transport stream, it can be delivered over IP to wherever the secure hardware lives and descrambled there. Only legacy modules that require a CI slot adjacent to the tuner impose physical co-location. Modern professional multi-CAM equipment and card-server paths descramble an IP-delivered MPTS perfectly well — which decouples "where the dish is" from "where the smartcards are" entirely.

15. SAT>IP Servers Pro — the CA paths

SAT>IP Servers Pro implements both descrambling paths described above and exposes them as explicit options. Listing them together is the clearest way to see how the abstractions map onto a running system.

Option	What it does
`-o` / `--dvbapi [~]host:port[,offset]`	Connects to a card server over the dvbapi protocol; requires the `dvbcsa` library. A local socket path works too. The `offset` distinguishes multiple clients sharing one server. Prefixing `~` disables filtering of unencrypted packets on `pids=all` requests.
`--send-all-ecm`	Passes every received ECM to the card server rather than only those needed. Documented with a warning that it may overload the server; not needed for normal operation.
`-c` / `--ca-channels`	Declares how many concurrent services a CAM supports, and optionally overrides its CAIDs. A `*` before the channel count enables two PMTs inside one CAPMT, doubling the descrambled services — official CAMs support one or two channels, which this extends to two or four. Default is one.
`-C` / `--ci`	Disables CI+ mode for specified adapters. Relevant because CI+ requires certificates obtained from an external source.
`-3` / `--ca-pin`	Supplies the PIN for CI modules, per adapter or adapter range.
`-5` / `--disable-cat`	Stops the CAT being passed to specified DDCI devices — useful when a module misbehaves on EMM traffic it does not need.
`-9` / `--disable-pmt-scan`	Reads only the PMTs a client actually requests instead of scanning all of them. Documented as giving more reliable descrambling for services carried by multiple providers — the ambiguous case where the same service appears under more than one CA system.
`-t` / `--cleanpsi`	Strips all CA information from the PSI, so a successfully descrambled service is presented to the client as clear. See the warning in section 6.

Building with CA support needs both libraries, because the two paths are genuinely separate: libdvbcsa-dev for the software descrambler used by the card-server path, and libssl-dev for the hardware CA path used by cards with their own CA support.

# DDCI logging is part of the ca subsystem
satip-server-pro -s 10.0.0.10:554 -l ca,pmt,satipc,adapter -v satipc,ca -j 4

When ECM or CAT mapping misbehaves, that log selection is the place to start: the ca subsystem emits the ECM and CAT mapping lines, and -l ddci with -v ddci adds DDCI detail on top.

16. Delivering a tuner where the beam does not reach

One configuration deserves separating out, because it inverts the usual assumption that reception and descrambling are the same place.

A satellite beam covers a footprint. If a facility sits outside it — or the required orbital position is not visible from that site — no amount of local equipment helps. The conventional answer is to build a receiving station inside the footprint and backhaul the content, which means encoding, transport and a second decode.

The alternative is to keep the transport stream intact. A SAT>IP tuner inside the footprint receives the transponder and delivers the MPTS over IP to the facility, where the CAM and smartcard live. The -s host:port option does exactly this: SAT>IP Servers Pro uses a remote tuner while the CI/DDCI module stays local.

What each half contributes. The remote tuner solves geography — it puts reception inside a footprint the facility cannot see. The local CAM solves authorisation — the smartcard stays in the operator's own rack, under its own physical control, which is usually what the agreement with the rights holder requires. Neither half works alone: a remote tuner without local descrambling delivers a stream nobody can read, and a local CAM without a remote tuner has nothing to descramble.

This is also the honest case for dedicated hardware. If the requirement is a physical CI/CAM module, a GPU for transcoding, or a large DVR array, a dedicated server is the right answer and no virtual tuner replaces it. What SAT>IP changes is not whether you need that hardware, but whether it has to sit under the dish.

17. What breaks, and how to tell

CA faults are diagnosable if you know which layer to look at. The table below maps symptoms to the layer that produces them.

Symptom	Likely layer	What to check
Nothing descrambles at all, immediately	ECM path	Is the ECM PID present and carrying data? Does the `CA_system_ID` in the PMT match what the module holds?
Rhythmic breakup on a regular cycle	Crypto period timing	One parity is failing. Check ECM insertion timing against the crypto period, and whether one parity's ECM is being filtered out.
Services fail gradually over days, in no obvious order	EMM path	Entitlements expiring with no refresh. Check EMM continuity and the CAT — the order of failure follows expiry dates, not the fault.
Intermittent, worse under load	SimulCrypt timing	ECMG round-trip time against `CP_duration`. A shorter crypto period makes this worse, not better.
Descrambles, but the client refuses to play	Signalling	The PMT still advertises a CA system. This is what `--cleanpsi` is for.
Some services in a multiplex work, others do not	Module capacity	Concurrent-service limit on the CAM. Check the declared channel count, and whether two PMTs per CAPMT are enabled.
Correct key, still garbage	Scrambling algorithm	Wrong `scrambling_mode`. Remember 0x01 (CSA v1) is assumed when no `scrambling_descriptor` is present.
A service that was fine changes behaviour mid-event	Access criteria or mode change	Legitimate transitions exist — access criteria changes have their own timing parameters, and scrambling mode may change between events. Transitions are explicitly not required to be seamless.
Same service under two providers behaves erratically	PMT ambiguity	The service appears under more than one CA system. `--disable-pmt-scan` addresses exactly this.

The first question, always. Read the transport_scrambling_control bits. They are in the clear, in every packet header, and they tell you whether the content is scrambled at all and on which parity. A surprising share of "CA problems" turn out to be streams that were never scrambled, or that were already descrambled upstream — and two bits settle it before any deeper investigation starts.

18. Standards and sources

Specification	Role here
ETSI TS 103 197 V1.5.1 (2008-10)	Head-end implementation of DVB SimulCrypt. Source of the component definitions in section 9, the message-type table in section 10 and the timing parameters in section 11, read directly from the specification.
ETSI TS 100 289 V1.2.1 (2014-03)	Support for use of the DVB Scrambling Algorithm version 3. Source of the scrambling-control tables in section 5, the CSA v3 construction in section 4, and the `scrambling_mode` coding and mode-mixing rules in section 4.1.
ETSI TS 103 127 V1.1.1 (2013-05)	Content Scrambling Algorithms for DVB-IPTV Services using MPEG2 Transport Streams. Defines CISSA — the AES-128-CBC construction, the constant IV, and the clear-remainder behaviour in section 3.1.
EBU Tech 3292 v3.0	BISS2 — Basic Interoperable Scrambling System. Source of the mode table in section 12 and the CISSA-replaces-CSA1 change.
EBU Tech 3292 Supplement 1	BISS-CA. Source of section 13, including the EKID and ESID identifiers and the AES-plus-RSA construction.
ISO/IEC 13818-1 / ITU-T H.222.0	MPEG-2 Systems. Defines the CAT, the `CA_descriptor` (tag 0x09), the scrambling-control fields and the rule that PES headers are not scrambled.
ETSI EN 300 468 V1.19.1 (2025-02)	DVB Service Information. Descriptor placement rules referenced in section 6.

19. About the author

Gleb Sazanov

Project Leader

Gleb Sazanov is an accomplished Chief Technology Officer (CTO) with over 20 years of experience in software development, system architecture, and cloud-based solutions. As the CTO of SATLINE, a leading provider of virtual and colocation services tailored to SATCOM businesses, Gleb drives the company’s technological strategy, fostering innovation and efficiency in data center services. His expertise spans various domains, including DevOps, system scaling, and high-performance infrastructure management. With a deep passion for cutting-edge technologies, Gleb plays a pivotal role in shaping the future of the SATCOM industry.

LinkedIn View more articles by Gleb Sazanov Contact SATLINE