Low-latency service transmission method, access point and storage medium

Abstract

The embodiment of the invention relates to a wireless communication technology, and discloses a low-delay service transmission method, an access point and a storage medium. In the invention, the access point equipment which is also in a multi-AP cooperative transmission mechanism is used as a transmission opportunity holder; a multi-user request sending frame used for inquiring low-delay service information is sent to each transmission opportunity waiting party in a multi-AP cooperation set, and distribution of transmission opportunities is determined through feedback clear sending frames carrying the low-delay service information; and when serving as a transmission opportunity waiting party, generating low-latency service information according to the low-latency service existing in the station equipment or the station equipment associated with the station equipment, and sending a clear sending frame carrying the low-latency service information to the transmission opportunity holder. By reasonably distributing the transmission opportunities, the actual demand of current low-delay service processing is met, the characteristics of multi-AP cooperation and the low-delay service are fully fused, and efficient and stable transmission of the low-delay service in a wireless network is achieved.

Description

Technical Field

[0001] The embodiments of the present invention relate to wireless communication technology, and in particular to a low-latency service transmission method, access point and storage medium. Background Art

[0002] Low-latency services are types of services that require extremely low data transmission delay and extremely short response time in network communications. This type of service has extremely high real-time requirements, and any slight delay may have a significant impact on the service effect. Typical low-latency services include online games, real-time audio and video calls, financial transactions, remote control, etc. In these applications, the real-time and stability of data transmission are directly related to user experience and business efficiency. Therefore, low-latency services have extremely high requirements for network performance, and network equipment and systems are required to provide fast and reliable data transmission services. In order to meet these needs, modern network technology continues to develop and innovate, including the use of efficient coding algorithms, optimization of network protocols, and increased transmission speeds, in order to minimize data transmission delays and improve the performance and experience of low-latency services.

[0003] The inventors have discovered that there are at least the following problems in the related art: the multi-AP collaborative transmission mechanism aims to improve the performance of the entire wireless network system by enhancing the collaboration capabilities between APs, but how to coordinate and respond to low-latency services in each device in the multi-AP collaborative transmission mechanism is still a technical gap in the field. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a low-latency service transmission method, access point and storage medium, so that the characteristics and advantages of multi-AP collaboration technology are combined, the actual needs of current low-latency service processing are met by reasonably allocating transmission opportunities, and the characteristics of multi-AP collaboration and low-latency services are fully integrated, so as to realize efficient and stable transmission of low-latency services in wireless networks.

[0005] To solve the above technical problems, an embodiment of the present invention provides a low-latency service transmission method, which is applied to an access point device in a multi-AP collaborative transmission mechanism, including: when acting as a transmission opportunity holder, sending a multi-user request to send frame for inquiring about low-latency service information to each transmission opportunity waiting party in a multi-AP collaborative set, and determining the allocation of transmission opportunities through a clear to send frame carrying the low-latency service information fed back by each of the transmission opportunity waiting parties; when acting as a transmission opportunity waiting party, after receiving the multi-user request to send frame, generating the low-latency service information according to the low-latency service existing in itself or its associated site device, and sending the clear to send frame carrying the low-latency service information to the transmission opportunity holder.

[0006] An embodiment of the present invention also provides an access point, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned low-latency service transmission method.

[0007] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, which implements the above-mentioned low-latency service transmission method when executed by a processor.

[0008] In the embodiment of the present invention, the access point device which is also in the mechanism of multi-AP cooperative transmission, when acting as a transmission opportunity holder, sends a multi-user request to send frame for inquiring low-latency service information to each transmission opportunity waiting party in the multi-AP cooperative set, and determines the allocation of transmission opportunities through the clear to send frame carrying low-latency service information fed back by each transmission opportunity waiting party; when acting as a transmission opportunity waiting party, after receiving the multi-user request to send frame, it generates low-latency service information according to the low-latency service existing in itself or its associated site device, and sends a clear to send frame carrying low-latency service information to the transmission opportunity holder. The actual needs of current low-latency service processing are met by reasonably allocating transmission opportunities, the characteristics of multi-AP collaboration and low-latency service are fully integrated, and efficient and stable transmission of low-latency service in wireless networks is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0010] Figure 1 is a flow chart of a low-latency service transmission method provided according to an embodiment of the present invention;

[0011] Figure 2 is a schematic diagram of a frame exchange mechanism related to multi-user requests provided according to an embodiment of the present invention;

[0012] Figure 3 is a schematic diagram of a frame exchange mechanism when a block confirmation frame with return information carried in a reserved bit is provided according to an embodiment of the present invention;

[0013] Figure 4 It is a schematic diagram of a frame exchange mechanism when a site device is a receiver of a low-latency service according to an embodiment of the present invention;

[0014] Figure 5is a schematic diagram of a frame exchange mechanism when a return frame is a CF-End frame carrying return information according to an embodiment of the present invention;

[0015] Figure 6 It is a schematic diagram of a frame exchange mechanism for notifying the completion of low-latency service transmission provided according to an embodiment of the present invention;

[0016] Figure 7 It is a schematic structural diagram of an access point according to another embodiment of the present invention. DETAILED DESCRIPTION

[0017] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0018] An embodiment of the present invention relates to a low-latency service transmission method, which can be applied to any access point device in a multi-AP collaborative transmission mechanism. In this embodiment, the access point device, which is also in the multi-AP collaborative transmission mechanism, when acting as a transmission opportunity holder, sends a multi-user request to send frame for inquiring low-latency service information to each transmission opportunity waiting party in the multi-AP collaborative set, and determines the allocation of transmission opportunities through the clear send frame carrying low-latency service information fed back by each transmission opportunity waiting party; when acting as a transmission opportunity waiting party, after receiving the multi-user request to send frame, it generates low-latency service information according to the low-latency service existing in itself or its associated site device, and sends a clear send frame carrying low-latency service information to the transmission opportunity holder. By reasonably allocating transmission opportunities to meet the actual needs of current low-latency service processing, the characteristics of multi-AP collaboration and low-latency services are fully integrated, and efficient and stable transmission of low-latency services in wireless networks is realized. The following will propose corresponding low-latency service processing mechanisms for different scenarios. It is particularly noted here that the present invention does not impose restrictions on the signaling interaction method between the access point (AP) and the station equipment (STA) within the same basic service set (BSS). In other words, when a station equipment has a low-latency service to be transmitted, the AP associated with it is aware of this situation by default. As for the way in which the STA reports its low-latency service, this embodiment does not make specific provisions or restrictions. The following is a specific description of the implementation details of the low-latency service transmission method of this embodiment. The following content is only the implementation details provided for the convenience of understanding and is not necessary for the implementation of this solution.

[0019] like Figure 1 As shown, when the access point device in the multi-AP cooperative transmission mechanism acts as a transmission opportunity holder, in step 101, a multi-user request transmission frame for inquiring low-latency service information is sent to each transmission opportunity waiting party in the multi-AP cooperative set.

[0020] The mechanism of multi-AP cooperative transmission is a huge and complex concept. There are many possible situations and corresponding coping measures under the mechanism of multi-AP cooperative transmission, such as: multi-AP discovery, which is used to exchange relevant information between APs supporting multi-AP cooperation; coordinated agreement, which is used to reach an agreement between APs supporting multi-AP cooperation and form a multi-AP set (also called Multi-AP group or multi-AP coordination set); there will be a coordinator AP (referred to as Coordinator AP, or Master AP) in the multi-AP set, which is used to coordinate the coordination work between the devices in the entire multi-AP (Multi-AP). Usually, the Coordinator AP is the AP that initiates the establishment of the multi-AP coordination set; other participating APs in the Multi-AP set are called coordinated APs (also called slave APs); pre-transmission is used for some preparations before the multi-AP cooperative transmission is turned on, such as coordinated beamforming, joint transmission, etc. Some configuration operations of functions such as Multi-AP Coordinated Transmission; Multi-AP Coordinated Transmission is initiated by a Sharing AP. After multiple APs reach an agreement to form a Multi-AP set, the AP that successfully obtains the transmission opportunity (TransmissionOpportunity, referred to as TXOP) and starts the multi-AP coordinated operation is called the transmission opportunity holder (Sharing AP). It is the coordinator of the entire multi-AP transmission and is responsible for managing and controlling the transmission process. The other APs in the Multi-AP set are called transmission opportunity waiting parties (Shared AP). These APs are coordinated by Sharing AP and actually participate in multi-AP transmission. They are responsible for completing data transmission tasks under the guidance of Sharing AP.

[0021] The following will give an example of the specific way in which the frame exchange mechanism (frameexchange) of multi-user request to send / clear to send (MU-RTS / CTS) is extended to the coordinated time division multiple access mechanism in multi-AP collaboration, where the coordinated time division multiple access (Coordinated-TDMA, C-TDMA can also be called C-OFDMA) mechanism means that in the multi-AP collaboration mechanism, the AP that obtains the TXOP (i.e., Sharing AP) can share the TXOP with other APs in need (SharedAP) in the multi-AP collaboration set for itself or its associated STA to transmit urgent or required services.

[0022] The frame exchange mechanism related to multi-user requests is as follows Figure 2 As shown in the example, Sharing AP can send a multi-user request to send (MU-RTS) frame carrying an indication for inquiring about low-latency service information (LL Poll for short, where LL is the abbreviation of low-latency service) to the relevant Shared APs, namely, transmission opportunity waiting party 1 and transmission opportunity waiting party 2 (Shared AP1 and Shared AP2). Shared AP1 and Shared AP2 receive the MU-RTS frame inquiring whether there is low-latency service to be transmitted. After a certain period of time, they simultaneously feedback a Clear to Send (CTS) frame, in which the Shared AP with low-latency service (Shared AP2) can carry low-latency service information (LL Notification) to inform Sharing AP. After receiving CTS, Sharing AP can give priority to allocating TXOP to SharedAP2 with low-latency service to be processed according to actual conditions, and carry relevant information through a Trigger frame. After receiving the Trigger frame that allocates TXOP to it, Shared AP2 can send a Trigger frame for low-latency service to the associated STA ( Figure 2 In the example above, the STA of SharedAP2 has a low-latency service to be transmitted. If Shared AP2 itself has a low-latency service to be transmitted, the low-latency service can be directly transmitted and this step can be omitted. After receiving the notification that the low-latency service can be sent, the STA sends a data packet of the low-latency service, and after receiving the block acknowledgment (BA) frame fed back by Shared AP2, Shared AP2 needs to send a notification frame to Sharing AP to notify Sharing AP that the low-latency service transmission is completed and the TXOP information can be returned.

[0023] The following examples will illustrate the structural design of two different types of multi-user request sending frames:

[0024] The overall design idea of ​​the first type of design is to utilize the traditional MU-RTS (Multi-User Request to Send) frame structure and improve it on this basis. The indication for inquiring low-latency service information is carried by the reserved bits in the multi-user request to send frame, and its function is expanded by multiplexing its reserved bits to adapt to the needs of low-latency service inquiries in the multi-AP collaboration mechanism. Specifically, the main structure and type identification of the MU-RTS frame are retained to ensure its compatibility with the traditional MU-RTS frame, and at the same time, new information is conveyed by modifying or reallocating several reserved bits without adding additional complexity.

[0025] The existing MU-RTS frame contains several unused reserved bits, such as UL length, GI and HE-LTF Type, MU-MIMO HE-LTF Mode, Number of HE-LTF symbols and Midamble periodicity, UL STBC, LDPC Extra Symbol Segment, AP Tx Power, Pre-FEC Padding Factor, PE Disambiguity, UL Spatial Reuse, Doppler, UL HE-SIG A2 Reserved and reserved fields in the common information field (Common infofield); and UL FEC coding type, UL HE-MCS, UL DCM, SS allocation RA-RU information, UL target received power (ie UL FEC CodingType, UL HE-MCS, UL DCM, SS Allocation RA-RU information, UL Target Receive Power) fields and reserved fields. One of these bits (or a combination of multiple bits to provide greater flexibility) can be used to mark whether the MU-RTS frame carries information asking for low-latency services.

[0026] For example, in the first type of design, when one or more of the above bits are set to 1, it means that this MU-RTS frame is not only used for the purpose of sending regular requests, but also additionally asks the relevant APs in the multi-AP collaboration set whether they have low-latency service requirements. The relevant AP can decide whether to report the status of its low-latency service based on this information in the response (CTS or similar frame). The advantage of this design structure lies in its low implementation cost and wide compatibility. For devices with previous Wifi versions, the above reserved bits will not be parsed, while new versions or devices that support multi-AP collaboration will identify the corresponding bits and obtain relevant information about low-latency services. This solution is directly extended based on the existing MU-RTS frame structure without the introduction of a new frame type or complex processing logic.

[0027] The overall design idea of ​​the second type of design is to design a new MU-RTS frame type specifically for the multi-AP collaboration mechanism, that is, a multi-AP dedicated MU-RTS frame, which can optimize the resource allocation and scheduling strategy in the multi-AP environment by defining a new trigger frame. The second type of design has an indication field for inquiring about low-latency service information in the trigger type subfield in the common information field in the multi-user request sending frame. That is, a new type indication is added to the Trigger Type Subfield in the common information (CommonInfo) field of the new type of MU-RTS frame, and the specific value can be any reserved bit from the 8th to the 15th bit.

[0028] In the second type of design, the multi-AP proprietary MU-RTS frame will contain a series of fields customized for multi-AP collaboration, including but not limited to AP identifiers, collaboration mode indicators, resource allocation information, etc. In particular, for the inquiry of low-latency service requirements, this solution provides two implementation methods: one method is similar to the first design idea mentioned above, reusing the traditional reserved bits, but here, these reserved bits are explicitly reserved in the newly defined MU-RTS frame structure to indicate specific inquiry intentions, such as asking whether there is a low-latency service requirement to be transmitted. Another more concise way is to make an implicit inquiry, that is, not directly setting up a specific bit to indicate the inquiry of low-latency services, but when sending this proprietary MU-RTS frame, it implies the intention to ask all relevant APs whether they have low-latency service requirements. When responding, the receiving end decides whether to report its low-latency service status based on this implicit inquiry.

[0029] When the access point device in the multi-AP collaborative transmission mechanism acts as a transmission opportunity waiting party, in step 102, after receiving a multi-user request to send frame, it generates low-latency service information according to the low-latency service existing in itself or its associated site device, and sends a clear-to-send frame carrying the low-latency service information to the transmission opportunity holder, so that the transmission opportunity holder can determine the allocation of transmission opportunities through the clear-to-send frames carrying the low-latency service information fed back by each transmission opportunity waiting party.

[0030] The following examples illustrate two different structural designs of clear-to-send frames that carry low-latency service information:

[0031] The overall design idea of ​​the first type of design is to utilize the traditional CTS (clear to send) frame structure and improve it on this basis, and to achieve the indication of low-latency services by changing the meaning of one or more bits. In the traditional CTS frame used to reply to the MU-RTS frame, there are 8 bits in the frame control field that have no practical significance and are uniformly configured to 0. They are named: ToDS, From DS, More Frag, Retry, Power Management, More data, Protected frame fields and +HTC subfields. On this basis, one or more of the above 8 bits can be selected to carry the indication information of low-latency services. In an example, the low-latency service information in the clear to send frame is carried by the power management subfield in the frame control field to indicate the existence of low-latency services. If the current AP has low-latency services to be processed, the power management subfield in the CTS frame can be configured to 1. This solution has the advantages of reusing existing structures, good compatibility, and low modification costs. Optionally, another way is to set all the above-mentioned 8 bits that do not play a practical role to 1 to indicate that there is a low-latency service to be transmitted in the current device, that is, the To DS, From DS, More Frag, Retry, Power Management, More data, Protected frame and +HTC subfields in the Framecontrol field in the CTS frame are all set to 1, indicating that there is a low-latency service to be transmitted in the current device. This solution can reduce the impact of interference and is simple and easy to implement.

[0032] The overall design idea of ​​the second type of design is to design a new type of CTS frame specifically for transmission within a multi-AP collaboration mechanism. This clears the control frame extension field in the frame control field in the send frame, which is used to carry low-latency service information, so that this CTS frame can not only carry an indication of the existence of low-latency services, but also add other information about low-latency services, and implicitly indicates that the sender of the CTS frame is an AP. This new type of CTS frame can be used as one of the extended control frames, and its structure can follow the structure of CTS, but its Framecontrol field can be modified to some extent, as shown in Table 1 below:

[0033] The Protocol version is filled in according to the actual situation. The values ​​of the Type, Subtype, and Control frame extension fields are as follows. When the Control Frame Extension field is configured to 1100, it indicates a new type of CTS, namely, M-AP CTS. Optionally, other reserved fields can also be used to indicate M-AP CTS, such as one of 1101-1111. As shown in Table 2 below:

[0034]

[0035] The B12-B15 bit in the Control frame field of the M-AP CTS is configured to 0 by default. Optionally, these 4 bits can also be used to convey other information, for example, one or more or all 4 bits can be used to indicate the existence of low-latency services. In addition, other information indications related to low-latency services can also be added, such as adding timing information (timing information) of low-latency services, such as the duration of the service, the maximum acceptable delay, the degree of urgency and other timing-related information, so as to better coordinate between APs. In addition, priority information of low-latency services can also be added to the frame to facilitate priority scheduling when multiple services are concurrent, such as using a field to indicate the priority level of the service. The second design scheme has a strong information carrying capacity, can provide more service information, and is conducive to multi-AP collaboration, but it requires the design of a new frame structure, which may increase the implementation complexity and compatibility issues.

[0036] In one example, in order to ensure that the AP or STA device in the OBSS can effectively identify the data transmission of low-latency services, an optimized strategy is to embed the indication of low-latency services into the PHY Preamble (physical layer preamble), that is, the low-latency service information is carried by the physical layer preamble. This allows the OBSS device to promptly perceive the existence of low-latency service traffic, thereby triggering the corresponding avoidance mechanism or optimizing the transmission strategy. This can not only significantly reduce the transmission delay of low-latency services, but also effectively maintain the stability and efficiency of the entire network environment. Specifically, an identifier (LL Notification) for the existence of low-latency services can be configured in the HE-SIG-A of the preamble. The notification is used to indicate that the current device contains low-latency services to be transmitted. After detecting the LL Notification, the Sharing AP can allocate the right to use the TXOP according to actual conditions. LL Notification can be configured in the reserved bit of HE-SIG-A1 subfield or HE-SIG-A2 subfield, such as the B14 bit of HE-SIG-A1 subfield. For example, when the bit is configured to 0, it means that the current PPDU contains low-latency services. When the bit is 1, it means that there is no low-latency service. In some cases, for EHT Preamble, LL Notification can be configured in EHT-SIG. In some cases, for the Preamble of the next-generation wifi standard, LL Notification can be configured in the beacon (signal, SIG) field or other fields therein.

[0037] In one example, when acting as a transmission opportunity waiting party, after receiving a multi-user request to send frame, when there is no low-latency service in itself or its associated site device, no clear to send frame is fed back. That is, when the MU-RTS sent by the Sharing AP contains information (LL Poll) asking whether there is a low-latency service. If the Shared AP has a low-latency service, a CTS frame is fed back; if not, no feedback is given. At this time, the CTS frame can use the existing CTS frame in the protocol without any modification. An LL Poll field is added to the MU-RTS frame to inquire whether there is a low-latency service. The design of the MU-RTS frame can follow the design mentioned above. After receiving the MU-RTS frame, if there is a low-latency service, the Shared AP sends a CTS frame; if not, the CTS frame is not sent.

[0038] In addition to the 1 bit mentioned in the text, the indication of low-latency services (LL Notification) can also be expressed in other forms, such as the AC category (Access Category) corresponding to the low-latency service. The AC category may be a new AC category designed for low-latency services, or an existing category with a higher priority such as AC_VO, AC_VI, etc. It can also be the priority or priority-related parameters corresponding to the low-latency service. However, if the indication of low-latency services is expressed in the above forms, more bits are needed for indication.

[0039] In the multi-AP cooperative transmission mechanism of this embodiment, there are two types of Trigger frames involved, one is sent by Sharing AP to indicate how TXOP is allocated; the other is sent by SharedAP that obtains the right to use TXOP to STA associated with itself, informing it that it can send low-latency services. It should be noted that the Trigger frame is only sent when the STA associated with Shared AP has low-latency services to be transmitted. If the Shared AP itself needs to transmit low-latency services, it is not necessary to send the Trigger frame. The design of the above two types of Trigger frames will be explained in this embodiment.

[0040] Regarding the first type of Trigger frame, the Trigger Frame is a new type of trigger frame, which is specially used in the multi-AP cooperation mechanism to be sent by the Sharing AP to one or more related Shared APs to indicate the allocation of TXOP. When acting as the holder of the transmission opportunity, after determining the allocation of the transmission opportunity, it generates configuration information for allocating the transmission opportunity, and sends a trigger frame carrying the configuration information to the transmission opportunity waiting party; for example: the configuration information can be a new value configured in the Trigger Type Subfield in the Common info field, which can be selected from the existing reserved bits, such as one of 8 to 15.

[0041] Among them, the configuration information includes: the user of the right to use the transmission opportunity, the validity period of the right to use the transmission opportunity; in other words, the Trigger frame should contain one or any combination of the following elements: a) The length of time that the TXOP can be used, so that the Shared AP knows the time window that can be used. The relevant device can only use the TXOP for its own data transmission within the TXOP usage time. After the time period is exceeded, the TXOP is automatically retracted. b) If the TXOP is allocated to multiple devices, the Trigger Frame should include the order in which the TXOP is used, as well as the TXOP usage time of each device, so that each device can use the TXOP in sequence. c) Information on available frequency bands. If conditions permit, resources on different frequency domains within the TXOP can also be allocated to the corresponding Shared AP for use. This makes the transmission between Shared APs in a frequency-divided state.

[0042] The information contained in the above Trigger frame can be configured in the Common info field or in the User info list. If a TXOP is to be allocated to multiple Shared APs, the Shared APs to which the TXOP is allocated should be included in the User info list.

[0043] Regarding the second type of Trigger frame, when acting as a transmission opportunity waiting party, after obtaining the right to use the transmission opportunity, a trigger frame carrying notification information is sent to each site device that has a low-latency service and is associated with itself; wherein the notification information is used to notify the site device that it can use the right to use the transmission opportunity to transmit the low-latency service. Specifically: After the Shared AP receives the Trigger frame indicating that the Sharing AP can use the TXOP, if the STA associated with itself has a low-latency service to be transmitted, it sends another Trigger frame to the low-latency service to notify it that it can use the TXOP to transmit the low-latency service. The Trigger frame can be the same as the Trigger frame format used between APs mentioned above, or it can be a trigger frame in an existing protocol or other forms of frames or a newly defined type of trigger frame. There is no special restriction, and it only requires the action of notifying the relevant STA to transmit the low-latency service.

[0044] In the multi-AP collaboration mechanism, when the low-latency service is transmitted, the TXOP needs to be returned to the Sharing AP. That is, when the low-latency service in the device itself or its associated site is completed, the transmission opportunity is returned to the transmission opportunity holder.

[0045] Among them, returning the transmission opportunity to the transmission opportunity holder can be: after waiting for the validity period of the right to use the transmission opportunity to expire, the transmission opportunity is automatically returned to the transmission opportunity holder; in other words, in the Trigger Frame of the Sharing AP allocating the TXOP, the usage duration of the TXOP has been indicated. After the corresponding duration ends, the TXOP is automatically returned to the Sharing AP. This method is simple and direct, and is suitable for transmission scenarios with a predetermined duration. Or it can be: sending a return frame carrying return information to the transmission opportunity holder to return the transmission opportunity to the transmission opportunity holder; after completing the use of the TXOP, the Shared AP feeds back a return frame to the Sharing AP to inform that the TXOP is finished. This method is applicable to the case where the TXOP usage duration is not configured, and can also be used to return the TXOP in advance. For example, if the transmission is completed before the duration specified by the Sharing AP, it can be returned in advance to save more resources.

[0046] Regarding the design of the return frame, there are several options:

[0047] 1. The return frame is a block acknowledgment frame (BA) frame that carries return information in a reserved bit. The TXOP return information is added to the BA frame. For example, an indication of returning the TXOP can be added to the reserved bit in the BA control field or the reserved bit in the BA type of the BA control field.

[0048] In the BA control field, there are some reserved bits, which are not currently used. One or more of these bits can be selected to indicate the return of the TXOP. When the Shared AP completes the low-latency service transmission, a specific value can be set in these reserved bits (for example, a bit position is set to 1) to indicate that the TXOP has been returned. Similarly, there are some reserved bits in the BA type field of the BA control field. A special type can be set for the BA that returns the TXOP, and one or more reserved bits can be selected for the BA frame dedicated to returning the TXOP. Optionally, the BA frame can carry two kinds of information at the same time. It can be used as a confirmation frame for feedback of received data, and it can also inform the Sharing AP to return the TXOP. As follows Figure 3As shown, the Sharing AP can send a multi-user request frame carrying an indication for inquiring low-latency service information to the relevant Shared AP. After a certain time interval, the transmission opportunity waiting party 1 and the transmission opportunity waiting party 2 simultaneously feedback the clear-to-send frame, in which the Shared AP with low-latency service can carry the low-latency service information to inform the Sharing AP. After receiving the CTS, the Sharing AP can preferentially allocate TXOP to the Shared AP2 with low-latency service to be processed according to the actual situation, and carry the relevant information through the Trigger frame. After receiving the Trigger frame for allocating TXOP to it, SharedAP2 can send a Trigger frame for low-latency service to the associated STA with low-latency service to be transmitted. After receiving the notification that the low-latency service can be sent, the STA sends a data packet of the low-latency service and completes the transmission after receiving the Block Acknowledgement (BA) frame fed back by Shared AP2. The BA can be sent to the STA and the Sharing AP at the same time to express two meanings. In this case, there can be wired communication between the Shared AP and the Sharing AP; or in the case of wireless communication, the information of returning the TXOP can be added to the PHY Preamble. This design enables the BA frame to not only complete the function of data reception confirmation, but also transmit the information of TXOP return without adding additional frames, thus improving communication efficiency.

[0049] 2. In some cases, the feedback block confirmation (Multi-STA BA) frame sent by the multi-connected site device can also be reused to carry the TXOP return (TXOP return) information. The BA information field (information field) can carry both the TXOP return information and the BA information to be replied. The BAinformation field of the Multi-STA BA frame contains several Per AID TID Information (Per AID TID Info) subfields, where the full name of AID is "Association Identifier", which indicates the user's association identifier; the full name of TID is "Traffic Identifier", which indicates the service identifier, and each AID TID Info subfield corresponds to a reply to a device. For the feedback content of low-latency services (such as LL Data), it can be generated according to the rules of the existing protocol. For the TXOP return information fed back to the Sharing AP, the following design can be used, where the AID TID Info subfield structure is as follows:

[0050]

[0051] Ack Type indicates the confirmation frame type.

[0052] Among them, in the AID TID Info subfield corresponding to the one sent to the Sharing AP, the AID11 subfield should be configured as 0, and the Ack type subfield and the TID subfield can use the reserved combination in the existing protocol to indicate TXOP return. For example, Ack type subfield = 0, TID subfiled = 14, or Ack type subfield = 0, TIDsubfiled = 15, or other reserved combinations. At the same time, the TXOP return option is added to several acknowledgmentcontext options of the Multi-STA BA frame. When the receiver of the Multi-STA BA frame is the AP, AID11subfield = 0, Ack type subfield = 0, TID subfiled = 14 (taking this combination as an example), it indicates TXOPreturn, and in this case, the AID TID info subfield does not include the Block Ack Starting SequenceControl subfield and the Block Ack Bitmap subfield. And the RA field of the Multi-STA BA frame should be a broadcast address.

[0053] In addition, in the above case, when the sender of the Multi-STA BA frame is the STA associated with the Shared AP, that is, the low-latency service is on the Shared AP side, and the STA is the receiver of the low-latency service. Figure 4 For example, the low latency service data (LL Data) frame sent by the transmission opportunity waiting party 2 (Shared AP2) should include an indication of its feedback TXOP return information. Optionally, in this case, other TXOP return methods can also be combined, and the station device (STA) sends a BA frame to Shared AP2, and Shared AP2 sends a feedback frame carrying TXOP return information to the transmission opportunity holder (Sharing AP) alone.

[0054] 3. The return frame is a contention-free period end (CF-End) frame that carries return information. The CF-End frame is used to indicate the return of the TXOP. In this case, a new meaning is given to CF-End. When the sender of CF-End is a Wifi8 AP or the AP supports multi-AP collaboration or the AP is a member of a multi-AP collaboration set, the CF-End frame can be sent as a signal to return the TXOP. The frame structure of the CF-End frame is the same as that of the traditional protocol, as shown below: Figure 5 As shown, Sharing AP can send a multi-user request frame carrying an indication for inquiring low-latency service information to the relevant Shared AP. After a certain time interval, transmission opportunity waiting party 1 and transmission opportunity waiting party 2 simultaneously feedback a clear-to-send frame, in which the Shared AP with low-latency service can carry low-latency service information to inform SharingAP. After receiving CTS, Sharing AP can preferentially allocate TXOP to Shared AP2 with low-latency service to be processed according to actual conditions, and carry relevant information through a trigger frame. After receiving the Trigger frame for allocating TXOP to it, Shared AP2 can send a Trigger frame for low-latency service to the associated STA with low-latency service to be transmitted. After receiving the notification that low-latency service can be sent, STA sends a data packet of low-latency service, and after receiving the block confirmation (BA) frame fed back by Shared AP2, Shared AP2 needs to send a CF-End frame to Sharing AP to notify Sharing AP that the low-latency service transmission is completed and the TXOP information can be returned.

[0055] 4. The return frame is an Acknowledgement Frame (ACK) frame that carries the return information.

[0056] The ACK frame can also be used to indicate the return of the TXOP. When the sender is a Wifi8 AP or the AP supports multi-AP collaboration or the AP is a member of a multi-AP collaboration set, an ACK frame can be sent as a signal to return the TXOP. The specific process is similar to the CF-end frame and will not be repeated here.

[0057] The following is an example of how to extend the frame exchange mechanism of the buffer status report polling / buffer status report (BSRP / BSR) to the mechanism of coordinated time division multiple access (C-TDMA) in multi-AP collaboration.

[0058] In one example, in the process of exchanging frames of buffer status report polling / buffer status report using time division multiple access technology, when acting as a transmission opportunity holder, a buffer status report polling frame for inquiring low-latency service information is sent to each transmission opportunity waiting party in a multi-AP collaboration set; when acting as a transmission opportunity waiting party, after receiving the buffer status report polling frame for inquiring low-latency service information, low-latency service information is generated according to the low-latency service existing in itself or its associated site equipment, and a buffer status report frame carrying the low-latency service information is sent to the transmission opportunity holder. For example:

[0059] like Figure 6 As shown, Sharing AP1 (BSS1) sends a buffer status report poll (BSRP) frame to Shared AP1 (BSS2) and Shared AP2 (BSS3) in the multi-AP collaboration set. This BSRP frame contains LL-Poll information, which is used to inquire whether Shared AP1 and Shared AP2 have low-latency services to be transmitted. After receiving the BSRP frame, Shared AP1 (BSS2) and Shared AP2 (BSS3) feedback a BSR frame (Buffer status report) to feedback the cache information of their own services to be transmitted. If there is a low-latency service to be transmitted, such as Shared AP2 (BSS3) in the figure, the BSR frame carries an indication of the low-latency service and reports the cache information of the low-latency service. After receiving the BSR frame fed back by the relevant AP, the Sharing AP decides on the use of the TXOP and notifies the relevant AP through the Trigger frame to allow it to use the TXOP. As shown Figure 6As shown in the example, Sharing AP sends a Triggerframe to Shared AP2 to notify it that it can use TXOP to transmit low-latency services. After receiving the Trigger frame that allocates TXOP to it, Shared AP2 can send a Trigger frame to the associated STA that has low-latency services to be transmitted (in this figure, the STA of BSS3 has a low-latency service to be transmitted as an example. If Shared AP2 itself has a low-latency service to be transmitted, it can directly transmit the low-latency service and this step can be omitted). After receiving the notification that the low-latency service can be sent, the STA sends a data packet for the low-latency service and completes the transmission after receiving the feedback confirmation frame BA from Shared AP2. After completing the transmission of the low-latency service, Shared AP2 sends a notification frame (TXOP Return frame) to Sharing AP to notify Sharing AP that the low-latency service transmission is complete and the TXOP information can be returned. The design of the TXOP return frame is the same as the description in the above embodiment and will not be repeated here. Among them, the information about LL-Poll can be defined as LL Poll subfield through B63 bit in the Common info field in the BSRP frame. When LL Poll = 1, it means that the BSRP also contains an indication to inquire whether there is a low-latency service to be transmitted. When LL Poll = 0, the function of inquiring about the low-latency service is not started. In some cases, the LL Poll subfield can also be included in the Trigger Dependent commoninfo subfield in the Common info field. In addition, in the above-mentioned BSRP / BSR frame exchange step, there can also be another form. For example, if the BSRP carries LL-poll information, the Shared AP with low-latency service will feedback BSR, which contains the cache information of the low-latency service. Shared APs without low-latency services do not feedback BSR. This method can reduce signaling transmission and save air interface resources.

[0060] The LL Notification indication in the BSR frame can be in the following forms:

[0061] 1. Use the AP PS Buffer State subfield (where PS stands for Power Save) to convey BSR information. For example, in the AP PS BufferState subfield in the Qos Control field (where Qos stands for Quality of Service) of the frame, add an LL Notification indication, and use the B0 reserved bit of the frame. LL Notification is used to indicate whether there is a cached low-latency service. When LLNotification is configured to 1, it indicates that the current BSR frame is used to indicate cache information related to the low-latency service. When LL Notification is configured to 0, it indicates that the current AP has no low-latency service to be sent. In addition, for the quality of service null data (Qos null) frame, the reserved bit (Bit 7) in the Qos Control field can also be used to indicate LLNotification.

[0062] 2. Use the BSR control subfield to convey BSR information. For example:

[0063] (1) The buffer status report control subfield (BSR control subfield) in the buffer status report frame may use the adjacent channel interference bitmap subfield and the incremental transmission identifier subfield to express the low-latency service information. Specifically:

[0064]

[0065] The format of the buffer status report control subfield is shown in Table 4: Among them, the access category index bitmap subfield (ACIBitmap, ACI: Access Category Index) is a bitmap used to indicate the commands that can be sent currently, and the incremental transmission identifier subfield (Delta TID) is a transaction identifier (TID) used to indicate the type of ACI command. The QueueSize High and Queue Size All fields are used to indicate the maximum or total size or the maximum or total remaining space of a specific queue, respectively. ACI High is generally used to indicate the maximum number of ACI commands that can be temporarily stored. Scaling Factor is a proportional factor or scaling factor. Here is the structure of the BSR control subfield, which can reuse the traditional structure, but the ACI Bitmap subfield and Delta TID subfield are both set to 0 to implicitly express LL notification. Of course, other specific values ​​can also be used to express the existence of low-latency services, such as ACI Bitmap = 0, DeltaTID subfield = 1 or 2; or ACI Bitmap = 1, Delta TID subfield = 2 or 3; or ACI Bitmap = 2, Delta TID subfield = 3. Accordingly, the cache information of the low-latency service should be included in the Queue Size All subfield.

[0066] (2) Design a new BSR control subfield to convey BSR information. Specifically: define a new low-latency service control ID (Control ID) in the A-Control subfield in the HT control field (HT Control field, where HT is the abbreviation of High Throughput, meaning high channel). One of the existing Reserved bits, such as 7 to 14, can be used. This new frame can be called a Low Latency Buffer Status Report (LL-BSR) frame, but this subfield only reports the cache information of the low-latency service. In other words, the reserved bit of the buffer status report frame carries the low-latency service control ID, and the frame carrying the low-latency service control ID is only used to report the low-latency service information;

[0067] (3) The BSR information is conveyed through a specific radio access control (AC) category, for example:

[0068] If low-latency services are uniformly classified into a specific AC category, there is no need to specifically add LLNotification indications, because the cache data information corresponding to different AC categories will be reported in the BSR report. In other words, when low-latency services are classified into a specified wireless access control category, the buffer status report frame sent to the transmission opportunity holder carries the cache data information corresponding to different wireless access control categories. The specific BSR frame type can be a Qos null frame, a Qos data frame, or a management frame (Management frame), but it needs to contain at least one of the fields 1 to 4 above containing BSR information. If it contains multiple fields, the information must be consistent. In addition, the BSR can also carry other low-latency service-related information indications, such as adding timing information (timing information) of low-latency services, such as the duration of the service, the maximum acceptable delay, urgency, priority and other related information, so as to better coordinate between APs.

[0069] The various technical features mentioned above can be applied not only to the Coordinated-FDMA strategy, but also to other multi-AP collaboration mechanisms, such as collaborative spatial reuse (C-SR, full name Coordinated Spatial reuse). In the collaborative spatial reuse strategy, the MU-RTS / CTS or BSRP / BSR frame exchange mechanism can also be used to obtain information about which APs have low-latency services to transmit. The design of MU-RTS / CTS and BSRP / BSR frames will not be repeated here. In an example, after receiving low-latency service information, when collaborative spatial reuse supports auxiliary processing of low-latency services, the relevant parameters of the device with low-latency services and the AP devices in the multi-AP collaboration set are adjusted according to the collaborative spatial reuse strategy; wherein the relevant parameters of the device with low-latency services include one of the following or any combination thereof: spatial reuse threshold, transmission power upper limit, working mode, interactive clustering information, working status information, and status information corresponding to the multi-AP collaboration group. Specifically:

[0070] After obtaining the information of the low-latency services to be transmitted by the relevant APs, in the OBSSPD-based spatial reuse (PD stands for Packet Detect) mode, the Sharing AP or Coordinator AP can send a Trigger frame to adjust the spatial reuse threshold (OBSS PD level), transmission power upper limit, working mode (such as capability mode or operating mode) and other information of the Shared AP or Coordinated AP. In the parameterized spatial reuse (PSR, full name Parameterized spatial reuse) mode, the Sharing AP or Coordinator AP can send the PSR Opportunity for low-latency services to the Shared AP or Coordinated AP with low-latency services to be processed.

[0071] In addition, the MU-RTS / CTS or BSRP / BSR frame exchange mechanism mentioned above can also be applied to the stage of multi-AP cooperation mechanism formation, for example:

[0072] 1) Through the MU-RTS / CTS or BSRP / BSR frame exchange mechanism, obtain whether the surrounding APs support multi-AP collaboration and which multi-AP collaboration modes they support, such as coordinated spatial reuse, coordinated FDMA, coordinated beamforming, coordinated r-TWT, and joint transmission (i.e., coordinated spatial reuse, coordinated-FDMA, coordinated beamforming, coordinated r-TWT, and joint transmission).

[0073] 2) Obtain whether the relevant AP agrees to join the multi-AP collaboration set through the MU-RTS / CTS or BSRP / BSR frame exchange mechanism.

[0074] 3) Obtain the current working status information of the relevant AP through the MU-RTS / CTS or BSRP / BSR frame exchange mechanism, including but not limited to the following information: Capability mode, working mode, number of working antennas (number of antennas for transmission and / or number of antennas for reception), channel bandwidth, NSS (Number of Spatial Streams, i.e. the number of supported receiving spatial streams and / or the number of supported transmitting spatial streams), modulation and coding scheme (MCS, full name Modulation and Coding Scheme), coding method, code rate, whether to support multi-RU scheduling, data rate, PPDU format (Physical Protocol Data Unit) and data packet size are all important factors affecting network performance. dRU (Dynamic Resource Unit) related parameters, seamless roaming, secondary channel access (or non-primary channel access).

[0075] After the multi-AP collaboration group is formed, if the working environment and other factors change, the MU-RTS / CTS or BSRP / BSR frame exchange mechanism can also be used to modify the state of the multi-AP collaboration set, for example, to ask if there is a related AP to exit the multi-AP collaboration set. The design of the MU-RTS / CTS and BSRP / BSR frames will not be repeated here.

[0076] In this embodiment, the access point device, which is also in the mechanism of multi-AP cooperative transmission, when acting as a transmission opportunity holder, sends a multi-user request to send frame for inquiring low-latency service information to each transmission opportunity waiting party in the multi-AP cooperative set, and determines the allocation of transmission opportunities through the clear to send frame carrying low-latency service information fed back by each transmission opportunity waiting party; when acting as a transmission opportunity waiting party, after receiving the multi-user request to send frame, it generates low-latency service information according to the low-latency service existing in itself or its associated site device, and sends a clear to send frame carrying low-latency service information to the transmission opportunity holder. The actual needs of current low-latency service processing are met by reasonably allocating transmission opportunities, fully integrating the characteristics of multi-AP collaboration and low-latency services, and realizing efficient and stable transmission of low-latency services in wireless networks.

[0077] The steps of the above method are divided only for clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this application.

[0078] All modules involved in this embodiment are logic modules. In practical applications, a logic unit may be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of the present invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by the present invention, but this does not mean that there are no other units in this embodiment.

[0079] Another embodiment of the present invention relates to an access point, such as Figure 7 As shown, it includes at least one processor 501; and a memory 502 that is communicatively connected to the at least one processor; wherein the memory 502 stores instructions that can be executed by at least one processor 501, and the instructions are executed by at least one processor 501 so that at least one processor 501 can execute the low-latency service transmission method as described above.

[0080] The memory 502 and the processor 501 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 501 and the memory 502 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor 501 is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor 501.

[0081] The processor 501 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 502 can be used to store data used by the processor 501 when performing operations.

[0082] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0083] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0084] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A low-latency service transmission method, characterized in that: Applicable to access point devices in a multi-AP cooperative transmission mechanism, including: When acting as a transmission opportunity holder, a multi-user request to send frame for inquiring low-latency service information is sent to each transmission opportunity waiting party in the multi-AP cooperation set, and a clear to send frame carrying the low-latency service information fed back by each transmission opportunity waiting party is used to determine the allocation of transmission opportunities; When acting as a transmission opportunity waiting party, after receiving the multi-user request to send frame, it generates the low-latency service information according to the low-latency service existing in itself or its associated site equipment, and sends the clear to send frame carrying the low-latency service information to the transmission opportunity holder.

2. The low-latency service transmission method according to claim 1, characterized in that: The indication for inquiring the low-latency service information in the multi-user request to send frame is carried by a reserved bit in the multi-user request to send frame; or, there is an indication field for inquiring the low-latency service information in the trigger type subfield in the common information field in the multi-user request to send frame.

3. The low-latency service transmission method according to claim 1, characterized in that: The low-latency service information in the clear-to-send frame is carried by a power management subfield in a frame control field; or, a control frame extension field for carrying the low-latency service information exists in the frame control field in the clear-to-send frame; or, the low-latency service information is carried by a physical layer preamble code.

4. The low-latency service transmission method according to claim 1, characterized in that: The method further comprises: When acting as a transmission opportunity waiting party, after receiving the multi-user request to send frame, if the low-latency service does not exist in itself or its associated site equipment, the clear to send frame will not be fed back.

5. The low-latency service transmission method according to claim 1, characterized in that: The method further comprises: When acting as a transmission opportunity holder, after determining the allocation of the transmission opportunity, generating configuration information for allocating the transmission opportunity, and sending a trigger frame carrying the configuration information to the transmission opportunity waiting party; The configuration information includes: the user of the right to use the transmission opportunity, the validity period of the right to use the transmission opportunity; When acting as a transmission opportunity waiting party, after obtaining the right to use the transmission opportunity, a trigger frame carrying notification information is sent to each site device that has the low-latency service and is associated with itself; The notification information is used to notify the site device that it can use the right to use the transmission opportunity to transmit the low-latency service.

6. The low-latency service transmission method according to claim 5, characterized in that: The method further comprises: When acting as a transmission opportunity waiting party, after the low-latency service existing in the site device of itself or itself associated with itself is completed, the transmission opportunity is returned to the transmission opportunity holder; The step of returning the transmission opportunity to the transmission opportunity holder includes: After the validity period of the right to use the transmission opportunity expires, the transmission opportunity is automatically returned to the transmission opportunity holder; or, Sending a return frame carrying return information to the transmission opportunity holder to return the transmission opportunity to the transmission opportunity holder; The return frame is a block confirmation frame carrying return information in a reserved bit, or the return frame is an ACK frame carrying return information, or the return frame is a CF-End frame carrying return information.

7. The low-latency service transmission method according to claim 1, characterized in that: The method further comprises: In the process of frame exchange of cache status report polling / buffer status report using time division multiple access technology, when acting as a transmission opportunity holder, a cache status report polling frame for inquiring low-latency service information is sent to each transmission opportunity waiting party in the multi-AP cooperation set; During the frame exchange process of cache status report polling / buffer status report using time division multiple access technology, when acting as a transmission opportunity waiting party, after receiving the cache status report polling frame for inquiring about low-latency service information, it generates the low-latency service information based on the low-latency service existing in itself or its associated site equipment, and sends a buffer status report frame carrying the low-latency service information to the transmission opportunity holder.

8. The low-latency service transmission method according to claim 7, characterized in that: The buffer status report control subfield in the buffer status report frame uses the access category index bitmap subfield and the incremental transmission identifier subfield to express the low-latency service information; or, The reserved bit of the buffer status report frame carries a low-latency service control ID, and the frame carrying the low-latency service control ID is only used to report the low-latency service information; The sending a buffer status report frame carrying the low-latency service information to the transmission opportunity holder includes: When the low-latency service is classified into a designated radio access control category, the buffer status report frame sent to the transmission opportunity holder carries buffer data information corresponding to different radio access control categories.

9. The low-latency service transmission method according to claim 1, characterized in that: The method further comprises: After receiving the low-latency service information, when the collaborative space reuse strategy supports auxiliary operation of the low-latency service information, adjusting the relevant parameters of the device with the low-latency service and the AP device in the multi-AP collaborative set according to the collaborative space reuse strategy; Among them, the relevant parameters of the device with the low-latency service include one of the following or any combination thereof: spatial multiplexing threshold, transmission power upper limit, working mode, interactive grouping information, working status information, and status information corresponding to the multi-AP collaboration group.

10. An access point, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the low-latency service transmission method as described in any one of claims 1 to 9.

11. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the low-latency service transmission method described in any one of claims 1 to 9 is implemented.

Images