Satellite system switching fault intelligent diagnosis method based on space-ground link cooperation

Abstract

The application discloses a kind of satellite system switching fault intelligent diagnosis methods of space-ground link cooperation, belong to satellite communication technical field.By multi-source heterogeneous data acquisition module (support SNMP / Telnet protocol and equipment proprietary protocol) real-time monitoring space-ground two channels: space-based link (satellite ABIS equipment E1 interface, main station resource pool) and ground-based link (BTS equipment physical layer state, data layer signaling flow / time slot configuration, and ground BSC port alarm);Innovative fusion rule base engine and end-to-end topology tracing model: consistency check engine dynamically analyzes the three-dimensional mapping conflict of physical port, network management configuration, BSC link, automatically generates port modification instruction;Hidden alarm detection module is based on Telnet instruction penetrating scanning underlying register (such as standard query instruction).The application shortens fault location time, improves operation and maintenance efficiency and implicit fault detection rate, directly hits pain point and builds technical barrier.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of satellite communication technology, in particular to a satellite system switching fault intelligent diagnosis method based on ground-satellite link cooperation. BACKGROUND

[0002] At present, there are significant defects in satellite system switching fault processing: first, the dependence on manual operation is high, and technical personnel need to check the physical indicator light on site and manually configure the network management during operation and maintenance, which is not only inefficient but also restricted by geographical environment; second, there is a lack of cross-domain cooperation, fault troubleshooting involves ground BTS, satellite ABIS, main station resource pool, ground-satellite transmission link and other links, but each link is isolated from each other, information is difficult to exchange, leading to difficult fault location and long repair cycle; third, there is an implicit fault blind area, part of the un-mappable alarms cannot be captured by the existing network management system, and the performance of device components slowly degrades, data packets are intermittently lost, etc., which cannot be timely warned and may easily cause serious faults, which needs to be improved. SUMMARY

[0003] In view of the defects and deficiencies of the prior art, the present application provides a satellite system switching fault intelligent diagnosis method based on ground-satellite link cooperation, which is suitable for satellite switching fault processing of ground-satellite cooperation between main ground transmission (BTS / BSC) and standby satellite link.

[0004] The technical scheme adopted by the present application is as follows: a satellite system switching fault intelligent diagnosis method based on ground-satellite link cooperation, comprising the following steps:

[0005] Step 1: Real-time collection of running state data of satellite ABIS equipment, main station resource pool and E1 interface through SNMP / Telnet protocol, and synchronization of data to the diagnosis system through an encrypted channel and addition of time stamp. The running state data includes device link connection state, signal strength, bandwidth utilization, clock synchronization deviation of satellite ABIS equipment, main station resource pool business processing delay, E1 interface supplementary CRC error rate, frame synchronization loss times.

[0006] Step 2: According to the information obtained in step 1, a three-element dynamic mapping table of physical port (such as E1 time slot number), network management configuration port (OMC defined logical port number) and BSC link identification (such as VLAN ID) is established, and the consistency of the three is checked in real time.

[0007] Step 3: Perform hidden alarm detection query.

[0008] Step 4: Query and synchronize the suppression switch state.

[0009] Step 5: Start the routine fault processing procedure.

[0010] Step 6: Verify the fault elimination condition.

[0011] Further, the step 2 is specifically: if the triplets are inconsistent, a mapping correction instruction is generated and automatically issued to the target BSC device (such as generating the instruction "map BSC link 3 to link 1"), record the switching time and execution result, reduce the recovery time; if the triplets are consistent, execute step 3.

[0012] Further, the step 3 is specifically: login satellite ABIS device through Telnet protocol penetration, execute standard query instruction to obtain underlying binary alarm code. The alarm code is compared with industry standard value range and manufacturer extension value range respectively, if the code value is not matched, it is determined as un-mappable alarm, trigger the main station spare replacement process and record the physical address of the fault module to the spare management system; if the code value is matched, execute step 4.

[0013] Further, the step 4 is specifically: query the ground (main station and ground) suppression switch state respectively, if the ground suppression switch state is inconsistent (such as main station ON / ground OFF), generate a switch state synchronization instruction through rule base matching conflict type, automatically adapt the instruction format based on the device type and remotely issue, verify the consistency of the suppression switch state of the main station and the ground terminal, ensure the normal triggering of the signaling link.

[0014] Further, the step 5 includes: matching common fault types (such as time slot degradation, link congestion) through rule base, executing regular fault repair (such as adjusting bandwidth configuration). If a common fault type is matched, adapt the instruction format according to the device type, and issue the repair instruction, execute the regular fault repair; if no common fault type is matched, start the cross-domain collaborative diagnosis mechanism, integrate the whole link information such as ground BTS, satellite ABIS, main station resource pool, generate a comprehensive diagnosis report based on multi-domain data, manually review and check the specific problems for troubleshooting, record the complete processing flow, end the diagnosis process.

[0015] Further, the step 6 is specifically: real-time monitoring of device state changes, verifying fault elimination through index recovery (such as signal strength recovery, bandwidth utilization normal). If the regular fault handling is successful, manually review the diagnosis report and processing result, supplement the unstructured fault information (such as environmental factors), and perfect the fault knowledge base. If the regular fault handling fails, manually review and check the specific problems for troubleshooting, finally record the complete processing flow (including switching time, instruction log), end the diagnosis process.

[0016] Beneficial effects:

[0017] 1. The application constructs an end-to-end topology model based on real-time network topology data, reversely traces abnormal nodes from BSC end to BTS end, adopts algorithm combined with probability model, and is higher in positioning accuracy.

[0018] 2、The application shortens the fault positioning time, improves the operation and maintenance efficiency and the hidden fault detection rate, directly hits the pain point and builds a technical barrier. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 Overall workflow diagram. DETAILED DESCRIPTION

[0020] The device will be described in detail below in combination with the drawings. The described implementation is not the entire use of the device. Based on the implementation of the device, all other implementations obtained by those skilled in the art without making creative technology belong to the protection scope of the device.

[0021] The following will make a detailed description of the technical scheme of the application by combining three cases, and the flow is as shown in Figure 1

[0022] Case 1: Autonomous repair of port mapping conflict

[0023] Step 1: Real-time collection of multi-source data, including satellite ABIS device data, E1 interface device data, main station resource pool data, and ground BTS signaling data.

[0024] Satellite ABIS device data (SNMP protocol collection):

[0025] (1) Collection instruction: query MIB library (OID example) through SNMPGET

[0026] Signal strength: 1.3.6.1.4.1.2011.5.25.318.1.1.1.3.1.1.1

[0027] Bandwidth utilization rate: 1.3.6.1.4.1.2011.5.25.318.1.1.1.4.1.1.1

[0028] Clock synchronization deviation: 1.3.6.1.4.1.2011.5.25.318.1.1.1.5.1.1.1

[0029] (2) Collection result:

[0030] Link state: down

[0031] Signal strength: -70dBm (threshold -65dBm, trigger alarm)

[0032] Bandwidth utilization rate: 100% (abnormal)

[0033] ​Clock synchronization deviation: ± 150ppm (exceeding the standard ± 50ppm).

[0034] E1 interface device data (Telnet protocol acquisition):

[0035] (1) Execute instruction: show controller E1

[0036] (2) Execution result: E10 / 1 / 0:

[0037] Timeslots 1-31: CAS / CCS

[0038] Physical port ID: E1-0 / 1 / 0-1 (physical port number E1-1)

[0039] CRC error rate: 0.01% (normal threshold ≤ 0.001%)

[0040] Frame synchronization loss times: 10 times / hour (normal threshold ≤ 2 times / hour).

[0041] Master station resource pool data (SNMP acquisition):

[0042] Acquisition result: service processing delay: 50ms (normal threshold ≤ 15ms); clock synchronization state: unsynchronized (not synchronized).

[0043] Ground BTS signaling data:

[0044] Acquisition result: EtherType: 0x8100 (VLAN); VLANID: 3#BSC link identifier is VLAN3.

[0045] Step 2: Consistency check of ternary mapping

[0046] Mapping table establishment: extract Physical port ID as E1-1 from show controller E1 output, confirm physical port number; query OMC server MIB library through SNMP, configure port OMC-1 through network management; get VLANID as 3 through signaling packet analysis, confirm VLAN3 as signaling link configuration BSC link identifier VLAN3 through SNMP query BSC device dot1qVlanTable; the above data generates a ternary group (physical port E1-1, network management port OMC-1, BSC link VLAN3).

[0047] Pre-set mapping comparison:

[0048] System preset: (E1-1, OMC-1, VLAN1);

[0049] Actual mapping: (E1-1, OMC-1, VLAN3);

[0050] Conflict determination: BSC link identifies VLAN3 is inconsistent with the preset mapping of physical port E1-1 (VLAN1), triggering the automatic repair process.

[0051] Step 3: Real-time monitoring and verification

[0052] Recovery time: The switching execution time is significantly improved compared to manual processing;

[0053] Data retest: Re-collecting the triple data, confirming that the physical port E1-1, OMC port 1, and BSC link VLAN1 mapping are consistent, the signal strength is restored, and the bandwidth utilization is stable.

[0054] Case 2: Coordination repair of space-ground suppression switches

[0055] Step 1: Real-time collection of multi-source data, including main station suppression switch state, ground end suppression switch state, and signaling link indicators.

[0056] Main station suppression switch state (SNMP protocol collection):

[0057] (1) Collection instruction: Query MIB library (OID example) through SNMPGET

[0058] Suppression switch state: 1.3.6.1.4.1.2011.5.25.318.1.1.1.6.1.1.1

[0059] (2) Collection result: State is ON (allow signaling transmission).

[0060] Ground end suppression switch state (Telnet protocol collection):

[0061] (1) Execute instruction: show config include suppress switch

[0062] (2) Execution result: Ground end suppression switch state is OFF (prohibit signaling transmission).

[0063] Signaling link indicators:

[0064] Transmission delay: Actual value 200ms (normal threshold ≤50ms), packet loss rate 100% (link interruption).

[0065] Step 2: Coordination processing of suppression switch state

[0066] Conflict matching and instruction generation:

[0067] Rule-based matching: Detect the "switch status inconsistency" fault code (fault code example: SW-007).

[0068] Instruction generation: Adapt instruction format according to device type: telnet 192.168.1.100 exec "config set suppress-switch ON"

[0069] Remote execution and status synchronization:

[0070] Issue switch synchronization instructions to ground equipment through the Telnet protocol, and the execution result feedback: Command executed successfully.

[0071] Step 3: Real-time monitoring and verification

[0072] Status recovery verification: Re-collect switch status: both the main station and the ground end are ON, signaling link delay is restored to 25ms, and packet loss rate is reduced to 0.1%.

[0073] Business verification: BSC to main station signaling transmission is normal, VLAN3 link data throughput is restored to 50Mbps (normal threshold), and business recovery time is shortened by 80% compared with manual processing.

[0074] Case 3: Intelligent capture and processing of un-mappable alarms

[0075] Step 1: Real-time collection of multi-source data, including satellite ABIS device bottom layer alarm code, device clock synchronization deviation, and intermittent packet loss rate.

[0076] Satellite ABIS device bottom layer alarm code (Telnet protocol penetration collection):

[0077] (1) Execute instruction: telnet 192.168.2.200 exec "show alarm raw-code"

[0078] (2) Execution result: Bottom layer alarm code is 0x3A7F (binary value 111010011111111).

[0079] Device clock synchronization deviation (SNMP protocol collection):

[0080] Collection result: Clock synchronization deviation ±200ppm (exceeding standard ±50ppm).

[0081] Intermittent packet loss rate:

[0082] Actual value: 5% (normal threshold ≤0.01%), showing a burst packet loss every 10 seconds.

[0083] Step 2: Hidden alarm double-layer detection and judgment

[0084] Double-layer check mechanism:

[0085] First layer: compared with the ETSI standard value range (0x0001~0x1000), 0x3A7F is not matched.

[0086] Second layer: compared with the Thales manufacturer extension value range (0x2000~0x4000), 0x3A7F is not matched.

[0087] Fault judgment:

[0088] Conclusion: Trigger un-mappable alarm, locate to the clock module of satellite ABIS equipment (physical address: CHASSIS-01 / SLOT-03 / PORT-02).

[0089] Step 3: Fault handling and spare management

[0090] Standby switching: start the main station 1+1 standby switching process, execute the instruction: switch over to standby-unit1, and the switching time is 50 ms.

[0091] Spare record: record the fault module physical address "CHASSIS-01 / SLOT-03 / PORT-02" in the spare management system, and generate a work order: SPARE-20250702-003.

[0092] Step 4: Real-time monitoring and verification

[0093] Index recovery: after replacing the spare part, the clock synchronization deviation is reduced to ±30ppm, the intermittent packet loss rate disappears, and the signal strength rises to -60dBm (normal threshold -65dBm).

[0094] Processing effectiveness verification: continuously monitor for 2 hours, the equipment runs stably, the fault does not recur, and the spare management system records the processing completion time: YYYY-MM-DDTHH:MM:SS.

[0095] The above examples are only used to help understand the method of the present application and its core idea, and do not limit the protection scope of the application; at the same time, for those skilled in the art, according to the idea of the present application, there will be changes in specific implementation and application range, and the above description should not be understood as a limitation of the present application.

Claims

1. A method for intelligent diagnosis of satellite system switchover failure in cooperation with the space-ground link, characterized in that, The method comprises the following steps: Step 1: Real-time acquisition of the running state data of the satellite ABIS device, the main station resource pool and the E1 interface, and synchronization of the data to the diagnosis system through an encrypted channel and addition of a time stamp; The data comprises device link connection state, signal strength, bandwidth utilization, clock synchronization deviation of the satellite ABIS device, main station resource pool business processing delay, E1 interface supplementary CRC check error rate and frame synchronization loss times; Step 2: Establishment of a three-element dynamic mapping table of physical ports, network management configuration ports and BSC link identifiers according to the information obtained in step 1, real-time checking of the consistency of the three elements, generation of a mapping correction instruction and automatic issuance of the instruction to the target BSC device if the three-element group is inconsistent, recording of the switching time and execution result and reduction of the recovery time consumption, and execution of step 3 if the three-element group is consistent; Step 3: Execution of hidden alarm detection and inquiry; specifically, login to the satellite ABIS device through Telnet protocol penetration, execution of a standard inquiry instruction to obtain underlying binary alarm codes, comparison of the alarm codes with industry standard value ranges and manufacturer extension value ranges in sequence, determination of un-mappable alarms if the code values are not matched, triggering of a main station spare part replacement process and recording of the physical address of the fault module to a spare part management system, and execution of step 4 if the code values are matched; Step 4: Inquiry and synchronization of the sky-ground suppression switch state; specifically, inquiry of the sky-ground suppression switch state, matching of the conflict type through a rule library if the sky-ground suppression switch state is inconsistent, generation of a switch state synchronization instruction, automatic adaptation of the instruction format based on the device type and remote issuance, return to step 4 after synchronization, verification of the consistency of the suppression switch state of the main station and the ground end and ensuring of the normal triggering of the signaling link; Step 5: Start of a regular fault handling process; Specifically, matching of common fault types through a rule library, execution of regular fault repair, issuance of a repair instruction and execution of regular fault repair if the common fault types are matched, start of a cross-domain collaborative diagnosis mechanism, integration of the information of the ground BTS, the satellite ABIS and the main station resource pool, generation of a comprehensive diagnosis report based on the multi-domain data, manual review of the specific problems for troubleshooting, recording of the complete handling process and ending of the diagnosis process if the common fault types are not matched; Step 6: Verification of the troubleshooting situation.

2. The method according to claim 1, wherein, The step 6 specifically comprises real-time monitoring of the device state change, verification of the troubleshooting through the signal strength recovery and the bandwidth utilization recovery, manual review of the diagnosis report and the processing result, supplement of non-structured fault information and improvement of the fault knowledge base if the regular fault handling is successful, manual review of the specific problems for troubleshooting, final recording of the complete handling process and ending of the diagnosis process if the regular fault handling fails.

Images