TWI394417B - Method and apparatus for communicating in multiple modes - Google Patents

Description

Multimode communication method and device

This disclosure generally addresses various aspects of a communication system.

The communication system exists to connect the user to the information. Such systems can use coaxial cable as well as wireless networks. Existing systems exhibit various limitations.

According to the general aspect, a frame structure is used for communication. The frame structure supports at least two communication modes. The communication modules include a slot in the frame structure for storing a time division mode for a device and wherein a polling slot in the frame structure is used by a multi-device for one of the polling modes of data communication.

According to another general aspect, a signal is constructed to carry data in accordance with a format that supports multiple communication modes. The signal includes a first portion that is constructed in the time slot for a time sharing mode. The first portion includes storing one or more time slots for individual devices and carrying data for the individual devices. The signal includes a second portion that is configured in one of the polling slots for polling the communication mode in one of the slots in which no device saves the poll. The second portion carries data for use in the polling slot of at least one device.

The details of one or more embodiments are set forth in the drawings and the description below. Even with a specific description, it should be clear that the implementation can be configured or embodied in a variety of ways. For example, an embodiment can be implemented as a method, or as a device configured to perform one of a set of operations or to store one of the instructions for performing a set of operations. Other aspects and features will be apparent from the following detailed description and claims.

At least the description of Figures 1 through 8 presents various embodiments including one or more novel and inventive aspects or features. At least one of these embodiments provides a system for transmitting data in a cable using typical features of a wireless system. In particular, at least one embodiment uses time division multiplexing in a coaxial cable. This system allows, for example, a cable television operator to provide television signals in a portion of the spectrum and provide additional services in another portion of the spectrum. Additional services may include, for example, Internet access, including access to search the Internet and view web pages on the Internet, and receive services over the Internet (eg, video on demand).

At least the description of Figures 9 through 20 presents additional embodiments, and at least one of the additional embodiments expands the description of Figures 1 through 8 by illustrating the novelty and inventive use of the package. A particular implementation includes a data machine that receives an Ethernet packet from a plurality of hosts. Each host may attempt to communicate with a different website through a router. The data packet encapsulates the packets into a single packet formatted for use in one of the format structures or protocols for wireless transmission. However, the packet message is transmitted in a coaxial cable for reception by the router. The router, in one embodiment, sequentially transmits the packets to different websites with which each of the hosts attempts to communicate.

The packets used by the embodiments described above provide an increase in output compared to a system that only encapsulates one packet at a time. Therefore, the work load of the wireless format structure is deployed in multiple Ethernet packets. This contrasts with, for example, the traditional use of packets that allow additional features to be provided by another communication layer, or to ensure backward compatibility by preserving the old framed structure in the packet data. In addition, the packets of the above-described embodiments are also allowed to encapsulate data from multiple sources to be packaged together with data intended for different end users (eg, different websites, or different hosts) depending on the system design.

At least the description of Figures 21 through 34 presents additional embodiments. Some of these implementations address the framework and novel and inventive aspects associated with polling and contention based access. A further embodiment addresses the dual mode configuration.

This application now provides an illustration of Figures 1-8. It should be noted that the headers are used in the various sections of the description of Figures 1-8. The header of a given chapter is not to be construed as limiting the disclosure of the section to the subject matter of the header, nor the disclosure of the other sections is limited to the subject matter other than the subject matter of the header. The headers are exemplary and are expected to be general assistance to the reader. The listings are not intended to be a limitation of the disclosure, nor the applicability or generality of the disclosure.

General description

application solution

In order to provide data services in existing coaxial cable TV systems (CATV), at least one embodiment places a time sharing function (TDF) protocol compliant access point (AP) and station (STA) in the cable access network. The AP and the STA are connected via a splitter in the hierarchical tree structure. In this way, users at home can access the remote IP core network via the cable access network. The detailed network layout is illustrated as illustrated in Figure 1.

As can be seen from Figure 1, in this typical access network infrastructure, there is a TDF protocol compliant AP with an Ethernet interface to the IP core network and the cable access network. A coaxial cable interface that is connected. On the other end of the cable access network, there is a TDF protocol compliant STA, ie a terminal, which is connected to the cable access network via the coaxial cable interface and via the Ethernet interface to the home LAN (regional network) )connection.

In accordance with at least one embodiment, both the TDF AP and the STA implement the protocol stack separately in the logical link control sublayer, the MAC sublayer, and the physical layer in accordance with the 802.11 family of specifications. However, in the MAC sublayer, the TDP AP and the STA replace the 802.11 frame transmission entity with the TDF frame transmission entity. Therefore, the MAC sublayer for the TDF AP and the STA is composed of the 802.11 frame packet/decapsulation entity and the TDF frame transmission entity, and the MAC sublayer for the 802.11 compliant AP and the STA is encapsulated/decapsulated by the 802.11 frame. The entity and the 802.11 frame transmission entity. For integrated APs and STAs, TDF frame transmission entities and 802.11 frame transmission entities can coexist simultaneously to provide both 802.11 and TDF functions. Switching between the two modes can be achieved by manual or dynamic configuration.

basic method

The main idea of the TDF protocol is to transmit IEEE 802.11 frames over coaxial cable media rather than over the air. The purpose of utilizing the IEEE 802.11 mechanism is to utilize mature hardware and software implementations of the 802.11 protocol stack.

The main feature of TDF is its unique media access control method for transmitting IEEE 802.11 data frames. That is, it does not utilize a legacy IEEE 802.11 DCF (Distributed Coordination Function) or PCF (Point Coordination Function) mechanism to exchange MAC frames, including MSDU (MAC Service Data Unit) and MMPDU (MAC Management Protocol Data Unit). Instead, it uses a time-sharing proximity method to transmit MAC frames. Thus TDF is an access method that defines a detailed implementation of a frame transport entity located in the MAC sublayer.

For purposes of comparison, the IEEE 802.11 MAC sublayer protocol in the OSI reference model as shown in FIG. 2 is illustrated herein. Although the exact location of the TDF protocol for use in the OSI reference model is illustrated in FIG.

Communication mode entry procedure

Currently, there are two communication modes suggested for the TDF compliant station, as explained below. One is the standard IEEE 802.11 operating mode, which is subject to the frame structure and transmission mechanism defined in the IEEE 802.11 series of standards; the other is in the TDF operating mode, and detailed information about it will be described in the following paragraphs. Figure 4 indicates the strategy for deciding which mode of operation to enter when a TDF STA is activated. Once a TDF STA receives a synchronization frame from an AP, it is enabled to enter the TDF mode. If the synchronization frame is not received within a preset timeout, the TDF STA remains or offsets to the IEEE 802.11 mode.

TDF agreement function description

Access method

The physical layer in the TDF station can have multiple data transfer rate capabilities that allow the implementation to implement dynamic rate switching with improved performance and device maintenance goals. Currently, the TDF station supports three types of data rates: 54 Mbps, 18 Mbps, and 6 Mbps. Data services are provided primarily at 54 Mbps data rates. When there is some problem with supporting 54 Mbps data transmission, it can temporarily switch to the 18 Mbps data rate. Design a 6 Mbps data rate operating mode based on network maintenance and desk debugging.

The data rate can be statically configured before a TDF station enters the TDF communication program and remains the same throughout the communication procedure. On the other hand, the TDF station can also support dynamic data rate switching during service. The criteria for data rate can be based on channel signal quality and other factors.

The basic access method of the TDF protocol is Time Division Multi-Direction (TDMA), which allows multiple users to share the same channel by dividing the same channel into different time slots. The TDF STAs successively transmit uplink traffic in succession, and each STA uses its own time slot in the TDF hyperframe assigned by the TDF AP. For downlink traffic, the STAs share the channel and select the data or management frame targeted by comparing the destination address information of the frame with its address. 5 illustrates an example of a TDF hyperframe structure and time slot allocation for a typical TDF hyperframe when there are m STAs competing for uplink transmission opportunities simultaneously.

As shown in FIG. 5, there is a time slot of a fixed number of TDF frames (tdfTotalTimeSlotNumber), which is composed of: a synchronization time for transmitting clock synchronization information from the TDF AP to the TDF STA. a slot for transmitting a registration request for uplink time slot allocation; by registering a TDF STA for successively transmitting data and some management frames to the TDF AP's tdfUplinkTimeSlotNumber uplink time slots; The tdfDownlinkTimeSlotNumber downlink time slot used by the TDF AP to transmit data and register the response management frame to the data machine. Except for the sync slot, all other slots known as the common slot have the same duration and have a length equal to tdfCommonTimeSlotDuration. The value of tdfCommonTimeSlotDuration is defined to allow transmission of at least one maximum IEEE 802.11 PLCP (Physical Layer Convergence Protocol) Protocol Data Unit (PPDU) for use in one of the highest rate data modules. The duration of the synchronization slot tdfSyncTimeSlotDuration is shorter than the duration of the common time slot because the clock synchronization frame transmitted from the TDF AP to the TDF STA in the slot is shorter than the 802.11 data frame.

Therefore, the duration of a TDF hyperframe defined as tdfSuperframeDuration can be calculated by the following equation:

tdfSuperframeDuration=tdfSyncTimeSlotDuration+tdfCommonTimeSlotDuration*(tdfTotalTimeSlotNumber-1)

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

tdfTotalTimeSlotNumber=tdfUplinkTimeSlotNumber+tdfDownlinkTimeSlotNumber+2

In addition, the number of allocated uplink time slots of the TDF STA in a TDF hyperframe can be changed from one to tdfUplinkTimeSlotThreshold. Therefore, the available downlink time slot in a TDF hyperframe can be changed from (tdfTotalTimeSlotNumber-2) to (tdfTotalTimeSlotNumber-2-tdfMaximumUplinkTimeSlotNumber). Each time there is a TDF STA requesting an uplink time slot, the TDF AP will infer one or more time slots from the available downlink time slots, and then assign the time slot to the TDF STA as long as The number of uplink time slots will not exceed tdfMaximumUplinkTimeSlotNumber after it. The value of tdfMaximumUplinkTimeSlotNumber can vary in different implementations. But it must be carefully chosen so that there is at least a downlink time slot available for an associated TDF STA in order to guarantee the QoS of the data service. In addition, all consecutive time slots used by the same TDF STA or AP for transmission in the same direction can be combined to continuously transmit MAC frames to avoid such time slots caused by unnecessary conversion and protection. Waste at the edge.

In the current embodiment, the tdfCommonTimeSlotDuration is about 300 us, which is sufficient for the TDF STA to transmit at least one maximum 802.11 PPDU for use in a common time slot of the 54M mode, and there are a total of 62 time slots per TDF frame. In this time slot, there are 20 uplink time slots and 40 downlink time slots in this way. When there are 20 STAs, it can guarantee that each TDF STA has access to the 680 kbps uplink data rate and share 30 Mbps (40 consecutive time slots) downlink data rate; when there are 30 STAs, Each TDF STA is guaranteed to have access to the 680 kbps uplink data rate and share a 22.5 Mbps (30 consecutive time slot) downlink rate. tdfMaximumUplinkTimeSlotNumber is 30. Finally, the value of tdfSuperframeDuration, which is the total duration of 61 common time slots and a synchronized time slot, is about 18.6 ms and can be defined as different values for different uses. For example, if there is only one TDF STA, it can be guaranteed to have 4 time slots to achieve an uplink data rate of approximately 18 Mbps and its own 18 Mbps (4 consecutive time slots) downlink data rate. In this way, the number of tdfSuperframeDurations for the total duration of the nine data time slots and one synchronization time slot is about 4 ms.

Frame format

In the 802.11 specification, there are three main frame types. Use the data frame to exchange data between stations. Depending on the network, several different types of data frames can appear. The control frame is combined with the data frame for performing the regional cleaning operation, the channel acquisition, and the carrier sensing maintenance function and the positive confirmation of the received data. Control and data frame joint operations to reliably deliver data between stations. More specifically, an important feature of data frame exchange is the existence of an acknowledgment mechanism, and therefore there is an acknowledgment (ACK) frame for each downlink unicast frame to reduce unreliable wireless The possibility of data loss caused by the channel. Finally, the management frame performs a supervisory function: it is used to engage and leave the wireless network and move the associated links between access points.

However, in the TDF system, since the TDF STA passively waits for the target TDF AP to be found from the sync frame of the TDF AP, the classic probe request and the probe response frame are not required. In addition, the frames are exchanged over the coaxial cable rather than over the air so that RTS and CTS frames do not have to be defined to clean up an area and prevent hidden node problems, and an ACK frame is defined to ensure the reliability of the delivery of the data frame.

Therefore, in the TDF protocol, only some useful 802.11 MSDU and MMPDU types are used for the data in the coaxial cable scheme. For example, the data subtype in the data frame type is used to encapsulate the upper data and transfer it from one station to another. In addition, in order to meet the clock synchronization requirements in the TDF system, a new management frame (synchronization frame) is defined; and in order to implement the function of uplink time slot request, allocation and release, four other management frames are defined. It is a registration request, registration response, non-registration request, and active notification.

To outline this, four new subtypes in the management frame type of the TDF agreement have been defined. The following table defines the valid combinations of types and subtypes added to the TDF contract. Table 1 shows the valid types and subtypes of TDF frames added for use in the TDF protocol.

T DF access program

TDF AP finds timely pulse synchronization program

The TDF agreement largely depends on the distribution of timing information to all nodes. First, the TDF STA listens to the sync frame to determine if there is an available TDF AP. Once it enters the TDF communication procedure, it uses the sync frame to adapt the area timer, and the TDF STA determines whether it will transmit the uplink frame according to the timer. At any time, the TDF AP is primarily in the synchronization process and the TDF STA is dependent. Furthermore, if it does not receive any synchronization frame from the associated AP within a predefined critical period defined as tdfSynchronizationCycle, the TDF STA will consider that the AP has abandoned the service and then it stops the TDF communication procedure and begins listening again. Synchronize the frame and look for any TDF AP.

In a TDF system, all STAs associated with the same TDF AP will be synchronized with a common clock. The TDF AP will periodically transmit a special frame containing its clock information to be synchronized by the call to synchronize the modems in its regional network. Each TDF STA will maintain an Area Timing Synchronization Function (TSF) timer to ensure that it is synchronized with the associated TDF AP. After receiving a synchronization frame, a TDF STA always accepts timing information in the frame. If the TSF timer is different from the timestamp of the received synchronization frame, the receiving TDF STA sets its regional timer according to the received timestamp value. In addition, it can add a small offset to the received timing value to resolve the region processing by the transceiver.

The sync frame will be generated for transmission in each TDF frame time unit by the TDF AP and in the sync slot of each TDF frame.

Registration procedure

Figure 6 illustratively illustrates the entire registration process. Once a TDF STA has obtained timer synchronization information from the sync frame, it will know when time slot 0 begins. If a TDF STA is not associated with any TDF AP, it will try to register with a particular TDF AP that transmits the registration request during the contention slot of the second time slot for a TDF frame. The frame is transmitted to the TDF AP and the synchronization frame is transmitted. The duration of the contention time slot equal to tdfCommonTimeSlotDuration, and the registration request frame structure should be carefully designed to allow at least tdfMaximumUplinkTimeSlotNumber registration request frames to be transmitted in a contention slot. According to the design, the contention time slot is divided into tdfMaximumUplinkTimeSlotNumber sub-time slots of the same length.

As soon as the target TDF AP is found, a TDF STA will select a sub-time slot in the contention time slot to transmit a registration request frame to the TDF AP according to the following method:

A. Each time an uplink time slot is allocated, a TDF STA will store the number of allocated uplink time slots defined as tdfAllocatedUplinkTimeSlot, which indicates the location and the location of the time slots in the slot set area throughout the uplink. 1 to the range of tdfMaximumUplinkTimeSlotNumber.

B. The TDF AP should allocate the same uplink time slot to the same TDF STA every time it requests an uplink time slot.

C. When it is time to decide when to select the slot to transmit the registration request frame, if there is a stored tdfAllocatedUplinkTimeSlot value, the TDF STA will set the same number of sub-time slots as tdfAllocatedUplinkTimeSlot; if there is no such value, the TDF STA A sub-time slot in the available sub-time slot of tdfMaximumUplinkTimeSlotNumber will be randomly selected. It will transmit a registration request frame to the TDF AP in a randomly selected sub-time slot.

The purpose of such an operation is to reduce the chance of collisions when there are many STAs that are simultaneously activated and try to register with the same TDF AP at the same time.

The TDF STA will enumerate all the data rates it supports at the time and also carry some useful information, such as the received signal carrier/noise ratio in the registration request frame. It can start with the highest data rate and transmit several consecutive registration request frames with different support data rates. After transmitting the frame, the TDF STA will listen to the registration response frame from the TDF AP.

After receiving a registration request frame from a TDF STA, the TDF AP will transmit a different kind of registration response frame to the TDF STA in the downlink time slot according to the following method:

A. If the allocated uplink time slot is equal to tdfMaximumUplinkTimeSlotNumber, the TDF AP places the uplinkTimeSlotUnavailable indicator in the frame body.

B. If the TDF AP does not support any of the data rates listed in the supportedDataratesSet of the registration request management frame, the TDF AP places the unsupportedDatarates indicator in the frame body.

C. If there is an uplink time slot available for allocation and a common data rate that both TDF AP and TDF STA can support, the AP will allocate an uplink time slot and base information (eg, registration of the STA) The carrier/noise ratio in the request frame is selected to an appropriate common data rate, and then a registration response frame is transmitted to the TDF STA. Information about the assigned uplink time slot and the selected data rate will be included in the frame body.

After a successful registration procedure, the TDF STA and the TDF AP will reach agreement on what uplink time slot and data rate to use.

Segmentation/reorganization procedure

In the TDF protocol, the time slot duration for the transmission of the MSDU is fixed to tdfCommonTimeSlotDuration. In some data rates, when the length of the MSDU is greater than a threshold, it is not possible to transmit in a single time slot. Thus, when a data rate for uplink transmission is longer than a threshold defined as tdfFragmentationThreshold and varies according to different data rates, it is segmented before being scheduled for transmission. For all segments except for the smaller last segment, the length of a segment frame will be an equal number of octets (tdfFragmentationThreshold octet). After segmentation, the segmentation frame is placed in the delivery queue for transmission to the TDF AP. The segmentation procedure can be run in the TDF frame transport entity or upper layer by using the tdfFragmentationThreshold dynamically set in the TDF frame transport entity.

At the end of the TDF AP, each received segment contains information to allow the full frame to be reassembled from its constituent segments. The header of each segment contains the following information used by the TDF AP to reassemble the frame:

A. Frame type

B. The 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 project segments belong to the same MSDU and that the sequence used for the segments should be reassembled. The sequence number within the sequence control field remains the same for all segments of an MSDU; the sequence number within the sequence control field is incremented for each segment.

E. Multiple Segment Indicators: Indicate to the TDF AP that this is not the last segment of the data frame. Only the last or only segment of the MSDU sets this bit to zero. All other segments of the MSDU set this bit to one.

The TDF AP reconstructs the MSDU by combining the segments in the order of the segment number subfields of the sequence control field. If a segment with a multi-segment bit set to zero has not been received, the TDF AP will know that the frame has not been completed. As soon as the TDF AP receives a segment with multi-segment bits set to zero, it knows that no more segments are available for the frame.

The TDF AP maintains a receive timer for each of the received frames. There is also an attribute tdfMaxReceiveLifetime that specifies the maximum amount of time allowed to receive a frame. The receiving timer is started after receiving the first segment of the MSDU. If the receiving timer exceeds tdfMaxReceiveLifetime, all receiving segments of the MSDU are discarded by the TDF AP. If additional segments that must be sent to the MSDU are received after their tdfMaxReceiveLifetime has expired, the segments are 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 it is not granted, it will stop for a while and apply for an uplink time slot later. If granted, it will begin transmitting uplink traffic during the assigned time slot using the data rate indicated in the registration response frame.

When the uplink transmission is started during the assignment time slot, if there is at least one external transmission frame in the transmission queue outside the TDF STA, the TDF STA will transmit the first frame to the external transmission queue to the TDF AP. Thereafter, the TDF STA will check the length of the second uplink frame and evaluate whether the second uplink frame can be transmitted during the remaining duration in the assigned time slot. If not, it will stop the uplink transmission procedure and wait for the second uplink frame to be transmitted in the assigned time slot during the next TDF frame. If so, it will immediately transmit the second frame to the destination TDF AP. The transfer program will continue to run in this manner until the time slot has been assigned, or there are no uplink frames to transmit.

Downlink transmission procedure

In the entire TDF communication procedure, the total number of downlink time slots may change dynamically due to changing the number of associated STAs. When the TDF AP prepares the transmit frame to the associated STA, it compares the time left in the remaining downlink time slots with the duration required to transmit the particular downlink frame using the protocol data rate. Therefore, depending on the result, it will decide whether to transmit the frame at a specific data rate during this TDF frame. In addition, the TDF AP does not need to segment any downlink frames.

When the time of the uplink message is not transmitted to the associated STA, the STA always listens to the channel for the feasible downlink frame targeted for it.

Non-registered procedure

As shown in FIG. 7, if the TDF STA decides to abandon the TDF communication procedure, it transmits a non-registration request frame to the associated TDF AP during its uplink time slot to inform the TDF AP to release the TDF AP for use therein. Allocate slot time resources. After receiving the non-registration request frame, the TDF AP will freely assign the uplink time slot assigned to the TDF STA and place it in the free time slot pool for future use.

Active notifier

Referring now to Figure 8, in order to release resources as soon as a TDF STA accidentally crashes or shuts down, the TDF STA must report its active notification frame to the TDF AP periodically during its uplink time slot period. Active. If there is no active notification frame within a predefined critical period called tdfAliveNotificationCycle, the associated TDF AP will consider that the TDF STA has abandoned the service and thus release the uplink time slot allocated for the TDF STA, Just like receiving a non-registration request frame from the TDF STA.

To ensure coexistence and interoperability on multi-rate capable TDF STAs, this specification defines a set of rules to be followed by all stations:

A. The sync frame will be transmitted at the lowest rate of the TDF base rate set so that it will be known by all STAs.

B. All frames with the destination unicast address are transmitted at the supported data rate selected by the registration mechanism. No station transmits a single frame at a rate supported by the receiver station.

C. All frames with destination multicast addresses are transmitted at the highest rate of TDF base rate concentration.

9 to 20 are explained as follows. At least Figures 9 through 20 illustrate embodiments that may be used, for example, in one or more of the systems illustrated by Figures 1-8. Of course, the features and aspects of the embodiments of Figures 9 through 20 can be used in other systems.

As explained above, a TDF protocol can replace the traditional 802.11 DCF (Distributed Coordination Function) or PCF (Point Coordination Function) mechanism. This system can take advantage of the wide layout of WLAN (802.11) networks and one of the wireless local area network (WLAN) chipsets that may become more mature and cheaper. This system provides a cost-effective solution for two-way communication of CATV networks by transmitting WLAN signals in a cable network, even if a WLAN protocol is established to transmit/receive in an air environment rather than a cable network. In this system, the basic access method of the TDF protocol is TDMA, which allows multiple users to share the same channel by dividing the same channel into different time slots. The TDF stations rapidly transmit uplink traffic in succession, each using its own time slot in one of the TDF super-frames assigned by the TDF AP (access point). For downlink traffic, the stations share channels (eg, as shown in the TDF hyperframe of Figure 5) and are selected by comparing the destination address information of the frames to their addresses. It is the target frame.

Referring to Figure 9, a typical TDF network 900 is shown. Network 900 provides connectivity from user premises 910 and 920 to the Internet (or another resource or network) 930. User homes 910 and 920 are connected in cable system 950 via an access point (AP) 940. The AP 940 can be located, for example, in neighbors at homes 910 and 920, or in apartment buildings including homes (in this case, apartments) 910 and 920. The AP 940 can be owned by, for example, a cable operator. The AP 940 is further coupled to a router 960 in the Ethernet 970. Router 960 is also coupled to Internet 930.

It should be clear that the term "coupled" refers to both a direct connection (without intermediate components or units) and an indirect connection (one or more intermediate components and/or units). Such connections may be, for example, wired or wireless, as well as permanent or transient.

User homes 910 and 920 can have a variety of different configurations, and each can be configured differently. However, as shown in network 900, user homes 910 and 920 each include one (referred to as a data machine) 912 and 922, respectively. Data machines 912 and 922 are coupled to a first host (host 1) 914, 924, and a second host (host 2) 916, respectively, in an Ethernet 918, 928. Each host 914, 916, 924, and 926 can be, for example, a computer or another processing device or communication device.

There are various ways in which network 900 can allow multiple hosts (e.g., 914, 916, 924, and 926) to connect to router 960. Based on simplicity, four embodiments are described below with reference to only data machine 912 and hosts 914 and 916.

In a first method, data engine 912 acts as another router. Hosts 914 and 916 are identified by their IP addresses, and data 912 sends IP packets from hosts 914 and 916 to router 960. This method 1 typically requires the data processor 912 to run a router software that requires additional memory and increased processing power.

In a second method, the data engine 912 acts as a bridge. Data machine 912 and AP 940 use a standard wireless distribution system (WDS) mechanism to convey layer 2 packets to router 960. Hosts 914 and 916 are identified by their Media Access Control (MAC) address. This method 2 is part of the 802.11 standard and can simultaneously serve multiple hosts. However, not all APs and modems support WDS, and APs and modems that do support WDS usually have limited support. For example, with some APs and modems, Wi-Fi Protected Access (WPA) cannot be used for WDS, and this can introduce security issues.

In a third method, the data engine 912 uses the MAC priming to change the source MAC address of the Ethernet packet (one of the source hosts 914 and 916) as its own MAC address. Thus, from the perspective of router 960, router 960 only sees data machine 912. The data machine 912 can only serve one host at a time using this method.

In an alternate method, data machine 912 uses a packet, as explained in more detail below. Each of the above methods has advantages and disadvantages, and such advantages and disadvantages may vary depending on the embodiment. However, the packetization method provides certain advantages, which generally do not require the data machine to run the router software and allow the data machines to be simpler, which typically does not introduce security issues, and which can serve multiple hosts at a time.

In addition, the packetization method avoids the large workload associated with the three methods prior to transmitting each packet from a host using a single WLAN packet. Therefore, the first three methods incur the workload of the WLAN packets of each packet transmitted from a host, and correspondingly reduce the output. Such inefficiencies are usually exacerbated in the TDF environment. In a TDF environment, the duration of the time slot is fixed and the time slot is designed to allow only one WLAN packet to be transmitted in one slot. Therefore, only one host packet can be transmitted in each slot.

Therefore, the packet method generally provides one or more of various advantages. Such advantages include, for example, simpler router design and operation, increased security, servoing multiple hosts, and increased efficiency and output.

In summary, at least one embodiment of the packetization method includes packetizing a plurality of Ethernet packets into one WLAN packet. The WLAN packet will be as large as the maximum length allowed by the TDF time slot. The AP (eg, another modem) will decapsulate the WLAN packet into individual Ethernet packets and transmit it to the router. For communication in the reverse direction, a modem will decapsulate a WLAN packet and transmit an individual Ethernet packet to the host.

Referring to Figure 10, a diagram 1000 includes a plurality of data machines, two of which are explicitly shown; and an AP. The commentary includes a data machine #1 1010, a data machine #N 1020, and an AP 1030, wherein each of the data machines 1010 and 1020 is coupled to the AP 1030 in a cable network 1040. Other embodiments use a separate cable network for each of the data machines.

The data machines 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 on a data machine and an AP. Therefore, a common unit is provided for use as both a data machine and an AP. However, it should be clear that different units can be designed for a data machine and an AP, wherein different units only implement the functions required by a data machine or an AP, respectively.

The modem 1010 includes a zone application 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/de-collection 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 the Ethernet 1052, which is coupled to a first host (host 1) 1054 and a second host (host 2) 1056.

Data machine 1020 is similar to data machine 1010. However, data machine 1020 is coupled to Ethernet 1062, and Ethernet 1062 is coupled to a first host (host 1) 1064 and a second host (host 2) 1066. The components of data machine 1020 are shown as being identical to the components of data machine 1010. However, it should be clear that various configuration parameters (for example) will be different when the data machines 1010 and 1020 are set up and operating.

The AP 1030 includes an area application 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 1082, which in turn is coupled to a router 1090. The WLAN interfaces 1017 and 1075 are communicatively coupled to each other in the cable network 1040.

Router 1090 is further coupled to Internet 1095. Therefore, there is a connection between the hosts 1054, 1056, 1064, 1066 and the Internet 1095.

The various regional application layers (1011, 1071) are standard layers for running regional applications and interfacing with other layers in the architecture. The various TCP/IP layers (1012, 1072) are standard layers for running TCP/IP and providing services typically provided by such layers, including interfacing with other layers in the architecture. Various Ethernet interfaces (1015, 1077) are used to interface to/from the standard unit of the Ethernet. Such interfaces 1015, 1077 transmit and receive Ethernet packets and operate in accordance with the Ethernet protocol.

Various WLAN interfaces (1017, 1075) are used to interface to/from the WLAN network. Such interfaces 1017, 1075 transmit and receive WLAN packets and operate in accordance with the WLAN protocol. However, the WLAN interfaces 1017, 1075 are actually coupled to a cable network 1040 in the narration 1000 rather than using wireless communication.

The Ethernet and WLAN interfaces 1015, 1017, 1075, and 1077 can be implemented in, for example, a hardware such as an add-in card for a computer. The interfaces can also be implemented to a large extent in software such as a program that performs the functions of the interface using instructions implemented by a processing device. The interface typically includes a portion for receiving an actual signal (eg, a connector) and buffering the received signal (eg, a transmit/receive buffer) and typically includes a portion for processing the signal (eg, a signal processing chip) All or part).

The various bridges (1014, 1074) are units that forward packets between an Ethernet interface and a WLAN interface. A bridge can be implemented in software or hardware, or can be just a logical entity. A standard implementation for a bridge includes a processing device (e.g., an integrated circuit) or a set of instructions running on a processing device (e.g., one of the processors running the bridge software).

PADMs 1016 and 1076 perform various functions, including packet encapsulation and decapsulation, which are further described below. PADMs 1016 and 1076 can be implemented, for example, in 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 wafer, such as an application specific IC (ASIC).

Referring to Figure 11, a routine 1100 describes a procedure for transmitting a packet from a host to a modem. The packets are further transmitted from the modem for reception by an AP and finally delivered to a router and then to a final destination. This program 1100 is also referred to as an uplink transmission procedure.

Program 1100 includes connecting the data machine to the AP (1110) using, for example, a procedure as described earlier in this application. Such programs may include, for example, standard WLAN protocols including authentication and associated operations.

The program 1100 thus includes one or more hosts transmitting one or more packets (1120) to the data machine, and the data machine receiving the (etc.) transmission packets (1130). It should be noted that the transport packets are received by a router that delivers the packets to the final destination. In the embodiment of FIG. 10, the data machine 1010 receives the transport packets from one or more of the hosts 1054 and 1056 over the Ethernet interface 1015 over the Ethernet 1052.

The modem therefore determines that the (etc.) packet will be transmitted on a WLAN interface (1140). The modem makes this decision (1140) by identifying that the router is accessing the WLAN interface as opposed to accessing it on another interface (not shown). In the embodiment of FIG. 10, data machine 1010 transmits the (etc.) receive packet to bridge 1014, and bridge 1014 makes this decision (1140).

The modem thus encapsulates a plurality of packets for the router, including one or more received packets (1150). The packet (1150) may include packets received from a plurality of hosts, such as hosts 1054 and 1056 in the embodiment of FIG. In addition, the packet can include the (etc.) packets received in operation 1130 and the packets received earlier and stored in the queue.

In an embodiment that does not packetize multiple packets, the implementation may use a bridge to map Ethernet packets to individual WLAN packets to individually packetize each Ethernet packet. The packet may, for example, include the entire Ethernet packet as part of a WLAN packet and add an additional WLAN header.

In addition, implementations that do not encapsulate multiple packets do not even need to encapsulate individual Ethernet packets. Rather, such an implementation may convert individual Ethernet packets into individual WLANs by, for example, replacing the Ethernet header with a WLAN header and adding one or more additional fields as needed. Packet.

For example, referring to FIG. 12, a conversion 1200 is shown that receives an Ethernet packet 1210 that includes an Ethernet header 1220 and a data portion 1230. The translation 1200 generates a WLAN packet 1240 that includes a WLAN header 1250, a data portion 1230, and a frame check sequence (FCS) 1260.

However, implementing operation 1150 includes packetizing a plurality of Ethernet packets into a single WLAN packet. FIG. 13 illustrates one embodiment of operation 1150.

Referring to Figure 13, a conversion 1300 receives a plurality of Ethernet packets, including Ethernet packets 1310, 1312, and 1314, and generates a single WLAN packet 1318. Each of the Ethernet packets 1310, 1312, and 1314 includes an Ethernet header 1320, 1322, and 1324, and includes a data portion 1326, 1328, and 1329, respectively.

Ethernet packets 1310, 1312, and 1314 may originate from the same host or different hosts. In addition, although the Ethernet packets 1310, 1312, and 1314 are packetized for transmission 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 can be a destination of a different internet location with which one or more hosts communicate (or attempt to communicate).

The transformation 1300 series is shown to include two intermediate operations. However, other embodiments do not implement any intermediate operations, and other embodiments implement multiple intermediate operations.

The first intermediate operation converts the Ethernet packets into extended Ethernet packets. The Ethernet packets 1310, 1312, and 1314 are converted into extended Ethernet packets 1330, 1332, and 1334, respectively. In the conversion 1300, all Ethernet packets 1310, 1312, and 1314 are included to expand the data portions 1336, 1338, and 1340 of the Ethernet packets 1330, 1332, and 1334, respectively. The extended Ethernet packets 1330, 1332, and 1334 also include optional headers 1342, 1343, and 1344, respectively, and optional endings 1346, 1347, and 1348. Headers 1342, 1343, and 1344 and endings 1346, 1347, and 1348 may include a variety of different pieces of information, whether or not they are typical for the header/end, such as the number of packets, confirmation and retransmission information, for source and/or The address of the destination, as well as error checking information.

The second intermediate operation includes converting the extended Ethernet packets into a single "WLAN In Ethernet" (EIW) packet 1350. The EIW Packet 1350 includes a data portion for each of these extended Ethernet packets. Show two possible conversions. The first transformation is illustrated by the solid arrow 1370 and the second transformation is illustrated by the dashed arrow 1375.

As indicated by the solid arrow 1370 in the conversion 1300, the data portions 1352, 1353, and 1354 correspond to the included extended Ethernet packets 1330, 1332, and 1334, respectively. The EIW packet 1350 further includes an optional header 1356 (also referred to as an EIW header) and an optional ending 1358, which may include, for example, any of the materials previously described for header/end.

If the header or the end is not inserted in an extended Ethernet packet, the data portion of the extended Ethernet packet (eg, data portion 1336) becomes the data portion of the EIW packet (eg, , data section 1352). Moreover, even if a header or trailer is inserted into the extended Ethernet packet, an embodiment can discard/ignore the header or end when forming the EIW packet. In either of these cases, the expanded Ethernet packet and the portion of the data of the EIW packet have the same information.

As indicated by the dashed arrow 1375 in the transformation 1300, the data portions 1352, 1353, and 1354 do not have to correspond to the extended Ethernet packets 1330, 1332, and 1334, respectively. That is, one of the data portions of an EIW packet does not have to include an entire extended Ethernet packet. As indicated by the dashed arrow 1375, an extended Ethernet packet can be divided into data portions of two EIW packets.

More specifically, the embodiment illustrated by the dashed arrow 1375 shows (1) that the second portion of the extended Ethernet packet 1330 is placed in the data portion 1352 of the EIW packet 1350, and (2) the entire expansion is expanded. The Ethernet packet 1332 is placed in the data portion 1353 of the EIW packet 1350, and (3) the first portion of the extended Ethernet packet 1334 is placed in the data portion 1354 of the EIW packet 1350. Therefore, in one scheme for the EIW packet 1350, (1) the first data portion 1352 includes a portion of the extended Ethernet packet, and (2) the last data portion 1354 includes a portion of the extended Ethernet packet. And (3) the intermediate data section (1353 and any other data sections not explicitly shown) contains all of the extended Ethernet packets. Although not shown, it should be clear that the first part of the extended Ethernet packet 1330 can be placed in one of the data sections of a previous EIW packet, and (2) the second part of the Ethernet packet 1334 can be expanded. Place it in a data section of a subsequent EIW packet.

In the final phase of the conversion 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.

It should be clear that not all embodiments use all of the optional headers and endings, or even all (or any) of the optional intermediate operations (also referred to as stages). For example, other embodiments only copy portions of the extended Ethernet packets into the EIW packets to fit more of the original data (eg, data portions 1326, 1328, and 1329) to a fixed duration time slot. It should be clear that which headers and endings are used, and how many intermediate operations are included, may vary for each implementation and depending on design goals and constraints.

Referring to Figure 14, a diagram 1400 shows how an embodiment of a PADM encapsulates an Ethernet packet. The PADM maintains an entry queue 1410 in which each item of the Ethernet packet is placed. The PADM chained the Ethernet packets into a string 1420 and adds an EIW header 1430 and a WLAN header 1440. Based on the information included in headers 1430 and 1440, such headers 1430 and 1440 can be constructed early or after chaining the Ethernet packets. For example, at least one embodiment includes a number in the EIW header 1430 indicating the number of Ethernet packets in the string 1420. If the Ethernet packets can have a variable length, then the number is typically not available until the Ethernet packets have been packaged into strings 1420. It should be clear that headers 1430 and 1440 can be defined to meet the needs of a particular implementation.

Referring to Figure 15, a format 1500 of one embodiment of an EIW header is shown. The format 1500 includes a field 1510 for the sequence and the confirmation number, a total number of packets 1520, and a series of packet descriptors, including each Ethernet packet for packetization in the WLAN packet. A descriptor. Therefore, one of the expected packet descriptors is variable in number, as indicated by the ellipses in FIG. Packet descriptors 1530 and 1540 are displayed, wherein each of the packet descriptors 1530 and 1540 includes 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 packet material that allows the recipient to confirm receipt of the transmission. The confirmation number provides confirmation of previously received material. The number of total packets is the number of Ethernet packets encapsulated in the WLAN packet.

The packet flag (1550, 1555) indicates whether the associated Ethernet packet is a complete packet. If the time slot has a fixed duration, it is possible that the entire Ethernet packet may not fit a given WLAN packet. Therefore, it is contemplated in certain embodiments that the first and last Ethernet packets are typically incomplete in any given WLAN packet. The packet length (1560, 1565) indicates the length of the particular Ethernet packet.

Continuing with program 1100, in the embodiment of FIG. 10, operation 1150 can be performed by, for example, PADM 1016 of data machine 1010. Other embodiments may perform operation 1150 in, for example, the bridge, the Ethernet interface, the WLAN interface, another intermediate component other than the PADM, a component over the bridge, or a combination of components. . It will be appreciated that the operation 1150 can be implemented in, for example, a software (eg, a program of instructions), a hardware (eg, an IC), a firmware (eg, a firmware embedded in a processing device), or a combination (etc.) ) components.

Additionally, the PADM can be located at a different location within the modem (eg, over the bridge or between the Ethernet interface and the bridge), in one of the interfaces or within the bridge And/or distributed among multiple components.

The program 1100 further includes transmitting the packet to the data machine (1160) of the AP in the cable. The transmission packet is expected to be received by the router. The cable can include, for example, a coaxial cable, a fiber optic cable, or other wired transmission medium.

In a particular embodiment, when the uplink time slot of a data machine arrives, the data machine will collect the packets from the incoming queue and place them in a large WLAN packet. The WLAN packet is not larger than the maximum packet allowed by the time slot. Conversely, when the time slot arrives, if the WLAN packet is not large enough to fill the duration of the fixed time slot, then one embodiment will transmit a (smaller) WLAN packet, while another embodiment transmits null data. (NULL data).

Referring to Figure 16, a routine 1600 depicts a procedure for receiving a packet, decapsulating the packet, and delivering a packet. This procedure 1600 is also referred to as an uplink receiving procedure.

The program 1600 includes an AP receiving a packet (1620) from a modem on a WLAN interface. In the embodiment of FIG. 10, AP 1030 receives the packet from data machine 1010. The packet is received on cable network 1040 (e.g., a coaxial cable network) over WLAN interface 1075.

The AP decapsulates the received packet to retrieve the constituent packet (1630) constituting the packet. In the embodiment of FIG. 10, the WLAN interface 1075 transmits a receive (packet) packet to the PADM 1076. The PADM 1076 performs decapsulation and provides the composition of the Ethernet packet to the bridge 1074. By checking, for example, the number of total packets 1520, and the packet flag (e.g., packet flag 1550) of each packet descriptor (e.g., packet descriptor 1530) and the packet length (e.g., The packet length is 1560) and the decapsulation is carried out. By examining this information, PADM 1076 can determine where each of the constituent packets is opened and closed.

In particular, PADM 1076 checks each component packet to ensure that the packet is a complete Ethernet packet. If the constituent packet is not complete, the PADM 1076 retains the incomplete packet and waits until it receives the rest of the Ethernet packet (presumably in the subsequent packet). When receiving the rest of the Ethernet packet, the PADM 1076 assembles the full Ethernet packet and forwards the full Ethernet packet to the bridge 1074.

Referring to Figure 17, the above embodiment of operation 1630 is described in Figure 1700 for receiving a packet 1710. Based on the simplicity, the received packet packet 1710 is assumed to be identical to the transport packet described with reference to FIG. However, it should be understood that there may be a change between a transmission packet and a reception packet. Receive packet 1710 includes a WLAN header 1440, an EIW header 1430, and a string 1420 that forms an Ethernet packet.

As the PADM 1076 processes the received packet 1710, if a component of the Ethernet packet is complete, the packet (e.g., packet 1720) is provided to the bridge 1074. If a component of the Ethernet packet is incomplete, the incomplete packet is stored in a waiting queue 1730 (which does not have to be located in the PADM 1076) until the remainder of the packet arrives. FIG. 1700 shows an incomplete packet 1740 stored in the waiting queue 1730. This can occur, for example, in the case of an Ethernet packet spanning two WLAN packets. When the packet is complete, the packet is transmitted to the bridge 1074. It should be noted that a WLAN may include, for example, a full Ethernet packet and a partial Ethernet packet.

Referring to Figure 18, to further illustrate the decapsulation process 1130, a PADM 1750 is described that provides an embodiment of any of the PADMs 1016 or 1076. The PADM 1750 includes a packetizer 1760 and a depacketer 1770. Packetizer 1760 and depacketizer 1770 are communicatively coupled to a bridge and a WLAN interface. In the case of providing components of the PADM 1750, the PADM 1750 may be more specifically referred to as a packet encapsulation/decapsulation module.

In operation, the packetizer 1760 receives the Ethernet packets from the bridge and encapsulates the Ethernet packets, as explained above. The packet data is then provided to the WLAN interface.

In operation, the depacketer 1770 receives the packet data from the WLAN interface. The packetizer 1770 is decapsulated to receive the data as described above, and provides decapsulation information to the bridge.

Clearly, other embodiments are possible and envisioned. For example, another embodiment combines a packer and a depacker. Another embodiment uses the virtual Ethernet interface feature of Linux.

It should be noted that an AP or other embodiment of a modem directly transmits a packet from a WLAN interface to a bridge. The bridge determines that the packet can be packetized and transmitted to a PADM.

Continuing with process 1600, the AP determines that the component packets will be transmitted to a router (1640). This operation can be performed at a different point in the program 1600 with a number of operations (1640). In the embodiment of FIG. 10, bridge 1074 determines that the packets will be transmitted to router 1090.

The AP then transmits the component packets to the router (1650) on an Ethernet interface. In the embodiment of FIG. 10, the bridge 1074 transmits the component packets to the Ethernet interface 1077, which transmits the packets to the router 1090 over the Ethernet 1082.

The router receives (1060) and processes (1070) the packets. Processing may include, for example, transmitting the packets or portions thereof to another destination, such as a website with which the host communicates or attempts to communicate. In addition, in an implementation in which one packet includes an Ethernet packet from multiple hosts, the router can transmit the underlying information to multiple websites.

Referring to Figure 19, a procedure 1800 depicts a procedure for receiving a packet from a router at an AP. The packets are encapsulated and the packet is transmitted from the AP. The transport packet is expected to be received by a modem, and the packet is expected to be finally delivered from the modem to one or more hosts. This program 1800 is also referred to as a downlink transmission procedure.

The program 1800 includes a router receiving one or more packets intended for one or more hosts (1820), and the router transmits the (etc.) received packets to an AP (1830). The router can receive packets from, for example, one or more websites that attempt to communicate with one or more hosts. In the embodiment of FIG. 10, router 1090 receives packets from Internet 1095. Router 1090 then transmits an incoming packet to Ethernet 1077 of AP 1030 over Ethernet 1082.

The AP determines that at least one of the received packets will be transmitted to the data device on a WLAN interface (1840). In the embodiment of FIG. 10, the Ethernet interface 1077 sends a receive packet (which is an Ethernet packet) to the bridge 1074. Bridge 1074 determines that a packet will be transmitted on WLAN interface 1075 to, for example, data machine 1010.

The AP packet includes one or more packets that receive the packet for transmission to the modem (1850). It should be noted that all of the packets are received from the router, but may have been received at the router from one or more different sources (e.g., different websites). In addition, the packet can include packets received in operation 1820 and packets received earlier and stored in a queue.

Regarding operation 1850, in the embodiment of FIG. 10, bridge 1074 forwards the (etc.) receive packet to PADM 1076. The PADM 1076, in conjunction with other packets intended for, for example, the data machine 1010, arranges the (sequential) received packets and forms a packet WLAN packet for the available downlink time slot of the data machine 1010. The PADM 1076 maintains a separate queue for each data machine (also referred to as a single), including a first queue for the data machine 1010 and a second queue for the data machine 1020. The packet is illustrated as described earlier with reference to Figures 11 through 15 of the PADM 1016.

The AP transmits a packet to the modem in a cable connection, the packet being expected to be finally delivered to one or more hosts (1860). In the embodiment of FIG. 10, PADM 1076 prepares a WLAN packet for each of data machines 1010 and 1020 in a circular frequency format. The PADM 1076 then supplies the WLAN packets to the WLAN interface 1075 for insertion into the corresponding downlink time slots in the TDF hyperframe structure. The WLAN interface 1075 then transmits the WLAN packet to the data machines 1010 and 1020 using the TDF hyperframe structure.

Referring to Figure 20, a procedure 1900 depicts a procedure for receiving a packet, decapsulating the packet, and delivering a packet. This program 1900 is also referred to as a downlink receiving procedure.

The program 1900 includes a data machine receiving a packet (1920) from an AP on a WLAN interface. In the embodiment of FIG. 10, the data machine 1010 receives the packet on the WLAN interface 1017 in a cable network 1040 (eg, a coaxial cable network).

The data machine then proceeds to the packet receiving packet to retrieve the constituent packets constituting the packet (1930). In the embodiment of FIG. 10, the PADM 1016 performs de-encapsulation of the WLAN packets and provides an Ethernet packet to the bridge 1014. The decapsulation can be performed as described earlier in the description of Figures 16 through 18 of PADM 1076.

The modem determines that the component packets are to be delivered to one or more intended host recipients (1940). This operation can be performed at a different point in the program 1900 with a number of operations (1940). For example, operation 1940 can be performed in conjunction with any of operations 1930 or 1950. In the embodiment of Figure 10, bridge 1014 determines that the packets will be delivered to the host.

The modem then transmits the component packets to the host (1950) on an Ethernet interface. In the embodiment of FIG. 10, the bridge 1014 transmits the component packets to the Ethernet interface 1015, which transmits the packets to one or more of the host 1 1054 and the host 2 1056 on the Ethernet 1052. One.

One or more hosts receive (1960) and process (1970) the packets. Processing may include, for example, a personal computer that stores multimedia files received on the Internet; a PDA that displays an electronic message (also received over the Internet) for viewing and interacting with a user .

21 to 34 will now be explained. However, the description of the embodiments represented by FIGS. 21 to 34 is not limited to the following description.

In order to take advantage of the mature hardware and software implementation of the 802.11 protocol stack, the concept of transmitting 802.11 frames in coaxial cable media with different frequency bands using WLANs with modified WLAN (Wireless Local Area Network) chip sets has been proposed. Therefore, a TDF (Time Sharing Function) protocol is established to replace the traditional 802.11 DCF (Distributed Coordination Function) or PCF (Point Coordination Function) mechanism in the MAC (Media Access Control) layer for this application. As mentioned above, this TDF protocol is based on TDMA (Time Division Multi-Direction), which allows multiple users to share the same channel by dividing the same channel into different time slots. The TDF STAs quickly and successively transmit uplink traffic, each of which uses its own time slot in one of the TDF super-frames assigned by the TDF AP (access point). For downlink traffic, the STAs share the channel and select the frame to target by comparing the destination address information in the frame with the address of interest. Figure 5 illustrates time slot allocation for a typical TDF hyperframe when there are m (= tdfUplinkTimeSlotNumber) STAs that are simultaneously competing for uplink transmission opportunities.

As shown and described with respect to FIG. 5, there is a time slot of a fixed number of TDF frames (tdfTotalTimeSlotNumber), which is composed of: one for transmitting the clock step information from the TDF AP to the TDF STA ( 1) Synchronous time slot, one of the registration requests for transmitting the time slot allocation for the uplink (1) the competition time slot, the tdfUplinkTimeSlotNumber uplink used by the registered TDF STA to transmit data and some management frames to the TDF AP. The link time slot, and the tdfDownlinkTimeSlotNumber downlink time slot used by the TDF AP to transmit data and some management frames to the STA. Except for the sync slot, all other slots known as the common slot have the same duration and have a length equal to tdfCommonTimeSlotDuration.

The duration value of tdfCommonTimeSlotDuration is defined to allow transmission of at least one maximum 802.11 PLCP (Physical Layer Convergence Protocol) Protocol Data Unit (PPDU) for use in one of the highest rate data patterns. The duration of the synchronization slot tdfSyncTimeSlotDuration is shorter than the duration of the common time slot because the clock synchronization frame transmitted from the TDF AP to the TDF STA in the slot is shorter than the 802.11 data frame.

Therefore, the duration of a TDF hyperframe defined as tdfSuperframeDuration can be calculated by the following equation:

tdfSuperframeDuration=tdfSyncTimeSlotDuration+tdfCommonTimeSlotDuration*(tdfTotalTimeSlotNumber-1)

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

tdfTotalTimeSlotNumber=tdfUplinkTimeSlotNumber+tdfDownlinkTimeSlotNumber+2

In practical applications where a WLAN chipset with reduced frequency bands is used to provide data transmission over a CATV access network, there are typically two applications. An application uses this solution to provide Internet access, so users must be assigned a guaranteed time slot to achieve constant data rate and QoS (quality of service). Another application uses this solution to transmit sporadic uplink traffic from the user side to the headend, such as user control messages in a VoD (Video on Demand) application of a digital TV service.

Using the above proposed MAC layer mechanism, the STA uses an AP registration to first acquire an uplink time slot, and then transmits such control information in each slot allocation time slot. However, because the traffic for such applications is extremely low, the STA needs to use a very small portion of the time slot for data transmission, and even, even if it is used to support such applications with sporadic traffic. There are still no traffic to be transmitted during the number of consecutive hyperframes of the TDF STA. Therefore, those skilled in the art will appreciate that in some scenarios, it may be quite wasteful to support this second application using a purely time-sharing media access method previously established and known in the TDF protocol.

According to other known embodiments, TDF STAs with sporadic uplink traffic to be transmitted and TDF AP registrations for uplink time slot allocation will use DCF during the contention-based uplink time slot. The mechanism transmits uplink traffic to the TDF AP.

However, due to the inherent nature of the DCF mechanism, it is possible that a TDF STA will have a greater chance of accessing the channel for uplink traffic transmission than the STA if it always uses a smaller contention window to obtain transmission opportunities. . Moreover, a fair distribution of transmission opportunities cannot be achieved among such TDF STAs that use a contention based media access method for uplink traffic.

This disclosure suggests at least two TDFs to support data services and sporadic user control messages over the cable access network. The first type of TDF uses both polling and time-sharing media access, and the second type of TDF uses a hybrid mechanism to obtain the upstream channel. Variations and other combinations, such as the use of polling and a competition-based hybrid mechanism, are imaginary and part of this disclosure.

Referring to Figure 21, in order to provide support for both high data rate services with QoS support and other services with sporadic data traffic and latency tolerance characteristics, an advanced technology TDF is shown that includes and accesses uplink channels. Both polling and time-sharing media access mechanisms.

The suggested TDF with polling and time-sharing media access adds a time slot (eg, a polling slot) to one of the time slots used in the TDF program previously implemented in the TDF hyperframe.

As shown in FIG. 21, there is a time slot of a fixed number of TDF frames (tdfTotalTimeSlotNumber), and the detailed function series for each of the time slots included therein is as follows:

One (1) sync slot. This synchronization slot of the synchronization time slot is used to transmit clock synchronization information from the TDF AP to the TDF STA.

One (1) registration slot. The registration slot (ie, the registration slot) is used by the TDF STA to transmit a registration request to the TDF AP. In the registration request frame body, the TDF STA will inform the AP of its operation mode, polling mode or time-sharing mode to obtain an uplink transmission request.

One (1) polling slot. During this time slot, TDF STAs with occasional uplink traffic to transmit and not using TDF AP registration for uplink time slot allocation will transmit uplinks using the specific PCF (Point Coordination Function) mechanism detailed below. Link traffic to the TDF AP.

Downlink time slot. The slots include tdfDownlinkTimeSlotNumber downlink time slots, which are used by the TDF AP to transmit data and some management frames to the TDF STAs.

Time-sharing uplink time slot. These slots contain tdfUplinkTimeSlotNumber uplink time slots, which are used by the registered TDF STA to successively transmit data and some management frames to TDF APs with high data rate and QoS support.

The durations for the synchronization time slot, the registration time slot, the polling time slot, the downlink time slot, and the time-sharing uplink time slot are, in most cases, different from each other, depending on the requirements of the particular application. However, each uplink time slot referred to as a common time slot in the tdfUplinkTimeSlotNumber time slot has the same duration equal to tdfCommonTimeSlotDuration.

Therefore, the duration of a TDF hyperframe defined as tdfSuperframeDuration can be calculated by the following equation:

tdfSuperframeDuration=tdfSyncTimeSlotDuration+tdfRegTimeSlotDuration+tdfPollingTimeSlotDuration+tdfCOmmonTimeSlotDuration*(tdfTotalTimeSlotNumber-3)

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

tdfTotalTimeSlotNumber=tdfUplinkTimeSlotNumber+tdfDownlinkTimeSlotNumber+3.

Enhanced PCF program during polling time slot

For STAs in this TDF having both polling and time-sharing media access mechanisms, various implementations include two modes of operation: one is a polling mode; and the other is a time-sharing mode.

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

Basic access

The PCF mechanism in the slot provides poll-free frame transmission. Referring to FIG. 23, a PC (Point Coordinator) 2302 is resident in the TDF AP 2300. The form of the polling mode support provided by the AP 2300 is identified in the capability information field of the beacon frame transmitted from the APs. The TDF STA 2304, which requires poll-based media access, should be able to respond to the contention-free polling (CF polling) received from an AP 2300, and is therefore referred to as CF-capable polling. When polled by PC 2302, the CF pollable STA will transmit only one MPDU (MAC Protocol Data Unit), which will be transmitted to the AP and does not need to be acknowledged by the AP. An AP never polls STAs that are not in the polling list of this AP.

Frames transmitted by an AP or STA during the polling slot will use the appropriate frame type according to the following usage rules:

1-CF polling, which is transmitted by only one AP to the CF-capable STA. In this frame, the AP is not transmitting data to the address recipient, and the address recipient is allowed to transmit the next STA during the polling time slot; and 2-data and null frames can be any CF Poll the STA transmission.

The AP gets media control at the beginning of the polling slot and attempts to maintain control of the entire polling slot. It does not require the start and end of the polling slot to be signaled by the end of each AP transmitting a beacon and CF, as required in the classic PCF protocol.

When there is an entity in the polling list, the AP will transmit a CF poll to at least one STA during each polling slot. During each polling slot, the AP will issue a poll to a subset of the STAs on the polling list in order from beginning to end.

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

The AP then resumes control after receiving a data or null frame from the particular CF-capable STA (2508), or after receiving a response to the CF poll from a particular STA within a predefined period immediately following the AP transmission. The next CF round inquiry frame can be transmitted to the next entity in the polling list, unless there is insufficient time during the current polling period. If at this time, it has reached the last item in the polling list, the AP will try to transmit the CF round inquiry frame to the STA from the first item in the polling list next time. If the current polling period does not hold enough time (2510) to allow the polling STA to transmit the data frame containing the minimum length MPDU, the AP will not issue a CF round inquiry frame. Conversely, if the last item in the STA list has been polled at the beginning of the polling time slot during the next hyperframe, the AP begins to issue a CF round inquiry frame to the polled STA of the polling list. The next item in the box, or the first item in the polling list.

Referring to Figure 24, all CF-capable STAs in the polling mode associated with this AP should not transmit any uplink traffic unless it is polled by the AP during this polling slot. One of the polling modulo CF polling STAs always responds to a CF poll that is directed to its MAC address and received without error. It will transmit a data frame immediately after receiving the CF poll. If there is no frame to be transmitted when the STA polls, the response will be a null frame. The polling STA will respond by transmitting a null frame before polling the polling sequence.

Polling list maintenance

The AP will maintain a "Polling List" for selecting STAs that meet the conditions for receiving CF polls during the polling slot and for the CF to poll the STA for polling. The polling list can be used to control the use of the CF polling type for transmitting the data frame transmitted by the AP to the CF-capable STA.

Once an AP receives a registration request frame from a STA, where the STA needs to access the channel using a polling mechanism, and the AP decides to authorize the STA to transmit the mechanism according to the setting policy in the AP, the AP will Add an item 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 unregistered frame from a STA indicating that it will not access the channel using the polling mechanism, the AP will delete the corresponding entry in the polling list for this STA. If a STA needs to change from a time-sharing mode to a polling mode, the STA will notify the AP by transmitting a non-registration to abandon the time-sharing mode and then transmitting a registration request with a polling mode indication to the AP.

Referring to FIG. 22, in order to enjoy the flexibility provided by the DCF and the fairness provided by the PCF, a hybrid medium access mechanism for uplink traffic is also described, which uses both DCF and PCF for the STA to obtain For sporadic traffic transmission opportunities, and dedicated time slots for STAs to transmit high data rate traffic. A detailed time slot allocation for this enhanced TDF hyperframe is illustrated in FIG.

As shown, there are fixed tdfTotalTimeSlotNumber time slots per TDF hyperframe, and the detailed functional series for each of the time slots contained therein are as follows:

One (1) sync slot. This synchronization slot of the synchronization time slot is used to transmit clock synchronization information from the TDF AP to the TDF STA.

A (1) contention-based uplink slot. During this slot, the TDF STA can transmit a registration request to the TDF AP. In the registration request frame body, the TDF STA will inform the AP of its operation mode, polling, contention-based or time-sharing mode to obtain an uplink transmission request. At the same time, TDF STAs with occasional uplink traffic to transmit and not using TDF AP registration for uplink time slot allocation will use the specific DCF mechanism to transmit uplink traffic to the TDF AP.

One (1) polling slot. During this time slot, a TDF STA with occasional uplink traffic to transmit and no TDF AP registration for uplink time slot allocation will transmit uplink traffic to the TDF using the specific DCF mechanism previously described. AP. In general, the TDF STA can inform the TDF AP of its mode of operation (ie, DCF or PCF) by setting a corresponding flag transmitted by the TDF STA to the associated request frame of the TDF AP.

Downlink time slot. The slots include tdfDownlinkTimeSlotNumber downlink time slots, which are used by the TDF AP to transmit data and some management frames to the TDF STAs.

Time-sharing uplink time slot. These slots contain tdfUplinkTimeSlotNumber uplink time slots, which are used by the registered TDF STA to successively transmit data and some management frames to TDF APs with high data rate and QoS support.

The durations for the synchronization time slot, the contention base time slot, the polling time slot, the downlink time slot, and the time-sharing uplink time slot are, in most cases, different from each other, depending on the requirements of the particular application.

Therefore, the duration of a TDF hyperframe defined as tdfSuperframeDuration can be calculated by the following equation:

tdfSuperframeDuration=tdfSyncTimeSlotDuration +tdfContentionTimeSlotDuration+tdfPollingTimeSlotDuration+tdfCommonTimeSlotDuration*(tdfTotalTimeSlotNumber-3).

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

tdfTotalTimeSlotNumber=tdfUplinkTimeSlotNumber+tdfDownlinkTimeSlotNumber+3.

The present principles suggest a TDF that uses both contention-based and time-sharing media access to obtain uplink channels to support data services on the cable access network and occasional user control messages.

In order to provide support for both high data rate services with QoS support and other services with sporadic data traffic and latency tolerance characteristics, an advanced technology TDF is shown that includes competition for uplink channel access. Basic and time-sharing media access mechanisms. The functional description of this TDF protocol using the mixed media access method is described in detail below.

Access method

A TDF that uses both the competition-based and time-sharing media access of the present principles adds a time slot (e.g., a registration slot) to the previously disclosed TDF procedure. A detailed time slot allocation for this enhanced TDF hyperframe is illustrated in FIG.

As shown in Fig. 26, there is a time slot of a fixed number of TDF frames (tdfTotalTimeSlotNumber), and the detailed functions for each of the time slots included therein can be enumerated as follows:

- One () sync slot. This synchronization slot of the synchronization time slot is used to transmit clock synchronization information from the TDF AP to the TDF STA.

- One (1) registration slot. The registration slot (i.e., the registration time slot) that can be compared to the contention time slot in the hyperframe structure illustrated in Figure 5 is used by the TDF STA to transmit a registration request to the TDF AP for uplink time slot allocation.

- One (1) contention based uplink time slot. During this time slot, TDF STAs with occasional uplink traffic to transmit and not using TDF AP registration for uplink time slot allocation will transmit uplink traffic to the specific DCF mechanism as described in detail below. TDF AP.

- Time-sharing uplink time slot. These slots contain tdfUplinkTimeSlotNumber uplink time slots, which are used by the registered TDF STA to successively transmit data and some management frames to TDF APs with high data rate and QoS support.

- Downlink time slot. The slots include tdfDownlinkTimeSlotNumber downlink time slots, which are used by the TDF AP to transmit data and some management frames to the TDF STAs.

In one embodiment, the registration slot and the contention-based uplink time slot can be combined into a mixed time slot to improve system performance. This improvement will be due to the fact that both slots use a contention-based fallback method for channel access and in most cases there may be few traffic during the registration slot. In addition, the CWmin and CWmax of the contention window for the registration request can be defined as less than the CWmin and CWmax of the contention window for the data frame respectively, so as to provide a higher priority for the transmission of the registration request frame than the transmission of the data frame. right.

Those skilled in the art should recognize that "competition window" is for the 802.11 standard and indicates how many hours the STA will wait (eg, 9us) before attempting to access the wireless medium and then decide whether the medium is available to the user for transmission of data. By way of example, an accurate competition window is initially determined by selecting a random number of backoffs between 0 and CWmin. Each time the back-off period expires, indicating that the channel is still busy, the STA will randomly select another back-off period between 0 and a number of [CWmin, CWmax] in an incremental manner until 0 and CWmax are selected. The last back cycle between.

CWmin and CWmax defined by the competition window for the registration request frame are smaller than CWmin and CWmax for the competition window respectively used for the data frame, ie (CWmin for registration) <(CWmin for data frame) And (CWmax for registration) < (CWmin for data frame), ensuring priority over the transmission of the registration request frame of the transmission of the data frame. As explained below, this higher priority is due to the smaller number of backoff periods available during the smaller contention window.

The durations for synchronization time slots, registration time slots, contention-based time slots, time-sharing uplink time slots, and downlink time slots are, in most cases, different from each other, depending on the requirements of the particular application. . However, each uplink time slot referred to as a common time slot in the tdfUplinkTimeSlotNumber time slot has the same duration whose length is equal to tdfCommonTimeSlotDuration.

Therefore, the duration of a TDF hyperframe defined as tdfSuperframeDuration can be calculated by the following equation:

tdfSuperframeDuration=tdfSyncTimeSlotDuration+tdfRegTimeSlotDuration+tdfContentionTimeSlotDuration+tdfCommonTimeSlotDuration*(tdfTotalTimeSlotNumber-3).

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

tdfTotalTimeSlotNumber=tdfUplinkTimeSlotNumber+tdfDownlinkTimeSlotNumber+3.

In addition, the number of allocated uplink time slots of the TDF STA in a TDF hyperframe can be changed from 0 to tdfMaximumUplinkTimeSlotNumber. Therefore, the available duration of the downlink time slot in a TDF hyperframe can be

(tdfCommOnTimeSlotDuration*(tdfTotalTimeSlotNumber-3)) changed to

tdfCommonTimeSlotDuratiOn*(tdfTotalTimeSlotNumber-3-dfMaximumUplinkTimeSlotNumber)).

Each time there is a TDF STA that requires an uplink time slot, the TDF AP will infer one or more common time slots from the available downlink time slots, and then assign the time slots to the TDF STA as long as the uplink The link time slot will not exceed tdfMaximumUplinkTimeSlotNumber after it.

Furthermore, although the duration of the slot for the downlink is equal to (tdfCommonTimeSlotDuration tdfDownlinkTimeSlotNumber), it is not necessary to have the guard time between the boundaries of such common time slots, since the downlink is stable and independent from each other. The AP transmits the traffic. In this way, the downlink transmissions in this protocol will be highly efficient and channel efficient.

Enhanced DCF procedure for contention-based uplink time slots

For STAs in this TDF with both contention-based and time-sharing media access mechanisms, several implementations have two modes of operation: one is based on competition and the other is time-sharing.

The basic media access method for STAs operating in a contention-based mode of uplink traffic transmission is a DCF defined in the 802.11 specification, which allows for the use of CSMA/CA (Carrier Detect Multiple Collision Avoidance) And automatic media sharing with random back-off times after busy media conditions. However, several improvements to this classical DCF mechanism have been made due to the specific environment of data transmission on the fixed line.

Random back procedure

A TDF STA that needs to initiate transmission of the frame invokes a carrier detection mechanism (in most cases, physical carrier detection) to determine the busy/idle state of the media. If the media is busy, the STA is deferred until the media system decides to be idle and not interrupted during the defined time period. After this media idle time, the STA generates a random backoff period for the additional delay time before transmission, unless the back-off timer already contains a non-zero value, in which case the selection of the random number is unnecessary and not implemented. This procedure minimizes collisions during competition between multiple STAs that have been deferred to the same event.

Back time = Random()*aSlotTime

among them

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

The set of CW values will be a sequence of 2 increments of the integer power minus 1, starting with the special application aCWmin value and continuing upwards and including a special application aCWmax value. More specifically, for most of the application environment for this agreement, the maximum number of STAs in the competition-based model (which is tdfMaximumContentionStationNumber) is known in advance and can be manually configured and/or broadcast from TDF APs. The management frame is notified to the TDF STA, so the value can be set to a multiple of tdfMaximumContentionStationNumber or tdfMaximumContentionStationNumber. Therefore, the STA can access the physical medium after a relatively short back-off time when compared to the condition in which the aCWmax value is blindly set.

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

Confirmation procedure

For TDF STAs operating in time-sharing mode, the STA-derived frame is switched in a wired environment rather than over the air during the uplink time slot allocated for this particular STA, so it is based on excellent signal quality. Transfer without competition. Therefore, it is not necessary to define an acknowledgment (ACK) frame to ensure the reliability of the delivery of the MAC frame.

However, for TDF STAs operating in a competition-based mode, because of the difference between the wired environment and the wireless channel, the physical carrier sensing mechanism does not work extremely well in the fixed line, so the hidden table problem will be Many collisions among different TDF STAs are caused in the competition mode. As a way to combat such failures, this principle recommends the use of a positive confirmation mechanism.

Therefore, there are two types of confirmations that can be used for configuration:

1. When the AP receives an uplink frame originating from a TDF STA in the contention mode, it immediately acknowledges from the TDF AP, and therefore, if the ACK is not received, it is retransmitted by the TDF STA schedule.

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

The immediate block ACK is immediately transmitted by the TDF AP after being a number of uplink frames from a TDF STA in the contention mode, and is suitable for high frequency wide and low latency traffic.

The delay block ACK is transmitted by the TDF AP at the beginning of the downlink time slot in the same hyperframe as the contention-based uplink time slot in response to the TDF during the time slot based on the specific contention. Several successfully transmitted uplink frames transmitted by the STA. It is appropriate for applications that tolerate moderate latency and will be used for most of this TDF protocol with contention-based and time-sharing media access control. The block ACK frame may be a unicast frame in a competition mode to a specific TDF STA to notify it of successful reception of its uplink frame, and may also be a broadcast or multicast frame for notification. The number of TDF STAs in the contention mode successfully received from the uplink frames of the STAs.

Operating mode conversion program

Once a TDF STA is initiated (eg, after initialization), it enters a competition-based mode by default. Then, depending on its application requirements, configuration, and/or service provider's service level agreement, it can enter the time-sharing mode after transmitting the registration frame to the TDF AP and receiving the registration response with access permission.

The transition from a competition-based mode to a time-sharing mode is illustrated in FIG. As shown, when in the competition-based modulo 2710, it is decided (2712) whether or not it is necessary to enter the time-sharing mode. When the answer is yes, then it is determined (2714) whether a positive response has been received after the TDF STA has transmitted a registration request to the TDF AP. If a positive response has been received, then the time sharing mode 2716 is entered. If the decision 2712 or 2714 produces a negative response, the system remains in the competition-based modulo 2710.

In contrast to the embodiment shown in Figure 27, a TDF STA can enter a competition-based mode from a time-sharing mode during its operation. This concept is illustrated in FIG. As shown, when in time-sharing mode 2802, it is determined (2804) whether a competition-based mode is required. If necessary, a non-registration request is transmitted (2806) and a competition-based modulo 2808 is entered. If it is not necessary to enter a competition-based mode (2804), the system remains in the time-sharing mode 2802.

It should be noted that similar procedures can be applied to the polling implementation. For example, an embodiment can switch between polling mode and time-sharing mode as needed.

As explained above, in order to provide a cost effective two-way data transmission solution over existing coaxial cable access networks, a method has been established that uses a mature commodity WiFi wafer set with external frequency conversion circuitry for frame delivery. The system using this method is called an ADoC (Asymmetric Coaxial Cable Data) system in which a TDF (Time Sharing Function) protocol must be configured in the cable access network to comply with ADoC Access Points (APs) and Stations (STAs). The terms "ADoC system" and "TDF system" as used herein are interchangeable. APs and STAs are connected via a splitter in a hierarchical tree structure (see Figure 1). In this way, users at home can access the remote IP core network via a cable access network. The detailed network layout is illustrated in Figure 1.

In this typical infrastructure access network architecture, there is a TDF protocol adaptation ADoC (TDF) access point (AP) with an Ethernet interface through which the AP is connected to the IP core network. And a coaxial cable interface through which the AP is connected to the cable access network. At the other end of the access network, there is a TDF protocol-adaptive ADoC (TDF) STA that is connected to the cable access network via a coaxial cable interface and via a wireless interface (such as a WLAN (Wireless Local Area Network) interface). Or a wired interface (such as an Ethernet interface) to connect to a resident LAN (local area network).

Referring to Figure 29, an inventive embodiment of a hardware implementation for an ADoC STA 2900 integrates two devices (an ADoC device 2903 and a WLAN device 2904) into an integrated STA. The ADoC device 2903 will interface with a coaxial cable interface 2906 to support bidirectional data communication in the cable network, while the WLAN device 2904 will interface with an antenna 2908 to support bidirectional data communication in the WLAN network. The STA 2900 will exchange the data frame between the ADoC device 2903 and the WLAN device 2904 as needed to enable the PC in the WLAN network to access the Internet via the ADoC STA.

The STA presented in Figure 29 requires two separate devices for channel encoder/decoder and data processing to provide Internet access for personal computers in a home WLAN. The present principles provide a solution that utilizes a separate dual mode device and can periodically switch between the ADoC mode and the WLAN mode to provide the same access functionality for the regional network.

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

By using a single dual-mode device solution of the present principles, rather than two of the classic solutions shown in Figure 29, the ADoC STA embedded in the dual-mode ADoC device can provide Internet access to the local area network. Features. Thus, the manufacturing cost of an ADoC STA with Internet access support via a cable access network can be reduced by almost half of the original cost compared to the classic solution of the two devices shown in FIG.

To implement the dual mode device 2902 of the present principles, a standard ADoC device 2903 is modified and developed in accordance with a mature WLAN device. It differs primarily from the WLAN device 2904 in two aspects: 1) in a physical implementation, the RF operates in the ADoC band (about 1 GHz) instead of the standard 802.11 band (about 2.4 GHz); and 2) in the MAC ( In the Media Access Control layer, it does not utilize traditional 802.11 DCF (Distributed Coordination Function) or PCF (Point Coordination Function) mechanisms to exchange MAC frames. Instead, it uses the TDF protocol, which is based on a Time Division Multi-Direction Near (TDMA) method to transmit MAC frames.

As shown in FIG. 30, dual mode ADoC device 2902 will be coupled to a coaxial cable interface 2906 for interconnection with a cable access network and simultaneously coupled to an antenna 2908 to support bidirectional data communication in a WLAN network. The ADoC STA 2900 will exchange data frames received from this dual mode ADoC device 2902 during the two modes as needed.

Hardware architecture of dual-mode ADoC devices

In accordance with one of the hardware implementations of dual mode ADoC device 2902 shown in FIG. 31, a switch 3102 is provided that is configured to switch between WLAN RF circuit 3104 and ADoC RF circuit 3106. The switch 3102 can be controlled by the MAC layer software. This embodiment requires modifying the WLAN wafer set and adding switch 3102 to the modified wafer set.

According to another hardware embodiment shown in Figure 32, the position of switch 3102 can be changed in proximity to the MAC baseband portion 3100 of the device. In this embodiment, converter 3108 reduces the WLAN band (which is the output of WLAN RF 3104 and is about 2.4 GHz) to the ADoC spectrum (which is about 1 GHz) and can reach a relatively long distance in the coaxial cable. It should be noted that the MAC baseband portion 3100 can 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 embodiment of Figure 31, the embodiment of Figure 32 is external to the existing WLAN chip set, and as such does not require modification of the WLAN chip set.

MAC layer program for dual mode ADoC devices

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

As shown in FIG. 34, there is a time slot of a fixed number of TDF frames (tdfTotalTimeSlotNumber), which is composed of the following items: one synchronization time slot for transmitting clock synchronization information from the ADoC AP to the ADoC STA, a competing time slot for transmitting a registration request for uplink time slot allocation, tdfUplinkTimeSlotNumber uplink time slots used by the registered ADoC STA for successive transmission of data and some management frames to the ADoC AP, and by the ADoC AP The tdfDownlinkTimeSlotNumber downlink time slot used to transmit data and some management frames to the STA.

With this TDF protocol, the dual mode ADoC device 2902 in the STA mode will be active only during the synchronization slot, the contention time slot, the allocation uplink time slot (e.g., time slot k), and the downlink time slot. In the remaining time slots (ie, from time slot 2 to time slot k; and from time slot k to time slot m), the dual mode ADoC device in the STA mode will be inactive in the ADoC interface portion and thus Switching to the WLAN AP mode is present in the presence of a switch that can be controlled to change the operational RF from the ADoC band to the WLAN band.

The detailed MAC layer procedure in the dual-mode ADoC device is as follows:

1. Once an ADoC STA is enabled and successfully allocates an uplink time slot for uplink traffic transmission, such as time slot k, the dual mode device will calculate whether k>(m+2)/2 . If , the duration of _{[time slot 2, time slot k)} indicated by T _{[time slot 2, time slot k)} is at least equal to that indicated by T _{(time slot k, time slot m} ] _{(time slot k, time slot} ) m] duration. Therefore, the dual-mode ADoC device will choose to operate in the WLAN mode during the [time slot 2, time slot k) period. On the other hand, if k < (m + 2) / 2, then its meaning It means that T[ _{time slot 2, time slot k} ) is shorter than T _{(time slot k, time slot m)} . Therefore, the dual-mode ADoC device will choose to operate in the WLAN mode during the [time slot k, time slot m) period. .

It should be noted that determining whether the period [slot 2, slot k) > period (slot k, slot m) yields a criterion (k-2) > (mk), which in turn produces a criterion k > (m + 2)/2. In the illustrated embodiment, the WLAN model is selected for longer periods. However, other embodiments operate in the WLAN mode during shorter periods or multiple times between modes in the hyperframe.

2. For other time slots in a TDF frame, in the case where the dual mode ADoC device decides to operate in the WLAN mode during the [Time slot 2, time slot k) period, the dual mode ADoC device will be in the ADoC mode. The operation is an ADOC STA and acts in a manner consistent with the standard ADoC TDF protocol. Therefore, when the dual mode ADoC device enters the time slot 2 in the ADoC mode, it will configure the RF switch 3102 to change the operating frequency to the WLAN spectrum and act as a WLAN AP. Therefore, the dual mode STA can communicate with the WLAN STA in the resident WLAN network according to a standard WLAN procedure.

Over time and closer to slot k, and before time slot k begins to show no time for at least one WLAN frame, dual mode device 2902 will transmit a CTS (clear transmission) signal to the resident WLAN. All STAs. The duration field in the CTS frame will be equal to the duration from time slot k in the superframe to time slot 2 in the next hyperframe. After receiving the CTS message, all STAs will update their NAV and stop accessing the WLAN media for the duration reported by the CTS message. In this way, the dual mode device will cause all STAs to move from the time slot k in the superframe to the time slot 2 in the next superframe by pretending another entity to save the WLAN media for the duration. Keep quiet during the cycle. Thereafter, the device will control the switch to change the operational spectrum back to the ADoC band and operate in accordance with the TDF procedure.

When the dual mode device 2902 enters the time slot 2 of the next hyperframe, the device 2902 will repeat the same mode switch procedure and the STAs resident in the WLAN will also begin to use this available infrastructure WLAN to communicate again because The quiet duration indicated by the CTS expires at the same time.

Conversely, for the dual mode ADoC device to determine operation in the WLAN mode during other time slots (time slot k, time slot m) periods for use in a TDF superframe, the dual mode ADoC device will be in the ADoC The operation in the modulo is a STA. When the dual mode ADoC device 2902 enters the time slot (k+1) in the ADoC mode, it will configure the switch 3102 to change the operating frequency to the WLAN spectrum and act as an AP. Once it is passed over time slot (m-1), the dual mode device will try to transmit the CST signal during time slot m, the duration field is equal to the downlink from this superframe The duration from the start of the time slot to the time slot (k+1) in the next superframe. Thereafter, dual mode device 2902 will control switch 2002 to change the operational spectrum to the ADoC band and operate in accordance with the ADoCTDF procedure. Therefore, when the dual mode device enters the time slot (k+1) in the next superframe, it will again perform the same mode switching procedure, as explained above.

According to one embodiment, the dual mode device 2902 of one embodiment of the present principles is integrated into a data machine (e.g., 1010, 1020, etc.) from FIG. Figure 33 shows an example of this embodiment. Likewise, when the dual mode device 2902 is operating or performing standard WLAN communications (i.e., when operating during an appropriate time period), the device allows the user PC to connect to the Internet. In this embodiment, the PC user will request an internet address (eg, a web page) by transmitting a request for the internet address to the data machine over the wireless medium via a WLAN interface, and 2) The modem relays the request over the cable network over the cable network to the ADoC AP, then to the router, and then to the Internet.

In this embodiment, dual mode device 2902 includes an ADoC interface or device 1018 rather than an Ethernet interface.

When the dual mode device of the data machine operates in a WLAN (ie, wireless mode), the device acts as a WLAN AP, and the personal computer acts as a WLAN station, wherein the dual mode device wirelessly communicates with the personal computer through the data machine The link receives the request from the personal computer. The dual mode device relays a request to the bridge, and the bridge determines whether the dual mode device needs to transmit the request in the cable via an ADoC interface in the dual mode device, or according to an IP packet for the request The destination address information in the middle transmits the request to other PCs in the resident network. The bridge then passes the request down to the dual mode device.

In order for the request to establish an external connection, the dual mode device maintains the request until the dual mode device enters the ADoC mode (ie, the wired mode), at which time the dual mode device acts as an ADoC station and transmits over the wired network via the ADoC interface. The request is sent to the ADoC AP.

In order for the request to be established internally with one of the other PCs in the resident network, the dual mode device maintains the request until the dual mode device enters the WLAN mode (ie, the wireless mode), at which point it acts as a WLAN AP and via the WLAN. The request is transmitted to the destination PC on the wireless medium.

The reverse program is implemented when the dual mode device receives any response from an associated ADoC AP in the cable network or other PC in the regional network.

As is apparent from the above description, in at least some embodiments, a common circuit or software (for example) can be used to perform most of the processing associated with the WLAN mode and the ADoC mode. For example, the reception and de-packetization of data from two modes and the conversion between two modes can be performed by a common circuit. Various applications that may require this conversion include (1) receiving a WLAN mode item from a computer (eg, a request for Internet access) and transmitting the data machine using the ADoC module, and (2) receiving the ADoC The modem requests the internet data and uses the WLAN module to transmit the data to a modem of a computer. These scenarios will typically involve conversions between different agreements.

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

It should be noted that a modem may include not only a dual mode device as described above, but also an interface to enable communication across other networks (other than WLAN and ADoC). Such other networks may include (eg, an Ethernet). Thus, a modem can include, for example, a dual mode device 2902 that enables communication across the WLAN and ADoC networks as well as the Ethernet interface 1015.

Various embodiments, for example, access data in one form or another. The term "access" is used as a broad term to include, for example, obtain, capture, receive, manipulate, or process in a manner. Accordingly, the description of the access data (for example) is a broad description of a possible implementation.

The features and aspects of the illustrated embodiments can be applied to a variety of applications. Applications include, for example, an individual using a host device in their home to communicate with the Internet using an on-board Ethernet communication framework, as explained above. However, the features and states described herein can be adapted for other applications. Areas, and therefore other applications are feasible and envisioned. For example, a user can be positioned outside of their home, for example, in a public space or in their work. In addition, protocols and communication media other than Ethernet and cable can be used. For example, on 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. (and use the agreement associated with it) to transmit and receive data.

The embodiments described herein may be implemented, for example, in a method or program, a device, or a software program. Even if only described in the context of a single form of the embodiments (e.g., only as a method), embodiments of the described features may be implemented in other forms (e.g., a device or program). A device can be implemented, for example, in a suitable hardware, software, and firmware. The method can be implemented, for example, in a device, such as a processor generally referred to as a processing device, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processing devices also include communication devices such as computers, mobile phones, portable/personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end users.

Embodiments of the various programs and features described herein can be embodied in a variety of different devices or applications, particularly in devices or applications associated with, for example, data transmission and reception. Examples of devices include video encoders, video decoders, video codecs, web servers, transponders, laptops, personal computers, and other communication devices. It should be clear that the device can be mobile and even installed in a car.

In addition, the method can be implemented by instructions executed by a processor, and such instructions can be stored in a processor readable medium, such as an integrated circuit, a software carrier or other storage device, such as a A hard disk drive, a compact disc, a random access memory ("RAM") or a read-only memory ("ROM"). The instructions can form an application that is tangibly embodied in the processor readable medium. It should be clear that a processor can include a processor readable medium having, for example, instructions for implementing a program.

With regard to storage devices, it should be noted that the various devices in the overall illustrated embodiment typically include one or more storage devices. For example, although not explicitly indicated, data machines 1010 and 1020 and AP 1030 (and various other components) typically include one or more storage units for storing material. Storage can be, for example, electronic, magnetic or optical.

It will be apparent from the above disclosure that embodiments can also produce signals that are formatted to carry information that can be stored or transmitted, for example. The information may include, for example, instructions for implementing a method, or data generated by one of the illustrated embodiments. This signal can be formatted as, for example, an electromagnetic wave (e.g., using one of the radio frequency portions of the spectrum) or a baseband signal. The formatting can include, for example, encoding a data stream, packetizing the encoded stream according to any of the various frame structures, and employing a packetized stream to modulate a carrier. The information carried by the signal can be, for example, analog or digital information. This signal can be transmitted over a variety of different wired or wireless links, as is known.

900. . . network

910. . . User home

912. . . Data machine

914. . . Host 1

916. . . Host 2

918. . . Ethernet

920. . . User home

922. . . Data machine

924. . . Host 1

926. . . Host 2

928. . . Ethernet

930. . . Internet

940. . . AP

950. . . Cable system

960. . . router

970. . . Ethernet

1010. . . Data machine #1

1011. . . Regional application layer

1012. . . TCP/IP layer

1014. . . Bridge

1015. . . Ethernet interface

1016. . . PADM

1017. . . WLAN interface

1018. . . Device

1020. . . Data machine #N

1030. . . AP

1040. . . Cable network

1052. . . Ethernet

1054. . . First host

1056. . . Second host

1062. . . Ethernet

1064. . . First host

1066. . . Second host

1071. . . Regional application layer

1072. . . TCP/IP layer

1074. . . Bridge

1075. . . WLAN interface

1076. . . PADM

1077. . . Ethernet interface

1082. . . Ethernet

1090. . . router

1095. . . Internet

1210. . . Ethernet packet

1220. . . Ethernet network road sign

1230. . . Data section

1240. . . WLAN packet

1250. . . WLAN header

1260. . . Frame check sequence (FCS)

1310. . . Ethernet packet

1312. . . Ethernet packet

1314. . . Ethernet packet

1318. . . WLAN packet

1320. . . Ethernet network road sign

1322. . . Ethernet network road sign

1324. . . Ethernet network road sign

1326. . . Data section

1328. . . Data section

1329. . . Data section

1330. . . Expand the Ethernet packet

1332. . . Expand the Ethernet packet

1334. . . Expand the Ethernet packet

1336. . . Data section

1338. . . Data section

1340. . . Data section

1342. . . Header

1343. . . Header

1344. . . Header

1346. . . end

1347. . . end

1348. . . end

1350. . . EIW package

1352. . . Data section

1353. . . Data section

1354. . . Data section

1356. . . Header

1358. . . end

1360. . . Data section

1362. . . WLAN MAC header

1364. . . FCS

1410. . . Enter queue

1420. . . string

1430. . . EIW header

1440. . . WLAN header

1530. . . Packet descriptor

1540. . . Packet descriptor

1550. . . Packet flag

1555. . . Packet flag

1560. . . Packet length

1565. . . Packet length

1710. . . Packet

1720. . . Packet

1730. . . Waiting queue

1740. . . Incomplete packet

1750. . . PADM

1760. . . Packetizer

1770. . . Depacker

2002. . . switch

2100. . . Frame structure

2110. . . Polling slot

2120. . . Time slot

2300. . . TDF AP

2302. . . PC

2304. . . TDF STA

2600. . . Frame structure

2610. . . Competitive time slot

2620. . . Time slot

2900. . . STA

2902. . . Dual mode device

2903. . . ADoC device

2904. . . WLAN device

2906. . . Coaxial cable interface

2908. . . antenna

3100. . . MAC baseband part

3102. . . switch

3104. . . WLAN RF circuit

3106. . . ADoC RF circuit

3108. . . converter

Figure 1 illustrates a simplified exemplary TDF access network architecture.

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

3 illustrates one implementation of a TDF transport entity in an OSI reference model.

Figure 4 illustrates one embodiment of a communication mode entry procedure.

Figure 5 illustrates one embodiment of a TDF hyperframe structure.

Figure 6 illustrates one implementation of a registration procedure.

Figure 7 illustrates one implementation of a non-registration procedure.

Figure 8 illustrates one implementation of an active notification procedure.

Figure 9 includes a system diagram depicting one embodiment of a TDF network.

Figure 10 includes a block diagram of one embodiment of an AP and a data machine from Figure 9.

Figure 11 includes a flow diagram of one embodiment of an uplink transmission procedure.

Figure 12 includes a diagram of one embodiment of a one-to-one mapping between an Ethernet packet and a WLAN packet.

Figure 13 includes a diagram of one implementation of a transition between multiple Ethernet packets and a single WLAN packet.

Figure 14 includes a diagram depicting the packet flow in the conversion of Figure 13.

Figure 15 includes a diagram of one embodiment of the EIW header from Figure 14.

Figure 16 includes a flow diagram of one embodiment of an uplink receiving procedure.

Figure 17 includes a diagram of an embodiment for decapsulating packets.

Figure 18 includes a diagram depicting one embodiment of a PADM from Figure 10.

Figure 19 includes a flow diagram of one embodiment of a downlink transmission procedure.

Figure 20 includes a flow diagram of one embodiment of a downlink receive procedure.

Figure 21 illustrates one embodiment of a TDF hyperframe structure employing both polling and time-sharing media access.

Figure 22 illustrates one embodiment of a TDF hyperframe structure with a hybrid media access mechanism.

Figure 23 illustrates a block diagram and SP and stations in a TDF network.

Figure 24 illustrates one embodiment of a polling notification procedure.

Figure 25 illustrates a flow chart of a polling procedure.

Figure 26 illustrates one embodiment of a TDF hyperframe structure with a hybrid media access mechanism.

Figure 27 illustrates a flow chart for a procedure for switching from a competition based mode to a time sharing mode.

28 illustrates a flow diagram of a procedure for switching from a time-sharing mode to a contention-based mode.

Figure 29 is a block diagram of a TDF (ADoC) STA.

Figure 30 is a block diagram of a TDF (ADoC) STA having a dual mode device in accordance with an embodiment.

Figure 31 is a block diagram of one of the hardware implementations of a TDF (ADoC) STA dual mode device.

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

Figure 33 is a block diagram of an embodiment of the dual mode device of the present principles in the data engine of Figure 10.

Figure 34 illustrates another aspect of a TDF hyperframe structure.

(no component symbol description)

Claims (22)

A communication method includes: using a frame structure (2100) for communication, the frame structure supporting at least two communication modes, the communication modes including a time-sharing mode and a polling mode, the time-sharing mode One of the slots in the frame structure is stored for a device, and one of the polling modules in the frame structure is used for data communication by a plurality of devices, wherein any one of the devices operates in the time division mode or The polling module. The communication method of claim 1, wherein the frame structure supports a third communication mode of a competition-based module, wherein one of the content frames in the frame structure is used for data communication by a plurality of devices. The communication method of claim 1, wherein the frame structure is part of a time division function (TDF) communication system. The communication method of claim 1, wherein: the use of the frame is performed by a TDF access point, and the frame structure is used to receive data from a slot of the frame structure from a TDF station. The communication method of claim 1, further comprising: maintaining a polling list of one of the stations to be polled; deciding whether to maintain sufficient time for one response to be polled in the polling list; and transmitting if the decision is maintained for a sufficient time A poll is sent to one of the polling lists. The communication method of claim 5, further comprising transmitting from the polling to The station receives a data frame to return the polling. The communication method of claim 5, further comprising: (1) the station to which the polling is transmitted does not have a data frame to transmit or (2) the station does not maintain sufficient time in the polling slot to transmit If the data frame is arranged, a null frame is received from the station to return the poll. The communication method of claim 1, further comprising: receiving, from a first device, the first data in the polling slot, the first device has used the polling mode to transmit the data in the polling slot; and receiving Preserving a second material for use in a slot of a second device, the second device having used the time-sharing mode to transmit the data in the storage slot, wherein the first data and the first frame are received in the same frame Two materials. The communication method of claim 1, wherein: the use of the frame by a TDF station, and the use of the frame structure comprises transmitting data in a slot of the frame structure to a TDF access point. The communication method of claim 1, further comprising: deciding which module is used to communicate with an access point at one station; and transmitting the data to the access point using the decision mode. The communication method of claim 1, further comprising: receiving one of the polling slots from an access point; and transmitting a data frame to the access point in response to receiving the transmission poll. The communication method of claim 1, further comprising: receiving one of the polling slots from an access point; and If (1) there is no data frame to transmit or (2) sufficient time remains in the polling slot to transmit a data frame, a null value frame is transmitted to the access point in response to receiving the transmission poll. The communication method of claim 1, further comprising: receiving one of the polling slots from an access point; and transmitting a media access control (MAC) protocol data unit (MPDU) to receive the polling. The communication method of claim 1, further comprising transmitting the data from one of the polling periods using the One Point Coordination Function (PCF) mechanism to transmit the MAC frame. A communication device comprising: a communication unit (1010; 1030) 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 and A polling mode in which one slot of the frame structure is stored for a device, and one of the polling slots in the frame structure is used for data communication by a plurality of devices. Any one of the devices operates in the time division mode or the polling mode. The communication device of claim 15, further comprising a storage unit (1010; 1030) for storing data. The communication device of claim 15, wherein: the device is part of a TDF station, and the communication unit is configured to transmit the data in the polling slot from the TDF station to the first during the polling mode The frame structure is used by the TDF access point. The communication device of claim 17, wherein the communication unit is configured to (1) determine which mode in the time-sharing mode or the polling mode is used by the TDF station, and (2) if the polling mode is used, A PCF communication mechanism is then identified to transmit data during the polling slot. The communication device of claim 17, wherein the communication unit is configured to notify a TDF access point of one of the communication modes used by the TDF station. The communication device of claim 15, wherein: the device is part of a TDF access point, and the communication unit is configured to receive data in the polling slot from a TDF station at the TDF access point To use the frame structure. The communication device of claim 20, wherein: the TDF access point includes a point coordinator configured to transmit a contention free poll to the at least one TDF station during the polling slot, and the polling slot One of the slots of the TDF hyperframe is used to support data traffic on a cable network. A communication device (1010; 1030) includes a processor readable medium, the processor readable medium including instructions stored thereon for communicating a frame structure for communication, the frame structure support At least two communication modes, the communication modes include a time division mode and a polling mode, wherein a slot in the frame structure is saved for a device, and the frame structure is in the polling mode One of the polling slots is used for data communication by a plurality of devices, any of which operates in the time-sharing mode or the polling mode.