This disclosure is directed generally to wireless communications, and particularly to a method, device, and system for data transmission and resource scheduling in a wireless network.
Flexible and efficient wireless transmission resource scheduling is critical in the wireless communication network. The ecosystem in a wireless communication network includes more and more applications that require low latency. These applications include Vehicle-to-Vehicle Communication, self-driving, mobile gaming, etc. Data transmission among various network elements in a wireless communication network need to be coordinated, to ensure smooth data transmission which meets a delay budget and requirement, and to improve overall network performance.
This disclosure is directed to a method, device, and system for data transmission and resource scheduling in a wireless network.
In some embodiments, a method performed by a first network element is disclosed. The method may include: determining, based on downlink (DL) resource availability, that a DL burst arrival time of a DL burst for a wireless device needs to be adjusted; and transmitting a first message to a core network in the wireless communication system, the first message comprising a DL burst arrival time adjustment indication for the wireless device indicating that a DL burst arrival time of a DL burst for the wireless device needs to be adjusted.
In some embodiments, a method performed by a core network node in a wireless communication system is disclosed. The method may include: receiving a first message from a base station in the wireless communication system, the first message comprising a DL burst arrival time adjustment indication for a wireless device indicating that a DL burst arrival time of a DL burst for the wireless device needs to be adjusted.
In some embodiments, a method performed by a first network element is disclosed. The method may include: determining, based on uplink (UL) resource availability, that a UL burst arrival time of a UL burst for a wireless device needs to be adjusted; and transmitting a first message to a core network in the wireless communication system, the first message comprising a UL burst arrival time adjustment indication for the wireless device.
In some embodiments, a method performed by a core network node in a wireless communication system is disclosed. The method may include: receiving a first message from a base station in the wireless communication system, the first message comprising a UL burst arrival time adjustment indication for a wireless device indicating that a UL burst arrival time of a UL burst for the wireless device needs to be adjusted.
In some embodiments, a method performed by a wireless device is disclosed. The method may include: transmitting a first message to a first network element in the wireless communication system, the first message comprising a UL burst arrival time adjustment indication for the wireless device; and receiving a second message as a response to the first message from the first network element, the second message comprising a confirmed UL burst arrival time information.
In some embodiments, there is a network element or a device comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement any methods recited in any of the embodiments.
In some embodiments, a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement any method recited in any of the embodiments.
The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.
adjustment.
The gNB 124 may include a central unit (CU) and at least one distributed unit (DU). The CU and the DU may be co-located in a same location, or they may be split in different locations. The CU and the DU may be connected via an F1 interface. Alternatively, for an eNB which is capable of connecting to the 5G network, it may also be similarly divided into a CU and at least one DU, referred to as ng-eNB-CU and ng-eNB-DU, respectively. The ng-eNB-CU and the ng-eNB-DU may be connected via a W1 interface.
The wireless communication network 100 may include one or more tracking areas. A tracking area may include a set of cells managed by at least one base station. For example, tracking area 1 labeled as 140 includes cell 1, cell 2, and cell 3, and may further include more cells that may be managed by other base stations and not shown in
The wireless communication network 100 may be implemented as, for example, a 2G, 3G, 4G/LTE, or 5G cellular communication network. Correspondingly, the base stations 122 and 124 may be implemented as a 2G base station, a 3G NodeB, an LTE eNB, or a 5G NR gNB. The UE 160 may be implemented as mobile or fixed communication devices which are capable of accessing the wireless communication network 100. The UE 160 may include but is not limited to mobile phones, laptop computers, tablets, personal digital assistants, wearable devices, Internet of Things (IoT) devices, MTC/eMTC devices, distributed remote sensor devices, roadside assistant equipment, XR devices, and desktop computers. The UE 160 may also be generally referred to as a wireless communication device, or a wireless terminal. The UE 160 may support sidelink communication to another UE via a PC5 interface.
While the description below focuses on cellular wireless communication systems as shown in
The electronic device 200 may also include system circuitry 204. System circuitry 204 may include processor(s) 221 and/or memory 222. Memory 222 may include an operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured for the one or more of the processors 221 to perform the functions of the network node. The parameters 228 may include parameters to support execution of the instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and/or other parameters.
Referring to
Referring to
In a wireless network, radio resource is shared by various devices, such as user equipments. The radio resource may include time resource and spectrum resource. The delivery or transmission of user data needs to go through various network elements. For example, for downlink traffic, the data may start from a Data Network or an Application, to a core network, to a radio access network (RAN), then it may be delivered by a base station to a UE via radio interface (e.g., Uu interface). For uplink traffic, the data may from a Data Network or an Application running on the UE, and delivered to a base station via air interface, the data will further be routed to the core network by the RAN. To ensure smooth data transmission and improve network performance, coordination effort is needed among these various network elements.
For example, the base station has resource constraint such that only certain resource may be used or allocated to the UE. For example, the data may only be transmitted to the UE at certain time. In this case, it is desirable for the core network to deliver the data to the RAN at a right time which meets the resource constrain on the base station. This means that the base station, once receives the data from the core network, may have radio resource readily available or with minimal delay (e.g., below a threshold), so the data may be transmitted to the UE to meet a delay requirement. Otherwise, the base station may have to buffer the data till the moment when the resource is available, and this will lead to excessive transmission delay and will also increase buffering cost.
To achieve this goal, a base station may communicate with the core network, to coordinate data burst arrival time, so the data burst arrival time match with the resource condition on the base station side. The burst arrival time may be adjusted to be aligned with the radio resource pattern. In this disclosure, various embodiments are described for coordinating the burst arrival time information among various network element in the wireless network. Details on these embodiments are described below.
In this embodiment, a base station initiates a request to the core network for adjusting downlink burst arrival time.
step 1: This step is optional. The core network, or a core network node such as an Access and Mobility Management Function (AMF), may send downlink (DL) burst scheduling arrangement for DL data burst of the UE to the base station. The DL burst scheduling arrangement may include a DL burst arrival time and may further include a periodicity for the DL burst.
step 2: The base station may determine whether the DL burst scheduling arrangement is aligned with its own DL resource availability, or DL resource which can be allocated to the UE. The base station may decide to adjust the DL burst arrival time so it may better align with the DL resource availability. The base station may send a DL burst arrival time adjustment indication to the core network (e.g., AMF) via UE associated signaling. The DL Burst arrival time adjustment indication may include as least one of following:
The DL burst arrival time pattern may be represented as a sequence of {DL burst arrival time, time duration, periodicity}, for example, a sequence of {StartTime1, TimeDuration1, Periodicity1}, {StartTime2, TimeDuration2, Periodicity2}.
The DL burst arrival time related configuration may include at least one of: DL burst arrival starting time, periodicity of DL burst.
The DL burst arrival starting time and DL burst duration may be represented as a sequence of {StartTime, TimeDuration}.
The cell specific TDD downlink time domain pattern or cell specific Uplink/Downlink TDD configuration is used to indicate the quasi-periodic DL available time.
In one implementation, the DL burst arrival time related configuration may include the DL arrival time, and a periodicity for the DL burst.
step 3: Upon receiving the DL burst arrival time adjustment indication, if the core network agrees with the recommended DL burst arrival time, it may send a DL burst arrival time adjustment confirmation to the base station via UE associated signaling, to confirm the DL burst arrival time adjustment recommended by the base station. The DL burst arrival time adjustment confirmation may include as least one of following:
As an example, the DL burst arrival time pattern may be represented as a sequence of {DL burst arrival time, periodicity}.
In one implementation, the DL burst arrival time related configuration may include the DL arrival time, and a periodicity for the DL burst.
step 4: For DL burst, the data network (DN) or the application (APP) running at application layer is driving the data transmission. The core network may also send the DL burst arrival time adjustment indication to the DN or the APP, to trigger the data transmission time adjustment on DN/APP side, so the DL burst arrival time may match the recommended value.
step 5: The core network may also send the DL burst arrival time adjustment indication to UE via Non-Access Stratum (NAS) message. The UE may determine the 5G system (5GS) egress time for DL data based on the DL burst arrival time adjustment indication.
In this embodiment, the core network may indicate to the base station whether DL burst arrival time adjustment is supported, or the base station may obtain whether DL burst arrival time adjustment is supported in the core network by OAM. Then based on this indication, the base station may initiate a request to the core network for adjusting downlink burst arrival time.
step 1: The core network, or a core network node such as an AMF, may send downlink (DL) burst scheduling arrangement for DL data burst of the UE to the base station. The DL burst scheduling arrangement may include a DL burst arrival time and may further include a periodicity for the DL burst. The core network may also send an indication to the base station indicating whether DL burst arrival time adjustment is supported. The granularity of the indication may include a UE level, a base station level, or a core network level.
step 2: The base station may determine whether the DL burst scheduling arrangement is aligned with its own DL resource availability, or DL resource which can be allocated to the UE. The base station may decide to adjust the DL burst arrival time so it may better align with the DL resource availability. The base station may send a DL burst arrival time adjustment indication to the core network (e.g., AMF) via UE associated signaling. The DL Burst arrival time adjustment indication may include as least one of following:
step 3: Different from embodiment 1, when receiving the DL Burst arrival time adjustment indication, the core network does not need to send back a response or confirmation to the base station, as the core network already indicates to the base station that such adjustment is supported.
For DL burst, the data network (DN) or the application (APP) running at application layer is driving the data transmission. The core network may send the DL burst arrival time adjustment indication to the DN or the APP, to trigger the data transmission time adjustment on DN/APP side, so the DL burst arrival time may match the recommended value.
step 4: The core network may further send the DL burst arrival time adjustment indication to UE via NAS message. The UE may determine the 5GS egress time for DL data based on the DL burst arrival time adjustment indication.
In this embodiment, a base station initiates a request to the core network for adjusting uplink burst arrival time. The base station may not know whether the core network supports such adjustment before sending this request. Therefore, the base station expects a confirmation from the core network in order to activate the adjustment.
step 1: This step is optional. The core network, or a core network node such as an AMF, may send downlink (UL) burst scheduling arrangement for UL data burst of the UE to the base station. The UL burst scheduling arrangement may include a UL burst arrival time and may further include a periodicity for the UL burst.
step 2: The base station may determine whether the UL burst scheduling arrangement is aligned with its own UL resource availability, or UL resource which can be allocated to the UE. The base station may decide to adjust the UL burst arrival time so it may better align with the UL resource availability. The base station may send a UL burst arrival time adjustment indication to the core network (e.g., AMF) via UE associated signaling. The UL Burst arrival time adjustment indication may include as least one of following:
The UL burst arrival time pattern may be represented as a sequence of {UL burst arrival time, time duration, periodicity}, for example, a sequence of {StartTime1, TimeDuration1, Periodicity1}, {StartTime2, TimeDuration2, Periodicity2}.
The UL burst arrival starting time and UL burst duration may be represented as a sequence of {StartTime, TimeDuration}.
In one implementation, the UL burst arrival time related configuration may include the UL arrival time, and a periodicity for the UL burst.
step 3: Upon receiving the UL burst arrival time adjustment indication from the base station, if the core network agrees with the recommended UL burst arrival time, it may send a UL burst arrival time adjustment confirmation to the base station via UE associated signaling, to confirm the UL burst arrival time adjustment recommended by the base station. The UL burst arrival time adjustment confirmation may include as least one of following:
In one implementation, the UL burst arrival time related configuration may include the UL arrival time, and a periodicity for the UL burst.
step 4: The core network may further send the UL burst arrival time adjustment indication to the UE via, for example, a NAS message.
step 5: For UL burst, the data network (DN) or the application (APP) running at application layer is driving the data transmission. The APP may include applications running on the UE, such as an online meeting APP, video streaming APP, etc. The UE may send the UL burst transmission time adjustment indication to the DN or the APP, to trigger the data transmission time adjustment on DN/APP side, so the UL burst arrival time may match the recommended value.
In this embodiment, the core network may indicate to the base station whether UL burst arrival time adjustment is supported. Then based on this indication, the base station may initiate a request to the core network for adjusting uplink burst arrival time.
step 1: UE may send at least one of: a UL burst arrival time, periodicity for the UL burst, and UL burst arrival time adjustment support indication to the core network, via, for example, a NAS message. In one implementation, UL burst arrival time adjustment Support indication may be indicated implicitly with a range of UL burst arrival time, i.e., UE supports UL burst arriving within this specified range.
step 2: The core network, or a core network node such as an AMF, may send UL burst scheduling arrangement for UL data burst of the UE to the base station. The UL burst scheduling arrangement may include a UL burst arrival time and may further include a periodicity for the UL burst. The core network may also send an indication to the base station indicating whether UL burst arrival time adjustment is supported. The granularity of the indication may include a UE level, a base station level, or a core network level.
step 3: The base station may determine whether the UL burst scheduling arrangement is aligned with its own UL resource availability, or UL resource which can be allocated to the UE. The base station may decide to adjust the UL burst arrival time so it may better align with the UL resource availability. The base station may send a UL burst arrival time adjustment indication to the core network (e.g., AMF) via UE associated signaling. The UL Burst arrival time adjustment indication may include as least one of following:
The UL burst arrival time pattern may be represented as a sequence of {UL burst arrival time, time duration, periodicity}, for example, a sequence of {StartTime1, TimeDuration1, Periodicity1}, {StartTime2, TimeDuration2, Periodicity2}.
The UL burst arrival time related configuration may include the UL arrival time, and a periodicity for the UL burst.
The UL burst arrival starting time and UL burst duration may be represented as a sequence of {StartTime, TimeDuration}.
step 4: Different from embodiment 1, when receiving the UL Burst arrival time adjustment indication, the core network does not need to send back a response or confirmation to the base station, as the core network already indicates to the base station that such adjustment is supported.
The core network may send the UL burst arrival time adjustment indication to UE via a NAS message.
step 5: For UL burst, the data network (DN) or the application (APP) running at application layer is driving the data transmission. The APP may include applications running on the UE, such as an online meeting APP, video streaming APP, etc. The UE may send the UL burst transmission time adjustment indication to the DN or the APP, to trigger the data transmission time adjustment on DN/APP side, so the UL burst arrival time may match the recommended value.
In this embodiment, a UE may initiate a request to the core network for adjusting uplink burst arrival time.
step 1: The UE may have a recommended UL burst transmission configuration, or the UE may already have a UL burst transmission configuration. The UE may inform the core network its current configuration or its preferred UL burst transmission configuration via, for example, a NAS message. UE may include in the message at least one of: a UL burst arrival time, or a periodicity for the UL burst.
Alternatively or additionally, the UE may send a UL burst arrival time adjustment indication to the core network (e.g., AMF) via a NAS message. The UL burst arrival time adjustment indication may include as least one of following:
The UL burst arrival time related configuration may include the UL arrival time, and a periodicity for the UL burst.
step 2: Upon receiving the UL burst arrival time adjustment indication from the UE, if the core network agrees with the recommended UL burst arrival time, it may send a UL burst arrival time adjustment confirmation to the UE via a NAS message, to confirm the UL burst arrival time adjustment recommended by the UE. The UL burst arrival time adjustment confirmation may include as least one of following:
step 3: The core network may send the UL burst arrival time adjustment indication to the base station, so the base station may configure/re-configure its UL resource for the UE accordingly.
step 4: For UL burst, the data network (DN) or the application (APP) running at application layer is driving the data transmission. The APP may include applications running on the UE, such as an online meeting APP, video streaming APP, etc. The UE may send the UL burst transmission time adjustment indication to the DN or the APP, to trigger the data transmission time adjustment on DN/APP side, so the UL burst arrival time may match the recommended value.
In option 1, the UE sends the UL burst arrival time adjustment indication to the core network directly using a NAS message. Alternatively, in another option, the UE may use the base station as a relay for sending the UL burst arrival time adjustment indication to the core network. More details are described in option 2.
step 1: The UE may have a recommended UL burst transmission configuration, or the UE may already have a UL burst transmission configuration. The UE may inform the base station its current configuration or its preferred UL burst transmission configuration via, for example, an AS message, such as a Medium Access Control-Control Element (MAC CE) message, a UE dedicated Radio Resource Control (RRC) message, etc. UE may include in the message at least one of: a UL burst arrival time, or a periodicity for the UL burst.
Alternatively or additionally, the UE may send a UL burst arrival time adjustment indication to the base station. The UL burst arrival time adjustment indication is similar as in option 1 of this embodiment.
step 2: The base station may forward the message from UE in step 1 to the core network via a UE associated signaling.
step 3: The core network, if agrees with the recommended UL burst arrival time, may send a UL burst arrival time adjustment confirmation to the base station via a UE associated signaling. Details on the confirmation may be found in option 1 of this embodiment.
step 4: The base station forward the UL burst arrival time adjustment confirmation to the UE via, for example, an AS message, such as a MAC CE message, a UE dedicated RRC message, etc
step 5: For UL burst, the data network (DN) or the application (APP) running at application layer is driving the data transmission. The APP may include applications running on the UE, such as an online meeting APP, video streaming APP, etc. The UE may send the UL burst transmission time adjustment indication to the DN or the APP, to trigger the data transmission time adjustment on DN/APP side, so the UL burst arrival time may match the recommended value.
Exemplarily, the UL burst arrival time may include at least one of following:
In a current wireless network, in order to reduce UE power consumption, a Connected mode Discontinuous Reception (CDRX) may be configured which applies to both periodic or non-periodic traffic. In CDRX mode, the on-duration start occasion is calculated as follows:
or
In the formulas (1) and (2) above, the periodicity for periodic traffic is not considered.
If CDRX is used to align with periodicity of periodic traffic, and the formulas above are used, and if the DRX Cycle in the formulas (i.e., drx-LongCycle or drx-ShortCycle) is not an integer factor of 10240 ms (millisecond), then there be a mismatch between the periodicity of periodic traffic and the DRX ON duration cycle, because of the System Frame Number (SFN) wrap around. This issue may cause the DRX cycle being out of sync with the arrival time of data traffic, for example, eXtended Reality (XR) traffic, as a result of the SFN wrap around. This issue is further illustrated in
In this embodiment, to solve the SFN wrap around issue, the start occasion of CDRX on-duration time can be indicated by network (e.g., Radio Access Network, or core network), and the start of subsequent CDRX on-duration time may be determined based on a periodicity shift relative to the start of the previous adjacent (neighbor) CDRX on-duration time.
In one implementation, after a CDRX is configured, the Medium Access Control (MAC) entity may consider that the Nth CDRX on-duration start at one of:
Where SFNstart time and subframe start time are represented in SFN number and subframe number, respectively, of the first on-duration start occasion when the CDRX was (re-)configured.
or
Where SFNstart time and slotstart time are SFN and slot number, respectively, of the first on-duration start occasion when the CDRX was (re-)configured.
or
Where SFNstart time, slotstart time, and symbolstart time are the start time of the SFN, the slot and the symbol, respectively, of the first on-duration start occasion when the CDRX was (re-)configured.
Where the ceil(X) is the ceiling operation to get a minimal integer value that is larger than or equal to X. In one implementation, the ceil( ) operation may be removed from the formula if non-integer CDRX periodicity value is not configured.
In one implementation, the ceil( ) operation may be replaced by FLOOR( ), wherein the FLOOR(X) is the floor operation to get a maximal integer value that is smaller than or equal to X.
XR service may be a video streaming service with fixed picture frames (e.g., H.264 frame) which may include I-frame, P-frame, B-frame.
Since different picture frames are coded/decode using different coding/decoding schemes, the Quality of Service (QoS) priority or importance of different frames are also different. For example, the Decoding Time Sequence and Presentation Time Sequence for the ADU as shown in in
Considering that different application frames have different QoS priority or importance level during ADU decoding, and there are dependencies among different frames, it is beneficial to differentiate these frames in the RAN and weight/consider the difference for radio resource scheduling.
In one implementation, one XR service (e.g. one video streaming) is mapped to one QoS flow, which can indicate the video frame sequence (e.g. PDU set sequence based on PDU set sequence number, if one video frame is map to one PDU set). To differentiate the QoS priority or importance level of PDU sets in one QoS flow, there are two options:
QoS subflows may also be named as “sub QoS flow”, which is used to differentiate the different QoS attributes (e.g. priority levels) within a same QoS flow.
When QoS subflows are introduced, a gNB may map one QoS flow to one Data Radio Bearer (DRB), and then map different QoS subflows of the same DRB to different Logical Channels (LCs) as show in
In one implementation, the user plain data PDU is routed from General Packet Radio System (GPRS) Tunneling Protocol User Plane (GTP-U) to Service Data Adaption Protocol (SDAP) entity, then from SDAP entity to Packet Data Convergence Protocol (PDCP) entity, then from PDCP entity to Radio Link Control (RLC) entity, and then from RLC entity to Medium Access Control (MAC) entity. Radio resource scheduling may be performed in MAC entity.
Considering that one PDCP entity is associated with a DRB, if different QoS subflows of same DRB are mapped to different logical channels, the PDCP entity should be aware of the QoS subflow information, so that it can properly route PDCP PDUs with different QoS subflows to different logical channels.
In order for the PDCP entity to be aware of the QoS subflow information, QoS sub-flow ID or QoS sub-flow priority should be included in a SDAP PDU (e.g., by adding a SDPA header which includes a QoS sub-flow ID and/or a QoS sub-flow priority field).
In one implementation, the user plain data PDU is routed from GTP-U (e.g., in DL PDU SESSION INFORMATION (PDU Type 0) format) to SDAP entity, then from SDAP entity to PDCP entity, then from PDCP entity to RLC entity, and then from RLC entity to MAC entity. Radio resource scheduling are performed in MAC entity.
Considering that one PDCP entity is associated with a DRB, if QoS sub-flow is not introduced, one DRB usually is mapped to one logical channel.
If priority level or importance indication is introduced in GTP-U header, so that MAC entity can be aware of the priority level or importance indication information for radio resource scheduling, the priority level or importance indication should be available in the MAC entity. This can be implemented using one of the following solutions:
Solution 1: Priority level or importance indication are included in XnAP and/or F1AP user plane packet header (e.g., GTP-U header) to deliver the priority level or importance indication information between different RAN network elements (e.g. between gNBs and/or between gNB-CU and gNB-DU). In a RAN network element, the priority level or importance indication delivery can be based on gNB implementation and/or UE implementation.
Solution 2: priority level or importance indication is included in SDAP data PDU (e.g., by adding a SDPA header which includes QoS sub-flow ID or QoS sub-flow priority field), and then included in PDCP data PDU (e.g., priority level or importance indication is included in the header of PDCP data PDU), and further included in RLC data PDU (e.g. priority level or importance indication is included in the header of RLC PDU).
The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.
Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.
In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and”, “or”, or “and/or,” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on context.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.
The present application is a continuation of International Patent Application No. PCT/CN2022/122252, filed Sep. 28, 2022. The contents of International Patent Application No. PCT/CN2022/122252 are herein incorporated by reference in their entirety.
Number | Date | Country | |
---|---|---|---|
Parent | PCT/CN2022/122252 | Sep 2022 | WO |
Child | 18981037 | US |