Network packet
A network packet is a formatted unit of data carried by a packet-switched network. A packet consists of control information and user data,[1] which is also known as the payload. Control information provides data for delivering the payload, for example: source and destination network addresses, error detection codes, and sequencing information. Typically, control information is found in packet headers and trailers.
In packet switching, the bandwidth of the communication medium is shared between multiple communication sessions, in contrast to circuit switching, in which circuits are preallocated for the duration of one session and data is typically transmitted as a continuous bit stream.
Terminology
In the seven-layer OSI model of computer networking, packet strictly refers to a protocol data unit at layer 3, the network layer. The correct term for a data unit at layer 2, the data link layer, is a frame, and at Layer 4, the transport layer, the correct term is segment or datagram. For TCP/IP communication over Ethernet, a TCP segment is carried in one or more IP packets, which are each carried in one or more Ethernet frames.
Architecture
The basis of the packet concept is the postal letter: the header is like the envelope, the payload is the entire content inside the envelope, and the footer would be your signature at the bottom. .[2]
Network design can achieve two major results by using packets: error detection and multiple host addressing.
Framing
Different communications protocols use different conventions for distinguishing between the elements of a packet and for formatting the user data. For example, in Point-to-Point Protocol, the packet is formatted in 8-bit bytes, and special characters are used to delimit the different elements. Other protocols like Ethernet, establish the start of the header and data elements by their location relative to the start of the packet. Some protocols format the information at a bit level instead of a byte level.
Contents
A packet may contain any of the following components:
- Addresses
- The routing of network packets requires two network addresses, the source address of the sending host, and the destination address of the receiving host.
- Error detection and correction
- Error detection and correction is performed at various layers in the protocol stack. Network packets may contain a checksum, parity bits or cyclic redundancy checks to detect errors that occur during transmission.
- At the transmitter, the calculation is performed before the packet is sent. When received at the destination, the checksum is recalculated, and compared with the one in the packet. If discrepancies are found, the packet may be corrected or discarded. Any packet loss due to these discards is dealt with by the network protocol.
- In some cases modifications of the network packet may be necessary while routing, in which cases checksums are recalculated.
- Hop counts
- Under fault conditions packets can end up traversing a closed circuit. If nothing was done, eventually the number of packets circulating would build up until the network was congested to the point of failure. A time to live is a field that is decreased by one each time a packet goes through a network node. If the field reaches zero, routing has failed, and the packet is discarded.
- Ethernet packets have no time-to-live field and so are subject to broadcast radiation in the presence of a switch loop.
- Length
- There may be a field to identify the overall packet length. However, in some types of networks, the length is implied by the duration of transmission.
- Priority
- Some networks implement quality of service which can prioritize some types of packets above others. This field indicates which packet queue should be used; a high priority queue is emptied more quickly than lower priority queues at points in the network where congestion is occurring.
- Payload
- In general, payload is the data that is carried on behalf of an application. It is usually of variable length, up to a maximum that is set by the network protocol and sometimes the equipment on the route. When necessary, some networks can break a larger packet into smaller packets.
Example: IP packets
IP packets are composed of a header and payload. The header consists of fixed and optional fields. Then the data that packet carries is added. An IP packet has no trailer. However, an IP packet is often carried as the payload inside an Ethernet frame, which has its own header and trailer.
Many networks do not provide guarantees of delivery, non-duplication of packets, or in-order delivery of packets, e.g., the UDP protocol of the Internet. However, it is possible to layer a transport protocol on top of the packet service that can provide such protection; TCP and UDP are the best examples of layer 4, the Transport Layer, of the seven layered OSI model.
Example: NASA Deep Space Network
The Consultative Committee for Space Data Systems (CCSDS) packet telemetry standard defines the protocol used for the transmission of spacecraft instrument data over the deep-space channel. Under this standard, an image or other data sent from a spacecraft instrument is transmitted using one or more packets.
CCSDS packet definition
A packet is a block of data with length that can vary between successive packets, ranging from 7 to 65,542 bytes, including the packet header.
- Packetized data is transmitted via frames, which are fixed-length data blocks. The size of a frame, including frame header and control information, can range up to 2048 bytes.
- Packet sizes are fixed during the development phase.
Because packet lengths are variable but frame lengths are fixed, packet boundaries usually do not coincide with frame boundaries.
Telecom processing notes
Data in a frame is typically protected from channel errors by error-correcting codes.
- Even when the channel errors exceed the correction capability of the error-correcting code, the presence of errors is nearly always detected by the error-correcting code or by a separate error-detecting code.
- Frames for which uncorrectable errors are detected are marked as undecodable and typically are deleted.
Handling data loss
Deleted undecodable whole frames are the principal type of data loss that affects compressed data sets. In general, there would be little to gain from attempting to use compressed data from a frame marked as undecodable.
- When errors are present in a frame, the bits of the subband pixels are already decoded before the first bit error will remain intact, but all subsequent decoded bits in the segment usually will be completely corrupted; a single bit error is often just as disruptive as many bit errors.
- Furthermore, compressed data usually are protected by powerful, long-blocklength error-correcting codes, which are the types of codes most likely to yield substantial fractions of bit errors throughout those frames that are undecodable.
Thus, frames with detected errors would be essentially unusable even if they were not deleted by the frame processor.
This data loss can be compensated for with the following mechanisms.
- If an erroneous frame escapes detection, the decompressor will blindly use the frame data as if they were reliable, whereas in the case of detected erroneous frames, the decompressor can base its reconstruction on incomplete, but not misleading, data.
- However, it is extremely rare for an erroneous frame to go undetected.
- For frames coded by the CCSDS Reed–Solomon code, fewer than 1 in 40,000 erroneous frames can escape detection.
- All frames not employing the Reed–Solomon code use a cyclic redundancy check (CRC) error-detecting code, which has an undetected frame-error rate of less than 1 in 32,000.
Example: Radio and TV broadcasting
MPEG packetized stream
Packetized Elementary Stream (PES) is a specification defined by the MPEG communication protocol (see the MPEG-2 standard) that allows an elementary stream to be divided into packets. The elementary stream is packetized by encapsulating sequential data bytes from the elementary stream inside PES packet headers.
A typical method of transmitting elementary stream data from a video or audio encoder is to first create PES packets from the elementary stream data and then to encapsulate these PES packets inside an MPEG transport stream (TS) packets or an MPEG program stream (PS). The TS packets can then be multiplexed and transmitted using broadcasting techniques, such as those used in an ATSC and DVB.
PES packet header
| Name | Size | Description |
|---|---|---|
| Packet start code prefix | 3 bytes | 0x000001 |
| Stream id | 1 byte | Examples: Audio streams (0xC0-0xDF), Video streams (0xE0-0xEF) [3][4] |
| Note: The above 4 bytes is called the 32-bit start code. | ||
| PES Packet length | 2 bytes | Can be zero as in not specified for video streams in MPEG transport streams |
| Optional PES header | variable length | |
| Stuffing bytes | variable length | |
| Data | See elementary stream. In the case of private streams the first byte of the payload is the sub-stream number. |
Optional PES header
| Name | Number of Bits | Description |
|---|---|---|
| Marker bits | 2 | 10 binary or 0x2 hex |
| Scrambling control | 2 | 00 implies not scrambled |
| Priority | 1 | |
| Data alignment indicator | 1 | 1 indicates that the PES packet header is immediately followed by the video start code or audio syncword |
| Copyright | 1 | 1 implies copyrighted |
| Original or Copy | 1 | 1 implies original |
| PTS DTS indicator | 2 | 11 = both present, 10 = only PTS |
| ESCR flag | 1 | |
| ES rate flag | 1 | |
| DSM trick mode flag | 1 | |
| Additional copy info flag | 1 | |
| CRC flag | 1 | |
| extension flag | 1 | |
| PES header length | 8 | gives the length of the remainder of the PES header |
| Optional fields | variable length | presence is determined by flag bits above |
| Stuffing Bytes | variable length | 0xff |
NICAM
In order to provide mono "compatibility", the NICAM signal is transmitted on a subcarrier alongside the sound carrier. This means that the FM or AM regular mono sound carrier is left alone for reception by monaural receivers.
A NICAM-based stereo-TV infrastructure can transmit a stereo TV programme as well as the mono "compatibility" sound at the same time, or can transmit two or three entirely different sound streams. This latter mode could be used to transmit audio in different languages, in a similar manner to that used for in-flight movies on international flights. In this mode, the user can select which soundtrack to listen to when watching the content by operating a "sound-select" control on the receiver.
NICAM offers the following possibilities. The mode is auto-selected by the inclusion of a 3-bit type field in the data-stream
- One digital stereo sound channel.
- Two completely different digital mono sound channels.
- One digital mono sound channel and a 352 kbit/s data channel.
- One 704 kbit/s data channel.
The four other options could be implemented at a later date. Only the first two of the ones listed are known to be in general use however.
NICAM packet transmission
The NICAM packet (except for the header) is scrambled with a nine-bit pseudo-random bit-generator before transmission.
- The topology of this pseudo-random generator yields a bitstream with a repetition period of 511 bits.
- The pseudo-random generator's polynomial is: x^9 + x^4 + 1.
- The pseudo-random generator is initialized with: 111111111.
Making the NICAM bitstream look more like white noise is important because this reduces signal patterning on adjacent TV channels.
- The NICAM header is not subject to scrambling. This is necessary so as to aid in locking on to the NICAM data stream and resynchronisation of the data stream at the receiver.
- At the start of each NICAM packet the pseudo-random bit generator's shift-register is reset to all-ones.
See also
References
- ↑ Stallings, William (2001). "Glossary". Business Data Communication (physical book)
|format=requires|url=(help) (4 ed.). Upper Saddle River, New Jersey, USA: Prentice-Hall, Inc. p. 632. ISBN 0-13-088263-1.Packet: A group of bits that includes data plus control information. Generally refers to a network layer (OSI layer 3) protocol data unit.
- ↑ "Understanding The OSI Reference Model: An Analogy", The TCP/IP Guide, archived from the original on 2014-08-09, retrieved 2014-08-09
- ↑ "Standards" (PDF). DVB. Archived (PDF) from the original on 2007-11-17. Retrieved 2014-01-23.
- ↑ Method and apparatus for changing codec to reproduce video and/or audio data streams encoded by different codecs within a channel - Patent EP1827030