KR20160006209A - Qoe-aware wifi enhancements for video for video applications - Google Patents

Abstract

The importance level may be determined using the history of packet loss associated with the video packet at the video source and / or corresponding to the video flow. A video packet may be associated with a class and may be further associated within a subclass based on, for example, a level of importance. Associating a video packet with a level of importance may include receiving a video packet associated with the video stream, assigning a level of importance to the video packet, and transmitting the video packet according to the access category and importance level. The video packet may be characterized by an access category. The importance level may be associated with a transmission priority of a video packet in the access category of the video packet and / or a retransmission limit of the video packet.

Description

QUE-AWARE WIFI ENHANCEMENTS FOR VIDEO FOR VIDEO APPLICATIONS FOR VIDEO APPLICATIONS -

relation Cross reference to applications

This application claims priority to U.S. Provisional Patent Application No. 61 / 820,612, filed May 7, 2013, and U.S. Patent Application No. 61 / 982,840, filed April 22, 2014, Which is incorporated herein by reference.

The media access control (MAC) sublayer may include enhanced distributed channel access (EDCA) functionality, hybrid coordination function controlled channel access (HCCA) functionality, and / Or mesh coordination function controlled channel access (MCCA) functionality. The MCCA may be used for mesh networks. The MAC sublayer may not be optimized for real-time video applications.

Systems, methods, and means are disclosed for improvements to real-time video applications. One or more modes or functions of WiFi, such as, for example, Enhanced Distributed Channel Access (EDCA), Hybrid Coordination Function (HCF) Control Channel Access (HCCA), and / or Distributed Content Function (DCF) May be improved. The importance level may be associated with a video packet at a video source (e.g., a video transmission device) and / or determined (e.g., determined dynamically based on the history of packet loss generated for that video stream, for example) ). A video packet may be associated with a class such as, for example, an access category video (AC_VI), and then further associated within a subclass based on, for example, a level of importance.

A method of associating a video packet with an importance level may include, for example, receiving a video packet associated with a video stream from an application layer. The method may include assigning the importance level to a video packet. The importance level may be associated with the transmission priority of the video and / or the retransmission limit of the video packet. The video packet may be transmitted according to the retransmission limit. For example, transmitting a video packet may include transmitting the video packet, routing the video packet, transmitting the video packet to the buffer for transmission, and so on.

The access category may be a video access category. For example, the access category may be AC_VI. The importance level may be characterized by a contention window. The importance level may be characterized by an Arbitration Inter-Frame Space Number (AIFSN). The importance level may be characterized by a Transmission Opportunity (TXOP) limit. The importance level may be characterized by a retransmission limit. For example, the importance level may be characterized by one or more of a contention window, an AIFSN, a TXOP, and / or a retransmission limit specific to the importance level. The retransmission limit may be assigned based on the importance level and / or at least partially on the loss event.

The video stream may comprise a plurality of video packets. A first subset of the plurality of video packets may be associated with a first importance level and a second subset of the plurality of video packets may be associated with a second importance level. A first subset of video packets may comprise I frames, while a second subset of video packets may comprise P frames and / or B frames.

1 is a diagram illustrating an exemplary MAC architecture.
2 is a diagram showing an example of a system.
3 is a diagram illustrating an example system architecture for an example static video traffic prioritization approach to EDCA.
4 is a diagram illustrating an example system architecture for an example dynamic video traffic prioritization approach to EDCA.
5 is a diagram showing an example of binary prioritization.
6 is a diagram showing an example of no differentiation.
Fig. 7 shows an example of the PSNR of the function of the frame number.
Figure 8 shows an example of three-level dynamic prioritization.
Figure 9 shows an example Markov chain model for modeling video packet classes.
Figure 10 shows an example fixed frame comparison.
Figure 11 shows an exemplary topology of a network.
Figure 12 shows an example video sequence.
13 illustrates simulated collision probabilities of an example.
Figure 14 shows simulated percentages of examples of frozen frames.
15 shows simulated average percentages of examples of fixed frames for different RTTs between a video transmitter and a receiver.
Figure 16 is a diagram illustrating an example reassignment method in which packets are reassigned to ACs upon arrival of a packet.
17 is a diagram showing an example of a reallocation method for causing the latest packets to be allocated to ACs upon arrival of a packet to be optimized.
18 is a diagram illustrating an example system architecture for an example static video traffic differentiation approach to DCF.
19 is a diagram illustrating an example system architecture for an example dynamic video traffic differentiation approach to DCF.
20A is a system diagram of an example communication system in which one or more of the disclosed embodiments may be implemented.
FIG. 20B is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 20A.
FIG. 20C is a system diagram of an example wireless access network and an example core network that may be used in the communication system illustrated in FIG. 20A.
20D is a system diagram of an example wireless access network and an example core network that may be used within the communication system illustrated in FIG. 20A.
20E is a system diagram of an example wireless access network and an example core network that may be used in the communication system illustrated in FIG. 20A.
Figure 21 illustrates an example Markov chain model for video packet classes.

The detailed description of specific embodiments will now be described with reference to the various figures. Although this description provides detailed examples of possible implementations, it should be noted that the details are intended to be illustrative and not in a limiting sense the scope of the present application.

For example, quality of experience (QoE) for video applications such as real-time video applications (e.g., video telephony, video gaming, etc.) may be optimized and / or bandwidth (BW) May be reduced for IEEE 802.11 standards (e.g., WiFi related applications). One or more modes of WiFi, such as enhanced distributed channel access (EDCA), hybrid coordination function (HCF) control channel access (HCCA), and / or distributed content function (DCF) It is possible. The importance level may be associated with (e.g., attached to) the video packet at the video source, e.g., for each mode. The importance level may be determined (e.g., dynamically determined) based on the history of the packet loss generated for the flow of the video stream, for example. Video packets of a video application may be divided into sub-classes based on importance level. The importance level may be determined for each video packet, for example, dynamically, e.g., for each mode, by a station (STA) or an access point (AP). An AP may, for example, refer to a WiFi AP. The STA may refer to a wireless transmit / receive unit (WTRU) or a wired communications device, such as a personal computer (PC), a server, or other device that may not be an AP.

A reduction in QoE prediction to peak signal-to-noise ratio (PSNR) time series prediction may also be provided herein. A frame-by-frame PSNR prediction model that may be jointly implemented by a video transmitter (e.g., microcontroller, smartphone, etc.) and a communications network may be described.

One or more enhancements to the Media Access Control (MAC) layer may be provided herein. FIG. 1 is a diagram illustrating an example MAC architecture 100. FIG. MAC architecture 100 includes one or more functions such as Enhanced Distributed Channel Access (EDCA) 102, HCF Control Channel Access (HCCA) 104, MCF Control Channel Access (MCCA) 106, A mesh adjustment function (MCF) 110, a point adjustment function (PCF) 112, a dispersion adjustment function (DCF) 114, and the like.

2 is a diagram illustrating an example of a system 200. In FIG. System 200 may include one or more APs 210 and one or more STAs 220 that may deliver real-time video traffic (e.g., video call traffic, video gaming traffic, etc.) . Some applications may act as cross traffic.

A static approach may be used to prioritize the transmission of packets in a video application (e.g., a real-time video application). In a static approach, the importance of a video packet may be determined by a video source (e.g., a video transmitter). The importance of a video packet may remain the same during transmission of this packet across the network.

A dynamic approach may be used to prioritize the transmission of packets in a video application (e.g., a real-time video application). In a dynamic approach, the importance of a video packet may be dynamically determined by the network, for example, after the video packet leaves the source and before the video packet arrives at its destination. The importance of a video packet may be based on what happened to past video packets in the network and / or what might be expected to happen to future video packets in the network.

Although described with reference to video telephony, the techniques described herein may be used with any real-time video applications, such as, for example, video gaming.

Enhancements to EDCA may be provided. In EDCA, the following four access categories (ACs) may be defined: AC_BK (for background traffic), AC_BE (for best effort traffic), AC_VI And AC_VO (e.g., for voice traffic). (E.g., as determined by setting an AIFS number (AIFSN)), and / or a transmission opportunity (e.g., a contention window, CW) TXOP) may be unlimitedly defined. Quality of Service (QoS) differentiation may be achieved by assigning each AC to a different set of values for CW, AIFS, and / or TXOP limits.

ACs (e.g., AC_BK, AC_BE, AC_VI, AC_VO) may be referred to as classes. The video packets of AC_VI may be divided into sub-classes based on the importance level. One or more parameters (e.g., contention windows, AIFS, TXOP limits, retransmission limits, etc.) may be defined for each importance level (e.g., sub-class) of video packets. Quality of service (QoS) differentiation may be achieved within the AC_VI of a video application, for example, by using a level of importance.

Table 1 shows example settings for CW, AIFS, and TXOP limits for each of the four ACs described above when the dot11OCBActivated parameter has a false value. When the dot11 OCBActivated parameter has a false value, the network (e.g., WiFi network) operation may be in a normal mode, for example, the STA may participate in a basic service set (BSS) and transmit data. A network (e.g., a WiFi network) may be configured with parameters that may be different from the values shown in Table 1 based on, for example, the traffic conditions and / or QoS requests of the network.

Table 1: Example of EDCA parameter set element parameter values

Video traffic may be handled differently from other types of traffic (e.g., voice traffic, best effort traffic, background traffic, etc.) in the 802.11 standard, for example. For example, the access category of a packet may determine how the packet is transmitted with respect to packets of other access categories. For example, the AC of the packet may indicate the transmission priority of the packet. For example, voice traffic (AC_VO) may be transmitted with the highest priority of ACs. However, for example, in the 802.11 standard, there may be no differentiation between the types of video traffic in the AC_VI. The impact of loss of video packets on the quality of the recovered video may be different for each packet, for example, not all video packets may be equally important. Video traffic may be further differentiated. Compatibility of video traffic with other traffic classes (e.g., AC_BK, AC_BE, AC_VO) and video streaming traffic may be considered. When video traffic is further differentiated into subclasses, the performance of other ACs may remain unchanged.

One or more Enhanced Distributed Channel Access Functions (EDCAFs) may be generated for video traffic, e.g., video call traffic. One or more EDCAFs may refer to quantization of the QoS metric space using video AC. One or more EDCAFs may reduce or minimize control overhead while providing sufficient differentiation levels within the video traffic.

A static approach may be used to prioritize the transmission of packets in a video application (e.g., a real-time video application). In a static approach, the importance of a video packet may be determined by the video source. The importance of a video packet may change during transmission of this packet across the network. Static prioritization of video packets may be performed at the source. The priority level may change, for example, during transmission of a video packet based on the history of packet loss occurring for this flow. For example, a packet that was considered by a video source to be of highest importance may be downgraded to a lower importance level due to packet loss incurred for that flow.

3 is a diagram illustrating an example system architecture 300 for an example static prioritization approach to EDCA. The network layer 302 may forward the packet importance information to the video importance information database 304. [ The packet importance information may provide a level of importance to different types of video packets. For example, in the case of hierarchical P, temporal layer 0 packets may become more important than temporal layer 1 packets, temporal layer 1 packets may be more important than temporal layer 2 packets, and so on.

Video traffic may be separated into two classes, e.g., real-time video traffic and other video traffic, for example, by an AC mapping function. Other video traffic may be referred to as AC_VI_O. AC_VI_O may be serviced for the physical layer (PHY) to be transmitted in such a manner that video traffic is serviced according to AC for video. The mapping of packets (e.g., IP packets) and aggregated MPDUs (A-MPDUs) may be performed using a table lookup.

The real-time video traffic may be differentiated using the importance information of the packets, for example, the hierarchical P classification described herein. For example, packets belonging to temporal layer 0 may be characterized by importance level 0, packets belonging to temporal level 1 may be characterized by importance level 1, packets belonging to temporal layer 2 may be characterized by importance level 2 . ≪ / RTI >

The contention window may be defined based on the importance level. The range of contention windows CW [AC_VI] for video, which may be represented as [CWmin (AC_VI), CWmax (AC_VI)], may be partitioned, for example, . CW (AC_VI) may grow exponentially with the number of unsuccessful attempts to send the MPDU, for example starting from CWmin (AC_VI) and peaking at CWmax (AC_VI). The back off timer may be randomly set, for example, uniformly from the interval [0, CW (AV_VI)]. A backoff timer may be triggered after the medium remains idle for an AIFS amount of time and then it may be specified how long the STA or AP will not operate before accessing the medium.

AC_VI_1, AC_VI_2, ..., AC_VI_n may be defined. The video traffic delivered by AC_VI_i may be more important than the video traffic carried by AC_V_j for i <j. The intervals [CWmin (AC_VI), CWmax (AC_VI)] may be partitioned into n intervals, which may or may not have the same lengths, for example. For example, if the intervals have the same lengths, then for AC_VI_i, its CW (AC_VI_i) may be used at an interval in accordance with the following rules, such as at exponentially increasing intervals with the number of attempts to send an MPDU Values.

[ceiling (CWmin (AC_VI) + (i-1) * d), floor (CWmin

Where ceiling () may be a ceiling function, floor () may be a floor function, and d = (CWmax (AC_VI) -CWmin (AC_VI)) / n.

Compartmenting the range of contention windows for video in this manner may meet compatibility requirements when the amounts of traffic to different video phone traffic types are equal. The distribution of the backoff timer for the entire video traffic may be kept close without compartmentalization.

The intervals [CWmin (AC_VI), CWmax (AC_VI)] may be partitioned not to be the same. For example, the amount of traffic of different types of video traffic may not be the same. The intervals [CWmin (AC_VI), CWmax (AC_VI)] are calculated such that small intervals arising from the compartment are proportional to the traffic amount of the traffic class (e.g., each traffic amount of each traffic class) Or may be unequally partitioned so as to be possible. The traffic quantities may be monitored and / or estimated by the STA and / or the AP.

The inter-inter-frame spacing (AIFS) may be defined based on the importance level. For example, AIFS numbers (AIFSNs) for ACs with a higher priority than AC_VI and AC with lower priority than AC_VI may be AIFS1 and AIFSN2, respectively. For example, in Table 1, AIFSN2 = AIFSN (AC_BE) and AIFSN1 = AIFSN (AC_VO).

The n numbers may be selected from the interval [AIFS1, AIFSN2] for AIFSN (AC_VI_i), i = 1, 2, ..., n, each of which is for the type of video call traffic, AIFSN (AC_VI_2) &lt; / = AIFSN (AC_VI_n). Differentiation between full video traffic and other traffic classes may be preserved. For example, if different types of video packets are differentiated based on importance levels, if the video stream may maintain access to the medium in case the video traffic may be serviced as a whole, You can still access it.

One or more constraints may be imposed. For example, the average of these n selected numbers may be equal to AIFSN (AC_VI) used when no differentiation in video traffic based on importance is performed.

A TXOP limit may be defined based on the importance level. The setting for the TXOP limit may be PHY specific. The TXOP limit for a given type of PHY (termed PHY_Type) and access category may also be denoted as TXOP_Limit (PHY_Type, AC). Table 1 shows examples of three types of PHYs, e.g., PHYs (e.g., DSSS and HR / DSSS) defined in Sections 16 and 17, Sections 18, 19 and 20 Defined PHYs (e.g., OFDM PHY, ERP, HT PHY), and other PHYs. For example, the PHY_Type may be 1, 2, and 3, respectively. For example, TXOP_Limit (1, AC_VI) = 6.016 ms may be for PHYs defined in Sections 16 and 17.

The maximum possible TXOP limit may be TXOPmax. For example, for the i = 1, 2, ..., n, for n TXOP_Limit (PHY_Type, AC_VI_i), for each type of video packets, in the interval near TXOP_Limit (PHY_Type, AC_VI) Numbers may be defined. Standards may be imposed on these numbers. For example, the average of these numbers may be equal to TXOP_Limit (PHY_Type, AC_VI), for example, for compatibility.

Retransmission limits may be associated with the importance level. The 802.11 standard may define two attributes, e.g., dot11LongRetryLimit and dot11ShortRetryLimit, to set a limit on the number of retransmission attempts that may be the same for EDCAFs. The attributes (dot11LongRetryLimit and dot11ShortRetryLimit) may vary depending on the importance information (e.g., priority) of the video traffic.

a * amountTrqffic(AC_VI_i) +(1-a) * (지속기간 T의 마지막 시간 간격 내에 도착된 AC_VI_i에서의 프레임들의 수), 여기서 시간은 지속기간 T의 시간 간격들로 구획화될 수도 있고, 0<a<1이 상수 가중치일 수도 있다.For example, values such as dot11LongRetryLimit = 7 and dot11ShortRetryLimit = 4 may be used. Values, e.g., dot11LongRetryLimit (AC_VI_i) and dot11ShortRetryLimit (AC_VI_i), i = 1, 2, ..., n, may be defined for each importance level (e.g., priority) of video traffic. Higher priority packets (e.g., based on importance information) may be provided to more potential retransmissions, and lower priority packets may be given to less potential retransmissions. The retransmission limits may be designed such that, for a given distribution of traffic volumes from, for example, video packets having different priorities, the average number of potential retransmissions remains the same as for AC_VI_O. The distribution may be monitored and / or updated by the AP and / or the STA. For example, a state variable amountTraffic (AC_VI_i) may be maintained for each video traffic sub-class (e.g., importance level), for example, to maintain a record of the amount of traffic for that sub-class have. The variable amountTraffic (AC_VI_i) may also be updated as follows: amountTraffic (AC_VI_i)

a * amountTrqffic (AC_VI_i) + (1-a) * (the number of frames in AC_VI_i that arrived within the last time interval of duration T), where time may be partitioned into time intervals of duration T, a < 1 may be a constant weight.

The fraction of traffic belonging to AC_VI_i may be:

(1)

(One)

Where i = 1, 2, ..., n.

For example, for i = 1, 2, ..., n, dot11LongRetryLimit (AC_VI_i) = floor ((n-i + 1) L). L may be obtained, for example, by making its average equal to dot11LongRetryLimit (AC_VI_O).

(2)

(2)

This may provide the following approximate solution:

(3)

(3)

It may provide a value for dot11LongRetryLimit (AC_VI_i) according to dot11LongRetryLimit (AC_VI_i) = floor ((n-i + 1) L) for i = 1, 2, ...,

Similarly, the value of dot11ShortRetryLimit (AC_VI_i) may be determined as:

(4)

(4)

Where i = 1, 2, ..., n. The procedure may be implemented by the AP and / or the STA, for example, independently. Changing the values of these limits (e.g., dynamically changing) may not cause communication overhead, for example, because the limits may be derived to the transmitter.

The selection of retransmission limits may be based, for example, on the level of contention experienced by the 802.11 link. The contention may be detected in various ways. For example, the average contention window size may be a contention indicator. The Carrier Sense Multiple Aggregation (CSMA) result (e.g., whether the channel is free or not) may be a contention indicator. If rate adaptation is used, the average number of times the AP and / or the STA abandons transmission after reaching the retry limit may be used as a contention indicator.

A dynamic approach may be used to prioritize the transmission of packets in a video application (e.g., a real-time video application). In a dynamic approach, the importance of a video packet may be dynamically determined by the network, for example, after the video packet leaves the source and before the video packet arrives at its destination. The importance of a video packet may be based on what happened to past video packets in the network and / or what is expected to happen to future video packets in the network.

 Prioritization of packets may be dynamic. The prioritization of a packet may vary depending on what has happened to previous packets (e.g., the previous packet has been removed) and the failure to deliver this packet to future packets. For example, in the case of video call traffic, packet loss may result in error propagation.

For example, the media access control (MAC) layer may have two traffic directions. One traffic direction may be from the AP to the STA (e.g., downlink), and the other traffic direction may be from the STA to the AP (e.g., uplink). On the downlink, the AP may be the central point at which prioritization for different video call traffic flows to different STAs may be performed. The AP may compete for media access with STAs that transmit uplink traffic, for example due to the TDD nature of the WiFi channel and the CSMA type of media access. The STA may originate multiple video traffic flows, and one or more of the traffic flows may go uplink.

4 is a diagram illustrating an example system architecture 400 for an example dynamic video traffic prioritization approach to EDCA. The video quality information may be or may include parameters that may indicate a degradation in video quality if the packet is lost. In AC mapping, the video call traffic may include video quality information (e.g., from video quality information database 402) and / or MAC layer (e.g., EDCAF_VI_i modules, i = 1, 2, ...) for packets under consideration (e. g., dynamically) based on events that have occurred in a plurality of classes (e. g., as reported by. The event report may include an A-MPDU sequence control number and / or a result (e.g., success or failure) of the transmission of this A-MPDU.

Binary prioritization, three-level dynamic prioritization, and / or predicted video quality prioritization may be used. 5 is a diagram showing an example of binary prioritization. 6 is a diagram showing an example of non-discrimination. In binary prioritization, if multiple video call traffic flows traverse the AP, the AP may identify the flow that suffered packet losses and assign a lower priority to that flow. Dotted boxes 502 and 602 in Figs. 5 and 6 indicate the degree of error propagation.

Binary prioritization indicates that an AP (or STA) that uses binary prioritization may lower the priority of certain packets (e.g., by packet losses), while routers in video-aware queue management may drop packets It may not necessarily be the case). Video-aware queue management may be a network layer solution, which may be used in conjunction with binary prioritization at layer 2, for example as described herein.

Three-level dynamic prioritization may improve the QoE of real-time video without negatively impacting cross-traffic.

In some real-time video applications, such as video conferencing, an IPPP video encoding scheme may be used to meet delay constraints. In an IPPP video encoding scheme, a first frame of a video sequence may be intra-coded, and other frames may be encoded using a preceding (e.g., previous) frame as a reference for motion compensated prediction. When transmitted on the lossy channel, the packet loss may affect the corresponding frame and / or subsequent frames, e.g., errors may propagate. To handle packet losses, a macroblock (MB) infrastructure refresh may be used, e.g., some MBs of a frame may be intra-coded. This may, for example, mitigate error propagation at the expense of lower coding efficiency.

The video destination may feed back packet loss information to the video encoder to trigger insertion of an instantaneous decoder refresh (IDR) frame, which may be intra-coded, so subsequent frames may be free from error propagation. The packet loss information may be transmitted through an RTP control protocol (RTCP) packet. When the receiver detects a packet loss, the receiver may retransmit packet loss information, which may include the index of the frame to which the lost packet belongs. After receiving this information, the video encoder may determine whether the packet loss creates a new error propagation interval. If the index of the frame to which the lost packet belongs is less than the index of the last IDR frame, the video encoder may do nothing. Packet loss may occur over the existing error propagation interval, a new IDR frame may have already been generated, which may also stop error propagation. Otherwise, the packet loss may generate a new error propagation interval, and the video encoder may encode the current frame in intra mode to stop error propagation. The duration of the error propagation may vary depending on the feedback delay, which may be at least a round trip time (RTT) between the video encoder and the decoder. The error propagation may be mitigated using a recurring IDR frame insertion in which the frame may be intra-coded after all (e.g., fixed) numbers of P frames.

In an IEEE 802.11 MAC, a retransmission may be performed when a transmission is not successful, for example, until a retry limit or a retransmission limit is exceeded. The retry limit or retransmission limit may be the maximum number of transmission attempts for the packet. Packets that may not be transmitted after the maximum number of transmission attempts may be discarded by the MAC. The short retry limit or retransmission limit may be applied to packets with packet lengths less than or equal to the RTS / CTS (Request to Send / Clear to Send) threshold. A long retry limit or a retransmission limit may be applied to packets having a packet length exceeding the RTS / CTS threshold. The use of RTS / CTS may be disabled, and a short retry limit or retransmission limit may be used or indicated by R.

MAC layer optimization may improve video quality by providing differentiated services to video packets, e.g., by adjusting transmission retry limits, and may be compatible with other stations in the same network. The retry limit may be assigned based on the importance of the video packet. For example, a low retry limit may be assigned to less important video packets. More important video packets may get more transmission attempts.

The retry limit may be dynamically assigned to a video packet based on the type of video frame that the packet is delivering and / or the lost events that have occurred in the network. Some video packet prioritization may involve static packet differentiation. For example, video packet prioritization may vary depending on the video encoding scheme, e.g., cyclic IDR frame insertion and / or scalable video coding (SVC). The SVC may separate the video packets into substreams based on the layer to which they belong, or may advertise the priorities of each of the substreams to the network. The network may allocate more resources to sub-streams having higher priorities, e.g., in the case of network congestion or poor channel conditions. The SVC-based prioritization may be static, for example, it may not be considered as instantaneous network conditions.

The analytical model may also assess the impact of MAC layer optimization on the performance, e.g., video quality. Considering the transmission of the cross traffic, the compatibility condition may prevent the MAC layer optimization from adversely affecting the cross traffic. The simulations may show that the throughput of the cross traffic may remain substantially similar to the scenario where MAC layer optimization is not employed.

The retry limits may be the same for packets, e.g., for all packets. Fig. 7 shows an example of the PSNR of the function of the frame number. As illustrated in FIG. 7, due to loss of frame 5, subsequent P frames may be erroneous up to the next IDR frame, and video quality may remain low regardless of whether subsequent frames are successfully received . The transmission of these frames may be less important to video quality, and the retry limit may be lowered for those frames.

Video frames may be classified into a plurality of priority categories, e.g., three priority categories, and a retry limit R _i may be assigned to video frames having priority i (i = 1, 2, 3) , And priority 1 may be the highest priority and R ₁ > R ₂ = R> R ₃ . The frames after the IDR frame and the IDR frame may be allocated to the retry limit R ₁ until the frame is lost or compatibility criteria are not met. After generating the IDR frame, the decoded video sequence at the receiver may be as error-free as possible. If the network misses the frame after a short time in the IDR frame, the video quality may be dramatically reduced and may remain poor until a new IDR frame is created, which may take at least one RTT. The advantage of an IDR frame with rapid packet loss is that it may be limited to several video frames. IDR frames and frames following those IDR frames may be prioritized. If the MAC layer discards packets because the retry limit has been reached, subsequent frames may be assigned to a minimum retry limit R ₃ until a new IDR frame is created, although high retry limits may not improve video quality Because. Other frames may be assigned a retry limit R ₂ .

Compatibility criteria may be applied so that the performance of different access categories (ACs) are not adversely affected by configuring (e.g., optimizing) retry limits for video packets. The total number of transmission attempts of a video sequence may remain the same without constructing retry limits or with a configuration of such limits (e.g., optimization).

The average number of transmission attempts for video packets may be determined by monitoring the actual number of transmission attempts. The average number of transmission attempts for video packets may be estimated. For example, p may represent the probability of collision of a single transmission attempt at the MAC layer of the video transmitter. p may be a constant or may be independent of packets, regardless of the number of retransmissions. The station's transmit queue may not be empty. The probability p may be monitored at the MAC layer and used as an approximation of the collision probability, for example, when the IEEE 802.11 standard is used. The probability that the transmission will still fail after r attempts is p ^r . For a packet with a retry limit R, the average number of transmission attempts may be given by

(5)

(5)

Here, p ^i-1 (1 - p) may be the probability that the packet will be successfully transmitted after i attempts and p ^R in the second term of the left side of equation (5) It may still be a chance to fail. For convenience, we denote p ₀ = p ^R and p _i = p _Ri for i = 1, 2, 3, where p _i is the packet loss rate when the retry limit is R _i . P ₁ <p ₂ = p ₀ <p ₃ since R ₁ > R ₂ = R> R ₃ . M may be the total data size in the video sequence (e.g., in bytes) and M _i (i = 1, 2, 3) may be the total data size of video frames with retry limit R _i , where M = M ₁ + M ₂ + M ₃ . To meet compatibility criteria, the total number of transmission attempts may not increase after increasing packet retry limits, for example:

(6)

(6)

3-level dynamic prioritization may be performed. A frame may be assigned a priority level based on, for example, its type. The priority level may be assigned based on successful transmission or failure to transmit packets or packets, e.g., adjacent packets or packets. The priority level may be based in part on whether compatibility criteria are met. Figure 8 shows an example of three-level dynamic prioritization. The IDR frames 802 and 804 may be assigned priority 1. In the case of a subsequent frame, if its preceding frames are successfully transmitted, then the subsequent frame may be assigned priority 1 if the compatibility criterion is met. If a compatibility criterion is not met for a frame, the MAC may assign priority 2 to subsequent frames as well as to the frame until the packet is missed due to exceeding the retry limit. When a packet with priority 1 or 2 is missing, one or more subsequent frames may be assigned priority 3, for example up to the next IDR frame. The number of consecutive frames with priority 3 may be determined by the duration of the error propagation, which may be at least one RTT. Cumulative sizes M and M _i may be calculated from the beginning of the video sequence. When the video duration is large, the cumulative size may be updated, for example, for a specific time period or for a specific number of frames.

The cumulative packet sizes M and M _o may be initialized to values of zero. The priorities q and q ₀ of the current frame and the last frame may be initialized to values of 0, respectively. When a video frame having a size m arrives from a higher layer, the priority q of the video frame may be set to 1 if it is an IDR frame. Otherwise, if the priority q ₀ of the last frame is 3, the priority q of the current frame may be set to 3. If the current frame is not an IDR frame and the last frame has a priority q0 of 3, if the last frame is missing, the priority q of the current frame may be set to 3. If the current frame is not an IDR frame and the last frame is not missing, if the priority q ₀ of the last frame is 2, the priority q of the current frame may be set to 2. If the current frame is not an IDR frame and the last frame is not missed and the inequality (6) is satisfied when the priority q ₀ of the last frame is 1, the priority q of the current frame may be set to one. If neither of these conditions applies, the priority q of the current frame may be set to two. The priority q ₀ of the last frame may then be set to the priority q of the current frame. The cumulative packet sizes M and M _q may both be increased by the size m of the video frame. This process may be repeated until, for example, the video session ends.

A priority 2 may be assigned to a frame if priority 2 is assigned to the last frame or if inequality (6) is not satisfied. If inequality (6) is satisfied, no priority 2 is assigned to the frame, for example, priority 1 or 3 may be assigned to the frames.

Some video conferencing applications may present the most recent error free frames rather than presenting erroneous frames. The video destination may also lock the video during error propagation. The fixed time may be a metric for performance evaluation. For a constant frame rate, the fixed time may be a metric equivalent to the number of fixed frames due to packet losses.

IDR and non-IDR video frames may be respectively encoded to be d and d 'packets having the same size, where d>d'. When the IEEE 802.11 standard is used, N is the total number of frames encoded so far, and n may be the number of packets. Priority may be assigned to a frame, as disclosed herein. The number of packets with priority i may be denoted by ni. n and n ₁ + n ₂ + n ₃ may be different because there may be different numbers of IDR frames in these scenarios. N may be sufficiently large, and it may be assumed that n, n ₁ , n ₂ , n ₃ > 0. By assuming that the packets have the same size, the inequality (6) can be rewritten as:

(7)

(7)

Considering a constant frame rate, D may be the number of frames transmitted during the feedback delay. When a packet is lost at the time of transmission, the packet loss information may be received as a feedback delay at the video source after the packet is transmitted. A new IDR frame, which may be the D-th frame after the frame to which the lost packet may belong, may be generated, for example, immediately. D-1 fixed frames may be affected by error propagation. For example, if the feedback delay is short, at least there may be an error in the frame (s) to which the lost packet belongs. D &gt; = 1, and the interval including the D fixed frames may be a fixed interval.

The packet loss probability p0 may be small such that, at fixed intervals, there may be one packet loss (e.g., the first packet) when the IEEE 802.11 standard is used. The number of independent error propagations may be equal to the number of lost packets that may be p ₀ n in the n-packet video sequence. The expected total number of erroneous frames, e.g., fixed frames, may be given by

. (8)

. (8)

As disclosed herein, a fixed interval may begin with an erroneous frame with priority 1 or 2, which may follow D-1 frames with priority 3. The number of lost packets with priorities 1 and 2 may be p ₁ n ₁ and p ₂ n _2, respectively. The total number of fixed frames may be

. (9)

. (9)

Frames with priority 3 may appear at fixed intervals, and one or more frames (e.g., each frame) may be encoded with d 'packets. The expected total number of packets with priority 3 may be given by

. (10)

. (10)

If D = 1, one frame (e.g., the frame to which the lost packet belongs) may be transmitted at a fixed interval, and the next frame may be an IDR frame that may stop the fixed interval. Priority 3 may not be assigned to the frame, and n ₃ = 0.

n ' ₁ may be the number of packets belonging to IDR frames. Except for the first IDR frame, other IDR frames may appear after the end of fixed intervals, and IDR frames may be encoded with d packets. The total number of packets belonging to IDR frames may be given by

(11)

(11)

Using the IEEE 802.11 standard, a lost packet may trigger a new IDR frame. The first frame of the video sequence may be an IDR frame, so the expected total number of IDR frames is p ₀ n + 1. The expected total number of packets may be given as:

.

.

From the above equation, N can be obtained as follows

(12)

(12)

As disclosed herein, a lost packet with priority 1 or 2 may result in the creation of a new IDR frame. The expected total number of packets may be given as:

.

.

The total number of frames may be obtained from the above equation as &lt; RTI ID = 0.0 &gt;

(13)

(13)

The equation? D may be defined as? D = d - d '. (12) and (13)

. (14)

. (14)

Because p2 = p0,

. (15)

. (15)

The above inequality follows the fact that 1 - p ₁ Δd <1, and the equation is maintained when n ₃ = 0, eg, D = 1. Since p ₁ <p ₀ , 1 - p ₀ Δd <1 - p ₁ Δd. (15) &lt; / RTI &gt;

. (16)

. (16)

From the above inequality, n> n ₁ + n ₂ + n ₃ , eg, for the same video sequence, the number of packets when the IEEE 802.11 standard is used may be larger than when QoE based optimization is used have.

N _I and N ' _I may represent the number of IDR frames when the IEEE 802.11 standard and QoE based optimization are used, respectively. IDR frames and non-IDR frames may each be encoded with d and d 'packets, respectively, and the total number of packets when the IEEE 802.11 standard is used may be given by

.

.

When QoE-based optimization is used, the total number of packets may be

.

.

Since n> ₁ + n ₂ + n ₃ , from the above two equations, N _I > N ' _I. A fixed interval may trigger the generation of an IDR frame, and an IDR frame may appear immediately after a fixed interval, except for a first IDR frame, which may be the first frame of the video sequence. then,

.

.

The number of fixed frames when QoE based optimization is used may be smaller than when the IEEE 802.11 standard is used,

(17)

(17)

(14)

. (18)

. (18)

(P ₁ n ₁ + p ₂ n ₂ ) &gt; ₀ because the left side of equation (18) is larger than zero.

Considering compatibility criterion 7,

The second equation may be obtained by substituting (18). The inequality follows the fact that p ₀ n - (p ₁ n ₁ + p ₂ n ₂ )> 0, Δd ≥ 1, and n ₃ ≥ 0, and the equation is maintained when Δd = 1 and n ₃ ≥ 0.

When the video sequence is sufficiently large, compatibility criterion 7 may be satisfied. In one embodiment, a frame having priority 2 may not be generated after the beginning of the video sequence. Furthermore, since the left side of (3) is absolutely larger than the right side, the expected number of transmission attempts is reduced using the approach disclosed herein. Thus, transmission opportunities may be protected against cross traffic.

In one embodiment, except for the beginning of the video sequence, the frame may not be assigned priority 2. A frame having priority 1 may be followed by another frame having priority 1 when packets of that frame are successfully transmitted. According to the algorithm disclosed herein, the priority may not change within a frame. Even if a packet of a frame having priority 1 is missing, the remaining packets of the same frame may have the same priority, and the packets of the subsequent frame may be assigned priority 3. The fixed interval may include D-1 subsequent frames with priority 3, and one or more (e.g., each) of the frames may be encoded with d 'packets. The first (D-1) d '- 1 packets may be followed by another packet with probability 1 and priority 3, and the last packet may have a priority 1 packet that may belong to the next IDR frame Probability can be followed by 1. This process may be modeled by the discrete-time Markov chain 900 shown in FIG.

In FIG. 9, states 902, 904, 906, 908 may represent (D - 1) d 'packets with priority 3 at fixed intervals. The states in the first two rows 910 and 912 may represent d and d 'packets of an IDR frame and a non-IDR frame, respectively, with priority 1, where state (I, i) (N, j) may be for the jth packet of the non-IDR frame with priority one. After a fixed interval, d packets of the IDR frame with priority 1 may follow. If d packets are successfully transmitted, they may be followed by d 'packets of a non-IDR frame. Otherwise, they may be initialized at a new fixed interval. After transmission of the non-IDR frame, it may be followed by another non-IDR frame as long as the transmission does not fail. P _a and P _b may be the probabilities of successful transmissions of IDR frames and non-IDR frames with priority 1, respectively. The transmission of the IDR frame may be successful if, for example, d packets of the IDR frame are successfully transmitted. For a packet, the packet loss rate may be p ₁ , which has priority 1. therefore,

(19)

(19)

Non-IDR frames may have priority 1. The probability Pb may be given by

(20)

(20)

When D = 1, the frame may not be assigned priority 3, and states in the last row of FIG. 9 may not exist. If a frame is missed in the transmission, that frame may be followed by another IDR frame (e.g., immediately). The discrete time Markov chain may be the model illustrated in FIG. The following derivation may be based on the model shown in Fig. The derivation may be appropriate when D = 1. q _{I, i} , q _{N, j} and q _{3, k} may be the static distribution of the Markov chains for 1 ≤ i ≤ d, 1 <j ≤ d 'and 1 ≤ k ≤ have. q = _{I, 1} = q _{I, 2} = ... q = _{I, d} , q _{N, 1} = q _{N, 2} = ... q _{N, d} and q _3,1 = q _3,2 . .. = q _{3, (D-1) d '} . Furthermore,

(21)

(21)

(22)

(22)

(23)

(23)

From the above equations,

(24)

(24)

(25)

(25)

From the normalization condition

.

.

The following may also be obtained.

. (26)

. (26)

q ₃ may be the probability that a packet belongs to an IDR frame, which may be given by

In a video sequence comprising n ₁ + n ₂ + n ₃ packets, the expected number of packets that may belong to an IDR frame may be obtained by n ₁ = q ₁ (n ₁ + n ₂ + n ₃ ) . (11)

(27)

(27)

Here, the last inequality may depend on the fact that n ₁ + n ₂ + n ₃ <n. By Taylor's theorem, the probability P _a may be expressed as

Where 0? X? P _1? 1. therefore,

.

.

Similarly,

.

.

Applying the above range, the inequality 27 may be expressed as:

(28)

(28)

Here, the last inequality may be in accordance with the fact that p ₀ > p ₁ and N _f = Dp ₀ n. From the inequalities (17) and (28), the upper limit for N ' _f may be next

(29)

(29)

The expected fixation time may be reduced; The longer the fixed interval D, the greater the gain may be in comparison to the IEEE 802.11 standard. Figure 10 shows an example fixed frame comparison. The approach disclosed herein may concentrate packet losses into small segments of a video sequence to improve video quality.

11 illustrates an example network topology of a network 1100 that may include a video conferencing session with QoE based optimizations between devices 1102 and 1104 and other cross traffic. This cross traffic may include a voice session, an FTP session, and a video conferencing session without QoE-based optimization between the devices 1106 and 1108. Video transmissions may be unidirectional from device 1102 to device 1104 while video teleconferencing may be bidirectional between devices 1106 and 1108. [ The devices 1102 and 1106 may be in the same WLAN 1110 as the FTP client 1112 and the voice user device 1114. [ The access point 1116 communicates with the devices 1104 and 1108, the FTP server 11,18 and the voice user device 1120 via the Internet 1122 in one direction with a unidirectional delay of 100 ms It is possible. An H.264 video codec may be implemented for devices 1102 and 1104.

The retry limit R for packets may be set to 7, which is the default value in the IEEE 802.11 standard. Three levels of video priority may be assigned to video conferencing sessions using QoE based optimization. For example, the corresponding retry limits may be (R ₁ , R ₂ , R ₃ ) = (8, 7, 1). In a video transmitter, the packet may be discarded when the retry limit of the packet is exceeded. The video receiver may detect packet loss when it receives subsequent packets or when it does not receive any packets for the time period. The video receiver may transmit the packet loss information to the video transmitter via, for example, RTCP, and an IDR frame may be generated after the RTCP feedback is received by the video transmitter. The video receiver may present a fixed video until the next IDR frame is received from the time of the lost frame.

A Foreman video sequence may be transmitted from the device 1102 to the device 1104. The frame rate may be 30 frames / second, and the video duration may be 10 seconds including 295 frames. Cross traffic may be generated by OPNET 17.1. For a video session from device 1106 to device 1108, the frame rate may be 30 frames per second, and the outgoing and incoming stream frame sizes may be 8500 bytes. For a TCP session between the FTP client and the server, the receive buffer may be set to 8760 bytes. The numerical results may be averaged over 100 seeds, and for each seed, the data may be collected from a foreman sequence of a 10 second duration.

The WLAN 1124 may increase the error probability p. The WLAN 1124 may include an AP 1126 and two operations 1128 and 1130. The IEEE 802.11n WLANs 1110 and 1124 may operate on the same channel. The data rates may be 13 Mbps and the transmit powers may be 5 mW. Buffer sizes in APs may be 1 Mbit. The number of spatial streams may be set to one. APs and stations' distances may be set to acknowledge the problem of hidden nodes. In the simulations, the distance between two APs 1116 and 1126 may be set to 300 meters, and the distance between the device 1102 and the AP 1116 and between the AP 1126 and the device 1128 may be 350 meters have. A video conference session may be initiated via the AP 1126 between the devices 1128 and 1130. The frame rate may be 30 frames per second and the stream frame sizes of both incoming and outgoing may be used to adjust the packet loss rate of the video conferencing session using QoE based optimization operating on the device 1102. [

To simulate dynamic IDR frame insertion triggered by receipt of packet loss feedback conveyed by RTCP packets in OPNET, it is assumed that F _n with n = 0,1,2, ... is a video sequence beginning with frame n , Frame n may be an IDR frame, and subsequent frames may be P-frames to the end of the video sequence. Beginning with the transmission of the video sequence F0, RTCP feedback may be received when frame i - 1 is transmitted. After the transmission of the current frame, may result in the IDR frames inserted in the frame i and frame _i of F i and a subsequent frame may be used to feed the video transmitter in simulation OPNET video sequence in F _i may be used. 12 shows an example video sequence 1200 in which RTCP feedback may be received when frames 9 and 24 are transmitted. In OPNET simulations, the sizes of the packets may be of interest. The video sequences F _n that can be n = 0, 1, 2, ... may be encoded, which may be a one-time effort. The sizes of the packets of the video sequences may be stored. When an RTCP feedback is received, an appropriate video sequence may be used.

13 shows simulated collision probabilities p of the example for 100 seeds when the IEEE 802.11 standard and QoE based optimization are used, as shown at 1302 and 1304, respectively. The average collision probabilities may be 0.35 and 0.34 for IEEE 802.11 standard and QoE based optimization, respectively. The mean absolute error may be 0.017 and the relative absolute error may be 4.9%. Simulation results may confirm that it may be appropriate to use the collision probability when QoE-based optimization is applied as an approximation of the collision probability when the IEEE 802.11 standard is applied.

Figure 14 shows simulated percentages of examples of fixed frames using the IEEE 802.11 standard and QoE based optimization. For different application layer load configurations, the cross traffic between the devices 1128 and 1130 may be tuned to obtain different packet loss rates when the IEEE 802.11 standard is used. The exemplary packet loss rates may be 0.0023, 0.0037, 0.0044, 0.0052, and 0.0058 for Configurations 1 through 5, respectively. The simulations may be performed using QoE-based optimization with the same cross-traffic configuration. Figure 14 also illustrates the upper bound for QoE based optimization in equation (29), where the parameters D, d, d 'and p ₀ may be averaged from the simulation results. The average percentage of fixed frames of the QoE based optimization may be less than the upper limit. As the packet loss rate decreases, the average percentage of fixed frames may increase regardless of whether QoE-based optimization is used and the performance of the QoE-based optimization remains better than that of the corresponding value of the baseline method (E.g., there is no change to the IEEE 802.11 standard).

Figure 15 shows simulated average percentages of examples of fixed frames for different RTTs between a video transmitter and a receiver when application layer load configuration 3 is applied. The feedback delay may be at least one RTT between the video transmitter and the receiver. As the feedback delay increases, the duration of the fixed intervals may increase. More frames may be affected by packet losses. The percentage of fixed frames may increase as RTT increases. From the upper limit in equation (29), the gain of QoE-based optimization compared to the IEEE 802.11 standard may increase when a larger RTT is applied. This may be confirmed by the numerical results in Fig. When the RTT is 100 ms, the average percentage of fixed frames using QoE-based optimization may be 24.5% less than using the IEEE 802.11 standard. When the RTT is 400 ms, the gain may increase to 32.6%. The average percentages of fixed frames using QoE based optimization may be less than the upper limit in equation (29).

Tables 2 and 4 show the average throughputs of the examples for the cross traffic in WLAN 1 using the IEEE 802.11 standard and QoE based optimization when application layer load configurations 2 and 5 are applied, respectively. In addition, the standard deviations for these two scenarios are listed in Tables 3 and 5, respectively. The throughput results for QoE-based optimization may be substantially similar to the IEEE 802.11 standard.

Table 2: Average throughputs for cross-traffic in application layer load configuration 2

Table 3: Standard deviations for cross-traffic in application layer load configuration 2

Table 4: Average throughputs for cross traffic in application layer load configuration 5

Table 5: Standard Deviation for Cross-Traffic in Application Layer Load Configuration 5

The expected composition (e.g., optimization) of the video quality may be used. In configuring (e.g., optimizing) the expected video quality, the AP (or STA) may make decisions about QoS processing for each packet based on expected video quality. The AP may obtain video quality information for video packets, e.g., from a video quality information database. The AP may examine events that occur for the video session to which the video packet belongs. The AP may determine how to process packets that are still waiting for transmission to configure (e.g., optimize) the expected video quality.

In a WiFi network, packet losses may be random or may not be fully controlled by the network. Probability measurement results for packet loss patterns may be provided. The probability measurement result may be constructed from the probability of failing to deliver packets from the video traffic AC (AC_VI_i), i = 1, 2, ..., n, which may be locally measured and updated by the STA.

The AP and / or STA may perform any of the following. The AP and / or the STA may update the probability of failing to deliver the packet from the traffic class AC_VI_i. The AP and / or STA may indicate the probability as Pi, i = 1, ..., n, for example, when the fate of a packet transmission attempt is known. The AP and / or the STA may assign packets waiting for transmission to access categories AC_VI_i, i = 1, ..., n, for example, when a packet arrives. The AP and / or STA may evaluate the expected video quality. The AP and / or STA may also select a packet assignment corresponding to the optimal expected video quality.

One or more criteria may be applied to achieve some global characteristics of the video call traffic. For example, the criteria may be a threshold for the sizes of the cues corresponding to the access categories AC_VI_i, i = 1, ..., n. A criterion may be selected to balance the queue sizes of one or more access categories AC_VI_i, i = 1, ..., n.

One or more methods may be used to assign packets to different access categories AC_VI_i, i = 1, ..., n. 16 is a diagram illustrating an example of a reallocation method in which packets may be reassigned to ACs upon arrival of a packet. The "X" on packets 1602 and 1604 in FIG. 16 may illustrate that the corresponding packet was not successfully delivered over the channel. In the example method shown in FIG. 16, packets waiting for transmission may be subject to packet reassignment. The packet assignment may also determine the probability that the delivery of the packet will fail. If the packet loss events are assumed to be independent, the probability and / or video quality corresponding to each possible packet loss pattern may be calculated. The average of the packet loss patterns may provide the expected video quality.

17 is a diagram illustrating an example of a reallocation method in which the latest packets may be allocated to ACs upon arrival of a packet. In the example method of FIG. 17, when a new packet 1702 arrives, the assignment of the packet may be considered without changing, for example, the assignment of other packets waiting for transmission. The method of FIG. 17 may reduce computation overhead, for example, compared to the method of FIG.

When the STA and / or the AP support multiple video call traffic flows, the overall video quality of these flows may be configured (e.g., optimized). The STA and / or AP may track which video call flow the packet belongs to. The STA and / or the AP may find a video packet assignment that provides optimal overall video quality.

Enhancements to DCF may be provided. The DCF may refer to the use of the DCF alone or in conjunction with other components and / or functions. In the case of DCF, there may be no differentiation of data traffic. However, similar ideas disclosed herein in the context of EDCA may be applied to DCF (e.g., DCF-only MAC).

Video traffic (e.g., real-time video traffic) may be prioritized according to, for example, a static approach and / or a dynamic approach.

18 is a diagram illustrating an example system architecture 1800 for an example static video traffic differentiation approach to DCF. Traffic may be separated into two or more categories, such as, for example, real-time video traffic 1802 and other types of traffic 1804 (e.g., shown as OTHER). Within the real-time video traffic category 1802, the traffic may be further differentiated into sub-classes (e.g., importance levels) depending on the relative importance of the video packets. For example, referring to FIG. 18, n sub-classes VI_1, VI_2, ..., VI_n may be provided.

The contention window may be defined based on the importance level. The range of CW, which may be [CWmin, CWmax], may be partitioned into smaller intervals, for example, for compatibility. CW may be varied to an interval [CWmin, CWmax]. The back off timer may be set at random from the interval [0, CW].

For real-time video traffic subclasses VI_1, VI_2, ..., VI_n, the video traffic conveyed by VI_i may be considered more important than that conveyed by V_i for i <j. The interval [CWmin, CWmax] may be partitioned into n intervals, which may or may not have the same lengths. If the intervals have equal lengths, for VI_i, its CW (VI_i) may vary at the following intervals:

[ceiling (CWmin + (i-1) * d), floor (CWmin + i * d)]

Where ceiling () may be a ceiling function, floor () may be a floor function, and d = (CWmax-CWmin) / n.

The distribution of the contention window for the entire video traffic may remain the same.

If the amount of traffic of different types of real-time video traffic types is not the same, the interval [CWmin, CWmax] may not be equally partitioned so that small intervals resulting from, for example, (E.g., in inverse proportion) to the quantities. The traffic volumes may be monitored and / or estimated by the STA and / or the AP. For example, if the traffic for a particular class is higher, the contention window interval may be smaller. For example, if a subclass (e.g., importance level) has more traffic, the CW interval for that sub-class may be increased, for example, so that the contention may be handled more efficiently.

Retransmission limits may be defined based on a priority level (e.g., a subclass). There may be no differentiation of the attributes (dot11LongRetryLimit and dot11ShortRetryLimit) according to the traffic classes. The concepts disclosed herein for EDCA may be applied to DCF.

FIG. 19 is a diagram illustrating an example system architecture 1900 for an example dynamic video traffic differentiation approach to DCF. The concepts disclosed herein in the context of dynamic video traffic differentiation for EDCA may be applied to DCF. The concepts may be modified by replacing label AC_VI_i with label VI_i for i = 1, 2, ..., n.

HCCA enhancements may be defined based on a priority level (e.g., sub-class). The HCCA may be a centralized approach to media access (e.g., resource allocation). The HCCA may be similar to the resource allocation in the cellular system. As in the case of EDCA, prioritization of real-time video traffic in the case of HCCA may take more than one approach, for example a static approach and / or a dynamic approach.

In a static approach, design parameters for EDCA may not be used. The manner in which the importance of video packets is displayed may be the same as that disclosed herein in the context of EDCA. The importance information may be passed to the AP, which may schedule the transmission of video packets.

In HCCA, the scheduling may be performed on a per-flow basis, for example, where QoS estimates may be performed in the traffic specification (TSPEC) field of the management frame. The importance information in the TSPEC may be the result of the negotiation between the AP and the STA. In order to differentiate within the traffic flow, information about the importance of individual packets may be used. The AP may also transfer video quality / importance information from the network layer to the MAC layer and / or apply a packet mapping scheme.

In a static approach, an AP may consider the importance of individual packets. In the dynamic approach, the AP may consider what happened to previous packets of the flow to which the packet under consideration belongs.

PHY enhancements may be provided. The modulation and coding set (MCS) selection for multiple input / multiple output (MIMO) may be selected (e.g., adapted) for the purpose of configuring (e.g., optimizing) QoE of real time video, for example. Adaptation may occur at the PHY layer. The decision as to what MCS may be used may be made at the MAC layer. The MAC enhancements described herein may be extended to include PHY enhancements. For example, in the case of EDCA, the AC mapping function may be extended to configure (e.g., optimize) the MCS for the video call traffic. A static approach and a dynamic approach may be used.

In the case of HCCA, the scheduler at the AP may determine what packets will access the channel and what MCS may be used to send the packet in question, e.g., video quality is configured (e.g., optimized).

The MCS selection may include selection of modulation type, coding rate, MIMO configuration (e.g., spatial multiplexing or diversity), and the like. For example, if the STA has a very weak link, the AP may choose a low order modulation scheme, a low coding rate, and / or a diversity MIMO mode.

Video importance / quality information may be provided. The video importance / quality information may also be provided by a video transmitter. The video importance / quality information may be placed in an IP packet header such that routers (e.g., the AP serving similar functions for traffic going to STAs) may access the information. The DSCP field and / or the IP packet extension field may be used, for example, for IPv4.

The first six bits of the traffic class field may serve as a DSCP indicator for IPv6, for example. An extension header may be defined, for example, to convey video importance / quality information for IPv6.

Packet mapping and encryption handling may also be provided. Packet mapping may also be performed using a table lookup. The STA and / or the AP may construct a table for mapping IP packets and A-MPDUs.

20A is a diagram of an example communication system 2000 in which one or more of the disclosed embodiments may be implemented. The communication system 2000 may be a multiple access system that provides content to a plurality of wireless users, such as voice, data, video, messaging, broadcast, and the like. The communication system 2000 may enable a plurality of wireless users to access such content through the sharing of system resources including wireless bandwidth. For example, communication system 2000 may include one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division (FDMA), an orthogonal FDMA (OFDMA), a single carrier FDMA (SC-FDMA), or the like.

As shown in FIG. 20A, the communication system 2000 includes wireless transmit / receive units (WTRUs) 2002a, 2002b, 2002c, and / or 2002d (which may be referred to collectively or collectively as a WTRU 2002) (RAN) (2003/2004/2005), core network (2006/2007/2009), public switched telephone network (PSTN) 2008, Internet 2010, The Internet 2010, and other networks 2012, it will be understood that the disclosed embodiments are contemplated by any number of WTRUs, base stations, networks, and / or network elements . Each of the WTRUs 2002a, 2002b, 2002c, 2002d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, WTRUs 2002a, 2002b, 2002c, 2002d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, Personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, consumer electronics devices, and the like.

The communication system 2000 may also include a base station 2014a and a base station 2014b. Each of the base stations 2014a and 2014b may be coupled to one or more communication networks such as WTRUs 2014a and 2014b to facilitate access to the core network (2006/2007/2009), the Internet 2010, and / (2002a, 2002b, 2002c, 2002d). &Lt; / RTI &gt; By way of example, base stations 2014a and 2014b may be a base transceiver station (BTS), a Node-B, an eNode B, a home Node B, a home eNode B, a site controller, an access point (AP) . Although base stations 2014a and 2014b are each depicted as a single element, base stations 2014a and 2014b may include any number of interconnected base stations and / or network elements.

Base station 2014a may be part of a RAN (2003/2004/2005), which may include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller a radio network controller (RNC), relay nodes, and the like. Base station 2014a and / or base station 2014b may be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cell may be further subdivided into cell sectors. For example, a cell associated with base station 2014a may be divided into three sectors. Thus, in one embodiment, base station 2014a may include three transceivers, one for each sector of the cell, for example. In another embodiment, base station 2014a may employ multiple-input multiple output (MIMO) techniques and may therefore use multiple transceivers for each sector of the cell.

The base stations 2014a and 2014b may communicate with one or more of the WTRUs 2002a, 2002b, 2002c, 2002d via an air interface 2015/2016/2017, which may be any suitable wireless communication link , Radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 2015/2016/2017 may be established using any suitable radio access technology (RAT).

More specifically, as mentioned above, communication system 2000 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 2014a and the WTRUs 2002a, 2002b, 2002c, 2002d in the RAN (2003/2004/2005) are capable of receiving Universal Mobile Telecommunications System (UMTS) terrestrial radio access , UTRA), which may establish air interface 2015/2016/2017 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA +). The HSPA may include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).

In another embodiment, base station 2014a and WTRUs 2002a, 2002b, 2002c, 2002d may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA) May establish the air interface 2015/2016/2017 using LTE (Long Term Evolution) and / or LTE-A (LTE-Advanced).

In other embodiments, the base station 2014a and the WTRUs 2002a, 2002b, 2002c, 2002d may be configured to support IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access), CDMA2000, CDMA2000 IX, CDMA2000 EV- (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution May implement the same radio technologies.

The base station 2014b in FIG. 20A may be, for example, a wireless router, a home node B, a home eNode B, or an access point and may facilitate wireless connections in a localized area, such as a business premises, home, vehicle, campus, Any suitable RAT may be used to do so. In one embodiment, base station 2014b and WTRUs 2002c and 2002d may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 2014b and WTRUs 2002c and 2002d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, base station 2014b and WTRUs 2002c and 2002d may use a cellular based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell . As shown in FIG. 20A, the base station 2014b may have a direct connection to the Internet 2010. Thus, base station 2014b may not need to access the Internet 2010 through the core network 2005/2006/2007.

The RAN (2003/2004/2005) may also communicate with the core network (2006/2007/2009), which may be used by voice, data, applications, and / or voice over internet protocol (VoIP) 2002a, 2002b, 2002c, 2002d). &Lt; / RTI &gt; For example, the core network (2006/2007/2009) provides call control, billing services, mobile location based services, prepaid phones, Internet connectivity, video distribution, and / or high- For example, user authentication may be performed. Although not shown in FIG. 20A, the RAN (2003/2004/2005) and / or the core network (2006/2007/2009) have the same RAT as the RAN (2003/2004/2005) or other RANs employing different RATs It will be appreciated that direct or indirect communication may also be employed. For example, in addition to being connected to the RAN (2003/2004/2005), which may be using E-UTRA radio technology, the core network (2006/2007/2009) may be connected to other RANs ). &Lt; / RTI &gt;

The core network 2006/2007/2009 also serves as a gateway to the WTRUs 2002a, 2002b, 2002c, 2002d for accessing the PSTN 2008, the Internet 2010, and / or other networks 2012 . The PSTN 2008 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 2010 may include common communication protocols such as transmission control protocol (TCP), user datagram protocol (UDP), and internet protocol (IP) in the TCP / Lt; RTI ID = 0.0 &gt; interconnected &lt; / RTI &gt; Networks 2012 may include wired or wireless communication networks owned and / or operated by other service providers. For example, networks 2012 may include other core networks connected to one or more RANs, which may employ the same RAT as a RAN (2003/2004/2005) or a different RAT have.

Some or all of the WTRUs 2002a, 2002b, 2002c, 2002d in the communication system 2000 may have multi-mode capabilities, e.g., the WTRUs 2002a, 2002b, 2002c, Lt; RTI ID = 0.0 &gt; transceivers &lt; / RTI &gt; to communicate with different wireless networks. For example, the WTRU 2002c shown in FIG. 20A may be configured to communicate with a base station 2014a that may employ cellular based radio technology and a base station 2014b that may employ IEEE 802 radio technology.

FIG. 20B is a system diagram of an example WTRU 2002. FIG. 20B, the WTRU 2002 includes a processor 2018, a transceiver 2020, a transceiver element 2022, a speaker / microphone 2024, a keypad 2026, a display / touchpad 2028, A removable memory 2030, a removable memory 2032, a power source 2034, a global positioning system (GPS) chipset 2036, and other peripherals 2038. It will be appreciated that the WTRU 2002 may include any subset combination of the elements described above, but still remain consistent with one embodiment. Embodiments may also include a base transceiver station (BTS), a node-B, a site controller, an access point (AP), a home node-B, an evolved home node Nodes that base stations 2014a and 2014b may uniquely represent, such as -B (eNodeB), home evolved Node-B (HeNB), home evolved Node-B gateway, and proxy nodes, And may include some or all of the elements described herein.

The processor 2018 may be a general purpose processor, a special purpose processor, an existing processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, Field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), state machine, and the like. The processor 2018 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 2002 to operate in a wireless environment. The processor 2018 may be coupled to the transceiver 2020, which may be coupled to the transceiving element 2022. It should be appreciated that although Figure 20b depicts processor 2018 and transceiver 2020 as separate components, processor 2018 and transceiver 2020 may be integrated together in an electronic package or chip. A processor, such as processor 2018, may include an integrated memory (e.g., WTRU 2002 may include a processor with a processor and associated memory). The memory may refer to memory associated with a processor (e.g., processor 2018) or memory associated with a device (e.g., WTRU 2002) otherwise. The memory may be non-transient. The memory may include (e.g., store) instructions (e.g., software and / or firmware instructions) that may be executed by the processor. For example, memory, when executed, may include instructions that cause the processor to implement one or more of the implementations described herein.

The transceiving element 2022 may be configured to transmit signals to, or receive signals from, the base station (e.g., base station 2014a) via the air interface 2015/1116/2017. For example, in one embodiment, the transmit / receive element 2022 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 2022 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In another embodiment, the transmit / receive element 2022 may be configured to transmit and receive both an RF signal and an optical signal. It will be appreciated that the transmit / receive element 2022 may be configured to transmit and / or receive any combination of wireless signals.

In addition, although the transmit / receive element 2022 is depicted as a single element in Figure 20B, the WTRU 2002 may include any number of transmit / receive elements 1122. [ More specifically, the WTRU 2002 may employ MIMO technology. Thus, in one embodiment, the WTRU 2002 includes two or more transmit and receive elements 1122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 2015/2016/2017 You may.

The transceiver 2020 may be configured to modulate signals to be transmitted by the transmit / receive element 2022 and to demodulate signals received by the transmit / receive element 2022. As noted above, the WTRU 2002 may have multi-mode capabilities. Thus, the transceiver 2020 may include multiple transceivers that enable the WTRU 2002 to communicate over multiple RATs, such as, for example, UTRA and IEEE 802.11.

The processor 2018 of the WTRU 2002 includes a speaker / microphone 2024, a keypad 2026 and / or a display / touchpad 2028 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode Unit) and may receive user input data from them. Processor 2018 may also output user data to speaker / microphone 2024, keypad 2026, and / or display / touchpad 2028. In addition, the processor 2018 may access information from any type of suitable memory, such as non-removable memory 2030 and / or removable memory 2032, and store the data in its memory. The non-removable memory 2030 may include random-access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. Removable memory 2032 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 2018 may access information from a memory that is not physically located on the WTRU 2002, such as a server or a home computer (not shown), and may store the data in its memory.

The processor 2018 may receive power from a power source 2034 and may be configured to distribute power and / or control those components to other components in the WTRU 2002. The power source 2034 may be any suitable device that powers the WTRU 2002. For example, the power source 2034 may include one or more battery cells (e.g., NiCd, NiZn, NiMH, Li-ion, etc.) Solar cells, fuel cells, and the like.

The processor 2018 may also be coupled to a GPS chipset 2036 that may be configured to provide location information (e.g., longitude and latitude) for the current location of the WTRU 2002. In addition to, or instead of, information from the GPS chipset 2036, the WTRU 2002 receives location information from the base station (e.g., base stations 2014a, 2014b) via the air interface 2015/2016/2017 And / or may determine its location based on the timing of signals being received from two or more neighboring base stations. It will be appreciated that the WTRU 2002 may maintain location information consistent with one embodiment while obtaining location information by any suitable location-determining method.

The processor 2018 may be further coupled to other peripherals 2038 which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity . For example, the peripherals 2038 may be an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for pictures or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, , A Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

20C is a system diagram of a RAN 2003 and a core network 2006 according to an embodiment. As mentioned above, RAN 2003 may employ UTRA radio technology to communicate with WTRUs 2002a, 2002b, 2002c via air interface 2015. [ The RAN 2003 may also communicate with the core network 2006. 20C, RAN 2003 includes eNode-Bs 2040a, 2040b, and 2040c, which may each include one or more transceivers that communicate with WTRUs 2002a, 2002b, 2002c via air interface 2015 , 2040c. Each of the Node-Bs 2040a, 2040b, and 2040c may be associated with a specific cell (not shown) in the RAN 2003. [ RAN 2003 may also include RNCs 2042a and 2042b. It will be appreciated that the RAN 2003 may also include any number of Node-Bs and RNCs while maintaining consistent with one embodiment.

As shown in FIG. 20C, the Node-Bs 2040a and 2040b may communicate with the RNC 2042a. In addition, the Node-B 2040c may be in communication with the RNC 2042b. The Node-Bs 2040a, 2040b, and 2040c may communicate with the respective RNCs 2042a and 2042b through the Iub interface. The RNCs 2042a and 2042b may communicate with each other via the Iur interface. Each of the RNCs 2042a and 2042b may be configured to control each Node-B 2040a, 2040b, and 2040c to which it is connected. In addition, each of the RNCs 2042a and 2042b may be configured to perform other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, Or may be configured to perform or support functions.

The core network 2006 shown in Figure 20C includes a media gateway (MGW) 2044, a mobile switching center (MSC) 2046, a serving GPRS support node (SGSN) 2048, and / or a gateway GPRS support node (GGSN) (2050). It will be appreciated that while each of the elements described above is depicted as part of the core network 2006, any of these elements may be owned and / or operated by entities other than the core network operator.

The RNC 2042a in the RAN 2003 may be connected to the MSC 2046 in the core network 2006 via the IuCS interface. The MSC 2046 may be connected to the MGW 2044. The MSC 2046 and the MGW 2044 communicate access to the circuit switched networks, such as the PSTN 2008, to the WTRUs 2002a, 2002b, and 2002c to facilitate communications between the conventional landline communication devices and the WTRUs 2002a, (2002a, 2002b, 2002c).

The RNC 2042a in the RAN 2003 may also be connected to the SGSN 2048 in the core network 2006 via the IuPS interface. The SGSN 2048 may be connected to the GGSN 2050. The SGSN 2048 and the GGSN 2050 communicate access to packet-switched networks, such as the Internet 2010, to the WTRUs 2002a, 2002b, 2002c to facilitate communications between the WTRUs 2002a, 2002a, 2002b, 2002c).

As mentioned above, the core network 2006 may also be connected to networks 2012, which may include other wired or wireless networks owned and / or operated by other service providers .

20D is a system diagram of a RAN 2004 and a core network 2007 according to an embodiment. As noted above, RAN 2004 may employ E-UTRA radio technology to communicate with WTRUs 2002a, 2002b, 2002c via air interface 2016. [ The RAN 2004 may also communicate with the core network 2007.

It will be appreciated that although RAN 2004 may include eNode-Bs 2060a, 2060b, and 2060c, RAN 2004 may contain any number of eNode-Bs, but may remain consistent with one embodiment . The eNode-Bs 2060a, 2060b, and 2060c may each include one or more transceivers that communicate with the WTRUs 2002a, 2002b, and 2002c through the air interface 2016. In one embodiment, eNode-Bs 2060a, 2060b, and 2060c may implement MIMO technology. Thus, eNode-B 2060a may use multiple antennas, for example, to transmit wireless signals to and receive wireless signals from the WTRU 2002a.

Each of the eNode-Bs 2060a, 2060b, 2060c may be associated with a particular cell (not shown) and may include radio resource management decisions, hander's decisions, scheduling of users on the uplink and / And may be configured to handle. As shown in FIG. 20D, the eNode-Bs 2060a, 2060b, and 2060c may communicate with each other via the X2 interface.

The core network 2007 shown in Figure 20d may include a mobility management gateway (MME) 2062, a serving gateway 2064, and a packet data network (PDN) gateway 2066 have. It will be appreciated that although each of the elements described above is depicted as part of the core network 2007, any of these elements may be owned and / or operated by entities other than the core network operator.

The MME 2062 may be connected to each of the eNode-Bs 2060a, 2060b, and 2060c in the RAN 2004 through the S1 interface and may serve as a control node. For example, MME 2062 may be configured to authenticate users of WTRUs 2002a, 2002b, 2002c, enable / disable bearers, select a particular serving gateway during the initial attach of WTRUs 2002a, 2002b, And so on. MME 2062 may also provide a control plane function for switching between RAN 2004 and other radio technologies, such as GSM or other RANs employing WCDMA (not shown).

The serving gateway 2064 may be connected to each of the eNode Bs 2060a, 2060b, and 2060c in the RAN 2004 through the S1 interface. Serving gateway 2064 may routinely route and forward user data packets to / from WTRUs 2002a, 2002b, and 2002c. Serving gateway 2064 may be used for other functions, such as anchoring of user planes during inter-eNode B handovers, of paging when downlink data is available to WTRUs 2002a, 2002b, 2002c Triggering, management and storage of the contexts of the WTRUs 2002a, 2002b, 2002c, and so on.

The serving gateway 2064 may also be connected to a PDN gateway 2066 that is configured to facilitate communications between the WTRUs 2002a, 2002b, 2002c and IP-enabled devices , And may provide access to packet switched networks, such as the Internet 2010, to WTRUs 2002a, 2002b, and 2002c.

The core network 2007 may facilitate communications with other networks. For example, the core network 2007 may provide access to circuit-switched networks, such as the PSTN 2008, to the WTRUs 2002a, 2002b, 2002c in order to facilitate communications between the WTRUs 2002a, 2002b, (2002a, 2002b, 2002c). For example, the core network 2007 may include an IP gateway (e.g., an IP multimedia subsystem (IMS) server) serving as an interface between the core network 2007 and the PSTN 2008, It may also communicate with the gateway. In addition, the core network 2007 may provide access to the networks 2012 to the WTRUs 2002a, 2002b, 2002c, which may be other wired and / or wireless networks owned and / or operated by other service providers Or wireless networks.

20E is a system diagram of a RAN 2005 and a core network 2009 according to an embodiment. RAN 2005 may be an access service network (ASN) employing IEEE 802.16 radio technology to communicate with WTRUs 2002a, 2002b, 2002c via air interface 2017. [ As will be discussed further below, the communication links between the different functional entities of the WTRUs 2002a, 2002b, 2002c, RAN 2005, and the core network 2009 may be defined as reference points.

As shown in Figure 20E, RAN 2005 may include base stations 2080a, 2080b, 2080c and ASN 2082, but RAN 2005 may include any number of base stations and ASN gateways But may remain consistent with one embodiment. Each of base stations 2080a, 2080b and 2080c may be associated with a particular cell (not shown) in RAN 2005 and each of which may communicate with WTRUs 2002a, 2002b, and 2002c via air interface 2017 One or more transceivers. In one embodiment, the base stations 2080a, 2080b, 2080c may implement MIMO technology. Thus, the base station 2080a may use a plurality of antennas, for example, to transmit wireless signals to and receive wireless signals from the WTRU 2002a. The base stations 2080a, 2080b, and 2080c may also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. ASN gateway 2082 may act as a traffic aggregation point and may be responsible for paging, caching subscriber profiles, routing to core network 2009, and so on.

The air interface 2017 between the WTRUs 2002a, 2002b, 2002c and the RAN 2005 may be defined as an R1 reference point implementing the IEEE 802.16 standard. In addition, each of the WTRUs 2002a, 2002b, 2002c may establish a logical interface (not shown) with the core network 2009. The logical interface between the WTRUs 2002a, 2002b, 2002c and the core network 2009 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / have.

The communication link between each of the base stations 2080a, 2080b, 2080c may be defined as an R8 reference point including protocols that facilitate WTRU handovers and data transfer between base stations. The communication link between the base stations 2080a, 2080b, 2080c and the ASN gateway 2082 may be defined as an R6 reference point. The R6 reference point may include protocols that facilitate mobility management based on mobility events associated with each of the WTRUs 2002a, 2002b, 2002c.

As shown in Fig. 20E, the RAN 2005 may be connected to the core network 2009. Fig. The communication link between the RAN 2005 and the core network 2009 may be defined as an R3 reference point including, for example, protocols facilitating data transfer and mobility management capabilities. The core network 2009 may include a Mobile IP Home Agent (MIP-HA) 2084, an authentication, authorization, authorization, accounting (AAA) server 2086, and a gateway 2088. It will be appreciated that although each of the elements described above is depicted as part of the core network 2009, any of these elements may be owned and / or operated by entities other than the core network operator.

The MIP-HA may be responsible for IP address management and may enable the WTRUs 2002a, 2002b, 2002c to roam between different ASNs and / or different core networks. The MIP-HA 2048 provides access to packet-switched networks, such as the Internet 2010, to the WTRUs 2002a, 2002b, 2002c to facilitate communications between the WTRUs 2002a, 2002b, , 2002c). AAA server 2086 may be responsible for user authentication and supporting user services. The gateway 2088 may facilitate interworking with other networks. For example, the gateway 2088 may provide access to circuit-switched networks, such as the PSTN 2008, to WTRUs 2002 to facilitate communications between the WTRUs 2002a, 2002b, 2002c and traditional landline communication devices 2002a, 2002b, 2002c). In addition, gateway 2088 may provide access to networks 2012 to WTRUs 2002a, 2002b, 2002c, which may be other wired or wireless networks owned and / or operated by other service providers Wireless networks.

It is to be appreciated that although not shown in FIG. 20E, the RAN 2005 may be connected to other ASNs and the core network 2009 may be connected to other core networks. The communication link between the RAN 2005 and other ASNs may be defined as an R4 reference point which is a protocol for coordinating the mobility of the RAN 2005 and the WTRUs 2002a, 2002b, 2002c between other ASNs . The communication link between the core network 2009 and other core networks may be defined as an R5 reference point, which may include protocols that facilitate interworking between home core networks and visited core networks .

The processing and means described herein may be applied in any combination, applied to other wireless technologies, or for other services.

The WTRU may be associated with the identity of the physical device, or the user's identity, such as MSISDN, SIP URI, etc., such as subscription related identities. The WTRU may be associated with application-based identities, e.g., user names that may be used for each application.

The processors described above may be implemented in a computer program, software, or firmware incorporated into a computer readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals and / or computer readable storage media (transmitted via wired and / or wireless connections). Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memories, semiconductor memory devices, internal hard disks and removable disks, Media, magnetic-optical media, and / or optical media such as CD-ROM disks and digital versatile disks (DVDs). A software related processor may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, and / or any host computer.

Claims (20)

Receiving a video packet associated with a video stream from an application layer;
Assigning a priority level to the video packet, the priority level being associated with a transmission priority of the video packet, and the importance level being associated with a retransmission limit of the video packet; And
And transmitting the video packet according to the retransmission limit. The method according to claim 1,
Further comprising assigning the retransmission limit based at least in part on a network event. 3. The method of claim 2,
Further comprising assigning the retransmission limit based at least in part on a packet loss event. 3. The method of claim 2,
And assigning the retransmission limit based at least in part on the congestion level. The method according to claim 1,
And assigning a higher importance level to the video packet if the video packet is an instantaneous decoder refresh (IDR) frame. The method according to claim 1,
Assigning a higher priority level to the video packet if the video packet follows an instantaneous decoder refresh (IDR) frame and before packet loss after the IDR frame. The method according to claim 1,
Further comprising assigning a higher priority level to the video packet if the video packet occurs in a time interval following an IDR frame while a compatibility constraint is satisfied. 8. The method of claim 7,
Wherein the compatibility constraint requires that a load resulting from video traffic of all priority levels be less than a threshold. The method according to claim 1,
Assigning a lower priority level to the video packet if the video packet follows a packet loss and is a first IDR frame advance following the packet loss. The method according to claim 1,
Wherein the video stream comprises a plurality of video packets, a first subset of the plurality of video packets is associated with a first importance level, a second subset of the plurality of video packets is associated with a second importance level, Wherein the third subset of the plurality of video packets is associated with a third importance level. A device for transmitting video packets,
A processor; And
A memory including processor executable instructions,
The processor-executable instructions, when executed by the processor, cause the processor to:
Receive a video packet associated with a video stream from an application layer, the video packet being characterized by an access category;
Assigning a priority level to the video packet, the priority level being associated with a transmission priority of the video packet and the priority level being associated with a retransmission limit of the video packet; And
And transmit the video packet according to the retransmission limit. 12. The method of claim 11,
Wherein the memory comprises additional processor executable instructions for assigning the retransmission limit based at least in part on a network event. 13. The method of claim 12,
Wherein the memory comprises additional processor executable instructions for assigning the retransmission limit based at least in part on a packet loss event. 13. The method of claim 12,
Wherein the memory comprises additional processor executable instructions for assigning the retransmission limit based at least in part on a congestion level. 12. The method of claim 11,
Wherein the memory further comprises processor executable instructions for assigning a higher priority level to the video packet if the video packet is an instantaneous decoder refresh (IDR) frame. 12. The method of claim 11,
Wherein the memory comprises additional processor executable instructions for assigning a higher priority level to the video packet if the video packet follows an instantaneous decoder refresh (IDR) frame and before packet loss after the IDR frame. A device that sends packets. 12. The method of claim 11,
Wherein the memory includes additional processor executable instructions for assigning a higher priority level to the video packet if the video packet occurs in a time interval following an IDR frame while compatibility constraints are met. A device that sends packets. 18. The method of claim 17,
Wherein the compatibility constraint requires that a load resulting from video traffic of all priority levels be less than a threshold value. 12. The method of claim 11,
Wherein the memory includes additional processor executable instructions for assigning a lower priority level to the video packet if the video packet follows a packet loss and is a first IDR frame advance following the packet loss. Lt; / RTI &gt; 12. The method of claim 11,
Wherein the video stream comprises a plurality of video packets, a first subset of the plurality of video packets is associated with a first importance level, a second subset of the plurality of video packets is associated with a second importance level, And wherein the third subset of the plurality of video packets is associated with a third importance level.

Images