Multicast network paper as MS WORD 7 document
Download multicast demo software (GPClog, GPCadmin)
Multicast of positionsreports over network.
Distribution of ADS-B reports with a point-to-point type of network will result in high load on the network and consequently high costs for leasing required bandwidth in dedicated networks. This paper is discussing an alternative network architecture and a method of message distribution that could provide a high level of redundancy at low cost. The proposed method is the implementation of a network based on the "multicast" -principle which will result in low load and consequently low capacity requirements. Multicast means that the servers are automatically creating a tree-structure. This technology is implemented and used on many standard off-the-selves servers such as Windows NT and Winsock 2.0. The following figure explains the principle architecture for position reports. (see also Appendix A "Multicasting: A White Paper" and Unicast, Broadcast, and Multicast, "Network Load per Client").
In the simplest system configuration two (2) multicast addresses are used which in the above example are named 234.5.6.7 port 8910 (primary) and 234.5.6.7 port 8911 (secondary). In the above example there are six (6) basestations which are programmed with GPCmultiTX or GPClog that are sending positionreports on the international common primary address (234.5.6.7 port 8910). To support the GPCmultiTX programme the GNSS-Transponder basestations type R2/T2 (from version 11.5; 16 March 1996) include the identity of the base station by setting the parameter NETHEAD EQU 1. Since the base stations should be organised to provide overlapping coverage multiple base stations will receive the same message. Therefore, there will normally be more than one copy of each message in the network on the so-called primary address.
In order to minimise the load on the network and to manage the network one or more computers are used which in this example are called GPCadmin. Only one of these computers are active and the other(s) are on stand-by in case of failing main or master computer. This w ill secure the necessary redundancy of the network system. The software package for the network management computers - GPCadmin - is identical and can operate on a selected number of computers located at different geographical locations in the network. The network management programmes are communicating with each other over the common "multicast address" in order to continuously update the database (tracker) and will establish the priorities in case of failure of the master computer. The switch over time to one of the stand-by computers can be made within maximum 10 seconds.
The main task for GPCadmin is to assemble messages (position reports, etc.) and copies of those from the primary address and to transfer ONE (1) copy of each message to the secondary address, and to update the data base which is monitoring the traffic situation in the network.
The blocks manned USER is a presentation programme (software package) which is using the programme GPC multiRX that is establishing the "multicast" connection and thereafter reception of position reports. This programme should normally be integrated into the application software.
For end-to-end communication, for instance text messages, GPCmultiRX and GPCmultiTX are communicating directly or via GPCadmin through a point-to-point connection based on TCP/IP.
For global implementation it is recommended to use several multicast addresses with different update rates adopted to traffic conditions within the different geographical areas. A detailed description of the application protocols can be found in Appendix B.
The figure below is illustrating the principles of multicast.
Multicast is using INTERNET Class D Addresses in which the four most significant bits in the IP address is 1110 corresponding to IP addresses from 224.0.0.0 to 239.255.255.255. The initiation of multicast is done by using a IGMP (Internet Group Management Protocol) message (specified in RFC 1112 [Deering 1989]). This message is used to notify the servers of a multicast message and is called "joining the multicast group". The message consist of:
0 3 |
4 7 |
8 15 |
16 23 |
24 31 |
IGMP version |
IGMP type 1-2 | (unused) |
16-bit checksum |
|
32- bit group address (class D IP address) |
||||
An IGMP-message is transmitted as part of an IP message (specified in RFC 791 [Postel 1981a]). IGMP is always transmitted to the address 224.0.0.1 which is called the "all-hosts group address". After the initial IGMP the continued transmission or multicast of positionreports is made by using the following IP message.
0 15 |
16 31 |
|||
4-bit version |
header length |
8-bit type of service (TOS) |
16-bit total length (in bytes) |
|
16-bit identification |
3-bit flag |
13-bit fragment offset |
||
8-bit time to live (TTL) |
8-bit protocol |
16-bit header checksum |
||
32-bit source IP address |
||||
32-bit destination IP address |
||||
Data |
||||
Data |
||||
………. |
||||
Data |
||||
Where:
TTL (Time To Live) is describing how many levels of servers that should forward the multicast message. By increasing the TTL the number of levels of "branches" it can be on the "server tree".
Basic position report format from a base station.
The out format from a base station is a string of ASCII characters. The string starts with '$PRGPS,’ followed by the message and finally *## (## = checksum). The checksum is obtained by XOR of all bytes between '$' and '*'. (Note! '$' and '*' are not included). The format and the checksum are in accordance with the NMEA-0183 standard. The string is terminated by CR+LF. The data rate is normally 19200 (9600 is used only for test and trials). The checksum including '*' can be omitted but is to be recommended. Should compatibility with NMEA-0183 not be required, also 'PRGPS,' can be omitted. The string will then start with merely a '$' character. In order to shorten the message length between the base device and the control center, 'PRGPS,’ is not normally used from the base device.
Position: $ITTTTTTTTXXXXXXXYYYYYYYSSSDDDZZZZZNTTS*##+CR+LF
where:
I = type (1*ASCII HEX) 1= own GPS position, 2=incoming position
T = 8 characters identification e.g. SE-GNI_. (8* ASCII)
X = latitude in 1/1000 min. (7*ASCII HEX)
Y = longitude in 1/1000 min. (7*ASCII HEX)
S = speed in knots (3*ASCII HEX)
D = heading/direction in 1/10 degrees (3*ASCII)
Z = altitude in ft (5*ASCII HEX) FFFFF = land/see
N = navigation mode (1*ASCII HEX) 3 = 3-D nav. etc.
T = time for the position in seconds UTC (2*ASCII HEX)
S = climbing/descending, 1=up, F=down (1*ASCII HEX)
With 19200 bps this format is able to update about 42 active mobiles/second.
Networking of base stations.
Base stations can suitably be linked up by connection to a network. The transmission within the network can, of course, for efficiency reasons be carried out by other methods than by ASCII strings. This, however, is a separate subproject which does not concern the mobile GPS transponder. For networking during test and trials nine (9) ASCII characters has been added in the beginning of all messages from base stations. The purpose is to identify from witch base station the majority of messages is coming during the last minute and how many base station received the same message.
CNNNNNNNN$ITTTTTTTT………*##+CR+LF
where:
C = number of base station received the message (1*ASCII hex 1-F)
N = 8 characters id of main base station (8*ASCII).
$ = beginning of standard message from a base station.
MARK! Checksum is calculated between $ and * (the preceding data is not included).
MARK! "C" is computed by the program GPCadmin simply by adding the incoming "C" and use the sum as outgoing "C".
Integrity.
Many user groups are interested to have position information and movements of e.g. it own fleet secured from unauthorised use for instance for commercial or security reasons.
This is not a network issue. The required confidentiality can be provided by using encryption algorithms that is a part of the STDMA concept, and is already used in operational trials.
Appendix A
Microsoft may have patents, 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 these patents, trademarks, copyrights, or other intellectual property.
© 1996 Microsoft Corporation. All rights reserved.
Microsoft, MS, MS-DOS, Visual Basic, Win32, and Windows are registered trademarks, and Visual C++ and Windows NT are trademarks of Microsoft Corporation in the U.S.A. and other countries.
Other product and company names herein may be the trademarks of their respective owners.
Introduction
Unicast, Broadcast, and Multicast
The MBone, LAN, and WAN
How IP Multicasting Works
Summary
As personal computers have increased in power, that power has turned to running multimedia applications on the desktop. Now, multimedia applications are being designed for use on the network. Applications such as audio and video conferencing, and the transmission of live or recorded events using audio and video are only two of the many applications that blend multimedia and the network.
Today's networks are designed to reliably transmit data such as files from point to point. Multimedia places further demands on the network. First, data such as audio cannot tolerate delays in delivery. A network whose basic task is to move files from one place to another can transmit data packets at an uneven rate. If portions of a file arrive slowly or out of order, that is not a problem. Multimedia requires that data packets arrive at the client on time and in the proper order. Real-time protocols and quality of service guarantees on the network address this issue. Second, multimedia requires transmitting large amounts of data over the network and thus uses more of the network's bandwidth than basic network operations such as file transfer. Multicasting, the subject of this paper, addresses this issue.
The bulk of the traffic on today's networks is unicast: A separate copy of the data is sent from the source to each client that requests it. Networks also support broadcasting. When data is broadcast, a single copy of the data is sent to all clients on the network. When the same data needs to be sent to only a portion of the clients on the network, both of these methods waste network bandwidth. Unicast wastes bandwidth by sending multiple copies of the data. Broadcast wastes bandwidth by sending the data to the whole network whether or not the data is wanted. Broadcasting can also slow the performance of client machines needlessly. Each client must process the broadcast data whether the broadcast is of interest or not.
Multicasting takes the strengths of both of these approaches and avoids their weaknesses. Multicasting sends a single copy of the data to those clients who request it. Multiple copies of data are not sent across the network, nor is data sent to clients who do not want it. Multicasting allows the deployment of multimedia applications on the network while minimizing their demand for bandwidth. The following graph compares the network load per client when unicasting an 8 Kbps PCM audio stream and multicasting the stream and shows how a multicast saves bandwidth.
Network Load per Client
Today, the most widely known and used multicast enabled network is the Internet Multicast Backbone, the MBone. The MBone is a virtual network consisting of those portions of the Internet, sometimes called multicast islands, in which multicasting has been enabled. Multicasts that must travel across areas of the Internet that are not yet multicast enabled are sent as unicasts until they reach the next multicast enabled island. This process is referred to as tunneling.
Multicast Islands and Tunnels
The MBone has been in place since 1992 and has grown to more than 2000 subnets. It has been used to multicast live audio and video showing Internet Engineering Task Force conferences, NASA astronauts working in space, and the Rolling Stones in concert. The MBone has successfully demonstrated the practicality and utility of using multicasting to send multimedia across the network.
The hardware for multicasting, chiefly multicast enabled routers and their software, has reached a point where corporations can take advantage of multicasting on their own LANs and WANs. The technology is of benefit in any scenario where several (or hundreds or thousands) of individuals need the same information. Because such information can be multicast live, multicasting is the ideal method to communicate up-to-date information to a wide audience. For example, sales trends for the week could be presented to all regional sales managers via multicast. Events such as a product introduction or important press conference could also be multicast. Multicasts can also support bi-directional communication allowing, for example, individuals in widely dispersed locations to set up a live conference that includes audio, video, and a white board.
Multicasting follows a push model of communications. That is, like a radio or television broadcast, those who want to receive a multicast tune their sets to the station they want to receive. In the case of multicasting, the user is simply instructing the computer's network card to listen to a particular IP address for the multicast. The computer originating the multicast does not need to know who has decided to receive it.
Network Multicasting
Multicasting requires the following mechanisms:
Multicasts are announced in advance so that clients know when a multicast is available. On the MBone, multicasts are typically announced using the Session Description Protocol (SDP). This protocol supplies clients with all the information they need to receive a multicast including its name and description, the times it is active, the type of media (audio, video, text and so on) that it uses, and the IP addresses, ports, and protocol it uses. The announcement information is multicast to a well-known IP address and port where clients running the session directory tool receive this information.
In addition to SDP, there are other ways that multicasts can be announced. For example, on the corporate intranet, multicasts can be advertised using web pages. Controls embedded in the web page can then receive the multicast data.
To signal that they want to receive a multicast, clients join the group to whom the multicast is directed. The Internet Group Management Protocol (IGMP) handles this task.
Multicast groups provide several advantages. Groups are dynamic: clients can join or leave at any time. No elaborate scheme is required to create or disband a group. When a group has no members, it ceases to exist on the network. Groups also scale upward easily because as more clients join a multicast, it becomes more likely that the multicast is already being routed close to them.
When a client joins a group, it initiates two processes: First, an IGMP message is sent to the client's local router to inform the router that the client wants to receive data sent to the group. Second, the client sets its IP process and network card to receive the multicast on the group's address and port. Multicast addresses are Class D IP addresses ranging from 224.0.0.0 to 239.255.255.255. Class D IP addresses map automatically to IEEE-802 Ethernet multicast addresses, which simplifies the implementation of IP multicasting on Ethernet. When a client leaves a group and is the only one receiving the multicast on that particular subnetwork, the router stops sending data to the client's subnetwork, thereby freeing bandwidth on that portion of the network.
The bulk of the work that needs to be done to enable multicasting is performed by the network's routers and the protocols they run. Two years ago major router manufacturers began adding multicasting capability to their routers. Multicasting can be enabled on such routers by simply updating their software and adding memory.
There are several multicast routing protocols in use today: Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First Protocol (MOSPF), and Protocol-Independent Multicast (PIM). The task of these protocols is to create efficient multicast delivery paths through the network. Multicast routing protocols use varying algorithms to achieve efficiency.
Routed Multicast Data Path
An efficient delivery path implies that multicast data travels only to those clients who want to receive it and takes the shortest path to those clients. If data travels elsewhere through the network, bandwidth goes to waste needlessly. You can visualize the network as a tree structure. The source of the multicast sends data through the branches of the tree. The routers are responsible for sending data down the correct branches to other routers and to the subnetworks where members of a group are waiting for data. Routers prune off branches where no one wants data and graft branches back to the tree when a client in a new subnetwork joins the group. Routers can also stop data from traveling to their own subnetworks when it is not wanted.
A new generation of multimedia applications that provide enhanced communication through the use of audio and video are ready to move onto the network. Multicasting provides an efficient way to enable these applications on the network: