Communication method and satellite communication base station system
By detecting and inserting private frame headers in the switching unit of the satellite communication base station system, and using the processor's unique identifier for hardware-level pass-through forwarding, the contradiction between standard Ethernet compatibility and high-performance service requirements in satellite communication base stations is resolved, achieving low-latency and high-stability forwarding.
Patent Information
- Application Number
- CN202611570357.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-10-12
- Publication Date
- 2026-11-06
AI Technical Summary
Existing technologies present a contradiction between standard Ethernet compatibility and the high-performance service requirements on satellite communication base stations, and lack a method to provide hardware-level deterministic forwarding while maintaining compatibility with standard Ethernet in an environment with multiple processor architectures.
By detecting whether the data packet contains a private frame magic number in the switching unit of the satellite communication base station system, if no private frame header is detected, the processor's unique identifier is obtained by querying the address mapping table, and hardware-level pass-through forwarding is performed using the internal forwarding table. The private frame header can be stripped or maintained to adapt to different network scenarios.
It reduces the consumption of logical resources in the switching unit and the forwarding latency in resource-constrained environments, improves system stability and determinism, and adapts to the forwarding needs of various business scenarios.
Smart Images

Figure CN123055653A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of satellite communication technology, and more specifically, to a communication method and a satellite communication base station system. Background Technology
[0002] In 5th Generation (5G) Non-Terrestrial Network (NTN) satellite communication systems, satellite base stations (especially onboard or high-altitude platform base stations) need to simultaneously meet the requirements of high reliability of control signaling, high throughput of user plane, and high real-time performance of data such as beam control / in-phase / quadrature (IQ) sampling under extremely limited power consumption, size, and computing resources. They also need to be compatible with multiple network topologies to support various service needs.
[0003] To adapt to different mission scenarios, satellite base station hardware architectures have mainly evolved into two mainstream forms: heterogeneous processor discrete board architecture and multi-board parallel integrated architecture. These two architectures differ significantly in processor type, interconnect topology, and scheduling mechanism, leading to severe frame format differences in inter-board communication.
[0004] Meanwhile, satellite base stations often face complex scenarios such as multi-user plane function (UPF) interfacing and multiple boards sharing Internet Protocol (IP). Traditional solutions typically employ hop-by-hop IP routing or Medium Access Control (MAC) address learning, which incurs redundant table lookup overhead in multi-level switching topologies. Furthermore, dynamic MAC drift can easily lead to short-term service interruptions on the satellite, and the forwarding logic of some services does not conform to the forwarding behavior of standard data communication equipment, requiring comprehensive judgment based on tunnel protocol fields. Satellite base stations must simultaneously meet the stringent requirements of NTN systems for high stability, deterministic latency, and forwarding flexibility.
[0005] Therefore, existing technologies present a technical contradiction between standard Ethernet compatibility and the high-performance service requirements of satellites, and lack a unified frame format processing method that can simultaneously shield physical link differences, be compatible with standard Ethernet, and provide hardware-level deterministic forwarding in an environment where multiple architecture processors coexist. Summary of the Invention
[0006] The purpose of this application is to provide a communication method and a satellite communication base station system to solve the technical problem of the technical contradiction between standard Ethernet compatibility and the high-performance service requirements of satellites in the prior art.
[0007] In a first aspect, embodiments of this application provide a communication method applied to a switching unit in a satellite communication base station system. The satellite communication base station system includes various types of processors. The method includes: upon receiving a data packet, detecting whether the data packet includes a private frame magic number; if no private frame magic number is detected, querying an address mapping table based on the forwarding association information of the data packet to obtain the processor unique identifier of the target forwarding object, and inserting a private frame header into the data packet, wherein the address mapping table includes the correspondence between forwarding association information and processor unique identifiers, and the private frame header includes the private frame magic number and the processor unique identifier; querying an internal forwarding table based on the processor unique identifier in the private frame header to determine a forwarding exit, and forwarding the data packet through the forwarding exit, wherein the internal forwarding table includes the correspondence between processor unique identifiers and forwarding exits.
[0008] In the above scheme, the switching unit distinguishes between standard Ethernet frames and encapsulated frames by detecting the private frame magic number at the packet ingress. Only when the magic number is not detected is the address mapping table consulted to obtain the processor's unique identifier for the target forwarding object, and a private frame header containing that processor's unique identifier is inserted. This allows each switching unit to determine the forwarding exit by simply reading the processor's unique identifier in the private frame header and consulting the internal forwarding table, without needing to perform MAC address matching or IP route lookups. This achieves hardware-level pass-through forwarding with a single resolution. Furthermore, since forwarding association information is used as the basis for querying the address mapping table, forwarding decisions can be made without deep parsing of the packet content, significantly reducing the logical resource consumption and forwarding latency of the switching unit, making it particularly suitable for resource-constrained onboard environments.
[0009] In an optional implementation, before detecting whether the data packet includes a private frame magic number upon receiving the data packet, the method further includes: obtaining the processor unique identifier of each processor, and generating or receiving an internal forwarding table based on the processor unique identifier.
[0010] In the above scheme, by obtaining the unique processor identifier of each processor before detecting data packets and generating or receiving an internal forwarding table based on this unique processor identifier, the switching unit can complete the pre-configuration of the forwarding path before the data packets arrive. The generation method covers scenarios where the switching unit dynamically builds the forwarding table through listening and learning, while the receiving method covers scenarios where the main control board or integrated board statically distributes the forwarding table. Both methods ensure that the switching unit has a complete mapping between the unique processor identifier and the forwarding exit when forwarding data packets, providing a foundation for subsequent hardware-level pass-through forwarding.
[0011] In an optional implementation, obtaining the processor's unique identifier for each processor includes: obtaining the processor's unique identifier by listening to the messages sent by the processor, or receiving the processor's unique identifier generated by the main control board or the integrated board.
[0012] In the above scheme, the unique identifier of the processor is obtained by listening to the messages sent by the processor. This allows the switching unit to automatically discover each processor and establish a forwarding table after the board starts up through mutual notification and learning within the system, without manual configuration and supporting plug-and-play functionality. Simultaneously, by receiving the unique identifier of the processor generated by the main control board or integrated board, the system can uniformly allocate identifiers and statically distribute configurations based on the board's deployment location, avoiding service interruptions caused by MAC drift that may occur during dynamic learning. The parallel existence of these two acquisition methods allows this invention to be compatible with both hardware-fixed identifier scenarios and system-unified addressing scenarios.
[0013] In an optional implementation, the processor unique identifier is generated by the main control board or integrated board based on the deployment location of the processor on the board, and the processor unique identifier corresponds one-to-one with the deployment location.
[0014] In the above solution, the main control board or integrated board generates a unique processor identifier that corresponds one-to-one with the deployment location of the processor on the board. This ensures that the processor identifier is strictly bound to the physical slot, eliminating the need for hardware-fixed MAC addresses or factory IDs. During system initialization, all processor identifiers are generated by default and statically distributed to all switching units, eliminating the need for mutual notification and learning processes after board startup. This removes the risk of short-term service interruptions on the satellite caused by dynamic MAC address drift, improving system stability and determinism.
[0015] In optional implementations, the forwarding association information includes at least one of the following: destination IP address, destination MAC address, tunneling protocol field, and Virtual Local Area Network (VLAN) identifier.
[0016] In the above scheme, by setting the forwarding association information to at least one of the following: destination IP address, destination MAC address, tunnel protocol field, and VLAN identifier, the switching unit can adapt to the forwarding requirements of various service scenarios. For multi-UPF interconnection scenarios, mapping can be completed through the destination IP address; for scenarios where multiple baseband boards share the same UPF, the tunnel protocol field can be used for judgment; for scenarios involving VLAN isolation, the VLAN identifier can be used for mapping. This setting allows the present invention to flexibly adapt to complex forwarding logic under different network configurations without the need to develop separate forwarding schemes for each scenario.
[0017] In an optional implementation, after detecting whether the data packet includes a private frame magic number, the method further includes: if a private frame magic number is detected, querying the internal forwarding table based on the processor unique identifier in the private frame header to determine the forwarding exit, and forwarding the data packet through the forwarding exit.
[0018] In the above scheme, when a data packet is detected to contain a private frame magic number, the internal forwarding table is directly queried based on the processor's unique identifier in the private frame header for forwarding. This eliminates the need for repeated address mapping table lookups when data packets with encapsulated private headers are transmitted between different levels of switching units. This mechanism allows each level of switching unit in a multi-level cascaded scenario to directly reuse the encapsulated private frame header at the ingress point, eliminating the overhead of repeated table lookups at each level of switching node and further reducing the cumulative forwarding latency in multi-level switching topologies.
[0019] In an optional implementation, before forwarding the data packet through the forwarding exit, the method further includes: if the forwarding exit corresponds to a processor or an external exit, then stripping the private frame header from the data packet.
[0020] In the above scheme, by stripping the proprietary frame header from the data packet at the forwarding egress corresponding to the processor or external egress, the data packet is restored to the standard Ethernet frame format when it leaves the switching network and arrives at the processor or external network. The processor receives a standard Ethernet frame and does not need to be aware of the existence of the internal proprietary frame header. External network devices also do not need to support proprietary protocols to receive data packets normally, thus achieving seamless integration between the forwarding of internal proprietary frame formats and external standard Ethernet protocols.
[0021] In an optional implementation, before forwarding the data packet through the forwarding exit, the method further includes: if the forwarding exit corresponds to the next-level switching unit, then maintaining the private frame header in the data packet.
[0022] In the above scheme, by maintaining the private frame header in the data packet when forwarding to the next-level switching unit, the data packet with the encapsulated private header can be reused by each level of switching unit for forwarding decisions when transmitted between multi-level cascaded switching units. This eliminates the need to re-execute the address mapping table lookup operation at each switching node. This mechanism works in conjunction with the aforementioned stripping mechanism to dynamically decide whether to strip the private header based on the exit type, achieving full reuse of the private frame header within the switching network and automatic stripping at the exit.
[0023] Secondly, embodiments of this application provide a communication device applied to a switching unit in a satellite communication base station system. The satellite communication base station system includes various types of processors. The device includes: a detection module, used to detect whether a received data packet contains a private frame magic number; a query module, used to query an address mapping table based on the forwarding association information of the data packet to obtain the processor unique identifier of the target forwarding object if no private frame magic number is detected, and insert a private frame header into the data packet, wherein the address mapping table includes the correspondence between forwarding association information and processor unique identifiers, and the private frame header includes the private frame magic number and the processor unique identifier; and a determination module, used to query an internal forwarding table based on the processor unique identifier in the private frame header to determine the forwarding exit, and forward the data packet through the forwarding exit, wherein the internal forwarding table includes the correspondence between processor unique identifiers and forwarding exits.
[0024] In the above scheme, the switching unit distinguishes between standard Ethernet frames and encapsulated frames by detecting the private frame magic number at the packet ingress. Only when the magic number is not detected is the address mapping table consulted to obtain the processor's unique identifier for the target forwarding object, and a private frame header containing that processor's unique identifier is inserted. This allows each switching unit to determine the forwarding exit by simply reading the processor's unique identifier in the private frame header and consulting the internal forwarding table, without needing to perform MAC address matching or IP route lookups. This achieves hardware-level pass-through forwarding with a single resolution. Furthermore, since forwarding association information is used as the basis for querying the address mapping table, forwarding decisions can be made without deep parsing of the packet content, significantly reducing the logical resource consumption and forwarding latency of the switching unit, making it particularly suitable for resource-constrained onboard environments.
[0025] In an optional implementation, before detecting whether the data packet includes a private frame magic number upon receiving the data packet, the apparatus further includes: an acquisition module, configured to acquire the processor unique identifier of each processor, and generate or receive an internal forwarding table based on the processor unique identifier.
[0026] In the above scheme, by obtaining the unique processor identifier of each processor before detecting data packets and generating or receiving an internal forwarding table based on this unique processor identifier, the switching unit can complete the pre-configuration of the forwarding path before the data packets arrive. The generation method covers scenarios where the switching unit dynamically builds the forwarding table through listening and learning, while the receiving method covers scenarios where the main control board or integrated board statically distributes the forwarding table. Both methods ensure that the switching unit has a complete mapping between the unique processor identifier and the forwarding exit when forwarding data packets, providing a foundation for subsequent hardware-level pass-through forwarding.
[0027] In an optional implementation, the acquisition module is further configured to: obtain the processor's unique identifier by listening to the messages sent by the processor, or receive the processor's unique identifier generated by the main control board or the integrated board.
[0028] In the above scheme, the unique identifier of the processor is obtained by listening to the messages sent by the processor. This allows the switching unit to automatically discover each processor and establish a forwarding table after the board starts up through mutual notification and learning within the system, without manual configuration and supporting plug-and-play functionality. Simultaneously, by receiving the unique identifier of the processor generated by the main control board or integrated board, the system can uniformly allocate identifiers and statically distribute configurations based on the board's deployment location, avoiding service interruptions caused by MAC drift that may occur during dynamic learning. The parallel existence of these two acquisition methods allows this invention to be compatible with both hardware-fixed identifier scenarios and system-unified addressing scenarios.
[0029] In an optional implementation, the processor unique identifier is generated by the main control board or integrated board based on the deployment location of the processor on the board, and the processor unique identifier corresponds one-to-one with the deployment location.
[0030] In the above solution, the main control board or integrated board generates a unique processor identifier that corresponds one-to-one with the deployment location of the processor on the board. This ensures that the processor identifier is strictly bound to the physical slot, eliminating the need for hardware-fixed MAC addresses or factory IDs. During system initialization, all processor identifiers are generated by default and statically distributed to all switching units, eliminating the need for mutual notification and learning processes after board startup. This removes the risk of short-term service interruptions on the satellite caused by dynamic MAC address drift, improving system stability and determinism.
[0031] In optional implementations, the forwarding association information includes at least one of the following: destination IP address, destination MAC address, tunneling protocol field, and Virtual Local Area Network (VLAN) identifier.
[0032] In the above scheme, by setting the forwarding association information to at least one of the following: destination IP address, destination MAC address, tunnel protocol field, and VLAN identifier, the switching unit can adapt to the forwarding requirements of various service scenarios. For multi-UPF interconnection scenarios, mapping can be completed through the destination IP address; for scenarios where multiple baseband boards share the same UPF, the tunnel protocol field can be used for judgment; for scenarios involving VLAN isolation, the VLAN identifier can be used for mapping. This setting allows the present invention to flexibly adapt to complex forwarding logic under different network configurations without the need to develop separate forwarding schemes for each scenario.
[0033] In an optional implementation, the determining module is further configured to: if a private frame magic number is detected, query the internal forwarding table based on the processor unique identifier in the private frame header to determine the forwarding exit, and forward the data packet through the forwarding exit.
[0034] In the above scheme, when a data packet is detected to contain a private frame magic number, the internal forwarding table is directly queried based on the processor's unique identifier in the private frame header for forwarding. This eliminates the need for repeated address mapping table lookups when data packets with encapsulated private headers are transmitted between different levels of switching units. This mechanism allows each level of switching unit in a multi-level cascaded scenario to directly reuse the encapsulated private frame header at the ingress point, eliminating the overhead of repeated table lookups at each level of switching node and further reducing the cumulative forwarding latency in multi-level switching topologies.
[0035] In an optional implementation, the apparatus further includes a stripping module for stripping private frame headers from data packets if the forwarding egress corresponds to a processor or an external egress.
[0036] In the above scheme, by stripping the proprietary frame header from the data packet at the forwarding egress corresponding to the processor or external egress, the data packet is restored to the standard Ethernet frame format when it leaves the switching network and arrives at the processor or external network. The processor receives a standard Ethernet frame and does not need to be aware of the existence of the internal proprietary frame header. External network devices also do not need to support proprietary protocols to receive data packets normally, thus achieving seamless integration between the forwarding of internal proprietary frame formats and external standard Ethernet protocols.
[0037] In an optional implementation, the apparatus further includes a maintenance module, configured to maintain the private frame header in the data packet if the forwarding exit corresponds to the next-level switching unit.
[0038] In the above scheme, by maintaining the private frame header in the data packet when forwarding to the next-level switching unit, the data packet with the encapsulated private header can be reused by each level of switching unit for forwarding decisions when transmitted between multi-level cascaded switching units. This eliminates the need to re-execute the address mapping table lookup operation at each switching node. This mechanism works in conjunction with the aforementioned stripping mechanism to dynamically decide whether to strip the private header based on the exit type, achieving full reuse of the private frame header within the switching network and automatic stripping at the exit.
[0039] Thirdly, embodiments of this application provide a satellite communication base station system, including: at least one switching unit, and one or more boards connected to the switching unit, the boards carrying one or more processors, the processors including various types; the switching unit is used to perform the method as described in the first aspect.
[0040] Fourthly, embodiments of this application provide a computer program product, including computer program instructions, which are read and executed by a processor to perform the method described in the first aspect.
[0041] Fifthly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus; the processor and the memory communicate with each other via the bus; the memory stores computer program instructions executable by the processor, and the processor can execute the method described in the first aspect by calling the computer program instructions.
[0042] In a sixth aspect, embodiments of this application provide a computer-readable storage medium that stores computer program instructions, which, when executed by a computer, cause the computer to perform the method described in the first aspect.
[0043] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, embodiments of this application are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0044] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0045] Figure 1 A schematic diagram of a heterogeneous discrete architecture provided for an embodiment of this application; Figure 2 A schematic diagram of a homogeneous integration architecture provided for an embodiment of this application; Figure 3 A flowchart illustrating a communication method provided in this application embodiment; Figure 4 This application provides an internal route generation and forwarding flowchart for an embodiment of the present application. Figure 5 This application provides a structural block diagram of a communication device according to an embodiment; Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0046] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.
[0047] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0048] The mainstream inter-board communication solutions currently available fall into the following three categories: (1) The proprietary FPGA Application Protocol (FAP) protocol mode based on Peripheral Component Interconnect Express (PCIe) / Serial RapidIO (SRIO): By carrying custom FAP frames on the PCIe / SRIO link, scheduling parameters and service data are encapsulated using Type-Length-Value (TLV) headers. Although high bandwidth and low latency can be achieved, its frame format, Direct Memory Access (DMA) interaction mechanism are strongly bound to specific hardware and cannot be reused across platforms.
[0049] (2) Private L2 / L1 interface mode based on backplane serializer / deserializer (SerDes) / Ethernet / SRIO: Traditional macro base station base band processing units (BBUs) often adopt this solution, transmitting vendor-defined L2-L1 interface frames through backplane switching chips. Although this solution is optimized for baseband services, the protocol details are completely closed, making it impossible for equipment from different vendors to interoperate, and it is difficult to adapt to the newly defined on-board processing and routing requirements in NTN scenarios.
[0050] (3) Standard Ethernet mode based on commercial Ethernet chips: It adopts the IEEE 802.3 standard Ethernet frame and can be superimposed with sub-protocols such as enhanced Common Public Radio Interface (eCPRI) and Radio over Ethernet (ROE). The hardware ecosystem of this solution is mature, but there is an essential contradiction: the standard protocol is difficult to carry satellite-specific private control signaling and high-precision sampling data without loss, and it is difficult to support some complex scenarios that require judgment in combination with tunnel protocol fields. It is still necessary to break the standard and make some customized modifications.
[0051] However, existing technologies present a technical contradiction between standard Ethernet compatibility and the high-performance service requirements of satellites, and lack a unified frame format processing method that can simultaneously shield physical link differences, be compatible with standard Ethernet, and provide hardware-level deterministic forwarding in an environment where multiple architecture processors coexist.
[0052] In view of this, embodiments of this application provide a communication method and a satellite communication base station system. This method is applied to a switching unit in a satellite communication base station system including multiple types of processors. The switching unit obtains the unique identifier of each processor and generates or receives an internal forwarding table accordingly. When a data packet is received, it checks whether it contains a private frame magic number. If not detected, it queries the address mapping table based on forwarding association information to obtain the unique identifier of the target forwarding object's processor, inserts a private frame header containing the processor's unique identifier into the data packet, and then queries the internal forwarding table based on the processor's unique identifier in the private frame header to determine the forwarding exit and performs forwarding. If a private frame magic number is detected, it directly queries the internal forwarding table for forwarding. If the forwarding exit corresponds to a processor or an external exit, the private frame header is stripped to restore a standard Ethernet frame. If it corresponds to the next-level switching unit, the private frame header is maintained for reuse.
[0053] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.
[0054] A satellite communication base station system refers to communication base station equipment deployed on a satellite platform (including onboard or high-altitude platforms) to provide wireless communication services in 5G NTN and integrated space-ground networks. This satellite communication base station system can simultaneously meet the requirements of high reliability for control signaling, high throughput for the user plane, and high real-time performance for beam control / IQ sampling data under extremely limited power consumption, size, and computing resources.
[0055] The aforementioned satellite communication base station system includes at least one switching unit and one or more boards connected to the switching unit. The boards are equipped with one or more processors, which include various types.
[0056] The switching unit is the core forwarding device in this embodiment of the application. It is used to connect various boards in the satellite base station system, is responsible for frame format conversion, routing and scheduling of data packets, and is used to connect internal and external networks. For example, the switching unit can be implemented by a Field Programmable Gate Array (FPGA) or by a programmable intelligent switching chip.
[0057] In one optional implementation, the switching unit includes two forms: a central switching module and an on-board switching module. The central switching module connects various boards (main control board, baseband board, integrated board, etc.) and is responsible for data exchange between boards and communication with external networks; for example, the central switching module can be deployed independently as a daughter card or integrated into the main control board. The on-board switching module is located inside a board containing multiple processors (i.e., the on-board switching module) and is used for interconnection and communication between multiple processors within the same board; when there are multiple processors on a single board, they need to be connected through the on-board switching unit.
[0058] It should be noted that the core functions of the central switching module and the on-board switching module are the same, and both support the forwarding logic described in the embodiments of this application, such as private frame magic number detection, private frame header insertion and stripping, address mapping table lookup and internal forwarding table lookup.
[0059] A board is a pluggable hardware module in a satellite base station system, connected to the switching unit. The board carries one or more processors, and these processors come in various types. As an alternative implementation, depending on the system architecture, boards can be categorized as follows: main control board, baseband board, and integrated board.
[0060] The main control board typically carries a general-purpose central processing unit (CPU) to handle control and management plane operations. The baseband board typically carries a system-on-chip (SoC) or FPGA processor to handle physical layer and user plane protocol processing; a single board can contain multiple processors, interconnected within the board via on-board switching modules. In a homogeneous integrated architecture, a single integrated board integrates system control, protocol processing, and data transmission functions, carrying multiple processors; multiple integrated boards operate in parallel, interconnected within the board via on-board switching modules.
[0061] A processor is a chip on a board that performs computational and control tasks. For example, processors include one or more of the following types: CPU, Digital Signal Processor (DSP), System-on-a-Chip (SoC), and FPGA. In a heterogeneous discrete architecture, the main control board carries a general-purpose CPU, while the baseband board carries an SoC or FPGA processor; in a homogeneous integrated architecture, various types of processors are carried on different integrated boards.
[0062] Furthermore, this application supports three system architectures: heterogeneous discrete architecture, homogeneous integrated architecture, and hybrid architecture. The following sections describe these three system architectures respectively: Please refer to Figure 1 , Figure 1 This is a schematic diagram of a heterogeneous discrete architecture provided in an embodiment of this application. The heterogeneous discrete architecture mainly includes the following components: a main control board, a baseband board, and a central switching module. The baseband board includes an on-board switching module and a processor. Figure 2 The dashed line represents external data, and the solid line represents internal data.
[0063] Please refer to Figure 2 , Figure 2 This is a schematic diagram of a homogeneous integrated architecture provided in an embodiment of this application. The homogeneous integrated architecture mainly includes the following components: an integrated board and a central switching module. The integrated board includes an on-board switching module and a processor. Wherein, Figure 2 The dashed line represents external data, and the solid line represents internal data.
[0064] The switching unit supports the coexistence of heterogeneous main control boards, baseband boards, and homogeneous integrated boards on the same network. Seamless cross-architecture communication is achieved through a unified CPU identifier address space and frame format specification. The internal routing mechanism under this architecture is completely consistent with the internal routing mechanisms under heterogeneous or homogeneous architectures.
[0065] Furthermore, the aforementioned satellite communication base station system can be applied to Long Term Evolution (LTE) systems or NR systems (also known as 5G systems), LTE and NR hybrid networking systems, Vehicle-to-Everything (V2X) systems, Device-to-Device (D2D) systems, Machine-to-Machine (M2M) communication systems, Internet of Things (IoT) systems (such as Narrowband Internet of Things (NB-IoT) systems), 6G systems, and other systems evolving after 5G, as well as other next-generation communication systems. Alternatively, the communication system can also be an Open Radio Access Network (O-RAN or ORAN), a Cloud Radio Access Network (CRAN), or a Wireless Fidelity (Wi-Fi) system, without limitation.
[0066] Furthermore, the "protocol" involved in the embodiments of this application can refer to standard protocols in the field of communications, such as the LTE protocol, the New Radio (NR) protocol, and related protocols applied in future communication systems (such as 6G communication systems). The embodiments of this application do not limit this. The communication architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will understand that with the evolution of communication architectures and the emergence of new business scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0067] Please refer to Figure 3 , Figure 3 This application provides a flowchart of a communication method according to an embodiment of the present application. The method is applied to a switching unit in a satellite communication base station system and may specifically include the following steps: S301: Upon receiving a data packet, detect whether the data packet includes a private frame magic number.
[0068] The private frame magic number is the first field in the private frame header, used by hardware to quickly distinguish private frames from standard Ethernet frames. In one specific implementation, the private frame magic number is fixed at 0x55AA55AA (2 bytes). The switching unit determines whether the current data packet has been encapsulated with a private frame header by detecting this magic number at the data stream ingress.
[0069] In one specific implementation, the switching unit continuously monitors the data stream at the packet ingress point. When the data stream arrives, the switching unit detects the first few bytes of the data packet after the Start of Frame Delimiter (SFD). The switching unit compares the start bytes of the data packet with a preset private frame magic number (such as 0x55AA55AA) using hardware logic.
[0070] If the start byte matches the private frame magic number, the data packet is determined to contain a private frame header and is an encapsulated internal data packet. If the start byte does not match the private frame magic number, the data packet is determined to be a standard Ethernet frame and has not yet been encapsulated with a private frame header.
[0071] S302: If no private frame magic number is detected, query the address mapping table according to the forwarding association information of the data packet to obtain the processor unique identifier of the target forwarding object, and insert a private frame header into the data packet.
[0072] Forwarding association information is the data packet field information that the switching unit uses when querying the address mapping table. For example, forwarding association information may include at least one of the following: destination IP address, destination MAC address, tunnel protocol field (such as GTP-U Tunnel Endpoint Identifier (TEID), VLAN identifier). The tunnel protocol field is used to distinguish different tunnel endpoints in scenarios where multiple baseband boards share the same UPF.
[0073] An address mapping table is a mapping table used by a switching unit at the entry point of a data packet, including the correspondence between forwarding association information and the processor's unique identifier. In one specific implementation, the address mapping table can be an IP-CPU identifier mapping table, a MAC-CPU identifier mapping table, a specified tunnel field-CPU identifier mapping table, a VLAN-CPU identifier mapping table, or a combination or variation of the above mapping tables.
[0074] When the address mapping table is an IP-CPU identifier mapping table, its contents are as follows: 20.0.0.1→CPUID_20, 10.0.0.1→CPUID_21, which means that the data packet with the destination IP of 20.0.0.1 corresponds to the processor's unique identifier CPUID_20, and the data packet with the destination IP of 10.0.0.1 corresponds to the processor's unique identifier CPUID_21.
[0075] For example, the address mapping table can serve as a service forwarding table. Based on the configuration issued by the main control board, the switching unit generates key forwarding tables, including but not limited to routing tables and IP-CPU identifier mapping tables. The switching unit prioritizes routing based on the processor's unique identifier, achieving a one-time resolution and direct connection. For packets involving external network communication, the IP / Ethernet frame to processor's unique identifier mapping is completed at the entry point before being included in the internal routing, and then restored to a standard Ethernet frame at the exit point, achieving seamless integration between the internal CPU processor's unique identifier routing and the external standard Ethernet protocol.
[0076] Service configuration refers to the necessary network configuration for interfacing with external network elements (such as UPF, Access and Mobility Management Function (AMF), Operations and Maintenance Center (OMC)). Service configuration is usually read from configuration files, but can also be modified online through command line interface (CLI), network management, etc., and finally distributed to the switching unit.
[0077] The target forwarding object is the forwarding target of data packets within the satellite communication base station system. It can be a specific processor (in the downlink scenario, data packets are sent from the outside to the baseband board processor), an egress logical node (in the uplink scenario, data packets are sent from the baseband board to the external UPF), or the next-level switching unit (in the multi-level cascading scenario).
[0078] A processor unique identifier is an identifier used within the system to uniquely identify each processor. This application does not limit the processor unique identifier; it can be a hardware-fixed unique ID (such as a CPU pin number), a MAC address, a processor unique identifier uniformly generated at the system level (such as an ID, address, etc.), or a unique identification code generated using algorithms such as Hash and SHA1 based on ID and MAC.
[0079] For example, the processor's unique identifier can be uniformly generated based on the board slot (SLOT). This identifier corresponds strictly one-to-one with the SLOT and is determined by the board's deployment location. In other words, the processor's unique identifier is generated by the main control board or integrated board based on the deployment location of the board where the processor is located, and the processor's unique identifier corresponds one-to-one with the deployment location.
[0080] A proprietary frame header is a custom header inserted by the switching unit before the standard Ethernet frame to carry internal information required for forwarding. This application does not limit the format of the proprietary frame header, but it must include the proprietary frame magic number and the processor's unique identifier as necessary fields. The meaning, position, and length of the fields in the proprietary frame header can have various variations. For example, the format of the proprietary frame header is shown in Table 1:
[0081] Table 1. Example of proprietary frame format design In step S302 above, the switching unit parses the header of the standard Ethernet frame, extracts forwarding association information, and then queries a preset address mapping table based on the extracted forwarding association information. For example, in a multi-UPF interconnection scenario, the switching unit extracts the destination IP address of the data packet and queries the IP-CPU identifier mapping table. In a scenario where multiple baseband boards share the same UPF, since multiple baseband boards are connected to the same UPF and use the same destination IP address, the switching unit needs to further parse the GTP-U tunnel protocol header, extract the TEID field, and query the TEID-CPU identifier mapping table.
[0082] By querying the address mapping table, the switching unit obtains the unique processor identifier (CPU ID) of the target forwarding object. This unique processor identifier can represent the target processor (downlink scenario), the egress logical node (uplink scenario), or the next-level switching unit (multi-level cascading scenario).
[0083] The switching unit inserts a private frame header before the start of frame (SFF) of a standard Ethernet frame. The specific insertion method is as follows: when acquiring the data stream, if the start byte after detecting the SFF does not match the private frame magic number, a private frame header is inserted beforehand. The start byte is filled with the private frame magic number (e.g., 0x55AA55AA), and the CPUID field of the private frame header is filled with the unique identifier of the processor obtained from the query. Other fields such as total message length, service type, priority, and CRC16 are also filled in. Then, data stream reception is resumed.
[0084] S303: Determine the forwarding exit by querying the internal forwarding table based on the processor's unique identifier in the private frame header, and forward the data packet through the forwarding exit.
[0085] The internal forwarding table is a mapping table used by switching units during packet forwarding. It includes the correspondence between processor unique identifiers and forwarding exits, i.e., the CPU identifier-PORT mapping table. Switching units at all levels use this table to directly map the processor unique identifier in the private frame header to the physical forwarding exit, without needing to perform MAC address matching or IP routing lookups.
[0086] For example, there are several ways to generate internal forwarding tables: Method 1: For the identifiers that are embedded in the hardware, they are usually not predictable during system initialization. They need to be learned by each other within the system after the board starts up. Each processor learns from each other and generates a neighbor table based on the processor identifier. During the process, the switching unit also learns the forwarding table based on the processor identifier.
[0087] Method 2: For CPU identifiers such as ID and address uniformly generated at the system level, the hardware-provided fixed ID is ignored. This identifier usually corresponds strictly one-to-one with the SLOT slot, depending on its deployment location. Therefore, all processor identifiers can be generated by default during system initialization and statically distributed to all switching units, completing the configuration of all forwarding paths. When a new board is inserted, the board actively reports to the main control board, activating message exchange between them.
[0088] The forwarding exit is the physical output port of the switching unit. The switching unit queries the internal forwarding table (CPU identifier-PORT mapping table) to map the processor's unique identifier in the private frame header to a specific physical port, and then forwards data packets through that port.
[0089] In one specific implementation, after a private frame header is inserted, the data packet enters the internal switching network. Switching units at all levels (including the central switching module and on-board switching modules) perform the following operations: First, they read the processor's unique identifier from the private frame header: Upon receiving a data packet, the switching unit only reads the CPU ID field in the private frame header, without parsing the subsequent standard Ethernet frame header (such as MAC address, IP address, etc.). Second, they query the internal forwarding table: Based on the read CPUID, the switching unit queries its local internal forwarding table (CPU ID-PORT mapping table) to directly determine the physical forwarding exit (PORT) to which the data packet should be sent. Finally, hardware-level pass-through forwarding: The switching unit uses a hardware-level pass-through forwarding mechanism to forward the data packet through the determined forwarding exit. Because each switching unit only needs to perform a simple CPU ID-PORT mapping lookup, without needing to perform MAC address matching or IP routing lookups, it achieves hardware-level pass-through forwarding with one-time parsing and full pass-through.
[0090] Specifically, at the switching unit exit, the hardware logic continuously monitors the data flow. It handles the following cases: Case 1: If no magic number in the frame header is detected, it is considered a standard Ethernet frame and forwarded according to standard procedures; Case 2: If a private magic number in the frame header is detected, it is determined based on the exit type. If the exit type is still a switching module, the private header is maintained and forwarded to the next hop, and subsequent switching units can reuse the private header for forwarding decisions; Case 3: If the exit type is other (processor or external exit), stripping logic is triggered; Case 4: If the forwarding exit corresponds to the next-level switching unit, the switching unit maintains the private frame header in the data packet.
[0091] In the case of scenario one above, if a private frame magic number is detected, the switching unit queries the internal forwarding table based on the processor's unique identifier in the private frame header to obtain the forwarding exit, and then forwards the data packet through the forwarding exit.
[0092] In one specific implementation, when the switching unit detects at the ingress that a data packet already contains a private frame magic number, it indicates that the data packet has already undergone address mapping and private frame header encapsulation at a previous switching unit. At this point, the switching unit does not need to repeat the address mapping table lookup operation, but directly reads the CPU ID in the private frame header, queries the internal forwarding table to determine the forwarding exit, and forwards the data packet through that exit.
[0093] For scenarios two and three above, if the forwarding exit corresponds to a processor or an external exit, the switching unit strips the private frame header from the data packet.
[0094] In one specific implementation, at the switching unit's exit point, hardware logic continuously monitors the data flow. The switching unit first checks if a private frame magic number exists in the data packet: if no frame header magic number is detected, it is considered a standard Ethernet frame and forwarded according to standard procedures. If a private frame header magic number is detected, it is determined in conjunction with the exit type. If the exit type is other (processor or external exit), stripping logic is triggered.
[0095] For example, the stripping process can employ a cut-through mechanism. After identifying the magic number and skipping the proprietary header length, forwarding starts directly from the Destination MAC (DMAC) byte of the standard Ethernet frame until the complete frame is forwarded. After stripping, the data packet is restored to a standard Ethernet frame, and the processor or external network device receives a standard Ethernet frame without being aware of the existence of the internal proprietary header.
[0096] Regarding scenario four above, if the forwarding exit corresponds to the next-level switching unit, the switching unit maintains the private frame header in the data packet.
[0097] The switching units allow for multi-level cascading. All switching units only read the CPU identifier in the private frame header and directly determine the exit point through the CPU identifier-PORT mapping table, without needing to perform MAC address matching or IP route lookup. Furthermore, regardless of the network segment where external network elements (UPF, AMF, etc.) are located, the internal switching network converts traffic into routes based on the CPU identifier, eliminating the overhead of duplicate IP addresses and tunnel resolution in multi-level switching, and ensuring low-latency determinism for cross-network segment services.
[0098] In one specific implementation, when the switching unit determines that the forwarding exit is still the switching module (i.e., the next hop is still the switching unit), it does not perform the private frame header stripping operation, but instead maintains the private frame header and forwards it to the next hop. Subsequent switching units, after detecting the private frame magic number, can still reuse the processor's unique identifier in the private frame header for forwarding determination, without needing to re-execute the address mapping table lookup operation.
[0099] This mechanism enables data packets with encapsulated private headers to be forwarded between multi-level cascaded switching units. Each level of switching unit can reuse the processor's unique identifier in the private frame header for forwarding, without having to re-execute the address mapping table lookup at each level of switching node. This achieves full reuse of the private frame header within the switching network.
[0100] Furthermore, prior to S301 above, the communication method provided in this application embodiment may further include the following steps: Obtain the processor's unique identifier for each processor, and generate or receive an internal forwarding table based on the processor's unique identifier.
[0101] Specifically, taking a satellite base station in a heterogeneous discrete architecture as an example, the base station system consists of: one main control board (CPU), multiple baseband boards (each baseband board deploys multiple processor FPGA / SoCs and an on-board switching unit), and one central switching unit connecting all boards and external outputs. All boards undergo power-on initialization. The main control board (heterogeneous discrete architecture) (or a designated integrated board (homogeneous integrated architecture)) is responsible for the necessary initialization of the satellite base station equipment, such as activating and starting various hardware and software to ensure the overall system is functioning correctly. The baseband boards are responsible for ensuring the normal operation of various components, radio frequencies, interfaces, etc., on their boards.
[0102] It should be noted that the satellite base stations in the homogeneous integrated architecture and the satellite base stations in the hybrid architecture adopt the same processing method, which will not be elaborated here.
[0103] The process of obtaining the unique identifier of each processor can be achieved in two ways: Method 1: Obtain the unique identifier of the processor by listening to the messages sent by the processor (dynamic learning method); Method 2: Receive the unique identifier of the processor generated by the main control board or the integrated board (static distribution method).
[0104] Regarding Method 1, identifiers embedded in the hardware (such as MAC addresses) are typically unpredictable during system initialization and require mutual learning and notification within the system after board startup. Each processor sends a message (such as a broadcast frame or a custom discovery frame) carrying its unique processor identifier after startup. The switching unit listens to these messages, extracts the unique processor identifier from the source address field (such as the source MAC address), and generates a mapping between the processor identifier and the forwarding exit based on the receiving port and the unique processor identifier carried in the message. Each processor learns from the others and generates a neighbor table based on the processor identifier. During the learning process, the switching unit generates a forwarding table based on the processor identifier.
[0105] Regarding Method 2, for the CPU identifiers such as ID and address uniformly generated at the system level, these identifiers strictly correspond one-to-one with the SLOT slots, determined by the board's deployment location. The main control board or integrated board generates a unique processor identifier corresponding one-to-one with the deployment location of the processor (for example, a processor on a board inserted into slot 1 is assigned CPUID_1, and one inserted into slot 2 is assigned CPUID_2). All processor identifiers can be generated by default during system initialization and statically distributed to all switching units, completing the configuration of all forwarding paths. The switching unit receives configuration information from the main control board or integrated board, containing the correspondence between each processor's unique identifier and the forwarding exit, and generates an internal forwarding table accordingly. When a new board is inserted, the board proactively reports to the main control board, activating message exchange between them.
[0106] Furthermore, all types of boards can actively send data, including data sent from external networks. The following explanation uses the baseband board sending data as an example.
[0107] The baseband board processor software generates standard Ethernet frames. The board and switching unit are compatible with various connection methods, such as PCIe and onboard high-speed Ethernet driver ports. The processor's message sending and receiving methods are not limited and can use any of the following methods: Method 1 (DPDK / User-space DMA Engine): The processor directly constructs standard Ethernet frames and writes them to the DMA buffer, bypassing the kernel protocol stack. This method implements message sending and receiving through the user-space DMA engine, without needing processing by the operating system kernel protocol stack, resulting in lower latency and higher throughput.
[0108] Method 2 (System Built-in Network Suite): The processor uses the system's built-in network suite to directly forward packets to the network card via the kernel. This method uses the operating system kernel protocol stack to complete packet transmission and reception, offering better compatibility and is suitable for control plane signaling and other services that are not sensitive to latency.
[0109] Furthermore, when a base station needs to connect to multiple UPFs located in different network segments simultaneously, for example, baseband board A connects to UPF-A (IP address 20.0.0.1) and baseband board B connects to UPF-B (IP address 10.0.0.1), the main control board distributes service configurations to the IP-CPUID table in the switching unit: 20.0.0.1 → CPUID_20, 10.0.0.1 → CPUID_21. The forwarding process is as follows: the destination IP of the external packet is 20.0.0.1, the ingress gateway queries the IP-CPUID table to obtain CPUID_20, and encapsulates a private header. Subsequent switching nodes only consult the CPUID-PORT table for forwarding. The core forwarding mechanism is the same, avoiding the overhead of IP route matching at each level of switching node and simplifying the switching logic.
[0110] Furthermore, in scenarios where multiple baseband boards share the same UPF, it is necessary to combine the fields in the tunnel (such as GTP-U TEID) at the entry point to find the unique identifier of the corresponding CPU processor, which will serve as the basis for subsequent forwarding.
[0111] Specifically, multiple baseband boards connect to the same UPF and use the same destination IP address. At the entry point, the switching unit parses the GTP-U tunnel protocol header, extracts the TEID field, queries the TEID-CPU identifier mapping table (e.g., TEID_100 corresponds to CPUID_20, TEID_200 corresponds to CPUID_21), obtains the corresponding CPU ID, and then encapsulates a private frame header. Subsequent switching units at each level only forward packets based on the CPU ID in the private frame header.
[0112] Further, please refer to Figure 4 , Figure 4 This application provides an internal route generation and forwarding flowchart for its embodiments. Internal routing refers to the hardware forwarding path based on CPU identifiers between switching units and between a switching unit and a board processor. Standard Ethernet frames are used for communication between the board and external network devices. The internal routing layer and the standard Ethernet layer are seamlessly connected through the insertion and stripping of proprietary headers.
[0113] In summary, the embodiments of this application provide a multi-level switching and forwarding mechanism based on a globally unique CPU identifier: each level of switching unit constructs and maintains a forwarding mapping table based on the identifier; during data forwarding, hardware-level pass-through forwarding is completed by relying on the target CPU identifier in the private frame header. Multi-level switching units can reuse the CPU identifier, avoid repeated IP and MAC table lookup operations, and realize cross-level stateless, low-latency hardware-level pass-through forwarding.
[0114] Furthermore, a hardware pipeline-based frame header streaming processing method is proposed: at the data inlet side, the frame type is identified, and a private header containing the magic number and target CPU identifier is dynamically and streamingly inserted based on the message metadata; at the data outlet side, the hardware pipeline detects and strips the private frame header to restore the original frame format.
[0115] Therefore, firstly, by using dual-mode adaptive conversion between private frames and standard Ethernet frames, the internal routing communication of the CPU identifier and the external standard Ethernet communication are layered and coordinated. This satisfies the requirements of the onboard internal communication for extremely low latency and high deterministic forwarding through fast routing of the CPU identifier, while also shielding the differences in the underlying interfaces and architectures between boards. It does not require reliance on specific hardware, and various processors only need to process standard Ethernet frames. At the same time, it is compatible with external standard Ethernet interfaces, solving the technical bottleneck of the difficulty in integrating private protocols and standard networks.
[0116] Secondly, the CPU-based routing mechanism simplifies complex IP / MAC lookups into hardware-direct ID mapping, where the forwarding direction can be determined by the first few bytes. This significantly reduces the consumption of logical resources in the switching unit and the forwarding latency, making it particularly suitable for resource-constrained environments on satellites.
[0117] Furthermore, by using fields such as service type and priority in the private header, differentiated hardware queue scheduling can be provided for services with different QoS requirements, such as control signaling, user data, and IQ sampling, on the same physical link.
[0118] Please refer to Figure 5 , Figure 5 This application provides a structural block diagram of a communication device applied to a switching unit in a satellite communication base station system. The satellite communication base station system includes various types of processors. The communication device 500 includes: a detection module 501, used to detect whether a received data packet contains a private frame magic number; a query module 502, used to, if no private frame magic number is detected, query an address mapping table based on the forwarding association information of the data packet to obtain the processor unique identifier of the target forwarding object, and insert a private frame header into the data packet, wherein the address mapping table includes the correspondence between forwarding association information and processor unique identifiers, and the private frame header includes the private frame magic number and the processor unique identifier; and a determination module 503, used to query an internal forwarding table based on the processor unique identifier in the private frame header to determine the forwarding exit, and forward the data packet through the forwarding exit, wherein the internal forwarding table includes the correspondence between processor unique identifiers and forwarding exits.
[0119] In the above scheme, the switching unit distinguishes between standard Ethernet frames and encapsulated frames by detecting the private frame magic number at the packet ingress. Only when the magic number is not detected is the address mapping table consulted to obtain the processor's unique identifier for the target forwarding object, and a private frame header containing that processor's unique identifier is inserted. This allows each switching unit to determine the forwarding exit by simply reading the processor's unique identifier in the private frame header and consulting the internal forwarding table, without needing to perform MAC address matching or IP route lookups. This achieves hardware-level pass-through forwarding with a single resolution. Furthermore, since forwarding association information is used as the basis for querying the address mapping table, forwarding decisions can be made without deep parsing of the packet content, significantly reducing the logical resource consumption and forwarding latency of the switching unit, making it particularly suitable for resource-constrained onboard environments.
[0120] In an optional implementation, before detecting whether the data packet includes a private frame magic number upon receiving the data packet, the communication device 500 further includes: an acquisition module for acquiring the processor unique identifier of each processor and generating or receiving an internal forwarding table based on the processor unique identifier.
[0121] In the above scheme, by obtaining the unique processor identifier of each processor before detecting data packets and generating or receiving an internal forwarding table based on this unique processor identifier, the switching unit can complete the pre-configuration of the forwarding path before the data packets arrive. The generation method covers scenarios where the switching unit dynamically builds the forwarding table through listening and learning, while the receiving method covers scenarios where the main control board or integrated board statically distributes the forwarding table. Both methods ensure that the switching unit has a complete mapping between the unique processor identifier and the forwarding exit when forwarding data packets, providing a foundation for subsequent hardware-level pass-through forwarding.
[0122] In an optional implementation, the acquisition module is further configured to: obtain the processor's unique identifier by listening to the messages sent by the processor, or receive the processor's unique identifier generated by the main control board or the integrated board.
[0123] In the above scheme, the unique identifier of the processor is obtained by listening to the messages sent by the processor. This allows the switching unit to automatically discover each processor and establish a forwarding table after the board starts up through mutual notification and learning within the system, without manual configuration and supporting plug-and-play functionality. Simultaneously, by receiving the unique identifier of the processor generated by the main control board or integrated board, the system can uniformly allocate identifiers and statically distribute configurations based on the board's deployment location, avoiding service interruptions caused by MAC drift that may occur during dynamic learning. The parallel existence of these two acquisition methods allows this invention to be compatible with both hardware-fixed identifier scenarios and system-unified addressing scenarios.
[0124] In an optional implementation, the processor unique identifier is generated by the main control board or integrated board based on the deployment location of the processor on the board, and the processor unique identifier corresponds one-to-one with the deployment location.
[0125] In the above solution, the main control board or integrated board generates a unique processor identifier that corresponds one-to-one with the deployment location of the processor on the board. This ensures that the processor identifier is strictly bound to the physical slot, eliminating the need for hardware-fixed MAC addresses or factory IDs. During system initialization, all processor identifiers are generated by default and statically distributed to all switching units, eliminating the need for mutual notification and learning processes after board startup. This removes the risk of short-term service interruptions on the satellite caused by dynamic MAC address drift, improving system stability and determinism.
[0126] In optional implementations, the forwarding association information includes at least one of the following: destination IP address, destination MAC address, tunneling protocol field, and Virtual Local Area Network (VLAN) identifier.
[0127] In the above scheme, by setting the forwarding association information to at least one of the following: destination IP address, destination MAC address, tunnel protocol field, and VLAN identifier, the switching unit can adapt to the forwarding requirements of various service scenarios. For multi-UPF interconnection scenarios, mapping can be completed through the destination IP address; for scenarios where multiple baseband boards share the same UPF, the tunnel protocol field can be used for judgment; for scenarios involving VLAN isolation, the VLAN identifier can be used for mapping. This setting allows the present invention to flexibly adapt to complex forwarding logic under different network configurations without the need to develop separate forwarding schemes for each scenario.
[0128] In an optional implementation, the determining module 503 is further configured to: if a private frame magic number is detected, query the internal forwarding table based on the processor unique identifier in the private frame header to determine the forwarding exit, and forward the data packet through the forwarding exit.
[0129] In the above scheme, when a data packet is detected to contain a private frame magic number, the internal forwarding table is directly queried based on the processor's unique identifier in the private frame header for forwarding. This eliminates the need for repeated address mapping table lookups when data packets with encapsulated private headers are transmitted between different levels of switching units. This mechanism allows each level of switching unit in a multi-level cascaded scenario to directly reuse the encapsulated private frame header at the ingress point, eliminating the overhead of repeated table lookups at each level of switching node and further reducing the cumulative forwarding latency in multi-level switching topologies.
[0130] In an optional implementation, the communication device 500 further includes a stripping module for stripping private frame headers from data packets if the forwarding exit corresponds to a processor or an external exit.
[0131] In the above scheme, by stripping the proprietary frame header from the data packet at the forwarding egress corresponding to the processor or external egress, the data packet is restored to the standard Ethernet frame format when it leaves the switching network and arrives at the processor or external network. The processor receives a standard Ethernet frame and does not need to be aware of the existence of the internal proprietary frame header. External network devices also do not need to support proprietary protocols to receive data packets normally, thus achieving seamless integration between the forwarding of internal proprietary frame formats and external standard Ethernet protocols.
[0132] In an optional implementation, the communication device 500 further includes a maintenance module, configured to maintain a private frame header in the data packet if the forwarding exit corresponds to a next-level switching unit.
[0133] In the above scheme, by maintaining the private frame header in the data packet when forwarding to the next-level switching unit, the data packet with the encapsulated private header can be reused by each level of switching unit for forwarding decisions when transmitted between multi-level cascaded switching units. This eliminates the need to re-execute the address mapping table lookup operation at each switching node. This mechanism works in conjunction with the aforementioned stripping mechanism to dynamically decide whether to strip the private header based on the exit type, achieving full reuse of the private frame header within the switching network and automatic stripping at the exit.
[0134] Please refer to Figure 6 , Figure 6 This application provides a structural block diagram of an electronic device 600, which includes at least one processor 601, at least one communication interface 602, at least one memory 603, and at least one communication bus 604. The communication bus 604 enables direct communication between these components, the communication interface 602 facilitates signaling or data communication with other node devices, and the memory 603 stores machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 communicates with the memory 603 via the communication bus 604, and the machine-readable instructions are executed by the processor 601 when invoked.
[0135] The processor 601 comprises one or more, and can be an integrated circuit chip with signal processing capabilities. The processor 601 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a special-purpose processor, including a Neural-network Processing Unit (NPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors 601, some can be general-purpose processors, and others can be special-purpose processors.
[0136] The memory 603 includes one or more, which may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0137] This application also provides a computer-readable storage medium that stores computer program instructions. When the computer program instructions are executed by a computer, the computer performs various functions or steps in the above-described communication method embodiments.
[0138] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps in the above-described communication method embodiments.
[0139] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0140] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0141] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0142] It should be noted that if the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0143] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.
[0144] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A communication method, characterized in that, A switching unit used in a satellite communication base station system, the satellite communication base station system including various types of processors, the method comprising: Upon receiving a data packet, detect whether the data packet includes a private frame magic number; If the private frame magic number is not detected, the address mapping table is queried according to the forwarding association information of the data packet to obtain the processor unique identifier of the target forwarding object, and a private frame header is inserted into the data packet. The address mapping table includes the correspondence between the forwarding association information and the processor unique identifier, and the private frame header includes the private frame magic number and the processor unique identifier. The internal forwarding table is queried based on the processor's unique identifier in the private frame header to determine the forwarding exit, and the data packet is forwarded through the forwarding exit. The internal forwarding table includes the correspondence between the processor's unique identifier and the forwarding exit.
2. The communication method according to claim 1, characterized in that, Before detecting whether the received data packet includes a private frame magic number, the method further includes: Obtain the processor unique identifier of each processor, and generate or receive the internal forwarding table based on the processor unique identifier.
3. The communication method according to claim 2, characterized in that, The step of obtaining the processor's unique identifier for each processor includes: The processor's unique identifier can be obtained by listening to the messages sent by the processor, or by receiving the processor's unique identifier generated by the main control board or the integrated board.
4. The communication method according to claim 3, characterized in that, The processor's unique identifier is generated by the main control board or the integrated board based on the deployment location of the processor on the board, and the processor's unique identifier corresponds one-to-one with the deployment location.
5. The communication method according to claim 1, characterized in that, The forwarding association information includes at least one of the following: destination IP address, destination MAC address, tunnel protocol field, and VLAN identifier.
6. The communication method according to claim 1, characterized in that, After detecting whether the data packet includes a private frame magic number, the method further includes: If the private frame magic number is detected, the internal forwarding table is queried based on the processor unique identifier in the private frame header to determine the forwarding exit, and the data packet is forwarded through the forwarding exit.
7. The communication method according to any one of claims 1-6, characterized in that, Before forwarding the data packet through the forwarding exit, the method further includes: If the forwarding exit corresponds to a processor or external exit, then the private frame header in the data packet is stripped.
8. The communication method according to any one of claims 1-6, characterized in that, Before forwarding the data packet through the forwarding exit, the method further includes: If the forwarding exit corresponds to the next-level switching unit, then the private frame header in the data packet is maintained.
9. A satellite communication base station system, characterized in that, include: At least one switching unit, and one or more boards connected to the switching unit, the boards carrying one or more processors, the processors including various types; The switching unit is used to perform the method as described in any one of claims 1 to 8.
10. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-8.
11. An electronic device, characterized in that, include: Processor, memory, and bus; The processor and the memory communicate with each other via the bus; The memory stores computer program instructions that can be executed by the processor, and the processor can invoke the computer program instructions to perform the method as described in any one of claims 1-8.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-8.
