XipLink Successfully Demos LTE Using Satellite
Wireless link optimization specialist XipLink has completed a test with a significant Asian cellular service provider, delivering accelerated voice, data and video traffic exceeding 90 megabits per second (Mbps) to a remote LTE base station over a satellite connection...
5 Things We Learned at Global MilSatCom Today
Global MilSatCom is one of the main events for military and communications executives and officials...
Cobham Satcom Debuts Lightweight Sailor VSAT Antenna Systems
Cobham Satcom has revealed two new 60cm Ka-band VSAT antenna systems for maritime customers...
Eutelsat Inks new Broadcast and IoT Deals
Eutelsat Communications has signed up a number of customers in Africa and in Europe for broadcast services, and also tightened it’s collaboration with Internet of Things (IoT) pioneer Sigfox...
Avanti, Global Invacom Demo Encrypted Satellite TV Over Ka-band IP Networks
Avanti Communications and Global Invacom, in partnership with Microsoft and the European Space Agency’s (ESA) Advanced Research in Telecommunications Systems (ARTES) program, are demonstrating satellite broadcasting using standard IP-enabled networks such as Ethernet or Wi-Fi...
Iridium GO! Gains Five Third Party Apps
Iridium has made five mobile applications from third party developers available for Iridium GO!, the company’s global smartphone access device...
Industry Coalition Launched to Extend Role of Satellite Broadcasting
Six leading satellite operators and manufacturers announced the formation of the SAT>IP Alliance at the 2015 NAB Show in Las Vegas, Nev...
New Market Opportunities for Satellite Start to Emerge From Global Connectivity Boom
The “connected car” and “smart cities” are two potentially new and exciting markets the satellite industry could play in over the coming years, particularly the former as the potential for “always-on” connectivity could be a big draw for satellite...
Swiss Space Systems Opens Croatia Subsidiary, Plans Spaceport
Swiss Space Systems (S3) has inaugurated a new subsidiary in Croatia, where the company hopes to build a spaceport as well as a facility for manufacturing the upper stage of the SOAR launch vehicle...
SpaceX Satellite Project Boosted by $1 Billion Google, Fidelity Investment
Google and Fidelity have confirmed an investment of approximately $1 billion in SpaceX, powering the second large-scale Low Earth Orbit (LEO) satellite communications constellation...
GX Launches Getting Dicey after Proton Puts Telecom Satellite in Wrong Orbit
Failed Proton Launch - Opps - Wrong Orbit:
After last Tuesday's failed Proton launch Inmarsat's GX launches look riskier than ever...more
Explore some of the locations with our communication systems.more
dr.sc. Draško Marin, dipl.ing.
«Elektroničke komunikacije-regulativa, sustavi, norme»
Following the launch of the first satellite, Sputnik 1, by the Soviet Union in October, 1957, the US successfully launched the Explorer 1 satellite in 1958. The first commercial communications satellite was Telstar 1, built by Bell Labs and launched in July, 1962.
The idea of a geostationary satellite — one that could orbit the Earth above the equator and remain fixed by following the Earth’s rotation — was first proposed by science fiction writer Arthur C. Clarke in 1945. The first satellite to successfully reach geostationary orbit was Syncom3, built by Hughes Aircraft for NASA and launched Aug. 19, 1963. Succeeding generations of communications satellites featuring larger capacities and improved performance characteristics were adopted for use in television delivery, military applications and telecommunications purposes. Following the invention of the Internet and the World Wide Web, geostationary satellites attracted interest as a potential means of providing Internet access.
A significant enabler of satellite-delivered Internet has been the opening up of the Ka band for satellites. In December, 1993, Hughes Aircraft Co. filed with the Federal Communications Commission for a license to launch the first Ka-band satellite, Spaceway. In 1995, the FCC issued a call for more Ka-band satellite applications, attracting applications from 15 companies. Among those were EchoStar, Lockheed Martin, GE-Americom, Motorola and KaStar Satellite, which later became WildBlue.
Among prominent aspirants in the early-stage satellite Internet sector was Teledesic, an ambitious and ultimately failed project funded in part by Microsoft that ended up costing more than $9 billion. Teledesic's idea was to create a broadband satellite constellation of hundreds of low-orbiting satellites in the Ka-band frequency, providing inexpensive Internet access with download speeds of up to 720 Mbit/s. The project was abandoned in 2003. Teledesic's failure, coupled with the bankruptcy filings of the satellite communications providers Iridium Communications Inc. and Globalstar, dampened marketplace enthusiasm for satellite Internet development. It wasn’t until September 2003 when the first Internet-ready satellite for consumers was launched by Eutelsat.
In 2004 with the launch of Anik F2, the first high throughput satellite, a class of next-generation satellites providing improved capacity and bandwidth became operational. More recently, high throughput satellites such as ViaSat's ViaSat-1 satellite in 2011 and HughesNet’s Jupiter in 2012 have achieved further improvements, elevating downstream data rates from 1-3 Mbit/s up to 12-15Mbit/s and beyond. Internet access services tied to these satellites are targeted largely to rural residents as an alternative to Internet service via dial-up, ADSL or classic FSSes.
ViaSat-1, the highest capacity communications satellite in the world, was launched Oct. 19, 2011 from Baikonur, Kazakhstan. With 140 Gbit/s total throughput capacity, the new satellite services the Exede Internet service, with download and upload speeds much faster than anything previously offered in the satellite industry.
The EchoStar XVII satellite with JUPITER High-Throughput Technology, built by Space Systems/Loral, was launched July 5, 2012 by Arianespace and was placed in its permanent geosynchronous orbital slot of 107.1° West longitude. The satellite services the HughesNet Gen4 satellite Internet service. Employing a multi-spot beam, bent-pipe architecture, this Ka-band satellite has over 100 Gbit/s of throughput capacity.
SkyTerra-1 was launched in mid-November 2010 and will provide service across North America while Hylas-1 was launched at the end of November 2010 and will target Europe.
On December 26, 2010, Eutelsat's KA-SAT was successfully launched by an ILS Proton Breeze M vehicle at the Baïkonour Cosmodrome Kazakhstan. The last satellite was due in service in mid-2011. It covers the European continent with 80 spot beams—focused signals that cover an area a few hundred kilometers across Europe and the Mediterranean. Spot beams allow for frequencies to be effectively reused in multiple regions without interference. The result is increased capacity. Each of the spot beams will have an overall capacity of 900 Mbit/s and the entire satellite will have a capacity of 70 Gbit/s.
Satellite Internet access is Internet access provided through communications satellites. Modern satellite Internet service is typically provided to users through geostationary satellites that can offer high data speeds, with newer satellites achieving downstream data speeds up to 15 Mbps
Satellite Internet generally relies on three primary components: a satellite in geostationary orbit (sometimes referred to as a geosynchronous Earth orbit, or GEO), a number of ground stations known as gateways that relay Internet data to and from the satellite via radio waves (microwave), and a VSAT (very-small-aperture terminal) dish antenna with a transceiver, located at the subscriber's premises. Other components of a satellite Internet system include a modem at the user end which links the user's network with the transceiver, and a centralized network operations center (NOC) for monitoring the entire system. Working in concert with a broadband gateway, the satellite operates a Star network topology where all network communication passes through the network's hub processor, which is at the center of the star. With this configuration, the number of remote VSATs that can be connected to the hub is virtually limitless.
At the center of the new broadband satellite networks are a new generation of high-powered GEO satellites positioned 35,786 kilometres (22,236 mi) above the equator, operating in Ka-band (18.3–30 GHz) mode. These new purpose-built satellites are designed and optimized for broadband applications, employing many narrow spot beams, which target a much smaller area than the broad beams used by earlier communication satellites. This spot beam technology allows satellites to reuse assigned bandwidth multiple times, enabling them to achieve much higher capacity than conventional broad beam satellites. The spot beams also increase performance and consequential capacity by focusing more power and increased receiver sensitivity into concentrated areas. Spot beams are designated as one of two types: subscriber spot beams, which transmit to and from the subscriber-side terminal, and gateway spot beams, which transmit to/from a service provider ground station.
In conjunction with the satellite's spot-beam technology, a bent-pipe architecture is employed in the network in which the satellite functions as a bridge in space, connecting two communication points on the ground. The term “bent-pipe” is used to describe the shape of the data path between sending and receiving antennas, with the satellite positioned at the point of the bend. Simply put, the satellite's role in this network arrangement is to relay signals from the end user’s terminal to the ISP’s gateways, and back again. The satellite receives, amplifies, and redirects signals carried on a specific radio frequency through a signal path called a transponder.
The satellite has its own set of antennas to receive communication signals from Earth and to transmit signals to their target location. These antennas and transponders are part of the satellite’s “payload”, which is designed to receive and transmit signals to and from various places on Earth. What enables this transmission and reception in the payload transponders is a repeater subsystem (RF (radio frequency) equipment) used to change frequencies, filter, separate, amplify and group signals before routing them to their destination address on Earth. The satellite’s high-gain receiving antenna passes the transmitted data to the transponder which filters, translates and amplifies them, then redirects them to the transmitting antenna on board. The signal is then routed to a specific ground location through a channel known as a carrier. Beside the payload, the other main component of a communications satellite is called the bus, which comprises all equipment required to move the satellite into position, supply power, regulate equipment temperatures, provide health and tracking information, and perform numerous other operational tasks.
Along with dramatic advances in satellite technology over the past decade, ground equipment has similarly evolved, benefiting from higher levels of integration and increasing processing power, expanding both capacity and performance boundaries. The Gateway—or Gateway Earth Station (its full name)—is also referred to as a ground station, teleport or hub. The term is sometimes used to describe just the antenna dish portion, or it can refer to the complete system with all associated components. In short, the gateway receives radio wave signals from the satellite on the last leg of the return or upstream payload, carrying the request originating from the end-user’s site. The satellite modem at the gateway location demodulates the incoming signal from the outdoor antenna into IP packets and sends the packets to the local network. Access server/gateways manage traffic transported to/from the Internet. Once the initial request has been processed by the gateway’s servers, sent to and returned from the Internet, the requested information is sent back as a forward or downstream payload to the end-user via the satellite, which directs the signal to the subscriber terminal. Each Gateway provides the connection to the Internet backbone for the gateway spot-beam(s) it serves. The system of gateways comprising the satellite ground system provides all network services for satellite and corresponding terrestrial connectivity. Each gateway provides a multiservice access network for subscriber terminal connections to the Internet. In the continental United States, because it is north of the equator, all gateway and subscriber dish antenna must have an unobstructed view of the southern sky. Because of the satellite’s geostationary orbit, the gateway antenna can stay pointed at a fixed position.
At the far end of the outdoor unit is a small (2–3-foot diameter), reflective dish-type radio antenna constructed from and coated with a variety of materials. As indicated earlier, like the antenna used by the gateway, the VSAT antenna must also have an unobstructed view of the southern sky to allow for proper line-of-sight (L-O-S) to the satellite. There are four characteristic settings used to ensure that the antenna is configured correctly at the satellite, which are: azimuth, elevation, polarization, and skew. The combination of these settings gives the outdoor unit a L-O-S to the chosen satellite and makes data transmission possible. These parameters are generally set at the time the equipment is installed, along with a beam assignment (Ka-band only); these steps must all be taken prior to the actual activation of service. Transmit and receive components are mounted at the focal point of the antenna which receives/sends data from/to the satellite. The main parts are:
Feed – This assembly is part of the VSAT receive and transmit chain, which consists of several components with different functions, including the feed horn at the front of the unit, which resembles a funnel and has the task of focusing the satellite microwave signals across the surface of the dish reflector. The feed horn both receives signals reflected off the dish’s surface and transmits outbound signals back to the satellite.
Block upconverter (BUC) – This unit sits behind the feed horn and may be part of the same unit, but a larger (higher wattage) BUC could be a separate piece attached to the base of the antenna. Its job is to convert the signal from the modem to a higher frequency and amplify it before it is reflected off the dish and towards the satellite.
Low-noise block downconverter (LNB) – This is the receiving element of the terminal. The LNB’s job is to amplify the received satellite radio signal bouncing off the dish and filter out the noise, which is any signal not carrying valid information. The LNB passes the amplified, filtered signal to the satellite modem at the user’s location.
The satellite modem serves as an interface between the outdoor unit and customer-provided equipment (i.e. PC, router) and controls satellite transmission and reception. From the sending device (computer, router, etc.) it receives an input bitstream and converts or modulates it into radio waves, reversing that order for incoming transmissions, which is called demodulation. It provides two types of connectivity:
Coaxial cable (COAX) connectivity to the satellite antenna. The cable carrying electromagnetic satellite signals between the modem and the antenna generally is limited to be no more than 150 feet in length.
Ethernet connectivity to the computer, carrying the customer’s data packets to and from the Internet content servers.
Satellite modems employ either the DOCSIS (Data Over Cable Service Interface Specification) or WiMAX (World Interoperability for Microwave Access) telecommunication standard to communicate with the assigned gateway.
Latency is the delay between requesting data and the receipt of a response, or in the case of one-way communication, between the actual moment of a signal's broadcast and the time it is received at its destination. The amount of latency depends on the distance travelled and the speed of light. Light including wireless radiation would take about 0.12 seconds to reach a geostationary satellite (at 36,000 km above the equator), so nearly 1/4 second for a round trip. Latency is the main difference between a standard terrestrial based network and a geostationary satellite network. The round trip latency of a geostationary satellite communication's network is almost 20 times that of a terrestrial based network.
A geostationary orbit (or geostationary Earth orbit/GEO) is a geosynchronous orbit directly above the Earth's equator (0° latitude), with a period equal to the Earth's rotational period and an orbital eccentricity of approximately zero (i.e. "circular orbit"). An object in a geostationary orbit appears motionless, at a fixed position in the sky, to ground observers. Communications satellites and weather satellites are often given geostationary orbits, so that the satellite antennas that communicate with them do not have to move to track them, but can be pointed permanently at the position in the sky where they stay. Due to the constant 0° latitude and circularity of geostationary orbits, satellites in GEO differ in location by longitude only.
Compared to ground-based communication, all geostationary satellite communications experience high latency due to the signal having to travel 35,786 km (22,236 mi) to a satellite in geostationary orbit and back to Earth again. Even at the speed of light (about 300,000 km/s or 186,000 miles per second), this delay can be significant. If all other signaling delays could be eliminated, it still takes a radio signal about 250 milliseconds (ms), or about a quarter of a second, to travel to the satellite and back to the ground. The absolute minimum total amount of delay is variable, due to the satellite staying in one place in the sky, while ground based users can be directly below with a roundtrip latency of 239.6 ms, or far to the side of the planet near the horizon with a roundtrip latency of 279.0 ms.
For an internet packet, that delay is doubled before a reply is received. That is the theoretical minimum. Factoring in other normal delays from network sources gives a typical one-way connection latency of 500–700 ms from the user to the ISP, or about 1,000–1,400 ms latency for the total round-trip time (RTT) back to the user. This is much more than most dial-up users experience at typically 150–200 ms total latency, and two orders of magnitude higher than the typical 15-40 ms latency experienced by users of other high-speed internet services, such as cable or VDSL.
For geostationary satellites, there is no way to eliminate latency, but the problem can be somewhat mitigated in Internet communications with TCP acceleration features that shorten the round trip time (RTT) per packet by splitting the feedback loop between the sender and the receiver. Such acceleration features are usually present in recent technology developments embedded in new satellite Internet services.
Latency also impacts the initiation of secure Internet connections such as SSL which require the exchange of numerous pieces of data between web server and web client. Although these pieces of data are small, the multiple round trips involved in the handshake produce long delays compared to other forms of Internet connectivity, as documented by Stephen T. Cobb in a 2011 report published by the Rural Mobile and Broadband Alliance. This annoyance extends to entering and editing data using some Software as a Service or SaaS applications as well as other forms of online work.
The functionality of live interactive access to a distant computer—such as virtual private networks—is working much better with the new generation of satellite Internet service than in the past.
Medium Earth orbit (MEO) and low Earth orbit (LEO) satellites do not have such great delays. For example:
The current LEO constellations of Globalstar and Iridium satellites have delays of less than 40 ms round trip, but their throughput is less than broadband at 64 kbit/s per channel. The Globalstar constellation orbits 1,420 km above the earth and Iridium orbits at 670 km altitude.
The proposed O3b Networks MEO constellation scheduled for deployment in 2013 would orbit at 8,062 km, with RTT latency of approximately 125 ms. The proposed new network is also designed for much higher throughput with links well in excess of 1 Gbit/s (Gigabits per second).
The planned COMMStellation, scheduled for launch in 2015, will orbit the earth at 1,000 km with a latency of approximately 7 ms. This polar orbiting constellation of 78 microsatellites will provide global backhaul with throughput in excess of 1.2 Gbit/s.
Unlike geostationary satellites, low and medium Earth orbit satellites do not stay in a fixed position in the sky. Consequently, ground based antennas cannot be easily locked into communication with any one specific satellite. As with GPS, the small orbits may cause a low Earth orbit satellite to only be in the sky for an hour or less before it goes over the horizon and out of range, so a complex relaying and passing-off needs to be done to hand over the fixed-position terrestrial signal to other satellites passing overhead.
Communications with MEO or LEO satellites that are moving in the sky can be done in two ways:
More diffuse or completely omnidirectional ground antennas capable of communicating with one or more satellites visible in the sky at the same time, but at significantly higher transmit power than fixed geostationary dish antennas (due to the lower gain), and with much poorer signal to noise ratios for receiving the signal.
Tracking, high-gain, narrow beam antennas, but the tracking requires more expensive solutions like a motorized antenna mount or a dynamic phased array antanna that can steer the beam electronically, and complex software that can predict the path of each satellite in the constellation.
Satellite communications are affected by moisture and various forms of precipitation (such as rain or snow) in the signal path between end users or ground stations and the satellite being utilized. This interference with the signal is known as rain fade. The effects are less pronounced on the lower frequency 'L' and 'C' bands, but can become quite severe on the higher frequency 'Ku' and 'Ka' band. For satellite Internet services in tropical areas with heavy rain, use of the C band (4/6 GHz) with a circular polarisation satellite is popular. Satellite communications on the Ka band (19/29 GHz) can use special techniques such as large rain margins, adaptive uplink power control and reduced bit rates during precipitation.
Rain margins are the extra communication link requirements needed to account for signal degradations due to moisture and precipitation, and are of acute importance on all systems operating at frequencies over 10 GHz.
The amount of time during which service is lost can be reduced by increasing the size of the satellite communication dish so as to gather more of the satellite signal on the downlink and also to provide a stronger signal on the uplink. In other words, increasing antenna gain through the use of a larger parabolic reflector is one way of increasing the overall channel gain and, consequently, the signal-to-noise (S/N) ratio, which allows for greater signal loss due to rain fade without the S/N ratio dropping below its minimum threshold for successful communication.
Modern consumer-grade dish antennas tend to be fairly small, which reduces the rain margin or increases the required satellite downlink power and cost. However, it is often more economical to build a more expensive satellite and smaller, less expensive consumer antennas than to increase the consumer antenna size to reduce the satellite cost.
Large commercial dishes of 3.7 m to 13 m diameter are used to achieve large rain margins and also to reduce the cost per bit by requiring far less power from the satellite. Satellites typically use photovoltaic solar power, so there is no expense for the energy itself, but a more powerful satellite will require larger, more powerful solar panels and electronics, often including a larger transmitting antenna. The larger satellite components not only increase materials costs but also increase the weight of the satellite, and in general, the cost to launch a satellite into an orbit is directly proportional to its weight. (In addition, since satellite launch vehicles [i.e. rockets] have specific payload size limits, making parts of the satellite larger may require either more complex folding mechanisms for parts of the satellite like solar panels and high-gain antennas, or upgrading to a more expensive launch vehicle that can handle a larger payload.)
Typically a completely clear line of sight between the dish and the satellite is required for the system to work. In addition to the signal being susceptible to absorption and scattering by moisture, the signal is similarly impacted by the presence of trees and other vegetation in the path of the signal. As the radio frequency decreases, to below 900 MHz, penetration through vegetation increases, but most satellite communications operate above 2 GHz making them sensitive to even minor obstructions such as tree foliage.
The radio signal width between any two antennas is not perfectly straight and uniform, as if it were a beam of light. Instead as the signal propagates away from the transmitting antenna, it widens towards the centerpoint between the two antennas and then narrows again as it approaches the receiving antenna. This is known as the Fresnel zone (named for physicist Augustin-Jean Fresnel), and limits the usefulness of satellite dish antennas in locations where there is extremely limited open sky for signal reception. The signal path through space must be clear not only for direct line of sight, but also for the expanding Fresnel zone.
Two-way satellite Internet service involves both sending and receiving data from a remote very-small-aperture terminal (VSAT) via satellite to a hub telecommunications port (teleport), which then relays data via the terrestrial Internet. The satellite dish at each location must be precisely pointed to avoid interference with other satellites. The two way satellite market can be divided into those systems that support professional applications, such as banking, retail etc. and those built to provide home or small business users with access. The key difference between these systems can be seen in their ability to support advanced quality of service controls. While systems for professionals such as those from iDirect will allow the operator to define and meet strict service level.
There are several types of two way satellite Internet services, including time division multiple access (TDMA) and single channel per carrier (SCPC). Two-way systems can be simple VSAT terminals with a 60–100 cm dish and output power of only a few watts intended for consumers and small business or larger systems which provide more bandwidth. Such systems are frequently marketed as "satellite broadband" and can cost two to three times as much per month as land-based systems such as ADSL. The modems required for this service are often proprietary, but some are compatible with several different providers.
Satellite internet customers range from individual home users with one PC to large remote business sites with several hundred PCs.
Home users tend to use shared satellite capacity to reduce the cost, while still allowing high peak bit rates when congestion is absent. There are usually restrictive time-based bandwidth allowances so that each user gets their fair share, according to their payment. When a user exceeds their allowance, the company may slow down their access, deprioritise their traffic or charge for the excess bandwidth used.
The uplink direction for shared user customers is normally time division multiple access (TDMA), which involves transmitting occasional short packet bursts in between other users (similar to how a cellular phone shares a cell tower)
Each remote location may also be equipped with a telephone modem; the connections for this are as with a conventional dial-up ISP. Two-way satellite systems may sometimes use the modem channel in both directions for data where latency is more important than bandwidth, reserving the satellite channel for download data where bandwidth is more important than latency, such as for file transfers.
These usually come in the shape of a self-contained flat rectangular box that needs to be pointed in the general direction of the satellite—unlike VSAT the alignment need not be very precise and the modems have built in signal strength meters to help the user align the device properly. The modems have commonly used connectors such as Ethernet or Universal Serial Bus (USB). Some also have an integrated Bluetooth transceiver and double as a satellite phone. The modems also tend to have their own batteries so they can be connected to a laptop without draining its battery. The most common such system is INMARSAT's BGAN—these terminals are about the size of a briefcase and have near-symmetric connection speeds of around 350–500 kbit/s. Smaller modems exist like those offered by Thuraya but only connect at 444 kbit/s in a limited coverage area.
For many years satellite phones have been able to connect to the internet. Bandwidth varies from about 24 kbit/s for Iridium network satellites and ACeS based phones to 15 kbit/s upstream and 60 kbit/s downstream for Thuraya handsets. Globalstar also provides internet access at 96 kbit/s—like Iridium and ACeS a dial-up connection is required and is billed per minute, however both Globalstar and Iridium are planning to launch new satellites offering always-on data services at higher rates. With Thuraya phones the 96 kbit/s dial-up connection is also possible, the 60 kbit/s service is always-on and the user is billed for data transferred. The phones can be connected to a laptop or other computer using a USB or RS-232 interface. Due to the low bandwidths involved it is extremely slow to browse the web with such a connection, but useful for sending email, Secure Shell data and using other low-bandwidth protocols. Since satellite phones tend to have omnidirectional antennas no alignment is required as long as there is a line of sight between the phone and the satellite.
If you have information (a lot of information, usually) that should be transmitted to various (but usually not all) hosts over an internet, then Multicast is the answer. One common situation in which it is used is when distributing real time audio and video to the set of hosts which have joined a distributed conference.
Multicast is much like radio or TV in the sense that only those who have tuned their receivers (by selecting a particular frequency they are interested on) receive the information. That is: you hear the channel you are interested in, but not the others.
Unicast is anything that is not broadcast nor multicast. When you send a packet and there is only one sender process -yours- and one recipient process (the one you are sending the packet to), then this is unicast. TCP is, by its own nature, unicast oriented. UDP supports a lot more paradigms, but if you are sending UDP packets and there is only one precess supposed to receive them, this is unicast too.
With today's technology it is possible to afford the "cost" of making a unicast connection with everyone who wants to see your web page. However, if you are to send audio and video, which needs a huge amount of bandwidth compared with web applications, you have -you had, until multicast came into scene- two options: to establish a separate unicast connection with each of the recipients, or to use broadcast. The first solution is not affordable: if we said that a single connection sending audio/video consumes a huge bandwidth, imagine having to establish hundreds or, may be, thousands of those connections. Both the sending computer and your network would collapse.
Broadcast seems to be a solution, but it's not certainly the solution. If you want all the hosts in your LAN to attend the conference, you may use broadcast. Packets will be sent only once and every host will receive them as they are sent to the broadcast address. The problem is that perhaps only a few of the hosts and not all are interested in those packets. Furthermore: perhaps some hosts are really interested in your conference, but they are outside of your LAN, a few routers away. And you know that broadcast works fine inside a LAN, but problems arise when you want broadcast packets to be routed across different LANs.
The best solution seems to be one in which you send packets to a certain special address (a certain frequency in radio/TV transmissions). Then, all hosts which have decided to join the conference will be aware of packets with that destination address, read them when they traverse the network, and pass them to the IP layer to be demultiplexed. This is similar to broadcasting in that you send only one broadcast packet and all the hosts in the network recognize and read it; it differs, however, in that not all multicast packets are read and processed, but only those that were previously registered in the kernel as being "of interest".
Those special packets are routed at kernel level like any packet because they are IP packets. The only difference might reside in the routing algorithm which tells the kernel where to route or not to route them.
The range of IP addresses is divided into "classes" based on the high order bits of a 32 bits IP address:
Bit --> 0 31 Address Range:
|0| Class A Address | 0.0.0.0 - 127.255.255.255
|1 0| Class B Address | 220.127.116.11 - 18.104.22.168
|1 1 0| Class C Address | 192.0.0.0 - 22.214.171.124
|1 1 1 0| MULTICAST Address | 126.96.36.199 - 188.8.131.52
|1 1 1 1 0| Reserved | 240.0.0.0 - 247.255.255.255
The one which concerns us is the "Class D Address". Every IP datagram whose destination address starts with "1110" is an IP Multicast datagram.
The remaining 28 bits identify the multicast "group" the datagram is sent to. Following with the previous analogy, you have to tune your radio to hear a program that is transmitted at some specific frequency, in the same way you have to "tune" your kernel to receive packets sent to an specific multicast group. When you do that, it's said that the host has joined that group in the interface you specified.
There are some special multicast groups, say "well known multicast groups", you should not use in your particular applications due the special purpose they are destined to:
All this special multicast groups are regularly published in the "Assigned Numbers" RFC.
In any case, range 184.108.40.206 through 220.127.116.11 is reserved for local purposes (as administrative and maintenance tasks) and datagrams destined to them are never forwarded by multicast routers. Similarly, the range 18.104.22.168 to 22.214.171.124 has been reserved for "administrative scoping".
Hosts can be in three different levels of conformance with the Multicast specification, according to the requirements they meet.
Level 0 is the "no support for IP Multicasting" level. Lots of hosts and routers in the Internet are in this state, as multicast support is not mandatory in IPv4 (it is, however, in IPv6). Not too much explanation is needed here: hosts in this level can neither send nor receive multicast packets. They must ignore the ones sent by other multicast capable hosts.
Level 1 is the "support for sending but not receiving multicast IP datagrams" level. Thus, note that it is not necessary to join a multicast group to be able to send datagrams to it. Very few additions are needed in the IP module to make a "Level 0" host "Level 1-compliant".
Level 2 is the "full support for IP multicasting" level. Level 2 hosts must be able to both send and receive multicast traffic. They must know the way to join and leave multicast groups and to propagate this information to multicast routers. Thus, they must include an Internet Group Management Protocol (IGMP) implementation in their TCP/IP stack.
Broadcast is (in comparison) easier to implement than multicast. It doesn't require processes to give the kernel some rules regarding what to do with broadcast packets. The kernel just knows what to do: read and deliver all of them to the proper applications.
With multicast, however, it is necessary to advise the kernel which multicast groups we are interested in. That is, we have to ask the kernel to "join" those multicast groups. Depending on the underlying hardware, multicast datagrams are filtered by the hardware or by the IP layer (and, in some cases, by both). Only those with a destination group previously registered via a join are accepted.
Essentially, when we join a group we are telling the kernel: "OK. I know that, by default, you ignore multicast datagrams, but remember that I am interested in this multicast group. So, do read and deliver (to any process interested in them, not only to me) any datagram that you see in this network interface with this multicast group in its destination field".
Some considerations: first, note that you don't just join a group. You join a group on a particular network interface. Of course, it is possible to join the same group on more than one interface. If you don't specify a concrete interface, then the kernel will choose it based on its routing tables when datagrams are to be sent. It is also possible that more than one process joins the same multicast group on the same interface. They will all receive the datagrams sent to that group via that interface.
As said before, any multicast-capable hosts join the all-hosts group at start-up , so "pinging" 126.96.36.199 returns all hosts in the network that have multicast enabled.
Finally, consider that for a process to receive multicast datagrams it has to ask the kernel to join the group and bind the port those datagrams were being sent to. The UDP layer uses both the destination address and port to demultiplex the packets and decide which socket(s) deliver them to.
When a process is no longer interested in a multicast group, it informs the kernel that it wants to leave that group. It is important to understand that this doesn't mean that the kernel will no longer accept multicast datagrams destined to that multicast group. It will still do so if there are more precesses who issued a "multicast join" petition for that group and are still interested. In that case the host remains member of the group, until all the processes decide to leave the group.
Even more: if you leave the group, but remain bound to the port you were receiving the multicast traffic on, and there are more processes that joined the group, you will still receive the multicast transmissions.
The idea is that joining a multicast group only tells the IP and data link layer (which in some cases explicitly tells the hardware) to accept multicast datagrams destined to that group. It is not a per-process membership, but a per-host membership.
Using a new technology usually carries some advantages and disadvantages. The advantages of multicast are -I think- clear. The main disadvantage is that hundreds of hosts and, specially, routers don't support it yet. As a consequence, people who started working on multicast, bought new equipment, modified their operating systems, and built multicast islands in their local places. Then they discovered that it was difficult to communicate with people doing similar things because if only one of the routers between them didn't support multicast there was nothing to do...
The solution was clear: they decided to build a virtual multicast network in the top of the Internet. That is: sites with multicast routers between them could communicate directly. But sites joined across unicast routers would send their island's multicast traffic encapsulated in unicast packets to other multicast islands. Routers in the middle would not have problems, as they would be dealing with unicast traffic. Finally, in the receiving site, traffic would be de-encapsulated, and sent to the island in the original multicast way. Two ends converting from multicast to unicast, and then again to multicast define what is called a multicast tunnel.
The MBone or Multicast Backbone is that virtual multicast network based on multicast islands connected by multicast tunnels.
One trivial algorithm to make worldwide multicast traffic available everywhere could be to send it... everywhere, despite someone wants it or not. As this does not seem quite optimized, several routing algorithms and forwarding techniques have been implemented.
DVMRP (Distance Vector Multicast Routing Protocol) is, perhaps, the one most multicast routers use now. It is a dense mode routing protocol, that is, it performs well in environments with high bandwidth and densely distributed members. However, in sparse mode scenarios, it suffers from scalability problems.
Together with DVMRP we can find other dense mode routing protocols, such as MOSPF (Multicast Extensions to OSPF - Open Shortest Path First -) and PIM-DM (Protocol-Independent Multicast Dense Mode).
To perform routing in sparse mode environments, we have PIM-SM (Protocol Independent Multicast Sparse Mode) and CBT (Core Based Trees).
All this routing protocols use some type of multicast forwarding, such as flooding, Reverse Path Broadcasting (RPB), Truncated Reverse Path Broadcasting (TRPB), Reverse Path Multicasting (RPM) or Shared Trees.
So far we have been talking about multicast transmissions using UDP. This is the usual practice, as it is impossible to do it with TCP. However, intense research is taking place since a couple of years in order to develop some new multicast transport protocols.
Several of these protocols have been implemented and are being tested. A good lesson from them is that it seems no multicast transport protocol is general and good enough for all types of multicast applications.
If transport protocols are complex and difficult to tune, imagine dealing with delays (in multimedia conferences), data loss, ordering, retransmissions, flow and congestion control, group management, etc, when the receiver is not one, but perhaps hundreds or thousands of sparse hosts. Here scalability is an issue, and new techniches are implemented, such as not giving acknowledges for every packet received but, instead, send negative acknowledges (NACKs) for data not received. RFC 1458 gives the proposed requirements for multicast protocols.
Real-Time Transport Protocol (RTP) is concerned with multi-partite multimedia conferences, Scalable Reliable Multicast (SRM) is used by the wb (the distributed White-Board tool), Uniform Reliable Group Communication Protocol (URGC) enforces reliable and ordered transactions based in a centralized control, Muse was developed as an application specific protocol: to multicast news articles over the MBone, the Multicast File Transfer Protocol (MFTP) is quite descriptive by itself and people "join" to file much in the same way they would join a conference, Log-Based Receiver-reliable Multicast (LBRM) is a curious protocol that keeps track of all packets sent in a logging server that tells the sender whether it has to retransmit the data or can drop it safely as all receivers got it. One protocol with a funny name -especially for a multicast protocol- is STORM (STructure-Oriented Resilient Multicast).
Today, the advent of High Throughput Satellite (HTS) technology, coupled with rising demand for satellite communications, are expected to have a profound impact on the VSAT industry. With the huge influx of bandwidth capacity, HTS will bring both improved speeds and lower costs. Combined with major space segment and infrastructure advances, a prime opportunity exists to accelerate overall VSAT adoption on a much broader scale.
High Throughput Satellites are a new breed of high-performance broadband satellites that today mostly use Ka-band frequencies, but not exclusively – with Intelsat’s announcement of EPIC we will see Ku HTS very soon.
HTS is fundamentally different both in terms of design and the ground segment requirements. (For more details, see HTS Whitepaper.) Traditional satellites use large regional beams covering an entire footprint with fixed capacity. Any service provider could own a hub and teleport and offer services to customers as long as they were in the satellite footprint. By contrast, HTS employ frequency re-use across multiple spot beams to create a massive increase in capacity. A dedicated high bandwidth feeder link is required to serve to the spot beams. Hub infrastructure must be located within the feeder link to serve all the spot beams. See below:
As more and more HTS are launched they are expected, over time, to provide a huge influx of bandwidth capacity that will deliver higher speeds at lesser cost. In fact, NSR states that high throughput satellites are expected to supply at least 1.34 TBps of capacity by 2020.
Since bandwidth will no longer constrain how business is done, rapid adoption of satellite is expected to open doors to new opportunities in both the enterprise and government markets.