CN110049478B - Message transmission method, device, equipment and machine readable storage medium - Google Patents

Message transmission method, device, equipment and machine readable storage medium Download PDF

Info

Publication number
CN110049478B
CN110049478B CN201910337481.8A CN201910337481A CN110049478B CN 110049478 B CN110049478 B CN 110049478B CN 201910337481 A CN201910337481 A CN 201910337481A CN 110049478 B CN110049478 B CN 110049478B
Authority
CN
China
Prior art keywords
downlink
message
window
receiving window
lora
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910337481.8A
Other languages
Chinese (zh)
Other versions
CN110049478A (en
Inventor
史弘科
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Information Technologies Co Ltd
Original Assignee
New H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by New H3C Technologies Co Ltd filed Critical New H3C Technologies Co Ltd
Priority to CN201910337481.8A priority Critical patent/CN110049478B/en
Publication of CN110049478A publication Critical patent/CN110049478A/en
Application granted granted Critical
Publication of CN110049478B publication Critical patent/CN110049478B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/02Arrangements for increasing efficiency of notification or paging channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • H04W72/1263Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H04W72/1273Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows of downlink data flows

Abstract

The present disclosure provides a message transmission method, apparatus, device and machine-readable storage medium, the method comprising: after sending an uplink message to the LoRa server, starting a first downlink receiving window; if a downlink message returned by the LoRa server aiming at the uplink message is received in the first downlink receiving window, judging whether the current time meets the closing condition of the first downlink receiving window; if yes, judging whether the whole content of the downlink message is completely received; and if the whole content of the downlink message is not completely received, forbidding closing the first downlink receiving window until the whole content of the downlink message is completely received. By the technical scheme, all contents of the downlink message can be completely received, the downlink message is prevented from being lost, and the reliability of message interaction between the LoRa terminal and the LoRa server is improved.

Description

Message transmission method, device, equipment and machine readable storage medium
Technical Field
The present disclosure relates to the field of communications technologies, and in particular, to a method, an apparatus, a device, and a machine-readable storage medium for message transmission.
Background
The Long range (Long range) technology is a wireless modulation technology used in Long-distance, low-power consumption, low-rate applications, and can be applied to various network technologies, and is a generic name of a Long-distance low-power consumption protocol family. In the LoRa Network, the LoRa terminal and the LoRa server are included, and the LoRa terminal and the LoRa server communicate with each other by using a LoRa Wide Area Network (LoRa Wide Area Network) protocol.
The modes supported by the LoRa terminal include a ClassA mode, a ClassB mode, and a ClassC mode. When the LoRa terminal works in the ClassA mode, after the LoRa terminal sends uplink data to the LoRa server each time, two downlink receiving windows are started, the LoRa server sends downlink data to the LoRa terminal in the two downlink receiving windows, and the LoRa terminal can receive the downlink data in the two downlink receiving windows. When the LoRa terminal works in the ClassB mode, the LoRa terminal may open redundant downlink receiving windows within a preset time, and the LoRa terminal may receive downlink data within the downlink receiving windows. When the LoRa terminal works in the ClassC mode, the LoRa terminal continuously opens the downlink receiving window, and only closes the downlink receiving window when transmitting the uplink data, and the LoRa terminal can receive the downlink data in the downlink receiving window.
Disclosure of Invention
The present disclosure provides a packet transmission method, which is applied to a LoRa terminal, and the method includes:
after sending an uplink message to the LoRa server, starting a first downlink receiving window;
if a downlink message returned by the LoRa server aiming at the uplink message is received in the first downlink receiving window, judging whether the current time meets the closing condition of the first downlink receiving window;
if yes, judging whether the whole content of the downlink message is completely received;
and if the whole content of the downlink message is not completely received, forbidding closing the first downlink receiving window until the whole content of the downlink message is completely received.
The present disclosure provides a packet transmission device, which is applied to a LoRa terminal, the device includes:
the starting module is used for starting a first downlink receiving window after sending an uplink message to the LoRa server;
the judging module is used for judging whether the current time meets the closing condition of the first downlink receiving window or not if the downlink message returned by the LoRa server aiming at the uplink message is received in the first downlink receiving window; if yes, judging whether the whole content of the downlink message is completely received;
and the processing module is used for forbidding closing the first downlink receiving window until all the contents of the downlink message are completely received if all the contents of the downlink message are not completely received.
The present disclosure provides a LoRa terminal, including: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to perform the steps of the message transmission method described above.
The present disclosure provides a machine-readable storage medium having stored thereon machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the steps of the message transmission method described above.
Based on the above technical solution, in the embodiment of the present disclosure, after the LoRa terminal sends the uplink packet to the LoRa server, the first downlink receiving window may be started; and if a downlink message returned by the LoRa server aiming at the uplink message is received in the first downlink receiving window, judging whether the current time meets the closing condition of the first downlink receiving window. When the closing condition is met, the first downlink receiving window is not closed, but whether all the contents of the downlink message are completely received is judged. If not receiving the whole content of the downlink message completely, forbidding closing the first downlink receiving window until completely receiving the whole content of the downlink message. Obviously, based on the above manner, all contents of the downlink message can be completely received, loss of the downlink message is avoided, time overhead and flow overhead caused by message retransmission between the LoRa terminal and the LoRa server are saved, air interface resources are saved, and reliability of message interaction between the LoRa terminal and the LoRa server is improved.
Drawings
In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments of the present disclosure or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and other drawings can be obtained by those skilled in the art according to the drawings of the embodiments of the present disclosure.
Fig. 1A is a schematic diagram of message transmission in a ClassA mode according to an embodiment of the present disclosure;
fig. 1B is a schematic diagram of message transmission in a ClassC mode according to an embodiment of the present disclosure;
fig. 2 is a flowchart of a message transmission method in an embodiment of the present disclosure;
fig. 3A is a schematic diagram of message transmission in a ClassA mode according to an embodiment of the present disclosure;
fig. 3B is a schematic diagram of an LoRa packet according to an embodiment of the present disclosure;
fig. 3C is a schematic diagram of message transmission in a ClassC mode according to an embodiment of the present disclosure;
fig. 3D is a schematic diagram of message transmission in a ClassC mode according to an embodiment of the present disclosure;
fig. 4 is a block diagram of a message transmission apparatus according to an embodiment of the present disclosure;
fig. 5 is a hardware configuration diagram of an LoRa terminal according to an embodiment of the present disclosure.
Detailed Description
The terminology used in the embodiments of the disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein is meant to encompass any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information in the embodiments of the present disclosure, such information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present disclosure. Depending on the context, moreover, the word "if" as used may be interpreted as "at … …" or "when … …" or "in response to a determination".
The LoRa network includes an LoRa terminal and an LoRa server, the LoRa terminal and the LoRa server communicate with each other using LoRaWAN protocol, and the modes supported by the LoRa terminal include a ClassA mode, a ClassB mode, and a ClassC mode.
Fig. 1A is a schematic diagram of message transmission in a ClassA mode. And the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the first type window RX1 is opened after the preset first time (such as DELAY1) is waited. After the first type window RX1 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the first type window RX 1. The window duration of the first type window RX1 may be less than 1 second, and when the closing condition of the first type window RX1 is reached (e.g., the end time of the window duration is reached), the first type window RX1 may be closed.
In addition, after the uplink message is successfully sent, after waiting for a preset second time (e.g., DELAY2), the LoRa terminal opens a second type window RX 2. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the second type window RX 2. The window duration of the second type window RX2 may be less than 1 second, and when the closing condition of the second type window RX2 is reached (e.g., the end time of the window duration is reached), the second type window RX2 may be closed.
The preset first time and the preset second time can be configured according to experience, and values of the preset first time and the preset second time are not limited. Referring to fig. 1A, the preset second time may be greater than the preset first time, for example, the preset second time may be the sum of the preset first time and 1 second.
The window duration of the first type window RX1 and the window duration of the second type window RX2 may be the same or different, and are not limited thereto. For example, the window duration of the first type of window RX1 is less than 1 second, and the window duration of the second type of window RX2 is less than 1 second.
The parameters (such as the message receiving rate) of the LoRa terminal in the first type window RX1 and the parameters (such as the message receiving rate) of the LoRa terminal in the second type window RX2 may be different.
For example, in the first type window RX1, the LoRa terminal may receive the downlink packet at the first packet receiving rate; in the second type window RX2, the LoRa terminal may receive the downlink packet at a second packet receiving rate, where the first packet receiving rate is different from the second packet receiving rate. Of course, the above parameters are not limited to the message receiving rate, and may also be other types of parameters, which are not limited to this.
Fig. 1B is a schematic diagram of message transmission in the ClassC mode. And the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, a second type window RX2 is opened. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the second type window RX 2. For compatibility with the ClassA mode, the window duration of the second type window RX2 may be a preset first time, and when the closing condition of the second type window RX2 is reached (e.g., the end time of the window duration is reached, the closing condition of the second type window RX2 is reached, that is, the opening condition of the first type window RX 1), the second type window RX2 may be closed.
After the uplink message is successfully transmitted and the predetermined first time (such as DELAY1) is waited, the first type window RX1 is opened, i.e. after the second type window RX2 is closed, the first type window RX1 is opened. After the first type window RX1 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the first type window RX 1. The window duration of the first type window RX1 may be less than 1 second, and when the closing condition of the first type window RX1 is reached (e.g., the end time of the window duration, i.e., the opening condition of the second type window RX2 is reached), the first type window RX1 may be closed.
After the first type window RX1 is closed, the second type window RX2 is opened. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the second type window RX 2. The second type window RX2 in ClassC mode is opened for a long time, and the second type window RX2 is closed until the LoRa terminal needs to send an upstream message to the LoRa server.
After closing the second type window RX2, the LoRa terminal may send an uplink message to the LoRa server, and after the uplink message is successfully sent, open the second type window RX 2. After the uplink message is successfully sent and the preset first time is waited, the second type window RX2 is closed, and the first type window RX1 is opened. When the closing condition of the first type window RX1 is reached, the first type window RX1 is closed, and the second type window RX2 is opened until an uplink message needs to be sent to the LoRa server again, and so on.
In the above embodiment, the parameters (such as the message receiving rate) of the LoRa terminal in the first type window RX1 and the parameters (such as the message receiving rate) of the LoRa terminal in the second type window RX2 may be different.
For example, in the first type window RX1, the LoRa terminal may receive the downlink packet at the first packet receiving rate; in the second type window RX2, the LoRa terminal may receive the downlink packet at a second packet receiving rate, where the first packet receiving rate is different from the second packet receiving rate.
Referring to fig. 1A, when the LoRa terminal operates in the ClassA mode, the LoRa terminal may receive, in the first type window RX1, a downlink packet returned by the LoRa server for the uplink packet. However, if the first type window RX1 needs to be closed, all contents of the downlink message are not completely received yet, that is, the LoRa terminal is receiving the downlink message in the first type window RX1, the first type window RX1 needs to be closed, so that the downlink message being received cannot be completely received, that is, the downlink message transmission fails. Thus, the LoRa server needs to send the downlink message to the LoRa terminal again, which wastes air interface resources.
Referring to fig. 1B, when the LoRa terminal operates in the ClassC mode, the LoRa terminal may receive a downlink packet returned by the LoRa server for an uplink packet within the second-type window RX2 (i.e., the first second-type window RX2 in fig. 1B). However, if the second type window RX2 needs to be closed, all contents of the downlink message are not completely received yet, that is, the LoRa terminal is receiving the downlink message in the second type window RX2, the second type window RX2 needs to be closed, so that the downlink message being received cannot be completely received, that is, the downlink message transmission fails. Therefore, the LoRa server needs to send the downlink message to the LoRa terminal again, which wastes air interface resources and results in poor reliability of downlink message transmission.
Referring to fig. 1B, when the LoRa terminal operates in the ClassC mode, the LoRa terminal may receive, in the first type window RX1, a downlink packet returned by the LoRa server for the uplink packet. However, if the first type window RX1 needs to be closed, all contents of the downlink message are not completely received yet, that is, the LoRa terminal is receiving the downlink message in the first type window RX1, the first type window RX1 needs to be closed, so that the downlink message being received cannot be completely received, that is, the downlink message transmission fails. Thus, the LoRa server needs to send the downlink message to the LoRa terminal again, which wastes air interface resources.
In view of the above problem, the present disclosure provides a message transmission method, which may be applied to a network (such as an LoRa network) including an LoRa terminal and an LoRa server, where a message sent by the LoRa terminal to the LoRa server is referred to as an uplink message, and a message sent by the LoRa server to the LoRa terminal is referred to as a downlink message.
In general, the LoRa terminal actively sends an uplink message to the LoRa server, and the LoRa server may send a downlink message (i.e., a response message of the uplink message) to the LoRa terminal after receiving the uplink message.
For example, the LoRa terminal may be a parking space sensor deployed in a parking lot, and when the LoRa terminal detects that an automobile enters a designated position, the LoRa terminal sends an uplink message to the LoRa server, where the uplink message includes information such as a license plate number and entering time. After receiving the uplink message, the LoRa server sends a downlink message to the LoRa terminal, where the downlink message includes information that the LoRa server has received the uplink message. And when the LoRa terminal detects that the automobile leaves the designated position, sending an uplink message to the LoRa server, wherein the uplink message comprises information such as license plate numbers, leaving time and the like. After receiving the uplink message, the LoRa server sends a downlink message to the LoRa terminal, where the downlink message includes information that the LoRa server has received the uplink message. In summary, the LoRa server may perform charging by using the license plate number, the entering time, the leaving time, and other information.
Of course, the application scenario of the parking space sensor is only an example, and the application scenario is not limited.
In the above application scenario, referring to fig. 2, a schematic flow chart of the message transmission method provided by the present disclosure is shown, and the method may be applied to an LoRa terminal, and the method may include the following steps:
step 201, after sending an uplink message to the LoRa server, a first downlink receiving window is started.
Referring to fig. 1A, when the LoRa terminal operates in the ClassA mode, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal starts a first type window RX1 after waiting for a preset first time, that is, the first downlink receiving window is a first type window RX 1.
Referring to fig. 1B, when the LoRa terminal operates in the ClassC mode, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal opens a second type window RX2, that is, the first downlink receiving window is a second type window RX 2. Or, after the LoRa terminal sends the uplink message to the LoRa server successfully, the LoRa terminal starts the first type window RX1 after waiting for the preset first time, that is, the first downlink receiving window is the first type window RX 1.
Step 202, if a downlink message returned by the LoRa server for the uplink message is received in the first downlink receiving window, determining whether the current time meets a closing condition of the first downlink receiving window.
If so, the LoRa terminal may perform step 203. If not, the LoRa terminal may wait until the next time, continue to determine whether the current time meets the closing condition of the first downlink receiving window, and so on until the current time meets the closing condition of the first downlink receiving window, and perform step 203.
After the first downlink receiving window is started, the LoRa terminal may determine whether the current time meets the closing condition of the first downlink receiving window at each time (e.g., each time spaced by 1 ms).
Referring to fig. 1A, the first downlink receive window is a first type window RX1, and the closing condition of the first downlink receive window is a closing condition of a first type window RX 1. For example, assuming that the window duration of the first type window RX1 is 800 msec, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1. Alternatively, from the start of the first type window RX1, it is determined that the current time satisfies the closing condition of the first type window RX1 at the 1000 th millisecond (i.e., the difference between the preset second time and the preset first time). Specifically, since the second type window RX2 needs to be started for the 1000 th millisecond and the first type window RX1 needs to be closed before the second type window RX2 is started, it is determined that the 1000 th millisecond satisfies the closing condition of the first type window RX 1.
Referring to fig. 1B, if the first downlink receive window is the second type window RX2 (i.e. the first second type window RX2 in fig. 1B), the closing condition of the first downlink receive window is the closing condition of the second type window RX 2. For example, assuming that the preset first time is 1200 ms, the timer is started from the start of the second type window RX2, and at the 1200 ms, it is determined that the closing condition of the second type window RX2 is satisfied at the current time.
Referring to fig. 1B, if the first downlink reception window is the first type window RX1, the closing condition of the first downlink reception window may be the closing condition of the first type window RX 1. For example, assuming that the window duration of the first type window RX1 is 800 msec, it may be determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1.
In one example, after receiving a downlink message in a first downlink receiving window, the LoRa terminal may obtain a preamble from the downlink message; and if the message type of the downlink message is determined to be the LoRa type according to the lead code, judging whether the downlink message comprises the address of the LoRa terminal. If the downlink message includes the address of the local LoRa terminal, the LoRa terminal determines that the downlink message is a downlink message returned by the LoRa server for the uplink message. Further, the LoRa terminal determines whether the current time satisfies the closing condition of the first downlink receiving window at each time, and if so, executes step 203.
If the LoRa terminal determines that the downlink message is not a downlink message returned by the LoRa server for the uplink message (i.e., the downlink message is an interference message), the downlink message is processed by using a conventional process. For example, if it is determined that the message type of the downlink message is not the LoRa type according to the preamble, or the downlink message does not include the address of the LoRa terminal, it is determined that the downlink message is not the downlink message returned by the LoRa server for the uplink message.
Step 203, when the current time meets the closing condition of the first downlink receiving window, it is determined whether all the contents of the downlink message are completely received. If not, step 204 may be performed.
When the LoRa server sends the downlink message to the LoRa terminal, the downlink message may include a large amount of contents, which may be referred to as data a, and it is assumed that the data a includes sub-data a1, sub-data a2, and sub-data A3. When sending the downlink message, the LoRa server first sends the downlink message carrying the subdata a1, then sends the downlink message carrying the subdata a2, and then sends the downlink message carrying the subdata A3.
When the current time meets the closing condition of the first downlink receiving window, if the LoRa terminal has received the downlink message carrying the sub-data a1, the sub-data a2, and the sub-data A3 at the current time, it is determined that all the contents of the downlink message are completely received. If the LoRa terminal does not receive the downlink message carrying the sub-data a1, the sub-data a2 or the sub-data A3 at the current time, it is determined that all the contents of the downlink message are not completely received.
Step 204, if the whole content of the downlink message is not completely received, the first downlink receiving window is prohibited from being closed until the whole content of the downlink message is completely received, that is, the downlink message is successfully transmitted.
If the whole content of the downlink message is not completely received, although the current time meets the closing condition of the first downlink receiving window, the LoRa terminal does not close the first downlink receiving window, so that the remaining content of the downlink message is continuously received until the whole content of the downlink message is completely received.
Optionally, in an example, when the LoRa terminal operates in the ClassA mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2. Based on this, after the entire content of the downlink packet is completely received, the first downlink receiving window may also be closed, and the second downlink receiving window is prohibited from being started, that is, the second downlink receiving window is not started any more.
Optionally, in an example, when the LoRa terminal operates in the ClassC mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2. Based on this, after the entire content of the downlink packet is completely received, the first downlink receiving window may also be closed, and the second downlink receiving window is started, that is, the second downlink receiving window needs to be started.
Optionally, in an example, when the LoRa terminal operates in the ClassC mode, the first downlink receive window may be the second type window RX2, and the second downlink receive window may be the first type window RX 1. Based on this, after the entire content of the downlink packet is completely received, the first downlink receiving window may be maintained, and the second downlink receiving window is prohibited from being started, that is, the first downlink receiving window does not need to be closed, the first downlink receiving window is maintained in an open state, and the second downlink receiving window is not started any more.
In one example, after determining whether all the contents of the downlink packet are completely received, if all the contents of the downlink packet are completely received, the first downlink receiving window is closed, and the second downlink receiving window is started in step 203. For example, when the LoRa terminal operates in the ClassA mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2. For another example, when the LoRa terminal operates in the ClassC mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2; alternatively, the first downlink reception window may be the second type window RX2, and the second downlink reception window may be the first type window RX 1.
Based on the above technical scheme, in the embodiment of the present disclosure, all contents of the downlink message can be completely received, loss of the downlink message is avoided, time overhead and flow overhead caused by retransmission of the message between the LoRa terminal and the LoRa server are saved, air interface resources are saved, and reliability of message interaction between the LoRa terminal and the LoRa server is improved. The problem that the LoRa terminal cannot receive the downlink message is avoided, the packet loss problem is solved, the packet loss rate of the downlink message is reduced, the retransmission flow caused by the loss of the downlink message is reduced, and the communication reliability is improved.
The above technical solution is further described below with reference to several specific application scenarios.
Application scenario 1: the LoRa terminal operates in the ClassA mode, and the first downlink receive window may be a first type window RX1, and the second downlink receive window may be a second type window RX 2.
Referring to fig. 3A, the LoRa terminal sends an uplink packet to the LoRa server, and after the uplink packet is successfully sent, waits for a preset first time (e.g., DELAY1), and then opens a first type window RX 1. After the first type window RX1 is opened, the LoRa terminal may receive the downlink packet in the first type window RX 1.
After receiving the downlink message in the first type window RX1, the LoRa terminal determines whether the downlink message is a downlink message returned by the LoRa server for the uplink message. If so, the technical scheme of the disclosure is adopted, and if not, a traditional flow is adopted, so that the traditional flow is not limited. In order to determine whether the downlink packet is a downlink packet returned by the LoRa server for the uplink packet, the following method may be adopted:
referring to fig. 3B, which is a schematic diagram of a LoRa packet, the LoRa packet may include, but is not limited to, a Preamble, a Header, a Payload CRC (Cyclic Redundancy Check), and other fields. The preamble is used to indicate a message type, for example, the preamble of the LoRa message is a specific identifier, and the specific identifier indicates that the message type is the LoRa type. The Header includes NwkSKey (for data verification), AppSKey (for data encryption), DevAddr (address of LoRa terminal), and the like. Payload is the data that is actually transmitted and Payload CRC is a CRC check on Payload data. Of course, the above is only an example of the LoRa message, and the method is not limited thereto.
After receiving the downlink message in the first type window RX1, the LoRa terminal first obtains a preamble from the downlink message. If the message type of the downlink message is determined not to be the LoRa type according to the lead code, it is indicated that the downlink message is not the downlink message returned by the LoRa server for the uplink message, and a traditional flow is adopted.
And if the message type of the downlink message is determined to be the LoRa type according to the lead code, acquiring a DevAddr field from the downlink message. If the DevAddr field carries an address that is not the address of the local LoRa terminal, it indicates that the downlink message is not a downlink message returned by the LoRa server for the uplink message, and a conventional flow is adopted.
If the DevAddr field carries the address of the local LoRa terminal, it indicates that the downlink message is a downlink message returned by the LoRa server for the uplink message, and the LoRa terminal adopts the technical scheme disclosed by the present disclosure.
After determining that the downlink message is the downlink message returned by the LoRa server for the uplink message, the LoRa terminal determines whether the current time meets the closing condition of the first type window RX1 at each time. If not, waiting for the next time, continuing to judge whether the current time meets the closing condition of the first type window RX1, and so on until the current time meets the closing condition of the first type window RX 1.
Assuming that the window duration of the first type window RX1 is 800 msec, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1. Alternatively, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at the 1000 th millisecond (i.e., the difference between the preset second time and the preset first time) from the start of the first type window RX 1.
When the current time meets the closing condition of the first type window RX1, the LoRa terminal may further determine whether all the contents of the downlink packet are completely received. If so, the LoRa terminal closes the first type window RX1 and starts the second type window RX 2. If not, the LoRa terminal prohibits closing the first type window RX1 until the LoRa terminal completely receives the entire contents of the downlink packet.
After receiving the entire contents of the downlink packet completely, as shown in fig. 3A, the LoRa terminal may close the first type window RX1, but the LoRa terminal no longer starts the second type window RX 2.
In summary, in the embodiment of the present disclosure, the LoRa terminal operates in the ClassA mode, which may ensure that the LoRa terminal receives a complete downlink packet in the first type window RX1, and may not cause a packet loss problem. Through the judgment of the lead code and the DevAddr field, the influence of interference messages can be greatly reduced.
Application scenario 2: the LoRa terminal operates in the ClassC mode, and the first downlink receive window may be the second type window RX2, and the second downlink receive window may be the first type window RX 1.
Referring to fig. 3C, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal may open the second type window RX 2. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet within the second type window RX 2. Wherein, for compatibility with the ClassA mode, the window duration of the second type window RX2 may be a preset first time.
After receiving the downlink message in the second type window RX2, the LoRa terminal determines whether the downlink message is a downlink message returned by the LoRa server for the uplink message. If so, the technical scheme of the disclosure is adopted. Specifically, a preamble is obtained from the downlink message, and if the message type of the downlink message is determined to be the LoRa type according to the preamble, the DevAddr field is obtained from the downlink message. If the DevAddr field carries the address of the local LoRa terminal, it indicates that the downlink message is a downlink message returned by the LoRa server for the uplink message.
After determining that the downlink message is the downlink message returned by the LoRa server for the uplink message, the LoRa terminal determines whether the current time meets the closing condition of the second type window RX2 at each time. If not, waiting for the next time, continuing to judge whether the current time meets the closing condition of the second type window RX2, and so on until the current time meets the closing condition of the second type window RX 2.
Wherein, assuming that the preset first time is 1200 ms, the timer is started from the start of the second type window RX2, and at the 1200 ms, it is determined that the current time meets the closing condition of the second type window RX 2.
When the current time meets the closing condition of the second type window RX2, the LoRa terminal may further determine whether all the contents of the downlink packet are completely received. If so, the LoRa terminal closes the second type window RX2 and starts the first type window RX 1. If not, the LoRa terminal prohibits closing the second type window RX2 until the LoRa terminal completely receives the entire content of the downlink packet.
After receiving the entire contents of the downlink packet completely, referring to fig. 3C, the LoRa terminal does not close the second type window RX2, does not start the first type window RX1, and keeps the second type window RX 2.
In summary, in the embodiment of the present disclosure, the LoRa terminal operates in the ClassC mode, which can ensure that the LoRa terminal receives a complete downlink packet in the second type window RX2, and thus the problem of packet loss is not caused. Through the judgment of the lead code and the DevAddr field, the influence of interference messages can be greatly reduced.
Application scenario 3: the LoRa terminal operates in the ClassC mode, and the first downlink receive window may be a first type window RX1, and the second downlink receive window may be a second type window RX 2.
Referring to fig. 3D, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal may open the second type window RX 2. After the second type window RX2 is opened, the LoRa terminal does not receive the downlink message in the second type window RX 2. Wherein, for compatibility with the ClassA mode, the window duration of the second type window RX2 may be a preset first time.
After the uplink message is successfully transmitted and waits for a predetermined first time (e.g., DELAY1), the LoRa terminal may close the second type window RX2 and open the first type window RX 1. After the LoRa terminal opens the first type window RX1, the LoRa terminal may receive the downlink packet in the first type window RX 1.
After receiving the downlink message in the first type window RX1, the LoRa terminal determines whether the downlink message is a downlink message returned by the LoRa server for the uplink message. If so, the technical scheme of the disclosure is adopted. Specifically, a preamble is obtained from the downlink message, and if the message type of the downlink message is determined to be the LoRa type according to the preamble, the DevAddr field is obtained from the downlink message. If the DevAddr field carries the address of the local LoRa terminal, it indicates that the downlink message is a downlink message returned by the LoRa server for the uplink message.
After determining that the downlink message is the downlink message returned by the LoRa server for the uplink message, the LoRa terminal determines whether the current time meets the closing condition of the first type window RX1 at each time. If not, waiting for the next time, continuing to judge whether the current time meets the closing condition of the first type window RX1, and so on until the current time meets the closing condition of the first type window RX 1.
Assuming that the window duration of the first type window RX1 is 800 msec, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1. Alternatively, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at the 1000 th millisecond (i.e., the difference between the preset second time and the preset first time) from the start of the first type window RX 1.
When the current time meets the closing condition of the first type window RX1, the LoRa terminal may further determine whether all the contents of the downlink packet are completely received. If so, the LoRa terminal closes the first type window RX1 and starts the second type window RX 2. If not, the LoRa terminal prohibits closing the first type window RX1 until the LoRa terminal completely receives the entire contents of the downlink packet.
After receiving the entire contents of the downlink packet completely, as shown in fig. 3D, the LoRa terminal closes the first type window RX1 and starts the second type window RX2, that is, the second type window RX2 needs to be started.
In summary, in the embodiment of the present disclosure, the LoRa terminal operates in the ClassC mode, which can ensure that the LoRa terminal receives a complete downlink packet in the first type window RX1, and thus the problem of packet loss is not caused. Through the judgment of the lead code and the DevAddr field, the influence of interference messages can be greatly reduced.
Based on the same concept as the above method, an embodiment of the present disclosure further provides a message transmission apparatus, which may be applied to an LoRa terminal, and as shown in fig. 4, the apparatus may include:
a starting module 41, configured to start a first downlink receiving window after sending an uplink message to the LoRa server;
a determining module 42, configured to determine whether a current time meets a closing condition of a first downlink receiving window if a downlink packet returned by the LoRa server for the uplink packet is received in the first downlink receiving window; if yes, judging whether the whole content of the downlink message is completely received;
a processing module 43, configured to prohibit closing the first downlink receiving window until all the contents of the downlink packet are completely received if all the contents of the downlink packet are not completely received.
Optionally, in an example, the message transmission apparatus further includes (not shown in fig. 4):
a determining module, configured to obtain a preamble from the downlink packet if the downlink packet is received in the first downlink receiving window; if the message type of the downlink message is determined to be the LoRa type according to the lead code, judging whether the downlink message comprises the address of the LoRa terminal;
and if the downlink message comprises the address of the LoRa terminal, determining that the downlink message is the downlink message returned by the LoRa server aiming at the uplink message.
When the LoRa terminal operates in the ClassA mode, the processing module 43 is further configured to:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2.
When the LoRa terminal operates in the ClassC mode, the processing module 43 is further configured to:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2; alternatively, the first and second electrodes may be,
after receiving all the contents of the downlink message completely, keeping the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a second type window RX2, and the second downlink receiving window comprises a first type window RX 1.
The processing module 43 is further configured to:
and after judging whether all the contents of the downlink message are completely received or not, if all the contents of the downlink message are completely received, closing the first downlink receiving window and starting a second downlink receiving window.
In terms of hardware, a schematic diagram of a hardware architecture of the LoRa terminal provided in the embodiment of the present disclosure may specifically refer to fig. 5, and may include: a machine-readable storage medium and a processor, wherein:
the machine-readable storage medium stores machine-executable instructions executable by the processor.
The processor is in communication with the machine-readable storage medium, and reads and executes the machine-executable instructions stored in the machine-readable storage medium to implement the message transmission method.
The disclosed embodiments provide a machine-readable storage medium having stored thereon machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the above-described message transmission method.
Here, a machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and so forth. For example, the machine-readable storage medium may be: a RAM (random Access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the various elements may be implemented in the same one or more software and/or hardware implementations in practicing the disclosure.
As will be appreciated by one skilled in the art, embodiments of the present disclosure may be provided as a method, system, or computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the disclosed embodiments may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
The present disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
Furthermore, these computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The above description is only an example of the present disclosure and is not intended to limit the present disclosure. Various modifications and variations of this disclosure will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure should be included in the scope of the claims of the present disclosure.

Claims (12)

1. A message transmission method is characterized in that the method is applied to an LoRa terminal, and the method comprises the following steps:
after sending an uplink message to the LoRa server, starting a first downlink receiving window;
if a downlink message returned by the LoRa server aiming at the uplink message is received in the first downlink receiving window, judging whether the current time meets the closing condition of the first downlink receiving window;
if yes, judging whether the whole content of the downlink message is completely received;
and if the whole content of the downlink message is not completely received, forbidding closing the first downlink receiving window until the whole content of the downlink message is completely received.
2. The method of claim 1, further comprising:
if a downlink message is received in the first downlink receiving window, acquiring a lead code from the downlink message; if the message type of the downlink message is determined to be the LoRa type according to the lead code, judging whether the downlink message comprises the address of the LoRa terminal;
and if the downlink message comprises the address of the LoRa terminal, determining that the downlink message is the downlink message returned by the LoRa server aiming at the uplink message.
3. The method of claim 1,
when the LoRa terminal operates in the ClassA mode, the method further includes:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2.
4. The method of claim 1,
when the LoRa terminal operates in the ClassC mode, the method further includes:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2; or the like, or, alternatively,
after receiving all the contents of the downlink message completely, keeping the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a second type window RX2, and the second downlink receiving window comprises a first type window RX 1.
5. The method of claim 1, further comprising:
and after judging whether all the contents of the downlink message are completely received or not, if all the contents of the downlink message are completely received, closing the first downlink receiving window and starting a second downlink receiving window.
6. A message transmission apparatus, applied to a LoRa terminal, the apparatus comprising:
the starting module is used for starting a first downlink receiving window after sending an uplink message to the LoRa server;
the judging module is used for judging whether the current time meets the closing condition of the first downlink receiving window or not if the downlink message returned by the LoRa server aiming at the uplink message is received in the first downlink receiving window; if yes, judging whether the whole content of the downlink message is completely received;
and the processing module is used for forbidding closing the first downlink receiving window until all the contents of the downlink message are completely received if all the contents of the downlink message are not completely received.
7. The apparatus of claim 6, further comprising:
a determining module, configured to obtain a preamble from the downlink packet if the downlink packet is received in the first downlink receiving window; if the message type of the downlink message is determined to be the LoRa type according to the lead code, judging whether the downlink message comprises the address of the LoRa terminal;
and if the downlink message comprises the address of the LoRa terminal, determining that the downlink message is the downlink message returned by the LoRa server aiming at the uplink message.
8. The apparatus of claim 6,
when the LoRa terminal operates in the ClassA mode, the processing module is further configured to:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2.
9. The apparatus of claim 6,
when the LoRa terminal operates in the ClassC mode, the processing module is further configured to:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2; alternatively, the first and second electrodes may be,
after receiving all the contents of the downlink message completely, keeping the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a second type window RX2, and the second downlink receiving window comprises a first type window RX 1.
10. The apparatus of claim 6, wherein the processing module is further configured to:
and after judging whether all the contents of the downlink message are completely received or not, if all the contents of the downlink message are completely received, closing the first downlink receiving window and starting a second downlink receiving window.
11. A LoRa terminal, comprising: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to perform the method steps of any of claims 1-5.
12. A machine-readable storage medium having stored thereon machine-executable instructions which, when invoked and executed by a processor, cause the processor to perform the method steps of any of claims 1-5.
CN201910337481.8A 2019-04-25 2019-04-25 Message transmission method, device, equipment and machine readable storage medium Active CN110049478B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910337481.8A CN110049478B (en) 2019-04-25 2019-04-25 Message transmission method, device, equipment and machine readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910337481.8A CN110049478B (en) 2019-04-25 2019-04-25 Message transmission method, device, equipment and machine readable storage medium

Publications (2)

Publication Number Publication Date
CN110049478A CN110049478A (en) 2019-07-23
CN110049478B true CN110049478B (en) 2021-11-02

Family

ID=67279255

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910337481.8A Active CN110049478B (en) 2019-04-25 2019-04-25 Message transmission method, device, equipment and machine readable storage medium

Country Status (1)

Country Link
CN (1) CN110049478B (en)

Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102405613A (en) * 2009-04-21 2012-04-04 捷讯研究有限公司 Methods and apparatus to use window alignment information to process acknowledgment information associated with transmitted data blocks
CN103228053A (en) * 2012-01-29 2013-07-31 中兴通讯股份有限公司 Random access method of multi-carrier system, base station, as well as mobile terminal and random access system
EP2629453A1 (en) * 2012-02-20 2013-08-21 Telefonaktiebolaget L M Ericsson (Publ) Method, apparatus and system for setting a size of an event correlation time window
CN106162844A (en) * 2016-06-03 2016-11-23 西安电子科技大学 Implementation method based on the MAC protocol for wireless sensor networks of LoRa
CN107015930A (en) * 2017-03-31 2017-08-04 深圳市亿兆互联技术有限公司 A kind of usb expansion device and method based on Lora technologies
CN107147415A (en) * 2017-04-05 2017-09-08 深圳市亿兆互联技术有限公司 A kind of voice intercom device and method based on LORA technologies
CN107635254A (en) * 2017-09-22 2018-01-26 新华三技术有限公司 A kind of data transmission method and device
CN107708199A (en) * 2017-09-26 2018-02-16 南京哈卢信息科技有限公司 A kind of method for improving the descending reliability of low-consumption wireless Cellular Networks
CN107801172A (en) * 2017-09-18 2018-03-13 暨南大学 LoRa gateways with adaptive channel function and the network system based on LoRa gateways
CN108093379A (en) * 2018-02-01 2018-05-29 深圳市泰比特科技有限公司 A kind of train door monitor terminal and its system based on LoRa
EP3331187A1 (en) * 2016-12-05 2018-06-06 Alcatel Lucent Improved control of packet retransmission for low power wide area network
CN108235404A (en) * 2016-12-22 2018-06-29 上海未来宽带技术股份有限公司 A kind of realization method and system of wireless network relaying
CN108449786A (en) * 2018-03-23 2018-08-24 深圳市华奥通通信技术有限公司 A kind of signal transmit-receive method and system of multi-time-windows
CN109362066A (en) * 2018-11-01 2019-02-19 山东大学 A kind of real-time Activity recognition system and its working method based on low-power consumption wide area network and capsule network
CN109450714A (en) * 2018-12-28 2019-03-08 万能 A kind of LoRa terminal node and its data transmission method
CN109617744A (en) * 2019-01-10 2019-04-12 电子科技大学 A kind of LoRa minimum PingSlot several prediction techniques

Patent Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102405613A (en) * 2009-04-21 2012-04-04 捷讯研究有限公司 Methods and apparatus to use window alignment information to process acknowledgment information associated with transmitted data blocks
CN103228053A (en) * 2012-01-29 2013-07-31 中兴通讯股份有限公司 Random access method of multi-carrier system, base station, as well as mobile terminal and random access system
EP2629453A1 (en) * 2012-02-20 2013-08-21 Telefonaktiebolaget L M Ericsson (Publ) Method, apparatus and system for setting a size of an event correlation time window
CN106162844A (en) * 2016-06-03 2016-11-23 西安电子科技大学 Implementation method based on the MAC protocol for wireless sensor networks of LoRa
EP3331187A1 (en) * 2016-12-05 2018-06-06 Alcatel Lucent Improved control of packet retransmission for low power wide area network
CN108235404A (en) * 2016-12-22 2018-06-29 上海未来宽带技术股份有限公司 A kind of realization method and system of wireless network relaying
CN107015930A (en) * 2017-03-31 2017-08-04 深圳市亿兆互联技术有限公司 A kind of usb expansion device and method based on Lora technologies
CN107147415A (en) * 2017-04-05 2017-09-08 深圳市亿兆互联技术有限公司 A kind of voice intercom device and method based on LORA technologies
CN107801172A (en) * 2017-09-18 2018-03-13 暨南大学 LoRa gateways with adaptive channel function and the network system based on LoRa gateways
CN107635254A (en) * 2017-09-22 2018-01-26 新华三技术有限公司 A kind of data transmission method and device
CN107708199A (en) * 2017-09-26 2018-02-16 南京哈卢信息科技有限公司 A kind of method for improving the descending reliability of low-consumption wireless Cellular Networks
CN108093379A (en) * 2018-02-01 2018-05-29 深圳市泰比特科技有限公司 A kind of train door monitor terminal and its system based on LoRa
CN108449786A (en) * 2018-03-23 2018-08-24 深圳市华奥通通信技术有限公司 A kind of signal transmit-receive method and system of multi-time-windows
CN109362066A (en) * 2018-11-01 2019-02-19 山东大学 A kind of real-time Activity recognition system and its working method based on low-power consumption wide area network and capsule network
CN109450714A (en) * 2018-12-28 2019-03-08 万能 A kind of LoRa terminal node and its data transmission method
CN109617744A (en) * 2019-01-10 2019-04-12 电子科技大学 A kind of LoRa minimum PingSlot several prediction techniques

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Enhanced flexible LoRaWAN node for industrial IoT;Emiliano Sisinni 等;《2018 14th IEEE International Workshop on Factory Communication Systems (WFCS)》;20180705;全文 *
基于LoRa的LPWAN节能技术研究;虞阁飞;《万方数据库》;20181218;全文 *

Also Published As

Publication number Publication date
CN110049478A (en) 2019-07-23

Similar Documents

Publication Publication Date Title
CN108353268B (en) System and method for improving support for virtual Subscriber Identity Modules (SIMs) in a multi-SIM wireless communication device
CN101742697B (en) Method of improving a semi-persistent scheduling (sps) resource release process and related apparatus
US9706435B2 (en) Method and system for dynamically changing upper bound on data packet size in wireless communication networks
CN110996346B (en) Downlink message trajectory tracking method and device and computer readable storage medium
CN110832800B (en) Method and device for HARQ feedback enhancement, communication equipment and storage medium
CN102348173B (en) Method of handling emergency session and related communication device
CN110049478B (en) Message transmission method, device, equipment and machine readable storage medium
CN112866125B (en) Downlink data transmission method and device
CN107409427A (en) The data transmission method and device of a kind of data service
CN108141901A (en) The method and terminal of control service connection
CN113645103B (en) Method and device for detecting communication link abnormity between video monitoring platform and front-end equipment
CN109845346B (en) Method for awakening wireless device, transmitting device and receiving device
CN107547412B (en) STP calculation method and device
CN113994615B (en) HARQ codebook processing method and device, communication equipment and storage medium
KR101952793B1 (en) Improvements to Subscriber Identity Module (SIM) Access Profile (SAP)
EP2632192A1 (en) Methods, apparatuses and systems for accessing multi-operator core network
JP7166337B2 (en) DATA GENERATION METHOD, LOGICAL CHANNEL SETTING METHOD, TERMINAL DEVICE AND CHIP
WO2017193262A1 (en) Handling packet acknowledgments during tune-aways on mobile devices
CN111294856B (en) Shared flow terminal identification method, device, equipment and readable storage medium
KR101153243B1 (en) From tactical communication the data reference system which leads a priority readjustment and the use method
CN110945948A (en) Downlink control information transmission method and device, communication equipment and storage medium
KR20220140617A (en) UPLINK TRANSMISSION PROCESSING METHOD AND APPARATUS, AND COMMUNICATION DEVICE, AND STORAGE MEDIUM
CN113169826A (en) HARQ-ACK information transmission method and device and communication equipment
EP2887727A1 (en) Method and device for congestion control
US9767286B2 (en) Electronic module for making a message accessible to a targeted operating system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20230531

Address after: 310052 11th Floor, 466 Changhe Road, Binjiang District, Hangzhou City, Zhejiang Province

Patentee after: H3C INFORMATION TECHNOLOGY Co.,Ltd.

Address before: 310052 Changhe Road, Binjiang District, Hangzhou, Zhejiang Province, No. 466

Patentee before: NEW H3C TECHNOLOGIES Co.,Ltd.

TR01 Transfer of patent right