Research on Key Technologies of Elastic Satellite Optical Network Based on Optical Service Unit

Abstract

With the advent of 6G technologies, satellite communication networks are in urgent need of innovative bearer technologies to meet the demands of government and enterprise private lines as well as computing power networks. We propose optical service unit-based optical inter-satellite links (OISL-OSU) as a solution to address the current limitations in fine-grained service bearing within optical transport networks (OTNs), thereby enhancing the flexibility and efficiency of satellite optical networks. Comparative tests were conducted between OISL-OSU and existing packet-switching technologies in multi-service satellite optical transport networks. Through hardware-in-the-loop simulation verification, key performance indicators such as delay optimization, bandwidth utilization rate, and flexible resource adjustment capability were systematically evaluated. Experimental results demonstrate that OISL-OSU technology exhibits superior performance in delay optimization and fine-grained service bearing. The flexible mapping and multiplexing mechanism of OISL-OSU significantly improves resource utilization efficiency, decreases transmission delay, and strengthens hard-pipe connection capabilities.

1. Introduction

The low Earth orbit (LEO) Internet constellation represents a critical strategic infrastructure for the 6G space–terrestrial–sea three-dimensional network. The intrinsic characteristics of transparent forwarding and high mobility introduce substantial complexity to maintaining stable quality of service in traditional network architectures, thereby presenting significant challenges to the deployment and advancement of delay-sensitive space-based applications [1,2,3]. Consequently, the evolution of service and data forwarding paradigms within satellite networks has become an inevitable trend to enhance the service capabilities of space-based networks. Investigating deterministic networking technology is crucial for improving the service quality of LEO satellite optical networks, ensuring national infrastructure security, and expanding information coverage capabilities. In the literature [4,5], the concept of a novel optical service unit (OSU) and its associated requirements are introduced, with detailed descriptions of the primary technical elements of OSUs provided. In 2024, the China Communications Standards Association (CCSA) established an industry standard for OSUs [6]. Subsequently, China TELECOM developed a metro-optimized optical transport network (M-OTN) based on an OSU, enabling flexible transport for sub-1G applications [7,8]. Furthermore, the 6G network system must consider multiple scheduling factors, including business requirements, network resources, and equipment energy consumption. Different services impose distinct quality-of-service (QoS) requirements, such as latency, jitter, isolation, security, and robustness [9], necessitating customized network communication and computational power supply solutions. Since then, researchers have been dedicated to exploring the potential scalability of OSUs in space–terrestrial networks. An AI-augmented hybrid framework has been proposed, integrating deep reinforcement learning (DRL) for adaptive network slicing and graph neural networks (GNNs) for autonomous self-healing, to facilitate joint resource–service orchestration in the intelligent evolution of 5G [10]. As demonstrated in our prior work, integrated satellite routing optimization algorithms leveraging OSUs and DRL methodologies, such as the depth deterministic policy gradient (DDPG), have been devised to address challenges related to resource allocation and cross-orbit traffic scheduling in multi-satellite networks [11].

The technical evolution of satellite optical networking, from IP (shared resource architecture), through OTNs (physical isolation architecture), to all-optical architecture (pure photonic operation) are summarized in

Table 1. Comparison of satellite optical networking.

Networking Type	Principle	Features
IP	Switching/routing based on layer2/layer3 user data	Statistical multiplexing, flexible scheduling, high bandwidth utilization; different services share network resources, mutually competing and affecting each other [12,13,14].
OTN	Layer1 networking without IP resource occupation	Physical resource isolation of different layer1 channels, absolute guarantee of bandwidth, delay, and jitter; suitable for industry-level slicing [2,3,15].
All-optical	Layer0 (wavelength-level) networking with all-optical switching	Wavelength-level scheduling, all-optical switching, does not occupy electrical layer resources, lowest efficiency/energy consumption; large scheduling granularity, suitable for high-bandwidth service scenarios [16,17,18].

.

Currently, there exist several critical challenges in Internet protocol (IP)-based satellite optical networks:

1.

For IP over Consultative Committee for Space Data Systems (IPoC), IP-based optical satellite networks typically do not incorporate bandwidth resource information into their design;

2.

IPoC fails to establish the transmission of overhead information, thereby precluding integration across physical, application, and network management layers, which hinders the realization of an intelligent network architecture;

3.

Packet-forwarding optical satellite networks lack interoperability with terrestrial OTNs.

To address these challenges, we propose an innovative satellite optical network architecture leveraging optical inter-satellite links based on OSU infrastructure, referred to as OISL-OSU. The primary contributions are summarized as follows:

1.

Considering the instability of the inter-satellite wireless communication environment, Reed–Solomon (RS(255,223)) coding is employed to enhance forward error correction (FEC) performance in OISL-OSU. A comparative analysis with RS(255,239) used in M-OTN is provided. Specifically, a tailored encoding interleaving method for RS(255,223) is developed and detailed in Section 2 (Section 2.2.2).

2.

To bridge the gap between theoretical models and practical implementation, a hardware-in-the-loop simulation platform is established to evaluate the performance optimization of OISL-OSU compared to existing packet-switching methods in Section 3 (Section 3.1).

The remainder of this paper is organized as follows. In Section 2, the framework and principles of OISL-OSU are introduced. Simulation setups and results are discussed in Section 3. Finally, concluding remarks are presented in Section 4.

2. Methods

2.1. OISL-MPLS Packet Switching

As depicted in Figure 1a, OISL multi-protocol label switching (OISL-MPLS)-based packet switching splits a block from the transmission frame insertion field of an advanced orbiting system (AOS) standard frame as an extended control field to accomplish AOS frame forwarding based on labels and support multiple types of services [19,20]. The extended control field comprises a label field and a data communication network (DCN) field. Using the label domain, AOS frame forwarding is developed on label switching routers (LSRs) to replace IP address-based routing forwarding. Multiple types of services are supported, with different types inserted into the Transfer frame data field of the AOS frame for transmission, as illustrated in Figure 1b.

2.2. OISL-OSU Service Slicing

2.2.1. Mapping and Multiplexing OISL-OSU Signals into an OISL-OPU

The OISL-OSU protocol stacks are illustrated in Figure 2. Figure 2a depicts the frame encapsulation processes. Specifically, Gigabit Ethernet (GE) and 10 Gigabit Ethernet (XGE) interfaces connect to the Ethernet service interface through the physical layer (PHY) and the medium access control (MAC) layer. This Ethernet service interface is responsible for transmitting and receiving Ethernet frames. After processing within the MAC layer, the Ethernet frames are directed into the first-in-first-out (FIFO) queues associated with the virtual local area network (VLAN) and Internet Protocol (IP) layers. The 10 Gigabit Media Independent Interface (XGMII) serves as the standard interface for XGE, enabling the connection between the MAC layer and the PHY layer. Following conversion into the XGMII format, the Ethernet frames undergo 64-bit/66b-bit encoding and are subsequently transformed into 257-bit data blocks. The primary purpose of the 64-bit/66-bit and 66-bit/257-bit encoding schemes is to ensure compatibility with the higher-layer framing structure. Finally, the 257-bit data is encapsulated into a 192-byte OSU frame.

Moreover, the OISL-OSU adheres to the hierarchical International Telecommunication Union—Telecommunication Standardization Sector (ITU-T) G.709 compliant architecture, as presented in Figure 2b [21]. On the transmitter side, the processing involves optical channel payload unit (OPU) mapping, optical channel data unit (ODU) multiplexing, optical channel transport unit (OTU) encapsulation, forward error correction (FEC) coding, and scrambling for synchronization and robustness. Conversely, on the receiver side, the processing includes descrambling, frame alignment, FEC decoding, ODU demultiplexing, and OPU payload extraction.

2.2.2. RS(255,223) Interleaving and Encoding

After two decades of development, terrestrial OTNs have adopted the RS(255,239) encoding scheme with an interleaving depth of sixteen. This decision was made after careful consideration of service and channel characteristics to achieve a balance between minimizing delay and effectively combating burst errors. In contrast, OISL-OSU functionality exhibits significantly lower link stability compared to terrestrial OTNs. Therefore, within the framework of the mature terrestrial system, further optimization of the data interleaving depth is necessary. Consequently, this paper proposes the use of the RS(255,223) encoding scheme with an interleaving depth of thirty-two.

In inter-satellite laser links, the fixed-step accuracy of optical head movement introduces instability into the communication channel. As a result, the RS decoder may encounter data streams containing consecutive symbol errors spanning dozens of symbols with a certain probability. The RS(255,223) encoding scheme, with its interleaving depth of thirty-two, distributes these consecutive errors across thirty-two RS codewords for decoding. By comparison, OISL-MPLS employs an interleaving depth of only four. Consequently, each RS codeword in OISL-MPLS must process a greater number of error bytes, thereby increasing the likelihood of decoding failure.

Table 2. RS(255,223) parameters.

Item	Explanation
Coding scheme	System code $(n,k)$, where: - Code length: $n=255$ symbols - Code payload: $k=n-r=223$ symbols - Overhead: $r=32$ symbols
Error correction capability	16 RS symbols
Primitive polynomial	$\mathrm{F}\left(x\right)=x^8+x^7+x^2+x+1$, belonging to the Galois Field $GF\left(2^8\right)$
Generating polynomial	$\begin{array}{cc}\hfill g\left(x\right)& =\prod _{j=112}^{143}\left(x-{\alpha }^{11j}\right)=\sum _{i=0}^{32}{G}_i{x}^i,\mathrm{where}F\left(\alpha \right)=0,\mathrm{with}{\alpha }^{11}\mathrm{as}\mathrm{primitive}\mathrm{element}\hfill \end{array}$

presents the RS(255,223) parameters utilized in OISL-OSU.

The implementation process of RS coding interleaving is shown in Figure 3. In the FEC process, one line of OISL-OTU-FEC frame data is divided into sixteen sub-lines according to the method of inter-byte interpolation, and one of the sub-lines is processed by each FEC encoding. The byte transmission sequence of the OISL-OTU-FEC frame after applying RS interleaving coding is depicted in Figure 4.

The uncorrectable bit error rate (effective bit error rate) after interleaving and RS(255,223) encoding is given by [22]

$$p_{eff}=\sum _{i=t+1}^D\left({\displaystyle \genfrac{}{}{0pt}{}{D}{i}}\right)p_b^i{(1-p_b)}^{D-i}$$

(1)

where t denotes the maximum number of errors that the RS code can correct (error correction capability), D represents the interleaving depth, and $p_b$ is the bit error rate of the original channel (before error correction). The binomial term $\left({\displaystyle \genfrac{}{}{0pt}{}{D}{i}}\right)p_b^i{(1-p_b)}^{D-i}$ represents the probability of exactly i errors occurring in an interleaved block (containing D symbols).

Each symbol of RS is an element of $GF\left(2^8\right)$, and a specific basis can be chosen to represent each symbol. Specifically, the following hold@

1.

The first basis is $\{1,{\alpha }^1,{\alpha }^2,\dots ,{\alpha }^7\}$, such that any symbol can be expressed as

$$u_0{\alpha }^0+u_1{\alpha }^1+\dots +u_7{\alpha }^7,u_i\in \{0,1\}$$

(2)

2.

The second basis is $\{1,{\beta }^1,{\beta }^2,\dots ,{\beta }^7\}$, where $\beta ={\alpha }^{117}$. On this basis, there exists a dual basis $\{l^0,l^1,\dots ,l^7\}$ with the following characteristics:

$$T_r\left(l_i{\beta }^j\right)=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}i=j\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right.,j=0,1,\dots ,7$$

(3)

where $T_r\left(z\right)$ is defined as

$$T_r\left(z\right)=\sum _{k=0}^7{z}^{2^k},z\in GF\left(2^8\right)$$

(4)

Then each symbol of the RS can be expressed as

$$z_0{l}_0+z_1{l}_1+\dots +z_7{l}_7,z_i\in \{0,1\}$$

(5)

The dual-base method is adopted, where 8 bits represent $\{z_0,z_1,\dots ,z_7\}$, and the transmission sequence starts with $z_0$. The two bases are converted using the formulas in Equation (6) and (7), respectively:

$$[z_0,\dots ,z_7]=[u_7,\dots ,u_0]\left[\begin{array}{cccccccc}1& 0& 0& 0& 1& 1& 0& 1\\ 1& 1& 1& 0& 1& 1& 1& 1\\ 1& 1& 1& 0& 1& 1& 0& 0\\ 1& 0& 0& 0& 0& 1& 1& 0\\ 1& 1& 1& 1& 1& 0& 1& 0\\ 1& 0& 0& 1& 1& 0& 0& 1\\ 1& 0& 1& 0& 1& 1& 1& 1\\ 0& 1& 1& 1& 1& 0& 1& 1\end{array}\right]$$

(6)

$$[u_7,\dots ,u_0]=[z_0,\dots ,z_7]\left[\begin{array}{cccccccc}1& 1& 0& 0& 0& 1& 0& 1\\ 0& 1& 0& 0& 0& 0& 1& 0\\ 0& 0& 1& 0& 1& 1& 1& 0\\ 1& 1& 1& 1& 1& 1& 0& 1\\ 1& 1& 1& 1& 0& 0& 0& 0\\ 0& 1& 1& 1& 1& 0& 0& 1\\ 1& 0& 1& 0& 1& 1& 0& 0\\ 1& 1& 0& 0& 1& 1& 0& 0\end{array}\right]$$

(7)

To illustrate the conversion relationship between codes, for a given information symbol I,

$$\left[10111001\right]\left[\begin{array}{cccccccc}1& 1& 0& 0& 0& 1& 0& 1\\ 0& 1& 0& 0& 0& 0& 1& 0\\ 0& 0& 1& 0& 1& 1& 1& 0\\ 1& 1& 1& 1& 1& 1& 0& 1\\ 1& 1& 1& 1& 0& 0& 0& 0\\ 0& 1& 1& 1& 1& 0& 0& 1\\ 1& 0& 1& 0& 1& 1& 0& 0\\ 1& 1& 0& 0& 1& 1& 0& 0\end{array}\right]=[u_0,u_1,\dots ,u_7]=\left[00101010\right]=I^{\prime }$$

(8)

Given the check symbol $C^{\prime }$, and $[u_0,u_1,\dots ,u_7]=\left[01011001\right]$,

$$\left[01011001\right]\left[\begin{array}{cccccccc}1& 0& 0& 0& 1& 1& 0& 1\\ 1& 1& 1& 0& 1& 1& 1& 1\\ 1& 1& 1& 0& 1& 1& 0& 0\\ 1& 0& 0& 0& 0& 1& 1& 0\\ 1& 1& 1& 1& 1& 0& 1& 0\\ 1& 0& 0& 1& 1& 0& 0& 1\\ 1& 0& 1& 0& 1& 1& 1& 1\\ 0& 1& 1& 1& 1& 0& 1& 1\end{array}\right]=[z_0,z_1,\dots ,z_7]=\left[11101000\right]=C$$

(9)

For the proposed RS(255,223) encoding, the FEC overhead efficiency is defined as follows [23]:

$${\eta }_{FEC}={\displaystyle \frac{R_s}{R_c}}\left(1+\alpha ·{log}_2(1/BE{R}_{target})\right)$$

(10)

where $R_s$ is the source rate, $R_c$ is the code rate ($R_c=k/n$, k: information bits, n: coding bits), and $BE{R}_{target}$ is the target bit error rate (${10}^{-6}\sim {10}^{-15}$), and deep space communication requires $BE{R}_{target}\le {10}^{-12}$. $\alpha$ is the channel degradation factor, which characterizes the channel dynamics caused by Doppler frequency shift or atmospheric turbulence, etc., and is defined as $\alpha ={\displaystyle \frac{{\sigma }_{ch}^2}{{\sigma }_{AWGN}^2}}$.

2.2.3. IP over OISL-OSU

For OSU-carried packet traffic, the fundamental application requirement is MAC transparent transmission. The maximum bit rate of a packet only needs to consider the nominal Ethernet MAC bit rate, which is the maximum assured bandwidth that the packet can deliver. An OSU-carried packet is suitable for carrying Ethernet traffic without a defined bit rate. The bit rate of the packet fluctuates with traffic changes, ranging from 4 to C times the PB benchmark bit rate ($R_{PB}$). $C\times R_{PB}$ represents the maximum bit rate of the packet, where C refers to the maximum guaranteed bandwidth offered by the packet connection for Ethernet traffic. The maximum OSU bit rate ($R_{\mathrm{OSU}}$) and the maximum payload bit rate of the OSU ($R_{\mathrm{OSU}\_\mathrm{PLD}}$) for typical Ethernet services are listed in

Table 3. OSU bit rate and payload bit rate for typical Ethernet service rates.

Ethernet Service Rate	C Value	${\mathit{R}}_{\mathbf{OSU}-max}$ (Kbps)	${\mathit{R}}_{\mathbf{OSU}\_\mathbf{PLD}-max}$ (Kbps)
10 Mbps	4	10,400	10,020.833
100 Mbps	40	104,000	100,208.333
1 Gbps	400	1,040,000	1,002,083.333
10 Gbps	3996	10,381,800	10,003,296.875

$R_{\mathrm{OSU}}=C\times R_{\mathrm{PB}},R_{\mathrm{PB}}=2.6$ Mbps. $R_{\mathrm{OSU}\_\mathrm{PLD}}=C\times R_{\mathrm{PB}}\times {\displaystyle \frac{185}{192}},R_{\mathrm{PB}}=2.6$ Mbps.

[24].

2.2.4. Comparison of OISL-OSU and OISL-MPLS Technologies

Table 4. Pros and cons of OISL-OSU and OISL-MPLS.

Parameter	OISL-OSU	OISL-MPLS
Channel level	L1	L2
Channel isolation	Time slot isolation	Label isolation
Bandwidth guarantee	Hard-channel isolation	Statistical multiplexing and QoS priority
Bandwidth convergence	Not supported	Supported
Delay and jitter	Guaranteed	Not guaranteed
Channel monitoring and jitter	Path overhead and OAM	Path overhead

displays the comparative analysis of OISL-OSU and OISL-MPLS. Since OISL-OSU implements hard-channel isolation, a stringent resource isolation mechanism ensures the exclusive transmission of service flows via fixed resource reservation (PBs) within the OPU. Thus, OISL-OSU eliminates the need for services to compete for resources, thereby reducing transmission jitter.

3. Analysis and Discussion

3.1. Experiment Setup

The topology of the satellite optical network used for verification is illustrated in Figure 5. The network topology follows the Beidou System Constellation, consisting of inclined geosynchronous orbit (IGSO), medium earth orbit (MEO), and LEO satellites. For simulation convenience, a simplified network consisting of thirty-eight nodes—comprising the space segment, ground segment, and user segment—is selected [25]. Specifically, the space segment includes thirty-five satellites, i.e., three IGSOs, eleven MEOs, and twenty-one LEOs, while the ground segment and user segment consist of three ground gateway nodes and user terminals, respectively. At least two inter-satellite laser links connect neighboring satellite nodes within the same orbit and between cross-orbit satellite nodes (e.g., IGSO01 and MEO01, and MEO2 and LEO01). These inter-satellite laser links are bi-directional full-duplex links. Additionally, ground gateway stations connect to IGSO and LEO satellites via laser links (e.g., GroundStation01 to IGSO01, and GroundStation01 to LEO04), with each laser link providing a bandwidth of 10.709 Gbps. To simplify the experimental setup, SubMiniature version A (SMA) differential cables were substituted for the wireless laser terminal in the hardware-in-the-loop simulation to emulate the inter-satellite link.

To bridge the theoretical models described above with practical implementation, we further designed a hardware-in-the-loop simulation platform. In Figure 5, nodes spacecraft identifier (SCID) 1, SCID 2, and SCID 101 are selected from the IGSO and ground station nodes as real nodes for hardware-in-the-loop simulation, and the simulation network topology and experiment setup are shown in Figure 6a and Figure 6b, respectively. The device manufacturers and models are listed in

Table 5. Device manufacturers and models.

Device	Manufacturer	Model
Switch SCID	China Electronics Technology Group Corporation (CETC) Guilin, China	Design with XILINX 7V690T
Controller SCID	Loongson Technology Corporation Limited Beijing, China	Design with LOONGSON 1E300

. The hardware-in-the-loop simulation software environment and hardware setups are shown in

Table 6. Simulation software and hardware setups.

SCID Location		Software	Hardware
Data Plane	Virtual Node	INTEL WINDRIVER vxWorks 6.9	INTEL CORE I7
	Real Node	AMD VIVADO 2022.1	XILINX 7V690T
Control Plane	Virtual Node	INTEL WINDRIVER vxWorks 6.9	INTEL CORE I7
	Real Node	INTEL WINDRIVER vxWorks 6.9	LOONGSON 1E300
Management Plane		ORACLE JAVA jre1.8.0	INTEL CORE I7

. Given that the OISL-OSU interface’s line rate is approximately 10.709 Gbps, the FPGAs used for Switch SCIDs are XILINX 7V690T, which support a maximum serializer–deserializer (GTH) line rate of 12.0 Gbps.

3.2. The Performance of OISL-MPLS

To demonstrate OISL-MPLS switching, the IP capture tool Wireshark and the integrated logic analyzer (ILA) XILINX VIVADO (version 2022.1) are utilized to probe the IP data, in/out-labels, and in/out-ports of OISL-MPLS frames, as illustrated in Figure 7. Figure 7a depicts the IPv6 data transmitted from the source end and received at the destination end, as captured by Wireshark. Figure 7b illustrates the encapsulation of IPv6 data within the Transfer frame data field of the OISL-MPLS frame in SCID #101. This frame is pushed with an out-label (i.e., 0x00D2) and forwarding equivalence class corresponding to the destination IPv6 address FE80::0:0:30::, and it is sent out of port #3 (ingress LER) of node SCID #101 according to the forwarding information base (FIB). Upon receiving the OISL-MPLS frame with an in-label (i.e., 0x00D2), node SCID #1 immediately swaps the in-label (i.e., 0x00D2) to the out-label (i.e., 0xFFFF, since node SCID #1 is the penultimate node in the forward label switching path (LSP)) and forwards the swapped OISL-MPLS frame to port #1 based on the label forwarding information base (LFIB), as shown in Figure 7c. Finally, when node SCID #2 (egress LER) receives the OISL-MPLS frame with an in-label (i.e., 0xFFFF), it pops the in-label, de-encapsulates the IPv6 data from the Transfer frame data field, and delivers the IPv6 data to the terminal User #3, as depicted in Figure 7d. The process for the backward LSP follows a similar mechanism.

Table 7. The bi-directional LSP between node SCID #101, node SCID #1, and node SCID #2.

	SCID #101	SCID #1	SCID #2
Forward LSP	Out-port: 3 1	In-port: 3, Out-port: 1	In-port: 1
	Out-label: 0x00D2	In-label: 0x00D2, Out-label: 0xFFFF	In-label: 0xFFFF
Backward LSP	In-port: 3 1	Out-port: 3, In-port: 1	Out-port: 1
	In-label: 0xFFFF	Out-label: 0xFFFF, In-label: 0x0054	Out-label: 0x0054

¹ The out/in-ports of forward/backward LSP are the same, i.e., port 3.

summarizes the in/out-label and in/out-port configurations for the bi-directional OISL-MPLS frame-switching process.

3.3. The Performance of OISL-OSU

The mapping procedure for IP traffic over OISL-OSU is depicted in Figure 8, wherein IPv6 data (ICMPv6) are mapping into the payload of the ODU (as shown in Figure 8a). The ODU frame is then multiplexed to the OTU frame, with the OTU overhead (i.e., 0xF6F6F6282828), as illustrated in Figure 8b.

Moreover, the OISL-OTN-FEC frame encoding process is presented in Figure 9. Given that VIVADO RS encoder/decoder intellectual property cores only support an 8-bit data bit width, while the data bit width of the OISL-OTN-FEC frame is 64 bits, eight RS encoder/decoder intellectual property cores are simultaneously instantiated for processing the frame payload and frame checksum (as shown in Figure 9a and Figure 9b, respectively).

3.4. Performance Comparison Between OISL-OSU and OISL-MPLS

The performance of OISL-OSU and OISL-MPLS was evaluated based on the Internet Engineering Task Force (IETF) request for comments 2544 (RFC2544) standard under a packet loss rate of 0% [26]. The test results were measured by using an Ethernet tester (MTS 5800, VIAVI Solutions Inc., Chandler, AZ, USA) for throughput, loop delay, packet jitter, and back-to-back performance, as shown in Figure 10, Figure 11, Figure 12, and Figure 13, respectively.

The hierarchical evaluation framework in RFC2544 throughput testing exhibits distinct operational characteristics across Open Systems Interconnection (OSI) layers, as systematically demonstrated through controlled experimentation [27]. At Layer 1 (L1, i.e., the physical layer), raw bit rate quantification excludes protocol overhead through the computational model as follows:

$$L1=N_{frames}\times B_{frame},$$

(11)

where $N_{frames}$ denotes frames per second and $B_{frame}$ represents bits per frame. Electrical signal synchronization was rigorously maintained using precision clock recovery circuits (0.1 ppm stability) during measurement.

At layer 2 (L2, i.e., the data link layer), constituting the RFC2544 baseline implementation, frame forwarding efficiency is demonstrated as follows:

$$L2=N_{frames}\times (S_{frame}+20\mathrm{B}),$$

(12)

which incorporates inter-packet gap compensation as defined in Institute of Electrical and Electronics Engineers (IEEE) 802.3 specifications [28]. Our experimental configuration maintained 68B to 1522B VLAN frame sizes with $\pm 0.01\%$ measurement tolerance.

Layer 3 (L3, i.e., the network layer) evaluation necessitated IP stack parameter optimization, particularly maximum transmission unit (MTU) configuration, with throughput calculated as

$$L3=N_{packets}\times S_{MTU},$$

(13)

where $N_{packets}$ denotes packets per second and $S_{MTU}$ is empirically determined through path MTU discovery algorithms.

Layer 4 (L4, i.e., the transport layer) analysis implemented transmission control protocol (TCP) window scaling (RFC7323) and selective acknowledgment (RFC2018) mechanisms, measuring application-layer data unit transmission efficiency under varied congestion control regimes [29,30].

Firstly, Figure 10 demonstrates that OISL-OSU facilitates flexible bandwidth distribution, ranging from 2 Mbps to 1000 Mbps, and can dynamically adapt to operational demands. Both OISL-OSU and OISL-MPLS achieve high bandwidth utilization (with L1 rates ranging from 999.96 Mbps to 999.97 Mbps and 999.99 Mbps to 1000.00 Mbps, respectively). Notably, OISL-OSU outperforms OISL-MPLS in terms of bandwidth utilization when carrying small-packet services (frame lengths ranging from 68B to 132B). The throughput of OISL-MPLS depends on the network’s bandwidth configuration and traffic management strategy, constrained by packet switching efficiency and network congestion.

On the other hand, Figure 11 illustrates the loop delay performance. OISL-OSU adopts a flexible time-slot multiplexing mechanism, which eliminates the necessity for fixed data caching at intermediate nodes, thereby substantially reducing single-node delay. By optimizing the encapsulation layer, OISL-OSU significantly decreases both encapsulation and cross-processing latencies. Compared with OISL-MPLS, OISL-OSU reduces single-node delay by 44.72%, 46.26%, 48.78%, 52.11%, 56.29%, and 58.58% for frame lengths ranging from 68B to 1522B, respectively. These results demonstrate that OISL-OSU is well-suited for time-sensitive business scenarios.

Furthermore, Figure 12 shows the packet jitter performance. OISL-OSU provides a hard channel with predictable delays, effectively reducing packet jitter and making it suitable for delay-sensitive services. Packet jitter in OISL-MPLS is influenced by network congestion and traffic scheduling. As depicted in Figure 12, compared with OISL-MPLS, OISL-OSU reduces jitter by 75.00%, 66.67%, 66.67%, 66.67%, 66.67%, and 0% for frame lengths ranging from 68B to 1522B, respectively.

Finally, Figure 13 displays the back-to-back performance. Compared with OISL-MPLS, OISL-OSU reduces average burst frames by 80.91%, 80.53%, 80.29%, 80.15%, 80.08%, and 80.05% for frame lengths ranging from 68B to 1522B, respectively. The experimental data indicate that OISL-OSU outperforms OISL-MPLS in terms of bandwidth utilization, delay, jitter, and reliability.

3.5. Performance Evaluation

Following the analysis of delay performance, we have conducted a quantitative evaluation of the delay optimization mechanism of OISL-OSU compared with OISL-MPLS from three perspectives: network architecture, protocol processing, and switching mode.

1.

Network architecture

Table 8. Network architecture delay comparison.

Delay Source	OISL-OSU	OISL-MPLS
Encapsulation/decapsulation	Fixed-length	IP packet parsing
Label lookup	Optical layer wavelength selection	Electrical layer forwarding table lookup
Optical (O)/electrical (E) conversion	Optical switching	O/E/O conversion
Queue Buffering	Reserved bandwidth in hard channel eliminates contention delay	Bandwidth contention delay

presents a comparative overview of the network architectures of OISL-OSU and OISL-MPLS.

2.

Protocol processing

The OISL-MPLS protocol stack processing delay comprises IP/Label header processing ($t_{HdrProc}$), forwarding table lookup ($t_{FIB}$), and QoS shaping ($t_{QoS}^{shaper}$), which is

$${\mathcal{T}}_{OISL-MPLS}=t_{HdrProc}+t_{FIB}+t_{QoS}^{shaper}$$

(14)

Meanwhile the OISL-OSU protocol processing delay is burst scheduling ($t_{BurstSch}$):

$${\mathcal{T}}_{OISL-OSU}=t_{BurstSch}$$

(15)

3.

Switching mode

Store-and-forward processing ($t_{store}$ and $t_{forward}$) contributes to the delay in OISL-MPLS packet switching, which is

$${\mathcal{T}}_{OISL-MPLS}^{\prime }=\sum _{i=1}^n(t_{store}^{\left(i\right)}+t_{forward}^{\left(i\right)})$$

(16)

In contrast, OISL-OSU ensures deterministic delay through pre-configured optical paths ($t_{config}$) and implements cacheless forwarding based on burst header packets ($t_{BHP}$) as follows:

$${\mathcal{T}}_{OISL-OSU}^{\prime }=t_{config}+t_{BHP}$$

(17)

4. Conclusions

The proposed OISL-OSU method provides an effective solution to the bottleneck of carrying small-granularity, high-quality dedicated line services in current satellite optical networks. The comparison test results demonstrates that OISL-OSU outperforms OISL-MPLS in terms of bandwidth utilization, delay, jitter, and burst processing capabilities. The hard-channel, deterministic delay, and high reliability characteristics of OISL-OSU align with the stringent requirements of 6G networks for space–terrene–sea integration and industrial Internet. OISL-OSU can be applied in specialized scenarios such as high-frequency financial trading (microsecond-level delay-sensitive), industrial automation (with deterministic delay requirements), and ultra-high-definition video transmission (ensuring smoothness with low jitter), and is expected to become one of the core transmission technologies in 6G networks.