TW202247682A - Systems and methods of configuring traffic specification for wireless communication - Google Patents

Abstract

Disclosed herein are systems and methods directed to configuring traffic specification for wireless communication. In one aspect, a first wireless communication device may configure a bitmap indicating a plurality of traffic identifiers (TIDs) sharing a traffic specification (TSPEC) element. The first wireless communication device may send a message including the bitmap to a second wireless communication device.

Description

System and method for configuring traffic specifications for wireless communication

The present disclosure generally relates to communications with certain latency requirements, including but not limited to reducing latency in communications for artificial reality and other applications. Cross-reference to related applications

This application asserts U.S. Provisional Application No. 63/172,331, filed April 8, 2021, entitled "SYSTEMS AND METHODS OF CONFIGURING TRAFFIC SPECIFICATION FOR WIRELESS COMMUNICATION," and U.S. Provisional Application No. 17, filed March 8, 2022. Priority and Benefit of U.S. Nonprovisional Application No. 689,612, which is hereby incorporated by reference in its entirety.

Artificial reality such as virtual reality (VR), augmented reality (AR) or mixed reality (MR) provides immersive experience to users. In one example, a user wearing a head wearable display (HWD) can turn the user's head, and a virtual object's position corresponding to the HWD and the user's gaze direction An image of the HWD may be displayed on the HWD to allow the user to feel as if the user is moving within an artificial reality space (eg, VR space, AR space, or MR space). An image of a virtual object may be generated by a computing device communicatively coupled to the HWD. In some embodiments, the computing device may have access to a network.

In one embodiment, an image of a virtual object is generated by a console communicatively coupled to the HWD. In one example, the HWD includes various sensors that detect the position and/or orientation of the HWD, and transmit the detected information of the HWD through a wired connection or a wireless connection. position and/or bearing to the console. The console may determine the user's field of view of the artificial reality space according to the detected position and/or orientation of the HWD, and generate an artificial reality view corresponding to the user's field of view. Image data of images of space. The console may send the image data to the HWD, whereby an image of a space corresponding to the user's field of view of artificial reality may be presented to the user. In one aspect, the process of detecting the position of the HWD and the gaze direction of the user wearing the HWD and imaging the image to the user should be completed within one frame time (eg, less than 11 ms). implement. Any delay between the movement of the user wearing the HWD and the display of images corresponding to the user's movement may cause judder, which may cause motion sickness and may degrade the user experience.

Disclosed herein are systems and methods related to packetizing/bundling Traffic Identifiers (TIDs) with similar characteristics (eg, Quality of Service (QoS)) in a Single Traffic Specification (TSPEC) element. Certain embodiments relate to a method of configuring, by a first wireless communication device, a bitmap indicating traffic identifiers (TIDs) sharing a traffic specification (TSPEC) element. The method may include sending, by the first wireless communication device, a message including the bitmap to the second wireless communication device.

The message may include a field that is set to a predefined value to indicate that the bitmap contains valid information. The field set to the predefined field may cause the second wireless communications device to ignore a traffic flow identifier associated with the TSPEC element. The message may include a direction subfield, which may indicate a direction for the plurality of TIDs. The direction subfield may indicate one of the following: transmit traffic in an uplink direction, transmit traffic in a downlink direction, bidirectional transmit traffic, or direct transmit link traffic. When the direction subfield indicates direct link traffic, and the direct link traffic is to be transmitted during a service period with a restricted target wake-up time, the direction subfield may be such that The second wireless communications device ignores the plurality of TIDs. The second wireless communication device may comprise an access point or station device. The TSPEC element may include features, which may be common to the plurality of TIDs.

Other embodiments relate to a wireless communication device including at least one processor configured to configure a bitmap indicating traffic identifiers (TIDs) sharing a traffic specification (TSPEC) element. The wireless communication device may include a transmitter configured to transmit a message including the bitmap to a second wireless communication device.

The message may include a field that is set to a predefined value to indicate that the bitmap contains valid information. The field set to the predefined field may cause the second wireless communications device to ignore a traffic flow identifier associated with the TSPEC element. The message may include a direction subfield, which may indicate a direction for the plurality of TIDs. The direction subfield may indicate one of the following: transmit traffic in an uplink direction, transmit traffic in a downlink direction, bidirectional transmit traffic, or direct transmit link traffic. When the direction subfield indicates direct link traffic, and the direct link traffic is to be transmitted during a service period with a restricted target wake-up time, the direction subfield may be such that The second wireless communications device ignores the plurality of TIDs.

Other embodiments relate to a method of receiving a message including a bitmap from a first wireless communication device by a second wireless communication device. The bitmap may indicate a plurality of traffic identifiers (TIDs) that share a traffic specification (TSPEC) element.

The message may include a field that is set to a predefined value to indicate that the bitmap contains valid information. The field set to the predefined field may cause the second wireless communications device to ignore a traffic flow identifier associated with the TSPEC element. The message may include a direction subfield, which may indicate a direction for the plurality of TIDs. The direction subfield may indicate one of the following: transmit traffic in an uplink direction, transmit traffic in a downlink direction, bidirectional transmit traffic, or direct transmit link traffic. When the direction subfield indicates direct link traffic, and the direct link traffic is to be transmitted during a service period with a restricted target wake-up time, the direction subfield may be such that The second wireless communications device ignores the plurality of TIDs. The second wireless communication device may include a receiver and at least one processor configured to implement the method.

Before turning to the drawings, which depict certain embodiments in detail, it should be understood that the present disclosure is not limited to the details or methodology set forth in the description or depicted in the drawings. It is also to be understood that the terminology used herein is for the purpose of description only and should not be regarded as limiting.

Traffic flow across a network can be characterized by different types of traffic. For example, an application may be characterized as delay-sensitive traffic (e.g., video/voice (VI/VO), instant interactive applications, and the like) or regular traffic (e.g., best-effort/background applications (BE/BK) ). Delay-sensitive traffic may be identifiable by the periodic bursting characteristics of its traffic. For example, video display traffic may be driven by refresh rates such as 60 Hz, 72 Hz, 90 Hz and/or 120 Hz. An application and/or device may have a combination of traffic types (eg, delay-sensitive traffic and non-delay-sensitive traffic).

In some embodiments, if the communication between devices includes multiple TIDs, the sending device may transmit as many TSPEC elements as there are TIDs. In other words, a TSPEC element may correspond to a single TID. In one example, given three downlink (DL) TIDs and three uplink (UL) TIDs, then up to six TSPEC elements may be passed indicating characteristics of the DL TIDs and UL TIDs (e.g. , three TSPEC elements correspond to the three DL TIDs, and three TSPEC elements correspond to the three UL TIDs).

However, some traffic streams may share similar/common characteristics. In particular, streams of traffic originating from (or directed to) a single application may share features. For example, an application in the AR/VR context may send three TIDs (e.g., a TID identifying audio traffic, a TID identifying video traffic, and a TID identifying traffic related to captured sensor data TID). However, the three TIDs may share features because they serve the same application (eg, the TIDs are identifying delay-sensitive traffic). In such a case, it may not be advantageous/efficient to deliver the three TSPEC elements corresponding to the three TIDs generated from the application (e.g., with respect to the bandwidth consumed or utilized in delivering the TSPEC elements and/or power).

Disclosed herein are systems and methods for remotely imaging an artificial reality space (eg, AR space, VR space, or MR space) by delivering multiple TIDs in a single TSPEC element. This is illustrative and by no means intended to limit the application of solutions for describing/managing traffic streams to artificial realities.

FIG. 1 is a block diagram of an example augmented reality system environment 100 . In some embodiments, the augmented reality environment 100 includes an access point (AP) 105, one or more HWDs 150 (e.g., HWDs 150A, 150B), and one or more computing devices 110 (computing devices 110A, 110B) that provide data for artificial reality to the one or more HWDs 150 . The access point 105 may be a router or any networking device that allows one or more computing devices 110 and/or one or more HWDs 150 to access a network (eg, the Internet). The access point 105 can be replaced by any communication device (mobile communication base station). A computing device 110 may be a computing device or a mobile device capable of retrieving content from the access point 105 and providing artificial reality image data to a corresponding HWD 150 . Each HWD 150 can present the artificial reality image to the user according to the image data. In some embodiments, the augmented reality system environment 100 includes more, fewer, or different components than those shown in FIG. 1 . In some embodiments, the computing devices 110A, 110B communicate with the access point 105 via wireless links 102A, 102B (eg, interconnect links), respectively. In some embodiments, the computing device 110A communicates with the HWD 150A via a wireless link 125A (eg, an internal link), and the computing device 110B communicates with the HWD 150A via a wireless link 125B (eg, an internal link). internal link) to communicate with the HWD 150B. In some embodiments, the functionality of one or more components of the metaverse environment 100 may be distributed among the components in ways other than those described herein. For example, certain functions of the computing device 110 may be performed by the HWD 150 . Additionally or alternatively, certain functions of the HWD 150 may be performed by the computing device 110 .

In some embodiments, the HWD 150 is an electronic component that is wearable by a user and that can present or provide an artificial reality experience to the user. The HWD 150 may be referred to as, including a head mounted display (HMD), a head mounted device (HMD), a head wearable device (HWD), a head worn display (HWD), or a head mounted display (HMD). A wearable device (HWD), or a part thereof. The HWD 150 can generate one or more images, videos, audios, or some combination thereof to provide artificial reality experience to the user. In some embodiments, audio is presented via external devices (e.g., speakers and/or headphones) that receive audio information from the HWD 150, the computing device 110, or both , and render audio based on the audio information. In some embodiments, the HWD 150 includes sensors 155 , a wireless interface 165 , a processor 170 , and a display 175 . These components can work together to detect the position of the HWD 150 and the gaze direction of a user wearing the HWD 150, and image the detected position of the HWD 150 within the artificial reality and/or an image of a field of view of orientation. In other embodiments, the HWD 150 includes more, fewer, or different components than shown in FIG. 1 .

In some embodiments, the sensor 155 includes electronic components, or a combination of electronic and software components, that detect the position and orientation of the HWD 150 . Examples of the sensors 155 may include: one or more imaging sensors, one or more accelerometers, one or more gyroscopes, one or more magnetometers, or another suitable type of motion detection and/or position sensors. For example, one or more accelerometers may measure translational movement (e.g., forward/backward, up/down, left/right), and one or more gyroscopes may measure rotational movement (e.g., pitch, yaw ,roll). In some embodiments, the sensor 155 detects the translational movement and the rotational movement, and determines the orientation and position of the HWD 150 . In one aspect, the sensor 155 can detect translational and rotational movements relative to a previous orientation and position of the HWD 150, and by accumulating or integrating the detected translational movements and/or rotational movement to determine a new orientation and/or position of the HWD 150 . For example, assuming that the HWD 150 is oriented 25 degrees away from a reference direction, in response to detecting that the HWD 150 has rotated 20 degrees, the sensor 155 may determine that the HWD 150 is now facing Or oriented in a direction 45 degrees away from said reference direction. As another example, assuming the HWD 150 was previously positioned two feet from a reference point in a first direction, in response to detecting that the HWD 150 has moved three feet in a second direction, the sensing The controller 155 may determine that the HWD 150 is now at the vector product of two feet in the first direction and three feet in the second direction.

In some embodiments, the wireless interface 165 includes an electronic component or a combination of an electronic component and a software component that communicates with the computing device 110 . In some embodiments, the wireless interface 165 includes or embodies a transceiver for sending and receiving data over a wireless medium. The wireless interface 165 can communicate with a corresponding wireless interface 115 of the computing device 110 via a wireless link 125 (eg, internal link). The wireless interface 165 can also communicate with the access point 105 through a wireless link (eg, an interconnection link). Examples of the wireless link 125 include a near field communication link, Wi-Fi Direct, Bluetooth, or any wireless communication link. Through the wireless link 125, the wireless interface 165 may send data indicating the determined position and/or orientation of the HWD 150, the user's determined gaze direction, and/or measurements of tracking hands to the computing device 110 . Furthermore, via the wireless link 125, the wireless interface 165 may receive image data from the computing device 110 indicating or corresponding to an image to be imaged.

In some embodiments, the processor 170 includes an electronic component or a combination of an electronic component and a software component, which, for example, generates one or more parameters for displaying according to the spatial changes taking into account the artificial reality. of the image. In some embodiments, the processor 170 is implemented as one or more graphics processing units (GPUs), one or more central processing units (CPUs), or a combination thereof, which can execute instructions to perform various functions described here. The processor 170 may receive image data describing an image of an artificial reality to be imaged via the wireless interface 165 and image the image via the display 175 . In some embodiments, image data from the computing device 110 may be encoded, and the processor 170 may decode the image data to image the image. In some embodiments, the processor 170 receives object information from the computing device 110 through the wireless interface 165 indicating a virtual object in an artificial reality space, and indicates the depth (or depth) of the virtual object. distance from the HWD 150). In one aspect, the processor 170 is based on artificial reality images from the computing device 110 , object information, depth information, and/or updated sensor measurements from the sensors 155 . Shading, reprojection, and/or blending may be performed to update the artificial reality imagery to correspond to the updated position and/or orientation of the HWD 150 .

In some embodiments, the display 175 is an electronic component for displaying images. The display 175 can be, for example, a liquid crystal display or an organic light emitting diode display. The display 175 may be a transparent display that allows the user to see through. In some embodiments, the display 175 is located close (eg, less than 3 inches) to the user's eyes when the HWD 150 is worn by the user. In one aspect, the display 175 emits or projects light toward the user's eyes based on the image generated by the processor 170 . The HWD 150 may include a lens that allows the user to see the display 175 in close proximity.

In some embodiments, the processor 170 performs compensation to compensate for any distortion or aberration. In an aspect, the lens introduces optical aberrations such as chromatic aberration, pin cushion distortion, barrel distortion, and the like. The processor 170 may determine a compensation (eg, predistortion) to apply to the image to be imaged to compensate for the distortion caused by the lens, and apply the determined compensation to the image from the processor 170 . The processor 170 can provide the pre-distorted image to the display 175 .

In some embodiments, the computing device 110 is an electronic component or a combination of an electronic component and a software component that provides content to be imaged to the HWD 150 . The computing device 110 may be embodied as a mobile device (eg, smartphone, tablet PC, laptop, etc.). The computing device 110 can operate as a software access point. In one aspect, the computing device 110 includes a wireless interface 115 and a processor 118 . These components can work together to determine a view of artificial reality (e.g., a view of the user) corresponding to the position of the HWD 150 and the gaze direction of the user of the HWD 150, and can generate image data , which indicates an image of the artificial reality corresponding to the determined field of view. The computing device 110 can also communicate with the access point 105 , eg, via the wireless link 102 (eg, an interconnect link), and can obtain AR/VR content from the access point 105 . The computing device 110 may receive sensor measurements indicating the position and gaze direction of a user of the HWD 150, such as over the wireless link 125 (e.g., an internal link), and provide the image data to The HWD 150 is used for rendering of the artificial reality. In other embodiments, the computing device 110 includes more, fewer, or different components than those shown in FIG. 1 .

In some embodiments, the wireless interface 115 is an electronic component or an electronic component and a software component that communicates with the HWD 150, the access point 105, the other computing device 110, or any combination thereof. combination. In some embodiments, the wireless interface 115 includes or embodies a transceiver for sending and receiving data over a wireless medium. The wireless interface 115 may be a corresponding component of the wireless interface 165 to communicate with the HWD 150 via a wireless link 125 (eg, internal link). The wireless interface 115 may also include a means to communicate with the access point 105 over a wireless link 102 (eg, an interconnection link). Examples of the wireless link 102 include a cellular communication link, a near field communication link, Wi-Fi, Bluetooth, a 60GHz wireless link, or any wireless communication link. The wireless interface 115 may also include a means to communicate with a different computing device 110 via a wireless link 185 . Examples of the wireless link 185 include a near field communication link, Wi-Fi Direct, Bluetooth, or any wireless communication link. The wireless interface 115 may obtain AR/VR content or other content from the access point 105 via the wireless link 102 (eg, an interconnection link). Through the wireless link 125 (e.g., an internal link), the wireless interface 115 may receive from the HWD 150 information indicating the determined position and/or orientation of the HWD 150, the user's determined gaze direction, and and/or track hand measurements. Furthermore, via the wireless link 125 (eg, an internal link), the wireless interface 115 may send image data describing the image to be imaged to the HWD 150 . Through the wireless link 185 , the wireless interface 115 may receive or transmit information indicating the wireless link 125 (eg, channel, timing) between the computing device 110 and the HWD 150 . Based on the information indicating the wireless link 125, the computing devices 110 can coordinate or schedule operations to avoid interference or collisions.

The processor 118 may include or correspond to a means for generating content to be imaged based on the position and/or orientation of the HWD 150 . In some embodiments, the processor 118 includes or is embodied as one or more central processing units, graphics processing units, image processors, or any processor for generating images of the artificial reality. In some embodiments, the processor 118 may incorporate the gaze direction of the user of the HWD 150, as well as user interactions in artificial reality, to generate the content to be imaged. In one aspect, the processor 118 determines a field of view of the artificial reality based on the position and/or orientation of the HWD 150 . For example, the processor 118 maps the position of the HWD 150 in a physical space to a position within an artificial space, and along a pair corresponding to the mapped position from the artificial space. A field of view of the artificial reality space is determined based on the orientation and direction of the projection. The processor 118 may generate image data describing an image of the determined field of view of the artificial reality space, and send the image data to the HWD 150 through the wireless interface 115 . The processor 118 may encode image data describing the image, and may send the encoded data to the HWD 150 . In some embodiments, the processor 118 periodically (eg, every 11 ms or 16 ms) generates and provides the image data to the HWD 150 .

In some embodiments, the processor 118 may configure or cause the wireless interface 115 to switch, switch, cycle or swap between a sleep mode and a wake mode. In the wake-up mode, the processor 118 can enable the wireless interface 115 such that the wireless interface 115 can exchange data. In the sleep mode, the processor 118 may disable the wireless interface 115 (eg, may implement low power or reduced operation) such that the wireless interface 115 may consume no power, or may consume reduced power. The processor 118 may schedule the wireless interface 115 to periodically switch between the sleep mode and the wake-up mode every frame time (eg, 11 ms or 16 ms). For example, the wireless interface 115 may operate in the awake mode for 2 ms of the frame time, and the wireless interface 115 may operate in the sleep mode for the remainder of the frame time (eg, 9 ms). By disabling the wireless interface 115 in the sleep mode, the power consumption of the computing device 110 and the HWD 150 can be reduced or minimized.

In some embodiments, the processor 118 may configure or cause the wireless interface 115 to resume communication based on stored information indicating communication between the computing device 110 and the HWD 150 . In the awake mode, the processor 118 may generate and store information (eg, channel, timing) for communications between the computing device 110 and the HWD 150 . The processor 118 may schedule the wireless interface 115 to enter a subsequent wake-up mode based on the timing of previous communications indicated by the stored information. For example, the wireless interface 115 can predict/determine when to enter the subsequent wake-up mode according to the timing of the previous wake-up mode, and thus can schedule to enter the subsequent wake-up mode at the predicted time. After generating and storing the information and scheduling the subsequent wake-up mode, the processor 118 may configure or cause the wireless interface 115 to enter the sleep mode. When entering the wake-up mode, the processor 118 may enable or configure the wireless interface 115 to resume communication via the channel or frequency band of the previous communication indicated by the stored information. Thus, the wireless interface 115 can resume communication from the sleep mode and enter the wake-up mode while avoiding scanning procedures to search for available channels and/or perform handshake or authentication. Avoiding the scanning procedure allows extending the duration of operation of the wireless interface 115 in the sleep mode so that the computing device 110 and the HWD 150 can reduce power consumption.

In some embodiments, the computing devices 110A, 110B may operate in coordination to reduce collisions or interference. In one approach, the computing device 110A may periodically send a beacon frame to announce/advertise the existence of a wireless link 125A between the computing device 110A and the HWD 150A, and may coordinate between the computing device 110A and the HWD 150A. communication between the computing device 110A and the HWD 150A. The computing device 110B may monitor or receive beacon frames from the computing device 110A, and may schedule communications with the HWD 150B (e.g., using information in the beacon frames, such as an offset value ) to avoid conflicts or interference with communications between the computing device 110A and the HWD 150A. For example, when the computing device 110A and the HWD 150A are operating in the sleep mode, the computing device 110B may schedule the computing device 110B and the HWD 150B to enter a wake-up mode. For example, when the computing device 110A and the HWD 150A are operating in the awake mode, the computing device 110B may schedule the computing device 110B and the HWD 150B to enter a sleep mode. Thus, multiple computing devices 110 and HWD 150 in close proximity (eg, within 20 ft) can coexist and operate with reduced interference.

In some embodiments, a scheduler 180 (e.g., the scheduler 180A of the computing device 110A and/or the scheduler 180B of the computing device 110B) may request/configure/create TSPEC elements that indicate Data rate, bandwidth characteristics, QoS characteristics, and the like of the identified traffic stream. The AP 105 and the scheduler 180 of the computing device 110 may negotiate (eg, perform a handshake procedure) to establish a membership suitable for a schedule for traffic identified in the TSPEC element. A STA can establish membership in a schedule by negotiating with the AP. STAs can listen to service period (SP) announcements from the AP and get a SP schedule. The STA may provide its own traffic information and/or minimum QoS requirements/other data/traffic characteristics to a configuration procedure. The AP (and/or peer STAs in a peer-to-peer (P2P) configuration) may accept/reject/advise the request (eg, perform admission control) and may perform resource allocation to update the SP schedule.

The scheduler 180 of the computing device 110 may schedule communications between the computing device 110 and the HWD 150 and the AP 105 such that communications between the computing device 110 and the HWD 150 are scheduled. protected/managed. In some embodiments, the computing device 110 may initiate communication with the HWD 150 by indicating to the AP 105 that the computing device 110 wishes to schedule P2P communication in a scheduled specific SP. Protected P2P communication. The scheduler 180 of the computing device may schedule (or negotiate) the requested SP.

When the AP 105 and the scheduler 118 negotiate, the AP 105 can be considered a scheduled AP (eg, AP), and the computing device 110 can be considered a scheduled STA ( For example, STA). In some embodiments, the HWD 150 may request to transmit P2P traffic to the computing device 110 . Thus, the HWD 150 may be considered a requesting STA (e.g., a member's STA requesting a schedule), and the computing device 110 may be considered a responding STA (e.g., a STA responding to the request) . In other embodiments, the computing device 110 may request delivery of P2P traffic to the HWD 150 such that the computing device 110 is considered a requesting STA, while the HWD 150 is a responding STA.

The communication link 125 between the computing device 110 and the HWD 150 may be a P2P link (eg, a link for communication between two non-AP devices). The communication link 102 between the computing device 110 and the AP 105 may be any channel or other type of link. In some configurations, the HWD 150 may move/become out of range of the access point 105 .

FIG. 2 is a diagram of a HWD 150 according to an example embodiment. In certain embodiments, the HWD 150 includes a front rigid body 205 , a left side 240E, a front side 240A, a right side 240D, a bottom side 240C, a top side 240B, and a strap 210 . The front rigid body 205 contains the electronic display 175 (not shown in FIG. 2 ), the lens 180 (not shown in FIG. 2 ), the sensor 155 , the eye trackers 160A, 160B ( not shown), the communication interface (wireless interface) 165, and the processor (imager) 170. In the embodiment shown in FIG. 2, the communication interface 165, the video imager 170, and the sensor 155 are located within the front rigid body 205 and may not be visible to the user. . In other embodiments, the HWD 150 has a different configuration than that shown in FIG. 2 . For example, the communication interface 165 , the video imager 170 , the eye trackers 160A, 160B, and/or the sensor 155 may be in locations other than those shown in FIG. 2 .

Various operations described herein may be implemented on a computer system. FIG. 3 is a block diagram illustrating a representative computing system 314 that may be used to implement the present disclosure, according to an example embodiment. In some embodiments, console 110 , HWD 150 , or both of FIG. 1 are implemented by the computing system 314 . For example, computing system 314 may be implemented as a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smart watch, glasses, head-mounted display), desktop Computers, laptops, or using distributed computing devices for implementation. The computing system 314 can be implemented to provide VR, AR, MR experiences. In some embodiments, the computing system 314 may include conventional computer components such as a processor 316 , a storage device 318 , a network interface 320 , a user input device 322 , and a user output device 324 .

The network interface 320 may provide connection to a wide area network (eg, the Internet) to which the WAN interface of a remote server system is also connected. Network interface 320 may include a wired interface (e.g., Ethernet) and/or an implementation such as Wi-Fi, Bluetooth, or a cellular data network standard (e.g., 3G, 4G, 5G, 60GHz, LTE , etc.) wireless interface of various RF data communication standards.

User input device 322 may include any device (or devices) through which a user may provide a signal to computing system 314; computing system 314 may interpret the signal as indicating a specific user request for information. User input devices 322 may include a keyboard, trackpad, touchscreen, mouse or other pointing device, scroll wheel button, click wheel, dial, button, switch, keypad, microphone, sensor (eg, any or all of motion sensors, eye tracking sensors, etc.), etc.

User output device 324 may include any device through which computing system 314 may provide information to a user. For example, user output device 324 may include a display to display images generated by computing system 314 or communicated to computing system 314 . The display may incorporate a variety of image generating technologies, such as liquid crystal displays (LCDs), light emitting diodes (LEDs) including organic light emitting diodes (OLEDs), projection systems, cathode ray tubes (CRTs) or the like, and Supporting electronic devices (eg, digital-to-analog or analog-to-digital converters, signal processors, or the like). Devices such as touch screens may be utilized that function as both input and output devices. Output device 324 may be provided in addition to or instead of a display. Examples include indicator lights, speakers, tactile "display" devices, printers, and more.

Certain embodiments include electronic components, such as microprocessors, storage, and memory that store computer program instructions in computer-readable storage media (eg, non-transitory computer-readable media). Many of the aspects described in this specification can be implemented as a program, which is defined as a set of program instructions encoded on a computer-readable storage medium. These program instructions, when executed by one or more processors, cause the processors to perform the various operations indicated in the program instructions. Examples of program instructions or computer code are files including machine code generated by, for example, a compiler, and files including higher-level code, which are executed by a computer, electronic component, or microprocessor using an interpreter. Properly programmed, processor 316 may provide various functions to computing system 314, including any of the functions described herein as being performed by a server or client, or other functions related to message management services.

It will be appreciated that computing system 314 is illustrative and thus variations and modifications are possible. Computer systems used in connection with this disclosure may have other functions not explicitly described herein. Furthermore, although computing system 314 is described with reference to particular blocks, it will be appreciated that these blocks are defined for ease of illustration and thus are not intended to refer to a particular physical component of the component parts. configuration. For example, different blocks can be located in the same facility, in the same server rack, or on the same motherboard. Furthermore, the blocks do not need to correspond to actually different components. Blocks can be configured to perform various operations, for example by programming a processor or providing appropriate control circuitry, and various blocks may or may not be reconfigurable, depending on how the original configuration was obtained . Embodiments of the present disclosure may be implemented in a variety of devices, including electronics implemented with any combination of circuitry and software.

In some embodiments, devices may communicate using assigned channel transmit bandwidth such that only licensed (e.g., registered, designated, member) devices may utilize the channel (e.g., during a specific SP , during a specific scheduled period). The device may request membership in a schedule to utilize the channel according to a broadcast shared schedule and/or negotiate membership in the SP using a handshake procedure. The device may utilize TSPEC elements to communicate characteristics (eg, QoS characteristics) of its intended traffic streams as part of the handshake procedure.

For example, a device (eg, a STA or AP) may classify/identify each of the traffic streams according to source/destination address/identification and/or each TID during a setup negotiation procedure. A TID may include an identifier to identify a traffic stream. Traffic identified as delay sensitive (eg, which has a defined delay requirement, eg, is within a certain delay range, or below a defined delay threshold) may be given priority. Member devices (e.g., devices registered/assigned to an SP) can prioritize their delay-sensitive traffic by passing it during their assigned SP (and specified during the setup negotiation procedure) TID related) transmission.

FIG. 4 is a format of a traffic stream (TS) information (Info) field in a TSPEC element according to an example embodiment of the present disclosure. In some configurations, one or more fields are created/configured/modified/added/appended and/or rearranged to enable the TSPEC element to identify multiple TIDs. It is contemplated that the field/bit position (e.g. field, subfield, bitmap, byte group and/or bit position) and/or order in said TS Info field Changes and/or reorderings may be made from those depicted herein.

The Traffic Stream Identifier (TSID) 402 may indicate/identify a traffic stream in an expected traffic flow. The direction 404 may indicate the direction of the traffic identified by the TSID 402 . For example, the direction 404 may indicate whether the traffic identified by the TSID 402 is delivered in the uplink (UL) direction, downlink (DL) direction, bi-directional (e.g., both UL and DL), and and/or whether the traffic is being transmitted directly (eg, point-to-point traffic from one non-AP device to another non-AP device). The combination of the TSID 402 and direction 404 may indicate/represent/identify a single TID and associated direction within a single TSPEC element.

As described herein, one way to characterize multiple TIDs is to pass multiple TSPEC elements. Additionally or alternatively, multiple TIDs may be identified using a single TSPEC element. The plurality of TIDs identified in the TSPEC element may share one or more characteristics (eg, QoS characteristics). In some embodiments, one or more bits may be reprogrammed/modified/appended/set (e.g., set to a defined value such as '1') to indicate additional subfields/fields is valid. These additional subfields/fields can be used to identify multiple TIDs within a single TSPEC element. The single TSPEC element may be utilized to represent characteristics (eg, QoS characteristics) for the plurality of TIDs.

In some embodiments, a bit (or field) in the TS Info field 400 can be configured/reprogrammed/set to indicate the validity of other subfields in the TSPEC element . For example, a TID bitmap valid field 406 (or other specific field/bit) can be set (e.g., with a defined value such as '1') to indicate a TID bitmap subfield The bit is valid (eg, it contains useful/relevant information, eg, multiple TIDs correspond to a single TSPEC element). In one embodiment, the TID bitmap subfield 502 may be indicated in the extremely high throughput (EHT) attribute field 500 described in FIG. 5 . It should be appreciated that the TID bitmap subfield 502 may be indicated in other fields/subfields/bit positions/information elements. For example, the TID bitmap subfield can appear anywhere in the TSPEC element. Furthermore, the position/location of the TID bitmap subfield within the EHT attribute field 500 (or other fields/subfields/bit positions) may be changed/reordered. If the TID bitmap valid field 406 is set (e.g., set to the defined value), then one or more subfields (e.g., TID bitmap subfield 502 in FIG. 5 ) may contain /Points out useful/valid information about multiple TIDs. In some embodiments, the plurality of TIDs may be indicated because the TIDs share QoS characteristics and/or other traffic specifications.

A receiving device parsing the TS Info field 400 may ignore traffic indicated/identified in the TSID 402 if the TID bitmap field 406 is set (eg, to the defined value). The TSID 402 may be invalid/disregarded because it is irrelevant/inapplicable to the traffic specification contained/specified in the TS Info field 400 . It should be appreciated that although multiple TIDs may be indicated in certain subfields (e.g., TID bitmap subfield 502 in FIG. The direction subfield 404 in the TS Info field 400 is extracted.

If the bit/field is not set to the defined value (e.g., TID bitmap valid 406 is unset), then one or more subfields (e.g., EHT in Figure 5 The TID bitmap 502) in the attribute field 500 may contain padding or other non-useful information. Thus, if the bit/field (e.g., TID bitmap valid 406) is unset, certain subfields (e.g., the TID bit in the EHT attribute field 500 of FIG. 5 Figure 502) may be ignored, and other subfields may contain relevant/valid information (eg, TSID 402). In other words, the receiving device can parse the TS Info field 400 and determine the characteristics of a specific TID indicated in the TSID 402 . The EHT attribute field 500 is depicted in more detail in FIG. 5 . What is contemplated is the position (e.g., byte or bit position) and/or order of these bits, fields and/or subfields in an Information Element (IE) and/or TS Info field format Changes and/or reorderings may be made from those depicted herein.

FIG. 5 shows an example of an EHT attribute field format 500 according to an example implementation of the present disclosure. It is contemplated that the position (e.g., field, subfield, bitmap, byte group, and/or bit position) and/or order of bits indicated in the EHT attribute field format 500 Changes and/or reorderings may be made from those depicted herein. The EHT attribute field is an example field in which the TID bitmap 502 can be represented. As described herein, other fields/subfields/bit positions may be used to indicate the TID bitmap. If a field (eg, TID Bitmap Valid 406 in TS Info field 400 in FIG. 4 ) is set, the TID Bitmap 502 may contain information related to multiple TIDs. In some embodiments, the TID bitmap may indicate that the TID shares characteristics (eg, QoS characteristics) specified by the TSPEC element.

The EHT attribute field 500 may be sent in both ways/directions (e.g., from AP to STA and from STA to AP), and in some cases between STAs (e.g., in point-to-point communication or configuration ). In some configurations, fields are created/configured/modified/added/appended and/or rearranged. For example, one or more fields of the EHT attribute field 500 may optionally be created/configured/modified/added/appended and/or reprogrammed during negotiation between an AP and STA. In one embodiment, a STA can modify/reprogram the fields in the EHT attribute field 500 and the TS Info field 400 during negotiation with an AP, which enables the TSPEC element to be used for multiple TID. In response, the AP may append/configure/modify/add corresponding fields to the EHT attribute field 500 for confirming (or rejecting/modifying) the plurality of TIDs requested by the STA.

A TID bitmap subfield 502 can be added/reprogrammed in the EHT attribute field 500 . In some configurations, the TID bitmap subfield 502 may be 2 bytes (or other number of bits or bytes, such as 8 or 14 bits) long. The TID bitmap subfield 502 may indicate a plurality of TIDs identified via a TSPEC element. In some embodiments, the TID bitmap subfield 502 may indicate a TID (identified by the scheduled AP or the scheduled STA) that shares a QoS feature (or other feature).

The TID indicated in the TID bitmap subfield 502 is associated with the single TSPEC element. In an example, the identified TIDs may share QoS features or other features. For example, a value of 1 (or 0) in bit position k in the bitmap may indicate that TID k is identified as sharing features with another TID k+1 in position k+1. A value of 0 (or 1) in bit position k may indicate that TID k does not share the same characteristics as other TIDs that may be indicated. If a TID is not indicated/identified/selected/specified in the TID bitmap subfield 502, then the TSPEC element may not define (or may not apply) the characteristics of that TID. TIDs not indicated in the TID bitmap subfield 502 may be defined/described in a different TSPEC element, or in some cases, the TID (e.g., the TID and/or the corresponding The traffic specification of a traffic stream) may be completely undefined.

As described herein, the TID bitmap subfield (or some other equivalent subfield) may be located in any other field/subfield in the TSPEC element. For example, bits in other fields/subfields (eg, not the EHT attribute field 500 ) may be rearranged/modified/added for the TID bitmap subfield 502 .

In some cases, the STA or AP may not need to know the specific TID identified in a TSPEC element. For example, there may be a situation when a device is utilizing P2P communication to send traffic. In other words, the Direction 404 subfield may indicate that 'direct link' traffic is being passed. In this example, a device receiving the TSPEC element can parse the TS Info field 400 as well as other fields, and can extract the characteristics of the flow/link without associating the characteristics to a TID. In one example, a device such as an AP may extract characteristics (such as QoS characteristics) rather than the associated one or more from the TID bitmap subfield (if any) in the TSPEC element. TID. In this example, the AP may not fetch the TID indicated in the TSPEC element, because the device may not use the specific plurality of TIDs indicated (e.g., in the TID bitmap subfield middle). The second device (e.g., a STA) may report to the device (e.g., the AP) the presence of direct link traffic (e.g., P2P traffic) and related traffic of the direct link traffic A general indication of a feature.

In an example implementation, an AP and a STA negotiating a restricted target wake-up time (rTWT) schedule may not require information about TIDs communicated in P2P traffic. However, the AP can still benefit from extracting the requested characteristics in the TSPEC element for such P2P traffic. Thus, during negotiation of an rTWT schedule, if the direction subfield 404 indicates that direct link traffic is being passed, the receiving device may ignore TSID 402, TID bitmap valid 406, and/or Or the TID bitmap 502 in FIG. 5 .

FIG. 6 depicts an interaction/flow diagram illustrating a process 600 for specifying one or more TIDs in a single TSPEC element according to an example implementation of the present disclosure. In some embodiments, the program 600 is executed by a first device 601 and a second device 602 . The first device 601 and the second device 602 may be some combination of an AP (eg, AP 105 ), a software AP, and/or a station (eg, computing device 110 ). In some embodiments, the process 600 is performed by other entities. In some embodiments, the procedure 600 includes more, fewer, or different steps than those shown in FIG. 6 .

In more detail of operation 603, the first device 601 may configure a field in a message indicating a group/bundle/plurality of TIDs (which represent/identify traffic streams). As described herein, the first device 601 can indicate such a TID because the TID can share QoS features. For example, the first device 601 may request communication of multiple traffic streams in a specific SP. Alternatively, the first device 601 may accept/approve (or modify/deny) a request (eg, from a second device 602 ) of multiple TIDs. A field or subfield (eg, a first field) in the message may indicate (when set to a defined value) the plurality of TIDs identified in the TSPEC element. Specifically, the field may indicate whether one or more subfields in a second field are valid. The field may include a valid bit indication corresponding to one or more subfields containing valid/invalid information. For example, referring to FIG. 4, the TID bitmap valid 406 in the TS Info field 400 can be set (to the defined value) which indicates the number of TIDs in the TSPEC element. These TIDs can be identified (or grouped/bundled in a single TSPEC element) because they share QoS characteristics (or other characteristics). In other words, if the valid bit indicator is set (eg, valid 406 in TID bitmap in FIG. 4 ), then a corresponding subfield (eg, TID bitmap 502 in FIG. 5 ) ) can contain valid information. Furthermore, if the TID bitmap valid 406 in the TS Info field 400 is set, the first device 601 may communicate that the second device 602 should ignore the TS Info field in the TSPEC element Any bits in the TSID subfield 402 in the bits 400 (eg, should not be related/applicable to the traffic specification described/indicated in the TSID subfield 402 to the TS Info field 400 or TSPEC element).

Another field in the message (eg, the second field) may indicate/contain a bitmap conveying the plurality of TIDs sharing a TSPEC element. The second field may represent/identify (or correspond to) a TID utilizing the TSPEC element. The TIDs can be indicated/pointed/identified because they share QoS features (or other features). As described with reference to FIG. 5, a TID bitmap 502 may be added/remapped to the EHT attribute field 500 (or other fields in the TSPEC element). The TID bitmap 502 may be a plurality of TIDs in the single TSPEC element. The TIDs may share QoS characteristics and/or other traffic specifications.

Another sub-field (direction sub-field) in the first field in the message may indicate a TID (for example, the TID indicated in TSID 402 in TS Info field 400 of FIG. 4 ) and/or or a direction of multiple TIDs (eg, the TIDs indicated in the TID bitmap 502 in the EHT attribute field 500 of FIG. 5 ). If the first field is not set to the defined value (eg, TID Bitmap Valid 406 is not set), then the direction subfield may indicate the direction of a TID. If the first field is set to the defined value (eg, TID Bitmap Valid 406 is set), then the direction subfield may indicate the direction of multiple TIDs. The direction subfield (e.g., direction 404 in TS Info field 400 of FIG. 4) may indicate a traffic flow in the UL direction, a traffic flow in the DL direction, a bidirectional traffic flow stream, or a flow of traffic in one direction. The direction of traffic can be indicated for a specific SP. If the direction subfield indicates that direct link traffic is being passed (e.g., the first device 601 and a third device (not shown) intend to communicate using P2P communication), then the direction subfield may cause all The second means 602 ignores the plurality of TIDs indicated in the TID bitmap 502 of FIG. 5 . In a specific example, if the P2P communication is in an SP of an rTWT, the second device 602 may ignore the plurality of TIDs indicated in the TID bitmap 502 .

In more details of operation 620 , the first device 601 may send the message to the second device 602 . For example, the first device 601 may send the message as part of a handshake procedure.

In more detail of operation 604 , the second device 602 may receive the message sent by the first device 601 . The second device 602 can extract information from the message. In operation 606 , the second device 602 may generate a response message in response to the information extracted from the received message in operation 620 . In some embodiments, the response message may be (eg, structurally, operationally) similar to the message. For example, in some embodiments, an AP (e.g., the second device 602) may respond to the message by generating a response message authorizing the STA (e.g., the first device 601) to transmit during a specific SP The plurality of TIDs. The AP may approve the message by generating a response message similar to the message (e.g., using the configured subfield to copy the message, using the configured subfield to match said message). In one example, if the second device 602 is an AP, the second device 602 can schedule downlink traffic (or point-to-point traffic) to transmit from the first device 601 (for example, a STA) to send it. In some embodiments, if the TID is indicated as a common QoS feature (or other feature), the second device 602 can use (or according to) the QoS feature (or traffic specification) to schedule downlink traffic (or P2P traffic). In another example, if the second device 602 is a STA, the second device 602 can schedule uplink traffic (or point-to-point traffic) to transmit from the first device 601 (for example, an AP) , a different STA) to send. In some embodiments, if the TID is indicated as a common QoS feature (or other feature), the second device 602 can use the QoS feature (or traffic specification) to schedule uplink traffic (or P2P traffic ).

In other embodiments, the response message generated in operation 606 may be (eg, structurally, operationally) different from the message. If the response message does not match the message received by the second device 602, the second device 602 may reject multiple TIDs in a particular SP, suggesting alternative traffic streams to be bundled/grouped One or more other parameters (eg, allocated time, SP interval, QoS characteristics, etc.) are modified in the specific SP (or a different SP) and/or in the TSPEC element.

The response message may partially reject (or modify/suggest) one or more parameters of the message generated in operation 603 . For example, the second device 602 may reject one or more features/parameters requested in the message 620 . In particular, the second device 602 may deny a requested SP interval. The response message may also completely reject (or modify) the message generated in operation 603 . For example, the SP requested to deliver multiple TIDs may be full (eg, thus unable to accept/contain/schedule an additional traffic stream). In this example, the second device 602 may suggest an alternative schedule to the first device 601 to deliver the plurality of TIDs. Then, the response message will reject the message generated in operation 603 and suggest an alternative schedule.

In more details of operation 622 , the second device 602 may send the response message to the first device 601 . In more details of operation 607 , the first device 601 may receive the response message from the second device 602 . The response message may be received (in part) in response to the message delivered to the second device 602 in operation 620 . The first device 601 can extract information from the response message. For example, the first device 601 may compare one or more parts of the response message with the message generated in operation 603 to determine whether the plurality of TIDs requested for a specific SP are partially/completely approved, Refusal, and/or Modification. If the response message matches the message, the first device 601 may determine that the plurality of TIDs are authorized for transmission during the SP. Furthermore, the first device 601 may determine that the first device 601 and the second device 602 have agreed on one or more other parameters that may have been present in the message generated at 603 (for example, allocated time/ SP interval, QoS characteristics).

If the response message is a partial match, the first device 601 may determine that the response message matches the part of the message to indicate agreement. For example, a partially matching portion of the response message may indicate that TIDs requested to be delivered during a particular SP are authorized for transmission during that SP. The non-matching portion of the response message may indicate a disagreement (eg, rejection, modification, and/or suggestion of one or more parameters). For example, the mismatch portion of the response message may indicate a suggested SP interval.

Referring back to operation 607, the first device 601 may start a procedure according to the response message. For example, the first device 601 may schedule the plurality of TIDs (eg, approved/accepted by the second device 602 in the request message) to time slots and may deliver these traffic streams. Delivering the traffic may include/include sending the traffic stream using slots, time durations, media access mechanisms, symbols, carriers, and the like. Additionally or alternatively, the first device 601 may prepare a subsequent message to be sent to the second device 602 that approves/rejects/modifies a response message received by the first device 601. or multiple sections.

Having now described certain illustrative embodiments, it is apparent that the foregoing is by way of illustration and not limitation, which has been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts, and those elements, may be combined in other ways to achieve the same goal. Acts, elements and aspects discussed in relation to one embodiment are not intended to be excluded from a similar role in other embodiments.

The hardware and data processing components used to implement the various procedures, operations, illustrated logic, logical blocks, modules, and circuits described with respect to the embodiments disclosed herein may utilize general purpose single or multi-chip processing device, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware body component, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, or any well known processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some embodiments, specific procedures and methods may be performed by circuitry dedicated to a given function. The memory (e.g., memory, memory unit, storage, etc.) may include one or more devices (e.g., RAM, ROM, flash memory, hard disk storage, etc.) for Store data and/or computer code used to implement or facilitate the various programs, layers and modules described in this disclosure. The memory may be or include volatile memory or non-volatile memory, and may include database components, object code components, text components, or any other type of information structure used to support the The various activities and information structures described. According to an example embodiment, the memory is communicatively coupled to the processor via a processing circuit and includes computer code for execution (e.g., by the processing circuit and/or the processor) in one or more of the procedures described herein.

The present disclosure contemplates methods, systems, and program products on any machine-readable medium for performing various operations. Embodiments of the present disclosure may be implemented using off-the-shelf computer processors, or by special purpose computer processors incorporated for this or other purposes in appropriate systems, or by hard-wired systems. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer, or other machine with a processor. For example, such machine-readable media may include RAM, ROM, EPROM, EEPROM, or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other medium that may be utilized to carry or Desired program code in the form of machine-executable instructions or data structures is stored and accessible by a general purpose or special purpose computer, or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing machine to perform a certain function or group of functions.

The phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of "comprising", "comprising", "having", "comprising", "involving", "characterized by", "characterized by" and variations thereof is meant to encompass the items listed thereafter, other Equivalents, and additional items, and alternative embodiments, consist only of the items listed thereafter. In one embodiment, the systems and methods described herein are made up of one, each combination of more than one, or all of the elements, acts, or components described herein.

Any singular reference herein to an embodiment or element or act of the described systems and methods may also include an embodiment including a plural of such elements, and any plural reference herein to any embodiment or element or act may also include Embodiments comprising only a single element are included. References in singular or plural are not intended to limit the presently disclosed systems or methods, components, acts, or elements thereof to a single or plural configuration. Reference to any act or element being based on any information, act or element may include an embodiment in which said act or element is based at least in part on any information, act or element.

Any embodiment disclosed herein may be combined with any other embodiment or example, and references to "an embodiment," "some embodiments," "one embodiment," or the like are not necessarily mutually exclusive It is intended to point out that a specific aspect, structure or feature described in relation to the above-mentioned embodiments may be included in at least one embodiment or example. Such terms as used herein do not necessarily all refer to the same embodiment. Any embodiment can be combined inclusively or exclusively with any other embodiment in any manner consistent with the aspects and embodiments disclosed herein.

In the case where a technical aspect in a drawing, a detailed description, or any claim is followed by an element symbol, the element symbol is added to increase the intelligibility of the drawing, detailed description, and claim. Thus, the presence or absence of said element symbols has no limiting effect on the scope of any claim element.

The systems and methods described herein may be embodied in other specific forms without departing from their characteristics. Unless expressly stated otherwise, references to terms of "approximately," "approximately," "substantially," or other degrees include variations of +/- 10% from the given measurement, unit, or range. Coupled elements may be electrically, mechanically, or physically coupled to each other directly or with intervening elements. Accordingly, the scope of the systems and methods described herein is indicated by the appended claims, rather than the preceding description, and variations that come within the meaning and range of equivalence of the claims are contemplated. included in it.

The term "coupled" and variations thereof includes the direct or indirect joining of two elements to each other. Such engagement may be static (eg, permanent or fixed), or movable (eg, removable or releasable). Such engagement may be where the two members are coupled directly to each other or to each other, where the two members are by means of a further intervening member and any additional intermediate members that are coupled to each other. and each other, or when the two members are coupled to each other by means of an intervening member that is integrated with one of the two members into a single body to achieve of. If "coupled" or variations thereof are modified by an additional term (e.g., directly coupled), then the generic definition of "coupled" set forth above is defined by the plain language meaning of the additional term (eg, "directly coupled" means the joining of two elements without any individual intervening elements), which yields a narrower definition than the generic definition of "coupled" set forth above. Such coupling may be mechanical, electrical, or fluid.

References to "or" may be construed as inclusive such that any item recited with "or" may indicate any of a singular, more than one, and all of said items. References to "at least one of 'A' and 'B'" may include only 'A', only 'B', and both 'A' and 'B'. Such references used in conjunction with "comprises" or other open-ended terms may contain additional items.

Modifications of the components and actions, such as changes in the size, size, structure, shape and proportion, parameter values, installation configuration, use of materials, colors, and orientations of various components, can be made without substantially departing from the subject matter disclosed here. Based on the teachings and advantages of For example, elements shown as integrally formed may be constructed of multiple parts or elements, the position of elements may be reversed or varied, and the nature or number or positions of discrete elements may be altered or varied. Other substitutions, modifications, changes and omissions may also be made in the design, operating conditions and arrangement of the disclosed elements and operations without departing from the scope of the present disclosure.

References herein to the location of elements (eg, "top," "bottom," "above," "below") are used only to describe the orientation of the various elements in the drawings. According to other example embodiments, the orientation of various elements may be different, and such variations are intended to be encompassed by this disclosure.

100: Artificial Reality System Environment 102, 102A, 102B: wireless link 105: Access Point (AP) 110, 110A, 110B: Computing devices 115: wireless interface 118: Processor 125, 125A, 125B: wireless link 150, 150A, 150B: Head Wearable Display (HWD) 155: sensor 165: wireless interface 170: Processor 175: Display 180, 180A, 180B: Scheduler 185: wireless link 205: Front Rigid Body 210: strip 240A: front side 240B: top side 240C: bottom side 240D: right side 240E: Left 314:Computing systems 316: Processor 318: storage device 320: Network interface 322: User input device 324: User output device 400: Traffic stream information (TS Info) field 402: Traffic Stream Identifier (TSID) 404: Direction Subfield 406: Valid fields of TID bitmap 500: Extremely high throughput (EHT) attribute field 502:TID bitmap subfield 600: program 601: First device 602: Second device 603: Operation 604: Operation 606: Operation 607: Operation 620: Operation 622: Operation

The accompanying drawings are not intended to be drawn to scale. Like element numbers and designations in the various drawings indicate similar elements. For purposes of clarity, not every component may be labeled in every figure.

[ FIG. 1 ] is a diagram of a system environment including an artificial reality system according to an exemplary embodiment of the present disclosure.

[ FIG. 2 ] is a diagram of a head wearable display according to an exemplary embodiment of the present disclosure.

[ FIG. 3 ] is a block diagram of a computing environment according to an example embodiment of the present disclosure.

[ FIG. 4 ] is a format of a traffic stream information field in a TSPEC element according to an example embodiment of the present disclosure.

[ FIG. 5 ] is an example showing an extremely high throughput (EHT) attribute field format according to an example embodiment of the present disclosure.

[ FIG. 6 ] is an interaction/flow diagram showing a procedure for specifying one or more TIDs in a single TSPEC element according to an example embodiment of the present disclosure.

600: program

601: First device

602: Second device

603: Operation

604: Operation

606: Operation

607: Operation

620: Operation

622: Operation

Claims (20)

A method comprising: configuring, by the first wireless communication device, a bitmap indicating a plurality of traffic identifiers (TIDs) sharing a traffic specification (TSPEC) element; and Sending a message including the bitmap to a second wireless communication device by the first wireless communication device. The method of claim 1, wherein the message includes a field set to a predefined value to indicate that the bitmap contains valid information. The method of claim 2, wherein said field being set to said predefined value causes said second wireless communications device to ignore a traffic stream identifier associated with said TSPEC element. The method of claim 1, wherein the message includes a direction subfield indicating the direction of the plurality of TIDs. The method of claim 4, wherein the direction subfield indicates one of the following: transmit traffic in the uplink direction, transmit traffic in the downlink direction, bidirectionally transmit traffic, or direct transmit link road traffic. The method of claim 5, which includes: When the direction subfield indicates the directly transmitted link traffic and the directly transmitted link traffic is transmitted during service of a restricted target wake-up time, causing the second wireless communication device to ignore the Plural TIDs. The method of claim 1, wherein the second wireless communication device comprises an access point or a station device. The method of claim 1, wherein said TSPEC element includes characteristics shared by said plurality of TIDs. A first wireless communication device, comprising: at least one processor configured to configure a bitmap indicating a plurality of traffic identifiers (TIDs) sharing a traffic specification (TSPEC) element; and and a transmitter for transmitting a message including the bitmap to a second wireless communication device. The first wireless communication device of claim 9, wherein the message includes a field set to a predefined value to indicate that the bitmap contains valid information. The first wireless communication device of claim 10, wherein the field set to the predefined value causes the second wireless communication device to ignore traffic stream identifiers associated with the TSPEC element. The first wireless communication device according to claim 9, wherein the message includes a direction subfield indicating directions of the plurality of TIDs, wherein the direction subfield indicates one of the following: in an uplink direction transmit traffic, transmit traffic in the downlink direction, bidirectional transmit traffic, or direct transmit link traffic. The first wireless communication device of claim 12, wherein when the direction sub-field indicates the directly transmitted link traffic and the directly transmitted link traffic is transmitted during service of a restricted target wake-up time , the direction subfield is configured such that the second wireless communication device ignores the plurality of TIDs. A method comprising: receiving a message including a bitmap from the first wireless communication device by the second wireless communication device, Wherein the bitmap indicates a plurality of traffic identifiers (TIDs) sharing a traffic specification (TSPEC) element. The method of claim 14, wherein the message includes a field set to a predefined value to indicate that the bitmap contains valid information. The method as claimed in item 15, comprising: When the field is set to the predefined value, it is determined by the second wireless communication device to ignore the traffic stream identifier associated with the TSPEC element. The method of claim 14, wherein the message includes a direction subfield indicating the direction of the plurality of TIDs. The method of claim 17, wherein the direction subfield indicates one of the following: transmit traffic in the uplink direction, transmit traffic in the downlink direction, bidirectionally transmit traffic, or direct transmit link road traffic. The method of claim 18, comprising: Determined by the second wireless communication device when the direction sub-field indicates the directly transmitted link traffic and the directly transmitted link traffic is transmitted during service of a restricted target wake-up time The plurality of TIDs are ignored. A second wireless communication device includes a receiver and at least one processor configured to implement the method of claim 14.

Images