In computer networking, a packet is a formatted unit of data carried by a packet mode computer network. Computer communications links that do not support packets, such as traditional point-to-point telecommunications links, simply transmit data as a series of bytes, characters, or bits alone. When data is formatted into packets, the bitrate of the communication medium can be better shared among users than if the network were circuit switched.
A packet consists of two kinds of data: control information and user data (also known as payload). The control information provides data the network needs to deliver the user data, for example: source and destination addresses, error detection codes like checksums, and sequencing information. Typically, control information is found in packet headers and trailers, with payload data in between.
Different communications protocols use different conventions for distinguishing between the elements and for formatting the data. In Binary Synchronous Transmission, 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.
A good analogy is to consider a packet to be like a letter: the header is like the envelope, and the data area is whatever the person puts inside the envelope. A difference, however, is that some networks can break a larger packet into smaller packets when necessary (note that these smaller data elements are still formatted as packets).
A network design can achieve two major results by using packets: error detection and multiple host addressing.
The packet trailer often contains error checking data to detect errors that occur during transmission.
Modern networks usually connect three or more host computers together; in such cases the packet header generally contains addressing information so that the packet is received by the correct host computer. In complex networks constructed of multiple routing and switching nodes, like the ARPANET and the modern Internet, a series of packets sent from one host computer to another may follow different routes to reach the same destination. This technology is called packet switching.
In the seven-layer OSI model of computer networking, 'packet' strictly refers to a data unit at layer 3, the Network Layer. The correct term for a data unit at the Data Link Layer—Layer 2 of the seven-layer OSI model—is a frame, and at Layer 4, the Transport Layer, the correct term is a segment or datagram. Hence, e.g., a TCP segment is carried in one or more IP Layer packets, which are each carried in one or more Ethernet frames—though the mapping of TCP, IP, and Ethernet, to the layers of the OSI model is not exact.
In general, the term packet applies to any message formatted as a packet, while the term datagram is reserved for packets of an "unreliable" service. A "reliable" service is one that notifies the user if delivery fails, while an "unreliable" one does not notify the user if delivery fails. For example, IP provides an unreliable service. Together, TCP and IP provide a reliable service, whereas UDP and IP provide an unreliable one. All these protocols use packets, but UDP packets are generally called datagrams.
When the ARPANET pioneered packet switching, it provided a reliable packet delivery procedure to its connected hosts via its 1822 interface. A host computer simply arranged the data in the correct packet format, inserted the address of the destination host computer, and sent the message across the interface to its connected Interface Message Processor. Once the message was delivered to the destination host, an acknowledgement was delivered to the sending host. If the network could not deliver the message, it would send an error message back to the sending host.
Meanwhile, the developers of CYCLADES and of ALOHAnet demonstrated that it was possible to build an effective computer network without providing reliable packet transmission. This lesson was later embraced by the designers of Ethernet.
If a network does not guarantee packet delivery, then it becomes the host's responsibility to provide reliability by detecting and retransmitting lost packets. Subsequent experience on the ARPANET indicated that the network itself could not reliably detect all packet delivery failures, and this pushed responsibility for error detection onto the sending host in any case. This led to the development of the end-to-end principle, which is one of the Internet's fundamental design assumptions.
After those 160 bits, optional flags can be added of varied length, which can change based on the protocol used, 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, nonduplication 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.
The header of a packet specifies the data type, packet number, total number of packets, and the sender's and receiver's IP addresses.
The term frame is sometimes used to refer to a packet exactly as transmitted over the wire or radio.
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.
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.
Because packet lengths are variable but frame lengths are fixed, packet boundaries usually do not coincide with frame boundaries.
Data in a frame is typically protected from channel errors by error-correcting codes.
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.
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.
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.
|Packet start code prefix||3 bytes||0x000001|
|Stream id||1 byte||Examples: Audio streams (0xC0-0xDF), Video streams (0xE0-0xEF) |
|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.|
|Name||Number of Bits||Description|
|Marker bits||2||10 binary or 0x2 hex|
|Scrambling control||2||00 implies not scrambled|
|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|
|ES rate flag||1|
|DSM trick mode flag||1|
|Additional copy info 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|
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
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.
Making the NICAM bitstream look more like white noise is important because this reduces signal patterning on adjacent TV channels.
Here you can share your comments or contribute with more information, content, resources or links about this topic.