Converged communication command and dispatch system construction method based on distributed message bus

Abstract

The invention discloses a construction method of a converged communication command and dispatch system based on a distributed message bus. The construction method comprises the following steps: A, defining a unified message format; b, adopting a proper distributed message bus system program to realize message transmission among modules of the system; c, compiling related message mapping for data related to the system; d, defining and numbering interaction instructions to be realized in the system, and packaging the interaction instructions in a unified message format; e, defining each module in the system, and compiling an interface file; f, after the data structure in the step E is defined, each entity to be accessed to the message bus is divided into interaction functions needing to be realized; g, on the message bus, all system operations can be simplified into a publishing / subscribing interaction mode; due to the adoption of the distributed message bus architecture and the unified message format, the system can be easily accessed to a new communication network or equipment, and the expansibility of the system is greatly improved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method for constructing a fusion communication command and dispatch system based on a distributed message bus, which adopts a distributed message bus architecture to achieve multi-network fusion and optimization of resource scheduling, and improve the flexibility, scalability and maintainability of the system. The present invention is particularly suitable for scenarios where multiple communication networks need to be integrated to achieve unified command and dispatch. Background Art

[0002] With the continuous advancement of social informatization, modern communication technology has been widely used, especially in command and dispatch systems, and the diversified needs of communication networks are increasing. Traditional command and dispatch systems are usually based on simple communication protocols and network architectures, which cannot meet the integration needs of diversified communication networks. Especially in the context of broadband and narrowband integration, and public and private network integration, traditional systems have great limitations in resource sharing, scalability, and maintainability.

[0003] The existing technology has the following problems: 1. A single architecture is difficult to cope with the integration of multiple communication networks: The traditional command and dispatch system architecture is usually based on the implementation of a certain type of communication network and cannot flexibly adapt to the new network environment.

[0004] 2. Poor scalability: When the system expands new devices or new networks, each end is often required to modify the existing code, which increases the difficulty of development and maintenance.

[0005] 3. Difficulty in resource sharing: Since the protocols between systems are different, resource sharing between communication networks is limited, resulting in the inefficient use of some resources and waste.

[0006] 4. Difficulty in fault location: Due to the tight coupling of various functional modules in the system, the troubleshooting and location of system faults are relatively complicated.

[0007] Therefore, a new system construction method is urgently needed to solve these technical problems and provide an efficient, scalable and easy-to-maintain command and dispatch system. Summary of the invention

[0008] The purpose of the present invention is to provide a method for constructing a fusion communication command and dispatch system based on a distributed message bus, which can effectively support the integration of multiple communication networks, optimize resource scheduling, and simplify system development and maintenance, so as to solve the problems raised in the above background technology.

[0009] In order to achieve the above object, the present invention adopts the following technical scheme: a method for constructing a fusion communication command and dispatch system based on a distributed message bus, comprising the following steps: A. Define message format: Define a unified message format so that the transmission and processing of messages are unified and used for all data interactions within the system; B. Use appropriate distributed message bus system program to realize message transmission between system modules; C. Write relevant message mappings for the data involved in the system using the format selected in step A; D. Define and number the interactive instructions to be implemented in the system and encapsulate them in a unified message format; E. Define each module in the system and write the interface file according to step C; F. After defining the data structure in step E, divide the interactive functions that need to be implemented for each entity to be connected to the message bus; G. On the message bus, all system operations can be simplified to publish / subscribe interactions.

[0010] Preferably, the message format in step A includes message definition of database table structure; message definition of system interaction instructions; and unified message packaging format definition.

[0011] Preferably, step C includes two important message definitions, one is a message that needs to be persisted, such as data that needs to be saved in the system, especially table data saved in a database; the other is a message that does not need to be persisted, such as an instruction or a data change notification.

[0012] Preferably, the step E includes the following data structure: 1) Basic data table structure: 1.1 Organizational structure of the unit; 1.2 Users and corresponding permissions; 1.3 Data tables of relevant equipment and terminals, including basic data and configuration data; 1.4 Related map basic data, layers and related POI data; 1.5 Basic dialing data, call signs, dialing rules, blacklist and whitelist, etc.; 2) Production data: 2.1 System equipment, user login log; 2.2 Positioning data and related processing, such as tracking, fencing, sentry, etc.; 2.3 Call records, including narrowband intercom, ordinary PSTN phone, SIP phone, PC dispatch console, mobile phone APP, GB28181 monitoring call, etc.; 2.4 If video is involved, the relevant video data; 2.5 Various alarm data.

[0013] Preferably, the entity in step F includes: 1) The front end of the network management console is responsible for basic configuration and management of system data; 2) The back end of the network management console is responsible for receiving the data and operations from the front end of the network management console and writing the data into the database or sending corresponding control instructions; 3) Base station controller equipment, responsible for base station configuration and forwarding data for terminals under the base station; 4) Large-screen control consoles at all levels of dispatch centers are responsible for monitoring and organizing daily communications; 5) Front-end command and dispatch system of each dispatching unit; 6) Public network communication terminal, POC, dual-frequency relay, single-frequency relay; 7) GB28181 monitoring system or separately deployed GB28181 equipment; 8) Shortwave radio system.

[0014] Preferably, step G comprises the following steps: 1) Traditional RPC mode, that is, the client sends a request to the server, and the server replies with a response. This can be converted into the client publishing a message to the message bus, and it also subscribes to a topic with a specific ID. After the server receives and processes the message, the response will be published to the topic specified by the ID; 2) Broadcast information generated by each call / dispatch, as long as someone is interested and subscribes, they will receive the broadcast message, such as alarm messages, call conferences, cluster intercoms, shared videos, etc.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. Since the present invention adopts a distributed message bus architecture and a unified message format, the system can easily access new communication networks or devices, and the system scalability is greatly improved.

[0016] 2. The present invention adopts modular design, and each functional module is decoupled, which is convenient for independent development and maintenance, and improves the maintainability and stability of the system.

[0017] 3. The present invention can efficiently share resources between different communication networks, avoid duplication and waste of resources, and improve resource utilization efficiency.

[0018] 4. The present invention adopts a unified communication protocol adaptation layer and modular design, which reduces the complexity of system development and maintenance and reduces operation and maintenance costs.

[0019] 5. The system of the present invention can realize efficient and accurate command and dispatch, ensuring the timeliness and accuracy of task dispatch. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0021] In order to further explain the technical solution of the present invention, it is described in detail below through specific embodiments.

[0022] See also Figure 1 The present invention provides a method for constructing a fusion communication command and dispatch system based on a distributed message bus, comprising the following steps: A. Define message format: Define a unified message format so that the message transmission and processing are unified and used for all data interactions in the system. The message format includes the message definition of the database table structure; the message definition of the system interaction instructions; and the definition of a unified message packaging format. You can choose to define the message format in a variety of ways, for example: 1) ASN.1 format, which has a great advantage in message encoding size and can reduce bandwidth waste during message transmission, but its implementation is relatively complex; 2) JSON format: This format has a great advantage in readability, but it wastes a lot of bandwidth when transmitting messages and is relatively simple to implement; 3) XML format: This format has a great advantage in readability, but it wastes a lot of bandwidth during message transmission and has poor performance; The present invention adopts the open source protobuf format, which has great advantages in code size, performance and support for multiple programming languages, and greatly reduces the workload for system development and implementation; the coding efficiency is high and the message size is small: binary coding is adopted to reduce the amount of transmitted data, and variable-length coding is used to further optimize space occupancy; cross-language support capability is strong; multiple mainstream programming languages ​​are supported, such as C++, Java, Python, etc.; a unified API interface is provided to facilitate integration between different languages; forward and backward compatibility is good; adding, deleting and modifying fields are supported without affecting existing systems; the stability of the message structure is ensured by field identifiers; automatic code generation capability; automatic generation of serialization and deserialization code according to message definition; reduction of manual coding workload and improvement of development efficiency; type safety; strong type definition to reduce runtime errors; type checking during compile time to discover potential problems in advance; superior performance; fast parsing speed, suitable for high-performance systems; small memory occupancy, suitable for resource-constrained environments.

[0023] B. Use a suitable distributed message bus system program to implement message transmission between system modules. You can choose different distributed message bus programs, for example: 1) Apache Kafka: It has powerful message storage and processing capabilities, can realize large-scale message storage and processing, and focuses on message transmission between servers; 2) RabbitMQ: Traditional AMQP messaging processing, with poor large-scale capabilities; 3) Apache Pulsar: An open source distributed messaging and streaming platform built specifically for the cloud, with good processing power and performance; The present invention adopts cncf's NATS.io message bus. NATS.io is a connection technology for distributed systems, which is very suitable for connecting devices, edges, clouds or hybrid deployments, and the self-healing and expansion technology allows the topology to be changed at any time with zero downtime. The specific implementation includes: deploying a NATS.io server cluster; configuring a message persistence strategy; implementing message routing and load balancing; establishing a failover mechanism; and configuring a security authentication mechanism.

[0024] C. Write relevant message mappings for the data involved in the system using the format selected in step A. It includes two important message definitions: one is the message that needs to be persisted, such as the data that needs to be saved in the system, especially the table data saved in the database; the other is the message that does not need to be persisted, such as instructions or data change notifications. The examples are as follows: / / Each database table can be defined using protobuf. The following is an example of an organization structure table. / / Organization structure table message db_org { / / @table uuid primary key / / Row ID string rid = 1; / / @table timestamp not null default now_utc() / / Last modification time string update_at = 2; / / @table varchar(64) unique not null / / Organization number string org_self_id = 3; / / @table int default 100 / / Sort value, specified by the user, regardless of pinyin or other languages ​​int32 org_sort_value = 4; / / @table varchar(32) unique not null / / Organization name, abbreviation string org_short_name = 5; / / @table varchar(256) / / Organization name, full name string org_full_name = 6; / / @table text / / Detailed description of organization string note = 7; / / @table uuiddefault '11111111-1111-1111-1111-111111111111' / / Organization icon string org_img = 10; / / @table uuid not null default '11111111-1111-1111-111111111111' / / The parent organization of this organization device string parent_org_id = 11; / / @table uuid / / Creator string creator = 14;} / / Interaction instructions within the system can also be defined using protobuf. The following is an example of a login request. / / Login request rpc.cmd = 100 message login { / / Device dmrid can be left blank on the Android side fixed32 device_dmrid = 1; / / Device name, fill in username on the Android side string device_name = 2; / / Login type, 0: relay station 1: console program 2: console program / gateway terminal 3: android terminal login 23: public network poc login int32 login_type = 3; / / Device model is optional on Android / / BF8100 project: TR805005, dual-frequency repeater, 2 time slots / / BF-TR925 project: TR092500, dual-frequency repeater, 2 time slots / / BF-TR925R project: TR092501, single-frequency repeater, 1 time slot / / BF-TR925D project: TR09250M, single-frequency repeater, 1 time slot string device_model = 4; / / Password verification value Android side fill in password / sid string password = 5; / / Password verification method / / 0: password = hex (device_dmrid / 1023) / / 1: password = base64 (md5 (hex (device_dmrid) + device_password)) / / 10: pc / / The console logs in as a web user, password=base64(sha256(time_str+base64(sha256(user_name+user_pass)))) / / andoid end, public network poc end: / / 11: Log in with a password, password=base64(sha256(time_str+base64(sha256(user_name+user_pass)))) / / 12: Log in with sid, first login / / 13: Log in with sid, disconnect and reconnect int32password_method = 6; / / Parameters required when password_method=10 / 11 / / The current time (utc) format is: yyyy-mm-dd hh:mm:ss string time_str = 7; / / System number, 00-63 string sys_id =8; / / Additional required functions, each additional function has a corresponding function number / / 8: Relay supports monitoring function / / 107: Request the terminal that has registered under this relay to send a prompt that the terminal has logged in elsewhere, the function number is 107 / / 175: The controller requires sending all session end information, the function number is 175 / / 375: The app requires forwarding GPS information, it has a map display function repeated int32 extra_option = 9; / / Supported codec encoder, used by the background to determine whether the encoder is supported in order to forward related data / / Currently supported codec encoders: / / 0: dmr ambe->bc30 / / 1: opus->bc10 / / Not filled in by default, that is, only standard dmr ambe is supported, null=[0] / / Poc end generally=[1] / / cm625=[0,1]repeated int32 codec = 10;} / / Login response / / Specially, the andoid end needs to actively return information such as channels message res_login { / / Login response value / / 0: Login successful, / / 1: Repeat login / / 4: Incorrect password / / 5: No specified password login / / 10: Login failed, this device does not exist / / 44:badparam / / 303: The user did not specify a device / / 404: This session id does not exist, you need to change the username and password to log in / / 500: Server internal error int32 res_code = 1; / / last session id int64 sid = 3; / / server configuration hangup time, in milliseconds, 0 is an invalid value int32 hangup_time = 4; / / server http port int32 http_port = 5; / / server version number string server_version = 6; / / configuration last update time, UTC time / / currently only poc terminals have this field string setting_last_update_time = 7;}. ;

[0025] D. Define and number the interactive instructions to be implemented in the system and encapsulate them in a unified message format. The example is as follows: / / All message interactions in the system are wrapped in this message rpc_cmd { / / sequence noint32 seq_no = 2; / / session id int64 sid = 3; / / rpc command code int32 cmd =5; / / response code int32 res = 8; / / command body bytes body = 10; / / optionalstr parameter, additional information, generally not available, some special commands may use string para_str = 11; / / optional binary parameter, additional information, generally not available, some special commands may use bytes para_bin = 12; / / optional int64 parameter int64 para_int = 13;}.

[0026] E. Define each module in the system and write a protobuf interface file according to the example given in C, including at least the following data structure: 1) Basic data table structure: 1.1 Organizational structure of the unit; 1.2 Users and corresponding permissions; 1.3 Data tables of relevant equipment and terminals, including basic data and configuration data; 1.4 Related map basic data, layers and related POI data; 1.5 Basic dialing data, call signs, dialing rules, blacklist and whitelist, etc.; 2) Production data: 2.1 System equipment, user login log; 2.2 Positioning data and related processing, such as tracking, fencing, sentry, etc.; 2.3 Call records, including narrowband intercom, ordinary PSTN phone, SIP phone, PC dispatch console, mobile phone APP, GB28181 monitoring call, etc.; 2.4 If video is involved, the relevant video data; 2.5 Various alarm data; F. After defining the data structure in step E, divide the interactive functions that need to be implemented for each entity to be connected to the message bus. The entities that need to be considered include: 1) The front end of the network management console is responsible for basic configuration and management of system data; 2) The back end of the network management console is responsible for receiving the data and operations from the front end of the network management console and writing the data into the database or sending corresponding control instructions; 3) Base station controller equipment, responsible for base station configuration and forwarding data for terminals under the base station; 4) Large-screen control consoles at all levels of dispatch centers are responsible for monitoring and organizing daily communications; 5) Front-end command and dispatch system of each dispatching unit; 6) Public network communication terminal, POC, dual-frequency relay, single-frequency relay; 7) GB28181 monitoring system or separately deployed GB28181 equipment; 8) Shortwave radio system; For each entity in the system, if it can directly access the message bus, its business logic is implemented on the basis of the message bus. Otherwise, a message bus gateway needs to be implemented for it to achieve free interaction with other entities through the gateway.

[0027] G. On the message bus, all system operations can be simplified to publish / subscribe interactions; 1) Traditional RPC mode, that is, the client sends a request to the server, and the server replies with a response. This can be converted into the client publishing a message to the message bus, and it also subscribes to a topic with a specific ID. After the server receives and processes the message, the response will be published to the topic specified by the ID; 2) Broadcast information generated by each call / dispatch, as long as someone is interested and subscribes, they will receive the broadcast message, such as alarm messages, call conferences, cluster intercoms, shared videos, etc.

[0028] Here is an example: (1) Simple data editing interaction (1.1) The front end of the network management console generates the data that needs to be operated, which is encoded in protobuf format. It contains the data table to be operated, the operation code (add, delete, modify, query), and the topic ID to be replied to. This message is published to the message bus. After the back end of the network management console responsible for data processing is started, it has subscribed to the topics of editing these data. When new data is pushed, it will receive these messages and write the data into the database. After the processing is completed, a reply message is published to inform the front end of the network management console that the data has been processed. At the same time, a broadcast message can also be published to notify all those who are concerned about the entity data that changes have occurred; (1.2) In fact, data editing is not limited to the front-end operations of the network management. Unified data editing and processing can be achieved by publishing messages between the back-end command centers at all levels and the front-end command centers, and between the command system and other third-party integrated systems.

[0029] (2) Command and dispatch interaction (2.1) The front-end operations of the command and dispatch centers at all levels are published to the message bus through the unified protobuf message format and the pre-defined topic ID. The operation instructions will be distributed to each related entity by the message bus. The operation end does not need to care about the details of the specific operation, but only needs to publish the message. Such as roll call, location, etc. (2.2) Complex operations involving multiple entities and multiple steps can also be implemented through the message bus. For example, in the intercom scheduling of a cluster, the command center will add the members who will participate in the intercom to the list to form an intercom group (this operation can be performed in advance to save the waiting time for dynamic reorganization), and then the intercom can begin. In the message bus, the operation process is to first send a message to the message bus to establish an intercom group, and the message bus will distribute it to each intercom member. After each member receives the message to establish the intercom group, it will respond to the initiator with a confirmation message and subscribe to the message of the intercom group. After that, all messages about this intercom group will be received by subscribing to the topic of the intercom group ID. No matter which member initiates it, it will receive it. In this way, through the message bus, a cluster intercom function is realized. At the level of the entire integrated communication system, there is no need to pay attention to the specific details of each intercom member, whether it is a walkie-talkie, a mobile phone, a PC, or other terminals. The operation end only needs to publish and receive messages from the message bus.

[0030] (3) SIP system access (3.1) The SIP system access gateway subscribes to all SIP call-related topics, including call requests, call answers, call hang-ups, etc. When a new SIP call request arrives: (3.11) The SIP gateway converts the SIP signaling into a message in protobuf format and publishes it to the message bus; (3.12) The message content includes information such as the calling party number, the called party number, and the call type (voice / video); (3.13) Generate a unique call ID and subscribe to the answer topic corresponding to the ID; (3.2) System processing SIP call flow: (3.21) After receiving the call request, the dispatch service searches for the target terminal based on the called number; (3.22) If the target terminal is online, send a call request to the target terminal; (3.23) The response message of the target terminal is sent back to the scheduling service through the message bus; (3.24) The dispatch service publishes the response result to the topic corresponding to the previously generated call ID; (3.3) SIP gateway processes call answering: (3.31) After receiving the response message, convert the response in protobuf format into SIP signaling; (3.32) Based on the response result, establish a media channel or return the reason for failure; (3.4) Key points in the whole process: (3.41) All SIP signaling is converted to the standard protobuf message format; (3.42) Decoupling and unified processing of SIP signaling is achieved through the message bus; (3.43) Support parallel deployment of multiple SIP gateways to improve system reliability; (3.44) New signaling processing logic can be easily expanded, such as call permission control, call forwarding, etc.

[0031] The system architecture design of the present invention: The system adopts a layered architecture design: Access layer: responsible for the access of various communication networks, narrowband intercom access module, public network intercom access module, SIP phone access module, video surveillance access module, and relay base station access module; Message bus layer: responsible for message transmission and routing, message publishing / subscription management, message queue management, message priority processing, and message persistence; Business logic layer: responsible for the implementation of specific business functions, call control module, resource scheduling module, authority management module, alarm processing module, and data analysis module; Data persistence layer: responsible for data storage and management, relational database storage, non-relational database storage, distributed file storage, and data backup and recovery; Presentation layer: responsible for the implementation of user interface, Web management interface, mobile APP interface, large-screen display interface, and third-party system integration interface.

[0032] The key technology implementation method of the present invention is: 1Message Routing 1.1 Topic-based message routing 1.11 Messages can be assigned to multiple topics; 1.12 Topics can be assigned to multiple queues.

[0033] 1.2 Message priority management 1.21 Messages can be assigned to different priorities; 1.22 Messages with higher priority are processed first.

[0034] 1.3 Message Filtering Mechanism 1.31 messages can be filtered out; 1.32 Filtering rules can be based on the header and body of the message.

[0035] 1.4 Message forwarding rules 1.41 messages can be forwarded to different queues; 1.42 Forwarding rules can be based on the header and body of the message.

[0036] 2. System Monitoring 2.1 Message Traffic Monitoring 2.11 Monitor the sending and receiving rates of messages; 2.12 Monitor message delay and loss rate; 2.13 Monitor the length and overflow rate of the message queue.

[0037] 2.2 System Performance Monitoring 2.21 Monitor the CPU and memory usage of the system; 2.22 Monitor the system's disk usage and IO load; 2.23 Monitor the system's network bandwidth and latency.

[0038] 2.3 Fault Alarm Mechanism 2.31 Monitor the operating status and health of the system; 2.32 Monitor the operating status of key components of the system; 2.33 Monitor system configuration and status changes.

[0039] 2.4 Log Tracking System 2.41 Record all system operations and events; 2.42 Record all system errors and warnings.

[0040] 3. Safety Mechanism 3.1 Identity authentication; 3.2 Access control; 3.3 Data encryption; 3.4 Security Audit.

[0041] The present invention provides a method for constructing a converged communication command and dispatch system based on a distributed message bus. Since the present invention adopts a distributed message bus architecture and a unified message format, the system can easily access new communication networks or devices, and the system scalability is greatly improved; a modular design is adopted, and decoupling is achieved between various functional modules, which is convenient for independent development and maintenance, and improves the maintainability and stability of the system; resources can be efficiently shared between different communication networks, avoiding duplicate construction and waste of resources, and improving resource utilization efficiency; a unified communication protocol adaptation layer and modular design are adopted, which reduces the complexity of system development and maintenance, and reduces operation and maintenance costs; the system can achieve efficient and accurate command and dispatch, and ensure the timeliness and accuracy of task scheduling.

[0042] The above description is only a preferred example of the present invention and is not intended to limit the present invention. Although the present invention is described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for constructing a fusion communication command and dispatch system based on a distributed message bus, characterized in that: The following steps are involved: A. Define message format: Define a unified message format so that the transmission and processing of messages are unified and used for all data interactions within the system; B. Use appropriate distributed message bus system program to realize message transmission between system modules; C. Write relevant message mappings for the data involved in the system using the format selected in step A; D. Define and number the interactive instructions to be implemented in the system and encapsulate them in a unified message format; E. Define each module in the system and write the interface file according to step C; F. After defining the data structure in step E, divide the interactive functions that need to be implemented for each entity to be connected to the message bus; G. On the message bus, all system operations can be simplified to publish / subscribe interactions.

2. According to claim 1, a method for constructing a fusion communication command and dispatch system based on a distributed message bus, characterized in that: The message format in step A includes the message definition of the database table structure; the message definition of the system interaction instruction; and the unified message packaging format definition.

3. According to the method for constructing a fusion communication command and dispatch system based on a distributed message bus as described in claim 1, it is characterized by: The step C includes two important message definitions, one is the message that needs to be persisted, such as data that needs to be saved in the system, especially table data saved in the database; the other is the message that does not need to be persisted, such as instructions or data change notifications.

4. According to the method for constructing a fusion communication command and dispatch system based on a distributed message bus as described in claim 1, it is characterized by: The step E includes the following data structure: 1) Basic data table structure: 1.1 Organizational structure of the unit; 1.2 Users and corresponding permissions; 1.3 Data tables of relevant equipment and terminals, including basic data and configuration data; 1.4 Related map basic data, layers and related POI data; 1.5 Basic dialing data, call signs, dialing rules, blacklist and whitelist, etc.; 2) Production data: 2.1 System equipment, user login log; 2.2 Positioning data and related processing, such as tracking, fencing, sentry, etc.; 2.3 Call records, including narrowband intercom, ordinary PSTN phone, SIP phone, PC dispatch console, mobile phone APP, GB28181 monitoring call, etc.; 2.4 If video is involved, the relevant video data; 2.5 Various alarm data.

5. The method for constructing a fusion communication command and dispatch system based on a distributed message bus according to claim 1, characterized in that: The entities in step F include: 1) The front end of the network management console is responsible for basic configuration and management of system data; 2) The back end of the network management console is responsible for receiving the data and operations from the front end of the network management console and writing the data into the database or sending corresponding control instructions; 3) Base station controller equipment, responsible for base station configuration and forwarding data for terminals under the base station; 4) Large-screen control consoles at all levels of dispatch centers are responsible for monitoring and organizing daily communications; 5) Front-end command and dispatch system of each dispatching unit; 6) Public network communication terminal, POC, dual-frequency relay, single-frequency relay; 7) GB28181 monitoring system or separately deployed GB28181 equipment; 8) Shortwave radio system.

6. The method for constructing a fusion communication command and dispatch system based on a distributed message bus according to claim 1, characterized in that: The step G comprises the following steps: 1) Traditional RPC mode, that is, the client sends a request to the server, and the server replies with a response. This can be converted into the client publishing a message to the message bus, and it also subscribes to a topic with a specific ID. After the server receives and processes the message, the response will be published to the topic specified by the ID; 2) Broadcast information generated by each call / dispatch. As long as someone is interested and subscribes, they will receive broadcast messages, such as alarm messages, call conferences, cluster intercoms, shared videos, etc.

Images