Scheduling monitoring method, system and device, and storage medium

Abstract

The application relates to a dispatch monitoring method, a system, a device and a storage medium. The dispatch monitoring method is applied to a service layer in a dispatch monitoring system, the service layer is in communication connection with an external user terminal layer, and the method comprises the following steps: in response to a monitoring request of a dispatch station in the user terminal layer, determining a current session state of a target object corresponding to the monitoring request; if the current session state of the target object is not a real session, establishing a virtual session between the service layer and the dispatch station and pointing to the target object; forwarding the virtual session to the dispatch station; after receiving a session establishment request sent by the target object, generating a real session of the target object based on the virtual session, and forwarding the real session to the dispatch station for processing. The application can initiate a monitoring request for a target object without establishing a real session, avoids the limitation that a monitoring function in a traditional scheme depends on real session establishment, eliminates a monitoring blind area caused by the target object not initiating a call, and realizes comprehensive monitoring.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a scheduling monitoring method, system, device and storage medium. Background Technology

[0002] In mission-critical communication scenarios, audio and video communication monitoring is an important means of ensuring mission supervision, emergency response, and post-event traceability. It is an important extension of the scheduling function, providing relevant personnel with real-time communication situation control and helping to advance the mission efficiently.

[0003] In current critical communication practices, such as broadband trunking communication systems represented by MCX (Mission Critical X), the mainstream implementation scheme for dispatch console audio and video communication monitoring is based on the call establishment process of the trunking communication network to achieve real-time monitoring of target terminals or groups. Specifically, the dispatch console (the monitoring initiator) presets the target terminal number or group identifier to be monitored through the system configuration interface and submits the monitoring configuration information to the core control node of the trunking communication system. The core control node verifies the monitoring permission and saves the monitoring configuration after successful verification. When the core control node detects that the target terminal or group to be monitored has initiated a call and established a communication session, the monitoring mechanism is triggered.

[0004] However, in the aforementioned existing technical solutions, the triggering of the listening function is bound to the "establishment of a real session," meaning that it can only listen to established sessions and cannot support target listening to sessions that have not been established, resulting in incomplete coverage of listening scenarios. Summary of the Invention

[0005] This application provides a scheduling monitoring method, system, device, and storage medium, aiming to solve the problem that traditional technologies can only monitor established sessions and cannot support target monitoring of unestablished sessions, resulting in incomplete coverage of monitoring scenarios.

[0006] In a first aspect, embodiments of this application provide a scheduling monitoring method applied to the service layer of a scheduling monitoring system, wherein the service layer communicates with an external user-side terminal layer, and the method includes: In response to a listening request from the dispatch console in the user-side terminal layer, determine the current session state of the target object corresponding to the listening request; If the current session state of the target object is no real session established, then a virtual session pointing to the target object is established between the service layer and the dispatch console; Forward the virtual session to the dispatch console; Upon receiving a session establishment request from the target object, a real session for the target object is generated based on the virtual session, and the real session is forwarded to the dispatch console for processing.

[0007] Its further technical solution is to generate a real session for the target object based on a virtual session, including: Obtain the initial session identifier corresponding to the virtual session; Use the initial session identifier as the target session identifier to generate the real session for the target object.

[0008] A further technical solution involves forwarding the virtual session to the dispatch console, including: Obtain the target object's identification information and monitoring identifier; Based on the target object's identification information and listening identifier, generate the target empty data packet for the virtual session; Forward the target empty data packet to the dispatch console.

[0009] A further technical solution involves generating a target empty data packet for a virtual session based on the target object's identification information and listening identifier, including: Construct an empty data packet; The target object's identification information and listening identifier are embedded in the preset fields of the header of the empty data packet to obtain the target empty data packet of the virtual session.

[0010] Its further technical solution is to forward the real session to the dispatch console for processing, including: Copy the data packets of the real session; The target data packet is obtained by embedding the target object's identification information and listening identifier into the data packet of the real session; Based on the target data packet, the plaintext data packet to be forwarded is obtained; The plaintext data packets to be forwarded are forwarded to the dispatch console for processing.

[0011] A further technical solution involves determining the current session state of the target object corresponding to the listening request, and the method further includes: If the target object's current session state is an established real session, then copy the data packets of the real session; The target data packet is obtained by embedding the target object's identification information and listening identifier into the data packet of the real session; Based on the target data packet, the plaintext data packet to be forwarded is obtained; The plaintext data packets to be forwarded are forwarded to the dispatch console for processing.

[0012] Its further technical solution is that the target object is an ordinary user or an encrypted user, and based on the target data packet, a plaintext data packet to be forwarded is obtained, including: If the target is a regular user, the target data packet is directly treated as a plaintext data packet to be forwarded. If the target is an encrypted user, the target data packet is decrypted to obtain the plaintext data packet to be forwarded.

[0013] A further technical solution involves decrypting the target data packet to obtain the plaintext data packet to be forwarded, including: Use the built-in key management function to obtain the decryption key; The target data packet is decrypted using the decryption key to obtain the plaintext data packet to be forwarded.

[0014] A further technical solution involves forwarding the plaintext data packets to be forwarded to the dispatch console for processing, including: Forward the plaintext data packets to be forwarded to the dispatch console; The dispatch console is used to decode, play, and store plaintext data packets.

[0015] Secondly, this application provides a scheduling monitoring system, which includes a service layer that is communicatively connected to an external user-side terminal layer. The service layer is used to implement the steps of any of the scheduling monitoring methods described above.

[0016] Thirdly, this application provides a scheduling monitoring device, comprising: a processor, a memory, and a communication interface, wherein the processor is coupled to the memory and the communication interface; Memory, used to store computer instructions; A processor is used to execute computer programs or computer instructions stored in memory, causing the scheduling listening device to perform any of the methods described above.

[0017] Fourthly, this application provides a computer-readable storage medium for storing a computer program, which, when executed, is specifically used to implement the method described in any of the above.

[0018] Compared with the prior art, the beneficial effects of this application are as follows: This application achieves "pre-positioning" of the listening link by pre-constructing a virtual session (i.e., a pre-set listening channel) between the service layer and the dispatch console when the target object has not established a real session. Based on this, the dispatch console can initiate listening requests for target objects that have not established a real session, avoiding the limitation of the traditional solution where the listening function depends on the establishment of a real session, eliminating the listening blind spot caused by the target object not initiating a call, and realizing comprehensive listening in all scenarios.

[0019] Meanwhile, when the target object initiates a session establishment request, the service layer can generate a real session based on the virtual session, effectively avoiding the interaction time consumption caused by establishing a real session and then listening in the traditional solution, reducing listening latency and improving the system's response efficiency. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0023] Figure 1 A schematic diagram of the microservice architecture provided for this application; Figure 2 A flowchart illustrating a first embodiment of a scheduling and monitoring method provided in this application; Figure 3 This is a schematic diagram of a scheduling and monitoring device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0026] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0027] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0028] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0030] To address the aforementioned issues, this application provides a scheduling monitoring method, system, device, and storage medium. The scheduling monitoring method is applied to the service layer of the scheduling monitoring system and can initiate monitoring requests for target objects that have not established a real session. This avoids the limitation of traditional solutions where the monitoring function depends on the establishment of a real session, eliminates the monitoring blind spot caused by the target object not initiating a call, and achieves comprehensive monitoring.

[0031] First, the scheduling and monitoring system provided in this application embodiment will be introduced. This scheduling and monitoring system can be based on an MCX broadband trunking communication system, or other public network trunking communication systems (PoC) or private network communication systems with multimedia scheduling functions. For ease of explanation, the following will use an MCX broadband trunking communication system as an example to describe the scheduling and monitoring method in detail. This method is built using a microservice architecture; see [link to relevant documentation]. Figure 1 The overall system architecture is logically divided into two major modules: the user-side terminal layer and the MCX core service layer. The two modules communicate with each other through an IP network, and the modules work together to complete the function of monitoring encrypted audio and video communication.

[0032] Among them, the user-side terminal layer serves as the entry point for human-computer interaction and the initiator of communication services. It includes three types of terminal roles with different functions, all of which access the MCX core service layer through the IP network.

[0033] Specifically, the dispatch console user, as the initiator of the monitoring request, possesses the corresponding monitoring permissions. The dispatch console user initiates the audio / video monitoring request by inputting the identification information of the target to be monitored (such as user number or group number) through the terminal interface. In addition, the dispatch console user is also responsible for receiving monitoring data packets forwarded by the service layer, and for decoding, playing, and storing them.

[0034] MCX encrypted users, as terminal entities participating in encrypted audio and video sessions, transmit their communication data using end-to-end encryption. These users rely on the key management and encryption / decryption functions of the MCX broadband trunking communication system to ensure the security of the communication process.

[0035] As terminal entities participating in unencrypted audio and video sessions, ordinary MCX users transmit their communication data in plaintext form within the MCX broadband trunking communication system.

[0036] The MCX core service layer is deployed using a microservice architecture, comprising basic business microservices supporting the listening function and core microservices related to listening. Each component is decoupled and operates independently yet collaboratively, jointly undertaking the core responsibilities of business logic processing and data forwarding.

[0037] Among them, the basic business microservices provide the system with general communication capabilities, including but not limited to MCPTT service, MCVideo service and MCData service.

[0038] Specifically, the MCPTT service provides one-click voice session management capabilities for mission-critical tasks, responsible for the establishment, maintenance, and termination of voice sessions. The MCVideo service provides video session management capabilities for mission-critical tasks, responsible for the establishment, maintenance, and termination of video sessions. The MCData service provides data service support capabilities for mission-critical tasks, responsible for the transmission and management of non-audio and video data.

[0039] The core microservices related to monitoring are key components for implementing the technical solution of this invention, including but not limited to monitoring functions, key management functions, and encryption / decryption functions.

[0040] Specifically, the monitoring function, as the core scheduling monitoring microservice, is responsible for handling monitoring requests from users on the scheduling console. This function performs real-time queries on the target session status: for established sessions, it directly performs full data packet copying; for unestablished sessions, it generates virtual sessions as placeholders and replaces them after the session is established. Simultaneously, this function embeds target identifiers and monitoring tags into the data packets to complete the targeted forwarding of monitoring data.

[0041] The key management function is mainly responsible for the full lifecycle management of encrypted session keys in the MCX broadband trunking communication system, including key generation, storage, and distribution, providing the necessary key acquisition capabilities for encrypted communication monitoring.

[0042] The encryption / decryption function relies on the key provided by the key management function to decrypt encrypted audio and video data packets. This function directly forwards the decrypted plaintext data packets to the dispatch console user, ensuring that the dispatch console can obtain plaintext data that can be directly decoded and played, thereby achieving efficient encrypted communication monitoring.

[0043] See Figure 2 , Figure 2 This is a flowchart illustrating a first embodiment of a scheduling and monitoring method provided in this application. The scheduling and monitoring method includes the following steps: Step 110: In response to a listening request initiated by an external dispatch console, determine the current session state of the target object corresponding to the listening request.

[0044] The dispatch console can initiate listening requests to the service layer through a graphical user interface (GUI) or a command-line interface (CLI).

[0045] For example, the command-line interface-based listening method can use text commands to interact with the system. Specifically, the scheduler enters key parameters such as the target object's identifier, listening mode, priority, and duration in the terminal window or a specified input field, and sends the encapsulated listening request to the service layer by executing commands (such as pressing Enter to confirm or running a script).

[0046] When the target is a single terminal, an individual call identifier (such as user identity identifier, IP address or device serial number) can be entered.

[0047] When the target is a group, you can enter a group call identifier to monitor the group call communication of the entire group.

[0048] In some embodiments, a local query mechanism can be used to determine the current session state of the target object corresponding to the listening request. Specifically, the target object is used as an index to retrieve its associated target session: if the target session is successfully retrieved, it is determined that the target object has established a real session; otherwise, if no related target session is retrieved, it is determined that the target object has not yet established a real session.

[0049] Step 120: If the current session state of the target object is no real session established, then establish a virtual session between the service layer and the dispatch console that points to the target object.

[0050] The virtual session is a logical communication link established between the dispatch console and the service layer, pointing to the target object. Before the target object comes online, the logical communication link is in a virtual connection state; when the target object is detected to be online, the logical communication link is connected to the target object's media address.

[0051] Step 130: Forward the virtual session to the dispatch console.

[0052] Step 140: After receiving the session establishment request sent by the target object, generate a real session for the target object based on the virtual session, and forward the real session to the dispatch console for processing.

[0053] In other words, after receiving a session establishment request from the target object, the service layer triggers the real session establishment process and generates the target object's real session based on the existing virtual session.

[0054] Specifically, the service layer can keep the logical communication link (including transport layer connection and session identifier) ​​established by the virtual session unchanged; and inject the real-time media stream (such as voice / video stream) generated by the target object in the real session into the logical communication link for transmission.

[0055] This embodiment achieves "pre-positioning" of the listening link by pre-constructing a virtual session (i.e., a pre-set listening channel) between the service layer and the dispatch console for the target object when no real session has been established. When the target object initiates a session establishment request, the service layer can generate a real session based on the virtual session, effectively avoiding the interaction time caused by establishing a real session and then listening in the traditional solution, reducing listening latency, and improving the system's response efficiency.

[0056] Meanwhile, the establishment of virtual sessions enables the dispatch console to initiate listening requests to target objects that have not established real sessions, avoiding the limitation of traditional solutions where the listening function depends on the establishment of real sessions, eliminating listening blind spots caused by the target object not initiating a call, and achieving comprehensive listening.

[0057] Referring to a second embodiment of a scheduling and monitoring method provided in this application, the scheduling and monitoring method includes the following steps: Step 210: In response to a listening request initiated by an external dispatch console, determine the current session state of the target object corresponding to the listening request.

[0058] Step 220: If the current session state of the target object is no real session established, then establish a virtual session between the service layer and the dispatch console that points to the target object.

[0059] Step 230: Forward the virtual session to the dispatch console.

[0060] Step 240: After receiving the session establishment request sent by the target object, obtain the initial session identifier corresponding to the virtual session.

[0061] Step 250: Use the initial session identifier as the target session identifier to generate the real session of the target object.

[0062] Among them, the Session ID is a unique transmission channel ID assigned to each service by the scheduling and monitoring system.

[0063] In traditional methods, the system typically needs to randomly assign a session identifier to each newly established real session. However, this embodiment, upon receiving a session establishment request from the target object, uses the initial session identifier as the target session identifier for that session, directly referencing the pre-established initial session identifier of the virtual session. This allows subsequent real data streams to be directly directed to the transmission path originally reserved for the virtual session, eliminating the need for randomly assigning a new session identifier. This saves the time-consuming process of reallocating a new channel ID and establishing a transmission path in traditional methods, thereby improving the response efficiency of the monitoring.

[0064] For specific implementation details of steps 210, 220 and 230, please refer to the relevant content of the first embodiment, which will not be repeated here.

[0065] Referring to a third embodiment of the scheduling and monitoring method provided in this application, the scheduling and monitoring method includes the following steps: Step 310: In response to a listening request initiated by an external dispatch console, determine the current session state of the target object corresponding to the listening request.

[0066] Step 320: If the current session state of the target object is no real session established, then establish a virtual session between the service layer and the dispatch console that points to the target object.

[0067] Step 330: Obtain the target object's identification information and listening identifier.

[0068] The target object's identification information is used to uniquely identify the object being monitored, and this identification information may include identity credentials at different levels.

[0069] For example, the identification information can be a physical layer identity credential, such as an International Mobile Subscriber Identity (IMSI) assigned by the operator; or, the identification information can be a network layer or service layer identifier (such as an MCX broadband trunking communication system account or mobile phone number).

[0070] Furthermore, the target object can be a single user or a user group consisting of multiple users. When the target object is a user group, the identification information can be a group identity (GID) used to uniquely identify the group.

[0071] The listening identifier is used to identify that the data packet is listening service data.

[0072] Step 340: Generate a target empty data packet for the virtual session based on the target object's identification information and listening identifier.

[0073] In some embodiments, step 340 may include sub-steps 341 and 342: Sub-step 341: Construct an empty data packet.

[0074] An empty data packet can refer to a data packet with an empty data payload.

[0075] Sub-step 342: Embed the target object's identification information and listening identifier in the preset fields of the header of the empty data packet to obtain the target empty data packet of the virtual session.

[0076] In some embodiments, a network layer adaptive strategy can be adopted to embed the target object's identification information and listening identifier in the corresponding protocol layer of the data packet, depending on the user's actual network environment (Layer 2 network or Layer 3 network).

[0077] Specifically, when a user is detected to be in a Layer 2 network environment, the target object's identification information and listening identifier can be embedded in the header extension field of the Real-time Transport Protocol (RTP).

[0078] When it is detected that a user is in a Layer 3 network environment, or that the user is configured to transmit based on IP routing, the identification information of the target object and the listening identifier can be embedded in the extension header or option field of the IP packet.

[0079] Step 350: Forward the target empty data packet to the dispatch console.

[0080] In some embodiments, the service layer may forward target empty data packets to the dispatch console according to a preset period.

[0081] The preset period can be adjusted and set according to the session timeout set by the session management function, such as 20 minutes, 25 minutes or 30 minutes, etc., which is not limited in this application.

[0082] After a virtual session is established, if there is no actual business data transmission for an extended period, the virtual session may be deemed idle by the session management function and forcibly terminated. To address this issue, the service layer can periodically send empty data packets carrying a specific identifier to the dispatch console. This simulates continuous data interaction, maintains the activity of the virtual session, prevents abnormal interruption due to timeout, and effectively conserves system resources, thereby ensuring a stable communication link connection.

[0083] Step 360: After receiving the session establishment request sent by the target object, generate a real session for the target object based on the virtual session, and forward the real session to the dispatch console for processing.

[0084] For specific implementation details of steps 310, 320 and 360, please refer to the relevant content of the first embodiment, which will not be repeated here.

[0085] In some embodiments, the real session is forwarded to the dispatch console for processing, including steps 410-440.

[0086] Step 410: Copy the data packets of the real session.

[0087] Step 420: Embed the target object's identification information and listening identifier into the data packet of the real session to obtain the target data packet.

[0088] The target object's identification information and the listening identifier are the identifiers carried in the empty data packets of the virtual session.

[0089] For details on the specific embedding location of the identification information and the listening identifier in the real session data packets, please refer to the setting method in the empty data packets, which will not be repeated here.

[0090] Because virtual sessions are pre-bound to specific target objects, the service layer can directly reuse the identification information and listening identifier carried in the virtual session to associate and bind the real session with that target object. This approach leverages the inherent target-oriented nature of virtual sessions to ensure a precise correspondence between the real session and the target object, while eliminating the need to reallocate the listening identifier during real session establishment, thus achieving seamless integration between session establishment and listening tasks.

[0091] Step 430: Based on the target data packet, obtain the plaintext data packet to be forwarded.

[0092] This embodiment employs a "packet copy-and-forward" mode, abandoning the traditional architecture that relies on independent monitoring control nodes or proxy servers, eliminating the need to establish dedicated monitoring sessions or additional links. This approach significantly simplifies the system architecture, reduces deployment and maintenance costs, and effectively improves the real-time performance and stability of monitoring data transmission.

[0093] In one embodiment, the target object is a regular user or an encrypted user. The service layer can identify and determine the user's identity type based on the specific information carried in the session request initiated by the user.

[0094] In step 430, based on the target data packet, the plaintext data packet to be forwarded is obtained, including: 1) If the target is a regular user, the target data packet is directly treated as a plaintext data packet to be forwarded.

[0095] In this embodiment, since the session corresponding to a regular user does not use an encryption mechanism, the payload data in the target data packet it transmits is itself in plaintext form. Therefore, it can be directly treated as a plaintext data packet to be forwarded for subsequent processing.

[0096] Specifically, the monitoring process for ordinary users mainly includes four stages: the monitoring request initiation stage, the session state processing stage, the data packet processing and forwarding stage, and the dispatch console receiving and processing stage.

[0097] During the monitoring request initiation phase, the dispatch console user enters the user number or group number of the target object to be monitored in the operation interface, and initiates an audio and video monitoring request to complete the submission of the monitoring task.

[0098] During the session state processing phase, after receiving a listening request, the MCX broadband trunking communication system queries whether a corresponding target session exists in the MCPTT / MCVideo service. If a target session is found, it directly proceeds to the subsequent data packet processing flow. If no target session is found, a virtual session is automatically generated and the target user's status is continuously monitored. Once the target user establishes a new MCPTT / MCVideo session, the virtual session is automatically replaced with the real session, and then the subsequent data packet processing flow begins.

[0099] During the packet processing and forwarding phase, the MCX broadband trunking communication system copies the full audio and video data packets of the target session and embeds a target identifier (used to distinguish the monitored user / group) and a monitoring tag into the data packets. Subsequently, the MCX broadband trunking communication system sends the processed monitoring data packets to the dispatch console user who initiated the request.

[0100] During the dispatch console's receiving and processing phase, after receiving the monitoring data packet, the dispatch console user confirms that it is monitoring service data by parsing the monitoring marker in the data packet, and matches the corresponding monitored user / group using the target identifier. Subsequently, the dispatch console decodes the data packet, plays the audio and video content, and saves the monitoring data packet for later tracing. The monitoring task ends when the dispatch console user actively ends the monitoring or the target session terminates.

[0101] 2) If the target object is an encrypted user, the target data packet is decrypted to obtain the plaintext data packet to be forwarded.

[0102] Because the session corresponding to the encrypted user uses an encryption protection mechanism, the target data packet it transmits is ciphertext data. The system needs to use the corresponding decryption key to decrypt and restore the target data packet, extract the original payload, and thus obtain the plaintext data packet to be forwarded.

[0103] In one embodiment, the target data packet is decrypted to obtain a plaintext data packet to be forwarded, including: 2-1) Use the built-in key management function to obtain the decryption key.

[0104] 2-2) Use the decryption key to decrypt the target data packet to obtain the plaintext data packet to be forwarded.

[0105] In some embodiments, the MCX service layer integrates a key management service module and an encryption / decryption function module.

[0106] First, after the MCX service layer identifies the target object as an encrypted user, it can send a key retrieval request to the key management service module through a predefined interface. This request carries a user identifier or session identifier associated with the encrypted user. Subsequently, the key management service module retrieves the key index matching the encrypted user from the secure storage area based on the received identifier information and retrieves the corresponding decryption key. By calling the built-in functions of the MCX service layer, the key retrieval process is ensured to occur in a trusted execution environment, thereby guaranteeing the security of the key itself.

[0107] After successfully obtaining the decryption key, the encryption / decryption module uses the key to decrypt the target data packet, thus obtaining the plaintext data packet to be forwarded. In practice, the ciphertext payload portion of the target data packet can be read first, and a preset decryption algorithm (such as an end-to-end decryption algorithm or a national cryptographic algorithm) can be loaded. Next, the obtained decryption key is input into the decryption algorithm to perform reverse operations and restore the ciphertext payload. After processing by the decryption algorithm, the originally unreadable encrypted data is converted into a readable raw data stream. This raw data stream is then repackaged to generate the plaintext data packet to be forwarded, thus completing the conversion from ciphertext to plaintext.

[0108] Specifically, the monitoring process for encrypted users mainly includes the monitoring request initiation stage, session state processing stage, data packet copying stage, data packet decryption and forwarding stage, and dispatch console receiving and processing stage.

[0109] During the monitoring request initiation phase, the dispatch console user enters the user number or group number of the target object to be monitored in the operation interface, and initiates an audio and video monitoring request to complete the submission of the monitoring task.

[0110] During the session state processing phase, after receiving a listening request, the MCX broadband trunking communication system queries whether a corresponding target session exists in the MCPTT / MCVideo service. If a target session is found, it directly proceeds to the subsequent data packet processing flow. If no target session is found, a virtual session is automatically generated and the target user's status is continuously monitored. Once the target user establishes a new MCPTT / MCVideo session, the virtual session is automatically replaced with the real session, and then the subsequent data packet processing flow begins.

[0111] During the data packet copying phase, the MCX broadband trunking communication system copies the full audio and video data packets of the target session and embeds the target identifier (used to distinguish the monitored user / group) and monitoring tag in the data packets.

[0112] During the packet decryption and forwarding phase, the system first invokes its own key management function to obtain the decryption key corresponding to the target encrypted session. Then, using this decryption key, it decrypts the encrypted data packet with the embedded identifier, thus obtaining the plaintext data packet to be forwarded. The MCX broadband trunking communication system then sends the processed listening data packet to the requesting dispatch console user.

[0113] For details regarding the specific implementation and interaction process of the key management function and decryption algorithm, please refer to the relevant statements in the above embodiments.

[0114] During the dispatch console's receiving and processing phase, after receiving the monitoring data packet, the dispatch console user confirms that it is monitoring service data by parsing the monitoring marker in the data packet, and matches the corresponding monitored user / group using the target identifier. Subsequently, the dispatch console decodes the data packet, plays the audio and video content, and saves the monitoring data packet for later tracing. The monitoring task ends when the dispatch console user actively ends the monitoring or the target session terminates.

[0115] Step 440: Forward the plaintext data packet to be forwarded to the dispatch console for processing.

[0116] Because the MCX broadband trunking communication system integrates key management and encryption / decryption functions, this embodiment eliminates the need for a dedicated relay decryption node. The decryption key can be directly obtained at the service layer to decrypt encrypted data packets, and the restored plaintext data can then be directly pushed to the dispatch console. This approach ensures that the dispatch console can directly decode and play audio and video data, while effectively avoiding transmission delays and potential data leakage risks introduced by multiple relay stages. This significantly improves the real-time response capability and overall security of encrypted monitoring services.

[0117] In one embodiment, step 440, which forwards the plaintext data packet to be forwarded to the dispatch console for processing, includes: 1) Forward the plaintext data packets to be forwarded to the dispatch console; 2) Use the dispatch console to decode, play, and store plaintext data packets.

[0118] Upon receiving a plaintext data packet, the dispatch console first identifies the monitoring marker by parsing its extended fields, thus determining that the packet is a monitoring packet. Based on the identification information (such as UID / GID), it accurately matches and displays the information of the target object. Furthermore, the dispatch console decouples the audio and video streams within the plaintext data packet, calling the corresponding decoder according to the encoding format indicated in the data header. For example, for audio data, the dispatch console calls an audio decoding algorithm to restore it to an analog signal and outputs it through a playback device; for video data, it decodes video frames and renders them in real time on the display interface, thereby completing the playback of the monitored content.

[0119] In addition, the storage management module of the dispatch console can store the received plaintext data packets according to a preset storage strategy, thereby completing the decoding, playback and storage processing of the plaintext data packets.

[0120] The foregoing embodiments mainly address scenarios where the target object has not established a real session, illustrating the processing flow for constructing a virtual session. In other embodiments, if the target object's current session state is detected as "a real session has been established," then the data packets of that real session can be directly copied and forwarded. See the steps of the following fourth embodiment for details: Step 510: In response to the listening request from the dispatch console in the user-side terminal layer, determine the current session state of the target object corresponding to the listening request.

[0121] Step 520: If the target object's current session state is an established real session, then copy the data packets of the real session.

[0122] Step 530: Embed the target object's identification information and listening identifier into the data packet of the real session to obtain the target data packet.

[0123] Step 540: Based on the target data packet, obtain the plaintext data packet to be forwarded.

[0124] Step 550: Forward the plaintext data packet to be forwarded to the dispatch console for processing.

[0125] For steps 530-550, the specific processing details can be found in the relevant content of steps 420-440 in the aforementioned embodiments, and will not be repeated here.

[0126] This application can generate a virtual session when a real session has not been established, and automatically replace the virtual session with the real session after the target object initiates a real session. It can also directly monitor established real sessions in real time, thus achieving comprehensive monitoring of "existing sessions + unestablished sessions".

[0127] The scheduling and monitoring method provided in this application can be widely applied to various fields with high requirements for communication security and real-time performance, including but not limited to public safety and emergency command, energy and critical infrastructure operation and maintenance, and government affairs and large-scale event security.

[0128] Taking the field of public safety and emergency command as an example, this method is applicable to the communication monitoring needs of public security, fire protection, and emergency management departments in their daily duties and emergency response. Specifically, the dispatch console can initiate listening requests for MCPTT voice or MCVideo video conversations with frontline police officers or firefighters at any time. Even if the target user has not yet established a communication session, the system can automatically generate a virtual session and continuously monitor it; once the target user initiates a call, the listening will automatically connect immediately, thereby achieving all-weather, seamless monitoring of the duty status.

[0129] Especially in emergency command scenarios such as major disasters, accidents, and mass incidents, the command center can monitor the encrypted audio and video communications of on-site response teams in real time. Relying on the key management and decryption capabilities of the MCX broadband trunking communication system, the dispatch console can directly obtain the decrypted plaintext audio and video data, thereby quickly grasping the on-site situation, accurately issuing command instructions, and simultaneously retaining the monitoring data for post-event review and analysis and responsibility determination.

[0130] Taking the field of energy and critical infrastructure operation and maintenance as an example, the scheduling and monitoring method provided in this application embodiment can be widely applied to industries such as power, oil, gas, and rail transportation, meeting the needs of on-site operation supervision and remote operation and maintenance management.

[0131] Specifically, in the operation monitoring scenario, the dispatch console can listen to encrypted voice or video calls of on-site operation and maintenance personnel in real time, thereby supervising the standardization of the operation process and ensuring that high-risk operations such as high-pressure maintenance and pipeline inspection strictly follow safety standards.

[0132] A virtual session can be established in advance before the operation and maintenance personnel establish a session. When the operation and maintenance personnel start the communication session, the monitoring function will automatically connect to achieve seamless supervision of the entire operation process.

[0133] In addition, when equipment or lines fail, maintenance personnel can retrieve historical monitoring data to reconstruct the on-site communication content and operation process at the time of the failure, thereby quickly locating the root cause of the problem and effectively preventing the scope of the failure from expanding due to information asymmetry.

[0134] Taking the field of government affairs and large-scale event security as an example, the scheduling and monitoring method provided in this application embodiment can be widely applied to scenarios such as daily government affairs duty, security and on-site scheduling of large-scale events and exhibitions.

[0135] Specifically, during large-scale events, the security command center can monitor encrypted communications at various duty points in real time to keep track of the deployment and dynamic changes of personnel on site, ensuring that temporary emergency response teams can also be included in the monitoring scope in a timely manner, thereby enabling rapid response and precise dispatch in the event of an emergency.

[0136] In addition, the dispatch console for government affairs can monitor encrypted work sessions between departments to ensure the smooth transmission of government orders. Simultaneously, the system can record and archive important meetings or key procedures, providing data support for subsequent work verification and compliance audits.

[0137] Thus, this application effectively overcomes the problems of limited scenario coverage, insufficient adaptation to encrypted eavesdropping, and cumbersome system architecture in existing technologies. By constructing an efficient, secure, and reliable eavesdropping system, it provides efficient, secure, and reliable eavesdropping capabilities for the aforementioned critical mission scenarios such as public safety, emergency command, and energy operation and maintenance. Furthermore, it provides strong support for business processes such as daily supervision, emergency response, and post-event traceability, thereby powerfully promoting the optimization and upgrading of critical communication scheduling eavesdropping technology.

[0138] like Figure 3 As shown, this application embodiment provides a scheduling monitoring device, including a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111 and the communication interface 112 are coupled to the memory 113 and the communication interface 112, and communicate with each other through the communication bus 114. Memory 113 is used to store computer instructions; Processor 111 is configured to execute computer programs or computer instructions stored in memory 113 to implement the scheduling monitoring method provided in any of the foregoing method embodiments, including: In response to a listening request from the dispatch console in the user-side terminal layer, determine the current session state of the target object corresponding to the listening request; If the current session state of the target object is no real session established, then a virtual session pointing to the target object is established between the service layer and the dispatch console; Forward the virtual session to the dispatch console; Upon receiving a session establishment request from the target object, a real session for the target object is generated based on the virtual session, and the real session is forwarded to the dispatch console for processing.

[0139] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0140] Therefore, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the scheduling and monitoring method provided in any of the foregoing method embodiments, including: In response to a listening request from the dispatch console in the user-side terminal layer, determine the current session state of the target object corresponding to the listening request; If the current session state of the target object is no real session established, then a virtual session pointing to the target object is established between the service layer and the dispatch console; Forward the virtual session to the dispatch console; Upon receiving a session establishment request from the target object, a real session for the target object is generated based on the virtual session, and the real session is forwarded to the dispatch console for processing.

[0141] Storage media are physical, non-transitory storage media, such as USB flash drives, external hard drives, read-only memory (ROM), magnetic disks, or optical disks—various physical storage media capable of storing program code. Computer-readable storage media can be non-volatile or volatile.

[0142] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0143] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0144] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0145] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all 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, a terminal, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0146] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0147] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Since these modifications and variations fall within the scope of the claims and their equivalents, this application also intends to include these modifications and variations.

[0148] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of scheduling a listening, characterized by, A service layer applied in a scheduling and monitoring system, wherein the service layer communicates with an external user-side terminal layer, the method comprising: In response to a listening request from the dispatch console in the user-side terminal layer, determine the current session state of the target object corresponding to the listening request; If the current session state of the target object is no real session established, then a virtual session is established between the service layer and the dispatch console, pointing to the target object; Forward the virtual session to the dispatch console; Upon receiving a session establishment request from the target object, a real session for the target object is generated based on the virtual session, and the real session is forwarded to the dispatch console for processing.

2. The method of claim 1, wherein, The process of generating a real session for the target object based on the virtual session includes: Obtain the initial session identifier corresponding to the virtual session; The initial session identifier is used as the target session identifier to generate the real session of the target object.

3. The method of claim 1, wherein, The step of forwarding the virtual session to the dispatch console includes: Obtain the identification information and listening identifier of the target object; Based on the identification information and listening identifier of the target object, a target empty data packet for the virtual session is generated; The target empty data packet is forwarded to the dispatch console.

4. The method of claim 3, wherein, The step of generating the target empty data packet for the virtual session based on the identification information and listening identifier of the target object includes: Construct an empty data packet; The target object's identification information and listening identifier are embedded in the preset fields of the header of the empty data packet to obtain the target empty data packet of the virtual session.

5. The method of claim 4, wherein, The step of forwarding the real session to the dispatch console for processing includes: Copy the data packets of the actual session; The target data packet is obtained by embedding the identification information and listening identifier of the target object into the data packet of the real session; Based on the target data packet, the plaintext data packet to be forwarded is obtained; The plaintext data packet to be forwarded is forwarded to the dispatch console for processing.

6. The method of claim 1, wherein, After determining the current session state of the target object corresponding to the listening request, the method further includes: If the current session state of the target object is an established real session, then copy the data packets of the real session; The target data packet is obtained by embedding the identification information and listening identifier of the target object into the data packet of the real session; Based on the target data packet, the plaintext data packet to be forwarded is obtained; The plaintext data packet to be forwarded is forwarded to the dispatch console for processing.

7. The method according to any one of claims 5-6, characterized in that, The target object is a regular user or an encrypted user. The process of obtaining the plaintext data packet to be forwarded based on the target data packet includes: If the target object is a regular user, then the target data packet is directly used as a plaintext data packet to be forwarded; If the target object is an encrypted user, the target data packet is decrypted to obtain a plaintext data packet to be forwarded.

8. The method of claim 7, wherein, The process of decrypting the target data packet to obtain the plaintext data packet to be forwarded includes: Use the built-in key management function to obtain the decryption key; The target data packet is decrypted using the decryption key to obtain the plaintext data packet to be forwarded.

9. The method of claim 7, wherein, The step of forwarding the plaintext data packet to be forwarded to the dispatch console for processing includes: Forward the plaintext data packet to be forwarded to the dispatch console; The dispatch console is used to decode, play, and store the plaintext data packets.

10. A dispatch monitoring system characterized by comprising: The scheduling and monitoring system includes a service layer that is communicatively connected to an external user-side terminal layer. The service layer is used to implement the steps of the scheduling and monitoring method as described in any one of claims 1 to 9.

11. A dispatch monitoring apparatus characterized by comprising: It includes: a processor, a memory, and a communication interface, wherein the processor is coupled to the memory and the communication interface; The memory is used to store computer instructions; The processor is configured to execute a computer program or computer instructions stored in the memory, causing the scheduling monitoring device to perform the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, Used to store a computer program, which, when executed, is specifically used to implement the method as described in any one of claims 1 to 9.

Images