Data Naming Mechanism of LEO Satellite Mega-Constellations for the Internet of Things

Abstract

The low earth orbit (LEO) mega constellation for the internet of thing (IoT) has become one of the hot spots for B5G and 6G concerns. Information-centric networking (ICN) provides a new approach to the interconnection of everything in the LEO mega constellation. In ICN, data objects are independent of location, application, storage and transport methods. Therefore, data naming is one of the fundamental issues of ICN, and research on the data naming mechanism of the LEO mega constellation for the IoT is thus the focus of this study. Adopting a fusion of hierarchical, multicomponent, and hash flat as one structure, a data naming mechanism is proposed, which can meet the needs of the IoT multiservice attributes and high-performance transmission. Additionally, prefix tokens are used to describe hierarchical names with various embedded semantic functions to support multisource content retrieval for in-network functions. To verify the performance of the proposed data naming mechanism, an NS-3-based simulation platform for LEO mega constellations for the IoT is designed and developed. The test simulation results show that, compared with the IP address, the ICN-HMcH naming mechanism can increase throughput by as much as 54% and reduce the transmission delay of the LEO mega satellites for the IoT by 53.97%. The proposed data naming mechanism can provide high quality of service (QoS) transmission performance for the LEO mega constellation for IoT and performs better than IP-based transmission.

1. Introduction

Recent improvements in small satellite technologies are making the use of small-satellite-based solutions appealing in different use cases, including the internet of thing (IoT). One practical example among others is the departural satellite (D-SAT) project, where a flexible cubesat-based system has been designed and tested to broadcast data generated by sensors spread over a certain coverage area [1,2]. Concurrently, because 5G cannot achieve seamless global coverage, an important development trend of B5G and 6G is the space–air–ground–sea integrated communication network [3,4]. The 3GPP working group has thus started work in this area [5].

Compared with terrestrial communications, a major advantage of satellite communications is wide coverage, which is particularly beneficial to massive machine communication (mMTC) services with ultralarge-scale access equipment (i.e., IoT services) [6]. The third-generation partnership project (3GPP) working group has studied satellite networks in three orbits: medium earth orbit (MEO), geosynchronous earth orbit (GEO) and low earth orbit (LEO). The LEO satellite network has become important for delay-sensitive services due to its lower delay. However, LEO satellites require dense deployment of space segments due to their high flight speeds and short coverage times to ensure that the ground terminal has satellite coverage continuously [6]. Therefore, with the gradual maturity of small satellite technology, the LEO mega constellation, which is a satellite system composed of multiple satellite orbits and hundreds of small satellites, has become a hot spot for B5G and 6G [6,7], and the LEO mega constellation for the IoT has become a common goal of industry and academia [8,9,10,11].

Conversely, with the development of IoT in recent years and the explosive growth of the number of IoT access devices, the big data generated by IoT pose a serious challenge to the network architecture based on TCP/IP to efficiently achieve data distribution and routing [12,13]. Deep learning and IoT can be combined in TCP/IP-based network architectures to efficiently achieve data distribution and routing [14,15,16]. However, how to assign IP addresses to IoT access devices is also a tricky problem. Because IPv4 addressing space is full, the IPv6 address space may also fill in the future [12]. In addition, IPv6 addresses are long [12], which makes them less suitable for the access of billions of devices with various constraints (e.g., power consumption, storage, size) [12,17,18,19], including wireless sensors [17,18,19]. Therefore, TCP/IP is clearly inadequate for IoT requirements [12]. From a data perspective, business applications care more about data itself rather than the address of the data source. Therefore, in recent years, to fulfil all these needs of the IoT, designing a new future network architecture from the ground up has become an important subject of special attention in industry, and information-centric networking (ICN) is a landmark ideal solution [12,13], which is particularly valued in B5G and 6G core networks, IoT and other fields [20,21,22]. ICN aims to make the current complex network architecture simpler and more versatile. Network elements are no longer servers, routers, terminals, etc. ICN networking, based on the content goal of naming, is the receiving-driven model, and data naming is one of the basic problems of ICN, which has been a research hotspot in recent years [23]. Named-data networking (NDN) [24,25] is an implementation of ICN that uses hierarchical and human-readable names to transmit content across the network. In particular, the communication paradigm of NDN is based on request and response patterns with simplified pull-based communication through interest and data packets. Name-based data retrieval can eliminate the dependence on static locations and IP addresses [26]. End users only express their interest in the given content, and the entire network is responsible for organizing routing according to the content name request and passing the content to the end user through the reverse path. ICN features primarily include location-independent naming functions, naming-based routing, intranet caching, and content self-generation to support mobile and multihoming services [27]. ICN is a data-oriented network and uses data names as the primary network elements. Therefore, how to name the data is a key issue for the ICN network.

In [28], the NDN-based hybrid naming scheme (NDN-HNS) for IoT-based smart campus (IoTSC) is proposed to provide simple naming for smaller contents. In [29], a named-based query and command mechanism named the NINQ framework is proposed to improve network performance. Many ICN naming studies are published in the literature, and the naming schemes for ICN are similar; the difference is how they are applied. Unfortunately, existing studies use a static network topology without considering dynamic scenarios in which node locations change over time, particularly for space-based IoT scenarios.

To our knowledge, past research on ICN naming has primarily focused on hierarchical naming [30,31] on the ground for different scenarios, and many studies use IP as a comparison [32]. This paper applies ICN in space-based networks to alleviate the traffic load of terrestrial networks and provide global “anywhere-anytime” Internet access. In this study, data naming should be able to clearly identify services, content and equipment; meet the requirements of heterogeneity of IoT equipment and applications; achieve equipment interoperability from different vendors and across domains; and have the characteristics of efficient aggregation, fast search and dynamic content identification to ensure tight coupling with satellite IoT applications. In addition, data naming should meet the requirements of dynamic routing organizing, forwarding, storage, etc. Currently, the ICN network primarily uses two primary methods: hierarchical and flat naming [33,34]. The hierarchical data naming method is readable and has good aggregation properties, which is conducive to routing organizing.

In summary, the contribution of this paper is summarised as follows.

(1)

An LEO mega constellation for IoT is proposed.

(2)

Based on the IoT business attributes of the LEO satellite constellation, a data naming mechanism integrating hierarchical, multi-component and hash flattening is proposed. The hierarchical-multi-component part contains information for IoT applications such as data type, generation (spatial, temporal), and attributes; the hash flattening part serves as the unique identification information of data, which can meet the needs of spatial dynamic routing organisation, forwarding, and storage, and improve the network transmission performance.

The structure of this article is as follows. The Section 1 describes the LEO mega constellation model for the IoT and analyses the links between adjacent satellites on different orbital planes. The Section 2 proposes a data naming mechanism for IoT applications. The Section 3 analyses and evaluates the performance of the proposed data naming mechanism based on the discrete event network simulator NS-3. Finally, the Section 4 provides a summary of this study.

2. LEO Mega Constellation for the IoT

2.1. IoT and LEO Mega Constellations

The IoT connects people to things, and things to other things through machine-type communication (MTC) and man–machine communication (MMC). The IoT consists of a perception layer, a transmission layer, and an application layer, as shown in Figure 1. Generally, the perception layer uses radio frequency identification (RFID) [35], wireless sensor networks (WSN) [36], near field communication (NFC) [37], infrared and other technologies for object perception and data transmission using short-distance communication methods such as Bluetooth and ultra-wide band (UWB). The transmission layer uses the internet, public mobile communication technologies (4G, 5G [38]), mobile ad-hoc networks (MANETs) [39], satellite networks [40], vehicular ad-hoc network (VANET) [41], etc., to transmit collect data. At the application layer, data processing and analysis are completed by cloud computing [42], big data [43] and other means to provide services for end users.

An important application in the 5G era is the interconnection of all things, while B5G or 6G requires seamless interconnection of all things under the condition of via space–air–ground–sea integration, and the transmission of IoT services requires low latency and high bandwidth. Generally, according to the orbital height, space–air–ground–sea integrated communication can be divided into three methods: high-orbit GEO, medium-orbit MEO, and low-orbit LEO. The networking features of these three methods are listed in

Table 1. Constellation networking features.

Constellation Category	Orbital Height (km)	Satellites for Full Coverage	Transmission Delay
GEO	35,786	Least	High
MEO	2000~20,000	Less	General
LEO	500~2000	Most	Low

.

Table 1 shows that the three integrated communication methods have their own advantages and disadvantages. In recent years, small satellite technology, including Cubesat, has been developed rapidly, and LEO mega constellations for the IoT using intersatellite link networking technology have been highly valued globally, such as the SpaceX, Amazon, OneWeb, Hongyun and Hongyan systems in China, which primarily provide low-latency, high-bandwidth transmission services for IoT applications.

A satellite constellation is a collection of multiple satellites with similar types and functions that are distributed on the same or complementary orbital planes and are coordinated to complete certain tasks under shared control. A constellation is typically a satellite network that is composed of multiple satellite rings that are configured in a specific way. This network can provide high performance, flexible wireless coverage and communication services to achieve global connectivity. The primary technical parameters and ground coverage of the primary constellations are shown in

Table 2. Technical parameters of the constellations.

Constellation Category	Orbital Height (km)	Number of Satellites	Ground Coverage
Iridium	780	66	Global
SpaceX	1200	4425	Global
Amazon	590~630	3236	Global
OneWeb	1200	720	Global
Hongyun	1000	156	Global
Hongyan	~2000	300	Global

.

The Iridium constellation is the pioneer of LEO mega networking and uses polar orbits and satellites to communicate with each other via intersatellite links (ISL). The satellite visualisation simulation software SaVi [44,45] describes the structure and ground coverage of the Iridium constellation with six orbital planes, as shown in Figure 2.

To achieve full coverage globally, the LEO mega constellation for the IoT is promising network architecture and a powerful complement to the ground-based IoT network. This constellation can provide the unique advantage of high flexibility for the global expansion of the networking market.

2.2. Intersatellite Link of LEO Mega Constellation

For an LEO satellite mega constellation oriented to the IoT, intersatellite communication is required. The global coverage of the satellite constellation and the interconnection of everything in ground-side communications cannot be achieved without ISL. According to the topological characteristics of the LEO mega constellation, intersatellite communication links include links between adjacent satellites on the same orbital plane and satellite links between adjacent orbital planes.

2.2.1. Keplerian Elements

A satellite orbit can be described by seven orbital elements: the semimajor axis, eccentricity, right ascension of the ascending node, inclination, argument of the perigee, mean anomaly and true anomaly, as shown in Figure 3 [46]. The relationships between these parameters are shown in Figure 4 [47].

The orbital period $P$ is proportional to the semimajor axis $\alpha$:

$$P=2\pi \sqrt{\frac{a^3}{G\left(M_e+m\right)}}$$

(1)

where $G$ is the gravitational constant, $M_e$ is the mass of the earth, and $m$ is the mass of the satellite.

The eccentric anomaly angle is denoted as E and the average angular velocity is denoted as n. At time t, the geometric relationship among M, v and E is shown in Figure 5, and there are:

$$M=nt$$

(2)

$$E-e\sin E=M=nt$$

(3)

$$v=2{\tan }^{-1}\sqrt{\frac{1+e}{1-e}{\tan }^2\frac{E}{2}}$$

(4)

$$r=\alpha (1-e\cos E)$$

(5)

where r is the modulus of the satellite’s vector radius.

For the circular orbits commonly used in LEO satellite constellations, $e=0$, $M=E=v$. Therefore, only v is used to describe the Keplerian elements of the constellation. The Keplerian elements of the Iridium constellation are shown in

Table 3. Keplerian elements of the Iridium constellation.

Elements	Symbol	Value	Memo
Semimajor Axis (km)	α	7159.14 km	Earth Radius + Orbital Height
Eccentricity	$e$	0.002	Circular Orbit
Right Ascension of Ascending	$\Omega$	0, 31.80, 63.60, 95.41, 127.21, 159.01	6 orbital planes
Node (deg)	$i$	86	Non
Inclination (deg)	$\omega$	0	Circular Orbit
Rue Anomaly (deg)	v	0, 32.73, 65.45, 98.18, 130.91, 163.64, 196.36, 229.09, 261.82, 294.55, 327.29	11 satellites evenly distributed on the odd orbital plane
		16.36, 49.09, 81.82, 114.55, 147.27, 180, 212.73, 245.45, 278.18, 310.91, 343.64	11 satellites evenly distributed on the even orbital plane

.

2.2.2. ISL Analysis

Intersatellite communication links include links between adjacent satellites on the same orbital plane and satellite links between adjacent orbital planes. Therefore, the analysis of intersatellite links considers the following two scenarios:

Case 1: ISL between adjacent satellites on the same orbital plane

To facilitate analysis, each satellite in the constellation is marked as $S_{i-jk}$. For example, $S_{0-01}$ represents the 01 satellite in the 0# orbital plane, and $S_{1-11}$ represents the 11 satellite in the 1# orbital plane.

The geometric relationship between adjacent satellites on the same orbital plane remains unchanged, and the ISL distance can be calculated using a simple triangle relationship. Consider satellites $S_{0-00}$ and $S_{0-01}$ shown in Figure 6 as an example.

In Figure 6, if $r_e$ is the radius of the Earth, $r_s$ is the orbital height, $\theta$ is the angle between adjacent satellites, and $\phi$ is the angle between the line connecting points O and $S_{0-00}$ and the line connecting points $S_{0-00}$ and $S_{0-01}$, then the distance between $S_{0-00}$ and $S_{0-01}$ is:

$$d_{000-001}=\frac{\alpha \times \sin \theta }{\sin \phi }$$

(6)

Substituting the relevant parameters in Table 3, $\theta =32.73°$, $\phi =73.635°$, and $d_{000-001}=2016.53\mathrm{km}$.

Case 2: ISL between adjacent satellites on adjacent orbital planes

The ISL between adjacent track surfaces includes links with short communication distances and links with long communication distances. Therefore, ISL analysis considers the following two situations:

(1)

ISL with the closest communication distance

When $S_{1-00}$ is over the North Pole or South Pole, the ISL communication distance is the closest, as shown in Figure 7.

Similarly, the distance between $S_{0-00}$ and $S_{1-00}$ is:

$$d_{000-100}=\frac{\alpha \times \sin \frac{\theta }{2}}{\sin \phi }$$

(7)

Substituting the relevant parameters in Table 3, $\theta =32.73°$, $\phi =81.82°$, and $d_{000-100}=1010.53\mathrm{km}$.

(2)

ISL with the longest communication distance

When $S_{1-00}$ is above the equator, the ISL communication distance is the longest, as shown in Figure 8. The midpoint of the connection between points $S_{0-00}$ and $S_{0-01}$ is M. In $\mathrm{Rt}\mathsf{\Delta }OM{S}_{0-00}$ and $\mathrm{Rt}\mathsf{\Delta }O{S}_{0-00}{S}_{1-00}$, the length of $\overline{O{S}_{0-00}}$ means $\alpha$, and the angle between two adjacent tracks is $\mathsf{\gamma }=31.80°$. Thus, $\overline{OM}=7087.78\mathrm{km}$, $\overline{M{S}_{1-00}}=3903.68\mathrm{km}$, and $\overline{S_{0-00}{S}_{1-00}}=4393.76\mathrm{km}$.

3. Design of Data Naming Mechanism

3.1. ICN

ICN is an information-centric network. Data objects are independent of location, application, storage, and transportation, allowing for ubiquitous intranet caching and routing. Thus, ICN aims to make the current complex network architecture simpler and more versatile, and network elements are no longer servers, routers, terminals, etc. The ICN networking is based on the named content and is a reception-driven model, which is considered to be the future development direction of the network [48]. ICN provides access to named data as a network service, and the network can serve local requests for named data, which means that network nodes can receive requests for named data and perform actions as required (e.g., forward the request to the appropriate next hop). Therefore, each network node on the path can execute forwarding decisions, cache objects, etc., and the network can forward requests along the best path.

As an implementation of ICN, NDN is based on a request-response model, data naming uses a hierarchical name structure, and naming is based on the content itself. NDN consists of two parts, a requester and a content provider, and communicates through interest packets and data packets. The data retrieval model follows the principle of interest and data flow balance. If the requester requests certain content, an interest packet with the corresponding content name is generated, and it is forwarded through the network to the node where the content is stored. After receiving the interest packet, the node returns a data packet with the corresponding name along the reverse path.

For IP packets, the core field is the address. For ICN packets, there are two types of packets, including both interest and packets of data, which do not contain an address. The core field of ICN packets is the data name. Therefore, data naming methods have an impact on overall network performance. Naming data content is a key concept. Generally, the ICN name neither represents a network node nor an interface but represents a network node independent of its location, which is suitable for content-oriented principles in IoT applications [49]. This result occurs because the ICN can reduce the data transmission delay and data publisher load through simple data access [13], and its marked advantages in fast and efficient data transmission and reliability make it a promising network mode in IoT applications. Therefore, in the IoT architecture of the mega constellation, the use of ICN ideas and an appropriate content naming mode will improve data transmission efficiency and network performance.

3.2. ICN Forward Process

LEO satellite nodes primarily enable access to terrestrial mobile terminals. The communication in LEO mega constellation is initiated by the consumer, i.e., the user terminal (UT), which exchanges two types of packets: interest and data [50]. The UT sends an interest with a content identifier to request the corresponding data. Two types of packets have a name for identifying the content. When data are requested, the UT puts the name of the required data into the interest and sends it to the network [51]. The satellite nodes use this name to forward the interest to the data producer, i.e., the content source server [51]. Once the interest reaches the satellite nodes that have the requested data in its cache, the satellite nodes return the data. The packet structure is shown in Figure 9 [52].

For performing the interest and data forwarding, each satellite node needs to maintain three functional components: forwarding information base (FIB), pending interest table (PIT), and content store (CS) [53]. Moreover, the interest and data forwarding steps in a satellite node are described in Figure 10.

Setting the ground station1 (GS₁) as the interest requester and the ground station2 (GS₂) as the data responder, the communication of GS₁ and GS₂ in LEO mega constellation operates according to the following steps.

Step1: The GS₁ requests content through sending an interest with the name of the content.

Step2: A satellite node receives an interest and checks whether a match data already exists in its local CS: if the responding data are found, then data sends back GS₁. Otherwise, the satellite node investigates if an interest with the same name in the PIT already exists; if so, there is no forwarding of the new interest. If a similar interest is not found in the PIT, the new interest is forwarded according to the FIB and cached in the PIT.

Step3: When the GS₂ receives the interest, a data containing the requested content is sent back. By following the reverse path of interest, the data follows the traces left in the PIT of each satellite node.

Step4: When the data arrives at a satellite node, the data are forwarded through ISL. Afterwards, the satellite node eliminates the entry from the PIT, and the data are cached in the satellite node.

3.3. Data Naming Mechanism

This paper proposes a data naming mechanism that integrates hierarchical, multicomponent, and flat hashing called ICN-HMcH. The purpose of this mechanism is to integrate the characteristics of hierarchical, multicomponent, and hash flat names into a multilayered structure using prefix-based hierarchical thinking and IoT business attributes based on the LEO satellite constellation.

Figure 11 shows the top-down multilayer naming structure of ICN-HMcH, which uses a four-layer structure to identify the semantics of different applications:

• Root prefix layer: This layer defines the flags for publishing information and multisource information request flags.
• Task-type layer: This layer defines the data namespace in the LEO IoT. Two types of data namespaces are proposed using the executed request: one retrieves data and performs content extraction on demand; the other routes and forwards or caches the transmitted data.
• Service-type layer: This layer defines the types of services to be performed, such as data transmission, video, or voice.
• Network functions and local node identification layer: This layer identifies the network functions used to allow data retrieval from multiple sources.

In addition to the multilayer design, the ICN-HMcH naming mechanism uses a set of attribute value pairs at each level to describe different content/service attributes, such as operation types and security. Some of these names must exist, and some are optional or can be dynamically generated. The attribute value plays an important role in strengthening content security, protecting user/communication privacy, etc., and can be saved as a keyword.

According to the ICN-HMcH top-down multilayer naming structure, the embedded naming mechanism of the data transmission process is introduced. For the data transmission of the LEO mega constellation of the IoT, according to the function, each node can be divided into the following categories:

• Content provider or publisher node. Such nodes inform other nodes of their own data and issue content update notifications in a timely manner when the content changes. In addition, for the requester node to request these data, the publisher node performs the data source function and provides the download source.
• Forwarding node. Typically, an area contains at least one such node, and its location can relate to most nodes in the area to provide an efficient information summary and the function of obtaining content information. For example, each satellite can act as a central node, particularly when switching satellites.
• Requester node. When a large number of data must be acquired and learning distribution information in the network is also required concurrently, the requester node sends a content information request to the forwarding node. The forwarding node obtains and analyses the response message; obtains the different content blocks and its node information; and then transmits the data concurrently in multiple channels. Additionally, the node requests different content blocks from different nodes concurrently. You can download and aggregate to obtain the required content. Concurrently, when the requester node obtains new data, it can publish the locally stored data information as the publisher node so that other requester nodes can directly access and download from this node.

Therefore, data transmission can be divided into three steps: information publishing, content source information acquisition, and block data request downloading.

In Step 1 (information publishing), the content provider nodes in the network must publish to the forwarding node in time based on the content cached locally to make full use of the distributed storage of data. The forwarding node determines the latest state of the data distribution in the network in real time, and when processing various data requests, it searches for the optimal data source to respond to user requests according to the content distribution and network topology. Therefore, the content distribution process occurs at any time.

During information publishing, some content is divided into several equal-sized blocks, and the block information is stored in each content block. The Publish information name pattern is ‘/Publish/Data/Prefix/Version/Timestamp/Number/Host-B/’. The field “Publish” is the flag for publishing information, which is used to inform the forwarding node that this type of request is published push information. The “Data” field is the data flag. ‘Prefix’ is the name prefix, and “Version” is the data-type information, such as video, voice or data. “Timestamp” is a timestamp. The file block serial number information “Number” is included in the back, “Host-B” is the node information of the content publisher, and the ID of the information publisher is only a named name. Therefore, ID is location-independent and used to observe how many hops of ISL the communication between the content provider and consumer will go through. The ID will be used as a basis for simulation latency.

After receiving the content request, the forwarding node first parses the name, determines that the content is the type of posted information, and detects the second field. If it is a local node, node directly resolves and processes. The data name, content block number, and source node information are obtained by parsing, and this information is sorted and cached in the content storage structure, as shown in

Table 4. Summary of published information.

Data Name	Block Number	Source Node Information
/Data/Prefix1/Video/20210322/	2	B
	1	C
/Data/Prefix1/Data/20210420/	3	C
	5	B
	2	D
/Data/Prefix1/Voice/20210421/	3	A
…	…	…

. If it is not a local node, the node will perform routing and forwarding according to the content matching forwarding interface of the forwarding interest database FIB.

If a node in the network has new content, the data will be released via this process. When some data sources leave the service range of the central node due to problems such as movement or the data are deleted due to the cache replacement strategy, the content provider node sends the deletion information of the corresponding data, thereby updating the forwarding node information quickly.

In Step 2 (obtaining content source information), the LEO mega constellation for the IoT has multiple sources for data transmission due to the high dynamics of satellites. If the requester node wants to obtain the data response in a block request through a multisource method, it should generate a multisource information request name pattern as ‘/Multihoming/Data/Prefix/Version/Timestamp/Number1/Number2/’. The field “Multihoming” is a special flag bit that indicates that the interest request is multisource information. Ordinary interest request packets are distributed to various nodes in the network by broadcasting, and the forwarding node of the multisource information request only performs the forwarding function until the request reaches the content requester node. The structure of the data content name part is similar to that of the published information name mode. The difference is that the last part of the information request name pattern is a locally stored content block, which is used to inform the content provider node not to send related information.

In Step 3 (request to download data in blocks), the content provider node parses the data name after receiving the content request and searches for related items in the summary information. After the search is completed, the content blocks stored by the requesting node are discharged, and the sequence numbers of other content blocks are packaged with the corresponding content publisher information and block information as a data packet to respond. After the requester node obtains the corresponding file block information of the reply to the data packet, it integrates the data content name and block sequence number information to automatically generate a common request packet as ‘/Source/Host-A/Data/Prefix/Version/Timestamp/NumberX/’. After automatically generating multiple interest request packets, different nodes are requested for different content blocks concurrently, and finally the demand data are obtained through multiple paths in parallel transmission mode to speed up the content transmission speed and reduce the load of the content provider.

4. Simulation Settings

4.1. Design of LEO Mega Constellation Simulation Platform

The NS-3 simulator is a discrete event-driven network simulator that consists of interdependent modules, such as the core module, network module, application module, internet module, point-to-point module and ndnSIM module, and provides different functions for network simulation. The ndnSIM module is the latest NDN simulation module based on NS-3, which implements the basic components of NDN modularly. The current NS-3 does not provide an LEO satellite network simulation module [11], nor does it have high-speed LEO mobile and dedicated protocol stacks for satellite-to-ground communications, such as DVB-RCS2. ndnSIM can only provide the lower layer support of the NDN protocol stack, such as content storage CS, pending interest table PIT, forwarding interest database FIB, forwarding strategy and cache replacement strategy [32]. Therefore, this article expands the NS-3 structure by adding LEO satellite modules and develops a hierarchical LEO mega constellation simulation platform, as shown in Figure 12. From top to bottom, the simulation platform consists of four layers, infrastructure, network model, network configuration and control, and supports three-dimensional position and movement characteristics analysis.

The infrastructure layer primarily includes the LEO mega constellation and the ground station used to communicate with the satellite constellation.

The network model layer considers the number of orbital planes in the network, the number of satellites in each orbital plane, the orbital height of the satellite constellation, and ISLs to construct an LEO satellite constellation mobile model. For each orbital plane, the satellite closest to the equator is selected as the “reference satellite”, referring to the satellite geometry analysis in Section 2.2. The displacement between the reference satellite and the nearest satellite on the adjacent orbital plane is used as an increment to automatically determine the closest satellite to every other satellite in the orbital plane. The initial position of the satellite is set according to the orbital coordinates of each constellation. As time passes, the satellite orbits the Earth, and the distance between the satellites at a specific time point is calculated according to the ISL distance formula in Section 2.2. The network model layer also incorporates modules such as flow-monitoring and point-to-point in NS-3. The point-to-point module creates an in-plane link between the two satellite nodes that remains unchanged throughout the simulation period. The carrier sense multiple access (CSMA) module establishes a dynamic interplane satellite link and a link between the ground station and the satellite. CSMA also allows dynamic linking through connection and separation functions; the flow-monitor module allows traffic monitoring to be enabled on all nodes in the satellite-to-earth network. The data collected using traffic monitoring include data packet transmission delay and throughput. The delay of the communication of the LEO mega constellation in the NS-3 code is calculated using the speed of light and the distance between the satellite and ground nodes [54].

The network configuration layer configures the broadcast channel for the LEO mega constellation, configures the requester and content provider for the ground station model, and installs the corresponding NDN protocol or IP protocol for different network environments.

The control layer first applies the relevant mobile model to network the satellite constellation network nodes in the orbital planes and ground stations. The communication between the ground station and the satellite is dynamic. Because the ground station remains stationary, the ground station must switch when updating the connection to the satellite to ensure that it is still connected to the nearest satellite. Second, the top-level control is responsible for maintaining and updating the intersatellite and satellite-to-ground communication links. In addition, it is responsible for data packet storage and routing between nodes in the network.

4.2. Simulation and Performance Analysis

4.2.1. Simulation Scene

According to the Iridium constellation structure in Figure 2, the LEO mega constellation orbit number, number of satellites in each orbital plane, orbital height, satellites on the same orbital plane and links between adjacent orbital planes, and other parameters are configured while maintaining dynamic ISL updating. The orbital coordinates of the Iridium constellation in Table 3 are used as the initial position of the LEO mega constellation.

The coordinates of the two ground stations on Earth are (31° N, 3° E) and (148° N, 99° E), and are denoted by GS0 and GS1, respectively, as shown in Figure 13. GS0 is the requester of interest, and GS1 is the data responder, i.e., producer. Communication between the ground stations is established via the LEO mega constellation ISL with multiple hops. For example, the #13 satellite above GS0 transmits the interest request to GS1 through the #23 satellite, the #44 satellite, the #54 satellite, and the #55 satellite ISL, as shown in Figure 14.

4.2.2. Performance Analysis

Satellite-to-earth communication services transmit text, video or voice. This study analyses the throughput and transmission delay of transmission around the transmission of text-type data packets of different sizes. The transmission rate of the link between the satellite and the ground is 1.5 Mbps, and the transmission rate of the ISL on the same orbital surface and different orbital surfaces of the LEO mega constellation is 25 Mbps [55].

Additionally, for ease of analysis, this paper compares the data packets based on the IP address and the proposed ICN-HMcH naming mechanism. The same LEO mega constellation simulation platform is used in both methods that are investigated in this study using the same simulation scene and parameters. The IP protocol and the NDN protocol are configured in the LEO mega constellation scenario. In a network environment based on the ICN-HMcH naming mechanism, the content storage CS capacity is 10,000 data packets, and the default least-recently-used (LRU) cache replacement strategy and the default broadcast routing strategy are used.

In addition, the system operation event is 2000 s, the link is updated every 100 s, and data packets are sent at a frequency of 100 packets per second.

(1)

Throughput

Throughput is measured by the transmission rate of data packets based on the ICN-HMcH naming mechanism or based on the IP address. For the IP address-based data packets transmitted by the satellite-to-ground network, the throughput is calculated using a flow monitor. For data packets based on the ICN-HMcH naming mechanism, the throughput of each node is calculated by using the ndn::L3RateTracer class.

Figure 15 shows the variation of the communication throughput between the LEO mega constellation for the IoT and the ground station with the size of the data packets of different structures. The route shown in Figure 14 is from ground station 0# to ground station 1#, during which it passes through four hops of ISL. The figure shows that no matter how big the data packet is, the data packet based on the ICN-HMcH naming mechanism performs markedly better than the data packet based on the IP address in terms of transmission performance, increasing throughput by as much as 54%. This result occurs because this paper integrates ICN and the LEO satellite constellation and compares them to other naming methods, such as flat, attribute-value, and hybrid naming methods, on the ground side due to complex naming structures that result in long parsing times of content by nodes and influenced throughput. The ICN-HMcH uses hierarchical and human-readable names to transmit content across the network, eliminating dependence on static locations and IP addresses. Results show that for different business types of IoT, the ICN-HMcH naming mechanism based on the proposed hierarchical structure achieves high throughput.

(2)

Time delay

In the ICN network based on the ICN-HMcH naming mechanism, the end-to-end delay refers to the time required for an interest packet to be transmitted from the requester to the content provider or for the data packet to be transmitted from the content provider to the requester. However, in IP address-based networks, the end-to-end delay is expressed in terms of the time required for IP data packets to be transmitted from the content requester to the server or from the server to the requester and is calculated using a flow monitor. For data packets based on the ICN-HMcH naming mechanism, the ndn::AppDelayTracer class is used to calculate the delay. The output of the tracker is a.txt file, which is composed of delay parameters and other characteristics.

Figure 16 describes the data transmission process of the LEO mega constellation oriented to the IoT and the ground station communication. The time delay varies with the size of data packets of different structures. Compared with data packets based on the IP address, the transmitted data packets based on the ICN-HMcH naming mechanism can reduce the transmission delay of the LEO mega satellites for the IoT by 53.97%. This result occurs because the proposed method does not need to consider the content address of the interest packet sent by ground station #0 so that it can quickly obtain a response from ground station #1. Results show that the transmission delay based on the proposed hierarchical structure of the ICN-HMcH naming mechanism decreases for different types of IoT services.

(3)

Multi-source data retrieval performance

Baseline represents to the scenario of sending one interest for each producer (retrieve one data packet). In Figure 17, the number of interest messages grows linearly when the number of producers increases, whereas ICN-HMcH allows only one interest to be sent and provide in-network data aggregation; therefore, only one interest is used even when the number of producers increases. This results in improved bandwidth utilisation and energy efficiency.

ICN-HMcH needs to receive all response data packets before performing in-network aggregation, whereas baseline performs the same thing but in the application layer. Figure 18 shows that the data collection time for ICN-HMcH is rapid compared to the baseline scenario, especially when the number of producers increases.

5. Results and Discussion

The simulation results in Section 4.2.2 shows that no matter how big the data packet is, the data packet based on the ICN-HMcH naming mechanism performs markedly better than the data packet based on the IP address in terms of transmission performance. Additionally, comparing with data packets based on the IP address, the transmission delay based on the proposed hierarchical structure of the ICN-HMcH naming mechanism decreases for different types of IoT services. In addition, the ICN-HMcH naming mechanism improved bandwidth utilisation and energy efficiency.

This paper applies ICN in space-based networks to alleviate the traffic load of terrestrial networks and provide global “anywhere-anytime” Internet access. In this study, data naming can clearly identify services, content and equipment; meet the requirements of heterogeneity of IoT equipment and applications; and achieve equipment interoperability from different vendors and across domains.

6. Conclusions

The LEO mega constellation facing the IoT is a new and important direction for the development of satellite internet. From the perspective of improving transmission performance, this paper proposes a hierarchical data naming mechanism based on the idea of ICN. The hierarchical nature of the name allows for the naming of content and services, and the naming mechanism also integrates names based on attribute–value pairs to help service identification and add more semantic ways to the name to meet the needs of multiple services in the IoT. In addition, prefix notation is used to overcome the unbounded nature of ICN names. System performance was verified by designing and developing an NS-3-oriented LEO mega constellation simulation platform for the IoT. Simulation results show that, compared with the IP address, the ICN-HMcH naming mechanism can increase throughput by as much as 54% and reduce the transmission delay of the LEO mega satellites for the IoT by 53.97%. The proposed data naming mechanism can provide high Quality of Service (QoS) transmission performance for the IoT-oriented LEO mega constellation and performs markedly better in terms of transmission performance compared to IP. In future research, in-network caching strategies, routing and forwarding strategies should be investigated.