JP2013013093A - Improving throughput in lan by managing tcp acks - Google Patents

Abstract

A method and apparatus for managing receipt confirmation is provided.
A method and apparatus for managing acknowledgments that identify a data packet and acknowledgment as a connection, determine which acknowledgment can be erased, and accept a single acknowledgment that can be erased. What is described includes replacing with confirmation and sending the single receipt confirmation. An alternative method and apparatus for managing acknowledgments that receives data segments, tracks connections, and determines whether there are enough data segments for a predetermined number of channel time allocations. , Including generating an acknowledgment for the selected connection if there are sufficient data segments for the predetermined number of channel time allocations.
[Selection] Figure 20

Description

  The present invention relates to the delivery of compressed multimedia / video from a master device such as a set top box (STB) to a remote device such as an STB in a wireless video distribution system.

  For cable video services, individual video programs are typically broadcast on their own dedicated frequency band over the cable. Any television in the home can be tuned to any individual program by tuning to that frequency. For newer TV services (eg, satellite TV distribution, Internet TV distribution), the program is “tuned” at the master STB and then distributed over the home network to the remote STB. In many cases, a home network (or home distribution system) needs to be installed. Wired (coaxial cable, twisted pair, etc.) is reliable, but can be expensive to install, and homeowners do not like installers to drill holes in the wall for installation There can be. With that in mind, the industry is interested in wireless solutions to video program redistribution system issues.

  Most existing home digital video distribution systems use Ethernet as a distribution medium. Most Ethernet equipment uses a link speed of at least 1000 Mbps and uses a switch that selectively sends traffic only to the branch containing the addressed device, so video with a controlled traffic speed There are few QoS issues when used in redistribution systems. If general IP data traffic is sent over the same network without any type of QoS protection, problems may arise with Ethernet. Currently, one type of medium access control (MAC) level QoS is available for Ethernet. It is a priority-based scheme that uses a user priority field in a virtual local area network (VLAN) tag. The addition of parameterized QoS (bandwidth requirements, bandwidth guarantees, acceptance control, etc.) is currently one subject of a working group within the IEEE 802.1 subcommittee for IEEE 802 network bridging. However, Ethernet (registered trademark) has a drawback in that it requires a wired line for operation, and it is desirable to have an installation technique without a new wiring line.

  What is needed is a wireless distribution system that can replace Ethernet distribution through MAC level bridging. Many home networks use the IP protocol to deliver video, but there are many possibilities. Video may be sent using UDP as defined by the real time transport protocol (RTP), or video may be delivered over TCP (for example, the Digital Living Network Alliance). (DLNA: Digital Living Network Alliance). UDP requires only one-way communication, while TCP requires two-way communication. There are further possibilities. Do not require any modifications to the master and remote devices / STB when there is already an Ethernet interface (ie no bandwidth reservation, no talking to wireless bridge devices, etc.) It would be desirable to have. It is also desirable that the MAC layer be very efficient because the medium is wireless and thus a band-limited common medium. Therefore, the present invention uses the TDMA MAC method. In the TDMA MAC scheme, time allocation is allocated and dedicated bandwidth is given to each client / remote device (STB). The use of “/” in this article represents an alternative name for the same component. The exact bit rate and other characteristics of the video may not be known a priori, even for the master STB. Does not require the master STB to have any special or new communication with the wireless device (remote STB and / or master bridging node), even if the exact bit rate of the video is known a priori It is desirable. Since multimedia traffic is usually downstream from the master device to a few remote devices, there is an opportunity to eliminate overhead. When TCP is used to deliver multimedia streams, most of the upstream traffic is TCP ACK. Eliminating some of these TCP ACKs reduces the amount of overhead transmitted and allows more of the available BW to actually be broken down to carry multimedia stream information To do.

  The time allocated to the return path / upstream path from the remote STB / device to the master device / STB is the time that is not available for the downstream path for video distribution. Since video delivery is the primary function of the target system, it is desirable to reduce the overhead caused by TCP ACK and reduce the negative effects of TCP sliding windows.

  IEEE 802.11N, which is currently being standardized by IEEE, is required as a means for video distribution. There are several concerns regarding the technology that is the subject of IEEE 802.11N. First, it is still based on CSMA (IEEE802.11). This type of MAC layer is inherently inefficient and does not provide QoS guarantees. Many MAC-level QoS improvements have been added to IEEE 802.11N, but it is unlikely that a CSMA-based MAC can be as efficient as a TDMA MAC. QoS improvements include priority-based QoS from IEEE 802.11E, some form of polling, and a collection of MAC protocol data units (MPDUs) and MAC service data units (MSDUs) ( aggregation) addition. These enhancements can be very useful in managing the resources of the IEEE 802.11 network, but do not provide the QoS guarantees that are necessary or desirable for wireless home video distribution systems. Polling can be used to create a TDMA-like service that is the basis for operating the present invention, but polling itself hinders MAC efficiency. MAC efficiency is even more important for wireless networks because of the limited link speed available to more remote areas of the home. Most current wireless local area networks (WLANs) utilize a common transmission medium (ie, the radio spectrum at the same transmission frequency). Therefore, MAC needs a mechanism to share the medium. It should be noted that the present invention can be applied once a transmission opportunity is acquired via CSMA or allocated via polling.

  Some service providers are turning to no-new-wire technologies based on coaxial cables, telephone lines and / or power lines. There are many different possibilities, most of which have some form of priority or parameterized QoS. The problem inherent in these solutions is that even if coaxial cables or telephone lines are already in the home, they may not be connected to the correct spot, or the technology deals with them. It can be a difficult topology. Most of these technologies may also share bandwidth with other households (for example, one power transformer has power lines for up to four households) and is currently unreliable . For parameterized services, the STB needs to know how much bandwidth to reserve for each link. For video home distribution systems, traffic may be out of control, may be bursty, and is at least partially unknown.

  The present invention encompasses a home multimedia stream distribution system that solves the problems highlighted above.

  Most current wireless LANs utilize a common transmission medium (ie, a wireless spectrum at the same transmission frequency). Therefore, a media access control (MAC) layer requires a mechanism for sharing the medium. Most mechanisms are based on the carrier sense multiple access (CSMA) MAC layer (eg, IEEE 802.11). This type of MAC layer is inherently inefficient and does not provide quality of service (QoS) guarantees. MAC efficiency is even more important for wireless networks because of the limited link speed available to more remote areas of the home. In order to achieve very high efficiency and QoS guarantees, the present invention uses a MAC based on time division multiple access (TDMA) IEEE 802.15.3b. A standard MAC is used for basic TDMA functions, but a function to reduce network load caused by TCP ACK is added.

  A typical system for which the present invention is designed includes a master device that delivers Internet Protocol (IP) based video to up to three client / remote devices. The device is an Ethernet / wireless MAC level bridge device, and the actual video tuning and rendering is done in an Ethernet-based STB. Although the present invention is described using an STB, any device that has an equivalent or similar function is contemplated by the present invention regardless of the name of the device. In general, a pure MAC bridge connects LAN segments that can be the same or different. A collection of different LAN technologies interconnected by a bridge is known as a bridge local area network. The MAC bridge operates below the MAC service boundary and is transparent to the protocol used above the MAC bridge service boundary, except that there may be a difference in QoS.

  The system and method of the present invention is described using an exemplary home video distribution system with constrained communications to three remote STBs (ie, all communications to / from the master STB). The technique described in this article can be easily extended to more general home networks. It should be noted that to date there is no wireless home delivery system that can deliver three high-definition video streams to three remote locations in the home. Although the present invention will be described using an exemplary embodiment involving video streaming, the term “video” can be extended to include “multimedia streams” that include other streaming media such as digital audio. It should also be noted that should be obvious immediately.

  All traffic is constrained to / from the master bridging device. The master bridging device periodically transmits beacons that plan channel time allocations (CTAs). Each device transmits its data within the CTA. A beacon plus all the CTA up to the next beacon is called a “superframe” and is shown in FIG. CTA1, 2 and 3 are for downstream traffic (usually video) and CTA4, 5 and 6 are for upstream traffic (usually TCP acknowledgment (ACK) and other management / control frames). The master bridge device determines CTA assignment prior to beacon transmission. In general, the CTA can be determined by a master device (master STB) or a fixed time slot requested by a remote device (remote STB). It is desirable to make full use of all available time allocations / slots.

  The present invention also has the advantage of not requiring any changes to the video system middleware that includes the protocol for carrying the video.

  In the above application, video is delivered over TCP. TCP is a connection-oriented bidirectional protocol that is layered on top of IP in the protocol stack. Although TCP ACK is useful for transmission over the Internet, its utility in a reliable LAN for use in video streaming as in the present invention is questionable. However, TCP is available as middleware in bridging devices, and it is desirable to enhance and improve existing middleware rather than changing it. High reliability can be achieved through low physical layer (PHY) packet error rate and retransmission at the MAC layer. It is also desirable to reduce the negative effects on the overhead and TCP sliding window caused by the TCP ACK returned by the remote STB.

  Described in this article are three ways to reduce the overhead caused by TCP ACK. The first two methods are combined to form a third method. Since the exemplary embodiment of the present invention (for descriptive purposes) is based on TDMA MAC, transmissions from the remote STB to the master STB are bulked every 5 or 10 msec depending on the length of the superframe. Happens at. For this transmission, the remote STB takes the packet from its transmission queue and assembles it into a series of frames (or aggregated frames) for transmission. In this exemplary embodiment, all of this traffic is destined for the master STB. For the first method, the remote bridge device examines the IP and TCP headers of the frames in its transmission queue to determine which of the ACKs can be deleted. Depending on the contents of the frame, several TCP ACKs are replaced with one TCP ACK. This allows a shorter CTA to be allocated to the remote device / STB, allowing more time for the CTA allocated to the master device / STB and hence more time allocated for downstream video. leave.

  In the second method, a TCP ACK back to the master STB is generated by the master bridge device. In this case, the master STB is fooled and assumes that the packet has already been received by the remote STB. The master bridge device keeps track of the TCP sliding window, TCP sequence number, maximum segment size (MSS) and its own transmission queue. If TCP frames arrive too frequently from the master STB, the master bridge device refrains from TCP ACK until the queue level is lowered. This is a form of flow control. The master bridge device also intercepts the TCP ACK that is actually returned from the remote STB and prevents it from being forwarded to the master STB. Alternatively, the TCP ACK can be intercepted by the remote bridge device and a summary report can be sent to the master bridge device if necessary. It is also possible for the remote bridge device to discard a TCP ACK that was caught on the way. This second method has the advantage that in addition to reducing overhead, the negative effects of small TCP sliding windows can be reduced.

  The third method combines the above two methods. The TCP ACK is generated locally by one of the bridge devices (master or remote) as in the second method, but the TCP ACK returned by the remote STB is combined as described in the first method. It is. These methods involve the MAC, IP and TCP layers / functions and reside in the bridge / MAC layer and can be considered cross-layering. The benefit is to reduce the negative effect of streaming over TCP without requiring any changes to the STB. The bridge device identifies and performs a limited amount of TCP / IP processing. For general data network traffic, the industry has generally kept all of the layers separate and independent. The MAC layer is typically unaware of the type of data traffic being carried in the payload of the frame. For example, a home Ethernet switch has no knowledge of TCP or IP, and in fact does not typically require any setup. The bridge is transparent to the network and operates at the MAC layer. No prior art method of any delivery system has attempted to reduce TCP ACK through MAC / bridge layer involvement.

  A method and apparatus for managing acknowledgments, identifying data packets and acknowledgments as a connection, determining which acknowledgments can be erased, replacing erasable acknowledgments with a single acknowledgment, What includes sending the single acknowledgment is described. An alternative method and apparatus for managing acknowledgments, receiving data segments, keeping track of connections, and having enough data segments for a predetermined number of channel time allocations And determining if there are enough data segments for the predetermined number of channel time allocations to generate an acknowledgment for the selected connection. Yet another alternative method, which is a combination of the above two methods, is also described.

  The invention is best understood from the following detailed description when read in conjunction with the accompanying drawings. The drawings include the following figures.

FIG. 1 illustrates an exemplary wireless home video distribution system in accordance with the principles of the present invention. It is a figure which shows a MAC level bridge. It is a figure which shows a general wireless bridge. FIG. 2 illustrates a wireless bridge with constrained paths suitable for wireless home video distribution in an exemplary embodiment of the invention. It is a figure which shows the block diagram (logical structure) of the software by the side of the server of a master STB and a wireless MAC bridge. It is a figure which shows the block diagram (logical structure) of the software of the client side of remote / client STB and a radio | wireless MAC bridge. FIG. 3 is a block diagram of a wireless MAC bridge showing how DTA is used in accordance with the principles of the present invention. FIG. 3 is a diagram depicting a superframe according to the present invention. FIG. 4 is a high level transmit packet flow diagram for a PNC connected to a video server (master STB). Fig. 4 is a high level received packet flow diagram for a PNC connected to a video server (master STB). FIG. 6 is a high level transmit packet flow diagram for DEV-x connected to a video client (remote STB). FIG. 7 is a high level received packet flow diagram for DEV-x connected to a video client (remote STB). FIG. 6 is a diagram depicting a single downstream CTA (PNC to DEV-x). FIG. 2 depicts a super MAC (non-standard collection of MAC frames) and physical frame format. FIG. 6 is a diagram depicting a single upstream CTA (DEV-x to PNC). It is a figure depicting TCP / IP encapsulation. It is the figure which drew the IP header. It is the figure which drew the TCP header. FIG. 5 is a diagram depicting a TCP sliding window operation. 6 is a high-level flowchart of an exemplary embodiment of processing at a remote bridging device. 6 is a high-level transmission flowchart of a second exemplary embodiment of processing at a master bridging device. FIG. 6 is a high level flowchart of a remote acknowledgment (ACK) transfer at a master bridging device. Fig. 4 is a high level flowchart of the second embodiment in a remote bridging device.

  The present invention starts from an IEEE 802.15.3b MAC that supports TDMA service (beacon at the beginning of a superframe and transmission time allocation in the superframe). IEEE802.15b was designed to be a personal network and is therefore “lighter” than technologies designed for LANs and metropolitan area networks (MANs). There are other TDMA MACs that can be used (eg, IEEE 802.16), but in the prior art, no attempt has been made to dynamically allocate CTA length based on traffic characteristics that are purely available to the MAC layer. . IEEE 802.16 is designed for wireless metropolitan area networks (WMAN) and is used for Internet distribution to service subscribers. IEEE 802.16 includes many features and options that allow service providers to customize their networks. Although exemplary embodiments of the present invention are described with respect to IEEE 802.15.3b, the concept is equally applicable to IEEE 802.16 embodiments. There are a few more headers to parse.

  There are several features of TCP that must be considered when setting up CTA. TCP is a transport protocol that utilizes a 32-bit sequence number and request number and a 16-bit sliding window length field. These three numbers are used to implement a "Stop-and-Wait" or "Go-Back-N" ARQ error recovery scheme. TCP packets in the transmission queue and in the process of being transmitted are “in the network”, so the TCP window must be set large enough by the destination to allow those packets to be outstanding. Don't be. In general, MAC level bridging devices have no control over the size of their windows, but the initial selection of CTA and superframe length should be chosen short enough to minimize the problem. Can do. The length of the superframe may be made adjustable (or adaptable) to handle changing TCP window sizes.

  For a 10 msec superframe, approximately 19 1400 byte TCP packets are sent every 10 msec. This is 26,600 bytes. For the purposes of the following description of the exemplary embodiment, a transmit buffer queue of approximately 165 kilobytes was chosen. The TCP buffer size does not allow pending data exceeding 64 kilobytes, so the send buffer queue never overflows for TCP traffic. It is possible that the window is even small enough that it does not even allow the CTA to be completely filled. For this reason, it is better to start with a short superframe (5 msec). The send buffer queue then need not be larger than 51 kilobytes in order to be able to handle at least a single TCP session. However, to avoid lost packets in the case of video sent over UDP, we chose a 165 kilobyte transmit buffer queue.

  Note that a mathematical model of the ARQ error recovery scheme has been developed within the field of queuing theory and can be used to more accurately model TCP performance if necessary. The window size is assumed to be large enough to allow enough pending TCP packets for some to be in the queue while others are in the CTA. In an exemplary embodiment where up to 5 retransmissions are allowed, the CTA should be small enough that about 5 times that data can be detained in the transmit buffer queue. A 5 msec superframe will achieve this if the largest TCP window is used.

  While the initial application will use TCP to stream video, the only way to ensure good performance in the general sense is to allow it to adapt to traffic patterns There is uncertainty.

  Real-time, flexible length superframe construction is possible. This is thought to increase system robustness and improve system performance. The length of the superframe may depend on the length of the three individual video queues, the downlink transmission channel conditions and any other possible points in the exemplary embodiment. For a flexible length superframe, the beacon must broadcast the length of the subsequent CTA, and each remote STB is informed about the length of the dedicated CTA to the remote STB.

  As mentioned above, if the TCP receive window is small enough for the CTA length, the server will not release the next packet until it receives an ACK from the previous packet, effectively slowing the stream at the source. It is possible. That rate may be below the desired real-time streaming rate. To avoid this, the present invention chooses a CTA size that does not lead to this starvation condition. In order to maintain a reasonable rate, the CTA needs to occur more frequently if it is reduced in size. This occurs by reducing the size of the superframe or by assigning more than one CTA to that link per superframe.

  Furthermore, as described above, uncertainty about the TCP window size leads to the possibility of changing the superframe length. This is because the MAC layer triggers a superframe change based on looking at the TCP header or, more appropriately, monitors the transmit buffer queue and the transmit buffer queue becomes too often empty. When there is insufficient data to be transmitted, the superframe can be shortened. In the exemplary embodiment, initially a fixed superframe length was used. Given a fixed superframe length, it is investigated to modify the CTA length to accommodate traffic characteristics. In that case, there is some uncertainty about how much time should be allocated to the CTA that is usually intended for TCP ACK. This is because the TCP stack in the STB may group multiple ACKs and / or include ACKs in the header of packets that contain data.

  It has been found that at a minimum, the average output packet rate for any given transmission queue must be kept below the average packet arrival rate. Otherwise, the queue overflows. However, even though the average arrival rate is lower than the average departure rate, the input rate can temporarily exceed the output rate due to the statistical nature of the input stream. It is necessary but not sufficient to keep the average output rate above the average input rate. Due to the lack of specificity of IP traffic, it is best to make the system adaptive.

  In order to allow adaptation, queue information for all superframes is recorded. Queue information includes queue size (no need to send if fixed), number of packets in queue, average length of packets in queue, and estimate of input packet rate. This information is used as input to the adaptive algorithm along with information about reliable link speeds to each DEV or remote STB. The goal of the adaptive algorithm is not to drop packets and to distribute the superframe time to the CTA in such a way as to reach that goal. The adaptive algorithm attempts to minimize the number of expected packets in each queue (and thus minimize delay) and / or minimize the probability that the queue will overflow. By monitoring the queue level, the MAC can adjust the CTA to give transmission priority to the most satisfied queue for each superframe.

  The present invention relates to a MAC layer and a bridging layer of a wireless video service distribution system that distributes compressed video from a master STB to a remote STB. The system partially uses the IEEE 802.15.3b TDMA MAC and therefore uses some terminology from that standard. An exemplary system incorporating the technology in the STB is shown in FIG.

  The master STB 105 receives input from a variety of video sources including Advanced Television Systems Committee (ATSC) antennas (digital television), satellite antennas and wide area network (WAN) modems. Master STB is a composite National Television Standards Committee (NTSC) video display, high definition multi-media interface (HDMI) component video, connected to a customer switch. It provides output to a video display 110 (eg, a television) that includes a display and a local area network (LAN). The master STB has five satellite tuners (electronic program guide (EPG) tuner, main tuner, three remote tuners and a recording tuner). The main tuner is for tuning to the program desired by the user of the display communicating with the master STB. The three remote tuners are for tuning to the program desired by each user of the remote display. The EPG tuner is for tuning to an electronic program guide. The recording tuner is for the user of the display communicating with the master STB to tune to the program he wants to record while viewing the program tuned by the main satellite tuner. The master STB has two ATSC tuners-a main tuner and a recording tuner. The main tuner is for tuning to the program desired by the user of the display communicating with the master STB. The recording tuner is for the user of the display communicating with the master STB to tune to the program that he wants to record while viewing the program tuned by the main ATSC tuner. The master STB also has a demultiplexer, a personal video recorder (PVR), an infrared (IR) receiver, a satellite / ATSC decoder and a wireless hub for use with a remote control device. The master STB 105 can transmit video to each remote STB at about 20 Mbps. Master STB 105 can exchange satellite vendor IP traffic with each remote STB. Master STB 105 can exchange control information with each remote STB.

  The master STB is in communication with three remote STBs (remote STB1 115, remote STB2 125, and remote STB3 135). Remote STB1 115 is in communication with video display 120. Remote STB2 125 is in communication with video display 130. The remote STB 3 is in communication with the video display 140. Since the configuration of each remote STB is the same, only the remote STB1 will be described. The remote STB1 115 has a satellite / ATSC decoder, an IR receiver and radio station for use with a remote control device. The remote STB1 115 can receive video from the master STB 105 at about 20 Mbps. The remote STB 1 can exchange satellite vendor IP traffic between itself and the master STB 1 105. The remote STB1 115 can exchange control information with the master STB 105.

  The present invention is constructed as a MAC level wireless bridge (see FIG. 2). In general, a MAC bridge connects LAN segments that can be the same or different. A collection of different LAN technologies interconnected by a bridge is known as a bridge local area network. The MAC bridge operates below the MAC service boundary and is transparent to the protocol used above the MAC bridge service boundary, except that there may be a difference in QoS. MAC service users are above the MAC services boundary and MAC service providers are below the MAC service boundary. The MAC layer bridge includes a relay to interface with each LAN segment / component.

  A typical wireless bridge is shown in FIG. The wireless bridge 305 communicates with the server via an Ethernet connection. Two servers 310, 315 are shown. The wireless bridge 305 communicates with a client via an Ethernet (registered trademark) connection. Four clients 320, 325, 330, 335 are shown. Within this general wireless bridge is DEV0. This is a piconet controller (PNC) 340. The PNC 340 communicates with a plurality of devices wirelessly. Three devices DEV1 345, DEV2 350 and DEV3 355 are shown. DEV0 / PNC 340 communicates with servers 310, 315. DEV1 345 communicates with the client 320. DEV2 350 communicates with client 325. DEV3 355 communicates with clients 330, 335.

  However, exemplary embodiments of the present invention constrain paths that are suitable for wireless home video service delivery applications. Possible data paths are indicated by broken lines in FIG. The wireless bridge 405 communicates with the master STB 410 wirelessly. The wireless bridge 405 also communicates with the remote STBs 415, 420, and 425 wirelessly. The wireless bridge 405 is internally configured as shown in FIG. All traffic goes to or from the master STB 410.

  FIG. 5 shows the software architecture on the server side (master STB and bridge device). Note that the master bridge device is also a piconet controller (PNC) as described in IEEE 802.15.3. The master STB 505 has a middleware video server application 510 in the master STB 505. Multimedia stream middleware 515 interfaces with both media QoS control 520 and device driver 525. Multimedia stream middleware 515 transfers video data to device driver 525 and exchanges control information with media QoS control middleware 520. The medium QoS control middleware exchanges control information with the device driver 525. The device driver 525 mainly exchanges video data with a network interface (IEEE802.3) 530. Within the device driver 525 is a portable operating system Unix (POSIX) that receives video data and control information from the media stream middleware 515 and exchanges information with the media QoS control middleware 520. There is a subset of drivers 535. A subset of POSIX drivers exchange information with the QoS middleware in the stack with TCP / IP 540 and media stream protocol 545 and QoS management and control 550. The PNC 555 has a wireless MAC video server bridge application 560, which exchanges control information with software 565 including a plurality of software modules. The software 565 exchanges video data and control information with the radio wave interface 570 and the IEEE 802.3 driver 575. The IEEE 802.3 driver mainly exchanges video data with the IEEE 802.3 network interface 580. The IEEE 802.3 network interface 580 interfaces with the IEEE 802.3 network interface 530 to exchange video information. Software 565 includes a number of software components including an IEEE 802.1D bridging module, which includes a wireless device management entity (DME) and an IEEE 802.2 frame convergence sublayer. (FCSL: frame convergence sublayer) Overlaid as a layer on a service access point (SAP). The wireless MAC video server bridge application 560 has an interface with the wireless DME management SAP. Wireless DME management SAP and wireless DME and IEEE 802.2 FCSL SAP are all layered on top of IEEE 802.2 FCSL DME. The IEEE802.2FCSL DME performs IEEE802.15.3b PNC functions, performs QoS scheduling, and manages bridge functionality. The IEEE 802.2 FCSL DME is layered on top of the IEEE 802.15.3b MAC SAP and the IEEE 802.15.3b MAC layer management entity (MLME) SAP. IEEE802.15.3b MAC layer management entity (MLME) SAP is layered on top of IEEE802.15.3b MLME, and this IEEE802.15.3b MLME is layered on top of physical layer management entity (PLME) It is done. The IEEE 802.15.3b MAC SAP is layered on top of the IEEE 802.15.3b MAC sublayer, which is layered on top of the radio physical SAP. IEEE802.15.3b MAC SAP is layered on top of the radio physical layer. The radio physical layer management entity (PLME) SAP is overlaid as a layer on the radio physical layer PLME. The wireless PLME communicates with the wireless physical layer. The IEEE 802.15.3b MAC sublayer communicates with the IEEE 802.15.3b MLME. The radio physical layer and the radio PLME exchange video data and control information with the radio wave interface, respectively.

  FIG. 6 shows the SW (software) architecture on the client side (remote STB and bridge device). Note that although the present invention is in a bridge device, an STB is shown for context. Note that the remote / client bridge device is also a DEV-x (non-PNC device) as described in IEEE 802.15.3. The remote / client STB 605 has a middleware video client application 610 within the remote / client STB 605. Media stream middleware 615 interfaces with both media QoS control 620 and device driver 625. The media stream middleware 615 receives the video data in the device driver 625 and exchanges control information with the medium QoS control middleware 620. The medium QoS control middleware exchanges control information with the device driver. The device driver 625 usually exchanges video data with the network interface (IEEE 802.3) 630. Within device driver 625 is a subset of POSIX drivers 635 that send video data primarily to media stream middleware 615 to exchange information with media QoS control middleware 620. A subset of POSIX drivers exchange information with the QoS middleware in the stack with TCP / IP 640 and media stream protocol 545 and QoS management and control 650. Dev-x 655 has a wireless MAC video client bridge application 660 that exchanges video data and control information with software 665 including multiple software modules. To do. The software 665 exchanges video data and control information with the radio wave interface 670 and the IEEE 802.3 driver 675. The IEEE 802.3 driver mainly exchanges video data with the IEEE 802.3 network interface 680. The IEEE 802.3 network interface 680 has an interface with the IEEE 802.3 network interface 630 and exchanges video data thereof. The software 665 includes several software components including an IEEE 802.1D bridging module, which is layered on top of the DME and IEEE 802.2 FCSL SAP. The wireless MAC video client bridge application 660 has an interface with the wireless DME management SAP. Wireless DME management SAP and wireless DME and IEEE802.2 FCSL SAP are all layered on top of IEEE802.2 FCSL DME, which implements the functions of IEEE802.15.3b DEV-x, QoS Sends status to PNC for scheduling and manages bridge functionality. IEEE802.2 FCSL DME is layered on top of IEEE802.15.3b MAC SAP and IEEE802.15.3b MLME SAP. The IEEE 802.15.3b MLME SAP is layered on top of the IEEE 802.15.3b MLME, and this IEEE 802.15.3b MLME is layered on top of the physical layer management entity (PLME). The IEEE 802.15.3b MAC SAP is layered on top of the IEEE 802.15.3b MAC sublayer, which is layered on top of the radio physical SAP. IEEE802.15.3b MAC SAP is layered on top of the radio physical layer. The wireless PLME SAP is layered as a layer on the wireless physical layer PLME. The wireless PLME communicates with the wireless physical layer. The IEEE 802.15.3b MAC sublayer communicates with the IEEE 802.15.3b MLME. The wireless physical layer and wireless PLME exchange video data and control information with a wireless radio interface. Software 665 and 660 receive beacon signals with information about the CTA, receive redistributed video / media in their downstream CTA, and send MAC level ACKs or NAKs on the appropriate upstream CTA. Note that these ACKs are different from the TCP ACKs that can be generated at the video client when TCP is used.

  Reference is now made to FIG. FIG. 7 is a block diagram of a wireless MAC bridge in accordance with the principles of the present invention. The PNC 705 transmits data / information to the remote STBs 710, 715, 720 in the assigned CTA, and receives data / information from the remote STBs 710, 715, 720. The master device 705 periodically transmits beacons that negotiate channel time allocation (CTA). Each device transmits its data within the CTA. CTA1, 2 and 3 are for downstream traffic (usually video). CTAs 4, 5 and 6 are for upstream traffic (usually TCP ACK and other management frames).

  A superframe is shown in FIG. The master device determines CTAs prior to beacon transmission. In general, a CTA can be a fixed time slot determined by a master device / PNC or requested by a remote device / STB. Specifically, for IEEE 802.15.3b, the standard specifies that the remote STB / device requests bandwidth by sending a “CTReq” message to the PNC. However, no matter what CTA time is required or set, none of the devices truly know all of the IP traffic characteristics a priori. The traffic can be based on UDP (no ACK reply) or based on TCP. In some cases, all of the traffic can be downstream (asymmetric) and sometimes somewhat symmetric. It is desirable to make full use of all available time by adapting the amount of time within the CTA to optimize traffic flow. The leftmost part of the superframe is first transmitted in the air, and the rightmost part of the superframe is finally transmitted in the air. Following the beacon, the CTA is transmitted, but the downstream CTA is transmitted first, and then the upstream CTA is transmitted. The superframe in the context of the present invention can vary between 5 msec and 10 msec.

  Exemplary packet flow diagrams for PNCs connected to the master STB are shown in FIGS. Exemplary packet flow diagrams for DEV-x (ie, non-PNC devices) connected to a remote STB are shown in FIGS. As described above, the wireless MAC bridge of the exemplary high definition video distribution system acts as a constrained bridge.

  Referring now to FIG. 9, the PNC receives an Ethernet video data frame at the Ethernet port 905 (usually video). The PNC determines the superframe and the length of each CTA. The PNC places the frame in the appropriate transmission queue 910a, 910b, 910c depending on the destination MAC address. The PNC can learn MAC addresses through flooding as described in IEEE 802.1D, or the filtering / routing table can be manually filled. In order to reduce the clutter of the figure, the present invention is described assuming that there is only one queue per transmission port (defined for each DEV-x / remote STB). That is, one queue for each priority group. Ethernet video data frames are queued. In the exemplary embodiment, the queues are each 165 kilobytes, and the superframe is 5 msec to 10 msec long. Video data frames from the queue are forwarded to software module 915, which converts Ethernet video data frames to priority mapping, frame check sequence (FCS). , Conversion to IEEE 802.15.3b MAC frame including fragmentation and header correction code (HCC) calculation. The software module 915 receives forwarding tables and service flows from the data storage unit 920 for processing received Ethernet video data frames. The software module 915 communicates with a buffer 925 that stores a transmit MAC service data unit (MSDU). Software module 930 requests a MAC frame from software module 915 to construct a superframe. Software module 915 forwards multiple MSDUs to software module 930. Software module 930 receives physical characteristics and parameters from data storage unit 935 and MSDU acknowledgment (ACK) from the previous service frame from buffer 940 to build a superframe. The data storage unit 945 receives the MAC bandwidth management command stored as the local and remote DEV (STB) queue length from the previous superframe so that the CTA length can be changed. This information is forwarded to the MAC bandwidth management entity 950, which forwards the CTA length to the software module 930 to further assist in the construction of the superframe. The software module 930 also receives from the superframe retransmission buffer 955 the MSDU to be retransmitted from the previous frame. The superframe retransmission buffer 955 stores a plurality of MSDUs in each remote STB MAC protocol data unit (MPDU) and discards the MSDUs that have been acknowledged. The superframe constructed by the software module 930 is stored in the superframe construction buffer 960. The superframe constructed by the software module 930 includes the downlink MPDU and the uplink time. The superframe construction buffer 960 transfers the constructed superframe to the superframe transmission buffer 965 in the form of a plurality of MSDUs in each remote STB MPDU. The superframe transmission buffer 965 transfers the superframe received from the superframe construction buffer to the superframe retransmission buffer 955. Superframe transmit buffer 965 forwards the complete MPDU to software module 970. The software module receives the delayed ACK from the remote STB during the reception period and receives timing information from the time clock 975. Software module 970 bundles multiple MSDUs into each MPDU and forwards them to physical layer module 980 for transmission. The software module 970 transfers the transmission data, transmission data rate, transmission length, transmission power level and transmission antenna control to the physical layer module 980 using timing based on the timing in the beacon, and the physical layer module 980 A data protocol unit (PPDU) is transmitted from the PNC to the specified remote STB.

  Since FIG. 10 depicts the flow of received packets, the description starts from the right side of the figure. A PPDU is received at the physical layer software module 1005. The physical layer software module 1005 also receives input from the time clock 1010. The physical layer software module forwards the received data, length, link quality indicator (LQI), received signal strength indicator (RSSI) and PHY reception error to the software module 1015. The software module 1015 uses the timing based on the timing beacon to decompose the PPDU into MPDUs that are MSDU integrated, and forwards the MPDUs to the software module 1020. Software module 1020 performs an HCC calculation, isolates the complete MSDU frame or fragment, processes the frame check sequence, tracks the correctly received MSDU, and delays the ACK in response to the delayed ACK request And filter the MSDU so that only the correct MSDU intended for the server is passed to the server (master STB). The software module 1020 forwards the delayed ACK for the received MSDU and discards the MSDU that is not intended for the server (master STB). Software module 1020 receives physical characteristics and parameters from data storage unit 1025 to perform the functions described above. Software module 1020 forwards MAC commands, such as delayed ACKs and bandwidth management messages, to software module 1030. The software module 1030 separates the MAC command, transfers the MSDU ACK to the MSDU ACK buffer 1035, and transfers a MAC bandwidth information element (IE) to the MAC bandwidth management entity 1040. Software module 1020 also forwards MSDU (usually TCP ACK) to software module 1045. This software module 1045 reconstructs the completed MSDU from the fragments, stores the incomplete MSDU fragments, and places the MSDU fragments in the proper order. Software module 1045 communicates with reordered frame construction buffer 1050 and receive MSDU fragment buffer 1055. Software module 1045 forwards the complete MSDU to software module 1060, where the complete MSDU is converted to an Ethernet frame that includes a frame check sequence and priority mapping. The software module receives the forwarding table and service flow information from the data storage unit 1065 and forwards the Ethernet frame to the server (master STB).

  FIG. 11 shows a high-level transmission packet stream for DEV-x connected to a remote STB (video client). The Ethernet frame is received by the software module 1105. This software module 1105 filters and classifies incoming frames from the video client. The software module 1105 transfers the Ethernet frame to the frame queue 1110. All traffic should go to the server (master STB), so there is only one queue. However, if multiple priorities are desired, multiple queues are implemented--one queue for each priority group. The data in the queue is transferred to the software module 1115. This software module 1115 converts Ethernet frames into IEEE 802.15.3 MAC frames including priority mapping, frame check sequences, fragmentation and HCC calculations. Software module 1115 receives the forwarding table and service flow information from data storage unit 1120. Software module 1115 also communicates with transmit MSDU transmit buffer 1125. The software module forwards multiple MSDUs to the software module 1130. This software module 1130 constructs an uplink MPDU for transmission in the next superframe. Software module 1115 also receives requests from software module 1130. Software module 1130 receives MSDU ACK from the previous superframe from buffer 1135. Software module 1130 receives physical characteristics and parameters from data storage unit 1140 and CTA information from beacons from data storage unit 1145. The software module 1130 receives a MAC bandwidth management command from the software module 1150, which receives the local queue length information received from the data storage unit 1155 and the immediately preceding from the data storage unit 1160. A bandwidth management message is constructed using the MAC bandwidth request response from the superframe (IEEE 802.15.3 MAC commands used in a non-standard way to exchange queue information). Software module 1130 receives from the superframe retransmission buffer 1165 the MSDU to be retransmitted from the previous superframe. Each MPDU has multiple MSDUs. The superframe retransmission buffer 1165 also discards the confirmed MSDU. Software module 1130 communicates with build buffer 1170. This construction buffer 1170 is a buffer for uplink MPDU for the next superframe. The construction buffer 1170 transfers the uplink MPDU to the superframe transmission buffer 1175. The superframe transmission buffer 1175 transfers the upstream MPDU to the software module 1180. The superframe transmission buffer 1175 also transfers the uplink MPDU to the superframe retransmission buffer 1165. Software module 1180 uses beacon-based timing to bundle multiple MSDUs into each MPDU and passes the MPDU to physical layer software module 1185 for transmission. The software module receives the time from the time clock 1190 and receives an ACK delayed during the reception period from the server (master STB). Software module 1180 forwards the transmit data, transmit data rate, transmit length, transmit power level, and transmit antenna control to physical layer software module 1185.

  An approximation of the reception process at the remote DEV is shown in FIG. The receiving process mainly consists of the reconstruction of the Ethernet frame, which involves disassembling the superframe and then recollecting the fragmented frames. The receiver also checks for errors and prepares a DLY ACK (a type of bulk ACK) for return to the PNC. The DLY ACK is sent at the beginning of the CTA, pointing in the opposite direction of the CTA from which the packet arrived. This is another departure from the standard.

  FIG. 12 is a high level received packet flow diagram for DEV-x connected to a video client (remote STB). Thus, the description starts from the right side of the figure. Software module 1205 receives the PPDU and forwards the received data, received error, length, LQI and RSSI to software module 1215. Software module 1205 receives receive antenna control information from software module 1215 and receives timing information from time clock 1210. Software module 1215 receives the MPDU from physical layer software module 1205. Multiple MSDUs are grouped into each MPDU. Software module 1215 receives timing from time clock 1210. Software module 1215 forwards the MPDU pieces to software module 1220. This software module 1220 performs the HCC calculation, isolates the complete MSDU or fragment, processes the frame check sequence, tracks the correctly received MSDU, and delays the ACK in response to the delayed ACK request Build, filter MSDU and forward only correctly received MSDU intended for server (master STB). The software module receives physical characteristics and parameters from the data storage unit 1225 and forwards a delayed ACK for the received MSDU. The software module 1220 discards the MSDU that is not intended for the video client (remote STB) and forwards the MAC command to the software module 1230. The software module 1230 separates the MAC management message, forwards the MAC bandwidth response to the data storage unit 1235, and forwards the MSDU ACK from the remote STB to the MSDU buffer 1240. Software module 1220 forwards the MSDU to software module 1245, which reconstructs the completed MSDU from the fragments, stores the incomplete MSDU fragments, and places the MSDUs in the proper order. Software module 1245 communicates with reordering and frame building buffer 1250 and receiving MSDU fragment buffer 1255. Software module 1245 forwards the complete MSDU to software module 1260, which converts the MAC frame into an Ethernet frame containing priority. Software module 1260 also receives forwarding tables and service flow information from data storage unit 1265.

  Referring to FIG. 13, the physical preamble and the physical header form one physical frame per CTA. A delayed ACK to the remote STB, a queue status information request to the remote STB, and multiple data packets to the remote STB form a set of MAC frames with a protected MAC header. The above concatenated with any extra time in that CTA forms the downstream CTA for that PNC to the remote STB.

  Referring now to FIG. 14, there is a corresponding MAC header for each MAC payload. The HCC is calculated and inserted after the MAC header and before the MAC payload. The FCS is calculated and inserted after the MAC payload. This is done for each MAC payload to create a super MAC frame. The super MAC frame length is a part of the physical header. The physical header is inserted before the super MAC frame to create a CTA that is modulated and transmitted over the air. The physical header is sent at a slow, reliable rate, and the super MAC frame portion of the CTA is sent at some desired rate.

  Transmission of frames in CTA4, CTA5 and CTA6 is sent in the same way. An example of a frame sent in one of these CTAs is shown in FIG. FIG. 15 depicts one of the single uplink CTAs (DEV-x to PNC). A single upstream CTA includes one physical frame, a set of MAC frames with protected headers, and any extra time in the CTA. For the present invention, much of the upstream traffic will be a TCP ACK. Similar to the downlink CTA shown in FIG. 13, the physical frame includes a physical preamble and a physical header. The set of MAC frames includes a delayed ACK to the PNC, queue state information to the PNC, and a data packet to the PNC. Note that this CTA includes a frame that carries the queue state information back to the PNC. This queue status information may include the size of the queue (if variable), the number of frames in the queue, the average length of the frames, and the frame arrival rate at the queue input.

  For the present invention, it is assumed that video streaming packets (downstream) are sent from the master STB using TCP. For this reason, a TCP ACK is generated in the opposite direction (upstream) to the video. These TCP ACKs add overhead, and if that overhead is eliminated, time can be freed for more actual traffic (ie, downstream video). In addition, because of the flow control mechanism built into TCP, and because of the additional delay added by the wireless bridge (due to the buffer and CTA), TCP needs a video stream that it really needs to reach Can prevent reaching a certain rate.

  First, let's briefly discuss TCP to better understand the problem. It then presents a number of cross-layer modifications at a high level that can help solve the problem. Note that changing the TCP parameters themselves on the master and remote STBs is another way to solve this problem, but as mentioned several times, this is not possible. Keep it.

  TCP is a full-duplex connection-oriented transfer protocol. TCP sends a segment of the data stream. UDP sends the presented packet. One feature of TCP is reliable delivery. This is guaranteed through the use of TCP ACK. Although this mechanism has proven to be beneficial for Internet traffic, its benefits of producing reliable delivery are questionable on LANs that are already highly reliable. Thus, TCP ACK adds significant overhead. For bandwidth limited networks such as wireless, the overhead penalty is significant.

  TCP encapsulation is shown in FIG. A TCP header is added in front of the TCP payload. An IP header is added before both of these. A combination of a TCP payload and a TCP header is also called a TCP segment. The combination of a TCP segment and an IP header is also called an IP datagram.

  The IP header and TCP header are shown in FIGS. 17 and 18, respectively. The IP header includes a destination IP address and a source IP address. In addition, the IP header includes a protocol number used to identify the payload. For TCP, this number is 17. 6 for UDP. The TCP header contains the destination port number and the source port number. The port number is used by the device at each end to identify the software application or code associated with that TCP connection.

  In addition, the TCP header includes several other fields that are important to the operation of the present invention. Since TCP is a full-duplex connection, each end maintains a separate sequence number counter. The 32-bit sequence number is a byte counter that is incremented for each outgoing packet by a source device that is part of the same TCP connection. This header also includes a 32-bit receipt confirmation number. This is used to inform the sender what the next byte the receiver expects (in other words, the receiver has successfully received byte-1). Follow the same procedure for the opposite direction of a full-duplex TCP connection.

  A maximum segment size (MSS) indicating the maximum segment size (in bytes) that can be received by the receiver is sent from the receiver to the transmitter. Typical TCP MSSs are 1024 (general), 536 (default when one end does not receive MSS from the other end), 1460 over Ethernet, etc. The default of 536 reflects the fact that IP needs to be able to handle packets with a minimum size of 576 bytes (payload and TCP and IP header). Thus, traffic sent to the Internet is typically limited to this number. The external route vs. internal route is determined by finding a maximum transfer unit (MTU).

  The checksum covers the TCP header and data and is used to determine if the frame was received correctly. The most common option field is the maximum segment size (MSS). This is sent when a connection is about to be established. The ACK field means that the receipt confirmation value is valid.

  The sequence number is used to implement the sliding window protocol without selective retransmission or negative acknowledgment. The sequence number can be used in the “Go-Back-N” method or the “Stop-n-Wait” method. The TCP sliding window operation is shown in FIG. Basically, a limited number of unacknowledged bytes are allowed “in the network” at any given time. When the byte is received and confirmed, the trailing part of the window moves to the left. When a byte is received and / or a larger window is advertised, the leading end of the window moves to the left. The number of bytes left in the available window depends on the window size and how many bytes have already been sent. The destination sets the window size based on the number of bytes it can receive (perhaps based on the receive buffer size). The sliding window provides the following well-known bandwidth delay product limitation.

Window size (capacity) = effective bandwidth (bits / second) x round-trip time (seconds)
TCP originally had only a 16-bit window size. This meant that when the TCP receiver set the window size to its maximum, only 64 kilobytes were allowed in the network. The window size has been modified to include a scaling option that allows many more bytes in the network to be received and not acknowledged. However, because of the legacy implementation and because it works "in most cases", many implementations still only use a 16-bit sliding window. The finite TCP sliding window can cause problems in the target application due to the high bandwidth required for video and the delay required for the TDMA MAC wireless bridge.

  To see how a sliding window can negatively impact an exemplary bridging system, consider the following example. Table 1 shows some typical values when the length of the superframe is fixed at 5 msec or 10 msec and the CTA is fixed. Table 2 shows the approximate number of packets that can be expected within each CTA using the MPDU aggregation method presented in this paper and some other individual assumptions (eg, video packet size). The round trip time (RTT) is the time from when a TCP packet is sent to the time when a TCP ACK associated only with that segment is received. If the superframe is 10 msec, the RTT is at least 20 msec. In practice, it is higher because of retransmissions at the packet and MAC levels in the transmission queue. For 20 Mbps and 20 msec delays, the sliding window needs to be at least 50 kilobytes to allow the stream to flow at the intended rate. Due to the additional buffering and the fact that the data comes asynchronously with the start of the CTA, the stream is likely to be slow in this example. Furthermore, the TCP sliding window may be set to some value slower than 50 kilobytes.

いくつかの有利なタイムアウトもある。再送信タイムアウトは、RTTの測定に基づくことができるが、典型的には500msecに設定される。再送信タイムアウトは、受け取り確認されていないTCPセグメントの再送信を開始するために使用される。もう一つのタイマーは、TCP ACKが送信器に返される時を遅延させるために時々使用される。これは、データがペイロードについて利用可能になることを許容するためである。このタイマーは、典型的には200msecについて設定され、本願のためのRTTを増すことになる。

There are also some advantageous timeouts. The retransmission timeout can be based on RTT measurements, but is typically set to 500 msec. The retransmission timeout is used to initiate retransmission of TCP segments that have not been acknowledged. Another timer is sometimes used to delay when a TCP ACK is returned to the transmitter. This is to allow data to be made available for the payload. This timer is typically set for 200 msec and will increase the RTT for this application.

  If the TCP receiver receives a packet with an error, the TCP receiver discards the packet and waits for the sender to retransmit the packet. If the TCP sender does not receive an ACK within the timeout period, typically 500 msec, the TCP sender will resend the packet. For video streaming applications, this is too late for the receiver to use and the packet can also be discarded.

  “Slow Start” is a relatively new TCP function. In this function, the rate at which new packets should be injected into the network is the rate at which acknowledgment is returned from the other side. This effectively adds another window, known as the congestion window, to the sender's TCP. This is mainly used to avoid congestion when going through a router.

  In the present invention, there are two ways to reduce the effects of TCP ACK overhead and TCP window and manage congestion. The two methods can be combined to form a third method. The methods of the present invention involve the MAC layer participating in a limited manner in the TCP ACK process. Video stream packets and return ACKs are identified as part of the TCP connection. It is well known that TCP packets belonging to the same connection (or stream) can be uniquely identified by destination IP address, source IP address, TCP source port number and TCP destination port number. For the target application, most of the packets in the same transmission queue are likely to belong to the same TCP connection. Thus, a TCP ACK with a valid sequence number can be determined by looking at the ACK flag in the TCP header.

  In the first method, it is desirable to reduce the number of TCP ACKs actually transferred from the remote bridging device and the master bridging device over the wireless link. Since the present invention uses TDMA MAC, transmission from the remote STB to the master STB happens every 5 or 10 msec depending on the length of the superframe. For transmission from the remote STB / device to the master STB / device, the remote STB takes the packet from its transmission queue and assembles it into a series of frames (or aggregated frames) for transmission. In this exemplary application, all of this traffic is destined for the master STB.

  The remote bridge device examines the IP and TCP headers of the frames in the transmission queue to determine which is a TCP ACK from the same TCP connection. For those packets, the sequence number in the TCP header is then read. Assuming there is no payload in those packets, the remote bridge device only needs to send the highest sequence number. This is because in TCP, the sequence number includes all lower sequence numbers. If one of the packets includes a payload, that particular packet can be a packet returned with the proper sequence number set in the header. If more than one TCP ACK packet contains data in its payload, it will also be sent with repeated sequence numbers. This effectively removes all redundant “TCP ACK only” packets from the transmit queue. This allows a shorter CTA to be assigned to the remote device / STB, and allows more time for the CTA assigned to the master device / STB, and thus more for the downstream video transmission. Leave time.

  FIG. 20 is a high-level flowchart of the first method of the present invention, implemented in a remote bridge device. At 2005, the remote bridge device receives several TCP ACKs to be forwarded to the master bridge device. At 2010, the remote bridge device scans its transmit queue and receives a single TCP ACK that acknowledges the adjacent TCP ACK with no payload, receiving the highest sequence number from the set of TCP ACKs. Replace with. In 2015, a single aggregate TCP ACK is forwarded to the master bridge device in the CTA. This process is repeated from 2005.

  This first method reduces the overhead of TCP transmission ACKs, but still TCP packets are too slow and may be retransmitted at the TCP level. Because TCP retransmissions are based on fairly long timeouts, they are not very useful for real-time video streams. Since many video coder decoders (codecs) include error concealment schemes, TCP level retransmissions can cause worse problems than if the packets arrived on time with some errors.

  In the second method of the present invention, a local TCP ACK returned to the master device / STB is generated by the master bridge device. That is, the master device / STB is deceived and assumes that the downstream packet has already been received by the remote device / STB. Since the master device / STB receives the TCP ACK, it does not retransmit the data / information. Therefore, if downlink data is received in error for some reason, the downlink video data is still transferred to the remote device / STB even after several MAC-level retransmissions. However, as pointed out, for video streaming it is better to “slightly in error but relatively on time” than “slow and correct”.

  The method can be used for any TCP traffic from the master device / STB, or it can only be used for certain TCP connections. In either case, the master bridge device tracks each TCP connection separately. As pointed out above, TCP traffic is identified in the IP header by a protocol number, and the stream itself is uniquely identified by the source and destination IP addresses and the source and destination TCP port numbers.

  This method is best used only for the video stream itself for several reasons. Although video stream packets are best delivered to the remote device / STB on time even if there is an error, other less frequent data traffic (eg box control) It may be necessary to arrive correctly. In addition, each TCP connection needs to be managed separately, but managing N TCP connections is N times more resources than managing one TCP connection to each remote device / STB (ie, Data structure, etc.). Further, since the exemplary application is downstream video delivery, most of the potential efficiency gains are obtained in the video stream. For all this, it is desirable to generate local TCP ACKs only for the target application video stream connection.

  The master bridging device can use one of several methods to identify the video stream. In some applications, the STB and bridging device can be from one manufacturer. The TCP port number used for video delivery may be known in advance by the bridge device (ie, built in at design time), or the information can be passed directly or through a network or other interface to the bridging device. It may be possible to input manually. The bridging device can identify the stream in some other way, possibly in direct communication with the STB, which may be in direct communication with the service provider's network.

  The master bridging device can identify the video stream from its characteristics. Most video streams (from broadcasters) are in the range of 1-2 Mbps. High definition video is closer to 15-20Mbps. The master bridging device can sniff TCP connection setup packets and then monitor the stream for some time period (eg, 1 second). If it appears to be a constant stream, the master bridge device can begin using this method.

  The master bridge device keeps track of the TCP sliding window, TCP sequence number and its own transmission queue. If the arrival of TCP frames from the master device / STB is too frequent, the master bridge device refrains from TCP ACK until the queue level is lowered. The method of the present invention is a form of flow control.

  FIG. 21 is a high level transmission flowchart of the second method of the present invention implemented in the master bridging device. Optionally, at 2105 during TCP setup, the master bridge device is locally large to the master device / STB and has a TCP window that is large enough to cover the optimal segment size and system delay due to buffering and CTA・ Respond with size. At 2110, the master bridge device receives a TCP data segment from the master device / STB. A test is performed at 2115 to determine if the transmission queue contains sufficient TCP data for a predetermined number of CTAs (eg, two CTAs). If there is sufficient TCP data, operation 2110 is performed again. If there are not enough TCP data segments, at 2120 the master bridge device generates a local TCP ACK to return to the master device / STB and operation 2110 is performed again.

  Since the TCP connection is a full-duplex connection, there is also an ACK that logically goes from the remote device / STB to the master device / STB. In this case, the same process that the master device STB has performed for the downstream packet is performed by the remote device / STB for the upstream packet.

  The master bridge device also intercepts the TCP ACK that is actually returned from the remote device / STB and prevents it from being sent to the master device / STB. The master bridge device uses the information in these TCP ACKs to determine where the remote device / STB is for processing incoming packets. Alternatively, the TCP ACK can be intercepted by the remote bridge device and a summary report is sent to the master bridge device if desired. It is also possible for the remote bridge device to discard the TCP ACK that was caught on the way.

  FIG. 22 is a high level flow chart for transferring a remote TCP ACK at the master bridge device. At 2205, the master bridge device receives a TCP ACK (no payload) from the remote device / STB. A test is performed at 2210 to determine if the received data segment has already been acknowledged. If the data segment has already been acknowledged, the TCP ACK is discarded at 2215 and the process is repeated from 2205. If the data segment has not yet been acknowledged, at 2220 a single TCP ACK is forwarded to the master device / STB.

  The remote bridge device is aware of packets sent several times at the MAC level. Those packets may be slow and may even be wrong once they are finally received at the remote bridge device. In any case, since the remote device / STB keeps track of which bytes have been received and acknowledged, the data segment is still transferred to the remote device / STB.

  FIG. 23 is a high level flowchart of the second method of the present invention implemented in a remote device. At 2305, the remote bridge device receives a TCP data segment (no payload) from the master bridge device. A test is performed at 2310 to determine if the frame is correct (whether the frame passed the frame check sequence). If the frame is correct, the frame is transferred to the remote device / STB at 2315 and the process is repeated from 2305. If the frame is not correct, another test is performed at 2320 to determine if this is the last attempt of retransmission by the MAC layer (fifth attempt). If this is not the last attempt, the process repeats from 2305. If this is the last attempt, at 2325 a new frame check sequence is calculated to match the data and a new TCP frame is constructed. This new frame looks correct but has bad / incorrect data and should occur infrequently.

  An advantage of this second method of the invention is that it can trick the source and assume that the packet has been received and acknowledged. This allows more packets to be in the communication path, effectively lengthening the window and increasing the resulting average bit rate. This average bit rate must be kept above the natural streaming rate of the video.

  The third method combines the above two methods. The TCP ACK is generated locally by one of the bridge devices (master or remote) as in the second method, but the TCP ACK returned by the remote STB is as described in the first method. Combined.

  While the above description has focused on a wireless bridging system with one master and three remote devices suitable for high definition video delivery applications, those skilled in the art will recognize the present invention as described above. It should be apparent that the method can be extended to common wireless CSMA or TDMA MACs, and even to wired MACs running on a common medium (eg, power line).

  It is to be understood that the present invention can be implemented in various forms of hardware, software, firmware, special purpose processors, or combinations thereof. Preferably, the present invention is implemented as a combination of hardware and software. Furthermore, the software is preferably implemented as an application program embodied specifically on a program storage device. The application program may be uploaded to and executed by a machine having any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPUs), random access memory (RAM) and input / output (I / O) interfaces. The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code or part of the application program (or combinations thereof). It is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.

  Since some of the component system components and method steps depicted in the accompanying drawings are preferably implemented in software, the actual connection between system components (or process steps) is It should be understood that the invention can vary depending on how it is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.

The claims at the time of filing of the original application are also disclosed here.
[Claim 1]
A way to manage receipt confirmations:
Identifying data packets and acknowledgments as connections;
Determining which of said receipt confirmations can be deleted;
Replacing said acknowledgment that can be erased with a single acknowledgment;
Sending the single acknowledgment.
Method.
[Claim 2]
The method of claim 1, wherein the identifying step further comprises examining a header in the transmission queue.
[Claim 3]
The method of claim 2, wherein the examining step further comprises examining a flag in the header.
[Claim 4]
The method of claim 2, wherein the determining step further comprises determining which acknowledgment is from a common connection.
[Claim 5]
The method of claim 4, further comprising reading a sequence number in the header.
[Claim 6]
6. The method of claim 5, wherein the single acknowledgment has the highest sequence number of the data packet that is acknowledged.
[Claim 7]
Determining whether there is a payload packet to be transmitted;
Further comprising transmitting the single acknowledgment in the payload packet.
The method of claim 1.
[Claim 8]
The method of claim 1, wherein the connection is a TCP connection.
[Claim 9]
The method of claim 1, wherein the acknowledgment is a TCP acknowledgment and the single acknowledgment is a TCP acknowledgment.
[Claim 10]
A way to manage receipt confirmations:
Receiving a data segment;
Tracking connections;
Determining whether there are enough data segments for a predetermined number of channel time allocations;
Generating the acknowledgment for a selected connection if there are enough data segments for the predetermined number of channel time allocations.
Method.
[Claim 11]
The method of claim 10, further comprising withholding receipt if the frame arrives too frequently.
[Claim 12]
The method of claim 10, comprising:
Capturing a segment receipt confirmation forwarded by the remote device;
Determining whether the segment has already been acknowledged;
Discarding the segment receipt confirmation if the segment has already been acknowledged;
Forwarding the segment acknowledgment if the segment has not yet been acknowledged;
Method.
[Claim 13]
The method of claim 10, further comprising receiving a summary report.
[Claim 14]
The method of claim 10, wherein the connection is a TCP connection.
[Claim 15]
The method of claim 10, wherein the receipt confirmation is a TCP receipt confirmation.
[Claim 16]
The method of claim 10, further comprising aggregating the acknowledgments into a single acknowledgment.
[Claim 17]
A device that manages receipt confirmation:
Means for identifying data packets and acknowledgments as connections;
Means for determining which of said receipt confirmations can be deleted;
Means for replacing said acknowledgment that can be deleted with a single acknowledgment;
Means for transmitting the single acknowledgment.
apparatus.
[Claim 18]
18. The apparatus of claim 17, wherein the means for identifying further comprises means for examining a header in a transmission queue.
[Claim 19]
19. The apparatus of claim 18, wherein the means for examining further comprises means for examining a flag in the header.
[Claim 20]
19. The apparatus of claim 18, wherein the means for determining further comprises means for determining which acknowledgment is from a common connection.
[Claim 21]
21. The apparatus of claim 20, further comprising means for reading a sequence number in the header.
[Claim 22]
23. The apparatus of claim 21, wherein the single acknowledgment has the highest sequence number of the data packet that is acknowledged.
[Claim 23]
Means for determining whether there is a payload packet to be transmitted;
Means for transmitting the single acknowledgment in the payload packet;
The apparatus of claim 17.
[Claim 24]
The apparatus of claim 17, wherein the connection is a TCP connection.
[Claim 25]
The apparatus of claim 17, wherein the acknowledgment is a TCP acknowledgment and the single acknowledgment is a TCP acknowledgment.
[Claim 26]
A device that manages receipt confirmation:
Means for receiving a data segment;
Means for tracking connections;
Means for determining whether there are enough data segments for a predetermined number of channel time allocations;
Means for generating the acknowledgment for a selected connection when there are sufficient data segments for the predetermined number of channel time allocations;
apparatus.
[Claim 27]
27. The apparatus of claim 26, further comprising means for withholding receipt if the frame arrives too frequently.
[Claim 28]
27. The apparatus of claim 26, wherein
Means to intercept the receipt of the segment transferred by the remote device;
Means for determining whether the segment has already been acknowledged;
Means for discarding said segment receipt confirmation if said segment has already been acknowledged;
Means for forwarding the segment acknowledgment if the segment has not yet been acknowledged;
apparatus.
(Claim 29)
The apparatus of claim 16, further comprising means for receiving a summary report.
[Claim 30]
The apparatus of claim 16, wherein the connection is a TCP connection.
(Claim 31)
27. The apparatus of claim 26, wherein the receipt confirmation is a TCP receipt confirmation.
[Claim 32]
27. The apparatus of claim 26, further comprising means for integrating the receipt confirmations into a single receipt confirmation.

Further, some aspects are disclosed.
[Aspect 1]
A method for managing an acknowledgment performed by a wireless bridging device, sent by a remote device and addressed to a master device:
Identifying data and acknowledgment as a connection between the remote device and the master device;
Determining which of said receipt confirmations are redundant;
Replacing the redundant acknowledgment with a single acknowledgment;
Sending the single acknowledgment.
Method.
[Aspect 2]
The method of aspect 1, wherein the identifying step further comprises examining a header in a transmission queue.
[Aspect 3]
The method of aspect 2, wherein the examining step further comprises examining a flag in the header.
[Aspect 4]
The method of aspect 2, wherein the determining step further comprises determining which acknowledgment is from a common connection.
[Aspect 5]
5. The method of aspect 4, further comprising reading a sequence number in the header.
[Aspect 6]
The method of aspect 5, wherein the single acknowledgment has the highest sequence number of the data to be acknowledged.
[Aspect 7]
Determining whether there is a payload packet to be transmitted;
Transmitting the payload packet as the single acknowledgment.
A method according to aspect 1.
[Aspect 8]
The method of aspect 1, wherein the connection is a TCP connection.
[Aspect 9]
The method of aspect 1, wherein the acknowledgment is a TCP acknowledgment and the single acknowledgment is a TCP acknowledgment.
[Aspect 10]
A method for managing an acknowledgment performed by a wireless bridging device, sent by a remote device and addressed to a master device:
Receiving data sent by the remote device;
Tracking a connection between the remote device and the master device;
Generating an acknowledgment for the specific data if no acknowledgment is received after a predetermined number of retransmissions for the specific data;
Sending the generated acknowledgment to the master device.
Method.
[Aspect 11]
11. The method of aspect 10, further comprising withholding receipt confirmation if the data arrives too frequently.
[Aspect 12]
A method according to aspect 10, comprising
Intercepting the receipt confirmation sent by the remote device for specific data;
Determining whether the particular data has already been received and confirmed;
Discarding the receipt confirmation if the specific data has already been acknowledged;
Transferring the acknowledgment to the master device if the specific data has not yet been acknowledged;
Method.
[Aspect 13]
11. The method of aspect 10, further comprising receiving a summary report from another wireless bridging device that intercepted the acknowledgment sent by the remote device.
[Aspect 14]
The method of aspect 10, wherein the connection is a TCP connection.
[Aspect 15]
11. The method of aspect 10, wherein the receipt confirmation is a TCP receipt confirmation.
[Aspect 16]
11. The method of aspect 10, further comprising aggregating the receipt confirmations into a single receipt confirmation.
[Aspect 17]
A wireless bridging device that manages the acknowledgment sent by the remote device and addressed to the master device:
Means for identifying data and acknowledgment as a connection between the remote device and the master device;
Means for determining which of said receipt confirmations are redundant;
Means for replacing the redundant acknowledgment with a single acknowledgment;
Means for transmitting the single acknowledgment.
Wireless bridging device.
[Aspect 18]
The wireless bridging device of aspect 17, wherein the means for identifying further comprises means for examining a header in a transmission queue.
[Aspect 19]
The wireless bridging device of aspect 18, wherein the means for examining further comprises means for examining a flag in the header.
[Aspect 20]
The wireless bridging device of aspect 18, wherein the means for determining further comprises means for determining which acknowledgment is from a common connection.
[Aspect 21]
The wireless bridging device according to aspect 20, further comprising means for reading a sequence number in the header.
[Aspect 22]
The wireless bridging device of aspect 21, wherein the single acknowledgment has the highest sequence number of the data to be acknowledged.
[Aspect 23]
Means for determining whether there is a payload packet to be transmitted;
Means for transmitting the payload packet as the single acknowledgment.
The wireless bridging device according to aspect 17.
[Aspect 24]
The wireless bridging device according to aspect 17, wherein the connection is a TCP connection.
[Aspect 25]
The wireless bridging device of aspect 17, wherein the acknowledgment is a TCP acknowledgment and the single acknowledgment is a TCP acknowledgment.
[Aspect 26]
A wireless bridging device that manages the acknowledgment sent by the remote device and addressed to the master device:
Means for receiving data;
Means for tracking connections;
Means for determining whether there is sufficient data for a predetermined number of channel time allocations;
Means for generating the acknowledgment for a selected connection when there is sufficient data for the predetermined number of channel time allocations;
Wireless bridging device.
[Aspect 27]
27. The wireless bridging device of aspect 26, further comprising means for withholding receipt if data arrives too frequently.
[Aspect 28]
A wireless bridging device according to aspect 26,
A means of intercepting acknowledgments sent by remote devices for specific data;
Means for determining whether said particular data has already been received and confirmed;
Means for discarding the receipt confirmation if the specific data has already been confirmed;
Means for forwarding the acknowledgment to the master device if the specific data has not yet been acknowledged;
Wireless bridging device.
[Aspect 29]
The wireless bridging device of aspect 16, further comprising means for receiving a summary report from another wireless bridging device that intercepted the acknowledgment sent by the remote device.
[Aspect 30]
The wireless bridging device according to aspect 16, wherein the connection is a TCP connection.
[Aspect 31]
27. The wireless bridging device according to aspect 26, wherein the receipt confirmation is a TCP receipt confirmation.
[Aspect 32]
27. The wireless bridging device of aspect 26, further comprising means for integrating the acknowledgments into a single acknowledgment.
[Aspect 33]
A method for managing data transmission from a master device to a remote device performed by a wireless bridging device comprising:
Receiving data sent by the master device;
Determining whether the data is correct by using inspection data included in the data;
If it is determined that the data is incorrect and a predetermined number of retransmissions have already been attempted, changing the test data included in the data to new test data calculated to match the incorrect data; ;
Transferring the data to the remote device.
Method.
[Aspect 34]
A wireless bridging device that manages data transmission from a master device to a remote device:
Means for receiving data sent by the master device;
Means for determining whether the data is correct by using test data included in the data;
Means for changing the test data contained in the data to new test data calculated to match the incorrect data if the data is determined to be incorrect and a predetermined number of retransmissions have already been attempted; ;
Transferring the data to the remote device.
Wireless bridging device.

Claims (32)

A method for managing acknowledgments by a time division multiple access traffic constrained wireless medium access control bridge communicating with a remote device, comprising:
Identifying individual unicast connection data and acknowledgments by the client side of the time division multiple access traffic constrained wireless medium access control bridge;
Determining which of the acknowledgments can be erased by the client side of the time division multiple access traffic constrained wireless medium access control bridge;
Replacing the acknowledgment that can be erased with a single acknowledgment by the client side of the time division multiple access traffic constrained wireless medium access control bridge;
Transmitting the single acknowledgment by the client side of the time division multiple access traffic constrained wireless medium access control bridge to the master side of the time division multiple access traffic constrained wireless medium access control bridge. ,
Method.   The method of claim 1, wherein the step of identifying further comprises examining a header in a data frame in a transmission queue.   The method of claim 2, wherein the examining step further comprises examining a flag in the header.   The method of claim 2, wherein the determining step further comprises determining which acknowledgment is from a common unicast connection.   The method of claim 4, further comprising reading a sequence number in the header.   6. The method of claim 5, wherein the single acknowledgment has the highest sequence number of the data that is acknowledged. Determining whether there is a payload packet to be transmitted;
Further comprising transmitting the single acknowledgment in the payload packet.
The method of claim 1.   The method of claim 1, wherein the connection is a TCP connection.   The method of claim 1, wherein the acknowledgment is a TCP acknowledgment and the single acknowledgment is a TCP acknowledgment. A method of managing acknowledgments by a time division multiple access traffic constrained wireless medium access control bridge communicating with a master device comprising:
Receiving data by a master side of the time division multiple access traffic constrained wireless medium access control bridge;
Tracking individual unicast connections by the master side of the time division multiple access traffic constrained wireless medium access control bridge;
Determining by the master side of the time division multiple access traffic constrained wireless medium access control bridge whether there is sufficient data to satisfy a predetermined number of channel time allocations;
If there is not enough data for the predetermined number of channel time allocations, the master side of the time division multiple access traffic constrained wireless medium access control bridge generates the acknowledgment for a selected unicast connection Stages,
Transmitting the data by unicast to a remote device by the master side of the time division multiple access traffic constrained wireless medium access control bridge in the predetermined number of channel time allocations;
Method.   The method of claim 10, further comprising withholding receipt if the data arrives too frequently. The method of claim 10, comprising:
Capturing a segment receipt confirmation forwarded by the remote device;
Determining whether the data has already been received and confirmed;
Discarding the segment receipt confirmation if the data has already been acknowledged;
Transferring the segment acknowledgment if the data has not yet been acknowledged;
Method.   The method of claim 10, further comprising receiving a summary report.   The method of claim 10, wherein the connection is a TCP connection.   The method of claim 10, wherein the receipt confirmation is a TCP receipt confirmation.   The method of claim 10, further comprising aggregating the acknowledgments into a single acknowledgment. A time division multiple access traffic constrained wireless medium access control bridge that manages acknowledgments:
Means for identifying data and acknowledgment of individual unicast connections by the client side of the time division multiple access traffic constrained wireless medium access control bridge;
Means for determining which of said acknowledgments can be erased by said client side of said time division multiple access traffic constrained wireless medium access control bridge;
Means for replacing the acknowledgment that can be erased by the client side of the time division multiple access traffic constrained wireless medium access control bridge with a single acknowledgment;
Means for transmitting the single acknowledgment by the client side of the time division multiple access traffic restricted wireless medium access control bridge to the master side of the time division multiple access traffic restricted wireless medium access control bridge. ,
Traffic constrained wireless bridge.   The traffic constrained wireless bridge of claim 17, wherein said means for identifying further comprises means for examining a header in a data frame in a transmission queue.   19. The traffic constrained wireless bridge of claim 18, wherein the means for examining further comprises means for examining a flag in the header.   19. The traffic constrained wireless bridge of claim 18, wherein said means for determining further comprises means for determining which acknowledgment is from a common unicast connection.   21. The traffic constrained wireless bridge of claim 20, further comprising means for reading a sequence number in the header.   The traffic constrained wireless bridge of claim 21, wherein the single acknowledgment has the highest sequence number of the data packet that is acknowledged. Means for determining whether there is a payload packet to be transmitted;
Means for transmitting the single acknowledgment in the payload packet;
The traffic constrained wireless bridge of claim 17.   The traffic constrained wireless bridge of claim 17, wherein the connection is a TCP connection.   The traffic-constrained wireless bridge of claim 17, wherein the acknowledgment is a TCP acknowledgment and the single acknowledgment is a TCP acknowledgment. A time division multiple access traffic constrained wireless medium access control bridge that manages acknowledgments, which communicates with the master device:
Means for receiving data by the master side of the time division multiple access traffic constrained wireless medium access control bridge;
Means for tracking individual unicast connections by the master side of the time division multiple access traffic constrained wireless medium access control bridge;
Means for determining by said master side of said time division multiple access traffic constrained wireless medium access control bridge whether there is sufficient data for a predetermined number of channel time allocations;
Means for generating said acknowledgment for a selected connection by said master side of said time division multiple access traffic constrained wireless medium access control bridge when there is not enough data for said predetermined number of channel time allocations When;
Means for transmitting the data by unicast to a remote device in the predetermined number of channel time allocations by the master side of the time division multiple access traffic restricted wireless medium access control bridge;
Traffic constrained wireless bridge.   27. The traffic constrained wireless bridge of claim 26, further comprising means for withholding acknowledgment if data arrives too frequently. 27. A traffic constrained wireless bridge according to claim 26, comprising:
Means to intercept the receipt of the segment transferred by the remote device;
Means for determining whether said data has already been received and confirmed;
Means for discarding the segment receipt confirmation if the data has already been acknowledged;
Means for forwarding the segment acknowledgment if the data has not yet been acknowledged;
Traffic constrained wireless bridge.   27. The traffic constrained wireless bridge of claim 26, further comprising means for receiving a summary report.   27. The traffic constrained wireless bridge of claim 26, wherein the connection is a TCP connection.   27. The traffic constrained wireless bridge of claim 26, wherein said acknowledgment is a TCP acknowledgment.   27. The traffic constrained wireless bridge of claim 26, further comprising means for integrating the acknowledgments into a single acknowledgment.

Images