An air interface programming method and related apparatus

Abstract

The application discloses an air interface programming method and related device, and relates to the field of wireless communication, comprising the following steps: broadcasting common parameter information to all to-be-modified devices, so that all to-be-modified devices modify their own device parameters based on the common parameter information; and issuing differentiated parameter information corresponding to the to-be-modified devices containing differentiated parameters (which can be referred to as second type to-be-modified devices) one by one, so that the devices modify their own device parameters according to the differentiated parameter information. It can be seen that, for the modification parameters common to all devices, the common parameter information needs to be sent only once in the air interface, thereby reducing the air interface resource occupation, and meanwhile, the operation complexity and time of modifying the to-be-modified parameters common to the batch devices are reduced; for the to-be-modified parameters not specific to some or a small part of devices, the differentiated parameters corresponding to the devices are sent to the devices one by one, so that the whole air interface programming process is completed.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to an air interface programming method and related apparatus. Background Technology

[0002] Over-the-Air Programming (OTAP) is a remote firmware upgrade technology based on wireless communication. It enables device function iteration by pushing update packages through the cloud and is mainly used in mobile phones, IoT devices, and secure communication fields.

[0003] Currently, when using the OTAP function, only one-to-one air interface programming is possible, meaning that only one device (terminal device) can be contacted at a time to modify parameters. If multiple devices need to have their parameter configurations modified, such as changing the factory default parameters of a large number of networked devices to system parameters, or adjusting the parameters of networked devices after system optimization, most devices require identical configuration parameters. For example, if they share 100 contacts, identical configurations, and data, each device requiring modification needs to undergo air interface programming. Most of the time is spent processing the same operations and sending / receiving air interface data on different devices, resulting in extremely low efficiency, long processing times, and wasted air interface resources. Summary of the Invention

[0004] In view of the above problems, this application provides an over-the-air programming method and related apparatus to solve at least some of the aforementioned problems. The specific solution is as follows: The first aspect of this application provides an over-the-air programming method, executed by a system device, the method comprising: Broadcast a first message, which includes common parameter information for all devices to be modified. The devices to be modified include a first type of devices that contain only common parameters and a second type of devices that contain both common parameters and differentiated parameters. The first message is used to enable the first type of devices to be modified and the second type of devices to modify their device parameters based on the common parameter information. A second message is sent to each of the second type of devices to be modified. The second message includes the differentiated parameter information corresponding to the second type of devices to be modified. The second message is used to enable the second type of devices to modify their own device parameters based on the common parameter information and the differentiated parameter information.

[0005] In one possible implementation, the public parameter information includes public parameters, as well as the number of public parameters and / or the validity period of the public parameters.

[0006] In one possible implementation, the differentiated parameter information includes a device identifier, and the number and parameters of differentiated parameters of the device to be modified corresponding to the device identifier.

[0007] In one possible implementation, the second message further includes first private encryption information, wherein the differentiated parameter information is sent after being encrypted using the first private encryption information.

[0008] In one possible implementation, the first message further includes first public encryption information, wherein the public parameter information is sent after being encrypted using the public encryption information, and the public encryption information includes first public encryption information and second public encryption information.

[0009] In one possible implementation, the method further includes sending a third message to a first type of device to be modified, the third message including the second public encryption information.

[0010] In one possible implementation, the third message further includes second private encrypted information, which is sent after being encrypted using the second private encrypted information.

[0011] In one possible implementation, the second message also includes second public encrypted information.

[0012] In one possible implementation, the second message further includes third private encrypted information, wherein the second public encrypted information and the differentiated parameter information are encrypted using the third private encrypted information before being sent.

[0013] In one possible implementation, after broadcasting the first message, the method further includes: Broadcast a first upgrade instruction, which is used to indicate that the first type of devices to be modified have completed the upgrade and the second type of devices to be modified continue to wait for the upgrade.

[0014] In one possible implementation, the first upgrade instruction includes a device identifier that has completed the upgrade and a device identifier that is waiting to continue the upgrade.

[0015] In one possible implementation, after sending the second message, the process further includes sending a second upgrade instruction to each of the second type of devices to be modified, the second upgrade instruction indicating that the upgrade of the second type of devices to be modified is complete.

[0016] In one possible implementation, when the public parameter information includes the public parameter validity period, the public parameter validity period is the time required for the entire air interface programming process, calculated based on the number of public parameters, the number of differential parameters of all devices to be modified, and the number of devices to be modified.

[0017] Secondly, this application provides an over-the-air programming method, executed by a terminal device, the method comprising: Receive a first message from the system device, the first message including common parameter information of all devices to be modified; Receive a first upgrade instruction from the system device, the first upgrade instruction being used to indicate that the upgrade parameters for a first type of device to be modified, which contains only common parameters, have been sent; When it is determined that its own upgrade parameters have been received based on the first upgrade instruction, the device parameters are modified based on the public parameter information.

[0018] In one possible implementation, the first message further includes first public encrypted information; after receiving the first message from the system device, the method further includes: Receive a third message from the system device, the third message including second public encrypted information; Based on the first public encryption information and the second public encryption information, the encrypted public parameter information in the first message is decrypted to obtain the decrypted public parameter information.

[0019] In one possible implementation, the method further includes: Receive a second message from the system device, the second message including differential parameter information; Based on the common parameter information and the differentiated parameter information, modify its own device parameters.

[0020] In one possible implementation, the second message further includes second public encrypted information; after receiving the second message from the system device, the method further includes: The encrypted public parameter information in the first message is decrypted based on the first public encryption information and the second public encryption information, wherein the first public encryption information is contained in the first message.

[0021] In one possible implementation, the first upgrade instruction includes the identifier of the first type of device to be modified, in which upgrade parameters have been sent, and / or the identifier of the second type of device to be modified, in which upgrades need to be continued.

[0022] In one possible implementation, receiving the first upgrade instruction from the system device includes: The system receives a fourth message sent by the system device in a call manner, parses the fourth message to obtain the first upgrade instruction, and the first upgrade instruction is used to indicate that the upgrade parameters of the terminal device have been sent.

[0023] In one possible implementation, the method further includes: Receive a second upgrade instruction, which indicates that the upgrade parameters of the terminal device have been sent.

[0024] Thirdly, this application also provides a communication device including at least one processor coupled to a memory storing a program or instructions, wherein the processor executes the program or instructions to cause the device to perform the method as described in any of the first or second aspects.

[0025] Fourthly, this application also provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of the first or second aspects.

[0026] By employing the above technical solution, the air interface programming method provided in this application involves the system device broadcasting common parameter information to all devices to be modified, thereby enabling all devices to modify their own device parameters based on the common parameter information; and, by sending the corresponding differential parameter information to each device to be modified (which can be referred to as the second type of device to be modified), enabling such devices to modify their own device parameters based on the differential parameter information. In this way, for modification parameters common to all devices, only the common parameter information needs to be sent once over the air interface, reducing air interface resource consumption and simultaneously reducing the operational complexity and time required to modify common modification parameters of a batch of devices; for modification parameters not unique to a particular device or a small number of devices, the corresponding differential parameters are sent to each of these devices individually, thus completing the entire air interface programming process. Attached Figure Description

[0027] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0028] Figure 1 A schematic diagram of an air interface programming system architecture is provided for this application; Figure 2 A flowchart of an air interface programming method provided in this application; Figure 3 A flowchart of another air interface programming method provided in this application; Figure 4 This application provides a schematic diagram of the structure of a DMR data service frame; Figure 5 A flowchart illustrating the generation and transmission process of a first message provided in this application; Figure 6 A flowchart of a device to be modified receiving a first message is provided in this application; Figure 7A flowchart illustrating the generation and transmission process of a second message provided in this application; Figure 8 A schematic diagram of a combination of second public encrypted information and differential parameter information provided in this application; Figure 9 A flowchart of a device to be modified receiving a second message is provided in this application; Figure 10 This is a schematic diagram of the structure of a communication device provided in this application. Detailed Implementation

[0029] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0030] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0031] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0032] OTAP (Over-The-Air Programming) technology is a function that modifies parameters of a terminal device through the air interface. For example... Figure 1 As shown, the OTAP system may include a scheduling device 100, a system device 200, and a terminal device 300. The number of terminal devices 300 may be 1 to n, where n is a positive integer.

[0033] The relevant parameter configuration can be modified by the scheduling device 100 and sent to the system device 200 with air interface transmission and reception capabilities. The system device 200 sends the configuration parameters through the air interface. The terminal device 300 receives the configuration parameters through the air interface, thereby completing the parameter modification of the terminal device.

[0034] For example, the dispatching device 100 can be a functional platform with management, dispatching, and intercom functions, such as a server or cloud server. The dispatching device 100 can communicate with the system device 200 via the Internet.

[0035] System equipment 200 can be a multi-device system with mobile communication system access network equipment. The access network equipment has wireless transceiver capabilities for communicating with terminal equipment. For example, system equipment 200 can be a base station, repeater, or other equipment. The terminal equipment in this application can be a wireless terminal device capable of receiving scheduling and instruction information from system equipment. The wireless terminal device can be a device providing voice and / or data connectivity to users, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. For example, the terminal device can communicate with one or more core networks or the Internet via a radio access network (RAN), or it can be a wireless device (e.g., a walkie-talkie) that communicates with system equipment via radio. Terminal equipment can also be referred to as a terminal, user equipment (UE), mobile station, mobile terminal, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), ultra-reliable low-latency communication (URLLC), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, or satellite communication. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, aircraft (such as drones, helicopters, and airplanes), hot air balloons, ships, robots, robotic arms, or smart home devices. The embodiments of this application do not limit the form of the terminal device.

[0036] In this application, the apparatus for implementing the functions of a terminal device can be the terminal device itself, or any apparatus capable of supporting the terminal device in implementing those functions, such as a processor, circuit, chip, or chip system. This apparatus can be installed in or connected to the terminal device. In the technical solutions provided in this application, the example of a terminal device being used to implement the functions of a terminal device is used to describe the technical solutions provided in this application.

[0037] As previously mentioned, when using OTAP functionality, such as with walkie-talkies, only one terminal device can be contacted at a time for parameter modification. In scenarios where parameter configuration needs to be modified for multiple terminal devices, each terminal device requires separate air interface programming, repeatedly executing the same code and performing the same air interface data transmission and reception. This results in inefficient and time-consuming parameter configuration processes and a waste of air interface resources.

[0038] To address the aforementioned issues, this application provides an air interface programming method. This method involves statistically analyzing all parameters to be modified across all devices, extracting and recording common parameters shared by all devices (i.e., common parameters), and recording the parameters that differ between each device and other devices (i.e., differential parameters). For common parameters, the information is broadcast over the air interface. This ensures that all devices receive the common parameter information only once, reducing air interface resource consumption and minimizing the operation and time required to modify common configuration parameters. For differential parameters, they are sent individually to the corresponding devices, thus completing the entire air interface programming process.

[0039] The air interface programming method provided in this application will be described in detail below with reference to the accompanying drawings.

[0040] Please see Figure 2 The diagram illustrates a flowchart of an air interface programming method provided in an embodiment of this application. This method is applied to a communication system, which includes system equipment and multiple terminal devices. Figure 2 As shown, the method may include the following steps: S101, the system device broadcasts the first message. Correspondingly, the terminal device receives the first message.

[0041] In one embodiment, this step may be a sending action performed by the server (i.e., scheduling device 100) through system devices (such as base stations or repeaters), such as the server sending a message to the base station, instructing the base station to broadcast over the air interface.

[0042] In one exemplary embodiment, the first message includes common parameter information, which may include common parameters, and may also include the number of common parameters and / or the validity period of the common parameters.

[0043] Common parameters refer to the parameters that all devices to be modified contain. The number of common parameters refers to the total number of parameters to be modified within the common parameters issued this time. The validity period of common parameters refers to the maximum waiting time for a terminal device to receive differentiated parameters after receiving the common parameter information. If this time is exceeded, the terminal device can perform an upgrade operation or exit upgrade mode.

[0044] In one possible implementation, the relevant configurations are modified by scheduling devices. For example, templates for all devices corresponding to the parameters to be modified are selected one by one, and the template parameters for all identifiers are modified and saved. For instance, each device that needs parameter modification has a parameter configuration template, which may contain all configuration parameters of the device or only some configuration parameters. Furthermore, the common parameters of all devices to be modified are extracted and recorded, the differential parameters of each device are recorded, and the number of common parameters and the number of differential parameters of each device are recorded.

[0045] In one possible implementation, the validity period of common parameters needs to be greater than or equal to the entire OTAP service cycle. For example, the validity period of common parameters can be calculated based on the data volume of all differentiated parameters corresponding to all devices to be modified and the number of devices to be modified.

[0046] In one possible implementation, the broadcast can be an all-call mode, that is, a call is initiated to all terminal devices on the network, meaning that all terminal devices on the network can receive the broadcast message. Alternatively, the broadcast can be a group call mode, that is, a call is initiated to all devices in the group to which the device to be modified belongs.

[0047] In one possible implementation, to ensure that the device to be modified can successfully receive the first message, the first message can be broadcast repeatedly, meaning that the content of the first message broadcast multiple times is exactly the same. The specific number of rebroadcasts can be set according to actual needs, for example, determined by the number of devices to be modified.

[0048] S102, the device to be modified receives the first message, starts the timer, and saves the common parameter information.

[0049] In this embodiment, the device to be modified refers to a terminal device whose configuration parameters need to be modified. For ease of description, devices with only common parameters are referred to as the first type of device to be modified, while devices with both common and differentiated parameters are referred to as the second type of device to be modified.

[0050] The timer's duration is the validity period of the common parameters. This application does not impose any special restrictions on the timer's timing method. When the device to be modified receives the first message for the first time, the timer is started. Before the timer expires, the device to be modified backs up the broadcast data (i.e., common parameter information) and the status of the received common parameters and the differential parameters to be received, until the timer expires or a data request for the differential parameters is received, ending the reception of broadcast data.

[0051] S103, the system device broadcasts the first upgrade command. Correspondingly, the device to be modified receives the first upgrade command.

[0052] The first upgrade command is used to indicate whether the upgrade of the device to be modified is complete (i.e., the upgrade can be performed) or to wait for the upgrade to continue (i.e., to wait to continue receiving modified parameter information).

[0053] In this embodiment, the first upgrade instruction is sent in a broadcast manner, meaning that all network-connected devices to be modified can receive the first upgrade instruction. In this scenario, the first upgrade instruction may include the device ID of the upgraded device (i.e., the device ID of the first type of device to be modified) and / or the device identifier that needs to continue waiting for the upgrade (i.e., the device ID of the second type of device to be modified), used to instruct the first type of device to be modified to perform the upgrade, and to instruct the second type of device to be modified to wait for the upgrade to continue.

[0054] For example, for a device to be modified, if it is determined that the upgraded device ID contains its own device ID, then the subsequent parameter upgrade process is executed; if it is determined that the device ID waiting to be upgraded contains its own device ID, then it continues to wait to receive subsequent upgrade parameter information.

[0055] In another possible implementation, the system device can broadcast a first upgrade command to devices in the same group as the devices to be modified, which only contain common parameters. This means sending the first upgrade command to the first type of devices to be modified via a group call. In this scenario, the first upgrade command indicates that the upgrade parameters for the first type of devices to be modified have been sent, and devices that have not received the first upgrade command via the group call will wait to continue the upgrade process.

[0056] In another possible implementation, the first upgrade instruction can be sent via individual calls. For example, the system device sends the first upgrade instruction to each device to be modified (i.e., the first type of device to be modified) that contains only common parameters. The first upgrade instruction is used to indicate that the upgrade parameters of the device to be modified have been sent. Devices to be modified that have not received the first upgrade instruction wait to continue the upgrade.

[0057] In another possible implementation, the first upgrade instruction can be sent along with the first message, that is, the first upgrade instruction is included in the first message.

[0058] S104, the first type of device to be modified responds to the first upgrade command and modifies its own device parameters based on common parameter information.

[0059] The first type of device to be modified determines that it can perform an upgrade operation based on the first upgrade instruction, and modifies its own device parameters based on the received public parameter information.

[0060] S105, the first type of device to be modified sends a first upgrade success message to the system device within the response time corresponding to its own device ID.

[0061] In scenarios where the system device issues the first upgrade command via broadcast, the first upgrade command carries a device identifier indicating that the upgrade parameters have been sent. Upon receiving the first upgrade command, the first type of device to be modified calculates its own response time based on its device ID and the sequence number in the first upgrade command, and sends an upgrade success message to the system device within the response time.

[0062] In one possible implementation, the response time can be calculated by multiplying the device's ID in the sequence number of the first upgrade instruction and the time taken for a single response frame. For example, 100 devices of type 1 to be modified have IDs from 1 to 100, which are stored sequentially in the first upgrade instruction and broadcast over the air interface. If a single response frame takes 60ms, then the device with ID 68, upon receiving the first upgrade instruction, will reply with a successful upgrade response message (i.e., a first upgrade success message) within a time slice of 68 × 60ms = 4080ms. All devices of type 1 to be modified calculate their corresponding response times according to the above example, thus achieving orderly response from devices of type 1 to be modified.

[0063] S106, the second type of device to be modified responds to the first upgrade instruction and waits to continue the upgrade. If the timer expires and no second message is received, the saved public parameter information is discarded.

[0064] For the second type of device to be modified with differentiated parameters, if the device ID waiting to continue upgrading carried in the first upgrade instruction sent by the system device includes its own device ID, it is determined that it needs to wait to continue upgrading and wait to receive differentiated parameter information. If it does not receive differentiated parameter information sent by the system device until the timer expires, the saved common parameter information is discarded and the parameter modification fails.

[0065] S107, the system device sends a second message to each of the second-type devices to be modified in a one-to-one call manner. Correspondingly, the second-type devices to be modified receive the second message.

[0066] The second message includes the differentiated parameter information for the second category of devices to be modified. This differentiated parameter information includes the device ID and the differentiated parameters, and may also include the number of differentiated parameters. The device ID is a unique identifier for the terminal device. The differentiated parameter information may also include the total number of parameters to be modified.

[0067] The differentiated parameters of each Category II device to be modified are those parameters that the device to be modified contains, and at least partially contains, those parameters that other devices to be modified do not contain. The number of differentiated parameters is the total number of differentiated parameters to be modified contained in the device to be modified.

[0068] The total number of parameters to be modified is the sum of the number of common parameters and the number of differential parameters corresponding to the device to be modified.

[0069] S108: If the second type of device to be modified receives the second message before the timer expires, determine whether the device ID in the second message is the same as its own device ID; if they are the same, execute S109; if they are different, execute S113.

[0070] Before the timer expires, the second type of device to be modified receives a second message sent by the system device via a personal call. It parses the second message to obtain the device ID it carries and determines whether this device ID is the same as its own device ID, i.e., whether the recipient of the second message is itself. If the device ID in the second message is the same as its own device ID, it is confirmed that the second message was sent to itself; if the device ID in the second message is different from its own device ID, it is confirmed that the second message was not sent to itself.

[0071] S109, the second type of device to be modified verifies whether the data in the second message is accurate; if accurate, proceed to S110; if inaccurate, end the current process.

[0072] In one possible implementation, the system first determines whether the number of modified parameters is consistent, that is, whether the sum of the number of common parameters carried in the first message and the number of differentiated parameters carried in the second message is equal to the total number of modified parameters carried in the second message; if they are equal, the data verification in the second message is confirmed to be accurate; if they are not equal, the data verification in the second message is confirmed to have failed.

[0073] This step is optional, meaning it can be skipped. S109 can be executed when the differential parameter information includes the total number of parameters to be modified; otherwise, S109 is not required, meaning S110 is executed directly after S108.

[0074] S110, the second type of device to be modified extracts the differential parameter information from the second message.

[0075] If S109 is executed, the second type of device to be modified verifies the accuracy of the data in the second message and extracts the differential parameter information from the second message. If S109 is not executed, the second type of device to be modified determines in S108 that the device ID in the second message contains its own device ID and then executes S110.

[0076] S111, the second type of device to be modified modifies its own device parameters based on common parameter information and differentiated parameter information.

[0077] At this point, the second type of device to be modified obtains common parameter information through the first message received, and obtains its own corresponding differentiated parameter information through the second message. Furthermore, the second type of device to be modified modifies its own device parameters based on the common parameter information and the differentiated parameter information.

[0078] Optionally, the second message may also carry a second upgrade instruction to instruct the device to be modified to complete the upgrade. Alternatively, the system device may send the second upgrade instruction to each of the second type of devices to be modified individually via a call.

[0079] Upon receiving the second upgrade instruction, the second type of device to be modified determines that it can perform subsequent upgrade operations. In response to the second upgrade instruction, the device to be modified modifies its own device parameters based on the common parameter information contained in the first message and the differentiated parameter information contained in the second message, thus completing the device parameter upgrade.

[0080] S112, the second type of device to be modified sends a second upgrade success message to the system device.

[0081] After the second type of device modifies its own device parameters based on common and differentiated parameter information, it returns a second upgrade success message to the system device.

[0082] S113, The second type of device to be modified discards the received second message.

[0083] If the device ID carried in the second message received by the second type of device to be modified is different from its own device ID, it is determined that the second message was not sent to itself and the second message is discarded.

[0084] The air interface programming method provided in this embodiment counts all parameters to be modified for all devices to be modified, extracts and records the common parameters (i.e., public parameters) and records the parameters that are different from other devices (i.e., differential parameters). For public parameters, the information is broadcast over the air interface. This way, only one broadcast is needed, and all devices to be modified will receive the information, reducing air interface resource consumption and lowering the complexity and time required to modify common parameters shared by multiple devices. For differential parameters, they are sent individually to the corresponding devices to be modified, thus completing the entire air interface programming process.

[0085] In another exemplary embodiment of this application, in order to ensure the security of upgrade parameter transmission, the public parameter information sent by the system device to the device to be modified can be encrypted using public encryption information, and further, the differentiated parameter information can be encrypted using private encryption information.

[0086] like Figure 3 As shown, the air interface programming method provided in this embodiment may include the following steps: S201, the system devices broadcast the first message. The corresponding first-type and second-type devices to be modified receive the first message.

[0087] In embodiments of this application, the first message includes encrypted public parameter information and first public encrypted information. The public parameter information may include public parameters, and may also include the number of public parameters and / or the validity period of the public parameters, as can be found in [reference needed]. Figure 2 The descriptions of the common parameter information in the illustrated embodiments will not be repeated here.

[0088] In one possible implementation, the system device encrypts the public parameter information using public encryption information (such as public encryption vector, encryption key ID, encryption algorithm ID), and fills the encrypted public parameter information into the first message.

[0089] For example, public encryption information can be a public encryption vector, encryption key ID, and encryption algorithm ID. The first public encryption information can be any one of these, or a combination of any two encryption information.

[0090] In one possible implementation, to ensure communication security, the public encrypted information is divided into at least two parts and contained in separate messages before being sent to the device to be modified. For example, the public encrypted information can be divided into two parts: a first public encrypted information and a second public encrypted information. For instance, the first public encrypted information might be a public encryption vector and an encryption key ID, while the second public encrypted information might be an encryption algorithm ID. The first public encrypted information can be included in a first message, while the second public encrypted information can be sent in another message. This avoids cracking the first message to obtain all the public encrypted information, thus improving the security of the public parameter information.

[0091] S202, the first type of device to be modified and the second type of device to be modified receive the first message and start a timer to save the encrypted public parameter information and the first public encrypted information.

[0092] After receiving the first message broadcast by the system device, the first and second type of devices to be modified parse the message header of the first message to obtain the validity period of the common parameters, and start a timer. The duration of the timer is the validity period of the common parameters.

[0093] S203, the system device broadcasts a third message. Correspondingly, the first type of device to be modified and the second type of device to be modified receive the third message.

[0094] In one possible implementation, the third message includes a first upgrade command and second public encrypted information. The device to be modified can only successfully decrypt the public parameter information after obtaining all the public encrypted information. The first upgrade command can be found in [reference needed]. Figure 2 The relevant descriptions in S103 of the illustrated embodiment will not be repeated here.

[0095] For the first type of device to be modified with no differentiating parameters, the device confirms its need for an upgrade based on the first upgrade instruction and obtains the second public encrypted information. At this point, the first type of device has obtained all the public encrypted information and can use this complete information to decrypt the encrypted public parameter information, obtaining the decrypted public parameter information. Subsequent upgrade operations are then performed based on the decrypted public parameter information.

[0096] In one possible implementation, to ensure the security of the public encrypted information, the second public encrypted information can also be encrypted. For example, the third message also includes second private encrypted information, and the second public encrypted information in the third message is encrypted using the second private encrypted information, thus avoiding the possibility of obtaining the second public encrypted information by directly cracking the third message.

[0097] The first type of device to be modified can parse the third message to obtain the second private encrypted information and the encrypted second public encrypted information, and use the second private encrypted information to decrypt the encrypted second public encrypted information to obtain the second public encrypted information.

[0098] In one embodiment, for the second type of device to be modified with differentiated parameters, after confirming that it needs to wait for further upgrades based on the first upgrade instruction, there is no need to parse the second public encrypted information in the third message. For the second type of device to be modified, the second public encrypted information can be sent together with the differentiated parameters.

[0099] S204, the first type of device to be modified responds to the first upgrade command by decrypting the encrypted public parameter information based on the first public encryption information and the second public encryption information.

[0100] The first type of device to be modified parses the first message to obtain the first public encrypted information and the encrypted public parameter information, parses the third message to obtain the second public encrypted information, and obtains all public encrypted information. Then, it uses all public encrypted information to decrypt the encrypted public parameter information to obtain the decrypted public parameter information.

[0101] S205, the first type of device to be modified modifies its own device parameters based on the decrypted public parameter information.

[0102] S206, After modifying the device parameters, the first type of device to be modified sends a first upgrade success message to the system device within the response time corresponding to its own device ID.

[0103] S207, the second type of device to be modified responds to the first upgrade instruction and waits to continue the upgrade. If the timer expires and no second message is received, the saved first public encrypted information and encrypted public parameter information are discarded.

[0104] For the specific implementation process of S205~S207 in this embodiment, please refer to [link / reference]. Figure 2 The relevant descriptions of S104 to S106 in the illustrated embodiment will not be repeated here.

[0105] S208, the system device sends a second message to each of the second-type devices to be modified in a one-to-one call manner. The corresponding second-type devices to be modified receive the second message.

[0106] For devices with differentiated parameters to be modified, the system sends the second public encrypted information along with the differentiated parameter information to the device to be modified.

[0107] In this embodiment, the second message includes differentiated parameter information, second public encryption information, and private encryption information.

[0108] In one possible implementation, the differentiated parameters in the second message are encrypted using the private encrypted information (i.e., the first private encrypted information) in the second message before being sent. That is, the second message includes encrypted differentiated parameter information, second public encrypted information, and first private encrypted information.

[0109] In another possible implementation, the differentiated parameter information and the second public encrypted information are encrypted using the private encrypted information (i.e., the third private encrypted information) in the second message before being sent. That is, the second message includes the encrypted differentiated parameter information, the encrypted second public encrypted information, and the third private encrypted information.

[0110] Differentiated parameter information may include device ID, number of differentiated parameters, and total number of modified parameters.

[0111] S209: Before the timer expires, the second type of device to be modified receives the second message and determines whether the device ID in the second message is the same as its own device ID; if they are different, proceed to S210; if they are the same, proceed to S211.

[0112] Upon receiving the second message, the device to be modified parses the second message to obtain its device ID, and compares it with its own device ID. If they are the same, it is confirmed that the second message was sent to itself, and the subsequent processing flow continues; if they are different, it is confirmed that the second message was not sent to itself.

[0113] S210, The second type of device to be modified discards the received second message.

[0114] If the device to be modified receives the second message and confirms that the message was not sent to itself, then it discards the message.

[0115] S211, the second type of device to be modified uses third private encryption information to decrypt encrypted differentiated parameter information and encrypted second public encryption information, and uses first and second public encryption information to decrypt encrypted public parameter information.

[0116] In one embodiment, after the second type of device to be modified parses the received second message to obtain encrypted differentiated parameter information, private encrypted information, and second public encrypted information, it uses the private encrypted information to decrypt the encrypted differentiated parameter information. Simultaneously, it uses the first and second public encrypted information to decrypt the encrypted public parameter information.

[0117] S212, verify whether the common parameter information and differential parameter information of the second type of device to be modified after decryption are correct; if the calibration is accurate, proceed to S213; if the verification is inaccurate, end the current process.

[0118] In one possible implementation, if the differentiated parameter information can be successfully decrypted using the private encrypted information in the second message in S211, and the common parameter information can be successfully decrypted using the first and second common encrypted information, then the second message is preliminarily determined to be correct. If at least one of the differentiated parameter information and the common parameter information fails to be decrypted in S211, then the second message is determined to be inaccurate.

[0119] Furthermore, it can be verified whether the number of modified parameters is consistent. That is, compare the sum of the number of differentiated parameters and the number of common parameters with the total number of modified parameters. If they are consistent, the second message is confirmed to be correct; if they are inconsistent, the second message is confirmed to be incorrect.

[0120] S213, the second type of device to be modified modifies its own device parameters based on the decrypted public parameter information and differentiated parameter information.

[0121] Optionally, after sending the second message, the system device can also send a second upgrade command to each of the second type of devices to be modified, indicating that the current device to be modified has completed the upgrade. Upon receiving the second upgrade command, the second type of device to be modified determines that it can perform subsequent upgrade operations.

[0122] S214, The second type of device to be modified sends a second upgrade success message to the system device.

[0123] Please refer to the implementation process of S213~S214 in this embodiment. Figure 2 The relevant descriptions of S111~S112 in the illustrated embodiment will not be repeated here.

[0124] The air interface programming method provided in this embodiment addresses common parameters shared by all devices to be modified. By broadcasting these common parameters over the air interface, all devices receive them, reducing the operations and time required to modify common configuration parameters and minimizing air interface resource usage. For differentiated parameters, individual calls are used to send them to the corresponding devices to be modified. Furthermore, common parameter information is encrypted using common encryption information, while differentiated parameter information is encrypted using private encryption information, thereby ensuring the security of upgrade parameters.

[0125] Furthermore, the public encrypted information is divided into two parts (first public encrypted information and second public encrypted information) and contained in two separate messages sent to the device to be modified, further enhancing the security of the public parameter information. Moreover, the second public encrypted information can also be encrypted using private encrypted information, further improving the security of the public encrypted information.

[0126] The following will combine Figure 4 This application describes the data frame format used for over-the-air programming in its embodiments.

[0127] In an exemplary embodiment, a data frame for over-the-air programming can be generated by selecting either the Digital Mobile Radio (DMR) standard communication protocol or the OTAP protocol. This application embodiment uses the DMR standard communication protocol as an example for illustration. Data frames based on the DMR standard communication protocol have multiple implementation methods; this application only illustrates one of them. The encryption process for the data (parameter information to be modified) is optional. Whether to encrypt the data depends on security considerations. This embodiment uses data encryption as an example for illustration. In scenarios where encryption is not required, the data frame does not contain fields related to encryption.

[0128] A DMR data frame typically includes a standard header, a private header, and data blocks. There is only one standard header, but there can be multiple private headers. The data blocks contain the specific content used to fill in common or differentiated parameters.

[0129] In one possible implementation, the system device uses the standard header (Head) as the first frame to initiate a service that modifies device parameters, and fills the OTAP private header (OTAP_Head) with common or differentiated parameter information. Encryption-related information is filled into the encrypted private header (P_Head), and the data frame structure is as follows. Figure 4 As shown, the LC Term in the data frame is used to indicate the end of communication, i.e., the termination frame.

[0130] The frame structure information of the standard data header is consistent with the description in the DMR standard communication protocol.

[0131] In one possible implementation, information related to common parameters or differentiated parameters can be filled into the OTAP private header. The frame structure information of the OTAP private header is shown in Table 1. Table 1

[0132]

[0133] The total number of modified parameters (All Para Sum) in the OTAP private header is also used to verify the correctness of data for network devices. Data is considered valid if and only if the sum of the number of differentiated parameters and the number of common parameters of the network device equals the value of the parameter.

[0134] For the public parameter "Valid Time" in the private header, if the time unit is defined as seconds and the step value is 3, then the maximum time is 2. 15 3 = 98301 seconds ≈ 27 hours. The Valid Time field occupies 15 bits. The control device (i.e., the system device) should dynamically calculate the Valid Time for each OTAP broadcast based on the number of devices to be modified on the network and the amount of data of parameters to be transmitted as needed.

[0135] In one possible implementation, calculating the validity period of common parameters requires calculating the amount of data for the differentiated parameters sent by each device to be modified to determine the total time. A complete data transmission and reception includes the system device transmitting a data header frame, a private data header frame, a data frame, and a termination frame, and the device to be modified replying with an acknowledgment frame, i.e., several data frames and 5 other frames. In single-timeslot transmission, a single frame requires 60ms. If transmission is performed in 1 / 2 Confirmed mode, the amount of data carried by a single frame is 10 bytes, and the total amount of data is X bytes. If there are N devices to be modified, the theoretical formula for calculating the validity period of common parameters can be as follows: (1) In the above formula, i Let N represent the i-th device to be modified, N represent the total number of devices to be modified on the network, and X represent the ith device. i The amount of data for the differential parameters of the device to be modified.

[0136] If there are 1000 devices on the network simultaneously, and each device needs to receive 500 bytes of differentiated parameters, then the Valid Time calculated according to the above formula is {1000}. [60 (5 + 500 / 10)]}=3300000ms=3300s. After receiving the common parameter information, a timer with a valid time of 3300s is started. If differentiated parameter information containing the device identifier is received before the timer expires, differentiated OTAP is performed. If differentiated parameter information containing the device identifier is not received after the timer expires, the saved common parameter information is discarded and the process ends.

[0137] In one possible implementation, encryption-related information can be filled into the encrypted private header P_Head. The encrypted private header P_Head of the first message contains the first public encrypted information. The encrypted private header P_Head of the second message contains private encrypted information, and the data portion of the second message contains the second public encrypted information encrypted using the private encrypted information, along with differential parameters. The encrypted private header P_Head of the third message contains the private encrypted information, and the data portion of the third message contains the encrypted second public encrypted information.

[0138] For example, the frame structure information of the encrypted private data header P_Head is shown in Table 2: Table 2

[0139]

[0140] In one possible implementation, some key information in the standard data header frame structure is shown in Table 3: Table 3

[0141]

[0142] After all parameters have been modified through the scheduling device, the common parameters shared by all devices to be modified are first broadcast. Before broadcasting, corresponding messages need to be filled in. The following section combines... Figure 5 The process of filling in the first message is described.

[0143] like Figure 5 As shown, the process of filling in the first message may include the following steps: S301, Fill in the standard data header. Fill in the standard data header according to the meaning of the key fields shown in Table 3.

[0144] S302, Fill in all OTAP headers. Fill in OTAP_Head according to the field meanings shown in Table 1, select OTAP Broadcast Private Header as Header Type, and fill in the contents of other fields according to this type.

[0145] S303, Generate public encrypted information. This public encrypted information includes first public encrypted information and second public encrypted information.

[0146] Generate a public encryption vector, selecting a public encryption algorithm ID and a public encryption key ID known to all devices on the network. Then, select one or more combinations of the public encryption vector, public encryption algorithm ID, and public encryption key ID for caching; this is called the second public encryption information. The uncached public encryption information is called the first public encryption information.

[0147] S304, cache the second public encrypted information. The cached second public encrypted information is sent in subsequent messages, for example, it can be filled into a third message and sent in a second message.

[0148] S305, fill in the encrypted private data header.

[0149] According to Table 2, fill the first public encrypted information into the encrypted private data header P_Head, and fill in the contents of other fields.

[0150] S306 uses all public encryption information to encrypt public parameter information and fills it into the data block.

[0151] S307 sends the first message over the air interface.

[0152] The following will combine Figure 6 Describe the process by which the device to be modified receives the first message, such as... Figure 6 As shown, the steps may include the following: S401 receives the first message via the air interface.

[0153] S402, Parse the standard data header. Parse the standard data header in the received first message according to Table 3.

[0154] S403, Parse the OTAP private header. Analyze the OTAP private header in the first received message according to Table 1.

[0155] S404, Parse the encrypted private header to obtain the first public encrypted information. Parse the encrypted private header in the received first message according to Table 2.

[0156] S405 caches the first public encrypted information.

[0157] S406: Receive data blocks and parse the data blocks to obtain encrypted public parameter information and the validity period of public parameters.

[0158] S407, caches encrypted public parameter information.

[0159] S408, start the timer. The timer's validity period is the validity period of the common parameter.

[0160] The following is combined Figure 7This section describes the process of filling in the second message for a call, such as... Figure 7 As shown, it may include the following steps: S501, Fill in the standard data header. Fill in the standard data header according to Table 3, where G / I selects a call.

[0161] S502, Fill in the OTAP private data header. Fill the OTAP private data header frame OTAP_Head according to Table 1, where the Header Type is selected as OTAP individual call private header, i.e., 00102, and fill in the other field contents according to this type.

[0162] S503 generates private encrypted information.

[0163] Generate a private encryption vector and select the known private encryption algorithm ID and private encryption key ID of the device to be modified. That is, the private encryption information includes the private encryption vector, the private encryption algorithm ID, and the private encryption key ID.

[0164] S504, fill in the encrypted private data header.

[0165] Fill all the private encrypted information into the encrypted private data header according to Table 2.

[0166] S505 combines the differentiated parameters corresponding to the current device identifier with the cached second common encrypted information. For example... Figure 8 As shown, the cached second public encrypted information and differential parameter information are combined to obtain combined data.

[0167] S506 uses private encryption information to encrypt the combined data and fill it into the data block.

[0168] The combined data of the second public encrypted information and the differentiated parameters is encrypted using the aforementioned private encrypted information and then filled into... Figure 4 In the data block frame shown.

[0169] S507 sends a second message via air interface in a call-to-send manner.

[0170] After filling in the second message, it is sent to the corresponding device to be modified via air interface individual call.

[0171] The following is combined Figure 9 This describes the process by which the device to be modified receives the second message of a personal call, such as... Figure 9 As shown, the process may include the following steps: S601 receives the second message of a personal call via the air interface.

[0172] S602, Parse the header parameters. The header includes a standard header frame, an OTAP proprietary header frame, and an encrypted proprietary header frame. Parse each header frame sequentially to obtain the header parameters. For example, parsing the standard header frame yields the target device ID to be modified. Parsing the OTAP proprietary header frame reveals the total number of modified parameters and the number of differentiated parameters. Parsing the encrypted proprietary header frame provides the second public encryption information and the proprietary encryption information.

[0173] S603, determine if the timer has timed out; if it has timed out, end the current process; if it has not timed out, execute S604.

[0174] The timer's validity period is the validity period of the common parameters.

[0175] S604, saves data header parameters.

[0176] S605, verify the second message based on the total number of modified parameters; if the verification is successful, execute S607; if the verification fails, execute S606.

[0177] Compare the total number of modified parameters with the sum of the number of common parameters in the first message and the number of differentiated parameters in the second message. If they match, the verification of the second message is confirmed to be successful; otherwise, the verification fails.

[0178] S606, discard the second message and respond to the failure at the application layer.

[0179] S607, receives data packets.

[0180] After the second message is successfully verified, the system continues to receive subsequent individual call data packets. These data packets contain a combination of second public encrypted information encrypted with private encryption information and differentiated parameter information.

[0181] S608, decrypt combined data. Decrypt combined data using proprietary encrypted information.

[0182] S609, Extract the second public encrypted information. Extract the second public encrypted information from the decrypted combined data.

[0183] S610, Decrypt the public parameter information. Using the first public encrypted information obtained from parsing the first message and the second public encrypted information obtained in S609, the encrypted public parameter information is decrypted to obtain the decrypted public parameter information.

[0184] S611, Modify common parameters and differential parameters.

[0185] Based on the decrypted public parameter information and the decrypted differentiated parameter information, the corresponding parameters of this device are modified.

[0186] S612, response successful.

[0187] After all the parameters to be modified on this device have been modified, a confirmation message indicating successful modification is sent to the application layer, and the application layer sends a successful upgrade message to the system device.

[0188] It should be understood that Figures 1 to 9 The flowcharts or scene diagrams shown are for illustrative purposes only and are not intended to limit the embodiments of this application to the examples illustrated. In fact, those skilled in the art can interpret the embodiments based on... Figures 1 to 9 The examples in the document can be transformed into equivalent ways to obtain more implementations.

[0189] The above text combined Figures 1 to 9 This document describes in detail the communication method provided in the embodiments of this application. The following will combine... Figure 10 The device embodiments of this application are described in detail below. It should be understood that the communication device of this application embodiment can execute the various air interface programming methods of the foregoing embodiments of this application, that is, the specific working processes of the various products below can be referred to the corresponding processes in the foregoing method embodiments.

[0190] In the embodiments described above, the terminal device can execute some or all of the steps in each embodiment; the system device can execute some or all of the steps in each embodiment. These steps or operations are merely examples, and the embodiments of this application can also perform other operations or variations of various operations. Furthermore, the steps can be executed in different orders as presented in the embodiments, and it is not necessary to execute all the operations in the embodiments of this application. Moreover, the sequence number of each step does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0191] Figure 10 This is another schematic block diagram of the communication device provided in the embodiments of this application. The communication device may be a terminal device or system device, including a chip, chip system, or processor, etc., that implements the above-described methods. This communication device can be used to implement the methods described in the above-described method embodiments; for details, please refer to the descriptions in the above-described method embodiments.

[0192] like Figure 10 As shown, the communication device may include one or more processors 110, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 110 may be a general-purpose processor or a dedicated processor, etc.

[0193] In an alternative design, the processor 110 may also store instructions and / or data that can be executed by the processor 110 to cause the communication device to perform the methods described in the above method embodiments.

[0194] In another alternative design, the communication device may include a communication interface 120 for implementing receiving and transmitting functions. For example, the communication interface 120 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0195] Optionally, the communication device may include one or more memories 130, which may store instructions that can be executed on the processor 110, causing the communication device to perform the methods described in the above method embodiments. Optionally, the memories 130 may also store data. Optionally, the processor 110 may also store instructions and / or data. The processor 110 and the memories 130 may be provided separately or integrated together.

[0196] It should be understood that, in one possible design, the steps in the method embodiments provided in this application can be implemented by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0197] In one implementation, the communication device may correspond to the terminal device in the above method embodiments and may be used to execute the various steps and / or processes executed by the terminal device in the above method embodiments. The processor 110 may be used to execute instructions stored in the memory 130, and when the processor 110 executes the instructions stored in the memory, the processor 110 is used to execute the various steps and / or processes of the above method embodiments corresponding to the terminal device.

[0198] In another implementation, the communication device may correspond to the system device in the above method embodiments and may be used to execute the various steps and / or processes executed by the system device in the above method embodiments. The processor 110 may be used to execute instructions stored in the memory 130, and when the processor 110 executes the instructions stored in the memory, the processor 110 is used to execute the various steps and / or processes of the above method embodiments corresponding to the system device.

[0199] It should be understood that the aforementioned processing device can be one or more chips. For example, the processing device can be a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0200] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0201] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0202] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0203] According to the method provided in the embodiments of this application, this application also provides a communication system, which includes the aforementioned system equipment and terminal equipment.

[0204] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the system device or terminal device in any of the foregoing method embodiments.

[0205] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the system device or terminal device in any of the foregoing method embodiments.

[0206] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0207] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0208] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0209] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0210] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0211] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An air interface programming method, characterized in that, Performed by a system device, the method includes: Broadcast a first message, which includes common parameter information for all devices to be modified. The devices to be modified include a first type of devices that contain only common parameters and a second type of devices that contain both common parameters and differentiated parameters. The first message is used to enable the first type of devices to be modified and the second type of devices to modify their device parameters based on the common parameter information. A second message is sent to each of the second type of devices to be modified. The second message includes the differentiated parameter information corresponding to the second type of devices to be modified. The second message is used to enable the second type of devices to modify their own device parameters based on the common parameter information and the differentiated parameter information.

2. The method according to claim 1, characterized in that, The public parameter information includes public parameters, as well as the number of public parameters and / or the validity period of public parameters.

3. The method according to claim 1, characterized in that, The differentiated parameter information includes a device identifier, and the number and parameters of the differentiated parameters of the device to be modified corresponding to the device identifier.

4. The method according to claim 1, characterized in that, The second message also includes first private encryption information, and the differentiated parameter information is sent after being encrypted using the first private encryption information.

5. The method according to claim 1, characterized in that, The first message also includes first public encryption information, wherein the public parameter information is sent after being encrypted using the public encryption information, and the public encryption information includes first public encryption information and second public encryption information.

6. The method according to claim 5, characterized in that, The method further includes sending a third message to a first type of device to be modified, the third message including the second public encryption information.

7. The method according to claim 6, characterized in that, The third message also includes second private encrypted information, which is sent after being encrypted using the second private encrypted information.

8. The method according to claim 5, characterized in that, The second message also includes a second public encrypted message.

9. The method according to claim 8, characterized in that, The second message also includes third private encrypted information, and the second public encrypted information and the differentiated parameter information are sent after being encrypted using the third private encrypted information.

10. The method according to any one of claims 1-9, characterized in that, After broadcasting the first message, the method further includes: Broadcast a first upgrade instruction, which is used to indicate that the first type of devices to be modified have completed the upgrade and the second type of devices to be modified continue to wait for the upgrade.

11. The method according to claim 10, characterized in that, The first upgrade instruction includes the device identifier that the upgrade is complete and the device identifier that is waiting to continue the upgrade.

12. The method according to any one of claims 1-9, characterized in that, After sending the second message, the process also includes sending a second upgrade instruction to each of the second type of devices to be modified, the second upgrade instruction being used to indicate that the upgrade of the second type of devices to be modified is complete.

13. The method according to claim 2, characterized in that, When the public parameter information includes the public parameter validity period, the public parameter validity period is the time required for the entire air interface programming process, calculated based on the number of public parameters, the number of differential parameters of all devices to be modified, and the number of devices to be modified.

14. An air interface programming method, characterized in that, The method, executed by a terminal device, includes: Receive a first message from the system device, the first message including common parameter information of all devices to be modified; Receive a first upgrade instruction from the system device, the first upgrade instruction being used to indicate that the upgrade parameters for a first type of device to be modified, which contains only common parameters, have been sent; When it is determined that its own upgrade parameters have been received based on the first upgrade instruction, the device parameters are modified based on the public parameter information.

15. The method according to claim 14, characterized in that, The first message further includes first public encryption information; after receiving the first message from the system device, the method further includes: Receive a third message from the system device, the third message including second public encrypted information; Based on the first public encryption information and the second public encryption information, the encrypted public parameter information in the first message is decrypted to obtain the decrypted public parameter information.

16. The method according to claim 14, characterized in that, The method further includes: Receive a second message from the system device, the second message including differential parameter information; Based on the common parameter information and the differentiated parameter information, modify its own device parameters.

17. The method according to claim 16, characterized in that, The second message also includes second public encrypted information; after receiving the second message from the system device, the method further includes: The encrypted public parameter information in the first message is decrypted based on the first public encryption information and the second public encryption information, wherein the first public encryption information is contained in the first message.

18. The method according to claim 14, characterized in that, The first upgrade instruction includes the identifier of the first type of device to be modified, which has completed sending upgrade parameters, and / or the identifier of the second type of device to be modified, which needs to wait for further upgrade.

19. The method according to claim 14, characterized in that, Receiving the first upgrade instruction from the system device includes: The system receives a fourth message sent by the system device in a call manner, parses the fourth message to obtain the first upgrade instruction, and the first upgrade instruction is used to indicate that the upgrade parameters of the terminal device have been sent.

20. The method according to claim 16, characterized in that, The method further includes: Receive a second upgrade instruction, which indicates that the upgrade parameters of the terminal device have been sent.

21. A communication device, characterized in that, The device includes at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions to cause the device to perform the method as described in any one of claims 1 to 20.

22. A computer program product, characterized in that, Includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 20.

Images