WO2009026747A1 - Method and apparatus for communicating over multiple networks - Google Patents

Method and apparatus for communicating over multiple networks Download PDF

Info

Publication number
WO2009026747A1
WO2009026747A1 PCT/CN2007/002615 CN2007002615W WO2009026747A1 WO 2009026747 A1 WO2009026747 A1 WO 2009026747A1 CN 2007002615 W CN2007002615 W CN 2007002615W WO 2009026747 A1 WO2009026747 A1 WO 2009026747A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
mode
tdf
wireless
wired
packet
Prior art date
Application number
PCT/CN2007/002615
Other languages
French (fr)
Inventor
Jinfei Yu
Zhigang Zhang
Junbiao Zhang
Original Assignee
Thomson Licensing
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • H04L12/2869Operational details of access network equipments
    • H04L12/2898Subscriber equipments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/46Interconnection of networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling

Abstract

A Asymmetric Data over Coaxial (ADoC) dual mode device provides support for both wired and wireless modes of operation, and can switch between these two modes periodically. In ADoC (wired) mode, the dual mode device operates as ADoC Station while in WLAN (wireless) mode, it operates as WLAN Access Point. In one particular implementation, a communication unit (3100, 3104, 3106) is configured for communicating over multiple media including a wireless medium and a wired medium, the communication unit being operable (1) in a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) in a wired mode for communicating over the wired medium using a variation of the wireless protocol. The implementation also includes a switch (3104) to switch the communication unit between the wireless mode and the wired mode.

Description

Method and Apparatus for Communicating over Multiple Networks

BACKGROUND

Technical Field This disclosure addresses a variety of aspects of communications systems generally.

Background

Communications systems exist for connecting users to information. Such systems may use coaxial cable as well as wireless networks. Existing systems exhibit a variety of limitations .

SUMMARY According to one general aspect, a device, such as, for example, a communication unit, is for communicating over multiple media including a wireless medium and a wired medium. The communication unit is operable (1) in a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) in a wired mode for communicating over the wired medium using a variation of the wireless protocol. A device, such as, for example, a switch is configured to switch the communicating device (for example, the communication unit) between the wireless mode and the wired mode. According to another general aspect, a method includes communicating over multiple media including a wireless medium and a wired medium, the communicating using one or more of (1) a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) a wired mode for communicating over the wired medium using a variation of the wireless protocol. The method includes switching between the wireless mode and the wired mode . According to another general aspect, an apparatus includes a processor-readable medium including instructions stored on the processor-readable medium for communicating over multiple media including a wireless medium and a wired medium, the communicating using one or more of (1) a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) a wired mode for communicating over the wired medium using a variation of the wireless protocol. The instructions are also for switching between the wireless mode and the wired mode.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Even if described in one particular manner, it should be clear that implementations may be configured or embodied in various manners. For example, an implementation may be performed as a method, or embodied as an apparatus configured to perform a set of operations or an apparatus storing instructions for performing a set of operations . Other aspects and features will become apparent from the following detailed description considered in conjunction with the accompanying drawings and the claims .

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates a simplified exemplary TDF access network architecture.

Fig. 2 illustrates the 802.11 MAC sublayer in OSI reference model.

Fig. 3 illustrates an implementation of a TDF transmission entity in OSI reference model. Fig. 4 illustrates an implementation of a communication mode entrance procedure .

Fig. 5 illustrates an implementation of a TDF super frame structure . Fig. 6 illustrates an implementation of a registration procedure .

Fig. 7 illustrates an implementation of an unregistration procedure . Fig. 8 illustrates an implementation of an alive notification procedure.

Fig. 9 includes a system diagram that depicts an implementation of a TDF network.

Fig. 10 includes a block diagram of an implementation of an AP and a modem from Fig. 9.

Fig. 11 includes a flow diagram of an implementation of an uplink transmission process.

Fig. 12 includes a diagram of an implementation of a one- to-one mapping between an Ethernet packet and a WLAN packet. Fig. 13 includes a diagram of an implementation of a transformation between multiple Ethernet packets and a single WLAN packet.

Fig. 14 includes a diagram depicting packet flow in the transformation of Fig. 13. Fig. 15 includes a diagram of an implementation of an EIW header from Fig. 14.

Fig. 16 includes a flow diagram of an implementation of an uplink reception process.

Fig. 17 includes a diagram depicting an implementation for decapsulating packets.

Fig. 18 includes a diagram depicting an implementation of a PADM from Fig. 10.

Fig. 19 includes a flow diagram of an implementation of a downlink transmission process. Fig. 20 includes a flow diagram of an implementation of a downlink reception process.

Fig. 21 illustrates an implementation of a TDF super frame structure with both polling and time division medium access. Fig. 22 illustrates an implementation of a TDF super frame structure with hybrid medium access mechanism.

Fig. 23 illustrates a block diagram and SP and Stations in a TDF network. Fig. 24 illustrates an implementation of the polling notification procedure.

Fig. 25 illustrates a flow diagram of the polling procedure.

Fig. 26 illustrates an implementation of a TDF super frame structure with hybrid medium access mechanism. Fig. 27 illustrates a flow diagram of the process for switching from contention based more to time division mode.

Fig. 28 illustrates a flow diagram of the process for switching from time division mode to contention based mode.

Fig. 29 is a block diagram of a TDF (ADoC) STA. Fig. 30 is a block diagram of a TDF (ADoC) STA having a dual mode device according to an implementation.

Fig. 31 is a block diagram of a hardware implementation of the TDF (ADoC) STA dual mode device.

Fig. 32 is a block diagram of another hardware implementation of the TDF (ADoC) STA dual mode device.

Fig. 33 is a block diagram of an implementation of the dual mode device of the present principles into a modem of Fig. 10.

Fig. 34 illustrates another implementation of a TDF Superframe structure.

DETAILED DESCRIPTION

The discussion of at least Figs. 1-8 presents a variety of implementations that include one or more novel and inventive aspects or features. At least one of these implementations provides a system that transmits data over a cable using features typical of a wireless system. In particular, at least one implementation uses time-division multiplexing over a coaxial cable. Such a system allows, for example, a cable television operator to provide television signals in part of a spectrum and to provide additional services over another part of the spectrum. The additional services may include, for example, Internet access, including access for searching the Internet and viewing web pages on the Internet, as well as for receiving services over the Internet (such as, for example, video-on-demand) .

The discussion of at least Figs. 9-20 presents additional implementations, and at least one of the additional implementations extends the discussion of Figs. 1-8 by describing novel and inventive uses of encapsulation. One particular implementation includes a modem that receives Ethernet packets from multiple hosts. Each host may be attempting to communicate with a different web site, through a router. The modem encapsulates these packets into a single packet that is formatted according to a format structure, or protocol, for wireless transmission. The encapsulated packet, however, is sent over a coaxial cable for receipt by the router. The router in turn sends the packets, in one implementation, to the different web sites with which each of the hosts is attempting to communicate.

The encapsulation used by the above-described implementation provides an increase in throughput, as compared to a system that encapsulates only one packet at a time. Thus, the overhead of the wireless format structure is spread out over multiple Ethernet packets. This stands in contrast to the conventional use of encapsulation which, for example, allows additional features to be provided by another communication layer, or ensures backward compatibility by preserving a legacy frame structure in the encapsulated data. Further, the encapsulation of the above-described implementation also allows, depending on system design, for data from multiple sources to be encapsulated together, and for data intended for different end-users (for example, different web sites, or different hosts) to be encapsulated together. The discussion of at least Figs. 21-34 presents yet further implementations. Some of these implementations address the frame structure and novel and inventive aspects associated with polling and contention-based access. Further implementations address dual-mode configurations.

This application now provides a description of Figs. 1-8. Note that headers are used for various sections of the description of Figs. 1-8. The header of a given section is not to be construed as limiting the disclosure of that section to the topic of the header, nor as limiting the disclosure of other sections to topics other than that of the header. The headers are exemplary, and are intended as a general aid to the reader. The headers are not intended to constrain the flow of the disclosure nor to restrict the applicability or generality of the disclosure.

General description

Application scenario

In order to provide data service over existing coaxial cable TV system (CATV) , at least one implementation deploys a time divisional function (TDF) protocol compliant Access Point (AP) and stations (STAs) in the cable access network. The AP and STAs are connected via splitters in the hierarchical tree structure. In this way, the user at home can access the remote IP core network via the cable access network. The detailed network topology is illustrated as illustrated in Fig. 1.

As can be seen from Fig. 1, in this typical access network infrastructure, there is a TDF protocol compliant AP which has one Ethernet Interface in connection with the IP core network, and one coaxial cable interface in connection with the cable access network. On the other end of the cable access network, there are TDF protocol compliant STAs, i.e. terminals, which connect with the cable access network via the coaxial cable interface and connect with the home LAN (Local Area Network) via the Ethernet interface.

According to at least one implementation, both TDF APs and STAs implement the protocol stack separately in logically link control sublayer, MAC sublayer and physical layer, according to 802.11 series specifications. However, in the MAC sublayer, the TDP APs and STAs replace the 802.11 frame transmission entity with TDF frame transmission entity. So, the MAC sublayer for TDF APs and STAs is composed of 802.11 frame encapsulation/decapsulation entity and TDF frame transmission entity, while MAC sublayer for 802.11 compliant APs and STAs consists of 802.11 frame encapsulation/decapsulation entity and 802.11 frame transmission entity. For an integrated AP and STA, the TDF frame transmission entity and 802.11 frame transmission entity may co-exist at the same time, to provide both 802.11 and TDF functionality. The switch between the two modes can be realized by manually or dynamically configuration.

Basic approach

The main idea of the TDF protocol is to transmit IEEE 802.11 frames in the coaxial cable media instead of over the air. The purpose of utilizing the IEEE 802.11 mechanism is to make use of the mature hardware and software implementation of 802.11 protocol stacks.

The main feature of TDF is its unique medium access control method for transmitting IEEE 802.11 data frames. That o

is, it doesn't utilize the conventional IEEE 802.11 DCF (Distributed Coordination Function) or PCF (Point Coordination Function) mechanism to exchange MAC frames, which include MSDU (MAC Service Data Unit) and MMPDU (MAC Management Protocol Data Unit) . Instead, it uses time division access method to transmit MAC frames . So the TDF is an access method which defines a detailed implementation of frames transmission entity located in MAC sublayer.

For the purpose of comparison, here we illustrate IEEE 802.11 MAC sublayer protocol in the OSI reference model as shown in the Fig. 2. While the exact location for TDF protocol in the OSI reference model is illustrated in the Fig. 3.

Communication mode entrance procedure

Currently, there are two communication modes proposed for the TDF compliant stations described as below. One is the standard IEEE 802.11 operation mode, which obeys to the frame structure and transmission mechanism defined in IEEE 802.11 series standard; the other is in TDF operation mode, the detailed information about which will be discussed in the following paragraphs. The strategy of determining entering into which operation mode when a TDF STA is started is indicated in the Fig. 4. Once a TDF STA receives a synchronization frame from an AP, it is enabled to entering into TDF mode, if there is no synchronization frame received within a preset timeout, then the TDF STA remains or shifts into IEEE 802.11 mode.

TDF protocol functional description Access method

The physical layer in a TDF station may have multiple data transfer rate capabilities that allow implementations to perform dynamic rate switching with the objective of improving performance and device maintenance. Currently, TDF station may support three types of data rates: 54 Mbps, 18 Mbps and 6 Mbps . The data service is provided mainly in 54 Mbps data rate. When there are some problems for a station to support 54 Mbps data transmission, it may temporarily switch to 18 Mbps data rate. The 6 Mbps data rate operation mode is designed for the purpose of network maintenance and station debugging.

The data rate may be configured statically before a TDF station enters the TDF communication procedure, and remain the same during the whole communication process. On the other hand, the TDF station may also support dynamical data rate switch during the service . The criteria for the data rates switch may be based on the channel signal quality and other factors.

The fundamental access method of TDF protocol is Time Division Multiple Access (TDMA) , which allows multiple users to share the same channel by dividing it into different time slots. The TDF STAs transmit in rapid succession for uplink traffic, one after the other, each using their own time slot in a TDF super frame assigned by the TDF AP. For downlink traffic, the STAs share the channels, and select the data or management frames targeting to them by comparing the destination address information in the frames with their address. Fig. 5 illustrates an example of TDF super frame structure and the time slots allocation for a typical TDF super frame when there are m STAs which simultaneously compete for the uplink transmission opportunity.

As shown in Fig. 5, there are fixed number of timeslots tdfTotalTimeSlotNumber per TDF super frame, which is composed of one synchronization time slot used to send clock synchronization information from TDF AP to TDF STAs; one contention time slot used to send registration request for uplink time slot allocation; tdfUplinkTimeSlotNumber uplink time slots used by the registered TDF STAs to send data and some management frames to TDF AP one after another; and tdfDownlinkTimeSlotNumber downlink time slots used by TDF AP to transmit data and registration response management frames to the modems. Except the synchronization time slot, all other time slots, which are named as common time slot, have same duration whose length equals with tdfCommonTimeSlotDuration. The value of tdfCommonTimeSlotDuration is defined to allow the transmission of at least one largest IEEE 802.11 PLCP (physical layer convergence protocol) protocol data unit (PPDU) in one normal time slot for the highest data rate mode. The duration of synchronization time slot, tdfSyncTimeSlotDuration, is shorter than that of the common time slot, because the clock synchronization frame, which is transmitted from TDF AP to TDF STA in this time slot, is shorter than the 802.11 data frame .

As a result, the duration of one TDF super frame, defined as tdfSuperframeDuration, can be calculated by: tdfSuperframeDuration = tdfSyncTimeSlotDuration + tdfCommonTimeSlotDuration * (tdfTotalTimeSlotNumber - 1)

The relationship between tdfTotalTimeSlotNumber, tdfUplinkTimeSlotNumber and tdfDownlinkTimeSlotNumber satisfies the following equality: tdfTotalTimeSlotNumber = tdfUplinkTimeSlotNumber + tdfDownlinkTimeSlotNumber + 2

Furthermore, the number of allocated uplink time slots for the TDF STAs in a TDF super frame may change from one to tdfUplinkTimeSlotThreshold. Accordingly, the available downlink time slots in a TDF super frame may change from (tdfTotalTimeSlotNumber-2) to (tdfTotalTimeSlotNumber-2- tdfMaximumUplinkTimeSlotNumber) . Every time when there is one TDF STA which asks for an uplink time slot, the TDF AP will deduce one or more time slots from the available downlink time slots, and then allocate these time slots to the TDF STA, as long as the uplink time slots number won't exceed tdfMaximumUplinkTimeSlotNumber after that. The value of tdfMaximumUplinkTimeSlotNumber may vary in different implementations . But it must be carefully chosen so that there is at least one downlink time slot available for an associated TDF STA in order to guarantee the QoS of data service. Furthermore, all successive time slots that will be used by the same TDF STA or AP for same direction transmission can be merged to send MAC frames continuously to avoid the wastes at the edge of these time slots caused by the unnecessary conversion and guarding.

In current implementation, the tdfCommonTimeSlotDuration is about 300 us, which is enough for the TDF STA to transmit at least one largest 802.11 PPDU in one common time slot for 54M mode, and there are total 62 time slots per TDF super frame. In these time slots, there are 20 uplink time slots and 40 downlink time slots in this way. When there are 20 STAs, each TDF STA can be guaranteed that it has access to 680 kbps uplink data rate and shares 30 Mbps (40 continuous time slots) downlink data rate,- when there are 30 STAs, each TDF STA can be guaranteed that it has access to 680 kbps uplink data rate and shares 22.5 Mbps (30 continuous time slots) downlink data rate. The tdfMaximumUplinkTimeSlotNumber is 30. Finally, the value of tdfSuperframeDuration, which is the total duration of 61 common time slots and one synchronization time slot, is about 18.6 ms and it can be defined to different value for different usage. For example, if there is only 1 TDF STA, it can be guaranteed that it has 4 time slots to achieve about 18 Mbps uplink data rate and own 18 Mbps (4 continuous time slots) downlink data rate. In this way, the value of tdfSuperframeDuration, which is the total duration of nine data timeslots and one synchronization timeslot, is about 4 ms .

Frame formats

In the 802.11 specification, three major frame types exist. Data frames are used to exchange data from station to station. Several different kinds of data frames can occur, depending on the network. Control frames are used in conjunction with data frames to perform area clearing operations, channel acquisition and carrier-sensing maintenance functions, and positive acknowledgement of received data. Control and data frames work in conjunction to deliver data reliably from station to station. More specifically, one important feature for the data frames exchanging is that there is an acknowledgement mechanism, and accordingly an Acknowledgement (ACK) frame for every downlink unicast frame, in order to reduce the possibility of data loss caused by the unreliable wireless channel. Finally, management frames perform supervisory functions: they are used to join and leave wireless networks and move associations from access point to access point.

However, in TDF system, because TDF STAs passively waits for the Synchronization frame from TDF AP to find the targeting TDF AP, there is no need for the classical Probe Request and Probe Response frames. Furthermore, the frames are exchanged in coaxial cable instead of in the air, so it isn't necessary to define RTS and CTS frames to clear an area and prevent the hidden node problem, and to define ACKs frames to ensure the reliability of delivery of data frames. So, in TDF protocol, we only use some useful 802.11 MSDU and MMPDU types for data over coaxial cable scenario. For example, we utilize the data subtype in data frame types, which is used to encapsulate the upper layer data and transmit it from one station to another. Furthermore, to cope with clock synchronization requirement in TDF system, we define a new kind of management frame—Synchronization frame; and to realize the functionality of uplink time slot request, allocation and release, we defines other four kinds of management frames that are Registration request, Registration response, Unregistration request and Alive notification.

To summarize it, we have defined four new subtypes in management frame type in TDF protocol. The following table defines the valid combinations of type and subtype added in TDF protocol. Table 1 shows valid type and subtype for TDF frames added in TDF protocol .

Table 1

Figure imgf000014_0001

TDF access procedure

TDF AP finding and clock Synchronization procedure

TDF protocol depends a great deal on the distribution of timing information to all the nodes. Firstly, the TDF STA listens to a Synchronization frame to decide if there is a TDF AP available. Once it enters the TDF communication procedure, it uses the Synchronization frame to adapt the local timer, based on which the TDF STA shall decide if it is its turn to send the uplink frames. At anytime, TDF AP is master and TDF STA is slave in synchronization procedure. Further, if it hasn't received any Synchronization frame from the associated AP for a predefined threshold period, which is defined as tdfSynchronizationCycle, the TDF STA will think that the AP has quit the service, and then it will stop the TDF communication process and start to look for any TDF AP by listening to the Synchronization frame again.

In the TDF system, all STAs associated with the same TDF AP shall be synchronized to a common clock. The TDF AP shall periodically transmit special frames called Synchronization that contains its clock information to synchronize the modems in its local network. Every TDF STA shall maintain a local timing synchronization function (TSF) timers, to ensure it is synchronized with the associated TDF AP. After receiving a Synchronization frame, a TDF STA shall always accept the timing information in the frame. If its TSF timer is different from the timestamp in the received Synchronization frame, the receiving TDF STA shall set its local timer according to the received timestamp value. Further, it may add a small offset to the received timing value to account for local processing by the transceiver.

Synchronization frames shall be generated for transmission by the TDF AP once every TDF super frame time units and sent in the Sync time slot of every TDF super frame.

Registration procedure

Fig. 6 illustratively describes the whole procedure of registration. Once a TDF STA has acquired timer synchronization information from the Synchronization frame, it will learn when time slot 0 starts. If a TDF STA doesn't associate with any TDF AP, it will try to register with the specific TDF AP, which sent the Synchronization frame, by sending Registration request frames to TDF AP during the contention time slot, which is the second time slot in a TDF super frame. The duration of contention time slot, which equals with tdfCommonTimeSlotDuration, and the Registration request frame structure should be carefully designed to allow for sending at least tdfMaximumUplinkTimeSlotNumber Registration request frames in one contention time slot. Based on the design, the contention time slot is divided into tdfMaximumUplinkTimeSlotNumber same length sub-timeslots .

As soon as it finds the targeting TDF AP, a TDF STA will choose one sub-timeslot in the contention time slot to send Registration request frame to the TDF AP according to the following method:

A. Every time when it is allocated an uplink time slot, a TDF STA will store the allocated uplink time slot number, defined as tdfAllocatedUplinkTimeSlot , which indicates the time slots' location in the whole uplink time slots pool and ranges from 1 to tdfMaximumUplinkTimeSlotNumber.

B. The TDF AP should try its best to allocate same uplink time slot to the same TDF STA every time when it asks for an uplink time slot. C. When it is time to decide to choose which sub- timeslot to send Registration request frame, if there is a stored tdfAllocatedUplinkTimeSlot value, the TDF STA will set the sub-timeslot number as same as tdfAllocatedUplinkTimeSlot ; if there isn't such a value, the TDF STA will randomly choose one sub-timeslot in the tdfMaximumUplinkTimeSlotNumber available sub-timeslots. It will send the Registration request frame to the TDF AP in the randomly chosen sub-timeslot. The purpose for this kind of operation is to reduce the chance of collision when there are many STAs start at the same time and try to register with the same TDF AP simultaneously.

The TDF STA will list all data rates it supports at that time and also carry some useful information such as the received signal Carrier/Noise ratio in the Registration request frame. It may send several successive Registration request frames with different supported data rates, starting from the highest data rate. After sending out the frame, the TDF STA will listen for the Registration response frames from the TDF AP.

After receiving a Registration request frame from a TDF STA, based on the following method, the TDF AP will send different kinds of Registration response frames back to the TDF STA in the downlink time slots:

A. If the already allocated uplink time slots equals with tdfMaximumUplinkTimeSlotNumber, the TDF AP will put an uplinkTimeSlotUnavailable indicator in the frame body.

B. If the TDF AP doesn't support any data rates listed in the supportedDataratesSet in the Registration request management frame, the TDF AP will put an unsupportedDatarates indicator in the frame body. C. If there are uplink timeslots available to allocate and common data rates that both the TDF AP and TDF STA can support, the AP will allocate one uplink time slot and choose a suitable common data rates according to some information such as Carrier/Noise ratio in the STA' s Registration request frame, and then send a Registration response frame to the TDF STA. In the frame body, the information about the allocated uplink time slot and the chosen data rate will be contained. After a successful registration process, the TDF STA and TDF AP will reach an agreement on which uplink time slot and data rate to use .

Fragmentation/defragmentation procedure

In TDF protocol, the time slot duration for the transmission of MSDU is fixed as tdfCommonTimeSlotDuration. In some data rates, when the MSDU' s length is more than a threshold, it is impossible to transmit it in a single time slot. So when a data frame for uplink transmission is longer than the threshold, which is defined as tdfFragmentationThreshold and varies depending on different data rates, it shall be fragmented before scheduled for transmitting. The length of a fragment frame shall be an equal number of octets (tdfFragmentationThreshold octets) , for all fragments except the last, which may be smaller. After fragmentation, the fragmented frames shall be put into the outgoing queue for transmission to the TDF AP. This fragmentation procedure may run in the TDF frame transmission entity or in the upper layer by using the tdfFragmentationThreshold dynamically set in the TDF frame transmission entity.

At the TDF AP end, each fragment received contains information to allow the complete frame to be reassembled from its constituent fragments . The header of each fragment contains the following information that is used by the TDF AP to reassemble the frame:

A. Frame type B. Address of the sender, obtained from the Address 2 field

C. Destination address

D. Sequence Control field: This field allows the TDF AP to check that all incoming fragments belong to the same MSDU, and the sequence in which the fragments should be reassembled. The sequence number within the Sequence Control field remains the same for all fragments of a MSDU, while the fragment number within the Sequence Control field increments for each fragment .

E. More Fragments indicator: Indicates to TDF AP that this is not the last fragment of the data frame. Only the last or sole fragment of the MSDU shall have this bit set to zero. All other fragments of the MSDU shall have this bit set to one.

The TDF AP shall reconstruct the MSDU by combining the fragments in order of fragment number subfield of the Sequence Control field. If the fragment with the More Fragments bit set to zero has not yet been received, the TDF AP will know that the frame is not yet complete. As soon as the TDF AP receives the fragment with the More Fragments bit set to zero, it knows that no more fragments may be received for the frame.

The TDF AP shall maintain a Receive Timer for each frame being received. There is also an attribute, tdfMaxReceiveLifetime, which specifies the maximum amount of time allowed to receive a frame. The receive timer starts on the reception of the first fragment of the MSDU. If the receive frame timer exceeds tdfMaxReceiveLifetime, then all received fragments of this MSDU are discarded by the TDF AP. If additional fragments of a directed MSDU are received after its tdfMaxReceiveLifetime is exceeded, those fragments shall be discarded.

Uplink transmission procedure

After receiving the Registration response frame from the TDF AP, the TDF STA will analyze the frame body to see if it is granted an uplink time slot. If not, it will stop for a while and apply for the uplink time slot later. If yes, it will start to transmit uplink traffic during the assigned time slot using the data rate indicated in the Registration response frame .

At the beginning of the uplink transmission during the assigned timeslot, the TDF STA will send the first frame in its outgoing queue to the TDF AP if there is at least one outgoing frame in the queue. After that, the TDF STA will check the second uplink frame's length and evaluate if it is possible to send it during the remaining duration in the assigned timeslot. If not, it will stop the uplink transmission procedure and wait for sending it in the assigned timeslot during the next TDF super frame. If yes, it will immediately send the second frame to the destination TDF AP. The sending procedure will continue to run in this way until the assigned timeslot has ended, or there isn't any uplink frame to transmit.

Downlink transmission procedure In the whole TDF communication procedure, the total downlink time slots number may change dynamically due to the changing associated STAs number. When the TDF AP prepares to send frames to the associated STAs, it will compare the time left in the remaining downlink time slots with the duration needed for transmitting the specific downlink frame using the agreed data rate. Then based on the result, it will decide if the frame should be transmitted with the specific data rate during this TDF super frame. Furthermore, TDF AP doesn't need to fragment any downlink frames.

When it isn' t time for the associated STA to send uplink traffic, the STA will always listen to the channel for the possible downlink frames targeting to it. Unregistration procedure

As shown in Fig. 7, if the TDF STA decides to quit the TDF communication procedure, it shall send an Unregistration request frame to the associated TDF AP during its uplink time slot, in order to inform the TDF AP to release the allocated uplink time slot resource for it. After receiving the Unregistration request frame, the TDF AP will free the uplink time slot assigned for the TDF STA and put it into free time slots pool for the future use.

Alive notification procedure

Now with reference to Fig. 8, to release the resources as soon as possible when a TDF STA unexpectedly crashes or shuts down, the TDF STA must report its aliveness by sending an Alive notification frame periodically to TDF AP during its uplink time slot period. If there isn't any Alive notification frame for a predefined threshold period which is named as tdfAliveNotificationCycle, the associated TDF AP will think that the TDF STA has quit the service, and then release the uplink time slot allocated for the TDF STA, just like receiving an Unregistration request frame from the TDF STA.

In order to ensure coexistence and interoperability on multirate-capable TDF STAs, this specification defines a set of rules that shall be followed by all stations: A. The Synchronization frames shall be transmitted at the lowest rate in the TDF basic rate set so that they will be understood by all STAs.

B. All frames with destination unicast address shall be sent on the supported data rate selected by the registration mechanism. No station shall transmit a unicast frame at a rate that is not supported by the receiver station.

C. All frames with destination multicast address shall be transmitted at the highest rate in the TDF basic rate set. ^

The description of Figs. 9-20 follows. At least Figs. 9- 20 describe implementations that may be used, for example, with one or more systems described by Figs. 1-8. Of course, the features and aspects of the implementations of Figs. 9-20 may be used with other systems .

As described above, a TDF protocol can replace the conventional 802.11 DCF (distributed coordination function) or PCF (point coordination function) mechanism. Such a system can take advantage of a wide deployment of WLAN (802.11) network, and a WLAN chipset that may be getting more and more mature and cheap. This system provides a cost effective solution for bidirectional communication of CATV network by transmitting WLAN signals in cable network, even though the WLAN protocols are created for transmission/reception in an air environment rather than a cable network. In this system, the fundamental access method of TDF protocol is TDMA, which allows multiple users to share the same channel by dividing it into different time slots. The TDF stations transmit in rapid succession for uplink traffic, one after the other, each using their own time slot in a TDF superframe assigned by the TDF AP (access point) . For downlink traffic, the stations share the channels (as shown, for example, in the TDF superframe of Fig. 5) , and select the frames targeting them by comparing the destination address information in the frames with their address .

Referring to Fig. 9, a typical TDF network 900 is shown. The network 900 provides a connection from user homes 910 and 920 to the Internet (or another resource or network) 930. The user homes 910 and 920 connect through an access point (AP) 940 over a cable system 950. The AP 940 may be located, for example, in a neighborhood of the homes 910 and 920, or in an apartment building that includes the homes (apartments, in this case) 910 and 920. The AP 940 may be owned by a cable operator, for example. The AP 940 is further coupled to a router 960 over an Ethernet network 970. The router 960 is also coupled to the Internet 930. As should be clear, the term "coupled" refers to both direct connections (no intervening components or units) and indirect connections (one or more intervening components and/or units) . Such connections may be, for example, wired or wireless, and permanent or transient. The user homes 910 and 920 may have a variety of different configurations, and each home may be differently configured. As shown in the network 900, however, the user homes 910 and 920 each include a station (referred to as a modem) 912 and 922, respectively. The modems 912, 922 are coupled to a first host (hostl) 914, 924, and a second host (host2) 916, 926, over an Ethernet network 918, 928, respectively. Each host 914, 916, 924, and 926 may be, for example, a computer or other processing device or communication device. There are various ways in which the network 900 may allow multiple hosts (for example, 914, 916, 924, and 926) to connect to the router 960. Four implementations are discussed below, considering only the modem 912 and hosts 914 and 916, for simplicity. In a first method, the modem 912 acts as another router. The hosts 914 and 916 are identified by their IP addresses, and the modem 912 routes IP packets from the hosts 914 and 916 to the router 960. This method 1 typically requires the modem 912 to run router software, which requires additional memory and increased processing power.

In a second method, the modem 912 acts as a bridge. The modem 912 and the AP 940 use the standard wireless distribution system (WDS) mechanism to convey layer 2 packets to the router 960. The hosts 914 and 916 are identified by their media access control (MAC) addresses. This method 2 is part of the 802.11 standard and can serve multiple hosts simultaneously. However, not all APs and modems support WDS, and those that do support WDS often have only limited support. For example, with some APs and modems, you cannot use Wi-Fi protected access (WPA) with WDS, and this may introduce security problems .

In a third method, the modem 912 uses MAC masquerade to change the source MAC address of Ethernet packets (the source being one of the hosts 914 and 916) to its own MAC address. So from the point of view of the router 960, the router 960 only sees the modem 912. The modem 912 can only serve one host at one time with this method.

In a further method, the modem 912 uses encapsulation, as described in further detail below. Each of the above methods has advantages and disadvantages, and these advantages and disadvantages may vary depending on the implementation. However, the encapsulation method provides particular advantages in that it generally allows the modem to be simpler by not requiring that the modem run router software, it does not typically introduce security problems, and it can serve multiple hosts at one time.

Additionally, the encapsulation method avoids the large overhead associated with the first three methods, which transfer each packet from a host by using a single WLAN packet Thus, the first three methods incur the overhead of the WLAN packet for every packet transferred from a host, and the throughput is correspondingly reduced. Such inefficiency is typically aggravated in the TDF environment. In the TDF environment, the duration of the time slot is fixed, and the time slot is designed to allow only one WLAN packet to transmit in one slot. Thus, only one host packet can be transmitted in each time slot. Accordingly, the encapsulation method generally provides one or more of a variety of advantages . Such advantages include, for example, simpler router design and operation, increased security, serving multiple hosts, and increased efficiency and throughput.

In summary, at least one implementation of the encapsulation method includes encapsulating multiple Ethernet packets into one WLAN packet. The WLAN packet will be as big as the maximum length allowed by the TDF time slot. The AP (for example, another modem) will decapsulate the WLAN packet into individual Ethernet packets and send them to the Router. For communication in the reverse direction, a modem will decapsulate a WLAN packet and send the individual Ethernet packets to the host(s).

Referring to Fig. 10, an illustration 1000 includes multiple modems, two of which are explicitly shown, and an AP. The illustration includes a modem #1 1010, a modem #N 1020, and an AP 1030, with each of the modems 1010 and 1020 coupled to the AP 1030 over a cable network 1040. Other implementations use separate cable networks for each of the modems .

The modems 1010 and 1020, and the AP 1030 include functional components of the same name, although some of the external connections are different and the components themselves perform different functions for a modem and for an AP. Thus, a common unit is provided that serves as both a modem and an AP. However, it should be clear that different units could be designed for a modem and for an AP, with the different units performing only those functions required of a modem or an AP, respectively.

The modem 1010 includes a local applications layer 1011, followed by a TCP/IP layer 1012, followed by a bridge 1014. The bridge 1014 is coupled to an Ethernet interface 1015, a packet aggregation/deaggregation module (PADM) 1016, and a WLAN interface 1017. The PADM 1016 is also coupled to the WLAN interface 1017. The Ethernet interface 1015 is coupled to an Ethernet network 1052, that is coupled to a first host (hostl) 1054 and a second host (host2) 1056.

The modem 1020 is analogous to the modem 1010. However, the modem 1020 is coupled to an Ethernet network 1062, and the Ethernet network 1062 is coupled to a first host (hostl) 1064 and a second host (host2) 1066. The components of the modem 1020 are shown as being identical to those of the modem 1010. However, it should be clear that various configuration parameters, for example, will be different when the modems 1010 and 1020 are set up and operational. The AP 1030 includes a local applications layer 1071, followed by a TCP/IP layer 1072, followed by a bridge 1074. The bridge 1074 is coupled to an Ethernet interface 1077, a PADM 1076, and a WLAN interface 1075. The PADM 1076 is also coupled to the WLAN interface 1075. The Ethernet interface 1077 is coupled to an Ethernet network 1082, which in turn is coupled to a router 1090. The WLAN interfaces 1017 and 1075 are communicatively coupled to each other over the cable network 1040.

The router 1090 is further coupled to the Internet 1095. Thus, a connection exists between the hosts 1054, 1056, 1064, 1066, and the Internet 1095.

The various local application layers (1011, 1071) are standard layers for running local applications and interfacing with other layers in the architecture. The various TCP/IP layers (1012, 1072) are standard layers for running TCP/IP and for providing the services typically provided by such layers, including interfacing to other layers in the architecture. The various Ethernet interfaces (1015, 1077) are standard units for interfacing to/from an Ethernet network. Such interfaces 1015, 1077 transmit and receive Ethernet packets and operate according to the Ethernet protocol .

The various WLAN interfaces (1017, 1075) are units for interfacing to/from a WLAN network. Such interfaces 1017, 1075 transmit and receive WLAN packets and operate according to the WLAN protocol. However, the WLAN interfaces 1017, 1075 are actually coupled, in the illustration 1000, to a cable network 1040 rather than using wireless communication.

The Ethernet and WLAN interfaces 1015, 1017, 1075, and 1077 may be implemented, for example, in hardware such as a plug-in card for a computer. The interfaces may also largely be implemented in software such as a program that performs the functions of the interface using instructions that are implemented by a processing device. Such an interface will generally include a portion for receiving the actual signal (for example, a connector) and for buffering the received signal (for example, a transmit/receive buffer), and typically a portion for processing the signal (for example, all or part of a signal processing chip) . The various bridges (1014, 1074) are units that forward packets between an Ethernet interface and a WLAN interface. A bridge may be software or hardware implemented, or may only be a logical entity. Standard implementations for a bridge include a processing device (such as an integrated circuit) or a set of instructions running on a processing device (such as a processor running bridge software) .

The PADMs 1016 and 1076 perform a variety of functions, including packet encapsulation and decapsulation, which are further described below. The PADMs 1016 and 1076 may be implemented in, for example, software, hardware, firmware, or some combination. Software implementations include, for example, a set of instructions such as a program for running on a processing device. Hardware implementations include, for example, a dedicated chip such as an application specific IC (ASIC) .

Referring to Fig. 11, a process 1100 depicts a process for transferring packets from a host to a modem. The packets are further transmitted from the modem for receipt by an AP, and for eventual delivery to a router and then a final destination. This process 1100 is also referred to as an uplink transmission process.

The process 1100 includes the modem connecting to the AP (1110) using, for example, processes described earlier in this application. Such processes may include, for example, standard WLAN protocols including authentication and association operations.

The process 1100 then includes one or more hosts sending one or more packets (1120) to the modem, and the modem receiving the sent packet (s) (1130). Note that the send packets are for receipt by a router which will deliver the packet (s) to the final destination (s) . In the implementation of Fig. 10, the modem 1010 receives the sent packets, from one or more of the hosts 1054 and 1056, over the Ethernet network 1052 through the Ethernet interface 1015.

The modem then determines that the packet (s) is (are) to be sent over a WLAN interface (1140) . The modem makes this determination (1140) by recognizing that the router is accessed over the WLAN interface, as opposed, for example, to being accessed over another interface (not shown) . In the implementation of Fig. 10, the modem 1010 sends the received packet (s) to the bridge 1014, and the bridge 1014 makes this determination (1140) . The modem then encapsulates multiple packets for the router, including the one or more received packets (1150) . The encapsulation (1150) may include packets received from multiple hosts, for example, from hosts 1054 and 1056 in the implementation of Fig. 10. Further, the encapsulation may include the packet (s) received in operation 1130 and packets received earlier and stored in a queue.

In an implementation that does not encapsulate multiple packets, the implementation may use a bridge to map Ethernet packets to individual WLAN packets, encapsulating each

Ethernet packet individually. Such encapsulation may, for example, include the entire Ethernet packet as a data portion of a WLAN packet and add an additional WLAN header.

Further, implementations that do not encapsulate multiple packets need not even encapsulate the individual Ethernet packets. Rather, such implementations may transform individual Ethernet packets into individual WLAN packets by, for example, replacing the Ethernet header with a WLAN header and by optionally adding one or more additional fields. For example, referring to Fig. 12, a transformation 1200 is shown that receives an Ethernet packet 1210 including an Ethernet header 1220 and a data portion 1230. The transformation 1200 produces a WLAN packet 1240 that includes a WLAN header 1250, the data portion 1230, and a frame check sequence (FCS) 1260.

However, implementing operation 1150 includes encapsulating multiple Ethernet packets into a single WLAN packet. One implementation of operation 1150 is illustrated in Fig. 13. Referring to Fig. 13, a transformation 1300 receives multiple Ethernet packets, including Ethernet packets 1310, 1312, and 1314, and produces a single WLAN packet 1318. The Ethernet packets 1310, 1312, and 1314 each include an Ethernet header 1320, 1322, and 1324, respectively, and a data portion 1326, 1328, and 1329, respectively.

The Ethernet packets 1310, 1312, and 1314 may originate from the same host, or from different hosts. Further, although the Ethernet packets 1310, 1312, and 1314 are being encapsulated for sending to a router, the final destinations of the Ethernet packets 1310, 1312, and 1314 may be different. For example, each of the Ethernet packets 1310, 1312, and 1314 may be destined for different Internet sites with which the one or more hosts are communicating (or attempting to communicate) .

The transformation 1300 is shown as including two intermediate operations. However, other implementations do not perform any intermediate operations, and still other implementations perform more intermediate operations. The first intermediate operation is transforming the

Ethernet packets into extended Ethernet packets . The Ethernet packets 1310, 1312, and 1314 are transformed into extended Ethernet packets 1330, 1332, and 1334, respectively. In the transformation 1300, the entire Ethernet packets 1310, 1312, and 1314 are included as data portions 1336, 1338, and 1340, respectively, of the extended Ethernet packets 1330, 1332, and 1334. The extended Ethernet packets 1330, 1332, and 1334 also include, respectively, optional headers 1342, 1343, and 1344, as well as optional tails 1346, 1347, and 1348. The headers 1342, 1343, and 1344, and the tails 1346, 1347, and 1348 may include a variety of different pieces of information, whether typical for headers/tails or not, such as, for example, packets numbers, acknowledgment and retransmission information, addresses for sources and/or destinations, and error checking information.

The second intermediate operation includes transforming the extended Ethernet packets into a single "Ethernet in WLAN" (EIW) packet 1350. The EIW packet 1350 includes data portions for each of the extended Ethernet packets. Two possible transformations are shown. The first is illustrated by solid arrows 1370 and the second is illustrated by dashed arrows 1375.

As shown by the solid arrows 1370 in the transformation 1300, data portions 1352, 1353, and 1354 correspond, respectively, to the included extended Ethernet packets 1330, 1332, and 1334. The EIW packet 1350 further includes an optional header 1356 (also referred to as an EIW header) and an optional tail 1358, which may include, for example, any of the information previously described for headers/tails.

If no header or tail is inserted into an extended Ethernet packet, then the data portion of the extended Ethernet packet (for example, the data portion 1336) becomes the data portion of the EIW packet (for example, the data portion 1352) . Further, even if a header or tail is inserted into the extended Ethernet packet, an implementation may discard/ignore the header or tail when forming the EIW packet. In either of these cases, the data portions of the extended Ethernet packet and the EIW packet have the same data. As shown by the dashed arrows 1375 in the transformation 1300, the data portions 1352, 1353, and 1354 need not correspond, respectively, to the extended Ethernet packets 1330, 1332, and 1334. That is, a data portion of an EIW packet need not contain an entire extended Ethernet packet. As indicated by the dashed arrows 1375, an extended Ethernet packet may be divided into the data portions of two EIW packets .

More specifically, the implementation illustrated by the dashed arrows 1375 shows that (1) a second part of the extended Ethernet packet 1330 is put into the data portion

1352 of the EIW packet 1350, (2) the entire extended Ethernet packet 1332 is put into the data portion 1353 of the EIW packet 1350, and (3) a first part of the extended Ethernet packet 1334 is put into the data portion 1354 of the EIW packet 1350. Thus, in one scenario for the EIW packet 1350, (1) the first data portion 1352 contains a partial extended Ethernet packet, and (2) the last data portion 1354 contains a partial extended Ethernet packet, while (3) the middle data portions (1353 and any other data portions not explicitly shown) contain complete extended Ethernet packets. Although not shown, it should be clear that the first part of the extended Ethernet packet 1330 may be placed in a data portion of a previous EIW packet, and (2) a second part of the extended Ethernet packet 1334 may be placed in a data portion of a subsequent EIW packet .

In the final stage of the transformation 1300, the EIW packet 1350 is included as a data portion 1360 in the WLAN packet 1318. The WLAN packet 1318 also includes a WLAN MAC header 1362 and an FCS 1364.

As should be clear, not all implementations use all of the optional headers and tails, nor even use all (or any) of the optional intermediate operations (also referred to as stages) . For example, other implementations only copy part of the extended Ethernet packets into the EIW packet, in order to fit more original data (for example, data portions 1326, 1328, and 1329) into a fixed-duration timeslot. As should be clear, the determination of which headers and tails are used, as well as how many intermediate operations are included, may vary for each implementation based on design goals and constraints.

Referring to Fig. 14, a diagram 1400 shows how one implementation of a PADM encapsulates Ethernet packets. The PADM maintains an ingress queue 1410 into which each incoming Ethernet packet is placed. The PADM concatenates the Ethernet packets into a string 1420, and adds an EIW header 1430 and a WLAN header 1440. Depending on the information included in the headers 1430 and 1440, these headers 1430 and 1440 may be constructed ahead of time or after concatenating the Ethernet packets. For example, at least one implementation includes in the EIW header 1430 a number representing the number of

Ethernet packets in the string 1420. Given that Ethernet packets may have a variable length, this number is not typically available until after the Ethernet packets have been assembled into the string 1420. As should be clear, the headers 1430 and 1440 may be defined to accommodate the needs of a particular implementation.

Referring to Fig. 15, a format 1500 of one implementation of an EIW header is shown. The format 1500 includes a field 1510 for sequence and ack numbers, a total packet number 1520, and a series of packet descriptors, including one descriptor for each Ethernet packet encapsulated in the WLAN packet. Accordingly, a variable number of packet descriptors is envisioned, as indicated by the ellipsis in Fig. 15. Packet descriptors 1530 and 1540 are shown, with each of the packet descriptors 1530 and 1540 including a packet flag (1550 and 1555, respectively) and a packet length (1560 and 1565, respectively) .

The sequence number (1510) provides a sequence identifier for the encapsulated data, which allows the recipient to acknowledge receipt of the transmission. The ack number provides an acknowledgement for previously received data. The total packet number is the number of Ethernet packets that are encapsulated in the WLAN packet . The packet flags (1550, 1555) indicate whether the associated Ethernet packet is a complete packet. Given that the time slot has a fixed duration, it is possible that an entire Ethernet packet might not fit into a given WLAN packet. Accordingly, in particular implementations it is expected that the first and last Ethernet packets will typically be incomplete in any given WLAN packet. The packet length (1560, 1565) indicates the length of that particular Ethernet packet.

Continuing with the process 1100, in the implementation of Fig. 10, the operation 1150 may be performed by, for example, the PADM 1016 of the modem 1010. Other implementations may perform the operation 1150 in, for example, the bridge, the Ethernet interface, the WLAN interface, another intermediary component other than the PADM, a component above the bridge, or in a combination of components. As should be clear, the component (s) performing the operation 1150 may be implemented in, for example, software (such as a program of instructions) , hardware (such as an IC) , firmware (such as firmware embedded in a processing device) , or a combination.

Additionally, the PADM may be located in a different position within the modem (such as, for example, above the bridge or between the Ethernet interface and the bridge) , within one of the interfaces or the bridge, and/or be distributed among multiple components.

The process 1100 further includes the modem sending the encapsulated packet to the AP over a cable (1160) . The sent packet is intended for receipt by the router. The cable may include, for example, a coaxial cable, a fiber optic cable, or other wired transmission medium.

In a particular implementation, when a modem' s uplink timeslot arrives, the modem will gather packets from the ingress queue and put them into one big WLAN packet. The WLAN packet is not bigger than the biggest packet that the timeslot allows. Conversely, when the timeslot arrives, if the WLAN packet is not big enough to fill the duration of the fixed timeslot, then one implementation still sends the (smaller) WLAN packet, whereas another implementation sends NULL data. Referring to Fig. 16, a process 1600 depicts a process for receiving encapsulated packets, decapsulating the packets, and delivering the constituent packets. This process 1600 is also referred to as an uplink reception process.

The process 1600 includes an AP receiving an encapsulated packet from a modem over a WLAN interface (1620) . In the implementation of Fig. 10, the AP 1030 receives the encapsulated packet from the modem 1010. The packet is received at the WLAN interface 1075 over the cable network 1040 (such as a coaxial cable network) . The AP decapsulates the received packet to extract the constituent packets that make up the encapsulated packet (1630) . In the implementation of Fig. 10, the WLAN interface 1075 sends the received (encapsulated) packet to the PADM 1076 The PADM 1076 performs decapsulation and provides the constituent Ethernet packets to the bridge 1074. Decapsulation is performed by examining, for example, the total packet number 1520, and the packet flag (for example, packet flag 1550) and packet length (for example, packet length 1560) of each packet descriptor (for example, packet descriptor 1530) . By examining such data, the PADM 1076 is able to determine where each of the constituent packets starts and ends .

In particular, the PADM 1076 examines each constituent packet to ensure that the constituent packet is a complete Ethernet packet. If the constituent Ethernet packet is not complete, then the PADM 1076 retains the incomplete packet and waits until the rest of the Ethernet packet is received (presumably in a subsequent encapsulated packet) . When the rest of the Ethernet packet is received, the PADM 1076 assembles the complete Ethernet packet and forwards the complete Ethernet packet to the bridge 1074.

Referring to Fig. 17, the above implementation of the operation 1630 is depicted in a diagram 1700 for a received encapsulated packet 1710. For simplicity, the received encapsulated packet 1710 is assumed to be the same as the transmitted packet described with reference to Fig. 14. However, it is understood that variations between a transmitted packet and a received packet might occur in practice. The received packet 1710 includes the WLAN header 1440, the EIW header 1430, and the string of constituent Ethernet packets 1420.

As the PADM 1076 processes the received packet 1710, if a constituent Ethernet packet is complete, then the packet (for example, a packet 1720) is provided to the bridge 1074. If a constituent Ethernet packet is incomplete, then the incomplete packet is stored in a waiting queue 1730 (which need not be located in the PADM 1076) until the rest of the packet arrives, The diagram 1700 shows an incomplete packet 1740 being stored in the waiting queue 1730. This may occur, for example, if an Ethernet packet spans two WLAN packets. When the packet is complete, the packet is sent to the bridge 1074. Note that a WLAN packet may include, for example, one complete Ethernet packet and one partial Ethernet packet.

Referring to Fig. 18, to further describe the decapsulation process 1130, a PADM 1750 is depicted that provides an implementation of either of the PADMs 1016 or 1076. The PADM 1750 includes an encapsulator 1760 and a decapsulator 1770. The encapsulator 1760 and the decapsulator 1770 are communicatively coupled to a bridge and a WLAN interface. Given the components of the PADM 1750, the PADM 1750 may, more specifically, be referred to as a packet encapsulation/decapsulation module . In operation, the encapsulator 1760 accepts Ethernet packets from the bridge and encapsulates the Ethernet packets, as described above. The encapsulated data is then provided to the WLAN interface.

In operation, the decapsulator 1770 receives encapsulated data from the WLAN interface. The decapsulator 1770 decapsulates the received data as described above, and provides the decapsulated data to the bridge .

Clearly, other implementations are possible and envisioned. For example, another implementation combines an encapsulator and a decapsulator. Yet another implementation uses a virtual Ethernet interface feature of Linux.

Note that other implementations of an AP or a modem send an encapsulated packet from a WLAN interface directly to a bridge. The bridge determines that the packet is encapsulated and sends the packet to a PADM.

Continuing with the process 1600, the AP determines that the constituent packets are to be sent to a router (1640) . This operation (1640) may be performed, as with many operations, at a different point in the process 1600. In the implementation of Fig. 10, the bridge 1074 determines that the packets are to be sent to the router 1090.

The AP then sends the constituent packets to the router over an Ethernet interface (1650) . In the implementation of Fig. 10, the bridge 1074 sends the constituent packets to the Ethernet interface 1077, which sends the packets to the router 1090 over the Ethernet network 1082.

The router receives (1060) and processes (1070) the packets. Processing may include, for example, sending the packets, or a portion thereof, to a further destination such as a web site with which a host is communicating or attempting to communicate. Further, in implementations in which an encapsulated packet includes Ethernet packets from multiple hosts, the router may send the underlying information to multiple web sites.

Referring to Fig. 19, a process 1800 depicts a process for receiving packets at an AP from a router. The packets are encapsulated, and the encapsulated packets is transmitted from the AP. The transmitted encapsulated packet is intended for receipt by a modem, and the constituent packets are intended for eventual delivery from the modem to one or more hosts. This process 1800 is also referred to as a downlink transmission process. The process 1800 includes a router receiving one or more packets intended for one or more hosts (1820) , and the router sending the received packet (s) to an AP (1830). The router may receive packets from, for example, one or more web sites that are attempting to communicate with one or more hosts. In the implementation of Fig. 10, the router 1090 receives packets from the Internet 1095. The router 1090 then sends the received packets over the Ethernet network 1082 to the Ethernet interface 1077 of the AP 1030. The AP determines that at least one received packet is to be sent over a WLAN interface to the modem (1840) . In the implementation of Fig. 10, the Ethernet interface 1077 routes the received packets (which are Ethernet packets) to the bridge 1074. The bridge 1074 determines that a packet is to be sent over the WLAN interface 1075 to, for example, the modem 1010.

The AP encapsulates multiple packets for transmission to the modem, including the one or more received packets (1850) . Note that the multiple packets are all received from the router, but may have been received at the router from one or more different sources (for example, different web sites) . Further, the encapsulation may include the packet (s) received in operation 1820 and packets received earlier and stored in a queue . Regarding the operation 1850, in the implementation of Fig. 10, the bridge 1074 forwards the received packet (s) to the PADM 1076. The PADM 1076 queues the received packet (s), along with other packets intended for (for example) the modem 1010 and forms an encapsulated WLAN packet for the available downlink timeslot for the modem 1010. The PADM 1076 maintains a separate queue for each modem (also referred to as a station) , including a first queue for the modem 1010 and a second queue for the modem 1020. The encapsulation is as described earlier in describing the PADM 1016 in conjunction with Figs. 11-15.

The AP sends the encapsulated packet to the modem over a cable connection, intended for eventual delivery to one or more hosts (1860) . In the implementation of Fig. 10, the PADM 1076 prepares a WLAN packet for each of the modems 1010 and 1020 in a round-bin manner. The PADM 1076 then supplies the prepared WLAN packets to the WLAN interface 1075 for insertion into the corresponding downlink time-slots in the TDF superframe structure. The WLAN interface 1075 then transmits the WLAN encapsulated packets to the modems 1010 and 1020, using the TDF superframe structure.

Referring to Fig. 20, a process 1900 depicts a process for receiving encapsulated packets, decapsulating the packets, and delivering the constituent packets. This process 1900 is also referred to as a downlink reception process.

The process 1900 includes a modem receiving an encapsulated packet from an AP over a WLAN interface (1920) . In the implementation of Fig. 10, the modem 1010 receives the encapsulated packet at the WLAN interface 1017 over a cable network 1040 (such as a coaxial cable network) .

The modem then decapsulates the received packet to extract the constituent packets that make up the encapsulated packet (1930) . In the implementation of Fig. 10, the PADM 1016 performs decapsulation of the WLAN packet and provides the constituent Ethernet packets to the bridge 1014. The decapsulation may be performed, for example, as described earlier for the PADM 1076 in the discussion of Figs. 16-18.

The modem determines that the constituent packets are to be sent to one or more intended host recipients (1940) . This operation (1940) may be performed, as with many operations, at a different point in the process 1900. For example, the operation 1940 may be performed in conjunction with either of operations 1930 or 1950. In the implementation of Fig. 10, the bridge 1014 determines that the packets are to be sent to the host (s) .

The modem then sends the constituent packets to the host(s) over an Ethernet interface (1950) . In the implementation of Fig. 10, the bridge 1014 sends the constituent packets to the Ethernet interface 1015, which sends the packets to one or more of the hostl 1054 and the host2 1056 over the Ethernet network 1052.

The one or more hosts receive (1960) and process (1970) the packets. Processing may include, for example, a personal computer storing a multi-media file received over the Internet, or a personal digital assistant (PDA) displaying an electronic message (also received over the Internet) for viewing and interaction by a user.

Figs. 21-34 are now described. However, the description of the implementations represented by Figs. 21-34 is not limited to the discussion below.

In order to utilize the mature hardware and software implementation of 802.11 protocol stacks, the concept of transmitting 802.11 frames in the coaxial cable media in different frequency band with WLAN (Wireless Local Area Network) with modified WLAN chipsets has been proposed. Accordingly, a TDF (Time Division Function) protocol was created to replace the conventional 802.11 DCF (distributed coordination function) or PCF (point coordination function) mechanism in MAC (Media Access Control) layer for this application scenario. As mentioned above, this TDF protocol is based on TDMA (Time Division Multiple Access) , which allows multiple users to share the same channel by dividing it into different time slots. The TDF STAs (Stations) transmit in rapid succession for uplink traffic, one after the other, each using their own time slot in a TDF superframe assigned by the TDF AP (Access Point) . For downlink traffic, the STAs share the channels, and select the frames targeting to them by comparing the destination address information in the frames with their interested address. Fig. 5 illustrates the time slots allocation for a typical TDF superframe when there are m (=tdfUplinkTimeSlotNumber) STAs simultaneously to compete for the uplink transmission opportunity. As shown and described with respect to Figure 5, there are a fixed number of time slots per TDF superframe, tdfTotalTimeSlotNumber, which is composed of one (1) Sync time slot which is used to send clock synchronization information from TDF AP to TDF STAs, one (1) contention time slot which is used to send Registration request for uplink 'time slot allocation, tdfUplinkTimeSlotNumber uplink time slots which are used by the registered TDF STAs to send data and some management frames to TDF AP one after another, and tdfDownlinkTimeSlotNumber downlink time slots which are used by the TDF AP to transmit data and some management frames to the STAs. With the exception of the Sync time slot, all other time slots, which are referred to as common time slots, have the same duration whose length is equal to tdfCommonTimeSlotDuration.

The duration value of tdfCommonTimeSlotDuration is defined to allow the transmission of at least one largest 802.11 PLCP (physical layer convergence protocol) protocol data unit (PPDU) in one normal time slot for the highest data rate mode. The duration of Sync time slot, tdfSyncTimeSlotDuration, is shorter than that of common time slot because the clock synchronization frame, which is transmitted from TDF AP to TDF STA in this time slot, is shorter than the 802.11 data frame.

As a result, the duration of one TDF superframe, defined as tdfSuperframeDuration, can be calculated by: tdfSuperframeDuration = tdfSyncTimeSlotDuration + tdfCommonTimeSlotDuration * (tdfTotalTimeSlotNumber - 1)

The relationship between tdfTotalTimeSlotNumber, tdfUplinkTimeSlotNumber and tdfDownlinkTimeSlotNumber satisfies the following equality: tdfTotalTiraeSlotNumber = tdfUplinkTimeSlotNumber + tdfDownlinkTimeSlotNumber + 2

In a practical application scenario which uses WLAN chipsets with decreased frequency band to provide data transmission through CATV access network, there are typically two kinds of applications. One application is to provide Internet access with this solution, so the subscribers must be allocated with guaranteed time slots for constant data rate and QoS (Quality of Service) . The other application is to use this solution to transmit sporadic uplink traffic from subscribers' side to head-end, such as the user controlling messages in VoD (Video on Demand) application in digital TV service .

With the MAC layer mechanism proposed above, the STA registers with an AP to acquire an uplink time slot at first, and then transmit this kind of controlling messages in the allocated time slot per superframe. However, because the traffic for this kind of application is very low, the STA requires a very small fraction of the time slot for data transmission, and even more, it is quite possible there is no traffic to transmit even during several consecutive superframes for TDF STAs which are used to support this kind of application with sporadic traffic. Thus, it will be apparent to those of skill in the art that in certain scenarios it may be quite wasteful to support this second kind of application with the previously created and known pure time division media access method in TDF protocol.

According to other known implementations, during the contention based uplink time slot, TDF STAs which have sporadic uplink traffic to transmit and did not register with the TDF AP for uplink time slot allocation, will send uplink traffic, to TDF AP using the DCF mechanism.

However, due to the intrinsic characteristic of the DCF mechanism, it is possible that one TDF STA will have greater chance to access the channel for uplink traffic transmission than other STAs, if it always uses a smaller contention window to acquire the transmission opportunity. And accordingly, a fair transmission opportunity distribution cannot be achieved among these TDF STAs which use contention based medium access method for uplink traffic.

This disclosure proposes at least two kinds of TDF in order to support data service and sporadic user controlling messages over the cable access network. The first uses both polling and time division medium access, and the second uses a hybrid mechanism for acquisition of uplink channel. Variations and further combinations, such as the use of polling and a contention-based hybrid mechanism, are envisioned and considered a part of this disclosure.

Referring to Figure 21, in order to provide the support to both high data rate services with QoS support and other services with sporadic data traffic and latency tolerance property, a state-of-the-art TDF, which includes both polling and time division medium access mechanisms for uplink channel access is shown.

The proposed TDF with both polling and time division medium access adds one time slot (e.g., a polling slot) to a TDF superframe of timeslots used in previously implemented TDF procedures .

As shown in Figure 21, there are fixed number of timeslots, tdfTotalTimeSlotNumber, per TDF superframe, and the detailed functionality for every kind of time slot contained therein is listed as follows:

> One (1) Sync slot. The Sync time slot, which means synchronization time slot, is used to send clock synchronization information from TDF AP to TDF STAs.

> One (1) Reg. slot. The Reg. slot, (i.e., registration time slot) is used by TDF STAs to send Registration request to TDF AP. In the Registration request frame body, the TDF STA will notify the AP of its operation mode, polling mode or time division mode, for uplink transmission opportunity acquirement .

> One (1) polling time slot. During this time slot, TDF STAs, which have sporadic uplink traffic to transmit and did not register with the TDF AP for uplink time slot allocation, will send uplink traffic to TDF AP using the specific PCF (Point Coordination Function) mechanism described in detail below.

> Downlink time slots. These slots contain tdfDownlinkTimeSlotNumber downlink time slots which are used by TDF AP to transmit data and some management frames to the TDF STAs.

> Time division uplink time slots. These slots contain tdfUplinkTimeSlotNumber uplink time slots which are used by the registered TDF STAs to send data and some management frames to TDF AP with high data rate and QoS support, one after another.

The duration for the synchronization time slot, registration time slot, polling time slot, downlink time slots and time division uplink time slots, are different from each other at most circumstances, based on the requirements of the particular practical application. However, every uplink time slot in the tdfUplinkTimeSlotNumber time division time slots, which are referred to as common time slot, has the same duration length equal to tdfCommonTimeSlotDuration.

As a result, the duration of one TDF superframe, defined as tdfSuperframeDuration, can be calculated by tdfSuperframeDuration = tdfSyncTimeSlotDuration

+ tdfRegTimeSlotDuration + tdfPollingTimeSlotDuration + tdfCommonTimeSlotDuration * (tdfTotalTimeSlotNumber - 3)

The relationship between tdfTotalTimeSlotNumber, tdfUplinkTimeSlotNumber and tdfDownlinkTimeSlotNumber satisfies the following equality: tdfTotalTimeSlotNumber = tdfUplinkTimeSlotNumber + tdfDownlinkTimeSlotNumber + 3.

Enhanced PCF procedure during polling time slot

For STAs in this TDF with both polling and time division medium access mechanism, various implementations include two operation modes: one is polling mode; and the other is time division mode.

The basic medium access method for STAs operating in polling mode for uplink traffic transmission is PCF. However, due to the special environment for data transmission over fixed line, several improvements to this classical PCF mechanism have been made.

Fundamental access The PCF mechanism in the polling time slot provides contention-free frame transfer. Referring to Figure 23, the PC (Point Coordinator) 2302 resides in the TDF AP 2300. The form of polling mode support provided by the AP 2300 is identified in the Capability Information field of Beacon frames, which are sent from the APs. The TDF STAs 2304 which require polling based medium access should be able to respond to a contention- free poll (CF-PoIl) received from an AP 2300, and so is referred to as being CF-Pollable. When polled by the PC 2302, a CF-Pollable STA shall transmit only one MPDU (MAC Protocol Data Unit) , which shall be sent to the AP and does not require the MPDU to be acknowledged by the AP. An AP shall never poll the STAs that are not in the polling list in this AP.

Frames sent by an AP or STA during the polling time slot shall use the appropriate frame types based upon the following usage rules:

1 — CF-PoIl, shall only be sent to CF-Pollable STAs by an AP. In this frame, the AP is not sending data to the addressed recipient, but the addressed recipient is the next STA to be permitted to transmit during this polling time slot; and

2 — Data and Null frame may be sent by any CF-Pollable STA.

The AP gains control of the medium at the beginning of the polling time slot and attempts to maintain control for the entire polling time slot. It does not require the start and end of the polling time slot to be signaled by the transmission of a Beacon and CF-End respectively by the AP, as required in the classical PCF protocol.

The AP shall send a CF-PoIl to at least one STA during each polling time slot when there are entries in the polling list. During each polling time slot, the AP shall issue polls to a subset of the STAs on the polling list in order from the head to the tail.

Referring to Figures 24 and 25, once each polling time slot begins, the AP shall transmit (2506) a CF-PoIl frame to one STA in the polling list. If there is no entry in the polling list (2502) , the AP shall immediately transmit downlink traffic (2504) during this polling time slot, until the end of downlink time slots.

After receiving data or Null frame (2508) from the specific CF-Pollable STA, or getting no response to the CF- PoIl from the specific STA within a predefined period following a transmission from the AP, then the AP shall resume control and may transmit its next CF-PoIl frame to the next entry in the polling list, unless there is insufficient time remained during this current polling time slot. If at this time, it has reached the last entry in the polling list, then the AP will try to send CF-PoIl frame to the STA, starting from the first one in the polling list, next time. The AP shall not issue a CF-PoIl frame if insufficient time remaining in the current polling time slot (2510) to permit the polled STA to transmit a data frame containing a minimum length MPDU. Instead, the AP will start to issue a CF-PoIl frame to the next entry in the already polled STA in the polling list, or the first entry in the polling list if the already polled STA is the last entry in the list, at the very beginning of polling time slot during the next superframe .

Referring Figure 24, all CF-Pollable STAs in polling mode associated with this AP should not transmit any uplink traffic unless it is polled by the AP during this polling time slot. A CF-Pollable STA in polling mode shall always respond to a CF-PoIl directed to its MAC address and received without error. It shall transmit one data frame immediately after receiving the CF-PoIl. If the STA has no frame to send when polled, the response shall be a Null frame. A polled CF-Pollable STA with insufficient time before the end of the polling time slot to send its queued data frame shall respond by transmitting a Null frame.

Polling list maintenance

The AP shall maintain a "polling list" for use in selecting STAs that are eligible to receive CF-Polls during the polling time slot, and to force the polling of CF-Pollable STAs. The polling list may be used to control the use of CF- PoIl types for transmission of data frames being sent to CF- Pollable STAs by the AP.

Once an AP receives a Registration request frame from a STA in which the STA requires access to the channel using the polling mechanism, and the AP decides to authorize the STA this kind of transmission mechanism based on the set policy in the AP, the AP shall add one entry to the end of the polling list, which includes the STA' s MAC address and data rate. On the other hand, once an AP receives an Unregistration frame from a STA in which the STA indicates it will not access the channel using the polling mechanism, the AP shall delete the corresponding entry for this STA in the polling list. If a STA desires to change from the time division mode to polling mode, that STA shall notify the AP by sending an Unregistration to quit the time division mode, and then sending a Registration request with a polling mode indication to the AP.

Referring to Figure 22, to enjoy the flexibility provided by the DCF and the fairness provided by PCF, a hybrid medium access mechanism for uplink traffic, which will utilize both DCF and PCF for STAs to gain transmission opportunity for sporadic traffic, and dedicated time slot for STAs to transmit high data rate traffic, is also described. The detailed time slot allocation for this enhanced TDF superframe is illustrated in Figure 22.

As shown, there are fixed tdfTotalTimeSlotNumber timeslots per TDF superframe, and the detailed functionality for every kind of time slot contained therein is listed as follows:

> One (1) Sync slot. The Sync time slot, which means synchronization time slot, is used to send clock synchronization information from TDF AP to TDF STAs.

> One (1) contention based uplink slot. During this slot, TDF STAs may send Registration request to TDF AP. In the

Registration request frame body, the TDF STA will notify the AP its operation mode, polling, contention based or time division mode, for uplink transmission opportunity acquirement. Meanwhile, TDF STAs, which have sporadic uplink traffic to transmit and did not register with the TDF AP for uplink time slot allocation, will send uplink traffic to the TDF AP using the specific DCF mechanism.

> One (1) polling time slot. During this time slot, TDF STAs which have sporadic uplink traffic to transmit and did not register with the TDF AP for uplink time slot allocation, will send uplink traffic, to the TDF AP using the specific PCF mechanism described previously. Generally speaking the TDF STA can notify the TDF AP of its operation mode, (i.e., either DCF or PCF) by setting a corresponding flag in the association request frame sent to the TDF AP by the TDF STA.

> Downlink time slots. These slots contain tdfDownlinkTimeSlotNumber downlink time slots which are used by TDF AP to transmit data and some management frames to the TDF STAs . > Time division uplink time slots. These slots contain tdfUplinkTimeSlotNumber uplink time slots which are used by the registered TDF STAs to send data and some management frames to TDF AP with high data rate and QoS support, one after another.

The duration for synchronization time slot, contention base time slot, polling time slot, downlink time slots and time division uplink time slots, are different with each other at most circumstances, based on the requirements in practical application.

As a result, the duration of one TDF superframe, defined as tdfSuperframeDuration, can be calculated by tdfSuperframeDuration = tdfSyncTimeSlotDuration

+ tdfContentionTimeSlotDuration + tdfPollingTimeSlotDuration + tdfCommonTimeSlotDuration

* (tdfTotalTimeSlotNumber - 3) .

The relationship between tdfTotalTimeSlotNumber, tdfUplinkTimeSlotNumber and tdfDownlinkTimeSlotNumber satisfies the following equality: tdfTotalTimeSlotNumber = tdfUplinkTimeSlotNumber + tdfDownlinkTimeSlotNumber + 3.

The present principles propose a TDF, which uses both contention based and time division medium access for acquisition of the uplink channel, in order to support data service and sporadic user controlling messages over cable access network. To provide the support to both high data rate services with QoS support and other services with sporadic data traffic and latency tolerance property, a state-of-the-art TDF, which includes both contention based and time division medium access mechanisms for uplink channel access, is proposed. The functional description for this TDF protocol with hybrid medium access method is described in detail as follows.

Access method The TDF with both contention based and time division medium access of the present principles adds one time slot (e.g., a Registration slot) to previously disclosed TDF procedures. The detailed time slot allocation for this enhanced TDF superframe is illustrated in Figure 26.

As shown in Figure 26, there are a fixed number of time slots tdfTotalTimeSlotNumber per TDF superframe, and the detailed functionality for every kind of time slot contained therein can be listed as follows: - One (1) Sync slot. The Sync time slot, which means synchronization time slot, is used to send clock synchronization information from TDF AP to TDF STAs.

-One (1) Reg slot. The Reg slot, (i.e., the registration time slot) is comparable to the contention time slot in the superframe structure described in Figure 5, is used by TDF STA to send Registration requests to TDF AP for uplink time slot allocation. - One (1) contention based uplink time slot.

During this time slot, the TDF STAs which have sporadic uplink traffic to transmit and did not register with the TDF AP for uplink time slot allocation, will send the uplink traffic, to TDF AP using the specific DCF mechanism described in detail below.

- Time division uplink time slots. These slots contain tdfUplinkTimeSlotNumber uplink time slots which are used by the registered TDF STAs to send data and some management frames to TDF AP with high data rate and QoS support, one after another.

- Downlink time slots. These slots contain tdfDownlinkTimeSlotNumber downlink time slots which are used by TDF AP to transmit data and some management frames to the TDF STAs .

In one implementation, the Reg slot and contention based uplink time slot can be combined into one hybrid time slot to improve system performance. This improvement will be due to the fact that both slots use a contention based backoff method for channel access and in most circumstances there may be little traffic during the Reg slot. Further, the CWmin and CWmax of the contention window for Registration request frames can be defined to be smaller than CWmin and CWmax of the contention window for data frames respectively, in order to give higher priority for transmission of Registration request frames than that of data frames . Those of skill in the art will recognize that the "Contention window" is used in the 802.11 standard, and represents how many mini-slot, typically 9 μs, the STA will wait before trying to access the wireless medium and then determine if the media is available for use to transmit data. By way of example, the exact contention window number is initially determined by choosing a random backoff number between 0 and CWmin. Every time the backoff period expires, indicating the channel is still busy, the STA will randomly choose another backoff period between 0 and a number in [CWmin, CWmax] in an increasing manner, until at last backoff period between 0 and CWmax is chosen.

By defining CWmin and CWmax of the contention window for Registration request frames to be smaller than CWmin and CWmax of the contention window for data frames respectively, i.e.

(CWmin for Registration) < (CWmin for data frames) and (CWmax for Registration) < (CWmin for data frames) , a higher priority for transmission of registrations request frames over that of data frames is ensured. As explained below, this higher priority is due to the fewer number of backoff periods available during the smaller contention window.

The duration for the synchronization time slot, registration time slot, contention based uplink time slot, time division uplink time slots and downlink time slots, are different for each other under most circumstances, based on the requirements during practical applications. However, every uplink time slot in the tdfUplinkTimeSlotNumber time division time slots, which are named as common time slot, has same duration whose length equals with tdfCommonTimeSlotDuration.

As a result, the duration of one TDF superframe, defined as tdfSuperframeDuration, can be calculated by: tdfSuperframeDuration = tdfSyncTimeSlotDuration

+ tdfRegTimeSlotDuration + tdfContentionTimeSlotDuration

+ tdfCommonTimeSlotDuration * (tdfTotalTimeSlotNumber - 3) .

The relationship between tdfTotalTimeSlotNumber, tdfUplinkTimeSlotNumber and tdfDownlinkTimeSlotNumber satisfies the following equality: tdfTotalTimeSlotNumber = tdfUplinkTimeSlotNumber

+ tdfDownlinkTimeSlotNumber + 3. Furthermore, the number of allocated uplink time slots for the TDF STAs in a TDF superframe may change from 0 to tdfMaximumUplinkTimeSlotNumber. Accordingly, the available duration for downlink time slots in a TDF superframe may change from:

(tdfCommonTimeSlotDuration * (tdfTotalTimeSlotNumber - 3)) to tdfCommonTimeSlotDuration * (tdfTotalTimeSlotNumber - 3 - tdfMaximumUplinkTimeSlotNumber) ) . Every time when there is one TDF STA which asks for uplink time slots, the TDF AP will deduce one or more common time slots from the available downlink time slots, and then allocate these time slots to the TDF STA, as long as the uplink time slots number will not exceed tdfMaximumUplinkTimeSlotNumber after that.

Furthermore, although the duration for the downlink time slots equals with (tdfCommonTimeSlotDuration * tdfDownlinkTimeSlotNumber) , it is not necessary to have guarding time between these common time slots' boundary, because these downlink time slots are continuous and the traffic is sent from one standalone AP. In this way, the efficiency and channel utilization rate will be highly improved for downlink transmission in this protocol.

Enhanced DCF procedure for contention based uplink time slot

For STAs in this TDF with both contention based and time division medium access mechanism, several implementations have two operation modes: one is contention based mode, another is time division mode.

The basic medium access method for STAs operating in contention based mode for uplink traffic transmission is the DCF defined in 802.11 specifications that allow for automatic medium sharing through the use of CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) and a random backoff time following a busy medium condition. However, due to the special environment for data transmission over fixed line, several improvements to this classical DCF mechanism have been made .

Random backoff procedure A TDF STA desiring to initiate transfer of frames shall invoke the carrier-sense mechanism (physical carrier sense at most circumstances) to determine the busy/idle state of the medium. If the medium is busy, the STA shall defer until the medium is determined to be idle without interruption for a period of defined time. After this medium idle time, the STA shall then generate a random backoff period for an additional deferral time before transmitting, unless the backoff timer already contains a nonzero value, in which case the selection of a random number is not needed and not performed. This process minimizes collisions during contention between multiple STAs that have been deferring to the same event.

Backoff Time = Random () * aSlotTime

Where

Random () = Pseudorandom integer drawn from a uniform distribution over the interval [0,CW], where CW is an integer within the range of values of aCWmin and aCWmax, aCWmin <= CW <= aCWmax.

The set of CW values shall be sequentially ascending integer powers of 2, minus 1, beginning with an application- specific aCWmin value, and continuing up to and including an application-specific aCWmax value. More specifically, for most of this protocol's application environments, the maximum number of STAs in contention based mode, which is tdfMaximumContentionStationNumber, is known in advance, and can be notified to TDF STAs by manually configuration and/or management frames broadcasted from TDF AP, so the aCWmax value can be set to tdfMaximumContentionStationNumber or multiple of tdfMaximumContentionStationNumber. Thus, the STA can access the physical medium after a relatively short backoff time, when compared with the condition where the aCWmax number value is blindly set.

By reducing the contention window size for the registration frames, the number of backoff periods available will be less than the number of backoff periods available for data frames, resulting in the registration frames having higher priority.

Acknowledgment procedure For TDF STA operating in time division mode, the frames originating from the STA are exchanged in wired environment instead of in the air during the uplink time slots solely allocated for this specific STA, consequently they are transmitted in the contention-free manner with very good signal quality. As a result, it is unnecessary to define Acknowledgments (ACKs) frames to ensure the reliability of delivery of MAC frames.

However, for TDF STA operating in contention based mode, because of the difference between wired environment and wireless channels, the physical carrier sense mechanism does not work very well in fixed line, so the hidden station problem will cause many collisions among different TDF STAs in JO

contention mode. As a way to combat against this kind of malfunction, the present principles propose the use of a positive acknowledgement mechanism.

Accordingly, there are two kinds of acknowledgments available to deploy:

1. Immediate positive acknowledgement from TDF AP as soon as this AP receives an uplink frame originating from a TDF STA in contention mode, and as a result, retransmission is scheduled by the TDF STA if no ACK is received.

2. Block ACK mechanism which improves channel efficiency by aggregating several acknowledgments into one frame. There are two types of Block Ack mechanisms: immediate and delayed.

Immediate Block Ack is sent by the TDF AP immediately after receiving several uplink frames from a TDF STA in contention mode, and is suitable for high bandwidth and low latency traffic.

Delayed Block ACK is sent by TDF AP at the very beginning of downlink time slots within the same superframe with the contention based uplink time slot, in response to several successfully received uplink frames sent from TDF STAs during the specific contention based time slot. It is suitable for application that tolerates moderate latency and will be used in most circumstances in this TDF protocol with both contention based and time division media access control. The Block ACK frames may be a unicast frame to one specific TDF STA in contention mode, in order to notify it of the successful reception of uplink frames from it, and also may be a broadcast or multicast frame, in order to notify a number of TDF STAs in contention mode of the successful reception of uplink frames from these STAs.

Operation mode conversion procedure

Once a TDF STA is started up (e.g., upon initialization), it enters the contention based mode by default. Then dependent on its application requirements, configuration and/or service level agreements with service providers, it may enter the time division modes after sending registration frames to the TDF AP and receiving the registration response with access admission.

The conversion from contention based mode to time division mode is illustrated in Figure 27. As shown, when in contention based mode 2710, a determination is made (2712) whether there is a need to enter time division mode. When the answer is yes, a subsequent determination is made (2714) as to whether a positive response has been received after the TDF STA has sent a registration request to the TDF AP. If a positive response has been received, time division mode is entered 2716. If either determination 2712 or 2714 results in a negative, the system remains in Contention based mode 2710.

In contrast to the implementation shown in Figure 27, a TDF STA can enter contention based mode from time division mode during its operation. This concept is illustrated in Figure 28. As shown, when in time division mode 2802, a determination is made (2804) as to whether there is a need to enter contention based mode. If yes, a un-registration request is sent (2806) , and contention based mode is entered 2808. In the event that there is no need to enter contention based mode (2804), the system remains in time division mode 2802. Note that similar processes are applicable to the polling implementations. For example, implementations may switch between polling mode and time division mode as needed.

As described above, in order to provide a cost-effective bi-directional data transmission solution over the existing coaxial cable access network, a method, which utilizes mature commodity WiFi chipsets with external frequency conversion circuit for frames delivery, has been proposed. The system which employs this method is called an ADoC (Asymmetric Data over Coaxial Cable) system, in which we must deploy TDF (Time Division Function) protocol compliant ADoC Access Point (AP) and stations (STAs) in the cable access network. As used herein, the terms "ADoC system" and "TDF system" are interchangeable. The AP and STAs are connected via splitters in the hierarchy tree structure (See Figure 1) . In this way, the user at home can access the remote IP core network via the cable access network. The detailed network topology is illustrated in Figure 1. In this typical infrastructure access network architecture, there is a TDF protocol compliant ADoC (TDF) Access point (AP) which has one Ethernet Interface, by which the AP connects with the IP core network, and one coaxial cable interface, by which the AP connects with the cable access network. On the other end of the access network, there are TDF protocol compliant ADoC (TDF) STAs, which connect with the cable access network via the coaxial cable interface, and with the residential LAN (Local Area Network) via a wireless interface, for example, a WLAN (Wireless Local Area Network) interface, or a wired interface, for instance, an Ethernet interface .

Referring to Figure 29, an inventive implementation for the hardware implementation of an ADoC STA 2900 is to integrate two devices, an ADoC device 2903 and a WLAN device 2904, into a colligated STA. The ADoC device 2903 will be connected with a coaxial cable interface 2906 to support bidirectional data communication in cable network, while the WLAN device 2904 will be connected with an antenna 2908 to support bi-directional data communication in WLAN network. The STA 2900 will swap the data frames between ADoC device 2903 and WLAN device 2904 if needed, in order to enable PCs in the WLAN network to access the Internet via the ADoC STA.

The STA architecture presented in Figure 29 requires two standalone devices for channel encoder /decoder and data processing to provide Internet access functionality for Personal computers in the home WLAN. The present principles provide a solution which utilizes one standalone dual mode device, and which is capable of switching between ADoC mode and WLAN mode periodically, to provide the same access functionality for local networks.

The dual mode ADoC device of the present principles can support both ADoC mode and WLAN mode and switch between these two modes periodically. In ADoC mode, the dual mode device operates as an ADoC STA; while in WLAN mode, it operates as a WLAN AP.

By using the single dual mode device solution of the present principles, instead of two devices in the classical solution shown in Figure 29, ADoC STAs embedded with this dual mode ADoC device can provide Internet access functionality for local networks. As a result, the manufacturing cost for an ADoC STA with Internet access support via the cable access network can be decreased by almost half the original cost, in comparison with the classical solution of the two devices shown in Figure 29.

In order to realize the dual mode device 2902 of the present principles, the standard ADoC device 2903 is modified and evolved based on a mature WLAN device. It is different from the WLAN device 2904 mainly in two aspects: 1) In physical implementation aspect, its RF operates in ADoC frequency band (about 1 GHz) instead of standard 802.11 frequency band (about 2.4 GHz); and 2) In the MAC (Media Access Control) layer, it does not utilize the conventional 802.11 DCF (Distributed Coordination Function) or PCF (Point Coordination Function) mechanism to exchange MAC frames. Instead, it uses TDF protocol, which is based on Time Division Multiple Access (TDMA) method, to transmit MAC frames.

As shown in Figure 30, the dual mode ADoC device 2902 will be connected with a coaxial cable interface 2906 for the interconnection with cable access network, and at the same time, be connected with an antenna 2908 to support bidirectional data communication in WLAN network. The ADoC STA 2900 will swap the data frames received during these two modes from this dual mode ADoC device 2902 if needed.

Hardware architecture of the dual mode ADoC device

According to one hardware implementation of the dual mode ADoC device 2902 shown in Figure 31, a switch 3102 is provided which is a circuit configured to switch between the WLAN RF circuit 3104 and ADoC RF circuit 3106. The switch 3102 can be controlled by the MAC layer software. This implementation requires that the WLAN chipset be modified and the switch 3102 is added to the modified chipset.

According to another hardware implementation shown in Figure 32, the location of the switch 3102 can be changed in terms of adjacency with the device's MAC baseband part 3100. In this implementation, the converter 3108 decreases the WLAN frequency band, which is the output of the WLAN RF 3104 and is about 2.4 GHz, to the ADoC spectrum, which is about 1 GHz and can reach a relative long distance in the coaxial cable. Note that the MAC baseband part 3100 may be characterized as a communication device configured to enable a user device to communicate with the dual-mode ADoC device 2902.

In contrast to the implementation of Figure 31, the implementation of Figure 32 is external to the existing WLAN chipset, and as such, does not require modifying the WLAN chipset .

MAC layer procedure of the dual mode ADoC device

In a dual mode ADoC device 2902, the basic access method is TDF protocol, which is the same with the MAC layer protocol in the ADoC device 2903.

As shown Figure 34, there are fixed tdfTotalTimeSlotNumber time slots per TDF superframe, which is composed of 1 Sync time slot which is used to send clock synchronization information from ADoC AP to ADoC STAs, 1 contention time slot which is used to send Registration request for uplink time slot allocation, tdfUplinkTimeSlotNumber uplink time slots which are used by the registered ADoC STAs to send data and some management frames to ADoC AP one after another, and tdfDownlinkTimeSlotNumber downlink time slots which are used by ADoC AP to transmit data and some management frames to STAs,

With this TDF protocol, the dual mode ADoC device 2902 in STA mode will only be active during the Sync slot, contention time slot, the allocated uplink time slot (for instance, time slot k) and the downlink time slots. In the remaining time slots {i.e., from time slot 2 to time slot k; and from time slot k to time slot m} , the dual mode ADoC device in STA mode will be inactive in the ADoC interface part, and as a result, can switch to WLAN AP mode, if there is a switch available to be controlled to change the operating RF from ADoC frequency band to WLAN frequency band. The detailed MAC layer procedure in a dual mode ADoC device is as follows:

1. Once an ADoC STA was started and successfully allocated an uplink time slot, for example, time slot k, for uplink traffic transmission, the dual mode device will compute if k > (m+2)/2. If k > (m+2)/2, it means the duration of [time slot 2, time slot k) , indicated by T[time slot 2/ time slot k) I is at least equal to the duration of (time slot k, time slot m] , indicated by T(time slot k/ time siot m] • As a result, the dual mode ADoC device will choose to operate in WLAN mode during the [time slot 2, time slot k) period; On the other hand, if k < (m+2)/2, it means T[time slot 2, time slot k) is shorter than T(time slot k/ time slot m] • Consequently, the dual mode ADoC device will choose to operate in WLAN mode during the (time slot k, time slot m] period.

Note that the determination of whether the period [slot 2, slot k) > the period (slot k, slot m] produces the criteria (k-2)>(m-k), which in turn produces the criteria k>(m+2)/2. Further, in the implementation described the WLAN mode is selected for the longer period. Other implementations, however, operate in WLAN mode during the shorter period, or change between modes multiple times in a superframe .

2. In the case that the dual mode ADoC device decides to operate in WLAN mode during the [time slot 2, time slot k) period, for other time slots in a TDF superframe, the dual mode ADoC device will operate in ADoC mode as ADOC STA and act in the manner in accordance with the standard ADoC TDF protocol. So, when the dual mode ADoC device enters the time slot 2 in ADoC mode, it will configure the RF switch 3102 to change the operating frequency to WLAN spectrum, and acts as a WLAN AP. Then this dual mode STA can communicate with WLAN STAs in the residential WLAN network in accordance with the standard WLAN procedure.

As time goes on and is approaching the time slot k, and there is no time left for at least one WLAN frame exchange before the beginning of time slot k, the dual mode device 2902 will send CTS (Clear To Send) signal to all STAs in the residential WLAN. The Duration field in the CTS frame will be equal to the duration from the time slot k in this superframe to the time slot 2 in the next superframe. Upon receiving the CTS message all STAs will update their NAV and refrain from accessing the WLAN medium for the duration reported by the CTS message . In this way, the dual mode device will make all STAs keep silent for the period from the time slot k in this superframe to the time slot 2 in the next superframe, by pretending there is another entity to reserve the WLAN medium for the duration. After that, the device will control the switch to change the operation spectrum to back to the ADoC frequency band and operate in accordance with the TDF procedure .

When it is time for the dual mode device 2902 to enter the time slot 2 in the next superframe, the device 2902 will repeat the same mode switch procedure and the STAs in the residential WLAN will also start to use this available infrastructure WLAN for communication again because the silence duration, indicated by the CTS, expires at the same time .

In contrast, for the case where the dual mode ADoC device decides to operate in WLAN mode during the (time slot k, time slot m] period, for other time slots in a TDF superframe, the dual mode ADoC device will operate in ADoC mode as a STA. When the dual mode ADoC device 2902 enters the time slot (k+1) in ADoC mode, it will configure the switch 3102 to change the operating frequency to WLAN spectrum, and acts as an AP. Once it is passing the time slot (m-1) as time goes on, the dual mode device will try to send the CTS signal during the time slot m, with the Duration field being equal to the duration from the beginning of the downlink time slots in this superframe to the time slot (k+1) in the next superframe. After that, the dual mode device 2902 will control the switch 2002 to change the operation spectrum to ADoC frequency band and operate in accordance with the ADoC TDF procedure. Thus, when the dual mode device enters the time slot (k+1) in the next superframe, it will perform the same mode switch procedure again, as described before.

According to one implementation, the dual mode device 2902 of an implementation of the present principles is integrated into a modem (e.g., 1010, 1020, etc.) from Figure 10. Figure 33 shows an example of such implementation. As such, when the dual mode device 2902 is operating or performing standard WLAN communication (i.e., when operating in the appropriate time period) , the device allows the user PCs to connect to the internet. In this implementation, the PC user would request an internet address (e.g., a webpage) by sending a request for the internet address to a modem over the wireless medium through a WLAN interface, and 2) the modem relays the request over the cable network to the ADoC AP via the ADoC interface, then to the router, then to the internet. In this implementation, the dual mode device 2902 includes an ADoC Interface or device 1018 rather than an Ethernet interface .

When the modem's dual mode device operates in WLAN (i.e. wireless mode) , the device acts as a WLAN AP, and the Personal computer acts as WLAN Station, where the dual mode device receives the request from the Personal computer via the wireless link between the modem and Personal computer. The dual mode device relays the received request to the bridge, and the bridge determines if the dual mode device needs to send the request out over the cable via the ADoC interface in the dual mode device, or send the request to other PCs in the residential network, based on the destination address information in IP packets for this request. The bridge then sends the request back down to the dual mode device.

In order for the request to establish an external connection, the dual-mode device holds that request until the dual mode device enters ADoC mode (i.e., wired mode), at which time the dual mode device acts as an ADoC station and sends out the request over the wired network to the ADoC AP, via the ADoC interface.

In order for the request to establish an internal connection with other PCs in the residential network, the dual mode device holds that request until the dual mode device enters the WLAN mode (i.e., wireless mode), at which time it acts as a WLAN AP and sends out the request over the wireless medium to the destination PC via the WLAN interface.

When the dual mode device receives any response from the associated ADoC AP in the cable network, or other PCs in the local network, the reverse process will be performed.

As is clear from the foregoing discussion, in at least some implementations common circuitry or software (for example) may be used to perform much of the processing associated with both the WLAN mode and the ADoC mode. For example, the reception and depacketizing of data from both modes, as well as converting between the two modes may be performed by a common unit. Various applications potentially requiring such conversion include (1) a modem receiving a WLAN mode input from a computer (such as a request for Internet access) and sending the input out using the ADoC mode, and (2) a modem receiving requested Internet data in the ADoC mode and sending the data to a computer using the WLAN mode. These scenarios will typically involve a conversion between different protocols.

Various implementations of a dual-mode device use a communication unit to enable communication in one or more modes. A communication unit may include, for example, dual mode ADoC device 2902, or portions thereof such as, for example, MAC baseband 3100, WLAN RF 3104, and ADoC RF 3106.

Note that a modem may include not only a dual-mode device as described above, but may also include interfaces to enable communication across other networks (in addition to WLAN and ADoC) . Such other networks may include, for example, an Ethernet network. Accordingly, a modem may include, for example, dual-mode device 2902 enabling communication across WLAN and ADoC networks, and Ethernet interface 1015.

Various implementations access data (for example) in one form or another. The term "accessing" is used as a broad term that includes, for example, obtaining, retrieving, receiving, manipulating, or processing in some manner. Accordingly, a description of accessing data (for example) is a broad description of possible implementations.

Features and aspects of described implementations may be applied to various applications. Applications include, for example, individuals using host devices in their homes to communicate with the Internet using an Ethernet-over-cable communication framework, as described above. However, the features and aspects herein described may be adapted for other application areas and, accordingly, other applications are possible and envisioned. For example, users may be located outside of their homes, such as, for example, in public spaces or at their jobs. Additionally, protocols and communication media other than Ethernet and cable may be used. For example, data may be sent and received over (and using protocols associated with) fiber optic cables, universal serial bus (USB) cables, small computer system interface (SCSI) cables, telephone lines, digital subscriber line/loop (DSL) lines, satellite connections, line-of-sight connections, and cellular connections .

The implementations described herein may be implemented in, for example, a method or process, an apparatus, or a software program. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method) , the implementation of features discussed may also be implemented in other forms (for example, an apparatus or program) . An apparatus may be implemented in, for example, appropriate hardware, software, and firmware. The methods may be implemented in, for example, an apparatus such as, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processing devices also include communication devices, such as, for example, computers, cell phones, portable/personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end-users.

Implementations of the various processes and features described herein may be embodied in a variety of different equipment or applications, particularly, for example, equipment or applications associated with data transmission and reception. Examples of equipment include video coders, video decoders, video codecs, web servers, set-top boxes, laptops, personal computers, and other communication devices. As should be clear, the equipment may be mobile and even installed in a mobile vehicle.

Additionally, the methods may be implemented by instructions being performed by a processor, and such instructions may be stored on a processor-readable medium such OO

as, for example, an integrated circuit, a software carrier or other storage device such as, for example, a hard disk, a compact diskette, a random access memory ("RAM"), or a readonly memory ("ROM") . The instructions may form an application program tangibly embodied on a processor-readable medium. As should be clear, a processor may include a processor-readable medium having, for example, instructions for carrying out a process .

Regarding storage devices, note that a variety of devices throughout the described implementations typically include one or more storage devices. For example, although not explicitly indicated, the modems 1010 and 1020, and the AP 1030 (as well as a variety of other elements) typically include one or more storage units for storing data. Storage may be, for example, electronic, magnetic, or optical.

As will be evident from the foregoing disclosure, implementations may also produce a signal formatted to carry information that may be, for example, stored or transmitted. The information may include, for example, instructions for performing a method, or data produced by one of the described implementations. Such a signal may be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal. The formatting may include, for example, encoding a data stream, packetizing the encoded stream according to any of a variety of frame structures, and modulating a carrier with the packetized stream. The information that the signal carries may be, for example, analog or digital information. The signal may be transmitted over a variety of different wired or wireless links, as is known.

Claims

CLAIMSWhat is claimed is:
1. An apparatus comprising: a communication unit (3100, 3104, 3106) for communicating over multiple media including a wireless medium and a wired medium, the communication unit being operable (1) in a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) in a wired mode for communicating over the wired medium using a variation of the wireless protocol; and a switch (3102) to switch the communication unit between the wireless mode and the wired mode.
2. The apparatus of claim 1 wherein said communication unit comprises : a communication device (3100) connected to the switch and configured to enable a user device to communicate with the communication unit; a wireless local area network (WLAN) device (3104) connected to the switch, the WLAN device being configured to connect to a wireless network via an antenna; a wired network device (3106) connected to the switch, the wired network device configured to connect to a wired network.
3. The apparatus of claim 2 wherein the wired network device is configured to connect to a coaxial cable network.
4. The apparatus of claim 1 wherein the variation of the wireless protocol in the wired mode comprises a time division access mechanism.
5. The apparatus of claim 1 wherein the variation of the wireless protocol in the wired mode comprises a WLAN packet structure .
6. The apparatus of claim 4 wherein the variation in the wireless protocol in the wired mode is communicated during at least one allocated time slot in a time division function (TDF) superframe of time slots.
7. The apparatus of claim 1 wherein said communication unit comprises : a wireless local area network (WLAN) device connected to the switch; a WLAN antenna connected to the switch; a communication device connected to the WLAN device; and a converter connected to the switch and configured to be connected to a wired network and to convert a wireless-mode frequency band to a wired-mode frequency band.
8. The apparatus of claim 1 wherein the wireless mode is entered during one of two time periods in a TDF superframe of time slots.
9. The apparatus of claim 8 wherein the wireless mode is entered during a selected longer one of the two time periods.
10. The apparatus of claim 9 wherein: the TDF superframe of time slots further comprises a plurality of uplink time slots, and the two time periods are within the plurality of uplink time slots .
11. The apparatus of claim 1 wherein the apparatus is part of a TDF station.
12. The apparatus of claim 1 wherein the communication unit is further configured to use a frame structure for communication, the frame structure supporting at least two communication modes, the communication modes including a time division mode in which a slot in the frame structure is reserved for a device and a contention-based mode in which a contention slot in the frame structure is used by multiple devices for data communication.
13. The apparatus of claim 12 wherein the apparatus is part of a TDF station configured to use the frame structure by sending data, in the contention slot during the contention-based mode, from the TDF station to a TDF access point.
14. The apparatus of claim 1 wherein the communication unit is further configured to use a frame structure for communication, the frame structure supporting at least two communication modes, the communication modes including a time division mode in which a slot in the frame structure is reserved for a device and a polling mode in which a polling slot in the frame structure is used by multiple devices for data communication.
15. The apparatus of claim 14 wherein the frame structure supports a third communication mode that is a contention-based mode in which a contention slot in the frame structure is used by multiple devices for data communication.
16. The apparatus of claim 1 wherein the communication unit is further configured for: receiving a packet from a first source, the packet from the first source having a particular format; receiving a packet from a second source, the packet from the second source having the particular format; and encapsulating the packet from the first source and the packet from the second source into an encapsulated packet having a different format.
17. The apparatus of claim 16 wherein: the particular format comprises an Ethernet format, the different format comprises a WLAN format adapted for wireless transmission, the method further comprises transmitting the encapsulated packet over a coaxial cable, transmitting the encapsulated packet comprises transmitting the encapsulated packet
(a) in a slot of a time-division multiplexing scheme, and
(b) according to a frequency-division multiplexing scheme on a signal carrying television data, the frequency-division multiplexing scheme providing that the encapsulated packet be transmitted in a frequency range for the encapsulated data and that the television data be transmitted in a different frequency range .
18. A method comprising: communicating over multiple media including a wireless medium and a wired medium, the communicating using one or more of (1) a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) a wired mode for communicating over the wired medium using a variation of the wireless protocol; and switching between the wireless mode and the wired mode .
19. The method of claim 18 wherein: communicating comprises receiving a communication in a particular one of the wireless mode or the wired mode, switching comprises switching from the particular one of the two modes of operation to the other of the two modes of operation, and communicating further comprises (1) converting the received communication from the protocol associated with the particular one of the two modes of operation into the protocol associated with the other of the two modes of operation, and (2) transmitting the received communication in the other of the two modes of operation.
20. The method of claim 18 wherein the wired mode of operation is part of a time division function communication system.
21. An apparatus comprising: means (3100, 3104, 3106) for communicating over multiple media including a wireless medium and a wired medium, the means for communicating being operable (1) in a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) in a wired mode for communicating over the wired medium using a variation of the wireless protocol; and means for switching (3102) between the wireless mode and the wired mode .
22. The apparatus of claim 21 wherein: the means for communicating is configured for receiving a communication in a particular one of the wireless mode or the wired mode, the means for switching is configured for switching from the particular one of the two modes of operation to the other of the two modes of operation, and the means for communicating is further configured for (1) converting the received communication from the protocol associated with the particular one of the two modes of operation into the protocol associated with the other of the two modes of operation, and (2) transmitting the received communication in the other of the two modes of operation.
22. The apparatus of claim 21 wherein the wired mode of operation is part of a time division function communication system.
23. An apparatus (3000) comprising a processor-readable medium including instructions stored on the processor-readable medium for performing at least the following: communicating over multiple media including a wireless medium and a wired medium, the communicating using one or more of (1) a wireless mode for communicating over a wireless medium using a wireless protocol, and (2) a wired mode for communicating over the wired medium using a variation of the wireless protocol; and switching between the wireless mode and the wired mode.
24. The apparatus of claim 23 wherein communicating comprises converting a communication, the communication having been received in a particular one of the two modes of operation, from the protocol associated with the particular one of the two modes of operation into the protocol associated with the other of the two modes of operation.
PCT/CN2007/002615 2007-08-31 2007-08-31 Method and apparatus for communicating over multiple networks WO2009026747A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2007/002615 WO2009026747A1 (en) 2007-08-31 2007-08-31 Method and apparatus for communicating over multiple networks

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PCT/CN2007/002615 WO2009026747A1 (en) 2007-08-31 2007-08-31 Method and apparatus for communicating over multiple networks
CN 200780101295 CN101843070B (en) 2007-08-31 2007-08-31 Method and apparatus for communicating over multiple networks
TW97126539A TW200926708A (en) 2007-07-13 2008-07-11 Method and apparatus for communicating over multiple networks

Publications (1)

Publication Number Publication Date
WO2009026747A1 true true WO2009026747A1 (en) 2009-03-05

Family

ID=40386648

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/002615 WO2009026747A1 (en) 2007-08-31 2007-08-31 Method and apparatus for communicating over multiple networks

Country Status (2)

Country Link
CN (1) CN101843070B (en)
WO (1) WO2009026747A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2257112A1 (en) * 2009-05-29 2010-12-01 Thomson Licensing, Inc. Time slot allocation method in communication system
US8665704B2 (en) 2011-11-25 2014-03-04 Hewlett-Packard Development Company, L.P. Parallelly coupled stackable network switching device

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2175590A1 (en) * 2008-10-10 2010-04-14 Thomson Licensing Method and apparatus for communicating over multiple networks
CN102377470B (en) * 2010-08-13 2015-08-12 中兴通讯股份有限公司 Reconfigurable wireless node and a method of macro cell access points working in cooperation
JPWO2012160932A1 (en) * 2011-05-20 2014-07-31 日本電気株式会社 Transmission apparatus and a processing method thereof
CN103607662A (en) * 2013-11-21 2014-02-26 乐视致新电子科技(天津)有限公司 Method and apparatus for communication protocol control in intelligent television equipment
CN104158712A (en) * 2014-08-28 2014-11-19 耿直 Time division working method for local area network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1449629A (en) * 2000-09-01 2003-10-15 朴琪业 Method and system for providing wireless multimedia services using bluetooth
EP1513098A2 (en) * 2003-09-03 2005-03-09 STMicroelectronics, Inc. Method and apparatus for a USB and contactless smart card device
CN1747483A (en) * 2004-09-06 2006-03-15 华为技术有限公司 Wireless terminal with double mode and realization thereof

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4367941B2 (en) * 2005-01-25 2009-11-18 キヤノン株式会社 Relay device, the image supply device and the printing system and its control method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1449629A (en) * 2000-09-01 2003-10-15 朴琪业 Method and system for providing wireless multimedia services using bluetooth
EP1513098A2 (en) * 2003-09-03 2005-03-09 STMicroelectronics, Inc. Method and apparatus for a USB and contactless smart card device
CN1747483A (en) * 2004-09-06 2006-03-15 华为技术有限公司 Wireless terminal with double mode and realization thereof

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2257112A1 (en) * 2009-05-29 2010-12-01 Thomson Licensing, Inc. Time slot allocation method in communication system
US8665704B2 (en) 2011-11-25 2014-03-04 Hewlett-Packard Development Company, L.P. Parallelly coupled stackable network switching device
US9025496B2 (en) 2011-11-25 2015-05-05 Hewlett-Packard Development Company, L.P. Parallelly coupled stackable network switching device

Also Published As

Publication number Publication date Type
CN101843070A (en) 2010-09-22 application
CN101843070B (en) 2014-12-10 grant

Similar Documents

Publication Publication Date Title
Xiao IEEE 802.11 n: enhancements for higher throughput in wireless LANs
Ni et al. A survey of QoS enhancements for IEEE 802.11 wireless LAN
US5329531A (en) Method of accessing a communication medium
US7293103B1 (en) Enhanced channel access mechanisms for a HPNA network
US6680929B1 (en) Base station, a terminal and a method for communicating between them
US20050018624A1 (en) Uniform power save method for 802.11e stations
Deng et al. A priority scheme for IEEE 802. 11 DCF access method
US20030206535A1 (en) LAN with message interleaving
US7120852B2 (en) Method and apparatus for packet aggregation in a wireless communication network
US6934752B1 (en) Quality of service extensions for multimedia applications in wireless computer networks
US20020093929A1 (en) System and method for sharing bandwidth between co-located 802.11a/e and HIPERLAN/2 systems
US20050021864A1 (en) 4X design for wireless local area network throughput enhancement
US20040143681A1 (en) Distributed architecture for deploying multiple wireless local-area network
US20040160930A1 (en) Method of transmitting multimedia data over WLAN and point coordinator in WLAN
US8233462B2 (en) High speed media access control and direct link protocol
Eklund et al. IEEE standard 802.16: a technical overview of the WirelessMAN/sup TM/air interface for broadband wireless access
US20070115882A1 (en) Symmetric transmit opportunity (TXOP) truncation
US5751708A (en) Access method for broadband and narrowband networks
US20080101308A1 (en) System and method for reducing packet collisions in wireless local area networks
US20050169296A1 (en) Temporary priority promotion for network communications in which access to a shared medium depends on a priority level
US20070268868A1 (en) Method and system for reliable broadcast or multicast communication in wireless networks
US20040071154A1 (en) Achieving high priority and bandwidth efficiency in a shared communications medium
US6754176B1 (en) Scheme for managing overlapping wireless computer networks
US8483105B2 (en) High speed media access control
US20050135318A1 (en) High speed media access control with legacy system interoperability

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07800832

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07800832

Country of ref document: EP

Kind code of ref document: A1