Cpe unified operations service method, platform, and medium

Abstract

The present disclosure provides a CPE unified operation service method, device and medium, relates to the technical field of communication, and is used for solving the problem of unified operation service of multiple sources of CPE. The method comprises the following steps: receiving a CPE device type created by an operator, generating a typeKey and a typeSecret, and sending the typeKey and the typeSecret to the operator, so as to solidify the typeKey, the typeSecret and a deviceKey in the CPE device; receiving a deviceKey sent by the CPE device based on the typeKey and the typeSecret, generating a deviceSecret, and sending the deviceSecret to the CPE device, so that the CPE device solidifies the deviceSecret; receiving a typeKey and a data communication request sent by the CPE device based on the deviceKey and the deviceSecret, generating a server certificate or a token, and sending the server certificate or the token to the CPE device; and performing data communication with the CPE device based on the server certificate or the token. The present disclosure realizes unified operation service of multiple sources of CPE through the CPE device type, different keys of the CPE device and data communication.

Description

Technical Field

[0001] This disclosure relates at least to the field of communication technology, and in particular to a CPE unified operation service method, a CPE unified operation service platform, and a computer-readable storage medium. Background Technology

[0002] CPE (Customer Premise Equipment) refers to customer terminal equipment in a broad sense, mainly wireless terminal networking devices, such as portable WiFi (Wireless Fidelity), 5G (5th Generation Mobile Communication Technology) routers, 5G industrial CPEs, and wireless bridges. Currently, the use of CPEs is still in the stage of manually configuring equipment parameters, and different manufacturers use different communication protocols, making it difficult to clearly display the data transmitted by the equipment to users and making it difficult to locate problems. There are only deployment and maintenance examples for specific CPEs or specific scenarios on the market, and there are no unified CPE operation service platform examples.

[0003] There are many types of CPEs with different communication protocols. For many user companies and large suppliers, the unified maintenance and management of these devices is a problem that urgently needs to be solved, and there is currently no such solution. Summary of the Invention

[0004] The technical problem to be solved by this disclosure is to provide a unified operation service method, a unified operation service platform for CPE, and a computer-readable storage medium to address the above-mentioned shortcomings, so as to solve the problem of how to achieve unified operation service for multi-source CPEs.

[0005] In a first aspect, this disclosure provides a unified operation service method for Customer Premises Equipment (CPE), applied to a unified operation service platform for CPE, the method comprising:

[0006] Receive the CPE device type created by the operator, generate the CPE device type identifier typeKey and key typeSecret and send them to the operator so that the operator can embed typeKey, typeSecret and CPE device identifier deviceKey into the CPE device;

[0007] Receive the deviceKey sent by the CPE device based on typeKey and typeSecret, generate the deviceSecret key of the CPE device and send it to the CPE device so that the CPE device can fix the deviceSecret;

[0008] Receive the typeKey and data communication request sent by the CPE device based on deviceKey and deviceSecret, generate a server certificate or token for data communication with the CPE device, and send it to the CPE device;

[0009] Data communication with CPE devices is based on server certificates or tokens.

[0010] Secondly, this disclosure provides a unified operation service platform for Customer Premises Equipment (CPE), the platform comprising:

[0011] The type management module is used to receive the CPE device type created by the operator, generate the CPE device type identifier typeKey and key typeSecret and send them to the operator so that the operator can embed the typeKey, typeSecret and CPE device identifier deviceKey into the CPE device;

[0012] The device management module, connected to the type management module, is used to receive the deviceKey sent by the CPE device based on the typeKey and typeSecret, generate the deviceSecret key of the CPE device, and send it to the CPE device so that the CPE device can fix the deviceSecret.

[0013] The communication management module, connected to the device management module, is used to receive the typeKey and data communication request sent by the CPE device based on the deviceKey and deviceSecret, generate a server certificate or token for data communication with the CPE device, and send it to the CPE device.

[0014] The data communication module, connected to the communication management module, is used to communicate with the CPE device based on a server certificate or token.

[0015] Thirdly, this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the Customer Premises Equipment (CPE) unified operation service method as described above.

[0016] This disclosure provides a unified CPE operation service method, a unified CPE operation service platform, and a computer-readable storage medium. First, it manages CPE device types using a one-type-one-key approach. Then, it manages CPE devices under the corresponding CPE device type based on this one-type-one-key approach, configuring a device key for each CPE device to achieve one-device-one-key CPE device management. Finally, it manages CPE device data communication by configuring server certificates or tokens. Through different key configuration management schemes at different stages, it achieves unified management of the entire lifecycle of different types of CPE devices, from manufacturer matching and production to device delivery and use, ensuring the security of data transmission and reception throughout the entire process and realizing unified operation services for multi-source CPEs. Attached Figure Description

[0017] Figure 1 This is a flowchart of a CPE unified operation service method according to an embodiment of this disclosure;

[0018] Figure 2 This is a functional composition diagram of a CPE unified operation service platform according to an embodiment of the present disclosure;

[0019] Figure 3 This is a flowchart of a type-one-key pre-registration process for a CPE unified operation service method according to an embodiment of this disclosure;

[0020] Figure 4 This is a flowchart of a one-machine-one-key registration process for a CPE unified operation service method according to an embodiment of this disclosure;

[0021] Figure 5 This is a flowchart illustrating the CPE device installation process of a unified CPE operation service method according to an embodiment of this disclosure.

[0022] Figure 6 This is a flowchart illustrating the CPE device removal process of a CPE unified operation service method according to an embodiment of this disclosure;

[0023] Figure 7 This is a schematic diagram of the structure of a CPE unified operation service platform according to an embodiment of this disclosure. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions of this disclosure, the embodiments of this disclosure will be further described in detail below with reference to the accompanying drawings.

[0025] It is understood that the specific embodiments and accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this disclosure.

[0026] It is understood that, without conflict, the various embodiments and features in the embodiments of this disclosure can be combined with each other.

[0027] It is understood that, for ease of description, only the parts relevant to this disclosure are shown in the accompanying drawings, while parts unrelated to this disclosure are not shown in the drawings.

[0028] It is understood that each unit or module involved in the embodiments of this disclosure may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units or modules may be integrated into one entity structure.

[0029] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this disclosure may occur in a different order than that marked in the accompanying drawings.

[0030] It is understood that the flowcharts and block diagrams of this disclosure illustrate the architecture, functions, and operations of possible implementations of systems, apparatuses, devices, and methods according to various embodiments of this disclosure. Each block in a flowchart or block diagram may represent a unit, module, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagrams and flowcharts may be implemented using a hardware-based system to implement the specified function, or using a combination of hardware and computer instructions.

[0031] It is understood that the units and modules involved in the embodiments of this disclosure can be implemented by software or by hardware, for example, the units and modules can be located in a processor.

[0032] Example 1:

[0033] like Figure 1 As shown, this disclosure provides a unified operation service method for Customer Premises Equipment (CPE), applied to a unified operation service platform for CPEs. The method includes:

[0034] Receive the CPE device type created by the operator, generate the CPE device type identifier typeKey and key typeSecret and send them to the operator so that the operator can embed typeKey, typeSecret and CPE device identifier deviceKey into the CPE device;

[0035] Receive the deviceKey sent by the CPE device based on typeKey and typeSecret, generate the deviceSecret key of the CPE device and send it to the CPE device so that the CPE device can fix the deviceSecret;

[0036] Receive the typeKey and data communication request sent by the CPE device based on deviceKey and deviceSecret, generate a server certificate or token for data communication with the CPE device, and send it to the CPE device;

[0037] Data communication with CPE devices is based on server certificates or tokens.

[0038] In this embodiment, the CPE unified operation service platform may specifically include, for example: Figure 2 The functions shown can be divided into the perspectives of operators and users. Operators refer to platform administrators and maintenance personnel, such as CPE suppliers, while users refer to CPE-using enterprises and customers. The platform is primarily used to manage multi-source CPE devices. Considering the wide variety of CPE devices and the different management solutions for different types, the operators first register the CPE device types with the platform. For example, CPE device manufacturers register the types of CPE devices they produce with the platform. The platform generates a unique typeKey and typeSecret for each device type, used by the operators to manage CPE devices under that type. After the operators produce the corresponding CPE devices, the typeKey, typeSecret, and deviceKey are embedded in each CPE device. The CPE devices are then connected to the platform, and the device key is obtained from the platform for each CPE device based on the typeKey, typeSecret, and deviceKey. eSecret enables one-device-one-secret management of CPE devices. When a CPE device enters the user's usage state, the platform manages the CPE device, including collecting the CPE device's status data and sending management commands to the CPE device. For data communication during device use, a data communication connection is established by requesting typeKey, deviceKey, and deviceSecret. The platform manages the CPE device's data communication by configuring server certificates or tokens. Through different key configuration management schemes at different stages, unified management of the entire lifecycle of different types of CPE devices is achieved, from manufacturer matching and production to device delivery and device use. This ensures the security of data transmission and reception throughout the entire process and enables unified operation services for multi-source CPEs.

[0039] In one implementation, the deviceSecret is sent to the CPE device, specifically including:

[0040] The deviceSecret is sent to the CPE device using typeSecret encryption.

[0041] The server certificate or token is sent to the CPE device, specifically including:

[0042] The server certificate or token is sent to the CPE device using deviceSecret encryption.

[0043] In this embodiment, data transmission security between the platform and the user can be guaranteed based on existing technologies, while data transmission security between the platform and the CPE device is guaranteed based on different keys at different stages, such as... Figure 3 As shown, during the Type-1 Secret pre-registration phase, the security of data transmission and reception between the platform and the CPE device is ensured by using Type-1 Secret. Specifically, all data transmitted and received between the two is encrypted and decrypted using the TypeSecret. Figure 4 As shown, during the one-device-one-secret registration phase, the one-device-one-secret ensures the security of data transmission and reception between the platform and the CPE device, meaning that all data transmitted and received between the two is encrypted and decrypted using deviceSecret.

[0044] In one implementation, receiving the deviceKey sent by the CPE device based on the typeKey and typeSecret, and generating the CPE device's key deviceSecret, specifically includes:

[0045] The system receives the deviceKey, encrypted using typeSecret, sent by the CPE device based on typeKey, along with the operator's account and password. Upon successful verification of typeKey, typeSecret, deviceKey, and the operator's account and password, the system generates a key deviceSecret for the CPE device and records the correspondence between typeKey, typeSecret, deviceKey, deviceSecret, and the operator's account and password. The operator's account and password are provided to the operator in advance by the platform and are entered by the operator when connecting to the CPE device.

[0046] In this embodiment, as Figure 2As shown, the platform's functions include 2-a Platform Homepage, 2-b System Management, 2-c Device Management, 2-d Operation and Maintenance Monitoring, and 2-e Media Asset Management. Except for the marked viewpoints, all other functional modules in the diagram are viewable from all angles. The platform homepage specifically includes: Device Statistics, used to count and display the total number of CPE devices, their online / offline status, and operating status; Device Distribution, used to display the distribution of CPE devices by organization, time, etc.; and User Profiling, used to obtain user profiles for users and provide them to operators for analyzing product market demand. System Management specifically includes: User Management, used to create (including user-requested registration and platform-initiated activation) operator and user accounts and passwords, and manage users based on these accounts and passwords; Enterprise Account Management, used to display enterprise users using the operator's CPE devices to the operator for viewing; and Organization Management, used to allow operators and users to create their own subordinate organizations and grant some or all permissions within their own scope to these organizations. Equipment management specifically includes: equipment type management, used by operators to create their own CPE equipment types; equipment list functionality, used to display CPE equipment produced by operators to operators and CPE equipment installed and used by users; equipment registration functionality, used by operators to register CPE equipment types and CPE equipment before installation and use, and by users to register their own installed and used CPE equipment. Monitoring and maintenance specifically includes: after users install and use CPE equipment, the platform obtains CPE equipment operation logs, sends time-based notifications to CPE equipment, or completes data communication with CPE equipment through message queue consumption. Media asset management specifically allows users to place advertisements on their own CPE equipment.

[0047] The platform needs to enable user management and equipment type and equipment management for operators, specifically as follows: Figure 3As shown, in the one-type-one-key pre-registration process, the operator first completes its own user registration on the platform, obtaining the operator's account and password. Then, based on the permissions corresponding to the operator's account and password, it creates a device type and initiates device type pre-registration. The platform generates and records the unique identifier typeKey and key typeSecret for this CPE device type. Next, the operator selects a device type, creates the corresponding device, and fills in the unique identifier deviceKey (generally recommended to be the device serial number SN or MAC address). The platform saves the device information filled in by the user and records the correspondence between typeKey, deviceKey, and the operator. Afterward, the operator burns typeKey, typeSecret, and deviceKey onto the device. If the platform uses MQTTTS communication, it also configures the pre-downloaded platform root certificate. After completing the corresponding configuration, the device is powered on and connected. The network requests login to the platform using typeKey, typeSecret, and deviceKey. After the connection component is powered on, the operator's account and password can be entered into the device and included in the login request. MQTTS communication also carries the platform's root certificate. HTTPS communication establishes a TLS / SSL connection with the platform, requesting the corresponding register interface with the type triplet information (typeKey, typeSecret, deviceKey). The platform verifies typeKey, typeSecret, and deviceKey, and can also verify the operator's account and password and the platform's root certificate. If verification fails, the connection is rejected; if verification succeeds, the platform sends typeKey, deviceKey, and deviceSecret to the device, and the device permanently stores the deviceSecret, obtaining a unique password for each device.

[0048] In one implementation, verifying the typeKey, typeSecret, deviceKey, and the operator's account and password specifically includes:

[0049] Obtain the typeSecret based on the typeKey, and decrypt the typeSecret to obtain the deviceKey, as well as the operator's account and password;

[0050] Verify that the mapping between typeKey and deviceKey has been pre-created by the operator;

[0051] The verification of the correspondence between the deviceKey and the operator's account and password has been pre-recorded on the platform by the operator through the CPE device registration request.

[0052] In this embodiment, as Figure 2The system management shown can be implemented as follows: Initially, the platform has a top-level system administrator with all operational permissions. This administrator can create platform administrator users, enterprise accounts, and organizational structures, and can also modify or delete corresponding users, accounts, and organizations. To enhance security, the platform adopts a top-down hierarchical management model where administrators open enterprise accounts (automatically creating login users for them), and enterprise users create their own enterprise users after logging in. If enterprises require this, a self-registration function can be customized. Enterprise users need to submit necessary materials, select their affiliated enterprise, and the self-registration is considered successful after the enterprise administrator approves the application. Furthermore, for user, account, and organization management, to ensure that operations do not exceed authorized permissions, a "whoever creates, manages" model is adopted. For example, if administrator user A of an enterprise creates organizational structure B, sub-administrator C, and enterprise user D, and C creates organizational structure E and subordinate user F, then A has all operational permissions to modify, delete, and view B, C, D, E, and F; C has all operational permissions to modify, delete, and view E and F. Figure 2 The device management shown can be implemented as follows: The operations team can create, modify, and delete device types, and the page will refresh in real time to display the latest device type list. Each device type represents a product, and multiple devices can be registered for each type. After selecting a device type, the operations team can register devices individually or in batches. The only difference is that batch registration requires filling in multiple pieces of information in an Excel spreadsheet, which is then uploaded to the platform and submitted. The registered device list is visible to both the operations team and the users, and can be filtered by device type, device name, and online status. The list includes the device name, serial number (SN), and IMEI (International Mobile Equipment Identity). The number of devices that can be registered in a batch can be dynamically controlled between 100 and 1000, depending on the transmission protocol and system response time requirements. After registration on the platform, the devices are inactive. They will only become online after the devices are powered on and successfully authenticated and connected to the platform. Devices that have not reported data for a long time will become offline. Devices that have not been installed can also be deregistered (operators only). Download the template, fill in the corresponding device's IMEI number, and upload the file to deregister devices in batches.

[0053] In one implementation, the system receives a typeKey and a data communication request sent by a CPE device based on the deviceKey and deviceSecret, and generates a server certificate or token for data communication with the CPE device. Specifically, this includes:

[0054] The system receives a data communication request, a user account, and a password from a CPE device, encrypted with a deviceSecret based on the deviceKey. Upon successful verification of the deviceKey, deviceSecret, typeKey, and user account, the system generates a server certificate or token for data communication with the CPE device based on the data communication request. It also records that the deviceKey is installed and the mapping between the typeKey, deviceKey, deviceSecret, server certificate or token, and the user account and password. The user account and password are provided to the user by the platform beforehand and entered by the user when connecting to the CPE device.

[0055] More specifically, the platform needs to manage users and the devices installed and used by users. For example... Figure 4 As shown, in the one-device-one-key registration process, the user first completes their own user registration on the platform. The platform generates the user's account and password. The user fills in the identifier deviceKey of the device to be registered. The platform records the correspondence between deviceKey and user. At this time, the platform and the device already have typeKey, deviceKey, and deviceSecret obtained based on one-device-one-key. The device obtains typeKey, deviceKey, deviceSecret, and user account and password. If MQTTS-based communication is to be established, the platform's root certificate is also obtained. The user powers on the device, connects to the network, and requests to connect to the platform. The user's account and password can be entered into the device after powering on. The platform verifies typeKey, deviceKey, and deviceSecret. The connection requires the user's eclt and account password or platform root certificate. If the connection fails, it will be rejected; otherwise, data communication with the CPE device will proceed. The communication data carries a token or is based on a certificate. For MQTTS communication, the platform issues a server certificate after successful verification. The device verifies the server certificate and communicates data through a message subscription / publishing model. The device can directly report data. For HTTPS communication, the device sends a request to the corresponding auth interface with the device's triplet information (typeKey, deviceKey, deviceSecret). After successful platform authentication, a token will be returned. The token can be updated, for example, with a validity period of 3 days. Devices using HTTPS communication must send the corresponding token when reporting data. All connected devices can receive commands issued by the platform and perform corresponding operations.

[0056] In one implementation, verifying the deviceKey, deviceSecret, typeKey, and the user's account and password specifically includes:

[0057] Obtain the deviceSecret based on the deviceKey, and decrypt the deviceSecret to obtain the typeKey, data communication request, and user account and password;

[0058] Verify that the mapping between typeKey and deviceKey has been pre-created by the operator;

[0059] The mapping between the deviceKey and the user's account and password has been verified and recorded by the user in advance through the CPE device installation request on the platform.

[0060] In this embodiment, as Figure 2 The device management shown also includes receiving installation and removal instructions from users, such as... Figure 5 As shown, devices pre-registered by the operator are in an unclaimed state, i.e., not installed, and the corresponding icon is grayed out. Only enterprise users (users) can install the devices. After installation, the devices become installed and the icon is highlighted. Device installation can be done individually or in batches. For individual installation, simply fill in the device alias and device IMEI (which can be a unique 15-digit number). For batch installation, follow the batch installation template, fill in the alias and device IMEI for each device, and upload the file. Users can also select an organization within their account's permissions to submit the data. The platform parses the input data sent by the user, updates the corresponding device installation status, and binds it to the organization. Then, it determines whether the selected organization's account is a single sign-on user. If so, subsequent device update information is synchronized to the corresponding partner subsystem user (i.e., the selected organization's account) via message queue / OpenFeign. Users can also delete devices. After deletion, the device returns to an installed state, and the corresponding icon is grayed out. The device deletion process is as follows: Figure 6As shown, after selecting the device to be deleted and clicking "Confirm," the platform updates the device to an "installed" state based on the device key, unbinds the device from the organization, and checks if the organization's account is a single sign-on user. If so, the device deletion information can be synchronized to the corresponding partner subsystem users via message queue / OpenFeign. Devices already installed cannot be reinstalled. If an incorrect organization was selected or a different device IMEI was entered during installation, it can be edited. If a user mistakenly installs a device, it can be deleted, allowing other users to install it. Connected devices can have their device attributes configured online and corresponding event commands issued. These can be categorized as: Wi-Fi management, DHCP management, advanced management, security control, and device logs. WIFI Management: 2.4G, 5G, WLAN, and guest network can be enabled or disabled; DHCP Management: DHCP server can be enabled or disabled; Advanced Management: Preset network mode, select default gateway, add APN, etc.; Security Settings: Set access whitelists, blacklists, and disabling rules (port filtering, IP filtering, MAC filtering, and URL filtering can all be set); Device Logs: Operators, issuance time, command status, response time, and response results can be filtered and viewed based on event issuance time and command type (this is a detailed command log record for each device); Note: Command issuance is an asynchronous operation, and there is a certain delay in device reception and processing. The processed device attributes will be reflected in the next report; If the user to which the device belongs is a partner's single sign-on platform, then after these commands are successfully issued and processed, they will be synchronized to the corresponding user in the partner's subsystem; Since the partner system is uncontrollable and the consistency of data after synchronization cannot be guaranteed, this platform has added a weekly scheduled task to inventory the devices of single sign-on users and synchronize the latest device attributes of the platform to the corresponding users in the partner's subsystem. This task will be executed every Sunday morning.

[0061] In one implementation, generating a server certificate for data communication with the CPE device based on the data communication request specifically includes:

[0062] In response to a data communication request that includes a platform root certificate, and after verifying that the platform root certificate has passed, a server certificate is generated. The platform root certificate is pre-configured by the platform and sent to the operator so that the operator can embed the platform root certificate in the CPE device.

[0063] In one implementation, data communication with the CPE device is based on a server certificate or token, specifically including:

[0064] After the CPE device verifies the server certificate according to the platform root certificate, it establishes MQTTS communication based on the server certificate, receives data sent by the CPE device via MQTTS communication, and / or sends data to the CPE device via MQTTS communication; or,

[0065] Receive data sent by the CPE device via HTTPS communication based on a token, and / or send data to the CPE device via HTTPS communication based on a token.

[0066] In this embodiment, the first step in using the unified operation service is to connect the CPE device to the platform. There are many types of CPE devices, and the data communication methods provided by manufacturers are different. Whether it is a wireless gateway, a bridge, an industrial CPE, a civilian CPE, a 5G router, etc., the connection methods can be roughly divided into two categories based on the amount of data transmitted and the amount of device services: one type and one key pre-registration mode, and one device and one key registration mode. Device type management and registration are the functions used in the device access process. To ensure device connection security, two protocols are used for data transmission: MQTTS (Message Queuing Telemetry Transport) and HTTPS (Hypertext Transfer Protocol Secure). MQTTS is a secure and encrypted transmission protocol based on TLS (Transport Layer Security) / SSL (Secure Socket Layer). Users need to download the platform's root certificate first, and the device also needs to configure the root certificate when connecting. The platform will also issue a corresponding server certificate for device authentication. Finally, data communication is conducted through a message subscription / publishing model, which is suitable for scenarios with low resource overhead and small data transmission volume. HTTPS is a secure and encrypted transmission protocol based on SSL, which uses token authentication for interface interaction, and is suitable for scenarios with high resource overhead and large data transmission volume. For simple, lightweight transmission scenarios where communication security requirements are not high, the MQTT protocol can be used. Compared to MQTTS-based connections, it only omits the certificate verification step, and the rest of the process is the same. Of course, the HTTP protocol can also be used (which is consistent with HTTPS-based connections, except that a TCP connection is established with the platform). However, transmitting information in plaintext is insecure, so it is not recommended to use the HTTP protocol for transmission. All four protocols are applicable to the two types of connection methods mentioned above.

[0067] In one implementation, sending data to the CPE device specifically includes:

[0068] Send advertisements placed by the user to the CPE device so that the CPE device can display the advertisements;

[0069] The data received from the CPE device includes:

[0070] Receive ad view count data sent by CPE devices after the ad is viewed.

[0071] In this embodiment, as Figure 2 The media asset management shown is as follows: it is open to enterprise accounts, and enterprises can create advertisements (images, text), set validity periods, and select organizations within the data permission scope for placement. Devices associated with the corresponding organization will receive the advertisement push. When a device connects to the platform, it is considered that the advertisement has been viewed, and the advertisement's view count is incremented by one. At the same time, a background scheduled task will clear expired advertisements once a day at midnight. Advertisements within their validity period can be re-edited or withdrawn from placement.

[0072] In one embodiment, after receiving the CPE device type created by the operator, the method further includes:

[0073] Receive CPE device management parameters configured by the operator according to the CPE device type;

[0074] After communicating with the CPE device based on a server certificate or token, the method further includes:

[0075] The status of the CPE device is displayed in real time based on the CPE device management parameters. The status of the CPE device is based on the data received and sent during data communication with the CPE device.

[0076] In this embodiment, as Figure 2 The monitoring and maintenance details are as follows: The platform records the main operations performed by the current user, such as device registration, device installation, device deletion, organization creation, modification of subordinate users, user login, and user logout. These are saved in the operation log table, which users can filter and view by time range or by viewing the operation logs of users within their data access permissions. Any modification to device attributes by the user is issued to the device in the form of a command event. The platform records the issuing device name, the time of event issuance, and the command name, which are saved in the command issuance data table. Users can filter and view this data by time range or by viewing the command issuance status of users within their data access permissions. To ensure that no reported data is missed, the data reported by the device periodically is directly put into the message queue by the platform, and multiple microservices and multiple threads in the background consume the data. The platform records the message consumption status, such as the topic, the time of receipt, whether it has been consumed, and the operation partition number. It also calculates the message backlog depth for each topic. Administrators can set warning thresholds. When the backlog depth exceeds the threshold, the platform will issue an alarm and highlight the alarm in a pop-up window.

[0077] CPE devices connected to the platform periodically upload device attribute data, which the platform then displays in real time. The data is categorized according to functional characteristics into: Device Overview, Wi-Fi Management, WAN Management, DHCP Management, Advanced Management, Security Control, and Device Logs. The specific attributes displayed for each category are as follows:

[0078] Device Overview: Device name, network mode, SIM card status, 2.4G WIFI status, 5G WIFI status, device version, model, serial number, IMEI, uptime, average load, total memory, available memory, memory cache, SIM card IMSI, SIM card ICCID, SIM card MSISDN, etc., where SIM cards are divided into two types: internal and external.

[0079] WIFI Management: Connected device status, including the total number of connected devices, hostname, MAC address, IP address, and network of each connected device; 2.4G / 5G status, including WiFi mode, working mode, whether WiFi function is enabled, and whether WiFi is enabled for guest networks, etc.

[0080] WAN Management: Mobile network includes network mode, signal quality, network parameters: RSRP, RSSI, RSRQ, SINR, PCI, frequency point, frequency band, bandwidth, uplink / downlink MCS, RANK type, EnodeBID, CQI, downlink bit error rate, etc., current power-on service traffic, historical total service traffic, etc., primary APN: APN value, IPv4 address, IPv6 address, etc.

[0081] DHCP management: LAN gateway, subnet mask, primary DNS, secondary DNS, DHCP enabled status, start IP, end IP, lease time, etc.

[0082] Advanced management: preset network modes, APN list, default gateway, etc.;

[0083] Security controls: rules for disabling port filtering, IP filtering, MAC filtering, URL filtering, and IP / MAC binding, either as whitelists or blacklists;

[0084] Device logs: Command types, command status, operators, response times, and response results issued by the device;

[0085] Note: All the CPE attribute data mentioned above comes from device reports, and the platform itself will not modify the data in any way; the CPE attribute reporting frequency is adjustable. Based on a comprehensive consideration of traffic costs and business needs, enterprises can choose device attribute reporting intervals of 60 minutes, 30 minutes, 10 minutes, and 5 minutes.

[0086] The backend receives data and processes it immediately. Multiple microservices concurrently compete to consume the latest messages and update the corresponding attributes. Refreshing the page will show the latest device attributes. If a connected device does not receive new attribute reports within two consecutive intervals, the platform will consider the device to be offline.

[0087] The above attributes basically cover all the attributes used by mainstream CPEs. If, in the future, a company's CPE needs to display other attributes, it can be customized separately by adding a tab and corresponding fields for storage.

[0088] In one embodiment, the status of the CPE device is displayed in real time based on CPE device management parameters, specifically including:

[0089] The status of CPE devices is displayed in real time to the operators who have a corresponding relationship with the CPE devices based on the CPE device management parameters;

[0090] The status of the CPE device is displayed in real time to the users who have a corresponding relationship with the CPE device based on the CPE device management parameters.

[0091] In this embodiment, as Figure 2 The platform homepage displays the following specific functions: Based on each user's data permissions, it calculates the total number of devices, their online / offline status, and the number of inactive devices within that user's permission range, thus determining the device online / offline rate and inactivation rate—essentially, device operational status statistics. It also categorizes devices by organization and device type. For operators, it calculates the daily number of devices connected within the past month based on device registration time; for users, it calculates the daily number of devices connected within the past month based on device installation time. For operators, the platform generates user profiles to help them analyze customer characteristics and develop targeted strategies. This primarily focuses on calculating customer numbers by organization, and the daily customer growth and device connection growth within the past month. Note: All statistics displayed on the platform homepage are within the current user's data permission range.

[0092] This embodiment provides a method for unified operation services for various types of CPE devices. It provides a unified operation service platform that enables multi-source data access and can connect to CPEs produced by most mainstream manufacturers on the market, ensuring a wide range of access channels. The platform displays the attributes of most CPEs on the market, allowing both users and operators to perform corresponding operations. Operation logs and command issuance are recorded, facilitating problem localization. It provides real-time display of various CPE attributes and simple data statistics services, helping enterprises and manufacturers to monitor the health and operational status of CPEs in real time.

[0093] Example 2:

[0094] like Figure 7 As shown, this disclosure provides a unified operation service platform for Customer Premises Equipment (CPE), the platform comprising:

[0095] Type management module 11 is used to receive the CPE device type created by the operator, generate the identifier typeKey and key typeSecret of the CPE device type and send them to the operator so that the operator can embed the typeKey, typeSecret and the identifier deviceKey of the CPE device in the CPE device;

[0096] Device management module 12, connected to type management module 11, is used to receive deviceKey sent by CPE device based on typeKey and typeSecret, generate deviceSecret for CPE device and send it to CPE device so that CPE device can fix deviceSecret;

[0097] The communication management module 13 is connected to the device management module 12 and is used to receive the typeKey and data communication request sent by the CPE device based on the deviceKey and deviceSecret, generate a server certificate or token for data communication with the CPE device and send it to the CPE device.

[0098] The data communication module 14 is connected to the communication management module 13 and is used to communicate with the CPE device based on the server certificate or token.

[0099] In this embodiment, the specific components of each module are as follows:

[0100] Type management module 11 includes:

[0101] The first receiving unit is used to receive the CPE device type created by the operator.

[0102] The first generation unit, connected to the first receiving unit, is used to generate the CPE device type identifier (typeKey) and key (typeSecret).

[0103] The first sending unit, connected to the first generating unit, is used to send the typeKey and typeSecret to the operator so that the operator can embed the typeKey, typeSecret and the deviceKey of the CPE device into the CPE device.

[0104] Device management module 12 includes:

[0105] The second receiving unit is used to receive the deviceKey sent by the CPE device based on the typeKey and typeSecret.

[0106] The second generation unit, connected to the second receiving unit, is used to generate the CPE device key deviceSecret based on the deviceKey.

[0107] The second sending unit, connected to the second generating unit, is used to send the deviceSecret to the CPE device so that the CPE device can fix the deviceSecret;

[0108] Communication management module 13 includes:

[0109] The third receiving unit is used to receive the typeKey and data communication request sent by the CPE device based on the deviceKey and deviceSecret.

[0110] The third generation unit, connected to the third receiving unit, is used to generate a server certificate or token for data communication with the CPE device based on the data communication request.

[0111] The third sending unit, connected to the third generating unit, is used to send the server certificate or token to the CPE device.

[0112] In one embodiment, the second transmitting unit specifically includes:

[0113] The second encryption subunit is used to encrypt the deviceSecret based on the typeSecret, and the second sending subunit is used to send the encrypted deviceSecret to the CPE device;

[0114] The third transmitting unit specifically includes:

[0115] The third encryption subunit is used to encrypt the server certificate or token based on deviceSecret, and the third sending subunit is used to send the encrypted server certificate or token to the CPE device.

[0116] In one embodiment, the second receiving unit specifically includes:

[0117] The second receiving subunit is used to receive the deviceKey, which is encrypted using typeSecret based on typeKey, as well as the operator's account and password, sent by the CPE device; and the second verification subunit is used to verify typeKey, typeSecret, deviceKey, as well as the operator's account and password.

[0118] The second generation unit specifically includes:

[0119] The second generation subunit is used to generate the CPE device key deviceSecret in response to successful verification, and the second recording subunit is used to record the correspondence between typeKey, typeSecret, deviceKey, deviceSecret and the operator's account and password;

[0120] The operator's account and password are provided to the operator in advance by the platform and entered by the operator by connecting to the CPE device.

[0121] In one embodiment, the second verification subunit is specifically used for:

[0122] Obtain the typeSecret based on the typeKey, and decrypt the typeSecret to obtain the deviceKey, as well as the operator's account and password;

[0123] Verify that the mapping between typeKey and deviceKey has been pre-created by the operator;

[0124] The verification of the correspondence between the deviceKey and the operator's account and password has been pre-recorded on the platform by the operator through the CPE device registration request.

[0125] In one embodiment, the third receiving unit specifically includes:

[0126] The third receiving subunit is used to receive the typeKey, data communication request, and user account and password sent by the CPE device based on the deviceKey and encrypted with deviceSecret. The third verification subunit is used to verify the deviceKey, deviceSecret, typeKey, and user account and password.

[0127] The third generation unit specifically includes:

[0128] The third generation subunit is used to generate a server certificate or token for data communication with the CPE device in response to successful verification, based on the data communication request.

[0129] The third record subunit is used to record whether the deviceKey is installed and to record the correspondence between the typeKey, deviceKey, deviceSecret, server certificate or token and the user's account and password;

[0130] The user's account and password are provided to the user in advance by the platform and entered by the user when connecting to the CPE device.

[0131] In one embodiment, the third verification subunit is specifically used for:

[0132] Obtain the deviceSecret based on the deviceKey, and decrypt the deviceSecret to obtain the typeKey, data communication request, and user account and password;

[0133] Verify that the mapping between typeKey and deviceKey has been pre-created by the operator;

[0134] The mapping between the deviceKey and the user's account and password has been verified and recorded by the user in advance through the CPE device installation request on the platform.

[0135] In one embodiment, the third generating subunit is specifically used for:

[0136] In response to a data communication request that includes a platform root certificate, and after verifying that the platform root certificate has passed verification, a server certificate is generated. The platform root certificate is pre-configured by the platform and sent to the operator so that the operator can embed the platform root certificate in the CPE device.

[0137] In one embodiment, the data communication module 14 specifically includes:

[0138] The MQTTTS communication unit is used to receive data sent by the CPE device via MQTTTS communication after the CPE device verifies the server certificate according to the platform root certificate, and / or to send data to the CPE device via MQTTTS communication; or...

[0139] The HTTPS communication unit is used to receive data sent by the CPE device via HTTPS communication based on a token, and / or to send data to the CPE device via HTTPS communication based on a token.

[0140] In this embodiment, the data communication module 14 can be further divided into:

[0141] The data receiving unit is used to receive data sent by the CPE device;

[0142] The data transmission unit is used to send data to the CPE device.

[0143] In one embodiment, the data transmission unit is specifically used for:

[0144] Send advertisements placed by the user to the CPE device so that the CPE device can display the advertisements;

[0145] The data receiving unit is specifically used for:

[0146] Receive ad view count data sent by CPE devices after the ad is viewed.

[0147] In one embodiment, the first receiving unit is further configured to:

[0148] Receive CPE device management parameters configured by the operator according to the CPE device type;

[0149] The platform also includes:

[0150] The real-time display module, connected to the data communication module 14, is used to display the status of the CPE device in real time according to the CPE device management parameters. The status of the CPE device is based on the data received and sent by the data communication with the CPE device.

[0151] In one embodiment, the real-time display module specifically includes:

[0152] The operation display unit is used to display the status of CPE devices in real time to the operators who have a corresponding relationship with the CPE devices based on the CPE device management parameters;

[0153] The display unit is used to display the status of the CPE device in real time to the users who have a corresponding relationship with the CPE device, based on the CPE device management parameters.

[0154] Example 5:

[0155] Embodiment 5 of this disclosure provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it implements the unified operation service method for customer terminal equipment (CPE) as described in Embodiment 1, or the unified operation service platform for customer terminal equipment (CPE) as described in Embodiment 2.

[0156] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.

[0157] In addition, this disclosure may also provide a computer device including a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the Customer Premises Equipment (CPE) unified operation service method as described in Embodiment 1, and the computer device may be the Customer Premises Equipment (CPE) unified operation service platform as described in Embodiment 2.

[0158] The memory is connected to the processor. The memory can be flash memory, read-only memory or other types of memory. The processor can be a central processing unit or a microcontroller.

[0159] Embodiments 1-3 of this disclosure provide a unified CPE operation service method, a unified CPE operation service platform, and a computer-readable storage medium. First, a one-type-one-key approach is adopted to manage CPE device types. Then, CPE devices under the corresponding CPE device types are managed based on the one-type-one-key approach, and a device key is configured for each CPE device to achieve one-machine-one-key CPE device management. Finally, the management of CPE device data communication is achieved by configuring server certificates or tokens. Through different key configuration management schemes at different stages, unified management of the entire lifecycle of different types of CPE devices is achieved from manufacturer matching and production to device delivery and device use, ensuring the security of data transmission and reception throughout the entire process and realizing unified operation services for multi-source CPEs.

[0160] It is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of this disclosure, and this disclosure is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this disclosure, and these modifications and improvements are also considered to be within the scope of protection of this disclosure.

Claims

1. A unified operation service method for Customer Premises Equipment (CPE), characterized in that, The method, applied to a unified operation service platform for CPEs, includes: Receive the CPE device type created by the operator, generate the CPE device type identifier typeKey and key typeSecret and send them to the operator so that the operator can embed typeKey, typeSecret and CPE device identifier deviceKey into the CPE device; Receive the deviceKey sent by the CPE device based on the typeKey and encrypted with typeSecret, generate the deviceSecret key of the CPE device and send it to the CPE device so that the CPE device can fix the deviceSecret; Receive the typeKey and data communication request sent by the CPE device based on the deviceKey and encrypted with deviceSecret, generate a server certificate or token for data communication with the CPE device, and send it to the CPE device. Data communication with CPE devices is based on server certificates or tokens.

2. The method according to claim 1, characterized in that, The deviceSecret is sent to the CPE device, specifically including: Use typeSecret to encrypt and send deviceSecret to CPE device; The server certificate or token is sent to the CPE device, specifically including: Use deviceSecret to encrypt and send the server certificate or token to the CPE device.

3. The method according to claim 1 or 2, characterized in that, Receive the deviceKey sent by the CPE device based on the typeKey and encrypted with typeSecret, and generate the CPE device's key deviceSecret, which specifically includes: The system receives the deviceKey, encrypted using typeSecret, sent by the CPE device based on typeKey, along with the operator's account and password. Upon successful verification of typeKey, typeSecret, deviceKey, and the operator's account and password, the system generates a key deviceSecret for the CPE device and records the correspondence between typeKey, typeSecret, deviceKey, deviceSecret, and the operator's account and password. The operator's account and password are provided to the operator in advance by the platform and are entered by the operator when connecting to the CPE device.

4. The method according to claim 3, characterized in that, Verification of typeKey, typeSecret, deviceKey, and operator account and password is successful, specifically including: Obtain the typeSecret based on the typeKey, and decrypt the typeSecret to obtain the deviceKey, as well as the operator's account and password; Verify that the mapping between typeKey and deviceKey has been pre-created by the operator; The verification of the correspondence between the deviceKey and the operator's account and password has been pre-recorded on the platform by the operator through the CPE device registration request.

5. The method according to claim 3, characterized in that, Receive the typeKey and data communication request sent by the CPE device based on the deviceKey and encrypted with the deviceSecret, and generate a server certificate or token for data communication with the CPE device, specifically including: The system receives a data communication request, a user account, and a password from a CPE device, encrypted with a deviceSecret based on the deviceKey. Upon successful verification of the deviceKey, deviceSecret, typeKey, and user account, the system generates a server certificate or token for data communication with the CPE device based on the data communication request. It also records that the deviceKey is installed and the mapping between the typeKey, deviceKey, deviceSecret, server certificate or token, and the user account and password. The user account and password are provided to the user by the platform beforehand and entered by the user when connecting to the CPE device.

6. The method according to claim 5, characterized in that, Verification of deviceKey, deviceSecret, typeKey, and the user's account and password is successful, specifically including: Obtain the deviceSecret based on the deviceKey, and decrypt the deviceSecret to obtain the typeKey, data communication request, and user account and password; Verify that the mapping between typeKey and deviceKey has been pre-created by the operator; The mapping between the deviceKey and the user's account and password has been verified and recorded by the user in advance through the CPE device installation request on the platform.

7. The method according to claim 5, characterized in that, Generate a server certificate for data communication with the CPE device based on the data communication request, specifically including: In response to a data communication request that includes a platform root certificate, and after verifying that the platform root certificate has passed verification, a server certificate is generated. The platform root certificate is pre-configured by the platform and sent to the operator so that the operator can embed the platform root certificate in the CPE device.

8. The method according to claim 6, characterized in that, Data communication with CPE devices is based on server certificates or tokens, specifically including: After the CPE device verifies the server certificate according to the platform root certificate, it establishes MQTTS communication based on the server certificate, receives data sent by the CPE device via MQTTS communication, and / or sends data to the CPE device via MQTTS communication; or, Receive data sent by the CPE device via HTTPS communication based on a token, and / or send data to the CPE device via HTTPS communication based on a token.

9. The method according to claim 8, characterized in that, Sending data to the CPE device, specifically including: Send advertisements placed by the user to the CPE device so that the CPE device can display the advertisements; The data received from the CPE device includes: Receive ad view count data sent by the CPE device after the ad is viewed.

10. The method according to claim 5, characterized in that, After receiving the CPE device type created by the operator, the method further includes: Receive CPE device management parameters configured by the operator according to the CPE device type; After communicating with the CPE device based on a server certificate or token, the method further includes: The status of the CPE device is displayed in real time based on the CPE device management parameters. The status of the CPE device is based on the data received and sent during data communication with the CPE device.

11. The method according to claim 10, characterized in that, The status of CPE devices is displayed in real time based on CPE device management parameters, specifically including: The status of CPE devices is displayed in real time to the operators who have a corresponding relationship with the CPE devices based on the CPE device management parameters; The status of the CPE device is displayed in real time to the users who have a corresponding relationship with the CPE device based on the CPE device management parameters.

12. A unified operation service platform for Customer Premises Equipment (CPE), characterized in that, The platform includes: The type management module is used to receive the CPE device type created by the operator, generate the CPE device type identifier typeKey and key typeSecret and send them to the operator so that the operator can embed the typeKey, typeSecret and CPE device identifier deviceKey into the CPE device; The device management module, connected to the type management module, is used to receive the deviceKey sent by the CPE device based on the typeKey and encrypted with typeSecret, generate the deviceSecret key of the CPE device, and send it to the CPE device so that the CPE device can fix the deviceSecret. The communication management module, connected to the device management module, is used to receive the typeKey and data communication request sent by the CPE device based on the deviceKey and encrypted with deviceSecret, generate a server certificate or token for data communication with the CPE device, and send it to the CPE device. The data communication module, connected to the communication management module, is used to communicate with the CPE device based on a server certificate or token.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the Customer Premises Equipment (CPE) unified operation service method as described in any one of claims 1-11.

Images