A B5G Non-Terrestrial-Network (NTN) and Hybird Constellation Based Data Collection System (DCS)

Abstract

In beyond 5G (B5G) non-terrestrial network (NTN) systems, satellite technologies play an important role. Especially for data collection systems (DCS), low-earth orbit satellites have many advantages. Such as global coverage, low latency, and high efficiency. As a miniaturization technology, CubeSat has attracted extensive attention from a large number of scholars. Satellite constellations can coordinate for distributed tasks. This paper proposes a B5G NTN-based data collection system. A CubeSat constellation achieves global coverage as the basic space platform for DCS. The 5G terrestrial network is used as the data bearer network of the gateway station. A traffic load balance strategy is proposed to optimize the system’s efficiency. As a unified hardware platform, software-defined radio (SDR) is compatible with various sensor data models. Finally, the design was verified by a series of experiments.

1. Introduction

With the rapid development of beyond 5G (B5G) technologies, many traditional network services are being replaced by space technologies [1]. Especially in the descriptions of 3GPP standards and the Beyond 5G roadmap [2], the non-terrestrial network (NTN) contains low-altitude platforms (LAP), high-altitude platforms (HAP), low-earth orbit satellites (LEO), medium earth orbit satellites (MEO), geostationary earth orbit satellites (GEO), and highly elliptical orbit satellites (HEO). Those multi-layer space platforms can be regarded as B5G remote access networks (RAN), B5G digital forwarding networks (DFN), B5G edge computing (EC) equipment, and B5G core networks (CN). Different applications of space platforms require different ground-supporting technologies [3]. For example, a gateway equipment is necessary for onboard B5G DFN, and large computing power is required for B5G CN. Massive Machine-Type Communications (mMTC) [4] is the main application sceneries of B5G [3]. The higher the altitude platform is, the larger ground coverage is. Comparing to traditional Internet of Things (IoT) systems, the non-terrestrial network-based massive Machine-Type Communications (NTN-mMTC) can achieve higher efficiency narrowband IoT. Large coverage and strong access abilities ensure global real-time data collection.

Moreover, CubeSat is considered an excellent miniaturization application of satellite technology. The unit structure is a cube of 10 cm [5], which is defined as 1U. Each 1U weighs less than two kilograms. CubeSat has the advantages of miniaturization, low cost, and easy launch. However, a 1U CubeSat cannot contain a complete satellite system, which consists of satellite platforms and payloads. A 6U CubeSat is more suitable for space missions. However, the performance of CubeSat is limited due to size constraints [6]. Fortunately, a CubeSat constellation can make up for this default through collaboration. It contains multiple CubeSats that work together to complete integrated missions. For NTN-mMTC, CubeSat constellation can cooperate to complete distributed data collection system (DCS) tasks. This system can greatly enhance the data collection capabilities of ground sensors due to the advantages of global coverage and fast scanning [7]. However, the traditional satellite constellations require independent ground gateway stations. As an application scenario for B5G, NTN-mMTC can use B5G CN as ground infrastructure. Add a satellite-ground-link (GSL) to the RAN, and the traditional independent gateway ground station can be replaced by a B5G base station. This design will greatly reduce construction costs.

Software-defined radio (SDR), an emerging communication technology, has been integrated with satellite technology. SDR-based satellite communication equipment and GSL communication equipment have become research hotspots. The most attractive advantage of SDR is reconfigurability. On a unified hardware platform, different communication functions can be realized by embedding different software packages. This feature is especially suitable for NTN-mMTC. For the reason that it needs to be compatible with many different modes of IoT signals.

In this paper, a CubeSat constellation based on B5G NTN-mMTC DCS is proposed. Constellation topology design, CubeSat platform design, and DCS payload design are proposed. Many simulations and tests are applied to verify this design. Moreover, this design is applying for the engineering stage.

2. Relate Work

There are two most popular IoT technologies, namely low-power wide-range (LoRa) and Narrow Band Internet of Things (NB-IoT). The former requires an independent terrestrial data collection device. The latter can apply the 4G LTE station as infrastructure.

LoRa has received increasing attention for the following three main reasons [8]: (a) companies building a large industry to collect data and control remotely, (b) 45.12% people worldwide with 3.5 billion smart phones willing to apply IoT systems remotely by the phone, and (c) people interested in monitoring and controlling their appliances at low cost and power.

LoRa-based IoT systems offer a cost-effective and straightforward application [9,10]. It adopts a modulation technique that is capable of transmitting 300~19,200 bps data rate, and the maximum communication distance is about 11 km. In contrast, Bluetooth, Wi-Fi, and ZigBee cannot cover a wide area [11]. A LoRa-based automation system is designed and developed to control appliances in industry [12]. In IoT systems, access control systems are built using Blockchain Managers (BCMs) for securing IoT access [13].

However, this terrestrial IOT system needs to be equipped with an independent data receiving device. And it needs to rely on the ground network for data collection [14]. Furthermore, the limited reception of the receiving station prevents global coverage.

With the gradual maturing of B5G and cloud technology, numerous wireless electronic devices have access to cloud servers, which allow the users to acquire and analyze large amounts of data [15,16,17,18]. A NB-IoT system for remote fire monitoring is proposed [19]. It is driven by a magnetic-assisted noncontact energy harvester (MN-EH), which hybridizes piezoelectric and electromagnetic genes. This system can solve the energy problem using the NB system.

Although many IoT systems have been widely used in terrestrial applications, they have many disadvantages: depending on the ground infrastructure; small ground coverage and customized signal model. Non-uniform terminal sensors require IoT systems compatible with different frequency bands, modulation methods, and coding methods. A qualified IoT system must be capable of global coverage, express scanning, and multi-mode compatibility. These challenges are difficult to meet simultaneously for traditional terrestrial IoT systems. Fortunately, a CubeSat constellation-based NTN system can solve these problems.

As a space data relay system [20,21], non-geostationary (NGSO) systems provide high-bandwidth data services to aircraft, ships, and terrestrial sensors. Some established NTN systems are shown in

Table 1. Current and Planned non-GSO systems.

Characteristics	StarLink	OneWeb	LightSpeed	O3b
Downlink data rate	100 Mbps	200 Mbps	50 Mbps	400 Mbps
Uplink data rate	14 Mbps	40 Mbps	10 Mbps	150 Mbps
Number of satellites	1584	358	289	34
Latency	35 ms	70 ms	40 ms	100 ms
Orbit altitude	560 km	1200 km	1015 km	3000 km
Coverage diameter	650 km	1400 km	1200 km	3500 km
Frequency bands	Ku, Ka	Ku, Ka	C, Ka, Ku	Ka

. Due to the high altitude, these NTN systems can achieve global coverage. The diameter of the coverage area can be up to 1.5 times the orbital altitude [22,23]

However, these NTN systems must still rely on independent ground gateway equipment. They are unable to communicate with the 5G system directly. This shortcoming will not only increase the construction cost but also degrade the communication performance.

Some important key performance indicators (KPI) of B5G [24] are shown in

Table 2. Key performance indicators.

KPI	Terrestrial 5G	NTN B5G
Peak data rate	20 Gbps	1 Tbps
Experienced date rate	0.1 Gbps	1 Gbps
Peak spectral efficiency	30 bps/Hz	60 bps/Hz
Experienced spectral efficiency	0.3 bps/Hz	3 bps/Hz
Maximum bandwidth	1 GHz	100 GHz
Area traffic capacity	10 Mbps/m2	1 Gbps/m2
Connection density	106 devices/km2	107 devices/km2
Energy efficiency	Not specified	1 Tb/J
Latency	1 ms	1 us
Bit error rate	10−5	10−9
Jitter	Not specified	1 μs
Mobility	500 km/h	1000 km/h

. The main application scenarios of NTN are oceans, mountains, and remote regions. For those scenarios, terrestrial infrastructure cannot be constructed [25].

The NTN-mMTC system is the integration of the NTN system with the terrestrial 5G network. The NTN system enables the construction of IoT collection equipment on satellite platforms. This design guarantees global coverage and fast scanning. The mMTC technology uses the terrestrial 5G network as the backhaul network for IoT. DCS equipment is the key technology of NTN-mMTC. The performance of the DCS determines ground sensor data collection performance. Especially for scenarios with low emission energy and complex signal modes, the performance of DCS is the most important

As a satisfactory DCS equipment, it should be compatible with different IoT signal models such as AIS, ADS-B, vehicle position applications, and various remote sensors. Those IoT systems are applied in various frequency bands, from the VHF band (140 MHz) to the C band (5 GHz).

For traditional DCS devices, it is necessary to independently set up a data receiving channel for different signal modes. This will greatly increase the operational burden on satellites. Fortunately, reconfigurable receiving equipment can solve this problem.

An SDR-based reconfigurable multi-modal transceiver for CubeSats is proposed [26]. It can support various standard transmission formats. The main software architecture depends on the Fast-Fourier Transform (FFT) processing block. With the idea of modularization, it is possible to design systems with different functions on a unified platform

There are five upcoming NTN system [27]. The performance of these communications is simulated by AGI’s Systems Tool Kit (STK). A LoRa module based on a Software Defined Radio (SDR) is proposed [28]. Its main function is to receive information from remote oil fields. However, these studies cannot meet the requirements of low cost, global coverage, and multi-modal compatibility at the same time.

Therefore, a CubeSat constellation-based NTN-mMTC system is necessary. The DCS equipment is an important component of the NTN-mMTC system. In order to achieve reconfigurability, SDR-based DCS equipment needs to be studied.

3. Topology Design

As described in the B5G roadmap 2022, B5G NTN system contains multiple space orbits with different altitudes. For IoT applications, orbit design must balance global coverage and communication costs. Based on the link analysis, LEO has the advantages of low latency, fast scanning, and low transmission loss. In addition, a symmetrical constellation topology can achieve global coverage. Therefore, a LEO constellation is suitable for the application.

There are two different symmetry constellation topologies, namely the Walker constellation and polar constellation. The former topology contains several vertical circle orbits. The inclination of the polar axis is about 90 degrees, as shown in Figure 1a. The later topology contains several inclined circle orbits, evenly distributed on the equator. The inclination of the Walker is about 65 degrees, as shown in Figure 1b.

The Polar constellation can achieve global coverage but suffers from reverse seams and traffic hotspots. The Walker constellation obtains better coverage performance in the middle and low latitude areas. However, it suffers from no coverage area in the polar regions.

As we all know, the traffic of ground sensors relates to population distribution. The traffic is higher in the low latitude regions. NTN-mMTC needs to satisfy traffic hotspots in low-latitude regions while achieving global coverage. Therefore, a hybrid constellation consisting of the Walker constellation and Polar constellation is suitable.

A hybrid constellation is shown in of Figure 1c, two different constellations work together. The design of hybrid constellation needs to take into account not only global coverage, connectivity but also safety. For a multi-satellite constellation, the most important criterion is collision avoidance. This safety mechanism is mainly through orbit design and prediction. In the design phase, the distance between any two satellites must be greater than the minimum safe distance (MSD). For this optimization goal, some design item in

Table 3. DCS constellation design.

Item	Walker	Polar
Orbit plane number	6	3
Total satellite number	36	6
Orbit latitude	500 km	550 km
Orbit inclination	55°	89°
RAAN	60°	60°
Phase delta	4	8

are iterated and simulated by commercial software STK. RAAN means the right ascension of the ascending node.

The specific hybrid constellation consists of 42 CubeSats. 36 CubeSats belong to the Walker topology, and 6 CubeSats belong to the Polar topology. Due to the narrowband requirement of DCS, this small-scale constellation is more efficient than a mega constellation like StarLink.

As shown in Figure 2, 42 CubeSats scatter around the world. They periodically scan terrestrial sensors. The half power band width (HPBW) of each DCS antenna is not less than 50 degrees. For an orbital altitude of 500 km, the receiving range of the DCS equipment exceeds 1000 km.

In order to achieve higher resource reuse efficiency, multi-beam antennas and MF-TDMA can also be applied to DCS equipment.

4. Network Design

Based on the analysis of NTN-mMTC, DCS equipment, and the hybrid constellation, a space-ground integrated network design is proposed in this chapter. The traditional 5G networks consist of an access network, a bearer network, and a core network. An improved network structure combining NTN and B5G needs to be proposed. A B5G-based NTN can be divided into various application scenarios.

As shown in Figure 3, there are four different application scenarios. In the access network, there are direct access mode and indirect access mode. In the former mode, signals are directly transmitted from ground sensors to satellites without any relay equipment. In the later mode, signal is collected by gateway and relayed to satellites. Such a collection gateway can be realized by a terrestrial base station or a high-altitude platform station.

In bearer network, there are transparent forwarding model, regenerating forwarding mode and onboard forwarding mode. In first mode, the radio frequency (RF) signal is filtered and amplified in satellites. This method is simple and energy-efficient. In secondary mode, the signal will be decoded, error corrected, and re-encoded in satellite. This method is complex and expensive but can greatly increase the signal-noise-radio (SNR). This mode is more suitable for the multi-hop relay scenario. In the last mode, more advanced algorithms are introduced in the signal process. This is the most complex and smartest signal process.

In the core network, NTN can be classified as network elements. User plan function (UPF) is the most relevant to data-plane functions among all core network elements. UPF should be responsible for data transfer and QoS guarantees. It can be allocated via satellite or ground station gateway.

For compatibility with the B5G terrestrial network, network slicing (NS) and network function virtualization (NFV) are utilized in different sceneries. The QoS assurance, routing algorithm, and interface control strategy are supported by the UPF block in Figure 4. The N9 interface and UPF element can be allocated on satellites or ground station gateways.

In order to increase system efficiency, the distribution of UPF should be dynamically adjusted. In a unified hardware platform of DCS equipment, different functions should be realized according to the requirements. Software defined radio (SDR) architecture is able to meet these requirements.

5. Traffic Balance Design

In the B5G system, the QoS guarantee is crucial. For DCS equipment, data receiving capability is the most important KPI of the QoS guarantee. As described in Section 3, traffic density is related to geographic location. And traffic congestion is more likely to occur in traffic hotspot. A geolocation-based traffic forecasting model is essential for traffic balance and QoS guarantee.

The distribution of traffic data obeys the global population density. As shown in Figure 5 [29], the population is mainly concentrated near the equator. Traffic density will be greater in areas of high population density. Traffic burden is related to the latitude of regions. A traffic estimation can be defined as:

$$T_b(lat)=\left\{\begin{array}{ll}110-\left|lat\right|+△l\hfill & \left|lat\right|\le {35}^{\circ }\hfill \\ 100-\left|lat\right|+△l\hfill & {35}^{\circ }<\left|lat\right|<{50}^{\circ }\hfill \\ 95-\left|lat\right|+△l\hfill & \left|lat\right|\ge {50}^{\circ }\hfill \end{array}\right.$$

(1)

$$△l=\left\{\begin{array}{ll}\frac{90}{\left|lat\right|}\hfill & lat>0\hfill \\ 0\hfill & lat\le 0\hfill \end{array}\right.$$

(2)

where lat is the latitude of region, t is the local time.

The throughput of a CubeSat can be defined as:

$$T_p(t)=BW(t)\cdot CD(t)$$

(3)

where BW(t) is the residual bandwidth of the CubeSat and CD(t) is the connect duration between the specific CubeSat and the covered region.

Once the constellation topology is designed, the connect duration can be predicted. It is determined by the access between satellites and sensors. In order to increase communication efficiency, CD(t) should be dynamically adjusted according to traffic demand. A traffic cycle (TC) can be defined as:

$$TC(lat,t)=\frac{T_b(lat)}{T_b(t)}$$

(4)

To predict the BW(t), a virtual topology (VT) technology is used. In VT, the whole operation period is evenly divided into a lot of time slots (T_s). In each T_s, the constellation topology and network mode are considered static.

$I_n$, $O_n$ and $L_n$ are defined as input flow, output flow and queuing length in n$\cdot$Ts. $I_{avg}$ and $O_{avg}$ are time balance value of input flow and output flow. ${\lambda }_i$, ${\lambda }_o$ and ${\lambda }_l$ are memory factor.

$$I_{avg}=(1-{\lambda }_i)\cdot I_{n-1}+{\lambda }_i\cdot I_n$$

(5)

$$O_{avg}=(1-{\lambda }_o)\cdot O_{n-1}+{\lambda }_o\cdot O_n$$

(6)

$$L_n=(1-{\lambda }_l)\cdot L_{n-1}+{\lambda }_l\cdot |I_n-O_n|$$

(7)

$$BW(t)=(1-{\lambda }_b)\cdot BW(t-T_s)+{\lambda }_b\cdot \frac{L_n}{L_{\max }}$$

(8)

where BW(t) is relate to BW(t–Δt) and $L_n$ ${\lambda }_b$ is the adjust factor, $L_{max}$ is the maximum storage space in each satellite. There are three operation state defined as:

$$State=\left\{\begin{array}{ll}Idle\hfill & L_n\le L_{\max }-2\cdot (I_{avg}-O_{ovg})\hfill \\ Busy\hfill & L_{\max }-2\cdot (I_{avg}-O_{avg})<L_n\le L_{\max }-I_{avg}+O_{avg}\hfill \\ Occupied\hfill & L_n>L_{\max }-I_{avg}+O_{avg}\hfill \end{array}\right.$$

(9)

In an idle state, satellites will normally receive data and relay it; in a busy state, satellites will degenerately receive data and normally relay; and in an occupied state, satellites will stop receiving data and only relay data. Load balancing can be achieved by this traffic control strategy.

The value range of ${\lambda }_i$, ${\lambda }_o$, ${\lambda }_l$ and ${\lambda }_b$ is between 0 and 1. The selection of these factors will affect the results of traffic estimation. In this paper, a satisfaction goal function (SGF) is introduced as the optimization objective, and four factors are defined as adjusted values.

$$S\mathrm{G}F=\frac{BW(t)}{B{W}_{total}}+\frac{L_n}{L_{\max }}+\frac{I_{avg}+O_{avg}}{C}$$

(10)

where $B{W}_{total}$ is the total bandwidth resource of the satellite, C is power consumption of sending and receiving unit data flow. SGF consists of three parts which represent spectrum resource, queue delay and power consumption respectively. In order to get more detailed optimization results, four factors are divided into two steps. In the first step, factors are set to a step of 0.1, and the value ranges from 0 to 1. And traverse all combinations to find the minimum value of SGF. The second part is based on the previous step, and factors are set to a step of 0.01.

The operation state of DCS should be controlled by DC (lat, t). In an idle or busy state, CubeSat can be used as a space data collector. On the contrary, it is disabled for ground devices. Moreover, onboard process functions can be introduced to increase system efficiency. Limited storage capacity can also be improved by information preprocessing. Invalid data is deleted in the preprocessing function. Valid data is compressed and returned to the ground data center.

To increase system efficiency, the above strategy can be embedded in a unified hardware platform. A uniformed software-defined radio (SDR) platform is preferred.

6. DCS Equipment Design

6.1. Module Design

NTN-mMTC DCS equipment is comprehensive sensor data collection equipment. Various signaling modes should be compatible. For traditional applications, the Automatic Identification System (AIS), Automatic Dependent Surveillance-Broadcast (ADS-B), Lora, NB-IoT, Beidou text, and military sensors (MS) need to be compatible. These applications work in different operating modes, frequency bands, and power consumption levels, as shown in

Table 4. Various DCS applications.

Item	Freq	Rate	Modulation	Protocol	Object
AIS	VHF	9.6 Kbps	GMSK	HDLC	Ship
ADS-B	L	1 Mbps	PPM	CRC	Aircraft
Lora	UHF or S	0.3~50 Kbps	Spread spectrum	FEC	Ground
NB-IoT	S	1 Mbps	QPSK	OFDM	Ground
Beidou	S/L	/	/	RDSS	Ground
MS	C	10 K~1 Mbps	BPSK	/	/

. Due to miniaturization and reconfigurability, the SDR architecture is suitable for the specific application. Different data collection functions can be realized on a unified SDR hardware platform. Several antennas resonating in different frequency bands are required.

The USRP E310 is a unified SDR platform with continuous frequency coverage from 70 MHz to 6 GHz. As shown in Figure 6, the integrated RF frontend on E310 is designed with the analog devices AD9361. A FPGA chip is responsible for the digital signal process such as digital filter and resample. Ubuntu system is embedded in it. All baseband process and application functions are realized in Ubuntu. The power supple is 5.15 v DC and an external is allowed.

A NTN-mMTC-based DCS equipment based on the E310 platform is shown in Figure 7a. It contains an SDR module, a radio frequency (RF) front-end module, a power supply module, and a connector module. E310 is implemented as a SDR module. Other modules are self-developed. Multiple antennas are shown in Figure 7b. This CubeSat flies along the X axis and keeps the Z axis pointing to the earth. A pair of tape measure antennas in UHF and VHF bands are mounted on the top. A L-band whip antenna is mounted on the bottom. A pair of patch antenna in S-band and C-band are mounted on the body of CubeSat.

The performance of the RF module affects the communication capability. For a 500 km orbit altitude, the detailed design parameters are shown in

Table 5. RF front-end design parameters.

Item	VHF	UHF	L	S	C
Output Power	1 W	1 W	1.5 W	2 W	2.5 W
Antenna Gain	0 dBd	0 dBd	2 dBd	3 dBd	3 dBd
EIRP	30 dBm	30 dBm	33.7 dBm	36 dBm	37.7 dBm
LNA Gain	30 dB	30 dB	25 dB	20 dB	20 dB
NF	0.6 dB	0.6 dB	1 dB	1.5 dB	2 dB

.

6.2. SDR Design

A Gnu Radio Companion (GRC) software platform is implemented in the SDR. Various communication functions can be defined as flows in GRC. Each flow is configured by several blocks, as shown in Figure 8a. A lot of basic blocks are defined internally by GRC. Customized blocks can be self-defined by python 3.8 or C++.

In the specific DCS equipment design, all communication modes can be satisfied by internally defined blocks. To optimize the performance of receivers, multiple design parameters are adjusted and iterated. Receive sensitivity and doppler frequency correction are the main optimization goals, as shown in

Table 6. SDR receiver performance optimization requirements.

Item	AIS	ADS-B	LORA	NB-IoT	Beidou	Military
Receive sensitivity	−107 dBm	−98 dBm	−115 dBm	−110 dBm	−100 dBm	−90 dBm
Doppler frequency	15 kHz	40 kHz	100 kHz	100 kHz	40 kHz	200 kHz

.

As shown in Figure 9, different signal modes can be compatible by relative flow designs.

6.3. Operation Control

Based on the flow designs, SDR-based DCS equipment can be constructed. A duty planning strategy is necessary for resource allocation. The orbit period is equally divided into time slots, as shown in Figure 10a. Each slot is engaged by a duty. And the “break in” task and the “forbid” task are responsible for urgent task and fault task. Each task can include “duty”, “break in”, and “forbid”.

The specific schedule is configured by a duty planning strategy, as shown in Figure 10b. All tasks in the schedule can be determined by the tele-command (TC) from ground stations. The “forbid” task can also be determined by the on-board computer. A restart function is introduced to avoid infinite loops. The periodical loop between the “operation begin” function and the “operation delay” function is the main operation in this strategy.

A cloud-server-based ground station network [30] is introduced as a gateway network. There are six ground gateway equipment, which work together to increase data transmission efficiency. They are No. 1, Haerbin (128°4′, 45°3′); No. 2, Shanghai (121°3′, 31°0′); No. 3, Xi’an (108°4′, 33°8′); No. 4, Yunnan (103°4′, 25°3′); No. 5, Qinghai (95°0′, 36°2′); and No. 6, Xin-jiang (80°6′, 39°4′), as shown in Figure 11. Task schedules are uploaded to CubeSats from the ground station network. All CubeSats will accomplish the tasks according to the arrangements.

The ground gateway equipment is composed of USRP B201 and Raspberry Pi 4B, as shown in Figure 12. After data packets have been collected by DCS equipment from ground sensors, they will be transmitted to ground gateway equipment. Each piece of gateway equipment is connected to the terrestrial 5G network via an Ethernet interface. All collected data packets are sent to the terrestrial 5G core network through the terrestrial 5G bearer network. GMSK and BPSK are the modulation methods of the downlink channel, which back up each other.

7. Simulations and Experiments

A CubeSat-based NTN-mMTC system contains orbit topology design, network design, and DCS equipment design. A series of simulations and experiments are implemented to verify the design. The verification consists of two parts: constellation simulations and equipment simulations.

7.1. Satellites Constellation Simulations

As described in Section 3, a hybrid constellation containing Walker and Polar is designed. There are 42 CubeSats between 500 km altitude and 550 km altitude. Those CubeSats can scan the world periodically. As described in Section 5, the traffic density is related to latitude. Some key parameters with different latitudes are simulated in this chapter.

To verify the orbit design, several key performances are simulated. Such as connection opportunity, connection duration, total duration, and duty cycle. The connection opportunity indicates the maximum number of connections at different latitudes during the simulation period. Connection duration indicates the longest and shortest time of each connection during the simulation period. The total duration indicates the total connection time in the simulation period at different latitudes. The duty cycle is an optimization parameter, indicating the access capability of the constellation.

Several simulations are performed by the commercial software STK and Matlab. To be more representative, these simulations are performed by a unified model and interface. The basic simulation parameters are described as follows:

• Simulation period 24 h;
• BW: 1 Mbps for each satellite;
• Node number: 36 nodes for walker constellation and 6 nodes for polar constellations;
• Latitude range: −90°~+90°;

As shown in Figure 13a, different connection opportunities are obtained at different latitudes. The maximum connection opportunity appears in middle latitude, and the minimum connection opportunity is more than 16. The connection durations are described in Figure 13b. It also follows the population distribution. However, in polar regions, the connection duration is long because of the orbit cross.

The total duration in 24 h at different latitudes is shown in Figure 14a. This parameter can comprehensively represent the access capability of the orbit. The throughput between a specific CubeSat and regions can be exported from Equations (1) and (2) in Section 5.

To optimize the efficiency of DCS, a duty cycle (DC) parameter can be used to control the operation state of CubeSats. DC is related to time and latitude. It can be deduced from the total duration and Equation (3). The results calculated by Matlab are shown in Figure 14b. Under the same throughput requirement, the DC parameter represents the working saturation of CubeSats at different latitudes. This working saturation contains output power, data rate, and storage ratio.

This parameter can also be used to control the onboard operation. An optimized control plan for CubeSat can accomplish energy balance and communication guarantee. However, the BW and connection will dynamically change in the actual operation. An adaptive control strategy is necessary in the B5G control plane.

7.2. DCS Receiver Simulations

The DCS equipment is based on the SDR platform, and each application corresponds to a GRC flow. The specific GRC flow design was shown in Figure 9, and the results of simulation are shown in Figure 15 individually.

A series of discrete pulses about PPM modulation belongs to ADS-B. A GMSK signal spectrum belongs to AIS. A two-symbol constellation about BPSK belongs to special military applications. Spread spectrum is the key technology of LORA.

7.3. Gateway Backhaul Simulations

Based on the design of the above ground gateway network, the results of connection simulation within 24 h are shown in

Table 7. Link status in 24 h.

Link Num	Start	Over	Duration (s)	Regions	Highest Pitch Angle (°)	Shortest Distance (KM)
1	09:07:57	09:14:16	379	Haerbin	24.5	1097
2	09:13:00	09:17:28	268	Shanghai	15.0	1456
3	10:41:54	10:48:14	380	Haerbin	25.4	1073
4	10:46:06	10:52:14	358	Shanghai	23.1	1108
5	10:45:28	10:52:46	438	Xi’an	46.1	701
6	10:48:04	10:54:42	398	Yunnan	28.8	969
7	12:19:27	12:25:48	381	Xinjiang	25.0	1077
8	12:20:18	12:27:21	442	Qinghai	36.7	821
9	12:24:04	12:26:00	116	Yunnan	10.8	1695
10	13:53:41	13:59:16	335	Xinjiang	19.7	1255
11	19:50:24	19:55:22	296	Haerbin	16.4	1405
12	21:19:16	21:26:43	446	Shanghai	56.6	618
13	21:23:00	21:30:13	433	Haerbin	37.3	820
14	21:23:01	21:26:17	195	Xian	12.3	1615
15	22:52:40	23:00:13	453	Yunnan	76.6	536
16	22:54:51	23:01:46	414	Xi’an	32.2	902
17	22:55:03	23:02:12	428	Qinghai	39.0	791
18	23:00:20	23:02:29	129	Xinjiang	10.9	1700

. Each satellite has multiple connection opportunities in a day.

As shown in Table 7, a CubeSat has 18 opportunities to build a connection within 24 h. According to different channel environments, different numbers of data packets can be downloaded over a connection. The average number of data packets downloaded by all satellites is shown in Figure 16. The size of each package is 100 Mbit. For a CubeSat, the maximum amount of data that can be downloaded per day is about 320 Gbit. Such transmission capability far exceeds the requirements of NTN-mMTC.

Those simulations verify the DCS equipment for various signals. Different GRC flows are operated according to task schedules. All task plans can be received from the ground command center. The main purpose of the CubeSat is to collect various ground sensor data and relay it back to the terrestrial B5G network.

8. Conclusions

In this paper, a B5G NTN and hybrid CubeSat constellation-based date collection system are introduced. After analyzing related work, a hybrid constellation consisting of 42 CubeSats is designed. There is a Walker constellation and a Polar constellation in hybrid topology. A B5G-based network design realizes the integration of a terrestrial B5G network and a CubeSat network. The payload data of CubeSats will be transmitted over terrestrial B5G network. A load balance analysis not only illustrates the performance of the CubeSat constellation but also assists CubeSat operation. All payload receivers are realized by software defined radio platforms. The GRC flow designs contain a variety of different signal modes. A series of simulations about orbit topology and SDR are used to verify DCS. As the results show, the specific constellation has a high connection duration and high efficiency, and the SDR design can satisfy multiple signal modes at the same time. The specific data collection system fully meets the requirements of NTN applications.