Microsoft
`Broadcast Technologies White Paper
`
`MSBDN Receiver Board Implementation
`
`This paper contains requirements and suggestions for implementing hardware and software to support
`Microsoft Broadcast Data Network (MSBDN) streams emanating from a network device. The paper
`describes the equivalent of the media access control (MAC) layer of the network protocol stack.
`
`
`
`
`
`Contents
`Introduction ............................................................................................................................................................. 3
`Data Flow Overview ................................................................................................................................................ 3
`Typical DSS Requirements ................................................................................................................................ 4
`DSS Multi-Packet Transport .................................................................................................................................... 6
`Overview of MPT .............................................................................................................................................. 6
`Sub-SCID Packet Filtering ................................................................................................................................. 9
`CRC Requirements .......................................................................................................................................... 11
`Writing MPT Packets into a Computer’s Memory ........................................................................................... 13
`Device Driver Model ....................................................................................................................................... 14
`DES Decryptor ...................................................................................................................................................... 14
`Requirements ................................................................................................................................................... 15
`RSA-Based 3DES Key Loading ...................................................................................................................... 16
`Inputs ............................................................................................................................................................... 18
`Device Driver Model ....................................................................................................................................... 20
`Tamper Proofing .............................................................................................................................................. 21
`
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`SAMSUNG 1022
`
`1
`
`

`
` MSBDN Receiver Board Implementation — 2
`
`
`
`This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR
`IMPLIED, IN THIS DOCUMENT.
`Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other
`intellectual property rights covering subject matter in this document. The furnishing of this document does not
`give you any license to the patents, trademarks, copyrights, or other intellectual property rights except as
`expressly provided in any written license agreement from Microsoft Corporation.
`Microsoft does not make any representation or warranty regarding specifications in this document or any product
`or item developed based on these specifications. Microsoft disclaims all express and implied warranties,
`including but not limited to the implied warranties or merchantability, fitness for a particular purpose and
`freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any
`warranty of any kind that any item developed based on these specifications, or any portion of a specification, will
`not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any
`country. It is your responsibility to seek licenses for such intellectual property rights where appropriate.
`Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications,
`including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not
`allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not
`apply to you.
`ActiveMovie, ActiveX, BackOffice, Developer Studio, Direct3D, DirectDraw, DirectInput, DirectPlay,
`DirectSound, DirectVideo, DirectX, Microsoft, NetMeeting, NetShow, Visual Basic, Win32, Windows, and
`Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other
`countries. Other product and company names mentioned herein may be the trademarks of their respective owners.
`© 1997 Microsoft Corporation. All rights reserved.
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`2
`
`

`
` MSBDN Receiver Board Implementation — 3
`
`Introduction
`The audience for this paper is network card manufacturers and cryptographic equipment suppliers.
`While the details and diagrams in this paper describe aspects of an implementation to support the
`Digital Satellite System (DSS), a direct broadcast satellite network, some of these techniques are also
`appropriate for implementation on other types of networks, such as corporate Ethernet local area
`networks (LANs). The details of the other implementations are necessarily different from those used
`in the DSS implementation.
`For a more general description of how the components described in this paper fit into a digital system
`of broadcast network clients, see Chapter 4, “Network Receiver and MPEG Display Subsystems,” in
`the Microsoft Broadcast Data Network (MSBDN) Device Driver Kit.
`
`Data Flow Overview
`The following figure shows how data flows through a MSBDN DSS satellite receiver card.
`
` Encrypted Data+control information
`
`MSBDN
`Hardware
`DES
`Engine
`
`DSS
`Hardware
`DES
`Engine
`
`Decrypted Data
`
`PC
`
`Sub-SCID
`Filter
`
`DSS TransportComponents
`
`
`
`Satellite Data
`
`Encrypted
`
`QPSK
`FEC
`
`RSA
`DES-Key
`Loader
`
`SCID
`filter
`
`NDC
`"Verifier"
`
`NDC
`Smart
`Card
`
`Figure 1. Data flow through the MSBDN DSS satellite receiver
`
`A MSBDN receiver card consists of the normal circuitry necessary to tune, decode, demultiplex, error
`correct, and apply DSS access control to the received signal. The DSS transport filters and delivers
`the DSS service channel identifiers (SCIDs) to the input of the sub-SCID filter. The packets selected
`by the sub-SCID filter are passed to the computer through the computer bus interface (typically a PCI
`bus interface), where they are bus mastered into memory.
`
`Note: Figure 1 does not show the optional ability to reassemble certain packet types in the receiver
`card, nor does it show received packets using Cyclic Redundancy Checks (CRCs).
`
`
`The receiver card driver selectively programs bus mastering of packets through the MSBDN data
`encryption standard (DES) decryptor, which in some receiver designs is combined with the DSS DES
`decryptor. The MSBDN DES decryptor decrypts the packets and writes them back to memory.
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`3
`
`

`
` MSBDN Receiver Board Implementation — 4
`
`Typical DSS Requirements
`
`The DSS-specific information contained in this paper is insufficient to complete a DSS-compatible
`satellite receiver. For detailed information on the system requirements and internal workings of a
`DSS-compatible receiver, contact DIRECTV.
`In the DSS environment, a transponder can send information streams at up to 30 megabits per second.
`This stream of information contains substreams, called SCIDs, analogous to packet identifiers (PIDs)
`found in the digital video broadcasting (DVB) system. The different SCIDs carry information such as
`audio, video, and data, which are separated to make decoding easier in a typical set-top device.
`
`Bus and Computer Software Interface
`The satellite receiver card should have bus mastering capability, and the receiver card driver should
`have programmatic access to various functions of the card through the bus interface.
`In some designs, this interface may use I/O address mapping; in others, a memory buffer may be used
`to pass register contents between the computer CPU and the various chips on the receiver card. The
`choice depends largely on which system bus you design the adapter for, Industry Standard
`Architecture (ISA) or PCI.
`You can achieve varying amounts of control over DSS reception through hardware on the receiver
`card, subject to overall design goals. Because a unique receiver card driver exists for each card
`design, a manufacturer can choose to decrease hardware functionality for a card, and increase the
`complexity of the software driver for that card.
`
`Tuning
`The satellite receiver card must perform all normal DSS functions, including tuning functions, QPSK
`demodulation, and forward error correction. The host CPU can control these various functions by
`programming transport registers through the computer bus interface. The receiver card driver can
`check status for these operations through the computer bus interface.
`
`NDS Access Control
`The satellite receiver card must perform all required News Data Systems (NDS) access control
`functions.
`In typical receiver card designs, an on-board CPU handles the verification code for access control by
`communicating with the receiver card driver running on the computer CPU through the computer bus
`interface.
`DIRECTV has mandated that data streams be encrypted using standard NDS access control methods.
`The NDS decryption process must occur before any CRC or sub-SCID filtering can take place.
`The MSBDN access control method is completely independent from NDS access control and occurs
`after the data is written to computer memory.
`
`SCID Filtering
`The satellite receiver card must be able to filter at least five SCIDs. This figure is the minimum
`requirement and is merely adequate for receiving DSS signals. Because the personal computer is a
`more versatile device than a typical set-top device, the hardware design of the satellite receiver card
`should be capable of filtering more than five SCIDs.
`The satellite receiver card must be able to support a total bandwidth into the computer of 30 megabits
`per second for the DSS network.
`
`PCI Bus Mastering
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`4
`
`

`
` MSBDN Receiver Board Implementation — 5
`
`Each SCID must be bus mastered into a separate buffer in computer memory. This rule includes data
`SCIDs, which may be subject to filtering, CRC checking, and other operations; for more information
`on these operations, see following sections in this paper.
`Buffers must be capable of being at least as long as 64K bytes, and as small as 4K bytes. The
`minimum granularity required for buffer sizes is 128 bytes.
`An important consideration in designing PCI bus mastering hardware is that DSS Motion Pictures
`Experts Group (MPEG) packets should not be formed as multiples of 4 bytes. Further, the packet
`transfers are unaligned and may begin on any physical memory address that is valid and page-locked.
`When writing DSS MPEG packets to memory, only the 127 bytes of data should be written. No
`padding is allowed. All received bytes must be written when they arrive. After a set time-out
`determined by the receiver card driver running on the computer CPU, any partially filled large buffers
`must be made available to the computer, even if they are not completely filled. The resulting MPEG
`data is considered a stream by the computer and passed in large blocks directly to the MPEG decoder.
`Passing individual 127-byte blocks to the MPEG decoder causes unacceptable system performance
`degradation due to interrupt overhead.
`
`Ring Buffers
`When a data buffer fills, the satellite receiver card must generate an interrupt and switch to filling
`another prespecified buffer.
`For each high-speed SCID, defined as streams that are 2 megabits per second or faster, you should
`provide a method to implement at least eight buffers. At any one time, the satellite receiver needs to
`process two high-speed SCIDs.
`
`Note: It is best to support more than two SCIDs—over time, individual customers will likely want to
`use more than one high-speed data service. Because high-speed SCIDs are faster than 2 megabits per
`second, with current satellites it is possible to have up to 15 high-speed SCIDs per transponder.
`
`
`For each low-speed SCID (that is, each SCID under 2 megabits per second), you should provide a
`method to implement at least three buffers. At any one time, the satellite receiver needs to be able to
`process five low-speed SCIDs.
`High-speed SCIDs and low-speed SCIDs differ only in the expected sustained bandwidth. Burst
`bandwidth is identical — the full rate of the satellite. High- and low-speed SCIDs are distinguished in
`this paper only to ensure receiver boards can maintain expected rates in regards to interrupt latency,
`buffer setup, and on-board CPU usage. All SCIDs can be high-speed.
`At minimum, the satellite receiver should support bus mastering of satellite data into ping-pong
`buffers (two active buffers) on a per-SCID basis. When either buffer fills, the satellite receiver must
`generate an interrupt. The host CPU must be able to change the address of the nonactive buffer while
`the active buffer is being filled without affecting the filling of the active buffer.
`Ideally, the satellite receiver card should accept a buffer description list from the receiver card driver
`for each SCID that contains information about the location and size of an arbitrary number of buffers;
`the receiver card fills these buffers consecutively and generates interrupts when each is full. The
`receiver card driver should be able to change this buffer list on the fly during typical operation as
`more or fewer buffers become available.
`
`Buffer Time-out
`While filling any buffer for any specified SCID, the satellite receiver card must be capable of being
`forced to change to the next buffer. After the active buffer is changed, the satellite receiver must
`generate an interrupt (as if the buffer were full) and must allow queries on the number of packets that
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`5
`
`

`
` MSBDN Receiver Board Implementation — 6
`
`were actually written. If the satellite receiver is in the middle of writing a packet, it must finish
`writing the entire packet before switching buffers and generating the interrupt.
`An alternate implementation of the buffer time-out is also acceptable: For each ping-pong buffer pair,
`the satellite receiver must be programmable to switch buffers and generate an interrupt after a
`programmable inactivity period of between 1 and 100 microseconds.
`
`Unique Serial Number
`Each receiver card must make the standard DSS serial number of a 5-byte unique integrated
`receiver/decoder (IRD) available to the computer through the bus interface. No additional serial
`numbers are required.
`
`DSS Multi-Packet Transport
`To facilitate easy transmission of computer network traffic over the DSS satellite system, Microsoft
`has created a transport protocol, Multi-Packet Transport (MPT). Multi-Packet Transport handles data
`packets longer than the 127-byte payloads allowed with the usual DSS packet format.
`
`Overview of MPT
`
`This section describes how data is handled at the satellite uplink site before it is sent through the
`satellite multiplexer (MUX). The section is provided for informational purposes only. Satellite
`receiver manufacturers are not required to provide information to the satellite, nor are they required to
`reassemble MPT packets within the satellite receiver board hardware before writing data into
`computer memory. For the current version of Broadcast Architecture, all reassembly is handled within
`the computer’s device driver, using software supplied by Microsoft.
`In MPT, large frames of data are transmitted using methods similar to those used in cell-based
`networks: Each transmitted cell, or packet, contains information used to reconstruct a much larger
`frame of data.
`
`TCP/IP Packets
`
`MSBDN
`Router
`
`MPT frames, split
`into DSS Packets
`
`Satellite
`MUX
`Interface
`
`To Satellite
`
`
`
`Figure 2. DSS multiplexing of IP data
`
`As shown in the preceding figure, Transmission Control Protocol/Internet Protocol (TCP/IP) packets
`arrive at the MSBDN router, where they are wrapped in MPT framing information, then split into
`DSS-sized packets. These DSS packets are then sent to the satellite MUX, where they are uplinked to
`the satellite.
`
`MPT Frame to DSS Packet Conversion
`When the MSBDN router at the satellite uplink site receives a typical computer network packet, the
`router wraps the packet in a general structure that contains a header, the original data, and padding to
`prepare the packet for transmission. The packet is then broken into multiple MPT packets, flag bytes
`are added, and a 32-bit CRC is calculated for all the packets and added to the last 4 bytes of the last
`packet. The following figure illustrates this process.
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`6
`
`

`
` MSBDN Receiver Board Implementation — 7
`
`Initial IP/UDP Packet
`UDP
`Data
`(8)
`(N)
`
`IP
`(20)
`
`Header, Data, and Padding added fit into multiple MPT packets
`Frame Data
`Header
`Padding
`(N+28)
`
`MPT Frame broken up into 127 byte MPT Packets
`Fragment ...
`Fragment K
`Fragment 1
`(120)
`(126)
`(122)
`
`(1)
`
`(1)
`
`(1)
`
`(6)
`
`CRC
`(4)
`
`These
`bytes
`are
`CRC'd
`
`
`
`SOF=1
`EOF=0
`
`SOF=0
`EOF=0
`
`SOF=0
`EOF=1
`
`7 bytes: Flags and SubSCID address if SOF bit=1
`Flags
`SubSCID Address
`(6 bytes)
`(1 byte)
`
`8 bits of Flags for each MPT packet
`Flags=0,0
`Undefined
`SOF=1
`EOF=0
`(2 bits)
`(4 bits)
`(1 bit)
`(1 bit)
`
`Figure 3. Network packet converted to MPT packet
`
`Internal Packet Format
`The following figure compares the formats of the MPT and DSS packets.
`
`Format of a MPT Packet
`
`DSS flags
`(2 bits)
`
`Undefined
`(4 bits)
`
`SOF
`(1 bit)
`
`EOF
`(1 bit)
`
`Sub-SCID
`(6 bytes)
`only if SOF=1
`
`Fragment Data
`(126) bytes)
`
`CRC
`(4 Bytes)
`only if EOF=1
`
`3 Byte DSS Header
`Flags:4bits, SCID:12, Seq:4, Type:4
`
`Format of a DSS Packet
`Payload
`(127 bytes)
`
`FEC
`(17 bytes)
`
`
`
`Figure 4. Formats of MPT and DSS packets (MPT packet shown with SOF=0)
`
`All MPT packets are 127 bytes long. For DSS, the first two bits of the flags byte, the DSS flags, are
`always zero. There are four packet types, based upon the values of the Start Of Frame (SOF) and End
`Of Frame (EOF) bits of the flags byte.
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`7
`
`

`
` MSBDN Receiver Board Implementation — 8
`
`The following table describes the meanings of the possible combinations of SOF and EOF bits.
`
`SOF
`1
`
`EOF
`0
`
`0
`
`0
`
`1
`
`0
`
`1
`
`1
`
`Description
`The first packet of a multiple-packet MPT frame. The 6 bytes
`following the flags are the sub-SCID address, followed by 120 bytes
`of fragment data. The CRC is accumulated on all bytes of this
`packet.
`An intermediate (that is, neither the first, nor the last) packet of a
`multiple-packet MPT frame. The 126 bytes following the flag byte
`are fragment data. The CRC is accumulated on all bytes of this
`packet.
`The last packet of a multiple-packet MPT frame. After the flag byte
`comes 122 bytes of data, then 4 bytes of CRC. The CRC is
`accumulated on the first 123 bytes of this packet.
`The first, last, and only packet of a single-packet MPT frame. The 6
`bytes following the flags are the sub-SCID address, followed by 116
`bytes of data, followed by 4 bytes of CRC. The CRC is accumulated
`on the first 123 bytes of this packet.
`
`All MPT packets have one byte of flags prepended. When the SOF bit of the flags byte is 1, the next
`six bytes are the sub-SCID address. Sub-SCID addresses are identical to the equivalent Ethernet
`address, which would be used over a noncell-based network.
`For all types of MPT packets, the resulting 127 bytes are then fed into a Call Level Interface (CLI)
`multiplexer at the satellite uplink site, which adds 3 bytes of flags and addresses to the beginning of
`the packet and 17 bytes of forward error correcting (FEC) codes to the end. This configuration
`becomes the standard 147-byte DSS packet payload.
`All MPT packets enter the CLI multiplexer aligned on DSS packet boundaries.
`
`
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`8
`
`

`
` MSBDN Receiver Board Implementation — 9
`
`Sub-SCID Packet Filtering
`
`The following figure shows the contents of an MPT packet.
`
`CRC Value Accumulated on these bytes
`
`
`
`7
`
`6
`
`5
`
`4
`
`3
`
`2
`
`1
`
`0
`
`DSS Packet Header
`(SCID, Flags, packet type, continuity counter)
`
`Flags (6 bits)
`
`SOF
`
`EOF
`
`Optional Sub-SCID Address
`(48 bits)
`only if SOF=1
`
`Fragment Data
`(928-1008 Bits)
`
`Optional CRC
`(32 bits)
`only if EOF=1
`
`0 1 2 3 4
`
`9
`10
`
`Figure 5. Contents of an MPT packet
`
`
`Note: The information in the preceding figure was drawn from Frank Baylin’s publication,
`“Miniature Satellite Dishes, The New Digital Television,” Baylin Publications, 1994, page 58, and
`from International Organization for Standardization, International Electrotechnical Commission
`(ISO/IEC) document 13818-1, “Graphics Syntax for ITU-T H.222.0,” page121.
`
`
`Overview of Sub-SCID Filtering
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`9
`
`

`
` MSBDN Receiver Board Implementation — 10
`
`In order to reduce PCI bus traffic, the satellite receiver card should filter out packets from unwanted
`sub-SCIDs. Only packets from specified sub-SCIDs should be passed to the computer; the others
`should be thrown away. The following figure illustrates this filtering process.
`
`Output
`from
`FEC,
`NDC
`Access
`Control
`
`Video SCID
`
`Audio SCID
`
` Data
`SCID0
`
`CRC
`Calculator
`
` Data
`SCID0
`
` Data
`SCID1
`
`CRC
`Calculator
`
` Data
`SCID1
`
`SubSCID
`Filtering:
`
`SubSCIDs
` for SCID0
`
`SubSCIDs
` for SCID1
`
`PC Bus
`
`
`
`Figure 6. SCID versus sub-SCID data flow in the satellite receiver
`
`Sub-SCID Addresses
`Sub-SCID addresses are 48 bits long. They are found in the fourth through ninth octets in a DSS MPT
`packet; octets are groups of eight bits each.
`Satellite receivers should be able to filter at least 16 different sub-SCIDs simultaneously. It is best that
`satellite receivers filter as many sub-SCIDs as possible, in addition to any SCID filtering that is also
`occurring. Many broadcast data satellite systems filter 32 different sub-SCIDs. However, filtering on
`more than 128 sub-SCIDs will not be necessary in the foreseeable future.
`Satellite receivers should also support a “promiscuous” mode, in which they do not filter any sub-
`SCIDs. In this mode, packets from all selected SCIDs (that is, those that the DSS transport decodes)
`pass through.
`Sub-SCID addresses must be capable of being loaded within 10 microseconds. Sub-SCID addresses
`must also be capable of being disabled and enabled with a single operation. In addition, adding and
`deleting a sub-SCID address must not interfere with the processing of other sub-SCID addresses.
`
`Multiple SCID Filtering
`In the future, MPT data may be transmitted on multiple SCIDs. Therefore, a satellite receiver card
`should support the simultaneous reception of MPT data on multiple SCIDs.
`Sub-SCID addresses are synchronized across all SCIDs transmitting MPT data, and sub-SCID packet
`filtering can be performed without regard to which SCID received the data. Sub-SCID addresses are
`not interleaved across multiple SCIDs.
`
`Wide-Band Packet Synchronization
`To support processing of data taken off of an existing IRD’s wide-band port, wide-band packet
`synchronization is provided. Wide-band packet synchronization can determine the required DSS
`packet boundaries.
`If a receiver of the wide-band data port detects 127 contiguous bytes, all of the value zero, the
`receiver must resynchronize its internal packet boundary upon receiving the next nonzero value.
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`10
`
`

`
` MSBDN Receiver Board Implementation — 11
`
`
`Note: Wide-band packet synchronization is relevant only when reading data from the wide-band IRD
`port.
`
`
`
`CRC Requirements
`
`This section describes the requirements for multiple-packet Cyclic Redundancy Checks (CRCs) over
`the DSS satellite system.
`
`Overview
`Multiple-packet CRCs are used to detect dropped packets, as well as packets that make it through the
`FEC yet contain undetected errors.
`Under most circumstances, the FEC detects packets arriving with errors and takes appropriate action.
`In some circumstances, packets arrive containing too many errors for the FEC to correct, and the
`errors occur in such a way that the FEC mistakenly reports that all the errors have been corrected.
`This occurrence happens at a rate of 1/N! where N is the number of bytes that can be corrected. For
`the DSS system, the probability of not detecting such an error condition and falsely reporting a valid
`packet is 2.48E-5.
`
`Error Rate Requirement
`An error rate of under 2.07E-17 is required. To satisfy this requirement, a CRC is provided in each
`block of packets, for the anticipated use of comparison against a calculated value. A 32-bit CRC, used
`when signal conditions are at video threshold, yields this comparison figure.
`Under most circumstances, the real error rate from the FEC does not approach the theoretical worst
`case, even with full signal strength. It has been suggested that the FEC status can be used in lieu of
`the CRC calculation under usual conditions.
`This error rate supposition has not been tested in practice. It may not be possible to detect transient
`poor-signal quality conditions, for example a seagull’s flyby occluding the satellite signal.
`Manufacturers should provide a receiver-driver combination that satisfies the error rate requirement.
`
`End of Frame Marker
`The satellite receiver must accumulate the CRC across multiple packets. An MPT packet’s End Of
`Frame (EOF) bit is set to TRUE (1) to indicate it is the last fragment of the original MPT frame.
`CRCs are calculated independently of sub-SCID filtering.
`The CRC is accumulated for all bytes in the MPT packet, excluding the 4 bytes containing the CRC.
`This accumulation includes MPT flags, as well as the optional 6-byte sub-SCID address. This
`accumulation corresponds to DSS packet bytes 3 through 129, or 3 through 125 if the EOF bit is
`TRUE. The CRC is accumulated in order, byte per byte, from DSS packet bytes 3 through 129 or 125.
`When the EOF condition is detected, the calculated CRC for this SCID should be compared to the
`value in the last packet. The last four bytes in this EOF packet contain a value that must match the
`accumulated CRC. The last four bytes of the EOF packet are not used in the CRC calculation.
`The CRC is stored in the MPT packet in network byte order, also called big endian format. This
`method of storage means that the most significant byte of the CRC is contained in byte 126 of the
`DSS packet, and the least significant byte of the CRC in byte 129.
`For any given SCID containing MPT packets, the receiver card needs to maintain only one CRC
`accumulator. Packets belonging to differing sub-SCIDs are never interleaved. Packets for a new sub-
`SCID never arrive unless the previous MPT packet was an EOF packet; note that this guarantee is for
`DSS systems only.
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`11
`
`

`
` MSBDN Receiver Board Implementation — 12
`
`If the satellite receiver supports MPT packet reception on multiple SCIDs, each SCID has a
`corresponding CRC accumulator, one for each MPT packet being received. Starting and stopping
`multiple MPT frames between SCIDs cannot be synchronized.
`Performing a CRC using a computer’s CPU consumes an unacceptably high amount of the available
`computation resources. Therefore, the satellite receiver card should perform CRC.
`
`CRC Algorithm
`The CRC algorithm used by the DSS satellite receiver card is the same as that used by the MPEG-2
`transport stream as defined in ISO/IEC 13818-1. The generator polynomial is:
`
`1
`
`
`
`2
`4
`5
`7
`8
`10
`D D D D D D D
`
`
`
`
`
`
`
`
`
`11
`
`D
`
`
`
`12
`D
`
`
`
`16
`
`D
`
`
`
`D
`
`As in the ISO/IEC 13818-1 specification, the initial state of the sum is 0xFFFFFFFF. This algorithm
`is not the same as that used by Ethernet.
`
`22
`
`D
`
`
`
`23
`
`D
`
`
`
`26
`
`D
`
`
`
`32
`
`Example Packets
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`12
`
`

`
` MSBDN Receiver Board Implementation — 13
`
`The following is an example of data (specifically, an Internet protocol packet) being carried by MPT
`packets to illustrate byte order and exact outputs. In the two following examples, data is represented
`exactly as it arrives from the satellite, which is also how it must be stored in memory, byte by byte.
`Because all data is treated as a byte stream, there are no big-endian versus little-endian issues, that is,
`the byte order is not an issue. The first example shows a single packet MPT frame, and the second
`example shows a multiple packet MPT frame.
`
`3F 00 00 E9 24 18 24 08 00 45 00 00 61 99 01 00
`00 20 11 41 60 DF DF DF 02 E9 24 18 24 27 06 27
`0F 00 4D 00 00 74 68 69 73 20 69 73 20 74 65 73
`74 2C 20 69 74 27 73 20 66 72 6F 6D 20 32 32 33
`2E 32 33 33 2E 32 32 33 2E 30 32 3A 39 39 39 30
`20 73 65 6E 74 20 74 6F 20 32 33 33 2E 33 36 2E
`32 34 2E 33 36 3A 39 39 39 39 00 00 00 00 00 00
`00 00 00 00 00 00 00 00 01 00 63 4B B1 B9 A9
`
`
`The MPT flags indicate the preceding example packet has both a sub-SCID address (SOF=1) and a
`CRC (EOF=1).
`
`3E 00 00 E9 24 18 24 08 00 45 00 00 B1 99 02 00
`00 20 11 41 0F DF DF DF 02 E9 24 18 24 27 06 27
`0F 00 9D 00 00 74 68 69 73 20 69 73 20 61 20 74
`65 73 74 20 6F 66 20 20 61 20 73 74 72 69 6E 67
`20 74 68 61 74 20 69 73 20 6C 6F 6E 67 65 72 20
`74 68 61 6E 20 61 20 73 69 6E 67 6C 65 20 70 61
`63 6B 65 74 2C 20 61 73 20 6C 65 61 73 74 20 49
`20 74 68 69 6E 6B 20 69 74 27 73 20 6C 6F 6E
`
`3D 67 65 72 20 74 68 61 6E 20 61 20 73 69 6E 67
`6C 65 20 70 61 63 6B 65 74 2C 20 77 65 6C 6C 2C
`20 6A 75 73 74 20 61 62 6F 75 74 2C 20 69 74 20
`73 75 72 65 20 69 73 20 6E 6F 77 2E 00 00 00 00
`00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
`00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
`00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
`00 00 00 00 00 00 00 00 02 00 B3 13 C4 95 B1
`
`
`The MPT flags in the first example packet indicate that the packet contains only a sub-SCID address
`(SOF=1, EOF=0). The MPT flags in the second example packet indicate that the packet contains only
`a CRC (SOF=0, EOF=1).
`
`Writing MPT Packets into a Computer’s
`Memory
`
`Buffers must be capable of being at least as long as 64K bytes, and as small as 4 Kbytes. MPT packets
`must be written in the order in which they arrive.
`
`Raw Packets
`
`© 1997 Microsoft Corporation. All rights reserved.
`
`13
`
`

`
` MSBDN Receiver Board Implementation — 14
`
`The driver software for the satellite receiver card writes MPT packets to a computer’s main memory
`using the computer’s CPU. MPT packets should be written as 128-byte blocks.
`
`Note: MPT packets differ from raw DSS packets that are unaligned and that are written as 127-byte
`blocks.
`
`
`The first byte is written in the form of padding or internal flags, which can be used by the satellite
`receiver card for any internal purpose; in other words, the receiver driver doesn’t “care” about the bits
`in the first byte of the MPT packet. The remaining 127 bytes are octets 3 through 129.
`Buffers must be a multiple of 128 bytes. Packets must be written so they align on DWORD (4-byte)
`boundaries.
`For satellite receivers that calculate CRCs, the last four bytes of the EOF packet should be replaced
`with the Boolean result of the CRC comparison (for example, all ones, or 0xFFFFFFFF). If the
`satellite receiver card does not calculate or compare CRCs, the CRC fields should be left intact; the
`satellite card driver does the calculation in this case.
`Data from individual sub-SCIDs does not need to be written into separate buffers.
`
`Device Driver Model
`
`In addition to the software on the satellite receiver card that handles the usual DSS and MPT
`requirements, the card manufacturer must supply a Windows®-based device driver that allows the
`computer to communicate with the satellite receiver card. The device driver for the computer consists
`of an Network Driver Interface Specification (NDIS) miniport driver, enhanced for Broadcast
`Architecture receiver card control.
`The NDIS port driver is a Microsoft-supplied interface library on the Windows NT® and Windows 95
`operating systems (OS