QoS-Guaranteed Secure Multicast Routing Protocol for Satellite IP Networks Using Hierarchical Architecture

Most recent satellite network research has focused on providing routing services without considering security. In this paper, for the sake of better global coverage, we introduce a novel triple-layered satellite network architecture including Geostationary Earth Orbit (GEO), Highly Elliptical Orbit (HEO), and Low Earth Orbit (LEO) satellite layers, which provides the near-global coverage with 24 hour uninterrupted over the areas varying from 75° S to 90° N. On the basis of the hierarchical architecture, we propose a QoS-guaranteed secure multicast routing protocol (QGSMRP) for satellite IP networks using the logical location concept to isolate the mobility of LEO and HEO satellites. In QGSMRP, we employ the asymmetric cryptography to secure the control messages via the pairwise key pre-distribution, and present a least cost tree (LCT) strategy to construct the multicast tree under the condition that the QoS constraints are guaranteed, aiming to minimize the tree cost. Simulation results show that the performance benefits of the proposed QGSMRP in terms of the end-to-end tree delay, the tree cost, and the failure ratio of multicasting connections by comparison with the conventional shortest path tree (SPT) strategy.


Introduction
Satellite networks are characterized by global coverage, cost-effective broadcast and multipoint capabilities, flexible network configuration and capacity allocation, bandwidth-on-demand flexibility, etc.There is no doubt that satellite networks will be an integral part of the newly emerging Next Generation Networks (NGN) and the evolution of Future Networks (FN), and also play an increasing critical role in providing broadband Internet access, personal communications, broadcast and multi--cast of digital content to geographically diverse user groups, and so on.Although satellite networks offer great potential, they also present significant security challenges that need to be addressed.These securityrelated challenges can be summarized as follows [1].
 Satellite channels are wireless broadcast media, which makes it possible for an unauthorized user to receive the signal and eavesdrop on the communications, if it is not encrypted.
 Without the proper security mechanisms, any sufficiently well-equipped adversary can send spurious commands to the satellite and jam or disrupt the communications.
 Security systems should add minimal delays to the communications and have mechanisms to recover from loss in security information.
The above challenges may incur more security threats for satellite networks, including insider attacks, packet modification, sending forged commands, denial of service, etc [2].
With the explosive growth of the Internet-based multimedia applications, such as push media, file distribution and caching, multimedia conferencing, chat groups, multi-player games, etc, multicasting constitutes an important service to perform the simultaneous distribution of the same multicast packets from a single source node to a group of destinations in satellite networks.Multicast routing is one of the key technologies in multicast service for satellite networks.In recent years, many conventional multicast routing protocols for terrestrial networks have been proposed [3,4].However, these existing multicast routing protocols can not be very well suited for satellite IP networks.At present, only a few multicast routing schemes in the literature have been developed for satellite IP networks.In [5], using the datagram routing algorithm (DRA) [6] to create the multicast trees, a multicast routing algorithm for LEO satellite IP networks is introduced, which minimizes the end-to-end delay for real time multimedia services.The bandwidth-efficient multicast routing mechanism [7] based on rectilinear Steiner trees (RSTs) for LEO satellite IP networks minimizes the total bandwidth and gains the limited overhead.Two multicast routing algorithms based on the dynamic approximate center (DAC) core selection method, i.e., the core-cluster combination-based shared tree (CCST) algorithm and the weighted CCST algorithm (w-CCST), are presented in [8].The former significantly decreases the average tree cost, and the latter reduces the average end-to-end propagation delay.The distributed multicast routing protocol in [9] aims to minimize the total cost of the multicast trees in multi-layered satellite IP networks, including Geostationary Earth Orbit (GEO), Medium Earth Orbit (MEO), and Low Earth Orbit (LEO) layers.
In addition, the future media rich applications such as media streaming, content delivery distribution and real time broadband access require satellite networks that inherently offer user level quality of service (QoS) guarantees.In this regard, one of the challenges for multicasting communications in satellite IP networks is to design the QoS multicast routing protocols.To our knowledge, there is no QoS multicast routing protocol so far specifically developed for satellite IP networks.In general, a combination of different layers of satellite constellations, such as GEO, LEO, MEO, and Highly Elliptical Orbit (HEO) satellite constellations, to build up a solid satellite network with multiple layers, can yield a much better performance than these layers individually, e.g., higher efficiency in the spectrum usage, flexible user's access and route selection, larger transmission capacity.In this paper, for the sake of better "global coverage", we take into account the demand of satellite communications over the high-latitude areas, and present a triple-layered LEO/HEO/GEO satellite network architecture.On the basis of the novel hierarchical architecture, we adopt the concept of logical locations [6] to isolate the mobility of LEO and HEO satellites and propose a QoS-guaranteed secure multicast routing protocol (QGSMRP) for satellite IP networks.In QGSMRP, we employ the asymmetric cryptography to protect the data integrity of the control messages via the pairwise key pre-distribution and propose a least cost tree (LCT) strategy to construct the multicast tree under the condi-tion that the QoS constraints are guaranteed, aiming to minimize the tree cost.Simulation results demonstrate that the proposed QGSMRP owns the better performance over the end-to-end tree delay, the tree cost, and the failure ratio of multicasting connections in contrast with the traditional shortest path tree (SPT) strategy.
The rest of the paper is organized as follows.Section 2 describes the satellite network architecture.In Section 3, the problem formulation is introduced.Section 4 presents the QGSMRP.Simulation results are given in Section 5. Section 6 concludes this paper.

Satellite Network Architecture
As illustrated in Figure 1, the triple-layered satellite network architecture consists of a GEO constellation, several LEO and HEO constellations, and some fixed terrestrial gateways.The hierarchical architecture is divided into three satellite layers, i.e., GEO, LEO, and HEO layers.The total number of GEO satellites is N G in GEO layer and a GEO satellite is denoted by . In LEO layer, the total number of LEO satellites is N L and a LEO satellite is denoted by L i,j , which is in the coverage area of the GEO satellite G i .Assume that Walker star pattern constellation is applied in LEO layer to organize the LEO satellites.We introduce the HEO constellations to provide coverage to selected areas of the Earth, e.g. the Polar Regions, over which most GEO satellites lack.In HEO layer, the total number of HEO satellites is N H and a HEO satellite is denoted by H i,k , which is in the coverage area of the GEO satellite G i .
Three types of full duplex links are maintained in the architecture.Satellites are connected to each other within the same layer via Inter-Satellite Links (ISLs), while the communications between satellites (e.g.GEO and LEO satellites) in different layers is completed via Inter-Orbital Links (IOLs).Note that communication capabilities from HEO satellites is only provided when HEO satellites are moving very slowly relative to the globe while in the vicinity of apogee.For that reason, assume that the communications between GEO satellites and HEO satellites is accomplished via IOLs when HEO satellites are moving near apogee, while the communications among HEO satellites cannot be maintained through ISLs in the architecture.The terrestrial gateways are directly connected to LEO and GEO satellites via User Data Links (UDLs) and assumed to be the sources and destinations of multicasting communications.
Considering the logical locations of satellites, we introduce the satellite domains to organize satellites in a hierarchical manner in order to isolate the mobility of satellites from upper layer, i.e., GEO layer.A LEO satellite domain L i is the set of logical locations of LEO satellites that are within the coverage of a GEO satellite G i .ISLs in LEO layer can be categorized into two types, i.e., intra-domain ISLs and inter-domain ISLs.Note that the LEO satellites are connected to their adjacent neighbors over the grid points in the same layer via intra-domain ISLs.Here, , { 1 , , ( size function that generates the total number of satellites in a satellite domain.Similarly, a HEO satellite domain H i is the set of logical locations of HEO satellites that are within the coverage of a GEO satellite G i , and , { 1 , , ( Assume that half of the HEO satellites within a HEO constellation in the same orbit have IOLs with a GEO satellite at time instant and different GEO satellites may own the same HEO satellite domains.We give an example to illustrate the HEO domain in the architecture.As shown in Figure 2, a HEO constellation owns 6 satellites and a HEO domain contains 3 satellites.

Problem Formulation
The topology of satellite network based on our architecture is modeled as a connected directed graph ( , ) G V E  , where V is the set of nodes representing satellites and terrestrial gateways in our architecture and is the set of links connecting the nodes, i.e., ISLs, IOLs and UDLs.
Let a terrestrial gateway denote a source, and other terrestrial gateways constitute a set of destinations, i.e., , called a multicast group.A multicast tree , for and , is a subtree of the graph rooted from S, which contains all of the nodes of D and an arbitrary subset of The link state of a link l consists of delay and available bandwidth , for , where and are delay function and available bandwidth function, respectively.Note that the delay of a link l contains three delay components: 1) radio propagation delay, 2) queuing delay, and 3) protocol processing delay.
where ( )   is a function that returns the number of links in the path P.
Definition 4. The available tree bandwidth of a multicast tree T is the minimum bandwidth of the links in the multicast tree, i.e., where ( )   is a function that returns the number of links in the tree T.
Definition 5.The path delay of a path P is the sum of the delay of the links on the path, i.e., Definition 6.The tree delay of a multicast tree T is the end-to-end maximum delay of the paths from source S to the destinations of D on the multicast tree, i.e., Definition 7. The path cost of a path P is defined as the product of available path bandwidth and path delay of path P, i.e., Definition 8.The least cost path from node A to node B is defined as a path that satisfies where denotes a feasible path from node A to node B, and is a function that returns the number of feasible paths from node A to node B.
  Definition 9.The tree cost of a multicast tree T is defined as the product of the available tree bandwidth and the tree delay of the multicast tree T, i.e., Our problem is: given a satellite network ( , ) G V E  , a source S, a multicast group D, a delay bound  , and a bandwidth bound  , to construct a multicast tree which spans S and D such that the tree cost defined in ( 7) is minimized under the condition that the available tree bandwidth and tree delay of the multicast tree T satisfy the required QoS constraints, namely, 1) delay constraint: , and 2) bandwidth constraint: .

The Proposed Protocol
Our proposed QoS-guaranteed secure multicast routing protocol (QGSMRP) is composed of four processes, i.e., link state report, route discovery and reply, route maintenance, and multicast tree creation.In QGSMRP, we assume that every node and its neighbor node in the satellite network mutually have the pairwise keys, i.e., public keys and private keys, preloaded by key pre-distribution mechanism.We also assume that every node in the satellite network has unique node address.Table 1 provides the notation description which will be used for cryptographic operations in the paper.

Link State Report
The link state report process is initiated when a source receives a QoS request for setting up a multicasting connection with a multicast group D and the delay bound  and bandwidth bound .The source initially creates a report request (REPORT_REQ) message and then transmits it to a GEO satellite via a UDL.When receiving the REPORT_REQ, the GEO satellite follows the steps below to complete the link state report process.Step 1: The GEO satellite sends the REPORT_REQ to other adjacent GEO satellites via ISLs.
Step 2: When the REPORT_REQ are received by all the GEO satellites in GEO layer, each GEO satellite sends the REPORT_REQ to the LEO and satellites within its covered LEO and HEO domain through IOLs.
Step 3: In LEO layer, LEO satellite floods the RE-PORT_REQ to other LEO satellites within the same domain via intra-domain ISLs and across different domains via inter-domain ISLs.
Step 4: The members of the multicast group D receive the REPORT_REQ from the GEO and LEO satellites via UDLs.
After all the nodes in the satellite network acquire the REPORT_REQ, the link state interaction process is initiated. 2

) Link State Interaction
Step 1: The member of the multicast group D, i D D  , sends a state report (STATE_REPORT) message to the GEO and LEO satellites via the reverse UDLs.The STATE_REPORT is constructed as follows: <{SRid, Node Address, Downstream Node Address, The pair <Node Address, SRid> uniquely identifies the STATE_REPORT.The SRid is monotonically increasing when a node issues a new STATE_REPORT to its downstream node and can be used to check the duplicate copies of an old STATE_REPORT for the downstream node.The destination encrypts the message {SRid, Node Address, Downstream Node Address, } with its private key

The Available Bandwidth and
Delay record the available bandwidth and the delay between a node and its downstream node over the corresponding link.When a GEO satellite (or a LEO satellite) receives the STATE_REPORT, it will decrypt the ciphertext in the STATE_REPORT with its public key to verify whether expires: If so, the GEO satellite (or LEO satellite) drops the STATE_REPORT.When receiving STATE_REPORT from all the destinations, the GEO and LEO satellites acquire the link state information, i.e., the available bandwidth and delay from the GEO and LEO satellites to destinations.
Step 2: In LEO layer, LEO satellite receives the STATE_REPORT from the upstream node (i.e., the destination) and performs the same cryptographic operations, and then issues its STATE_REPORT to other LEO satellites within the same domain via intra-domain ISLs and across different domains via inter-domain ISLs.
Step 3: The LEO satellites in the same domain transmit their STATE_REPORT via IOLs to their manager, the GEO satellite.
Step 4: In GEO layer, GEO satellite also transmits the STATE_REPORT to other adjacent GEO satellites via ISLs.When exchanging their link state information, GEO satellites delivers the STATE_REPORT to HEO satellites within its covered HEO domain via IOLs and also to the source via UDLs.
When the link state report process is completed, the available bandwidth and the delay of each link l E  in the satellite network are established and the related link state information is recorded in each node.

Route Discovery and Reply
When the link state report process is completed, the source S initiates the route discovery by flooding a route request (RREQ) message to its neighbor nodes.The RREQ is constructed as follows: <{RRQid, Source Address, Multicast Group Address List,  } , , , Accumulated Delay, Path> The pair <Source Address, RRQid > uniquely identifies the RREQ.The Path records the routing information during route discovery and the Accumulated Delay records the sum of delay along the path.When an intermediate node A receives a RREQ, it decrypts the ciphertext in the RREQ with its public key , and checks three items to decide whether to send the received RREQ: A  Item 1: Whether has expired.If so, the RREQ will be dropped.


Item 2: Whether there is enough available bandwidth over link l between the last hop node and itself according to link state information, i.e., whether , it means that there is no available bandwidth to meet the QoS requirements over that link and the RREQ will be dropped.
Item into Accumulated Delay, encrypts the corresponding message with its private key A  and then sends the RREQ out.If the newly received RREQ was received before, it means that there exists another path from the source to the node.The node records this path information and discards that RREQ.
This operation in route discovery will be repeated node by node until the delay bound or available bandwidth bound cannot be guaranteed.Eventually, a RREQ message will arrive at a destination and this destination will also check the three items to determine whether the QoS constraints are satisfied.If so, this destination will wait for a certain time to receive multiple RREQ, and then will create a route reply (RREP) message and send the RREP back to the source S. The RREP is constructed as follows: The pair <Destination Address, RRPid> uniquely identifies the RREP and the Lifetime denotes a value of a pre-defined time for which the nodes receiving the RREP consider the route to be valid.The Path Set is the set of multiple possible parallel paths from the source to the destination and each path is marked with the information of accumulated delay and available bandwidth from the source to the destination.Meanwhile, the destination can also act as an intermediate node and continues to forward the RREQ until the QoS constraints are not guaranteed.When the source receives the RREP, it first decrypts the ciphertext in the RREP with its public key S   to verify whether expires, and also records the Path Set into routing table.When the source receives all the RREP, it gets a partial topology from it to the multicast group in satellite network .

1) Joining Multicast Group
The joining multicast group process is initiated when a Copyright © 2010 SciRes.IJCNS new terrestrial gateway wants to join a multicast group D.
The new terrestrial gateway firstly creates a STATE_REPORT and then sends the STATE_REPORT to the GEO and LEO satellites via UDLs.Through link state interaction, the nodes with the corresponding links acquire the link state information.Then the new terrestrial gateway broadcasts a join request (JOIN_REQ) message which is constructed as follows:

Path, Accumulated Delay>
The pair <Terrestrial Gateway Address, JRQid> uniquely identifies the JOIN_REQ.When an intermediate node receives a JOIN_REQ, it checks the three items to decide whether to reflood the received JOIN_REQ.The new gateway will send multiple JOIN_REQ out within a pre-defined time until they arrive at a desitination .The destination firstly waits for a certain time to receive multiple JOIN_REQ.Secondly, according to the Path, it will check the three items to determine whether the QoS constraints are satisfied.If so, the destination creates a join reply (JOIN_REP) message and sends it back to the new gateway.Note that this destination serves as a forwarding node and the source does not know the information about this new gateway.The JOIN_REP is constructed as follows: The pair <Destination Address, JRPid> uniquely identifies the JOIN_REP.After a pre-defined time, the new gateway does not receive any more JOIN_REP and the joining multicast group process terminates.
2) Leaving Multicast Group The leaving multicast group process is initiated when a destination wants to leave a multicast group D. The destination firstly sends out multiple join negative acknowledgement (JOIN_NAK) messages to its neighbors and then deletes all the routing information of the neighbors.The JOIN_NAK is constructed as follows:

Path>
The pair <Terrestrial Gateway Address, JNid> uniquely identifies the JOIN_NAK.When receiving a JOIN_ NAK, a neighbor checks whether it has an upstream node or a downstream node.If so, the neighbor prunes the link from this destination and deletes the routing information of this destination, and then transmits the JOIN_NAK to notify that this destination has been leaving the multicast group.Otherwise, the neighbor will check whether it is a member of multicast group.If so, the neighbor just prunes the link from this destination.Otherwise, the neighbor becomes a non-forwarding node and withdraws from the QoS multicasting communications.

Multicast Tree Creation
The multicast tree creation process is activated by the source at the end of the route discovery and reply process.As mentioned previously, the source has maintained multiple parallel paths from itself to several destinations in multicast group.Therefore, the main goal of the source is to select one of the parallel paths to set up a multicasting connection, and then proceed to create a multicast tree.In this paper, we present a least cost tree (LCT) strategy to construct the multicast tree under the condition that the QoS requirements are guaranteed.The basic idea of the LCT strategy works as follows.Assume that the Path Set from a destination , is denoted by .When receiving a RREP from a destination , the source gets the information of accumulated delay and available bandwidth from the source to this destination along a path , After a pre-defined time, the source gains all the information about the paths with least path cost from itself to each destination in the multicast group D. Afterwards, the source follows the steps below to create a multicast tree.When the multicast tree is built up, the multicast session begins.
Step , where and 0 E   .
Step 3: For . In this section, we evaluate the performance of QGSM-RP by comparing it with the conventional shortest path tree (SPT) strategy [10] via computer simulations.In our empirical study, three metrics are considered in the performance evaluations, i.e., 1) the end-to-end tree delay, 2) the tree cost, and 3) the failure ratio of multicasting connections.

Performance Evaluation
In our simulations, the parameters of the triple-layer satellite network are described in Table 2.The performance of coverage from the triple-layer satellite network is illustrated in Figure 3.According to Figure 3, triplelayered satellite network can offer coverage over the areas varying from 75° S to 90° N with 24 hour uninterrupted.We use the non-uniform distribution [9] to determine the positions of the terrestrial gateways, including the source and the multicast group.Moreover, we assume that the capacity of all ISLs, IOLs, and UDLs are set to 800 Mb/s, each outgoing link has a buffer space of 20 MB, and the delay bound and bandwidth bound are set to ms and Mb/s, respectively.450   256   Figure 4 and Figure 5 illustrate the performance of the end-to-end tree delay of the proposed QGSMRP and the SPT strategy, respectively.The size of multicast group is set to 50.We can observe that with the growth of the simulation time, the variation of the end-to-end tree delay of the proposed QGSMRP and the SPT strategy is almost uniform with the range of 0.1 s to 0.5 s.Furthermore, the end-to-end tree delay changes quickly and obviously as the simulation time increases.Figure 6 shows the comparison of the end-to-end tree delay versus the multicast group size between the SPT and the proposed QGSMRP.It can be easily seen that the end-to-end tree delay of the proposed QGSMRP is much lower than that of the SPT strategy with the increase of the size of the multicast group.Figure 7 compares the performance of the tree cost versus the multicast group size between the SPT and the proposed QGSMRP.We can obviously see that as the multicast group size grows, the tree cost of the proposed QGSMRP is much smaller than that of the SPT strategy.This can be explained by the fact that the proposed QGSMRP focuses on the optimization of the tree cost during the process of the route discovery and reply, whereas the main target of the SPT strategy is to bring the better performance of the path delay in the multicast tree without taking into account the available bandwidth in the process of the multicast tree construction.
End-to-End Tree Delay (s) Figure 8 demonstrates the comparison of the failure ratio of multicasting connections between the SPT strategy and the proposed QGSMRP.It can be observed from Figure 8 that the failure ratio of multicasting connections of the proposed QGSMRP is smaller than that of the SPT strategy with the range of 15 to 30 of the multicast group size, which indicates that the success ratio of the QoS multicasting requests of the proposed QGSMRP is superior to that of the SPT strategy with the growth of the multicast group size.For that reason, the proposed QGSMRP can easily establish the QoS multicasting connections when the scale of the network is large, i.e., a large quantity of the terrestrial gateways.However, the failure ratio of multicasting connections of the SPT strategy is better than that of the proposed QGSMRP in the range of 5 to 10 of the size of the multicast group.We can also observe that the failure ratio of multicasting connections of both of the multicast routing strategies are represented as a gradual increasing trend.

Conclusions
In this paper, considering the difficulty to provide the coverage over the special regions or the areas of high latitudes by the existing hierarchical satellite networks, we introduce a novel triple-layered LEO/HEO/GEO satellite network architecture containing LEO, HEO, and GEO satellite layers, which yields the near-global coverage with 24 hour uninterrupted over the areas varying from 75° S to 90° N. On the basis of the novel hierarchical architecture, we propose a QoS-guaranteed secure multicast routing protocol (QGSMRP) for satellite IP networks using the concept of logical locations to isolate the mobility of LEO and HEO satellites.In QGSMRP, through the pairwise key pre-distribution, we employ the asymmetric cryptography to secure the data integrity of the control messages, and present a least cost tree (LCT) strategy to construct the multicast tree under the condition that the QoS constraints are guaranteed, aiming to minimize the tree cost.Simulation results demonstrate that the proposed QGSMRP owns the better performance including the end-to-end tree delay, the tree cost, and the failure ratio of multicasting connections by comparison with the conventional shortest path tree (SPT) strategy.

Figure 2 .
Figure 2. A HEO domain for example.

Definition 3 .
The available path bandwidth of a path P is the minimum bandwidth of the links along the path, i.e., denotes a path from source S to destination , and i S D P  i D D denotes the number of destinations.

Figure 6 .Figure 7 .
Figure 6.Comparison of the end-to-end tree delay between the SPT strategy and the proposed QGSMRP.

Figure 8 .
Figure 8.Comparison of the failure ratio of multicasting connections between the SPT strategy and the proposed QGSMRP.