WO2013126859A2 - Opportunistic radio access technology selection and aggregation - Google Patents

Abstract

Systems, methods, and instrumentalities are provided for managing multiple radio access technology (RAT) interfaces to enable opportunistic RAT selection and aggregation for sending data traffic over the multiple RAT interfaces. A system for selecting a RAT may include an Internet Protocol (IP) layer and RAT protocol stacks residing below the IP layer. An opportunistic multiple media access control aggregation (OMMA) layer may reside between the IP layer and the RAT protocol stacks. The OMMA layer may include an OMMA scheduler that may distribute incoming IP data packets among the RAT protocol stacks. An OMMA controller may communicate a control parameter to the OMMA scheduler for selecting a RAT protocol stack for distributing an incoming IP data packet. A wireless transmit/receive unit RAT capability database may store RAT capability information. A policy database may store a policy for distributing the IP data packets among the RAT protocol stacks.

Description

OPPORTUNISTIC RADIO ACCESS TECHNOLOGY SELECTION AND

AGGREGATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.

61/603,004, filed February 24, 2012; and U.S. Provisional Patent Application No. 61/676, 121, filed on July 26, 2012; and U.S Provisional Patent Application No. 61/678,060 filed July 31, 2012; the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Wireless technologies have been demanding higher data throughput rates and lower latencies. The use of carrier aggregation and multi-radio access technology (RAT) capabilities has been introduced. Carrier aggregation may allow operators to offload some of their data traffic to secondary cells (e.g., transmitted on secondary component carriers). In multi- RAT systems reception and/or transmission may be performed over multiple RATs. For example, a network terminal (NT) (e.g., an access point (AP), an eNodeB (eNB), Homes eNbs (HeNbs), etc.) and a wireless transmit/receive unit (WTRU) (e.g., a user equipment (UE), a station (STA), etc) may communicate over multiple parallel paths. However, each RAT may be used for only one Internet Protocol (IP) flow. There are many problems associated with such communication.

SUMMARY

[0003] Systems, methods, and instrumentalities are disclosed to manage multiple radio access technology (RAT) interfaces to enable opportunistic RAT selection and aggregation for sending data traffic over the RAT interfaces. A device may include an Opportunistic Multiple- Medium Access Control (MAC) Aggregation (OMMA) layer that resides below the IP layer but above the RAT protocol stacks and includes control plane and data plane processing capability.

[0004] A node (e.g., a WTRU or NT) in communication with a wireless communication system may comprise a processor that is in operable communication with a plurality of radio access technologies (RATs). The processor may be configured to receive first feedback information associated with a first RAT and receive second feedback information associated with a second RAT. The processor may be configured to determine a first IP packet to send via the first RAT according to the first and second feedback information and determine a second IP packet to send via the second RAT according to the first and second feedback information. The first and second IP packets may be part of an Internet Protocol (IP) flow addressed to a receiving node. The processor may send the first IP packet via the first RAT and may send the second IP packet via the second RAT.

[0005] The processor of the node may be further configured to perform a hybrid packet distribution method. For example, the processor may be configured to determine whether channel quality of the first RAT and/or the second RAT is below a threshold. Upon determining that channel quality of the first RAT is below the threshold, the processor may be configured to duplicate the first IP packet to create a first instance of the first IP packet and a second instance of the first IP packet. The processor may be configured to send the first instance of the first IP packet via the first RAT and send the second instance of the first IP packet via a third RAT. Upon determining that channel quality of the second RAT is at or above the threshold, the processor may be configured to send the second IP packet via the second RAT.

[0006] A method (e.g., performed by a WTRU or a NT comprising an OMMA layer) may aggregate the bandwidth available on multiple radio access technologies (RATs). The method may comprise assigning a first variable to a first RAT and a second variable to a second RAT. The method may increment the first variable of the first RAT by a first rate and increment the second variable of the second RAT by a second rate. The first rate may be related to an estimated arrival rate of a packet transmitted across the first RAT, and the second rate may be related to an estimated arrival rate of a packet transmitted across the second RAT. The method may comprise determining whether the first variable is greater than or equal to a threshold value. Upon determining that the first variable is greater than or equal to the threshold value and that the second variable is less than the threshold value, the method may send a packet across the first RAT. The method may then decrease the first variable by the threshold value.

[0007] A node (e.g., a WTRU or a NT) may comprise an opportunistic multiple radio access technologies (RAT) aggregation (OMMA) layer. The OMMA layer may comprise a controller and a scheduler, the controller and scheduler may be in operable communication with a first radio access technology (RAT) and a second RAT. The controller may be configured to determine a first time duration and a first bandwidth requirement for a first IP packet, and determine a second time duration and a second bandwidth requirement for a second IP packet. The first IP packet and the second IP packet may be part of an IP flow addressed to a receiving node. The controller may be configured to request resources on the first RAT and the second RAT based on the first time duration and the first bandwidth requirement for the first IP packet and based on the second time duration and second bandwidth requirement for the second IP packet. The controller may be configured to send instructions to a scheduler. The scheduler may be configured to receive first feedback information associated with the first RAT, and receive second feedback information associated with the second RAT. The scheduler may be configured to determine to send the first IP packet via the first RAT according to the first and second feedback information and the instructions, and to determine to send the second IP packet via the second RAT according to the first and second feedback information and the instructions.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. IB is a system diagram of an example wireless transmit/receive unit

(WTRU) that may be used within the communications system illustrated in FIG. 1A.

[0010] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0011] FIG. ID is a system diagram of an another example radio access network and another example core network that may be used within the communications system illustrated in

FIG. 1A.

[0012] FIG. IE is a system diagram of an another example radio access network and another example core network that may be used within the communications system illustrated in

FIG. 1A.

[0013] FIG 2 is an example system architecture of a base station system infrastructure.

[0014] FIG 3 is an example system of a NT with capability to support multiple RATs.

[0015] FIG 4 is a diagram illustrating an example of multi-RAT aggregation using an

OMMA layer.

[0016] FIG. 5 is a diagram illustrating an example of dual-RAT aggregation with a common OMMA layer residing above a MAC.

[0017] FIG. 6 is a block diagram of an example OMMA layer. [0018] FIG. 7 is a table illustrating an example of parameters that may be signaled when a NT advertises its RAT capabilities using a management signal.

[0019] FIG. 8 is a diagram illustrating an example of an active scanning procedure.

[0020] FIG. 9 is a diagram illustrating an example of an passive scanning procedure.

[0021] FIG. 10 is a diagram illustrating an example of diversity mode.

[0022] FIG. 1 1 is a diagram illustrating an example of multiplexing mode.

[0023] FIG. 12 is a diagram illustrating an example of hybrid mode.

[0024] FIG. 13 is a diagram illustrating an example of dynamic RAT switching mode.

[0025] FIG. 14 is a diagram illustrating an example timeline for transmitting feedback metrics.

[0026] FIG. 15 is a diagram illustrating an example message sequence where an OMMA requests measurement metrics for each RAT.

[0027] FIG. 16 is an example message sequence where RAT modules report metrics periodically or aperiodcially to an OMMA module.

[0028] FIG. 17 is a dia^ *ram illustrating ; an example of state and state transition triggers of an OMMA layer.

[0029] FIG. 18 is a dia^ *ram illustrating ; an example of a TCP session.

[0030] FIG. 19 is a dia^ *ram illustrating ; an example of aggregation performed for TCP data.

[0031] FIG. 20 is a dia^ *ram illustrating ; an example architecture of a solution.

[0032] FIG. 21 is a dia^ *ram illustrating ; an example processing of a solution.

[0033] FIG. 22 is a dia^ *ram illustrating ; an example header of a solution.

[0034] FIG. 23 is a dia^ *ram illustrating ; an example of how OMMA may route packets.

[0035] FIG. 24 is a dia^ *ram illustrating ; an example of a table maintained by OMMA.

[0036] FIG. 25 is a dia^ *ram illustrating ; an example of logic used when there is a packet to be scheduled.

[0037] FIG. 26 is a dia^ *ram illustrating ; an example of UDP logic.

[0038] FIG. 27 is a dia^ *ram illustrating ; an example of TCP logic. [0039] FIG. 28 is a functional block diagram that depicts an example implementation of an OMMA layer according to an embodiment.

[0040] FIG. 29 is a functional block diagram that depicts an example implementation of an OMMA Controller.

[0041] FIG. 30 is a functional block diagram illustrating one example implementation of an OMMA Scheduler.

[0042] FIG. 31 is a call flow diagram that illustrates an example call flow showing signaling corresponding to a process for RAT availability determination.

[0043] FIG. 32 is a system diagram illustrating data flow in an example scenario of an

OMMA sender in which both PBS and FBS are enabled at a NT for single RAT selection for single WTRU single IP flow.

[0044] FIG. 33 illustrates a call flow for the example scenario of FIG. 32.

[0045] FIG. 34 is a functional block diagram illustrating an example transparent OMMA

Receiver for single RAT enabled, single WTRU, single IP flow.

[0046] FIG. 35 is a functional block diagram illustrating an example OMMA receiver performing reassembly on a selected RAT.

[0047] FIG. 36 depicts an example call flow for allocating wireless resources for medium access by a NT and WTRUs using a RAT.

[0048] FIG. 37 illustrates an example interface between an OMMA Controller and a

WTRU RAT Capability Database.

[0049] FIG. 38 illustrates an example interface between an OMMA Controller and a

Policy Database.

[0050] FIG. 39 illustrates an example interface between an OMMA Controller and ai

OMMA Scheduler.

[0051] FIG. 40 illustrates an example matrix for signaling parameters.

[0052] FIG. 41 illustrates an example matrix for signaling parameters.

[0053] FIG. 42 illustrates an example matrix for signaling parameters.

[0054] FIG. 43 illustrates an example interface between an OMMA Controller and a

RAT protocol stack.

[0055] FIG. 44 illustrates example feedback metrics that may be sent by RATs. [0056] FIG. 45 is a functional block diagram depicting an example interface between an

OMMA Scheduler and a WTRU RAT Capability Database.

[0057] FIG. 46 is a functional block diagram depicting an example interface between an

OMMA Scheduler and a Policy Database.

[0058] FIG. 47 is a functional block diagram illustrating an example interface between

PBS and FBS modules.

[0059] FIG. 48 is a functional block diagram depicting an example interface between an

IP Packet QoS Identifier module and a PBS or FBS module within an OMMA Scheduler.

[0060] FIG. 49 is a functional block diagram illustrating an example implementation of an Ax interface between a Policy Database and a DNS-APP entity.

[0061] FIG. 50 is a functional block diagram illustrating an example implementation of an Ay interface between the Policy Database and a user interface application (UI-APP) entity.

[0062] FIG. 51 is a diagram illustrating an example of Multi-RAT Aggregation using

OMMA Layer.

[0063] FIG. 52 is a diagram illustrating an example of a threshold for mode selection in two RAT systems.

[0064] FIG. 53 is a diagram illustrating and examples of a packet reordering scenario.

[0065] FIG. 54 is a diagram illustrating and examples of a packet reordering scenario.

[0066] FIG. 55a is a diagram illustrating a random assignment of packets;

[0067] FIG. 55b is a diagram illustrating a smart assignment of packets across RATs.

[0068] FIG. 56 is a representation of an example OMMA smart packet allocation algorithm.

[0069] FIG. 57 is a graph illustrating an example of measurements of average reordering delay per packet for different scheduling schemes.

[0070] FIG. 58 is a diagram illustrating an example of an OMMA Sender at a NT for single RAT selection for Multi WTRU Multi IP Flow.

[0071] FIG. 59 is a diagram illustrating an example call flow.

DETAILED DESCRIPTION

[0072] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

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

[0074] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0075] The communications systems 100 may also include a base station 1 14a and a base station 1 14b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 1 10, and/or the networks 112. By way of example, the base stations 1 14a, 1 14b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 1 14b may include any number of interconnected base stations and/or network elements. [0076] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 1 14a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0077] The base stations 1 14a, 114b may communicate with one or more of the WTRUs

102a, 102b, 102c, 102d over an air interface 1 15/116/1 17, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 1 15/116/1 17 may be established using any suitable radio access technology (RAT).

[0078] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 1 14a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 1 15/116/1 17 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0079] In another embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/1 17 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).

[0080] In other embodiments, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like. [0081] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 1 10. Thus, the base station 114b may not be required to access the Internet 1 10 via the core network 106/107/109.

[0082] The RAN 103/104/105 may be in communication with the core network

106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.

Although not shown in FIG. 1A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0083] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a,

102b, 102c, 102d to access the PSTN 108, the Internet 1 10, and/or other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT. [0084] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system

100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology.

[0085] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.

[0086] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0087] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface

1 15/116/1 17. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0088] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/1 16/1 17.

[0089] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0090] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0091 ] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0092] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 15/1 16/1 17 from a base station (e.g., base stations 1 14a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0093] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0094] FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 15. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 15. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0095] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the

RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0096] The core network 106 shown in FIG. 1C may include a media gateway (MGW)

144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0097] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0098] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0099] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0100] FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0101] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more

transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0102] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell

(not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0103] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0104] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the

RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer

activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0105] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b,

160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0106] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0107] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0108] FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points. [0109] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[01 10] The air interface 1 17 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for

authentication, authorization, IP host configuration management, and/or mobility management.

[01 11] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[01 12] As shown in FIG. IE, the RAN 105 may be connected to the core network 109.

The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator. [01 13] The MIP-HA may be responsible for IP address management, and may enable the

WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[01 14] Although not shown in FIG. IE, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[01 15] A network terminal (e.g., an access point (AP), an eNodeB (eNB), a Home eNbs

(HeNbs), a relay, etc.) and a WTRU (e.g., a UE, a STA, etc.) may be configured to work in an infrastructure mode or an adhoc mode, for example, in an IEEE 802.11 based Wi-Fi system. As described herein, a NT and/or a WTRU may be referred to as a node. Therefore, a node may refer to a network terminal, a WiFi access point, a WTRU, etc.

[01 16] In the infrastructure mode, the NT may be the central controller for the system and may act as the gateway to the wired network. The NT may operate using an 802.1 1 system (e.g., 1 la/b/g/n) over a band (e.g., 2.4GHz or 5GHz) when communicating with the WTRU. For example, an 802.1 1 based system may operate in a time division duplexing (TDD) mode, for example, over a single 20/40MHz channel in the case of industrial scientific medical (ISM) band, or over a single 5/10/20 MHz channel in television white space (TVWS) band (e.g., using contiguous/non-contiguous carrier aggregation).

[01 17] A multi-band multi-mode NT may support a WTRU operating over 2.4GHz ISM band using the 802.1 In protocol and a WTRU operating over TVWS band. WTRUs operating on an ISM band may contend with each other for ISM channel access. WTRUs operating over a TVWS band may contend with each other for TVWS channel access. WTRUs operating over an ISM band and WTRUs operating over a TVWS band may not contend with each other, for example, since they are on different operating frequencies. A WTRU may be able to

communicate (e.g., simultaneously) with a NT over, for example, an ISM channel and a TVWS channel.

[01 18] The NT and WTRU may communicate with each other over a single radio frequency (RF) spectral band, for example, 2.4GHz ISM band, or 5 GHz ISM band, or TVWS band or 60GHz band, using a channel within the band or aggregating multiple contiguous or noncontiguous channels. A WTRU and NT may be multi-band and/or multi-RAT capable devices. A WTRU may support multiple internet protocol (IP) streams, for example, with a different QoS requirement per packet. A WTRU may select a RAT to communicate over the air interface with the other WTRU or NT.

[01 19] The medium access delay per channel may be high due to contention among

WTRUs, for example, due to a high number of devices crowding each spectral band. The transmit opportunity per WTRU may be small compared to the medium access delay, which may reduce the effective throughput on each channel. A device using a single RAT at a time may experience high latencies, which may impact IP QoS requirements.

[0120] A mechanism to aggregate two or more RATs operating independently on two or more bands to enhance the total IP throughput of the link may be described herein. For example, a single thin software layer (e.g., an opportunistic multi-medium access control (MAC) aggregation (OMMA) layer) may be described herein. For example, the single thin software layer may reside above the medium access control (MAC) layers of the protocol stacks but below the IP layer. For example, the single thin software layer may enable one RAT to operate over industrial scientific medical (ISM) and another RAT to operate over a TVWS band for the same IP flow. This may allow for enhanced throughput and reduced latency for a single IP flow.

[0121] In an IEEE 802.1 1 based Wi-Fi system, the NT and/or a WTRU may be configured to work in the infrastructure mode of the adhoc mode. FIG. 2 is a diagram illustrating an example system 200 architecture of a base station system infrastructure. In the infrastructure mode, for example, as illustrated in FIG. 2, a NT 201 may be the central controller for the system and act as the gateway to the wired network. The system 200 may comprise one or more WTRUs 202, which may operate utilizing one or more different RATs. The NT 201 may operate using one flavor of the 802.1 1 system (e.g., 1 la/b/g/n) at any given time over a specific band (e.g., 2.4GHz or 5GHz) when communicating with a WTRU. An 802.1 1 based system may operate in a time division duplexing (TDD) mode, for example, on a band over a single 20/40MHz channel in the case of ISM band or a single 5/10/20 MHz channel in television white space (TVWS) band using contiguous/non-contiguous carrier aggregation.

[0122] An aggregation layer, which may be referred to an opportunistic multi-medium access control (MAC) aggregation (OMMA) layer, and may be common to all RATs in a NT 201 and/or WTRU 202 may be proposed. The OMMA layer (e.g., or OMMA module) may reside below the IP layer and above the radio protocol stacks. The OMMA layer may not be an independent layer, but rather the functionality of the OMMA layer may reside partially on one or more layers (e.g., the IP layer, the MAC layer, etc.) of the protocol stack. Functionality (e.g., or modules) of the OMMA layer may reside on one or more NTs, for example, to allow the processing of the OMMA layer to be divided between network elements.

[0123] As described herein, the OMMA layer may receive meta-data/link statistics feedback (e.g., feedback information) from a RAT (e.g., each RAT). For example, feedback information/statistics may include, but are not limited to, a medium access delay, a frame error rate, an average data rate, a received signal strength indication (RSSI), queuing latency per access category per RAT, end-to-end latency, a backoff time, a number of channels, channel bandwidth, a media access control (MAC) type, MAC aggregation support, an access category, a transmission opportunity (TXOP) duration, an estimated arrival rate of a packet, an average serving rate, an average serving latency, a second moment of average serving latency, an average vacation time, a second average of vacation time, TCP parameters, such as sequence number, acknowledgement number, and window size, for example, etc. The statistics may be provided by each RAT.

[0124] The OMMA layer may comprise an OMMA scheduler. The OMMA scheduler may be responsible for traffic shaping, which, for example, may include policy based routing of IP packets across bands or feedback based routing of packets across bands.

[0125] The OMMA layer may comprise a MAC resource reservation mechanism. The

MAC resource reservation mechanism may be responsible for requesting a specific amount of time or frequency resources on the medium per channel.

[0126] The OMMA layer may be transparent. If the OMMA layer is transparent, then the OMMA layer may distribute/combine packets from different RATs and forward the packets to the IP layer. The OMMA layer may be non-transparent. If the OMMA layer is non- transparent, then the OMMA layer may add one or more additional headers to an IP packet at the transmitter and read and/or remove the headers at the receiver. The OMMA layer may utilize a packet distribution mode. For example, the packet distribution mode may be a diversity mode, a multiplexing mode, a hybrid mode, or a dynamic RAT selection mode.

[0127] Beacons, probe request/response, and/or association request/response frames may be updated by the OMMA layer to include OMMA device discovery parameters, for example, such as but not limited to OMMA modes, OMMA schemes, OMMA packet distribution modes, etc.

[0128] Supporting an OMMA layer may cause TCP reordering issues, for example, in case the transport layer used is TCP, since packet distribution across RATs may imply an out-of- order reception of packets at the receiver. Reordering of packets at the receiver may trigger detection of a congestion event at the sender TCP, which may subsequently decide to throttle the throughput. Solutions to solve these problems utilizing the OMMA layer may be described herein.

[0129] A system may comprise a NT with the capability to support multiple Radio

Access Technologies (RATs), where each RAT may be operating on one or more spectral bands. FIG. 3 is a diagram illustrating an example system 300 of a NT with capability to support multiple RATs. The NT 301 may be operable to communicate with WTRUs 302 that do not comprise an OMMA layer, and WTRUs 315 that do comprise an OMMA layer. For example, the NT 301 may support an 802.1 In based RAT operating on 802.1 laf, a RAT operating on 512MHz to 698 MHz TVWS band, 2.4 GHz ISM band, 802.1 lac RAT operating on 5GHz ISM band, LTE RAT operating on 2 GHz licensed band, WCDMA/HSPA RAT operating on 900 MHz licensed band, etc.

[0130] A WTRU 315 in the system 300 may operate on one or more RATs (e.g., those described herein). For example, one or more WTRUs 315 may support 802.1 In based RAT operating on 802.1 laf RAT operating on 512MHz to 698 MHz TVWS band, one or more WTRUs 315 may support 2.4 GHz ISM band, 802.1 lac RAT operating on 5GHz ISM band, one or more WTRUs 315 may support LTE RAT operating on 2 GHz licensed band, one or more WTRUs 315 may support WCDMA/HSPA RAT operating on 900 MHz licensed band, etc. WTRUs 315 operating on a particular spectral band may contend with each other for wireless medium access.

[0131] A WTRU (e.g. , a multi-RAT WTRU) may support more than one RAT. These

WTRUs may operate using one RAT at any given time based on an independent decision by the WTRUs or based on decision by the NT they are associated with. A WTRU may operate using a plurality of RATs at any given time based on an independent decision by the WTRUs or based on decision by the NT they are associated with. [0132] FIG. 4 is a diagram illustrating an example of multi-RAT aggregation using an

OMMA layer. A WTRU and/or a NT may comprise an OMMA layer 400. A WTRU or NT that comprises an OMMA layer 400 may support more than one RAT 401. Such a WTRU or NT may include one or more features described herein which may enable the WTRU or NT to operate on a plurality of RATs simultaneously by aggregating data across the RATs. For example, the data may be for a single IP flow. A single IP flow may refer to a stream of IP packets belong to a particular application. For example, a single IP flow may refer to a stream of IP packets that belong to a particular application and share the same 5-tuple. The 5-tuple may be comprised of the following five fields in the IP Header: IP protocol; Source IP address;

Destination IP; address; Source Port Number; and Destination Port Number. A WTRU and a NT that comprise an OMMA layer may support multiple RAT connection simultaneously.

[0133] A NT and/or WTRU may comprise one or more modules within the NT and/or

WTRU. The modules include, but are not limited to, one or more RATs 401, multiple antenna/radio frequency (RF) front-end pairs 403, a common module between the IP module 402 and the multiple RAT modules 401 (e.g., the OMMA layer 400), etc.

[0134] As described herein, a RAT may be, for example, a WiFi RAT, an LTE RAT, a

WCDMA/HSPA RAT, an UTRAN RAT, an E-UTRAN RAT, etc. A Wi-Fi RAT may be a IEEE802.1 In RAT, a IEEE802.1 lac RAT, a IEEE802.1 laf RAT, etc. An LTE RAT may be a LTE Rel-8 compliant RAT, a LTE-A Rel-10 compliant RAT, etc. A WCDMA RAT may be a WCDMA R4 compliant RAT, a WCDMA/HSDPA/HSUPA Rel6 RAT, etc. The OMMA layer may communication with a plurality of RATs, which for example, may comprise any combination of RAT types. For example, an OMMA layer may communicate with a WiFi RAT operating over an industrial, scientific and medical (ISM) radio band and a WiFi RAT operating over a TV white space (TVWS) radio band.

[0135] For multiple RATs 401, each RAT 401 may be operating on a specific band. For example, a 802.1 In PHY/MAC operating over 2.4GHz ISM band, a 802.1 laf PHY/MAC operating over 512MHz - 698 MHz TVWS band, an LTE RAT operating of a licensed band

(e.g., 700MHz band), a Bluetooth RAT operating on 2.4GHz ISM band, etc.

[0136] For multiple antenna/RF front-end pairs 403, each may be operating on a specific band. For example, one 2.4GHz ISM band radio, one 512MHz - 698 MHz TVWS band split as a low band radio and high band radio, one LTE 700MHZ radio, etc.

[0137] The OMMA layer 400 may be a common layer/module between the IP layer/module 402 and the multiple RAT layers/modules 401. As described herein, the OMMA layer/module 400 may allocate IP packets to one or more RATs. [0138] FIG. 5 is a diagram illustrating an example of dual-RAT aggregation with a common OMMA layer residing above MAC. FIG. 5 shows an exemplary device (e.g., NT or WTRU) architecture which is aggregating two RATs 501a, 501b, for example, an 802.1 In based RAT operating on ISM band and another 802.11 based RAT with non-contiguous carrier aggregation operating on TVWS band. The RATs 501a, 501b may comprise a MAC

layer/module 502 and one or more physical layers/modules 503. The OMMA layer 500 may receive meta-data feedback from each of the RATs 501a, 501b. The OMMA layer 500 may decide to split IP packets based on received meta-data. Table 1 may provide the interfaces between an OMMA layer (e.g., OMMA layer 500) and an IP layer (e.g., IP layer 504) and one or more RATs (e.g., RATs 501a, 501b), for example, as shown in FIG. 5.

Table 1

Ml Meta-data/link statistics from TVWS band protocol stack to thin layer

M2 Meta-data/link statistics from ISM band protocol stack to thin layer

Al Incoming/Outgoing MAC MSDUs on TVWS band, and MAC resource

reservation control signaling

A2 Incoming/Outgoing MAC MSDUs on ISM band, and MAC resource

reservation control signaling

S Incoming/Outgoing IP Packets

[0139] FIG. 6 is a block diagram of an example OMMA layer. The OMMA layer 600 may comprise one or more of the following: a traffic shaping module 601, a MAC resource reservation module 602, and an internet protocol (IP) quality of service (QoS) scheduler 603. The traffic shaping module 601 may responsible for determining the way packets are routed across RATs. For example, the traffic shaping module may determine the way a packet is routed using policy based routing or feedback based routing.

[0140] In policy based routing, the packets may be transmitted on different RATs using one or more rules (e.g., pre-defined rules or policies). The rules may include, but are not limited to, one or more of device capability, an operator policy, a quality of service (QoS) class, an IP packet flow, device coordinates, a source domain, a source IP address, a destination domain, a destination IP address, a port number, a subscriber priority, a link quality, charging, security, the rules/policies described in Table 5, etc. [0141] In feedback based routing, the packets may be transmitted on different RATs using the feedback metrics. The feedback metrics may include, but are not limited to, RSSI, medium access delay, etc. The feedback metrics may reflect the average state of the system operating on each RAT.

[0142] The MAC Resource Reservation module 602 may determine an amount of time duration and/or spectral fragment/bandwidth required by a packet or a set of packets. This module may transmit specific requests to the RATs over the A1/A2 interface.

[0143] The IP QoS Scheduler module 603 may segregate a single IP packet stream comprising multiple IP QoS types into distinct IP QoS streams, for example, so that the traffic shaping module 601 may treat each IP QoS stream independently and satisfy the specific QoS requirements when routing the IP packets.

[0144] OMMA device discovery parameters may be described herein. The OMMA system may comprise devices (e.g., NT, WTRU, etc.) that support a single RAT or support more than one RAT. Information (e.g., the number of RATs that are supported, the identity of the RATs, etc.) may be known to each device so that they may communicate using the highest possible link throughput. In a centralized network, the NT may advertise its RAT capabilities to all the WTRUs in its coverage area so that any new WTRU entering its coverage area may be informed. A WTRU in the coverage area of the NT (e.g., a new WTRU) may inform/advertise its RAT capabilities to the NT so that each NT may negotiate and/or select the appropriate set of RATs to be used for communication between them. FIG. 7 is a table of example parameters that may be signaled when a NT advertises its RAT capabilities using a management signal.

[0145] OMMA RAT selection may be described herein. OMMA devices (e.g., a NT and a WTRU) may discover each utilizing an active scanning procedure or a passive scanning procedure. FIG. 8 is a diagram illustrating an example of an active scanning procedure. In the active scanning procedure, a WTRU may transmit a probe request signal to one or more NTs, for example, as a way to discover the receiving devices. Since these may be multi-RAT devices (e.g., WTRUs and/or NTs) each operating over different spectral bands/channels, the probe request may be transmitted on one or more of the channels. The probe request signal may comprise the OMMA parameters of the device (e.g., WTRU OMMA parameters). Upon receiving the probe request on all or a subset of the RATs that it supports, the NT may transmit a probe response on one or more of the RATs. In the case of OMMA, the NT may transmit its OMMA parameters along with the probe response. Upon reception of the probe response, the WTRU may select one or more of the RATs to perform the authentication with the other device. [0146] After the authentication procedure, the WTRU may transmit an association request to the NT, for example, to request membership with the receiving device. The WTRU may use one or more of the RATs for association (e.g., the same RAT that was used for authentication). The authentication request signal may comprise the WTRU's OMMA parameters. The NT may respond with an association response signal accepting or rejecting membership of the WTRU. The association response may comprise a selected list of RATs and/or OMMA parameters for communication (e.g., downlink and/or uplink communication) between the NT and the WTRU.

[0147] FIG. 9 is a diagram illustrating an example of a passive scanning procedure. In the passive scanning procedure, the WTRU may wait for the periodic beacon signal to be transmitted by a NT on one or more of the RATs. Upon receiving a beacon signal, the WTRU may read the contents of the beacon. The NT may transmit its OMMA parameters on all beacon signals so that WTRUs (e.g., new WTRUs) may identify the OMMA capabilities of the NT.

[0148] The WTRU may compare a list of RATs supported by the NT with its own list of

RATs supports. The WTRU may then select one or more of the RATs and perform an authentication procedure with the NT over the one or more RATs.

[0149] After the authentication procedure, as in the active scanning case above, the

WTRU may transmit an association request to the NT to request membership with the NT. The WTRU may use one or more of the RATs for association (e.g., the same RAT that was used for authentication). The authentication request signal may comprise the WTRU's OMMA parameters. The NT may respond with an association response signal accepting or rejecting membership of the WTRU. The association response may comprise a selected list of RATs and/or the OMMA parameters for communication (e.g., uplink and/or downlink communication) between the NT and the WTRU.

[0150] OMMA packet distribution modes may be described herein. The OMMA layer at the transmitter may distribute packets across multiple RATs using one or more of the following distribution modes: Diversity Mode, Multiplexing Mode, Hybrid Mode, or Dynamic RAT Selection Mode.

[0151] FIG. 10 is a diagram illustrating an example of diversity mode. In diversity mode, IP Packets at the OMMA layer 1000 may be duplicated across multiple RATs 1001 when the instantaneous channel quality at each RAT 1001 is below a lower threshold (e.g., is very low). Diversity mode may enable transmission of an IP packet with a high probability of error- free reception. Diversity mode may be equivalent to the transmit diversity mode in a multiple- input multiple output (MIMO) system. [0152] FIG. 11 is a diagram illustrating an example of multiplexing mode. In multiplexing mode, when the OMMA layer 1100 determines that the channel quality for one or more RATs 1 101 is above an upper threshold (e.g., is very good), the OMMA layer 1100 may transmit different independent IP packets across one or more of the RATs 1101. This way the throughput may be maximized since the probability of the IP packet being received in error on any RAT 1 101 is relatively low.

[0153] FIG. 12 is a diagram illustrating an example of hybrid mode. In hybrid mode, when the OMMA layer 1200 under consideration supports multiple RATs 1201, some of which have a poor channel quality (e.g., RATs 1201a, 1201b), while the remaining have a good channel quality (e.g., RATs 1201c, 1201d), for example at a given time, the RATs with a poor channel quality may be used in one mode (e.g., diversity mode), while the RATs with good channel quality could be used in another mode (e.g., multiplexing mode). The determination of poor channel quality and good channel quality may be determined by the OMMA layer 1200 utilizing the lower threshold and upper threshold, respectively.

[0154] FIG. 13 is a diagram illustrating an example of dynamic RAT switching mode. In dynamic RAT switching mode, the OMMA layer 1300 may select the best RAT possible (e.g., RAT 1301a) at any given time and not use the remaining RATs (e.g., RAT 1301b). For example, the OMMA layer 1300 may make this determination based on the instantaneous channel quality/availability of the RATs 1301a, 1301b. As the channel quality/availability of RATs 1301a, 1301b changes, the best RAT may be selected which may be different from the one previously used.

[0155] For example, if the channel quality of one RAT is 6dB or lower than the channel quality of the other RATs, the RAT with the low channel quality may be disabled. If the OMMA layer determines that the ratio of packets distributed across a dual RAT device is 9: 1, Dynamic RAT Switching Mode may be enabled, for example, so the RATs with a better channel quality may be used. For example, channel quality events that may trigger this mode may include, but are not limited to, low throughput, low RSSI, transmission control protocol (TCP) re-ordering trigger, high medium access delay, and high end-to-end delay.

[0156] As noted herein, the OMMA layer may determine to send one or more IP packets via one or more RATs. For example, the OMMA layer may determine to send a first IP packet via a first RAT and a second IP packet via a second RAT according to a packet distribution mode. The packet distribution mode may be one of diversity mode, multiplexing mode, hybrid mode, or dynamic RAT selection mode. For example, the OMMA layer may determine that channel quality of the first RAT is below a threshold. The OMMA layer may duplicate the first IP packet to create a first instance of the first IP packet and a second instance of the first IP packet. The OMMA layer may send the first instance of the first IP packet via the first RAT and send the second instance of the first IP packet via a third RAT. This may be an example of the OMMA layer operating under diversity mode. The OMMA layer may determine that channel quality of the second RAT is at or above the threshold, and send the second IP packet via the second RAT. This may be an example of the OMMA layer operating under multiplexing mode (e.g., or may be considered hybrid mode when taken into consideration with the first IP packet sent via the first RAT and third RAT).

[0157] OMMA traffic shaping may be described herein. Traffic shaping at the OMMA layer may be done to distribute (e.g., optimally distribute) IP packets across the different RATs, for example, based on the feedback metrics received from each RAT module, which may indicate the quality of the channel of each RAT. Policy based routing or feedback based routing may be used to determine the ratio of distribution of packets between the various RATs.

[0158] Policy based routing may use a predefined set of rules/policies to determine the ratio with which the IP packets may be distributed across RATs. The OMMA layer may determine the IP packet distribution ratio utilizing one or more of device capability,

operator/administrator's local policy, and external database/policy server, etc.

[0159] For device capability, some of the devices may have a fixed ratio in which they may serve packets across the RATs. For example, this fixed ratio may be stored in the device (e.g., WTRU or NT) memory. The OMMA transmitter may look up an internal

memory/database to determine if the receiver OMMA can support such a fixed ratio and distribute the packets accordingly.

[0160] For operator/administrator's local policy, the operator or administrator may define certain policies which may be such that the OMMA transmitter uses certain fixed ratio of packet distribution for each of the receivers. This ratio may change based on the

operator/administrator's requirements. For external database/policy server, the OMMA transmitter may look up an external database or policy server to determine the ratio with which IP packets may be distributed to each receiving OMMA device.

[0161] In feedback based routing, the OMMA transmitter may use measurement metrics fed back from each RAT. The measurement metrics may include, but are not limited to, channel quality metrics and the number of available resources on the medium. The OMMA transmitter may utilized the measurement metrics to determine the instantaneous ratio of distribution of packets across the RATs. Table 2 provides examples of feedback metrics that may be used by an OMMA layer (e.g., an OMMA transmitter). Table 2

MtMric Ufsiripiion

Medium Access De lay MAC Total packet delay in queue plus contention delay

RSSI PHY Received signal strength indication from

PMD_RSSI.indication (e.g., strength)

Frame error rate MAC Average rate at which packets are NACKed

Data rate MAC Average throughput

Queuing latency MAC Total packet delay in queue

End-to-end delay MAC Total delay from input to MAC at transmitter to output of MAC at receiver

TXOP duration MAC TXOP duration for video and voice access categories

AC with medium ac ;cess MAC AC BK, AC_BE, AC_VI, AC_VO, legacy

Backoff time MAC Random back off duration

Number of channeli 5 PHY/MAC Integer number of distinct channels

Channel bandwidth (s) PHY/MAC Vector/List of elements which are multiple of 0.5 MHz

MAC Aggregation MAC Boolean: Yes, No

Supported

MAC Type MAC CSMA/CA, OFDMA, etc.

[0162] A feedback based OMMA algorithm may be described herein. Examples of how an OMMA layer may be utilized to distribute packets across multiple RATs based on feedback metrics may be described herein. The algorithm may comprise one or more of a cold start phase, a ramp-up phase, and a steady-state phase.

[0163] The cold start phase may be triggered when the device starts an OMMA layer/module for the very first time. In this phase, the OMMA layer may request the individual RATs to transmit the total channel bandwidths supported by them. The OMMA layer may use this information to distribute the IP packets across the RATs accordingly. For example, if two RATs are supported by the device, one operating on ISM band and the other operating on TVWS band, the ratio of packet distribution between the RAT on the ISM band to the RAT on the TVWS band may be determined by the OMMA layer utilizing the following:

N

B ^U W ^RR ISM · Y BW ^RR T^kVWS

k=\ [0164] In the ramp-up phase, the RSSI metrics may be assumed to have converged and/or may be assumed to be reliable metrics to indicate instantaneous channel quality of each RAT. For example, if two RATs are supported by the device, one operating on ISM band and the other operating on TVWS band, the ratio of packet distribution between the RAT on the ISM band to the RAT on the TVWS band may be determined by the OMMA layer utilizing the following: avg(RSSI_ISM ) avg{RSSI _V )

ISM ^χ ΒΨ T_Ί VWS

max(RSSI_ISM ) sx!tRSSlly )

[0165] In the steady state phase, the feedback metrics (e.g., all the feedback metrics) from the RATs received by the OMMA layer may be assumed to have converged, and may provide reliable indicators of channel quality, medium access delay, frame error rate, etc. For example, if two RATs are supported by the device, one operating on ISM band and the other operating on TVWS band, the ratio of packet distribution between the RAT on the ISM band to the RAT on the TVWS band may be determined by the OMMA layer utilizing one or more of the following. The ratio may be determined to be a function of bandwidth (BW) and frame error rate (FER). For example, the ratio may be determined by the OMMA layer utilizing the following:

N

[(\ - FER,_SM ) x BW,_SM . ∑( ^{~ FER}TVWS ) x BW T, VWS

k=l

[0166] The ratio may be determined by a function of the average total delay experienced by a packet over each RAT. For example, if two RATs are supported by the device, one operating on ISM band and the other operating on TVWS band, the ratio of packet distribution between the RAT on the ISM band to the RAT on the TVWS band may be determined by the OMMA layer utilizing the following:

\ ^{1 1}Ι τ ^L ISM Λ ' ^{1 1}Ι τ ^L TVWS where ^^M and ^^TVWS are the average total delay experienced by a packet over ISM and TVWS RATs respectively.

[0167] OMMA multi-RAT metric feedback management may be described herein. FIG.

14 is a diagram illustrating an example timeline for sending feedback metrics. At the transmitter, the feedback metrics from each RAT may be sent with a predetermined timing, for example, as shown in FIG. 14. At startup, the OMMA layer may receive the available bandwidth of each of the one or more RATs. At the beginning of the ramp-up phase, the OMMA layer may receive RSSI values as seen by the one or more RATs. Following the ramp-up phase, the steady state- phase may start where the RAT modules at the transmitter OMMA layer may report metrics periodically or aperiodically. The metrics may include, but are not limited to, medium access delay, RSSI, queuing delay, etc. The receiver OMMA layer may report certain RAT

measurement metrics back to the transmitter OMMA layer. The OMMA layer algorithm may process the metrics received and update the ratio of distribution of packets across RATs

periodically or aperiodically.

[0168] FIG. 15 is a diagram illustrating an example message sequence where an OMMA layer requests measurement metrics for each RAT. The message sequence in FIG. 15 shows an exemplary sequence where the OMMA layer 1500 at the transmitter may request measurement metrics for each RAT 1502a, 1502b from the OMMA layer 1501 at the receiver. The OMMA layer 1501 at the receiver may respond with the corresponding metric values. The

request/response for the measurement metrics may occur on either a subset or all of the RATs supported by the OMMA layer 1502 at the receiver.

[0169] FIG. 16 is a diagram illustrating an example message sequence where RAT modules may report metrics periodically or aperiodcially to an OMMA module. The message sequence 1600 is an example of a sequence where RAT modules 1603 at the transmitter OMMA layer 1601 may report metrics periodically or aperiodically to the receiver OMMA layer 1602. The receiver OMMA layer 1602 may determine the appropriate split based on the feedback metrics and may determine the ratio in which IP packets may be distributed across the RATs 1603.

[0170] FIG. 17 is a diagram illustrating an example of states and state transition triggers of an OMMA layer. Table 3 shows an example event list for OMMA layers.

Table 3

I Y KNT/STAT I: I > .CRI P NON ACT ION I N ITI A L M NA L

TRANSITION TRKiCi KR S I ATI . ST TL^"

OMMA START Initi alization at Transition to IDLE ΓΝΙΤ IDLE start up

OMMA STOP Rese It Transition to ΓΝΙΤ IDLE ΓΝΙΤ

IP PKT ARRIVAL DL IP p acket arrives OMMA performs IDLE IDLE fron l IP module Opportunistic assignment

to O MMA of IP packet to ISM band module or TVWS band

ISM_MSDU_ARRIVAL_U MAC MSDU OMMA is Transparent; IDLE IDLE L from ISM band Forwards packet to IP

arrives at OMMA module

TVWS_MSDU_ARRIVAL MAC MSDU OMMA is Transparent; IDLE IDLE _UL from TVWS band Forwards packet to IP

arrives at OMMA module

[0171] TCP over OMMA may be described herein. TCP IP flows may require some special handling by an OMMA layer. FIG. 18 is a diagram illustrating an example TCP. For example, there may be a single physical transport. The sending TCP entity may transmit six packets. It may be assumed that the interface is somewhat lossy, so one or more of the packets may get dropped and never reach the receiver. For example, packets 1, 2, 3, 5, and 6 may reach the receiver and packet 4 may be dropped. When the receiver senses that there is a missing packet, the receiver may presume that there was congestion on the interface between the sender and the receiver. The receiver may inform the sender of the missing packet. The sender may retransmit the missing packet, and may decide to limit the amount of data is transmits to the receiver, for example, because there is congestion on the link and the best way to reduce congestion is to throttle back how much data is being transmitted. If packets continue to be dropped, this process may continue until the sender is barely transmitting any packets to the receiver. Since TCP may be greedy when it comes to consuming bandwidth, if packets are not dropped, then the sender may keep increasing the amount of packets it transmits until packets are dropped. In this way, TCP may maximize it throughput up to the limits of the link and may have a mechanism to handle when it has reached the limits of the link.

[0172] FIG. 19 is a diagram illustrating an example of aggregation performed for TCP data. For example, it may be assumed that the sender has six packets to transmit to the receiver. The packets may reach the OMMA layer on the sender side, which may decide that the first packet is to be transmitted over 802.1 In while the remaining five packets are to be transmitted over the TVWS channels. It may also be assumed that the 802.1 In link has a higher latency than the TVWS channels, so that packets two through six may arrive before the first packet. The OMMA layer at the receiving side may push the received packets up the stack. When they reach the receiving TCP entity, it may assume that the first packet was dropped and request the sending side to retransmit. The sending TCP entity may assume that there is congestion on the link, retransmit the missing packet, and enter congestion avoidance. Congestion avoidance may reduce the amount of packets that will be transmitted. The effect of this is that even though there is no congestion, very little data may be transmitted from the sender TCP entity. Therefore, even though there is more bandwidth available since the OMMA layer aggregation is being utilized, the TCP entity may not attempt to utilize the additional bandwidth since it has sensed congestion. Therefore, the reordering issue may be addressed within the OMMA layer at the sender or the receiver.

[0173] The OMMA layer may interface the TCP layer of the stack to receive some of the internal data of the TCP entity. The OMMA layer may receive information about when the receiving TCP entity is about to signal to the sending TCP entity that is it receiving packets out of order. Upon receipt of this information, the OMMA entities at the sender and receiver may exchange this information and use it in the routing decisions that may be made by the sending OMMA entity. This TCP information may be in addition to any other information that the sending OMMA entity may use to make routing decisions on a packet-by-packet basis. FIG. 20 is a diagram illustrating an example architecture of such a solution. The parameters to be passed from the TCP entities to the OMMA entities may be related to the timers and other parameters that TCP uses to determine if congestion is occurring.

[0174] The OMMA layer may perform packet inspection of the TCP header to deduce the state of the TCP connection. This may need to be performed in both the uplink and downlink directions, therefore, this solution may require the OMMA layer to be cognizant of whether the packet is being sent or received. Therefore, when the OMMA layer at the receiver receives a packet, it may determine if it is a TCP packet or not. If not, then no further processing may be required. If it is a TCP packet, then it may be determined if it is either a transmit packet or a receive packet. After this determination, the required information within the TCP header may be extracted by the OMMA layer. For example, TCP parameters of interest may include, but are not limited to, sequence number, acknowledgement number, and window size. This information may be retained for each specific 5-tuple: source and destination IP address, source and destination port number, and IP protocol, which may be TCP.

[0175] As the transmit and receive packets traverse the OMMA entities, the OMMA layer at the sender may be able to deduce whether or not the receiving entity is receiving all the packets in the proper order for that specific TCP session. This information may then be used by the transmitting OMMA layer as an input to the decision process that determines over which transport to dispatch a packet. FIG. 21 is a diagram illustrating an example processing of such a solution. [0176] The OMMA layer at the sender may insert sequence numbers into the packets that are being sent. The OMMA layer at the receiver may reorder the packets based on these sequence numbers before passing them up to the IP layer, and subsequently to the TCP layer. This may ensure that the receiving TCP entity may not receive packets out of order. The receiving OMMA layer may not hold packets forever while it waits for any missing packets. Eventually, the receiving OMMA layer may pass along the packets it has even if there is missing data. Holding packets for extended periods of time may cause the transmitting TCP entity to retransmit these packets since the transmitting TCP entity may not receive any

acknowledgements for those packets that are being held within the receiving OMMA layer.

[0177] A header may be added to the information, for example, in response to this addition of sequence numbers. The header may comprise a sequence number and/or a flow ID number, which may be used to restore the proper order to TCP flows within the receiving OMMA layer. The flow ID may be set to zero to indicate when the payload is not a TCP packet and may be set to a unique non-zero number for each IP flow. The OMMA layer at the sender may reuse the same flow ID for all packets associated with the TCP IP flow. FIG. 22 is a diagram illustrating an example header of such a solution.

[0178] When the receiving OMMA layer receives a packet it may remove the OMMA header and route the packet to the IP layer based on the information within the OMMA header. If the flow ID is set to zero, the packet may not be part of a TCP flow and may be pushed to the IP layer. If the flow ID is not set to zero, the receiving OMMA layer may compare the sequence number with the next expected sequence number for that specific flow. If it is the next expected packet, the OMMA layer may be forwarded to the IP layer. If it is not the next expected packet, the receiving OMMA layer may hold the packet and start a timer. Upon expiry of the timer, the packet may be forwarded to the IP layer. If other packets are received while the timer has not expired, the OMMA layer may perform the same logic, forwarding it to the IP layer if it is the next expected packet. As new packets are received, the packets that are being held, as a result of not being the next expected packet, may be re-evaluated to see if they are now the next expected packet. If they are the next expected packet, the OMMA layer may forward the packet to the IP layer without waiting for the timer to expire.

[0179] The OMMA layer at the sender may use feedback from the MACs of each link to attempt to schedule the sending of the packets to maximize the likelihood that they are received in order, or as close as possible, to not trigger the congestion control mechanisms within TCP. While TCP may not require in order packets, it may do some reordering on its own and it may be tolerant of some out of order packets. This may minimize the amount of data that is out-of order. The feedback parameters that may be used within the OMMA layer are described herein.

[0180] An example of the logic and queuing structures that may be used include, but are not limited to, the packets from the IP layer that may be merged into a single buffer, each MAC may have a very small buffer, and a timer may be used for each MAC queue. Packets from the IP layer may be merged into a single buffer. The OMMA layer may service the buffer one packet at a time and may make a decision as to which transport should be used, which, for example may including determining which transport provides the highest likelihood that the packet may be received in order. Each MAC may have a small buffer. The OMMA layer may place each packet into these buffers if the buffer is not full, for example, based on the decision criteria. A timer may be used for each MAC queue, for example, so if a packet does not make it out of the buffer in the required timer and it is a protocol that has retransmissions (e.g., TCP), it may be dropped, for example, since the packet is part of a protocol which has retransmissions.

[0181] TCP may allow for packets to be received out of order. An attempt may be made to deliver the packets in as much of an ordered fashion as possible. Routing decisions may be made on a packet to attempt to minimize the disruption within the receiving TCP entity. For example, a transport decision for every x packets of every flow may be made, for example, instead of making a transport decision for every packet of every flow. Making the decision of whether to use the same transport or move the flow to another transport may be performed periodically instead of for every packet. This may minimize the amount of reordering and out- of-order packets that may occur within the receiving TCP entity. The value of x may be different for each type of IP flow. Feedback from the TCP entity and/or the MAC entity may be utilized, for example, to adjust the value of x dynamically.

[0182] FIG. 23 is a diagram illustrating an example of how an OMMA layer may route packets. FIG. 23 illustrates that the OMMA layer may decide to keep the TCP packets on one transport. The UDP packets may be transmitted over both transports. For example, the OMMA layer may utilize the 5-tuple of each packet and determine to keep or not keep the TCP IP flows on the same transport. For example, the OMMA layer may move them periodically.

[0183] The OMMA may maintain and reference a table that has information for each 5- tuple that the OMMA receives from the IP layer. FIG. 24 is a diagram illustrating an example of a table that may be maintained by an OMMA layer. The 5-tuple fields may be populated by the OMMA layer, for example, based on the IP packets it receives from the IP layer. If an IP packet arrives with a new 5-tuple, a new row may be added to the table. The current transport field may be filled in by the OMMA layer, for example, whenever it changes the transport that it plans to use for a specific 5-tuple. This may include selecting the transport once the first packet in a transport arrives for scheduling. The evaluation period may be a time of how often the OMMA layer may check to see if a TCP flow may be moved from one transport to another. Depending on the mode, this field may or may not be used. The OMMA layer may receive or determine the evaluation period from a policy. For example, if the evaluation period is 50 msecs, then the OMMA layer may revisit the routing decision every 50 msecs.

[0184] The split may be used by the OMMA layer to indicate how much of each IP flow may be routed over each transport. This may or may not be used depending on the mode. If the mode is set to split, then the OMMA layer may split the flow according to the percentages. For example, the OMMA layer may do this if the IP flow is TCP or UDP. For a TCP flow, aggregation may be performed, for example, 90% on one transport with the remaining 10% on another transport. For a UDP flow, aggregation may be performed, for example, according to some fixed percentages. These split percentages may come from a policy file.

[0185] The mode may be used to tell the OMMA layer how it may make scheduling decisions. For example, if the mode is set to split, then the scheduler of the OMMA layer may use the split percentages to make scheduling decisions. If the mode is not set to split, then the scheduler of the OMMA layer may do other logic. This logic may depend on the packet type. For TCP, it may use the current transport until the evaluation time has been reached, then reevaluate which transport to use. Once this re-evaluation has been decided, the OMMA layer may use that decision until the next period has elapsed. For UDP, the OMMA layer may determine the best transport to use for every packet that it schedules. Evaluation period, split, and/or mode may be filled in by the OMMA layer, for example, utilizing one or more of the rules and/or policies described herein. The evaluation period may be for TCP flows. Split and/or mode may be for TCP ad/or UDP flows.

[0186] The logic to determine the best transport may be described herein. For example, it may be the transport with the most available capacity, or the lowest latency or the lowest jitter. For example, it may be a combination of the criteria described herein or it may be defined per 5- tuple. For example, it may be as a result of metrics received from the TCP entity and/or the MAC entities.

[0187] FIG. 25 is a diagram illustrating an example of the logic 2500 that may be used by an OMMA layer when there is a packet to be scheduled. A packet may be received by the OMMA layer at 2501. It may be determined at 2502 whether the packet is in a table (e.g., the table of FIG. 24). If the packet is not then in table, then it may be determined that the packet is a packet from a new IP flow. If the packet is in the table, then it may be determined that the packet is from an existing IP flow. At 2503, it may be determined whether the packet is a UDP packet. If the packet is a UDP packet, then it may be determined how to route the UDP packet at 2505. If the packet is not a UDP packet (e.g., a TCP packet), then it may be determined how to route the packet at 2504. If the packet is from an existing IP flow, there may be a unique logic for UDP and/or TCP packets. Based on the packet type, UDP logic (e.g., Figure 26) or the TCP logic (e.g., Figure 27) may be used.

[0188] At 2506, if the packet is from a new IP flow, the best transport to route this packet may be determined by the OMMA layer and the packet may dispatched on that transport. The best transport may be the transport with the most capacity, the lowest latency, the least jitter, etc. After the routing or transport technique is determined, then the table may be updated with the packet at 2507. The packet may then be queued onto a separate transport.

[0189] FIG. 26 is a diagram illustrating an example of UDP logic that may be utilized by an OMMA layer. The UPD logic may look at the mode for the specific 5-tuple at 2601. If the mode is split, then the packet may be routed over the transport that best maintains the split percentages in the table. At 2602, if the mode is set to follow the split in the table for this packet, then the transport that best maintains the split may be determined. For example, if the split in the table is 50%-50%, then the OMMA layer may alternate between the transports when sending the packet. If the mode is not split, then the packet may routed over the best transport. For example, at 2603, since the packet is a UDP packet, the best transport may be determined for routing the packet. For example, the transport with the most capacity, the lowest latency, the least jitter, etc.

[0190] FIG. 27 is a diagram illustrating an example of TCP logic that may be utilized by an OMMA layer. The TCP logic may look at the mode for the specific 5-tuple at 2701. If the mode is split, then the packet may be routed over the transport that best maintains the split percentages in the table at 2702. Checks in this path may be utilized, for example, since there may be limits to how much aggregation may be done with TCP without causing a problem. If the limit is a 90%- 10% split, then this logic may preclude an entry of a 50%-50% split between the transports. If the mode is not split, then the evaluation period may be consulted at 2703. If it is time to re-evaluate which transport is used for this specific IP flow, then a decision may be made, for example; do we leave the IP flow on the current transport or do we move it to the other transport. If it is not time to re-evaluate which transport is used for this specific IP flow at 2704, then the packet may be dispatched using the current transport. If there is time to re-evaluate which transport is used for the IP flow at 2705, then the best transport may be selected. For example, since this may be a TCP packet, the OMMA layer may re-evaluate (e.g., periodically re-evaluate) which transport to use. After a determination is made by the OMMA layer, the OMMA layer may continue to utilize that transport until the next time to evaluate occurs. The best transport may be the transport with the most capacity, the lowest latency, the least jitter, etc.

[0191] Using multiple RATs simultaneously may provide the benefit of increased bandwidth for an application (e.g., an IP flow) as well as increased reliability. As described herein, the OMMA layer may manage multiple RAT interfaces efficiently and enable aggregation of an IP flow across multiple RAT interfaces or segregation of an IP flow over specific RATs. As described herein, the OMMA layer may reside below the IP layer and above the RAT protocol stacks. The OMMA layer may include control plane and data plane processing capability.

[0192] The OMMA layer may receive metadata/link statistics feedback from each RAT.

Within the OMMA layer, an OMMA scheduler may be responsible for traffic shaping, for example, by policy -based routing of IP packets across bands or feedback-based routing of packets across bands. The OMMA layer may be transparent in that it distributes and/or combines packets from different RATs and forwards the packets to the IP layer. The OMMA layer may be non-transparent, in that it adds additional headers at the transmitter, and/or reads and removes the headers at the receiver. The OMMA layer may utilize a packet distribution mode. As described herein, the packet distribution mode may be a diversity mode, a multiplexing mode, a hybrid mode, and a dynamic RAT selection mode.

[0193] Beacons, probe request/response and/or association request/response frames may be updated to include OMMA layer discovery parameters, for example, in WiFi based RATs. OMMA layer discovery parameters may include, but are not limited to, OMMA modes, OMMA schemes, OMMA packet distribution modes, etc.

[0194] Using multiple RATs simultaneously may provide increased bandwidth and/or increased reliability for an application. For example, a system comprising an OMMA layer may intelligently manage data traffic across multiple RATs for improved performance by

dynamically scheduling data packets across RATs as a function of the link quality of each RAT. The OMMA layer may employ an architecture that handles control plane and data plane processing. The OMMA layer may comprise logical entities that may be separated into different physical entities in a network, for example, to enable many possible physical network implementations to achieve improved multi-RAT operation. The OMMA layer may evaluate (e.g., periodically evaluate) RAT availability of a device (e.g., a WTRU or NT). The OMMA layer may store information regarding RAT availability and/or may utilize information regarding RAT availability for RAT selection. [0195] IP fragmentation may depend on the maximum transmission unit (MTU) size of the RAT. If a terminal supports multiple RATs, one or more of the RATs may have a different MTU size. An OMMA layer may support unequal MTU sizes of RATs, for example, by supporting fragmentation and reassembly of packets. For example, the OMMA layer may receive MTU information associated with one or more RATs, packet size information associated with one or more IP packets (e.g., of an IP flow), and adjust a size of a MTU of a RAT according to the MTU information associated with the one or more RATs. For example, the OMMA layer may receive first MTU information associated with a first RAT, and receive second MTU information associated with a second RAT. The OMMA layer may receive packet size information associated with a first IP packet, and receive packet size information associated with a second IP packet. The OMMA layer may adjust at least one of a size of a MTU of the first IP packet and a size of a MTU of the second IP packet based on the first MTU information and the second MTU information. The OMMA layer may adjust the size such that the size of the MTU of the first packet is different from the size of the MTU of the second packet. The OMMA layer may adjust the size such that the size of the MTU of the first packet is the same as the size of the MTU of the second packet.

[0196] An OMMA layer may comprise a mechanism to readjust the assigned medium resources to a WTRU on each RAT, for example, based on global knowledge of resource assignment on other RATs. For example, the OMMA layer may utilize MAC resource reservation to achieve globally optimal resource allocation across RATs.

[0197] As described herein, a device (e.g., a WTRU or NT) may include an OMMA layer that manages multiple RAT interfaces to enable opportunistic RAT selection and aggregation for sending data traffic over more than one RAT interface. The OMMA layer may reside below the IP layer and/or above the RAT protocol stacks. The OMMA layer may include control plane and/or data plane processing capability. The control plane may handle, for example, MAC resource reservation, RAT availability update management, and fragmentation control. The data plane may handle, for example, policy-based scheduling and feedback-based scheduling. The OMMA layer may define entities, for example, a policy database and a WTRU RAT capability database.

[0198] An OMMA layer (e.g., subsystem or module) may reside between the RAT protocol stacks and the IP layer, for example, in the case of a multi-RAT network terminal. For example, interfaces disclosed herein may be standardized as a service access point (SAP) between the RAT protocol stacks and the OMMA layer. [0199] Part of or the entirety of the OMMA layer may reside as a logical entity on another device external to the multi-RAT network terminal, for example, such as but not limited to a common gateway (GW), which may comprise a wired network interface. Multiple single RAT network terminals may be distributed across a geographic area, for example, a large enterprise, and the OMMA layer (e.g., partially or wholly) may reside on a common gateway (GW), which may have a wired network interface. The entirety of the OMMA layer may reside in the GW. A portion of the OMMA layer (e.g., some functions of the OMMA layer) may reside in the GW, while the rest of the OMMA layer may reside within a network terminal. The physical interface between the GW and the network terminal may be standardized. For example, if the physical interface between the GW and the network terminal is wireless, then the signals may be standardized and/or detectable. For example, the OMMA controller, policy database, WTRU RAT capability database, DNS-APP, and UI-APP may reside on the GW, while the OMMA scheduler may reside on a network terminal.

[0200] As described herein, a node (e.g., a NT or a WTRU) comprising an OMMA layer may aggregate bandwidth available on multiple radio access technologies (RATs). The node may establish a communication path via one or more RATs. For example, the node may establish a first communication path via a first RAT associated with the node, and establish a second communication path via a second RAT associated with the node. The node may receive feedback information associated with the one or more RATs. For example, the node may receive first feedback information associated with the first RAT, and receive second feedback information associated with the second RAT. The node may determine to send one or more IP packets of an IP flow across the one or more RATs, for example, as described herein (e.g., using feedback information, one or more policies/rules, a distribution mode, etc.). For example, the node may determine a first IP packet to send via the first RAT according to the first and second feedback information. The node may also determine a second IP packet to send via the second RAT according to the first and second feedback information. The first and second IP packets may be part of an Internet Protocol (IP) flow addressed to a receiving node (e.g., which may be a NT or a WTRU). The node may send one or more IP packets via the one or more RATs. For example, the node may send the first IP packet via the first RAT and send the second IP packet via the second RAT.

[0201] FIG. 28 is a functional block diagram illustrating an example implementation of an OMMA layer. As shown in FIG. 28, the OMMA layer 2800 may comprise an OMMA Controller 2810, an OMMA Scheduler 2820, a RAT Capability Database 2830 (e.g., which may be referred to as a WTRU RAT Capability Database), and a Policy Database 2840. [0202] The OMMA Controller may send control parameters to the OMMA Scheduler and/or the WTRU Capability Database. The control parameters may be used to make a decision on RAT selection for incoming IP packet flow. These parameters may be based on feedback from RATs and/or control information of incoming IP packets.

[0203] FIG. 29 is a functional block diagram that depicts an example implementation of an OMMA Controller. As shown in FIG. 29, the OMMA Controller 2900 may comprise a Multi-RAT Multi-Band Device Discovery module 2910 that may keep track of initial discovery and/or association phase results from each RAT, or example, through an interface A3 (e.g., as shown in FIG. 28). After receiving the maximum RAT capability of other devices (e.g., WTRU or NT) via a beacon request and/or probe response, the Multi-RAT Multi-Band Device

Discovery module 2910 may calculate a list of matched RATs and may send this information to a RAT Protocol stack, for example, using the interface A3 (e.g., as shown in FIG. 28). The Multi-RAT Multi-Band Device Discovery module 2910 may save the associated device's maximum RAT capabilities in the RAT Capability Database (e.g., RAT capability database 2830), for example, through an interface Al (e.g., as shown in FIG. 28). The Multi-RAT Multi- Band Device Discovery module 2910 may send its own system parameters to RATs, which may be used in initial discovery and association process for advertisement, for example, through the interface A3 (e.g., as shown in FIG. 28).

[0204] The OMMA Controller 2900 may comprise a Multi-RAT Multi-Band Security module 2920 that may store one or more security parameters (e.g., GMKSA) that may be generated at different phases of security association between a WTRU and a NT, for example, to enable multi-RAT multi-band security.

[0205] The OMMA Controller 2900 may comprise a Feedback Device Classifier module

2930. A RAT (e.g., each RAT) may provide feedback metrics (e.g., a vector comprising a value of serving rate, jitter, packet delay, and packet loss rate on its MAC) to the OMMA Controller 2900 per device (e.g., WTRU or NT) per access category supported at that RAT. This may be performed through interface A2 (e.g., as shown in FIG. 28). The Feedback Device Classifier module 2930 may classify the metrics for each device address (e.g., WTRU address or NT address), for example, so that the OMMA Controller 2900 may send feedback metrics to each device's OMMA layer (e.g., since each device may have different RAT capability), for example, through interface A5a (e.g., to a Feedback Based Scheduler (FBS) of OMMA Scheduler) and/or interface A5b (e.g., to a Policy Based Scheduler (PBS) of OMMA Scheduler) (e.g., as shown in FIG. 28). [0206] The OMMA Controller 2900 may comprise a Feedback QoS Classifier module

2940. The Feedback QoS Classifier module 2940 may classify the feedback metrics based on their access category ID, for example, so that it can send feedback per device per access category through interface A5a and/or A5b (e.g., as shown in FIG. 28).

[0207] The OMMA Controller 2900 may comprise a RAT Update Management module

2950. RAT availability of a device (e.g., WTRU) may change with time (e.g., due to mobility, a device may have different RATs enabled at different times), so the RAT Update Management module 2950 may keep track of RAT capability/availability of associate devices. The RAT Update Management module 2950 may receive the knowledge of RAT availability by using interface A3 with the RAT Protocol stack (e.g., as shown in FIG. 28). The RAT Update Management module 2950 may maintain the associated device's RAT availability list via a periodic update message from each WTRU, for example, at the NT side. It may use the Beacons received from a NT (e.g., periodically) to maintain the NT's RAT availability list, for example, at the WTRU side. The RAT Update Management module 2950 may reflect changes of available RATs in a RAT Capability Database (e.g., RAT capability database 2830), for example, on both sides, for example, through interface Al (e.g., as shown in FIG. 28).

[0208] The OMMA Controller 2900 may comprise a Packet Arrival Rate Estimation module 2960 that may be used to estimate the rate at which IP packets arrive at the OMMA layer from the IP layer. The arrival rate may be calculated as x = 1/E [ti+l-ti] for all i = 1, ..., n, where ti may be the time instant at which packet Id "I" arrives at the OMMA layer, ti+1 may be the time instant at which packet Id arrives at the OMMA layer, and E[.] may represent an expectation operation (e.g., a moving average or an exponential average), (ti+l-ti) may represent the inter-arrival time between successive packets. This arrival rate "x" may be appended with one or more feedback metrics and/or sent to the FBS.

[0209] The OMMA Controller may comprise a MAC Resource Reservation module 2970 that may reserve required resources on one or more RATs. The MAC Resource Reservation module 2970 may reserve resources (e.g., a fixed amount of bandwidth for a fixed amount of time) on one or more RATs, for example, based on the feedback metrics from the RATs and/or QoS requirements of incoming IP packets. The decision of requirement may be based on some predefined policies stored in a policy database. The reservation signaling between an OMMA Controller 2900 and a corresponding RAT may be performed through interface A3 (e.g., as shown in FIG. 28). The OMMA Controller 2900 may access the Policy Database (e.g., policy database 2840) through interface A10 (e.g., as shown in FIG. 28). [0210] The OMMA Controller 2900 may comprise a Fragmentation Controller module

2980 that may make decisions for enabling of fragmentation (e.g., within the OMMA Scheduler) for an incoming IP packet. For an IP packet, the RAT selection decision may be sent from the OMMA Scheduler to this module (e.g., within the OMMA Controller 2900), for example, through an interface Al l (e.g., as shown in FIG. 28). The Fragmentation Controller 2980 module may receive the knowledge of MTU size of one or more RATs from a RAT Capability Database (e.g., RAT Capability Database 2830), for example, using interface Al (e.g., as shown in FIG. 28). Based on the received RAT selection decision, MTU information for a RAT, and an incoming IP packet (e.g., size), the Fragmentation Controller module 2980 may decide to enable or disable fragmentation (e.g., within OMMA scheduler) for a RAT.

[0211] If the Fragmentation Controller module 2980 decides to fragment the IP packet on a RAT, it may enable a Packet Fragmentation module of the OMMA scheduler for that RAT given that fragmentation may be allowed by the IP layer for that IP packet. If the IP layer does not allow fragmentation for an IP packet, and the Fragmentation Controller module 2980 decides to fragment the IP packet on the RAT, it may send an ICMP unreachable error to the IP layer with the information of MTU size of that RAT (e.g., in case of single RAT selection), or a minimum MTU size of one or more selected RATs (e.g., in case of multiple RAT selection). If the Fragmentation Controller module 2980 determines that there is no requirement of fragmentation, then it may disable the Packet Fragmentation module of the OMMA scheduler of the corresponding RAT.

[0212] The OMMA Controller 2900 may comprise an OMMA Mode Management module 2990 that may manage the mode (e.g., Transparent or Non-Transparent) of the OMMA Scheduler in which it has to operate. The OMMA Controller 2900 may make the mode decision and notify the OMMA Scheduler. The OMMA Mode Management module 2990 may receive the mode decision for a device (e.g., WTRU) with the help of Policy Database (e.g., policy database 2840), for example, using interface A10 (e.g., as shown in FIG. 28). The OMMA Mode Management module 2990 may send this information to a corresponding device (e.g., WTRU), for example, using interface A3 (e.g., as shown in FIG. 28). This may be performed at the NT side. The OMMA Mode Management module 2990 may communicate with a RAT Capability Database (e.g., RAT Capability Database 2830), for example, through interface A 1 (e.g., as shown in FIG. 28), for example, to query the RAT Availability list to select an available RAT for sending mode information. The OMMA Controller 2900 may inform the OMMA Scheduler about the mode decision, for example, using interface A9 (e.g., as shown in FIG. 28). This may be performed on the WTRU side and/or the NT side. [0213] The OMMA Scheduler may determine the way packets are routed across one or more RATs (e.g., as shown in FIG. 28). The OMMA scheduler may distribute the incoming IP packet flow to the selected RATs based on a chosen packet distribution algorithm. For example, the OMMA Scheduler may receive feedback for one or more RATs per access category from the Controller, for example, through interface A5a and A5b (e.g., as shown in FIG. 28). Based on the QoS requirement (e.g., received by the IP QoS Identifier), and/or feedback from the controller and one or more of the RATs (e.g., capability), the OMMA scheduler may determine RAT(s) selection.

[0214] FIG. 30 is a functional block diagram illustrating one example of an OMMA

Scheduler. For example, as shown in FIG. 30, an OMMA Scheduler 3000 may comprise a Policy Based Scheduler (PBS) module 3010. The PBS module 3010 may perform policy based routing, for example, where packets may be sent on different RATs using pre-defined rules (e.g., operator policy, WTRU QoS class, etc.). The PBS module 3010 may utilize feedback metrics received from an OMMA Controller, for example, through interface A5b (e.g., as shown in FIG. 28). As described herein, the rules may include, but are not limited to, one or more of device capability, an operator policy, a quality of service (QoS) class, an IP packet flow, device coordinates, a source domain, a source IP address, a destination domain, a destination IP address, a port number, a subscriber priority, a link quality, charging, security, the rules/policies described in Table 5, etc.

[0215] The OMMA Scheduler 3000 may comprise a Feedback Based Scheduler (FBS) module 3020. The FBS module 3020 may perform feedback based routing, for example, where packets may be sent on different RATs using feedback metrics (e.g., RSSI, medium access delay, etc.), which may reflect the average state of the link between NT and WTRU on each RAT. These feedback metrics may be received from the OMMA Controller, for example, through interface A5a (e.g., as shown in FIG. 28). As described herein, the feedback may include, but is not limited to, one or more of a medium access delay, jitter, a frame error rate, an average data rate, a received signal strength indication (RSSI) level, queuing latency per access category per RAT, end-to-end latency, a backoff time, a number of channels, channel bandwidth, a media access control (MAC) type, MAC aggregation support, an access category, a transmission opportunity (TXOP) duration, an estimated arrival rate of a packet, an average packet delay, packet loss rate (or frame error rate), queuing latency, number of MAC retransmissions, an average physical layer data rate, an average serving rate, an average serving latency, a serving delay variance, a second moment of average serving latency, vacation time, an average vacation time, a second average of vacation time, a vacation time variance, QoS ID, TCP parameters, such as sequence number, acknowledgement number, and window size, for example, etc.

[0216] Feedback metrics, such as, but not limited to medium access delay, frame rate error, data rate, queuing latency, end-to-end latency, TXOP duration, AC with medium access, backoff time, number of channels, MAC aggregation supported, MAC type, jitter, serving delay, serving delay variance, vacation time, vacation time variance, STA_Addr, QoS_ID, and number of MAC retransmissions may be provided to the OMMA layer from the MAC layer. Feedback metrics, such as, but not limited to, RSSI, number of channels, and channel bandwidth may be provided to the OMMA layer from the MAC layer.

[0217] Medium access delay may refer to the total packet delay in a queue plus a contention delay. The medium access delay may be the duration from the time when packet is inserted into the transmission queue at the MAC layer until the time when the frame is sent to the physical layer. Jitter may refer to the difference Tj between one way delay of successive packets at a sender and a receiver, for example, ignoring lost packets. Tj may be defined as the difference to and ti, where:

to : 'Inter-arrival time between successive packets at receiver'; and ti : 'Inter-arrival time between successive packets at sender'.

[0218] Serving rate may be calculated as 1/Tj, where Tj may be an average serving delay per packet at RATj. Tj may be defined as time duration from ¾to tj, where:

to - time stamp MAC start perform CSMA/CA for that packet; and ti - time stamp when ACK for that whole packet is received successfully at MAC layer of sender node.

[0219] Serving latency/delay may equal one divided by the serving rate (e.g., 1/serving rate). The average packet delay may refer to the total delay experienced by an IP packet from the time t_a it enters the MAC queue until the time ¾ when the ACK for the packet is received at the sender. The average packet delay may be the summation of queuing delay and serving delay at a MAC layer for an IP packet.

[0220] Vacation time may be the time duration for a NT to stop serving a particular queue in order to serve another queue (e.g., a queue belonging to another WTRU, to send data of other Access Categories, etc.). The packet loss rate may be referred to as the frame error rate. The packet loss rate may be an average number of packets/frames in error in a unit time.

[0221 ] Queuing latency may be the total delay experienced by an IP packet from the time t_a it enters the MAC layer queue until the time to when MAC layer may begin to perform CSMA/CA for that packet. The number of MAC retransmissions may be the average number of MAC retransmission attempts per packet. The RSSI level may be an average RSSI level of a signal from a WTRU, for example, as measured at a NT. The average physical layer data rate may be the average data rate per second for a NT- WTRU link.

[0222] Serving delay variance may be calculated by:

where δ² may be the serving delay variance, X may be the serving delay, and N' may be the number of samples being used to calculate the serving delay variance.

[0223] Vacation time variance may be calculated by:

where δ may be the vacation time variance, X may be the vacation time, and N' may be the number of samples being used to calculate the vacation time variance.

[0224] STA_Addr may the WTRU address to associate feedback metrics with the appropriate NT- WTRU link. QoS_ID may be an access category identified (AC_BK, AC_VO, AC_BE, etc.) to associate feedback metrics with an appropriate access category.

[0225] The OMMA Scheduler 3000 may comprise a RAT Update Sender module 3030.

The RAT Update Sender module 3030 may extract (e.g., periodically extract) information regarding RAT availability from the RAT Capability Database (e.g., RAT Capability Database 2830), for example, through interface A4 (e.g., as shown in FIG. 28). The RAT update sender 3030 may send this information to the corresponding NT using over-the-air signaling.

[0226] The OMMA Scheduler 3000 may comprise a Device Capability Database Query module 3040. The Device capability database query module 3040 may communicate with the RAT Capability Database (e.g., RAT Capability Database 2830) to query about the RAT capability/availability of a specific device (e.g., WTRU). The RAT capabilities may be provided by the capability database in its response. This may be performed through interface A4 (e.g., as shown in FIG. 28).

[0227] The OMMA Scheduler 3000 may comprise a Packet Fragmentation module 3050.

The Packet Fragmentation module 3050 may be responsible for packet fragmentation of incoming IP packets from the IP layer at the OMMA sender (e.g., for each RAT). The decision of fragmentation may be received from the Fragment Controller module of the OMMA

Controller. Based on this decision, the packet fragmentation module 3050 may fragment the incoming packet or may not fragment the incoming packet. After this operation, the packet fragmentation module 3050 may send the packet to a lower layer. [0228] The OMMA Scheduler 3000 may comprise an Rx Duplicate Packet

Detection/Recovery module 3060. A sender may switch RATs, for example, in the case of a single RAT selection at any given time. When a RAT switch happens, the OMMA sender may duplicate packets to avoid out-of-order packet reception at the OMMA receiver. The Rx Duplicate Packet Detection/Recovery module 3060 may perform duplicate packet detection and removal, for example, at the OMMA receiver.

[0229] The OMMA Scheduler 3000 may comprise an Rx Packet Reassembly module

3070. The Rx Packet Reassembly module 3070 may be responsible for packet reassembly of fragmented packets at the OMMA receiver (e.g., in case any fragmentation occurred at the OMMA sender) (e.g., at each RAT). The Rx Packet Reassembly module 3070 may determine the OMMA header (e.g., if it is operating in Non Transparent mode) to receive the knowledge of whether reassembly is required (e.g., at each RAT). If there is no need of reassembly, the Rx packet reassembly module 3070 may send the packet to an upper module (e.g., an Rx Duplicate Packet Detection/Recovery module 3060). If it is determined that reassembly is needed, the Rx Packet Reassembly module 3070 may reassemble incoming packets on the RAT before transmitting them to an upper module.

[0230] The OMMA Scheduler 3000 may comprise an Rx Reordering Buffer module

3080. A sender may switch RATs frequently, for example, in the case of a single RAT selection at any given time. When a RAT switch happens, for example, a switch from a high latency RAT to a low latency RAT, packets may be received out-of-order for a single IP stream. The Rx Reordering Buffer module 3080 may maintain the order of IP packets before sending them up to an IP layer.

[0231 ] The OMMA Scheduler 3000 may comprise an IP Packet Classifier module 3090.

The OMMA layer may maintain a separate OMMA scheduler 3000 for each device (e.g., WTRU), for example, to support multi-device (e.g., multi-WTRU) association at another device (e.g., NT). Since a device (e.g., a WTRU) may have different RAT capabilities, selection of RATs for an IP packet may be different for each device, for example, based on policies such as, but not limited to QoS requirements of each IP flow. Through the IP Packet Classifier module 3090, the OMMA layer may read the header of the incoming IP packet and determine the destination (e.g., WTRU) address. The OMMA layer may send the packet to the corresponding device's (e.g., WTRU's) OMMA scheduler instance.

[0232] The OMMA Scheduler 3000 may comprise an IP Packet QoS Identifier module

3095 that may take an incoming IP packet and read the header information regarding the IP QoS class of the packet. The IP Packet QoS Identifier module 3095 may map the IP QoS class to one or more (e.g., four) MAC access categories. This information may be used by the PBS module 3010 and/or FBS module 3020 to determine RAT selection for an IP packet.

[0233] Referring to FIG. 28, the OMMA layer may comprise a RAT capability database

2830 may store the RAT capability information of associated WTRUs at NTs and/or associated NTs at WTRUs. This database 2830 may comprise multiple types (e.g., three types) of information relating to available RATs for an associated WTRU/NT. This information may include, but is not limited to, maximum capability of RAT (e.g., per WTRU or per NT), available RATs at a given time (e.g., per WTRU or per NT), and MTU for each RAT.

[0234] The RAT capability database 2830 may store the Maximum Capability of a device (e.g., WTRU) after a Discovery and Association phase, representing the maximum RAT capability (e.g., and not just those which may have better instantaneous channel quality) of a device (e.g., WTRU). This information may be stored in the RAT capability database 2830 by the OMMA Controller, for example, through interface Al (e.g., as shown in FIG. 28).

[0235] The RAT capability database 2830 may store the Available RATs at a given time for a device (e.g., WTRU). The maximum RAT capability (e.g., a subset of maximum RAT capability) may be enabled at a given time, for example, based on the average link quality (e.g., temporary availability/unavailability of RATs due to mobility). The RAT Capability Database 2830 may store this available RAT information for an associated device (e.g., WTRU). The OMMA Controller may update (e.g., continuously update) the available RAT capability of a device (e.g., WTRU) in this database 2830, for example, based on feedback metrics from each RAT.

[0236] The RAT capability database 2830 may store the Maximum Transmission Unit

(MTU) size for an available RAT. The Packet Fragmentation/Reassembly module of the OMMA scheduler may perform MTU discovery of a RAT, and may store the MTU size in the capability database 2830. For example, for a RAT "i," if the maximum capability is "1" and availability is "1," then the OMMA layer may determine that the OMMA sender may schedule packets on this RAT. If the maximum capability is "1" and availability is "0," or if the maximum capability is "0" and availability is "0," then the OMMA layer may determine that the OMMA sender may not schedule packets on this RAT. Table 1 is an example representation of RAT capability storage where "1" may indicate a RAT is available, and "0" may indicate a RAT may not be available. The type of RAT (e.g., LTE, 802.1 In, HSPA, etc.) may be indicated by a predefined RAT ID.

Table 4 WTRU RAT 1 RAT 2 RAT n Address Max Availability Max Availability Max Availability

Capability Capability Capability

MTU 1 Ml J 2 MTU n

WTRU 1 1 1 0 1 1 1

WTRU 0 0 1 1 0 0 2

WTRU 1 1 1 1 1 1 "k"

[0237] Referring to FIG. 28, the OMMA layer may comprise a Policy Database 2840 that may comprise one or more predefined policies/rules that may be designed for packet distribution on one or more RATs. The policies may be predefined by the administrator or operator. The policies may or may not be overwritten with new policies. As described herein, the

policies/rules may include, but are not limited to, one or more of device capability, an operator policy, a quality of service (QoS) class, an IP packet flow, device coordinates, a source domain, a source IP address, a destination domain, a destination IP address, a port number, a subscriber priority, a link quality, charging, and security.

[0238] The Policy Database 2840 may comprise a list of local policies or rules. Table 2 provides examples of local policies or rules that may be stored in the Policy Database 2840.

Table 5

Type Discriminators/Criteria/Events Action

Voice traffic Select RAT(s) with

Jitter<50ms and packet

latency < 5ms

QoS Video traffic Select RAT(s) with Packet loss rate<5% and packet

latency < 5ms

TCP traffic Select RATs such that

difference in serving latency is less than 1 ms

IP Flow UDP traffic Select RATs such that

difference in serving latency is less than 1 ms

Location of device (e.g.: TVWS channels are Look up TVWS database

available) and enable TVWS based

RAT

Device co-ordinates

Time of Day Assign spectral bands(and corresponding RATs) available at that time

Single ISM Band Only All traffic load will be

schedule to send out on

ISM band

Single TVWS Band Only All traffic load will be

schedule to send out on

Operator's Policies TVWS band

[0239] The Policy Based Scheduler module of the OMMA Scheduler may use one or more of the policies within the policy database 2840 to decide how to route packets. The policies within the policy database 2840 may comprise two sets of entries, discriminators/events and actions/results. There may be a one-to-one mapping between the discriminators/events and actions/results.

[0240] The discriminator/event may be evaluated at the start of an IP Flow, for example, periodically, continually, or based on an event (e.g., a link going down or becoming

available). If a discriminator/event is true, the result may be enforced. The discriminator/event may be for a specific IP Flow, a specific user, a specific transport, etc. A discriminator/event may be any combination of the above listed discriminators/events. A default discriminator/event may apply when none of the other discriminators/events are triggered or met.

[0241] The actions/results may be performed for a specific IP Flow, a specific user's IP

Flows, or a specific transport's IP Flows. The actions/results proposed may be a RAT selector value. The value may be a number in a range (e.g., [-x, x]). The value zero may indicate that there is no preference, for example, placing an IP Flow on either transport may be acceptable. The extremes (e.g., -x and x) of the range may indicate whether an IP Flow should be placed on a specific RAT or if an IP Flow should not be placed on a specific RAT.

[0242] RAT availability update management may be described herein. The OMMA module architecture may be used to address discovery and availability detection of RATs. The members of a WTRU-NT pair may associate with each other by signaling their maximum matched RAT Capability at a given time. The RAT availability list for the WTRU-NT pair may change with time depending on several factors (e.g., mobility, link quality fluctuation, etc.). Dynamic management of RAT availability may be implemented for a WTRU-NT pair, for example, in which a NT knows the RAT availability for an associated WTRU and a WTRU knows the RAT availability for the associated NT.

[0243] FIG. 31 illustrates an example call flow illustrating signaling corresponding to an example of a RAT availability update procedure described herein. A NT 3100 may send one or more beacons on its RATs (e.g., periodically). A WTRU 3150 may receive knowledge of RAT availability for an associated NT through one or more beacons. A RAT that receives a beacon may inform/update the OMMA Controller 3160 (e.g., RAT Update Management module) regarding RAT availability, for example, via a signal RAT_Capablities_A3 on interface A3 (e.g., as shown in FIG. 28). The OMMA Controller 3160 (e.g., RAT Update Management module) may update information of RAT availability in the RAT Capability Database 3170, for example, via a STA_RAT_Capability_Update_Al signal on interface Al (e.g., as shown in FIG. 28).

[0244] At the WTRU side, the OMMA Scheduler 3180 (e.g. , RAT Update Sender) may query (e.g., periodically query) the RAT Availability Database 3170 for a RAT availability list of an associated NT, for example, via a STA_RAT_Capability_Query_A4 signal on interface A4 (e.g., as shown in FIG. 28). After receiving a response (e.g.,

STA_RAT_Capability_Response_A4) for the above request, the OMMA scheduler 3180 may generate a STA_RAT_Availability message, for example, with one or more of the following parameters, to be sent using over-the-air signaling:

• STA_Addr : Self Address

• AP_Addr : Address of a NT (e.g., which it needs to send a message)

• RAT Ids : List of Ids of RATs (e.g., which are available) (e.g., [RAT_1, RAT_2 ])

[0245] The OMMA Scheduler 3180 (e.g., RAT Update Sender) at the WTRU 3150 may transmit RAT availability information to the NT 3100 using one of the operational RATs at that time. At the NT 3100, the RAT that receives the STA_RAT_Availability message may signal the OMMA Controller 31 10 (e.g., RAT Update Management module), for example, via a RAT_Capablities_A3 on interface A3 (e.g., as shown in FIG. 28). The OMMA Controller 3110 (e.g., RAT Update Management module) may update information of RAT Availability in the RAT Capability Database 3120 for that WTRU, for example, via a

STA_RAT_Capability_Update_Al signal on interface Al (e.g., as shown in FIG. 28). The RAT Availability information of a WTRU-NT pair may be refreshed (e.g., periodically refreshed).

[0246] Multi-RAT fragmentation control at the OMMA layer may be described herein.

The OMMA layer may be used for multi-RAT fragmentation control. For example, a WTRU may be associated with a NT. A single IP flow may be served by the NT-WTRU link. One or more fields (e.g., STA_Addr and IP QoS Type fields) of the signals may be fixed. The NT- WTRU link may be configured to operate using one (e.g., only one) of its RATs at any given time. For example, even if a NT and a WTRU are capable of multiple RATs, one (e.g., only one) of the RATs common to both NT and WTRU may be selected.

[0247] The OMMA layer at the sender, for example, at a NT when data traffic flows in the downlink direction from the NT to a WTRU, or, at a WTRU when data traffic flows in the uplink direction from the WTRU to a NT, may be described herein. The OMMA layer may receive packets from the IP layer and route the IP stream on to a selected RAT, for example, as determined by the PBS module and/or the FBS module. [0248] FIG. 32 is a system diagram illustrating data flow in an example scenario of an

OMMA sender in which both PBS and FBS are enabled at a NT for a single RAT selection for a single WTRU single IP flow. FIG. 33 illustrates an example call flow for this scenario. The Policy-Based Scheduler (PBS) module 3210 may determine a RAT selection based on one or more of a number of criteria. The PBS module 3210 may consider, for example, the RAT capability provided by the RAT Capability Database 3215, for example, using the interface A4 (e.g., as shown in FIG. 32). The OMMA Controller 3220 may update the RAT Capability Database 3215 (e.g., continuously) when there is a change in available RATs for a WTRU. The OMMA Scheduler 3225 may query (e.g. periodically query) the RAT Capability Database 3215 to check whether the RATs corresponding to the maximum capability of the WTRU are still available.

[0249] The PBS 3210 may consider feedback provided from the OMMA Controller 3220 for the IP flow's access category, for example, using the interface A5b (e.g., as shown in FIG. 32). In this case of single RAT selection, certain parameters in signal RAT_Metrics_PBS_A5b (e.g., on A5b interface) may be modified. The RAT_Id may be modified as the RAT ID of the enabled RAT. Metrics may comprise a number of parameters for the RAT with the Id given in the RAT Id parameter. These parameters may include, but are not limited to, the average packet delay Avg_Pkt_Delay , a Jitter parameter, and a packet loss rate Pkt_Loss_Rate. The choice of RAT may be based on maximum bandwidth available, for example, at a cold start. The PBS module 3210 may make a priority list of RATs based on the bandwidth available for each RAT. For example, if there are policies defined for these conditions, the PBS module may choose a one or more RAT capabilities based on the defined policy or policies (e.g., one or more of the policies/rules described herein). The PBS module 3210 may consider predefined policies from the policy database 3235, for example, using the interface A6 (e.g., as shown in FIG. 32). After the PBS module 3210 makes the decision on RAT selection, the decision may be sent to the Feedback based scheduler (FBS) module 3230, for example, through interface A7 (e.g., as shown in FIG. 32). A RAT_Selection_List parameter in the RAT_Selection_Decision_A7 signal on the interface A7 may comprise a single selected RAT or list of RATs based on the decision taken by the PBS module 3210. If there are no predefined policies in the Policy Database 3235, the PBS module 3210 may make the decision based on the feedback metrics from the OMMA Controller 3220.

[0250] An incoming IP packet may be delivered directly to the FBS module 3230, for example, after the PBS module 3210 makes the decision as to RAT selection. If the PBS module 3210 provides a single selected RAT to the FBS module 3230, the FBS module 3230 may select the same RAT and route the IP packets on the Packet Fragmentation module of it. If the PBS module 3210 provides multiple RATs, the FBS module 3230 may select a RAT (e.g., the best RAT), for example, based on the feedback metrics given by the OMMA Controller 3220, for example, through interface A5a (e.g., as shown in FIG. 32). In this case of single RAT selection, certain parameters in the RAT_Metrics_FBS_A5a signal of A5a interface may be modified. For example, a parameter RAT_Id may be modified as the RAT ID of the enabled RAT. Metrics may comprise one or more parameters for the RAT with the ID given in the RAT Id parameter. These parameters may include, but are not limited to, a packet arrival rate Arrival_Rate, a serving ratQ_Serving_Rate, and an average packet delay Avg_Pkt_Delay. The choice of RAT may be based on the best RAT in the priority list provided by the PBS module 3210, for example, at a cold start. For example, as shown in FIG. 32, RAT 3240 may be currently configured to have packets scheduled over it (e.g., send or receive), while RAT 3245 may be configured to have packets scheduled over it at a later time (e.g., according to the selection procedures described herein). Therefore, all packets may be scheduled over a single RAT (e.g, RAT 3240) at a given time.

[0251 ] After receiving the final decision on RAT selection, the FBS module 3230 may route the packets on the selected RAT's Packet Fragmentation module. The FBS module 3230 may transmit the selected RAT decision to the Fragmentation Controller module of the OMMA Controller 3220 for example, through interface Al 1 (e.g., as shown in FIG. 32). A parameter RAT_Id_List in Frag_Decision_Request_Al 1 on interface Al 1 may be modified to comprise one element that is a RAT Id of the selected RAT.

[0252] The Fragmentation Controller module may receive the decision of fragmentation, for example, based on the request made through interface Al l . If the fragmentation controller does not have MTU information of the selected RAT, it may communicate with the RAT Capability Database 3215 to receive MTU information, for example, using interface Al (e.g., as shown in FIG. 32). A parameter RAT_Id_List in a signal STA_RAT_Capability_Query_Al signal on Al interface may be modified to comprise an element that is a RAT Id of the selected RAT.

[0253] The RAT Capability Database 3215 may transmit the response of the above request, for example, via interface Al (e.g., as shown in FIG. 32). A parameter RAT_Id_List in a signal STA_RAT_capability_Response_Al on Al interface may be modified to comprise an element that is RAT Id of the selected RAT. A parameter RAT_Info may be modified to comprise an array of 3-tuples (e.g. , MTU, Max_RAT_Capability, RAJ ^Availability) for the RAT d of the selected RAT (e.g., as specified in RAT_Id_List). [0254] On the selected RAT, the Packet Fragmentation module may receive the decision of fragmenting or not fragmenting the incoming packet from the FBS module 3230, for example, based on the fragmentation decision received from the Fragmentation Controller module through interface A12. A parameter RAT_Id_List in a signal Fragmentation _Decision _A12 on interface A12 may be modified to comprise the RAT Id of the selected RAT. A parameter

Frag_Decision_List may be modified to comprise a value that represents the decision for fragmentation for the selected RAT, for example, "0" if fragmentation is off and Ί" if fragmentation is on. The FBS module 3230 may transmit the fragments or packets without fragments to a lower layer.

[0255] A RAT switch may occur when the selected RAT is not able to fulfill the requirement of a given IP flow QoS Class. If the PBS module 3210 detects this situation, the PBS module 3210 may query the RAT Capability Database 3215 for RAT availability information, for example, through a STA_RAT_Capability_Query_A4 signal on interface A4 (e.g., as shown in FIG. 32). After determining the RATs that are available for the WTRU (e.g., through the STA_RAT_Capability_Response_A4 signal on interface A4), the PBS module 3210 may select (e.g., randomly select) a RAT other than the current selected RAT from the RAT availability list. When a RAT switch occurs, the PBS module 3210 may signal the FBS module 3230 to duplicate one or more packets across the RATs to avoid out-of-order packet reception at the OMMA receiver. The RAT with the best feedback metrics, for example, such as but not limited to average packet delay or packet error rate, may be selected.

[0256] FIG. 34 is a functional block diagram illustrating an example of a transparent

OMMA Receiver for a single RAT enabled, single WTRU, single IP flow. The OMMA layer 3400 at the receiver may be implemented at a NT when data traffic flows in the uplink direction from a WTRU to the NT, or, at a WTRU when data traffic flows in the downlink direction from a NT to the WTRU. The OMMA Controller 3410 may inform the OMMA Scheduler 3420 about the receiver mode (e.g., Transparent or Non-Transparent) in which it operates. In transparent mode, the OMMA scheduler 3420 may receive packets from a RAT and pass the packets to the IP layer 3430, for example, without any additional processing (e.g., as shown in FIG. 34).

[0257] Though a single RAT may be used at any given time, the sender may switch

RATs (e.g., frequently). When a RAT switch happens, for example a switch from a high latency RAT to a low latency RAT, packets may be received out-of-order for a single IP stream. For example as shown in FIG. 34, RAT 3440 may be currently configured to send/receive IP packets from the OMMA layer, although RAT 3445 may be configured to send/receive IP packets from the OMMA layer at a later time. A Reordering Buffer 3450 may maintain the order of IP packets before sending them to the IP layer 3430. If IP packets are duplicated across both RATs 3440, 3445 when a RAT switch happens, a duplicate packet detection module 3460 may detect and remove the duplicate IP packet, for example, at the OMMA receiver.

[0258] In case of fragmentation at the OMMA sender, reassembly may be done on the selected RAT at the OMMA receiver, for example, as shown in FIG. 35 (e.g., which may be similar to that described with reference to FIG. 34). The reassembly decision may be taken based on a specific field in the OMMA header (e.g., added for enabling fragmentation at OMMA sender).

[0259] MAC resource reservation at the OMMA layer may be described herein. FIG. 36 is a diagram that illustrates an example call flow for allocating wireless resources for medium access by a NT and a WTRU using the RAT. The MAC on a RAT may allocate wireless resources (e.g., bandwidth and time duration) for medium access by the NT and WTRU utilizing the RAT. Since the OMMA layer may be part of a multi-RAT system with independent MACs (e.g., one MAC for each RAT), a MAC may be unaware of the resource allocation to the NT and WTRU by other MACs. For example, multi-RAT resource allocation may not be globally optimal. Since the OMMA layer may be the common entity which is aware of the link quality metrics on each RAT for a device and QoS class (e.g., every WTRU and every QoS class), a globally optimal resource allocation may be performed at the OMMA layer, and the optimal resource allocation may be signaled to the MAC on each RAT.

[0260] For example, the OMMA layer may determine a time duration and a bandwidth requirement for an IP flow. The OMMA layer may request resources on a first RAT and on a second RAT based on the time duration and the bandwidth requirement for the first IP packet and the second IP packet of the IP flow. The resources are characterized by the time duration and the bandwidth requirement. The OMMA layer may receive a quality of service (QoS) of the first IP packet and a QoS of the second IP packet. The resources on the first RAT and on the second RAT may be requested based on at least one of the feedback information relating to the first RAT, the feedback information relating to the second RAT, the QoS of the first IP packet, and the QoS of the second IP packet. The resources may be requested on the first RAT and on the second RAT using one or more of an A 1 interface and an A2 interface. Although described with reference to two IP packets and two RATs, MAC resource reservation may be performed by the OMMA layer for any number of IP packets of an IP flow and for any number of different RATs.

[0261] Inter-module interfaces may be described herein. As described herein, the

OMMA Controller may utilize one or more interfaces to communicate with one or more RATs, the Feedback Based Scheduler and the Policy Based Scheduler within the OMMA Scheduler, the Policy Database, and/or the RAT Capability Database.

[0262] FIG. 37 is a diagram illustrating examples of signals that may be communicated and used between the OMMA controller and the RAT capability database. For example, the OMMA Controller 3700 may communicate with the RAT Capability Database 3710, for example, using interface Al . Through this interface the OMMA controller 3700 may query or update the database with the RAT capability of an associated device (e.g., WTRU).

[0263] The interface between the OMMA Controller 3700 and the RAT Capability

Database 3710 may communicate a signal STA RAT Capability Update_Al that may be used at both the OMMA Sender and Receiver. Using this signal, the OMMA Controller 3700 (e.g., Multi-RAT Multi-Band Device Discovery or RAT Update Management module) may store the maximum RAT capability of a WTRU or NT (e.g., each WTRU) that it obtains after initial discovery and association phase into RAT Capability Database 3710. The OMMA controller 3700 may update the availability/unavailability of RATs that it triggers due to mobility of a WTRU or fluctuation in link quality due to other environmental effects. The OMMA controller 3700 may determine the availability or unavailability of a RAT from feedback metrics of the RATs, for example, through interface A3.

[0264] The signal STA RAT Capability Update_Al may be aperiodic. The signal STA

RAT Capability Update_Al may be used when a new WTRU is associated or when a change in the availability of a RAT occurs for an associated WTRU. The signal STA RAT Capability Update_Al may include a number of parameters, for example, an address STA_Addr of the WTRU, a list RAT_Id_List of RAT Id for the WTRU, and a parameter Reason _for_Update that comprises a value representing a reason for updating a RAT capability. For example, the Reason JOr Jpdate parameter may store the value 0 for a new WTRU association or the value 1 for a WTRU RAT availability change.

[0265] The signal STA RAT Capability Update_Al may include a parameter RAT_Info that comprises an array. If the parameter Reason JOrJJpdate stores a value of 0, the array may be an array of pairs (e.g., MTU, MaxJIATjOapability) comprising as many triplets as there are RAT Ids in the RATJd ist. The default setting of R^r_availability on the RAT performing association may be set to "1," while it may be set to "0" for other RATs (e.g., (MTU1,

Max_RATl jOapability), ...,(MTUn, MaxJlATnjCapabilityi)). If the parameter

Reason JorJJpdate stores a value of 1, the array may be an array of RAT _AvailabUity comprising many elements as there are RAT Ids in the RATJd ist (e.g., RA

Tl_Availability, ...,RATn_Availability). [0266] The interface between the OMMA Controller 3700 and the RAT Capability

Database 3710 may communicate a signal STA RAT Capability Query _A1 that may be used at the OMMA sender. It may be used by the OMMA Controller 3700 (e.g., OMMA Mode Management or Fragmentation Controller module) to request the RAT Capability database 3710 for specific information regarding WTRU capability, for example, maximum RAT capability, available RATs, MTU size, etc.

[0267] The signal STA RAT Capability Query _A1 may be aperiodic. The signal STA RAT

Capability Query _A1 may be used when the OMMA controller 3700 (e.g., OMMA Mode Management or Fragmentation Controller module) needs information regarding WTRU's RAT capability. It may include a parameter STA_Addr that comprises the address of the WTRU for which parameters are requested and/or a parameter RAT_Id_List that comprises a list of RAT Ids for which parameters are requested.

[0268] The interface between the OMMA Controller 3700 and the RAT Capability

Database 3710 may communicate a signal STA RAT Capability Response_Al that may be used at the OMMA sender. The RAT Capability database 3710 may respond to the signal

STA_RAT_Capability_Query_Al by the OMMA Controller 3700 (e.g., OMMA Mode

Management or Fragmentation Controller module) using this signal. The signal

STA_RAT_Capability_Query_Al may comprise specific information regarding WTRU capability, for example, maximum RAT capability, available RATs, MTU size, etc.

[0269] The signal STA RAT Capability Response_Al may be aperiodic. The signal STA

RAT Capability Response _A1 may be used in response to the STA_RAT_Capability_Query_Al signal. The signal may comprise a number of parameters, for example, the parameters described herein. These parameters may include, for example, an address STA_Addr of the WTRU for which parameters are requested, a list RAT_Id_List of RAT Ids for which parameters are requested, and an array RAT nfo of 3-tuples (e.g., MTU, Max _RAT_Cap ability,

RAT _Availabilityi) comprising as many 3-tuples as there are RAT Ids in the RAT_Id_List (e.g., (MTU1, Max_RATl_Capability, RATI _Availability), (MTUn, Max_RATn_Capability, RATn_Availability)).

[0270] FIG. 38 illustrates an example of the interface between the OMMA Controller and the Policy Database. The OMMA Controller 3800 may communicate with the Policy Database 3810 using interface A 10. Through the interface A 10, the OMMA controller 3800 may query to access the predefined policies in the Policy Database 3810 (e.g., those policies/rules described herein). The interface between the OMMA Controller 3800 and the Policy Database 3810 may communicate a signal Policy _Query_A 10 that may be used at the OMMA sender. The signal may be used by the OMMA Controller 3800 (e.g., MAC Resource Reservation or OMMA Mode Management module) to request the Policy database for specific information regarding policies specific to any WTRU or specific to any IP QoS traffic.

[0271] The signal Policy _Query_A 10 may be aperiodic. The signal Policy _Query_A 10 may be used when the OMMA controller 3800 (e.g., MAC Resource Reservation or OMMA Mode Management module) needs information regarding Policy information regarding a WTRU or IP QoS traffic. The signal Policy _Query_A 10 may include a number of parameters, for example, an address STA ADDR of the WTRU for which parameters are requested. A parameter IP QoS Type may store the QoS class of the IP packet for which parameters are requested. A parameter Mode Request may store a value that indicates whether the mode request is off or on. For example, the parameter Mode _Request may store a value of 0 if the mode request is off and a value of 1 if the mode request is on.

[0272] The interface between the OMMA Controller 3800 and the Policy Database 3810 may communicate a signal Policy _Response_A 10 that may be used at the OMMA sender. The Policy database 3810 may respond to the Policy _Query_A10 by OMMA Controller (e.g., MAC Resource Reservation or OMMA Mode Management module) using this signal. The signal Policy _Response_A10 may comprise information regarding policies to be applied when serving particular WTRUs and IP QoS traffic.

[0273] The signal Policy _Response_A10 may be aperiodic. The signal

Policy _Response_A10 be generated as a response to Policy _Query_A10. The signal may include a number of parameters, for example, an address STA ADDR of the WTRU for which parameters are requested. A parameter IP QoS Type may store the QoS class of the IP packet for which parameters are requested. A parameter Policy may store a policy that is defined in the policy database 3810 for a given IP QoS Type of a given STA_Addr. If there is no such policy, the parameter Policy may return a NULL value. A parameter Mode may return a mode defined in the policy database 3810 for a given IP QoS type for a given STA_Addr, for example, if the Mode Request is ON in Policy _Query_A10.

[0274] The OMMA Controller may communicate with the OMMA Scheduler, for example, using interfaces A5a, A5b, A9, Al l, and A12 (e.g., as shown in FIG. 39). FIG. 39 illustrates an example interface between an OMMA Controller and an OMMA Scheduler. The OMMA controller 3900 may communicate with the FBS module of the OMMA scheduler 3910 using interface A5a to signal feedback metrics. The OMMA controller 3900 may communicate with the FBS module of the OMMA scheduler 3910 using interface Al 1 to receive the RAT selection decision. The OMMA controller 3900 may communicate with the PBS module of the OMMA scheduler 3910 using interface A5b to signal the feedback metrics. The OMMA controller 3900 may communicate with the Packet Fragmentation module of the OMMA scheduler 3910 using interface A12 to signal the fragmentation enable/disable decision. Using interface A 12, the OMMA Scheduler 3910 may signal the OMMA controller 3900 regarding the mode (e.g., Transparent/Non-Transparent) in which it operates.

[0275] The interface between the OMMA Controller 3900 and the OMMA Scheduler

3910 may be utilized to communicate a signal RAT _Metrics _PBS_A5b that may be used at the OMMA sender. The OMMA Controller 3900 (e.g., Feedback WTRU and QoS Classifier module) may signal the feedback metrics of a RAT to the PBS module of the OMMA scheduler 3910. The signal RAT_Metrics_PBS_A5b may be aperiodic. The OMMA controller 3900 (e.g., Feedback WTRU and QoS Classifier module) may signal the feedback metrics based on a predefined period at which it gets feedback from the RATs.

[0276] The signal RAT_Metrics_PBS_A5b may include a number of parameters, for example, the parameters described herein. A parameter RAT_Id may comprise RAT IDs for which parameters apply. A parameter STA_Addr may comprise an address of the WTRU for which parameters apply. A parameter IP QoS Type may store QoS Classes for which parameters apply. Metrics may comprise a number of parameters for the RAT with the Id given in the RAT Id parameter. These parameters may include, but are not limited to the average packet delay Avg_Pkt_Delay, a Jitter parameter, and a packet loss rate Pkt_Loss_Rate. These parameters may be signalled as a matrix, for example, as shown in FIG. 40.

[0277] The interface between the OMMA Controller 3900 and the OMMA Scheduler

3910 may communicate a signal RAT_Metrics_FBS_A5a that is used at the OMMA sender. The OMMA Controller 3900 (e.g., Feedback WTRU and QoS Classifier module) may signal the feedback metrics of a RAT to the FBS module of the OMMA scheduler 3910. The signal RAT_Metrics_FBS_A5a may be aperiodic. The OMMA controller 3900 (e.g., Feedback WTRU and QoS Classifier module) may signal the feedback metrics based on a predefined period at which it gets feedback from the RATs.

[0278] The signal RAT Aetrics _FBS _A5a may include a number of parameters, for example, the parameters described herein. A parameter RAT_Id may comprise RAT IDs for which parameters apply. A parameter STA_Addr may comprise an address of the WTRU for which parameters apply. A parameter IP QoS Type may store QoS Classes for which parameters apply. Metrics may comprise one or more parameters for the RAT with the Id given in the RAT Id parameter. These parameters may include, but are not limited to, the arrival rate Arrival _Rate, a serving rate Serving _Rate, and an average packet delay Avg_Pkt_Delay. These parameters may be signalled as a matrix, for example, as shown in FIG. 41.

[0279] The interface between the OMMA Controller 3900 and the OMMA Scheduler

3910 may communicate a signal OMMA_Mode_Decision_A9 that is used at the OMMA sender and/or receiver. The OMMA Controller 3900 (e.g., OMMA Mode Management module) may signal the OMMA Scheduler 3910 about the mode in which it operates.

[0280] The signal OMMA_Mode_Decision_A9 may be aperiodic. The signal

OMMA_Mode_Decision_A9 may be used when a mode change is signaled by a NT for a WTRU. The signal OMMA_Mode_Decision_A9 may include a number of parameters, for example, the parameters described herein. A parameter STA_Addr may comprise an address of the WTRU for which parameters apply. A parameter IP QoS Type may store QoS Classes for which parameters apply. A parameter OMMA processing _Mode may have a value of 0 if the OMMA processing mode is transparent and a value of 1 if the OMMA processing mode is non- transparent. A parameter OMMA_Scheduling_Scheme may have a value of 0 if the scheduling scheme is policy -based and a value of 1 if the scheduling scheme is feedback-based. A parameter OMMA_Pkt_Dst_Mode may have a value of 0 in a diversity mode, a value of 1 in a multiplexing mode, and/or a value of 2 in a dynamic RAT selection mode. The OMMA

Controller 3900 may send the mode decision for a WTRU, for example, as shown in FIG. 42.

[0281 ] The interface between the OMMA Controller 3900 and the OMMA Scheduler

3910 may communicate a signal Frag_Decision_Request_Al 1 that is used at the OMMA sender. The FBS module of the OMMA Scheduler 3910 (e.g., where FBS is enabled, or both FBS and PBS are enabled) or the PBS module of the OMMA Scheduler 3910 (e.g., where PBS is enabled) may inform the OMMA Controller 3900 (e.g., Fragmentation Controller module) about the RATs selection, for example, when it takes a RATs selection decision for an IP packet.

[0282] The signal Frag_Decision_Request_Al 1 may be aperiodic. The signal

Frag_Decision_Request_Al 1 may be used when the FBS or PBS takes a decision on a RATs selection for routing an IP packet. The signal may include a number of parameters, for example, the parameters described herein. A parameter STA_Addr may comprise an address of the WTRU for which parameters apply. A parameter RAT_Id_List may comprise a list of RAT IDs selected for each WTRU.

[0283] The interface between the OMMA Controller 3900 and the OMMA Scheduler

3910 may communicate a signal Fragmentation _Decision_A 12 that is used at the OMMA sender. The signal may be the response of Frag_Decision_Request_Al 1 for corresponding IP packet. The OMMA Controller 3900 (e.g., Fragmentation Controller module) may notify the Packet Fragment module of the OMMA Scheduler 3910 to enable or disable the fragmentation for that packet on the selected RAT.

[0284] The signal Fragmentation _Decision _A12 may be aperiodic. The signal

Fragmentation _Decision_A12 may be used in response to Frag_Decision_Request__Al 1. The signal may include a number of parameters, for example, the parameters described herein. A parameter STA_Addr may comprise an address of the WTRU for which parameters apply. A parameter RAT_Id_List may comprise a list of RAT IDs for which a fragmentation decision is to be made. A parameter Frag_Decision_List may be an array (e.g., RATI _Frag, RATn_Frag), for example, where RATj_Frag may take one of two values for the RATs given in RATJd _List a 0 if fragmentation is off, and a 1 if fragmentation is on.

[0285] The interface between the OMMA layer and the RAT protocol stack may be described herein. FIG. 43 illustrates an example interface between an OMMA Controller and a RAT protocol stack. The OMMA Controller 4300 may communicate with the RAT Protocol Stack 4310 using interfaces A2 and A3. Using the interfaces A2 and/or A3, the OMMA layer may receive feedback metrics and RAT capability information from a RAT Protocol Stack 4310. Using the interfaces A2 and/or A3, the OMMA layer may reserve MAC resources on one or more RATs, for example, based on the requirements.

[0286] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal MAC Resource Reservation _A3 that may be used at the OMMA sender. The OMMA Controller 4300 (e.g., Mac Resource Reservation module) may request to reserve resources (e.g., x bandwidth for a fixed time duration "t") on one or more RATs.

[0287] The signal MAC Resource Reservation _A3 may be aperiodic. The signal MAC

Resource Reservation _A3 may be used when the OMMA Controller needs to reserve resources on one or more RATs. The signal MAC Resource Reservation _A3 may include a number of parameters, for example, RATJd, STA_Addr, IP QoS Type, and Resource. A parameter RATJd may identify the RAT on which a request may be sent. A parameter STA_Addr may comprise an address of the station for which the request was made. A parameter IP QoS Type may store a QoS Class for which the request was made. A parameter Resource may indicate resources that are to be reserved, for example, bandwidth and time.

[0288] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal System J³arameters_A3 that may be used at OMMA sender. The OMMA Controller 4300 (e.g., Multi-RAT Multi-Band Device Discovery) may inform a RAT (e.g., each RAT) about its RAT capability. This information may be used during discovery process to advertise WTRU RAT capability. [0289] The signal System_Parameters_A3 may be aperiodic. The signal

System parameters _A3 may be used when the WTRU boots up and/or for changes in the RAT capability. The signal Sy stem parameters _A3 may include a RAT_Id_List parameter that may be an array of RAT ^Capability (e.g., RATI _Capability, ...,RATn_CapabiUty).

[0290] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal RAT '^Capabilities _A3 that may be used at the OMMA sender and/or the OMMA receiver. A RAT may inform/update the OMMA Controller 4300 (e.g.,

Multi-RAT Multi-Band Device Discovery or RAT Update Management module) about RAT capabilities of associated WTRU/NT in case of, for example, a newly associated WTRU/NT.

The RAT may inform the Multi-RAT Multi-Band Device Discovery module of the OMMA controller 4300. On the WTRU side, after listening to a beacon on the RAT for an already associated WTRU-NT pair, the RAT may inform the RAT Update Management module of the

OMMA controller 4300. On the NT side, after receiving a STA_RAT_Availability message, the

RAT may inform the RAT Update Management modul eof the OMMA controller 4300.

[0291] The signal RAT ^Capabilities _A3 may be aperiodic. The signal

RAT _Cap abilities _A3 may be used when one or more of the events described herein occur. The signal RAT Cap abilities _A3 may comprise one or more parameters, for example, an address

STA_Addr of the WTRU and a parameter RAT_Id_List that may store an array of

RAT ^Capability (e.g., RATI ^Capability, ...,RATn_Capabilityi).

[0292] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal Mode Jo JController _A3 that may be used at the OMMA Receiver. The RAT may signal the OMMA Controller 4300 (e.g., OMMA Mode Management module) regarding the mode, for example, which it has received in a beacon from a NT.

[0293] The signal Mode Jo JController _A3 may be aperiodic. The signal

Mode Jo jController _A3 may be used when a RAT receives a new mode in a beacon. The signal Mode Jo JController _A3 may comprise one or more parameters (e.g., IP QoS Type,

OMMA processing JMode, OMMA_Scheduling_Scheme, and OMMA_PhjDst_Mode). A parameter IP QoS Type may store QoS Classes for which parameters may apply. A parameter OMMA processing Mode may have a value of 0 if the OMMA processing mode is transparent and a value of 1 if the OMMA processing mode is non-transparent. A parameter

OMMA_Scheduling_Scheme may have a value of 0 if the scheduling scheme is policy -based and a value of 1 if the scheduling scheme is feedback-based. A parameter OMMApktpst JMode may have a value of 0 in a diversity mode, a value of 1 in a multiplexing mode, and/or a value of 2 in a dynamic RAT selection mode. [0294] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal Mode_to_RAT_A3 that may be used at the OMMA sender. The OMMA Controller 4300 (e.g., OMMA Mode Management module) may signal a selected RAT about the mode, for example, which it may transfer in its beacon.

[0295] The signal Mode_to_RAT_A3 may be aperiodic. The signal Mode_to_RAT_A3 may be used when a new mode decision is made at the OMMA Controller 4300, for example, at a NT. The signal Mode_to_RAT_A3 may comprise one or more parameters, for example, STA_Addr, IP QoS Type, OMMA processing _Mode, OMMA_Scheduling_Scheme, and OMMA_Pkt_Dst_Mode. An address STA_Addr may be the WTRU for which parameters may apply. A parameter IP QoS Type may store QoS Classes for which parameters may apply. A parameter OMMA Processing Mode may have a value of 0 if the OMMA processing mode is transparent and a value of 1 if the OMMA processing mode is non-transparent. A parameter OMMA_Scheduling_Scheme may have a value of 0 if the scheduling scheme is policy -based and a value of 1 if the scheduling scheme is feedback-based. A parameter OMMA_Pkt_Dst_Mode may have a value of 0 in a diversity mode, a value of 1 in a multiplexing mode, and/or a value of 2 in a dynamic RAT selection mode.

[0296] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal Max_RAT_Capabilities_A3 that may be used at the OMMA receiver. When a device (e.g., WTRU) receives a maximum RAT capability advertisement of another device (e.g., a NT) through a beacon request and/or a probe response on its RAT Protocol Stack, the device (e.g., WTRU) may send information relating to the maximum RAT capability of the other device (e.g. NT) to the OMMA Controller 4300 (e.g., Multi-RAT Multi- Band Device Discovery module), for example, to calculate the match with its own RAT that is used to complete initial discovery and association procedure.

[0297] The signal Max_RAT_Capabilities_A3 may be aperiodic. The signal

Max_RAT_Capabilities_A3 may be used when a RAT Protocol Stack receives a beacon request and/or a probe response. The signal Max_RAT_Capabilities_A3 may comprise one or more parameters, for example, an address STA_Addr of the WTRU and a parameter RAT_Id_List that may comprise an array of RAT '^Capability (e.g., RATI ^Capability, ...,RATn_Capability).

[0298] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal Match _RAT_List_A3 that may be used at the OMMA Receiver. The OMMA Controller 4300 (e.g., Multi-RAT Multi-Band Device Discovery module) may calculate the matched RATs for response to Max_RAT_Capabilities_A3. This information may be used to complete the initial discovery and association procedure. [0299] The signal Match _RAT_List_A3 may be aperiodic. The signal

Match _RAT_List_A3 may be generated as a response to the signal Max_RAT_Capabilities_A3. The signal Match _RAT_List_A3 may comprise one or more parameters, for example, an address STA_Addr of the WTRU and a parameter RAT_Id_List that may comprise an array of matched RAJ ^Capability (e.g., RATI jnatched, ...,RATn jnatched).

[0300] The interface between the OMMA Controller 4300 and the RAT Protocol Stack

4310 may communicate a signal Feedback Metrics _A2 that may be used at the OMMA sender. A RAT may send feedback metrics to the OMMA Controller 4300 (e.g., Feedback WTRU Classifier module). The signal Feedback Metrics _A2 may be periodic, as this operation may be performed at predefined periodic intervals.

[0301] FIG. 44 is a diagram illustrating example feedback metrics that may be sent by a

RAT (e.g., each RAT). The signal Feedback _Metrics_A2 may comprise one or more parameters, for example, an identifier RAT ID that may identify the RAT that is sending feedback and an address STA_Addr for the WTRU for which parameters are sent. A parameter IP QoS Type may store QoS Classes for which parameters are sent. A metrics list Metrics _List may comprise one or more parameters, for example, a serving rate Serving _Rate, a Jitter parameter, an average packet delay Avg_Pkt_Delay, and a packet loss rate Pkt_Loss_Rate.

[0302] OMMA scheduler interfaces may be described herein. The OMMA Scheduler may communicate with the OMMA Controller, the Policy Database, and/or the RAT Capability Database. Interfaces with the OMMA Controller (e.g., A5a, A5b, A9, Al 1 and A12) are described herein.

[0303] FIG. 45 is a functional block diagram depicting an example interface between an

OMMA Scheduler and a RAT Capability Database. The OMMA Scheduler 4500 may communicate with the RAT Capability Database 4510 using interface A4. Through this interface, the OMMA scheduler 4500 may query the RAT capability database 4510 for RAT availability of a device (e.g., an associated WTRU). The PBS and/or FBS modules of the OMMA scheduler 4500 may communicate with the RAT Capability Database 4510 through the A4 interface.

[0304] The A4 interface between the OMMA Scheduler 4500 and the RAT Capability

Database 4510 may communicate a signal STA RAT Capability Query _A4 that may be used at the OMMA Sender and/or the OMMA Receiver. The signal STA RAT Capability Query _A4 may be used by the OMMA Scheduler 4510 (e.g., PBS, FBS, or RAT Update Sender modules) to request the RAT Capability database 4510 for availability of RATs. [0305] The signal STA RAT Capability Query _A4 may have aperiodic and/or periodic characteristics. For example, the PBS and/or FBS modules of the OMMA scheduler 4500 may transmit this query based on need. The RAT Update Sender module of the OMMA scheduler 4500 may transmit the query (e.g., periodically^. The signal STA RAT Capability Query _A4 may comprise one or more parameters, for example, an address STA_Addr of the WTRU for which parameters are requested and a list RAT_Id_List of RAT Ids for which parameters are requested.

[0306] The interface between the OMMA Scheduler 4500 and the RAT Capability

Database 4510 may communicate a signal STA RAT Capability Response_A4 that may be used at the OMMA Sender and/or the OMMA Receiver. The RAT Capability database 4510 may respond to the STA_RAT_Capability_Query_A4 by the OMMA Scheduler 4500 (e.g., PBS, FBS, and RAT Update Sender modules) using this signal. The STA_RAT_Capability_Query_A4 signal may comprise information of available RATs for a requested device (e.g., WTRU).

[0307] The signal STA RAT Capability Response_A4 may be aperiodic. The signal STA

RAT Capability Response_A4 may be generated in response to the signal

ST A _RAT _Cap ability JQuery _A4. The signal STA RAT Capability Response_A4 may comprise one or more parameters, for example, an address STA_Addr of the WTRU for which parameters are requested and a list RAT_Id_List of RAT Ids for which parameters are requested. The signal STA RAT Capability Response_A4 may comprise an array RATJnfo of RAT_Availability comprising one or more elements (e.g., corresponding to RAT Ids in the RAT_Id_List

({RATI _Availability >}, ..., { RATn_Availability})).

[0308] FIG. 46 is a functional block diagram depicting an example interface between an

OMMA Scheduler and a Policy Database. The OMMA Scheduler 4600 may communicate with the policy database 4610 using interface A6. Through interface A6, the PBS of the OMMA scheduler 4600 may query to access the predefined policies/rules (e.g., the policies/rules described herein) in the Policy Database 4610.

[0309] The interface between the OMMA Scheduler 4600 and the Policy Database 4610 may communicate a signal Policy _Query_A6 that may be used at the OMMA sender. The signal Policy _Query_A6 may be used by the OMMA Scheduler 4600 (e.g., PBS module) to request the Policy database 4610 for specific information regarding policies specific to a device (e.g., WTRU) or to IP QoS traffic.

[0310] The signal Policy _Query_A6 may be aperiodic. The signal Policy _Query_A6 may be generated when the OMMA Scheduler (e.g., PBS) needs policy information regarding a device (e.g., WTRU) or IP QoS traffic. The signal Policy JQuery _A6 may comprise one or more parameters, for example, an address STA_Addr of the WTRU for which parameters are requested and a parameter IP QoS Type that may store QoS Classes of IP packets for which parameters are requested.

[0311 ] The interface between the OMMA Scheduler 4600 and the policy database 4610 may communicate a signal Policy _Response_A6 that may be used at the OMMA sender. The policy database 4610 may respond to the Policy _Query_A6 by the OMMA Scheduler (e.g., PBS) using this signal. This signal may comprise specific information regarding policies to be applied when serving a device (e.g., WTRU) and IP QoS traffic.

[0312] The signal Policy _Response_A6 may be aperiodic. The signal

Policy _Response_A6 may be generated in response to the signal Policy _Query_A6. The signal Policy _Response_A6 may comprise one or more parameters, for example, an address STA_Addr of the WTRU for which parameters are requested and a parameter IP QoS Type that may store QoS Classes of IP packets for which parameters are requested. A parameter Policy may return information for a policy that is defined in the Policy Database 4610 for a given IP QoS Type of a given STA_Addr. If no such policy is defined, the parameter Policy may return a null value.

[0313] Within the OMMA Scheduler, modules may communicate with each other. FIG.

47 is a functional block diagram illustrating an example interface between a PBS module and an FBS module of an OMMA scheduler. The PBS 4700 may communicate with the FBS 4710 through interface A7. The PBS 4700 may transmit a RAT selection decision for an incoming IP packet.

[0314] The interface between the PBS 4700 and FBS 4710 modules may communicate a signal RAT_Selection_Decision_A7 that may be used at the OMMA sender. For an incoming IP packet, the signal RAT _Selection_Decision_A7 may be used by the PBS module 4700 to inform the FBS module 4710 about the RAT selection decision (e.g., RAT Id in case of Single RAT selection and RAT priority list in case of multiple RAT selection scenario) based on one or more policies (e.g., the policies/rules described herein).

[0315] The signal RAT_Selection_Decision_A7 may be aperiodic. The signal

RAT_Selection_Decision_A7 may be generated when the PBS module 4700 receives a decision of RAT selection for an new incoming IP packet. The signal RAT_Selection_Decision_A7 may comprise one or more parameters, for example, a parameter IP QoS Type that may store the QoS class of the IP packet for which a decision has been made. A parameter RAT_Selection_List may comprise the list of RATs in decreasing priority, e.g., [RAT_2, RAT_4, RAT_1 ]. In the case of a single RAT selection scenario, this parameter may be a single RAT, e.g., [RAT_3]. [0316] FIG. 48 is a functional block diagram depicting an example interface between an

IP Packet QoS Identifier module and a PBS or FBS module within an OMMA Scheduler. The IP Packet QoS Identifier module 4800 may inform the PBS or FBS module 4810 about the QoS class type (e.g., access category) of incoming IP packets, for example, through interface A 14, for example, using a signal QoS_Class_A14. The signal QoS_Class_A14 may be used at the OMMA sender. For an incoming IP packet, the signal QoS_Class_A14 may be used by the IP Packet QoS Identifier module 4800 to inform the PBS or FBS module 4810 about the QoS Class type (e.g., access category) of the incoming IP packet.

[0317] The signal QoS_Class_A14 may be aperiodic. The signal QoS_Class_A14 may be generated when the IP Packet QoS Identifier 4800 has a new incoming IP packet. The signal QoS_Class_A14 may comprise one or more parameters, for example, an address STA_Addr of the WTRU for which the packet is incoming. A parameter IP QoS Type may store the QoS class (e.g., access category) of the IP packet.

[0318] The Policy Database may interface with a DNS-APP entity. FIG. 49 is a functional block diagram illustrating an example implementation of an Ax interface between a Policy Database and a DNS-APP entity. The policy database 4910 may comprise one or more policies (e.g., the policies/rules described herein) specific to certain domain names. A DNS-APP entity 4900 may reside just above the IP layer. A purpose of the DNS-APP entity 4900 may be to query (e.g., periodically query) the policy database 4910 for domain names and resolve them into IP addresses. An interface Ax may be defined and used for this purpose.

[0319] There may be a conflict situation that occurs when a particular policy

corresponding to a domain name is in use by the PBS module at the same time as the DNS-APP entity 4900 is accessing the policy database 4910 and changing the IP address corresponding to the policy in use. To avoid such a conflict scenario, a token for each domain name may be defined in the policy database. When the policy corresponding to a particular domain name is in use, the PBS module may set the token to "1" so that the DNS-APP entity 4900 may read the token and know that the policy is in use. If the token is set to "0," the policy may not be in use, and the DNS-APP entity 4900 can resolve the domain name to an IP address.

[0320] The policies within the Policy Database may be changed (e.g., dynamically) based on user preference, for example, the RATs to be used for specific applications, etc. FIG. 50 is a functional block diagram illustrating an example implementation of an Ay interface between the Policy Database and a user interface application (UI-APP) entity. The Policy Database 5010 may interface with a user interface application (UI-APP) entity 5000 using an interface Ay. For example, a user of a device (e.g., a WTRU) may set specific policies within the policy database. [0321 ] If a user decides to add a new policy, the UI-APP entity 5000 may send a set _policy signal to the Policy Database 5010. The Policy Database 5010 may add a new entry in the database based on the (e.g., type, criteria, and action) 3-tuple sent in the set _policy signal.

[0322] If a user decides to modify an existing policy, the UI-APP entity 5000 may send a modify _policy signal to the Policy Database 5010. The Policy Database 5010 may modify an existing entry in the database based on the (e.g., type, criteria, and action) 3-tuple sent in the modify _policy signal.

[0323] FIG. 51 is a diagram illustrating an example of Multi-RAT Aggregation using

OMMA Layer. As described herein, the OMMA layer 5100 may receive meta-data and/or link statistics feedback from one or more RATs 51 10. A scheduler within the OMMA layer may be responsible for traffic shaping across the RATs 5110. At the sender side, traffic coming from the IP layer 5120 may be distributed across one or more RATs 5110 by the OMMA layer 5100, for example, based on the feedback associated with the RATs 51 10, for example as illustrated in Figure 51. At the receiver side, traffic received from different RATs 5110 may be aggregated to be sent up to the IP layer 5120. This may be referred to as a multi RAT aggregation system.

[0324] The OMMA layer architecture may manage control plane and/or data plane processing capability. The OMMA layer 5100 may enable periodic RAT availability evaluation at terminals, and may store the information and use it for RAT selection. Fragmentation and reassembly in a multi-RAT system with unequal maximum transmission unit (MTU) sizes may be enabled by the OMMA layer 5100. The OMMA layer 5100 may be used to enable MAC resource reservation to achieve resource allocation across one or more RATs.

[0325] The OMMA layer 5100 may comprise one or more mechanisms to allocate IP packets over multiple RATs 51 10 in multi-RAT systems, for example, to enable dynamic and opportunistic RAT selection and packet level aggregation. Traffic shaping by the OMMA layer 5100 may distribute IP packets across multiple RATs 51 10. Implementations may be disclosed with reference to a single WTRU, single NT and single IP flow, and multiple UTs and multiple IP flows.

[0326] Packet scheduling of IP traffic over multiple RATs 51 10 may be performed by the

OMMA layer 5100. For example, a wireless system may include one or more network terminals (NTs) (e.g., access points (APs), a Wi-Fi access point (AP), eNodeB, etc.) and one or more WTRUs (e.g., a user terminal (UT), a Wi-Fi station, a STA, etc.). A NT and a WTRU may have the capability of supporting multiple RATs (e.g., "K" RATs) where the RATs may operate on different spectral bands. The bands may be orthogonal. The signals on the one or more different bands may not interfere with each other. Transmitting terminals may operate in a OMMA multiplexing mode. At the NT, a stream of packets may be generated with an average packet arrival rate of x (e.g., packets/unit time). The main stream may be split into K sub-streams. The sub-streams may be assigned to a corresponding transmit buffer associated with a RAT. The incoming traffic may be split across the K streams, for example, so as to minimize average end- to-end packet latency and/or out-of-order packet reception latency, which may maximize throughput.

[0327] Examples of single WTRU single IP flow cases may be described herein. When a single WTRU, a single NT, and single IP flow from a NT to WTRU is considered, the OMMA layer 5100 may determine how to distribute packets corresponding to the IP flow across RATs 5100, e.g., such that the average end-to-end delay per packet may be minimized. Placing one or more packets in the transmit buffer associated with the RAT with the lowest latency may increase the average packet queuing delay. Dispersing the one or more packets across RATs 5100 randomly may decrease the average packet queuing delay and serving delay, however it may result in out-of-order reception of packets at the receiver due to differences in link latencies. This may cause longer queuing delays at the receiver to rearrange packets before sending them up to the IP layer 5120. The OMMA 5100 layer may comprise a packet assignment strategy that minimizes average end-to-end packet latency and/or out-of-order packet reception delay and maximizes throughput.

[0328] Examples of multi-WTRU multi-IP flow cases may be described herein. A system may comprise multiple WTRUs, a single NT, and multiple IP flows from the NT to one or more of the WTRUs. Although sender IP packets may be forwarded to the sender MAC layer as a single stream by the OMMA layer 5100, the MAC layer may sort them according to their corresponding access categories and/or WTRU addresses. The main IP stream for each WTRU may be split into multiple QoS streams that may be queued in separate buffers in the sender MAC layer. A buffer may correspond to an access category that may have a certain priority. This set up may complicate the traffic shaping because, for example, for each RAT 51 10, the average packet delay may depend on the queuing delay and the latency of other packets in the same buffer. The average packet delay may also depend on the channel access by packets of the other buffers, which may be random. The channel access scheme that may be used to schedule medium access between different AC buffers may tie the waiting times for the packets in the buffers. The OMMA layer 5100 may comprise one or more modified packet assignment strategies (for example, as compared to the single WTRU, single IP flow case) that minimize average end-to-end packet latency. [0329] The OMMA layer 5100 may comprise packet assignment implementations that may distribute IP packets across multiple RATs 51 10, e.g., to minimize average end-to-end latency per packet and/or maximize throughput for the case of a single NT, single WTRU, and single IP flow from NT to WTRU in the system.

[0330] The OMMA layer 5100 may comprise packet assignment implementations that may distribute IP packets across multiple RATs 51 10, e.g., to minimize average end-to-end latency per packet and/or maximize throughput for the case of multiple UTs, single NT and multiple IP flows from NT to each WTRU in the system.

[0331] The OMMA layer 5100 may comprise a leaky-bucket based smart packet assignment that may distribute IP schedule packets across multiple RATs 51 10, e.g., to minimize average end-to-end latency per packet and/or average out-of-order packet latency, and maximize throughput.

[0332] Criteria for the OMMA layer 5100 to adaptively select RATs for the

communication based on, for example, link quality feedback metrics from the RAT may be described herein.

[0333] Enhancements to the OMMA layer architecture and signalling procedures to enable traffic management for the case of multiple UTs, single NT and multiple IP flows from NT to each WTRU in the system may be described herein.

[0334] Traffic shaping implementations at the OMMA layer 5100 to improve the system performance with TCP traffic may be described herein.

[0335] The OMMA layer 5100 may utilized feedback metrics, for example, such as but not limited to, average serving rate, average serving latency, second moment of average serving latency, average vacation time, second moment of average vacation time, etc., that may be transmitted from a RAT protocol stack to an OMMA layer 5100 to enable packet assignment over multiple RATs 5110.

[0336] Criteria for the OMMA layer 5100 to adaptively select RATs 5110 for the communication based on link quality feedback metrics associated with the RAT may be described herein.

[0337] Leaky bucket based packet scheduling at an OMMA layer 5100, e.g., to minimize average end-to-end latency per packet and/or average out-of-order packet latency, and maximize throughput may be described herein.

[0338] In the case of a multi-RAT network terminal, an OMMA layer 5100 may reside as a layer between RAT protocol stacks and the IP layer 5120. In this case, the feedback metrics disclosed herein may be a service access point (SAP) between a RAT and the OMMA layer 5100.

[0339] The OMMA layer 5100 (e.g. , entirely or partially) may reside as a logical entity on another device external to the multi-RAT network terminal (e.g. , a common gateway (GW)), which may have a wired network interface. For example, multiple single RAT network terminals may be distributed across a geographic area (e.g. , like a large enterprise) and the OMMA layer 5100 may reside on the common gateway (GW), which may have a wired network interface to the IP backhaul. The OMMA layer 5100 may reside in the GW. For example, one or more functions of the OMMA layer 5100 may reside in the gateway, while the rest may be within the network terminals. If the physical interface is wireless, one or more of the feedback metrics carried over the wireless interface between GW and network terminals may be standardizable and/or detectable.

[0340] Packet assignment for single WTRU single IP flow may be described herein. For example, there may be a single NT and a single WTRU in a system. A QoS class of IP packets may be served. For example, K may be the number of available RATs supported by the NT and/or WTRU. One or more K RATs may operate on different spectral bands. The bands may be orthogonal. Signals on the different bands may not interfere with one another.

[0341] At the NT, a stream of packets may be generated in a Poisson fashion with an average packet arrival rate x (packets/unit time). The main stream may be split into K sub- streams. The sub-streams may be assigned to a corresponding transmit buffer in each RAT. For example, the 1^th sub-stream, i = { 1,...,K} may be Poisson with an average arrival rate xi (packets/unit time) where:

[0342] The multi-RAT system in a terminal device may be modeled as K parallel M/M/l queues, e.g. , to account for that there may be K servers. One or more of the servers may have a different serving rate. Packets may be transmitted over channel i in a first-come first-served (FCFS) basis and may be sent successfully at serving rate R; (packets/unit time). The constraint listed below may be imposed (e.g. , to assure system stability):

K i=l

[0343] Rate R; may reflect the quality of channel i and may be fed back from a RAT

(e.g. , each RAT) to the transmitting OMMA layer, for example, to update its traffic shaping strategy. At the receiver, the sub-streams may be combined in the receiving OMMA layer. An OMMA layer at the sender may identify and/or maintain the average rates x; based on the feedback metric ¾. This may minimize average end-to-end latency per packet and/or maximum throughput.

[0344] The x (e.g., which may be an optimal x- ) may be expressed as:

* _

where R; may be the average serving rate of a RAT; feedback to the OMMA layer.

[0345] Feedback metrics for single WTRU single IP flow cases may be described herein.

Ri may be the effective rate of packets being transmitted through RAT; of the transmitter and/or received successfully at the receiver. For example, this rate may be captured at the transmitter's

RATs by observing ACKs indicating successful packet delivery. Ri may be calculated as - , where T may be the average serving latency per packet at the RAT. T may be defined as the time duration from to to ti. to may be the moment when MAC starts to perform channel contention process (e.g., CSMA/CA) for that packet, ti may be the moment when ACK for that whole packet is received at the MAC layer of the sender node.

[0346] T may be counted as the total time duration that a MAC layer associated with a

RAT "serves" that packet to send it out. T may include a retransmission delay if a packet needs to be retransmitted. A MAC queuing delay may not be included in T

[0347] Criterion for RAT selection vs. aggregation may be described herein. Comparing the value of expression with 0 may give a threshold, which may be used as a switching criterion between a selection mode and multiplexing mode. For example, FIG. 52 is a diagram illustrating an example of a threshold for mode selection in two RAT systems. A threshold for the OMMA layer to decide an operating mode for two-RAT systems may be described herein.

[0348] The OMMA layer may rely on the value of total arrival rate x and the value of ?₁H2 ^— Ri (^e-g-_> assuming Ri > R₂), for example, to adaptively decide the operation mode. For example, when 0 < x < J ?₁i?₂ ^— ^2> ^me OMMA layer may switch to single RAT selection mode (e.g., data transmitting may be limited on RAT 1). For example, when J ?₁i?₂— ff₂ ^{< x <} R₁ + R₂, the OMMA layer may switch to a multiplexing mode (e.g., data may be sent on both RATs). The data allocation with a single WTRU may be deployed on downlink with a single WTRU, for example, it may be deployed on the uplink where data may be scheduled on different RATs at a WTRU to send to a NT.

[0349] Packet assignment for multi-WTRU multi-IP flow (QoS) may be described herein. For example, a NT may communicate substantially simultaneously with multiple UTs (e.g., as illustrated in FIG. 53). Multiple IP flows belonging to different QoS classes may be served by the NT -WTRU links (e.g., each NT -WTRU link), where each IP flow may have different packet delay and/or throughput requirements.

[0350] Referring back to FIG. 3, a diagram illustrating an example of a single network terminal and multi user terminals is provided. The OMMA layer (e.g., the OMMA layer 303 at the NT 301 and/or the OMMA layer 310 at a WTRU 315) may determine the traffic distribution across RATs for one or more IP flows and/or for one or more NT- WTRU links. The traffic distribution may be optimized. The data allocation based on this traffic ratio may minimize the average packet latency and/or may maximize total throughput. At the NT 301, one or more RAT's meta-data and/or link quality metrics may be measured for each AC and/or each WTRU 310. The meta-data and/or link quality metrics may be fed back to the OMMA layer 303.

[0351] Although sender IP packets may be forwarded to the sender MAC layer as a single stream, the MAC layer may sort them according to their corresponding access categories and/or WTRU addresses. The main IP stream for each WTRU 310 may be split into one or more QoS streams that may be queued in separate buffers in the sender MAC layer. Each buffer may correspond to an access category that has a certain priority. This may complicate the traffic shaping because the average packet delay may depend on the queuing delay, the latency on each RAT, and/or the channel access by packets of the other buffers, which may be random. The channel access scheme that may be used to schedule medium access between different AC buffers may tie the waiting times for the packets in the buffers.

[0352] Qi_k may denote the transmission buffer to store data destined for WTRU "i" for IP flow "k" (e.g., or access category k). Because of the nature of the queuing and contention process in multi QoS supported system (e.g., EDCA mode), each queue Qi_k may be modeled as a M/G/l queue with vacations. A vacation may refer to a time when the server may go on "vacations" for some random period of time, for example, at the end of each serving period for queue Qi_k. The vacation time with queue Qi_k may be the duration NT serves other WTRUs (e.g., not the WTRU i) and/or NT sends data of other IP flows or access categories (e.g., does not serve the IP flow k or access category k). The OMMA layer 300 may utilize the queuing implementations, for example, to effectively allocate data for each IP flow toward each WTRU 310, for example, independently.

[0353] Examples of feedback metrics for multi WTRU multi IP flow (QoS) cases may be described herein. Table 6 illustrates examples of feedback metrics to support multi-WTRU multi QoS configurations. The subscripts i and k may have been omitted in the terminologies below. A term below may correspond to one IP flow k or access category k from a NT to a WTRU i. Table 6: Feedback Metrics

[0354] The average system delay across K RATs that may be minimized may be:

x

[0355] The arrival rate packets for RAT j may be:

Where

[0356] For example, up to 2M different combinations of the sign ± in the above equations may be used. The OMMA transmitter may use the feedback metrics from a RAT (e.g., as in Table 6) to determine the instantaneous ratio of distribution of packets across the RATs based on, for example, the formulation above.

[0357] OMMA layer based smart packet scheduling may be described herein. FIG. 53 is a diagram illustrating an example of a packet reordering scenario. FIG. 54 is a diagram illustrating another example of a packet reordering scenario. For example, reordering delay D_n for each packet n may be defined as the time packet n waits at the OMMA layer of the receiver node for the earlier packets coming to the receiver (e.g., packets with the order smaller than n coming successfully to the OMMA layer of the receiver node). This may occur when data packets are received out of order. Packets may be received out of order when they traverse each link with different packet latency. At the transmitter side, packets of the main stream may be split into multiple sub streams for transmission over different links, which may have different latencies. As the OMMA layer at the receiver receives packets one after the other, it may send the packets to the IP layer in an order. Some packets may be held at the OMMA layer for reordering purpose, which may incur a reordering delay.

[0358] In an example, a packet of index n G { Ι,. , ., Ν} may be transmitted over RAT j, according to a probability— , where∑Jii— = 1 . This packet may experience a certain delay.

Upon reception, the packet may be given an index n + ε, where ε G {-N+l,..., N-2, N-l } may be the ordering offset. A packet may be referred to as being received in the correct order if ε =0. Otherwise, a packet may be referred to as offset. A reordering delay may occur when packets with lower indices are received late and/or when packets with higher indices are received early. This may happen in one or more circumstances. For example, a reordering delay may occur if a packet n is transmitted over the link with higher latency whereas δ subsequent packets are transmitted over the lower latency link, for example as illustrated in FIG. 53. A reordering delay may occur if a packet n is transmitted over the link with lower latency whereas δ preceding packets are transmitted over the higher latency link, for example as illustrated in FIG. 54.

[0359] If packet n is scheduled to be transmitted over a faster link than the packets after packet n and before packet n- δ in the transmitter's main queue, a reordering issue may not occur, for example, regardless of their RAT assignment. If packet n is scheduled to be transmitted over a slower link than the packets before packet n and after packet n+ δ in the transmitter's main queue, a reordering issue may not occur, for example, regardless of their RAT assignment (e.g., as shown in FIG. Error! Reference source not found.53 and FIG. 54).

[0360] FIG. 55a is a diagram illustrating an example of a random assignment of packets.

FIG. 55b is a diagram illustrating an example of a smart assignment of packets across RATs. For example as shown in FIG. 55a, if seven IP packets are transmitted and IP packets with IDs #1, #2, #3 and #5 are received (e.g., at a given time), then the OMMA layer may send packets #1, #2 and #3 to the IP layer and may wait for packet #4 to arrive before sending packets #5. This may cause a reordering delay for packet #5. The other four IP packets may not suffer this delay.

[0361] This may have an impact on UDP and/or TCP applications. For example, the

QoS of real-time UDP applications, such as but not limited to voice over IP and/or live video streaming, may suffer. Real-time UDP applications may suffer because out of order packets may be counted as lost packets and may be ignored at the receiver side. For TCP, packets out of order may generate a duplicate ACK issue, which may trigger unnecessary congestion control that may reduce end to end throughput.

[0362] A potential cause may be placing packets with a higher ID in a shorter queue

(e.g., smaller queuing delay) while other packets with a lower ID may be placed in a longer queue (e.g., bigger queuing delay). A potential cause may be when packets with a lower index are transmitted over slower links, while packets with a higher index are sent over faster links. A packet assignment strategy at the OMMA transmitter side may attempt to maintain the correct ordering of packet reception at the receiving end, such that the ordering delay may be minimized, for example, as shown in FIG. Error! Reference source not found.55b.

[0363] Referring to FIG. Error! Reference source not found.55a, an example configuration where a random assignment of packets may result in packet reordering delays at the receiving end is illustrated. This may be avoided via packet assignment strategies at the transmitting end, for example, as shown in the example of FIG. 55b.

[0364] FIG. 56 is a representation of an example OMMA layer smart packet allocation.

FIG. 56, which may be referred to as a leaky bucket implementation, may be a smart packet assignment that may minimize the average end-to-end latency per packet and/or minimize the out-of-order packet reception at the receiver for multi RAT aggregation. Simulations (e.g., OPNET simulations) may show the gains that this scheme may provide compared to other schemes, such as but not limited to, 50%-50% distributions of packets across two RATs and/or distribution of packets based on individual serving rates of RATs.

[0365] The example of FIG. 56 may maintain K token variables. There may be one token variable for each RAT. The token for each RAT may be assigned to be 0 (e.g., initially). The token for each RAT i may be incremented iteratively by— , where x; may be the optimal rate for RAT i calculated in the last section, until one or more of the tokens exceeds 1. The RAT corresponding to the token that exceeds 1 may be selected to send the next incoming

unscheduled packet at the OMMA layer. This token may be decremented by 1 and the process of incrementing tokens may be continued. This may run "ahead" of packets arriving at the OMMA layer (e.g., the OMMA layer may know which packet ID may be scheduled on which RAT). Since the x; s may be chosen so as to minimize the average system delay per packet, a leaky bucket implementation may ensure that the RAT chosen to send a packet may be such that each packet experiences the minimum delay and/or arrives in the correct order with respect to its preceding and succeeding packets at the receiver. [0366] The OMMA layer may perform a method of aggregating bandwidth available on multiple radio access technologies (RATs), for example, using a leaky bucket implementation. For example, the OMMA layer may assign a variable to each of a plurality of RATs. The OMMA layer may increment each of the plurality of variables at a rate. The rate related to an estimated arrival rate of a packet transmitted across the RAT to which the variable is assigned. The OMMA layer may determine that a variable of the plurality of variables is greater than or equal to one. The OMMA layer may transmit a packet across the RAT whose variable is greater than or equal to one. The OMMA layer may decrease the variable that is greater than or equal to one by one. The OMMA layer may continue to increment each of the plurality of variable at a rate, for example, until another variable is greater than or equal to one. The OMMA layer may send a packet across the RAT whose variable is greater than or equal to one, and decrease that variable by one. The OMMA layer may continue this implementation until all packets of an IP flow have been sent across the RATs.

[0367] The OMMA layer may perform a method of aggregating bandwidth available on multiple radio access technologies (RATs), for example, using a leaky bucket implementation. For example, the OMMA layer may have two or more associated RATs. The OMMA layer may assign a first variable to a first RAT and a second variable to a second RAT. The OMMA layer may increment the first variable of the first RAT by a first rate and increment the second variable of the second RAT by a second rate. The first rate may be related to an estimated arrival rate of a packet transmitted across the first RAT. The second rate related to an estimated arrival rate of a packet transmitted across the second RAT. The OMMA layer may determine that the first variable is greater than or equal to one, wherein the second variable is less than one. The OMMA layer may send a packet across the first RAT. The OMMA layer may decrease the first variable by one. The OMMA layer may continue the implementation until all packets of an IP flow have been sent across the RATs.

[0368] FIG. 57 is a graph illustrating an example of measurements of average reordering delay per packet for different scheduling implementations. Different scheduling

implementations at the OMMA layer of the sender node with different SNR levels at the PHY layer of a receiver node on each RAT may be deployed. The reordering delay at the receiver side may be measured, for example, as shown in FIG. 57. The leaky bucket implementation (e.g., as shown in FIG. 56) may be simulated and compared with other implementations which, for example, may schedule packets in random order but with predefined average percentage distribution across RATs. The leaky bucket implementation may outperform the other implementations. The single RAT selection (e.g., the results of which may be shown in FIG. 57) may be for reference. The single RAT selection (e.g., the results of which may be shown in FIG. 57) may use one RAT and may not experience any reordering issue.

[0369] Managing TCP traffic at the OMMA layer may be described herein. A congestion control and flow control mechanism may be triggered due to the packet loss and/or packet out of order over multiples RATs, for example, for TCP traffic. One or more of the following implementations may be used, e.g., to effectively handle UDP and/or TCP traffic, where such use may be in combination with other implementation(s) described herein. At the OMMA layer of the sender node, the OMMA layer may analyze the TCP header of an incoming packet to identify the beginning and/or the end of each TCP connection. At the beginning of the TCP transmission, the OMMA layer may route traffic to send over a single RAT (e.g., single RAT selection mode). This may help the TCP flow control ramp up to the stable stage before the OMMA layer may make the decision to switch to a multiplexing mode and/or RAT selection mode. The OMMA layer may analyze the TCP header to manage the beginning and/or the end of each TCP connection. The OMMA layer may deploy smart packet scheduling, e.g., as described herein, for each TCP flow and/or for combined TCP flows. A buffer may be deployed at the OMMA layer of the receiver. One function of this buffer may be for reordering purpose. Packets received out of order may be temporarily stored in this buffer. There may be a maximum duration for which packets may stay in the buffers (e.g., a few milliseconds). The packets may pop out of the buffer no later than this duration. This period of time may limit the sizes of the buffers. The TCP ACK packets sent back from the receiver may be allocated the highest priority and may be sent on the fastest and/or highest quality RAT at the time. This may ensure that the TCP ACK packets gets back as early as possible and in the correct order. ACK packets may have small sizes and may experience small packet latencies.

[0370] Various processing may occur for arriving TCP ACK packets at the OMMA layer of the sender. If the received packet at the OMMA sender is not a duplicate ACK, the OMMA layer may forward the ACK to upper layer as soon as it arrives. If the received packet is a duplicate ACK, the OMMA layer may buffer the third or later duplicate ACKs for a short period of time (e.g., a few milliseconds) before sending them to the upper layer. If an arrived packet is an ACK with later index than the duplicate ACK currently buffered, the OMMA layer may drop the duplicate ACK and send the most recent ACK to the upper layer. Since the third duplicate ACK that comes to sender may trigger the congestion control mechanism by reducing the sending rate (e.g., which may be significant), holding back this ACK may give more time for the data to get to the receiver successfully, for example, when latencies across the RATs are different. This may minimize an unnecessary congestion control mechanism to be triggered. [0371] Procedures to enable Multi-WTRU Multi IP flow traffic management in an

OMMA layer may be described herein. An example scenario of multiple WTRUs and a single NT in a system supporting multiple IP flows of different QoS classes from NT to WTRU in the system may be described herein. Each NT-WTRU link may be configured to operate using multiple RATs at any given time.

[0372] To support multiple WTRUs, each with multiple IP flows, the OMMA layer may comprise an OMMA Scheduler for each associated WTRU. It may comprise an IP Packet WTRU Classifier to read the WTRU address of the packet and/or send the packet to the OMMA scheduler corresponding to that WTRU. The OMMA Scheduler for each associated WTRU may comprise one or more Feedback Based Schedulers (FBSs) (e.g., separate FBS to handle IP flow of one QoS class (Access Category)). The OMMA scheduler may comprise an IP Packet QoS Identifier to identify the QoS class for incoming IP packet and/or to send it to corresponding FBS.

[0373] The OMMA Controller may comprise a Feedback WTRU Classifier to classify feedback metrics based on the WTRU address to send feedback metrics to OMMA Scheduler of corresponding WTRU. The OMMA Controller may comprise a Feedback QoS Classifier which may classify the feedback metrics based on the QoS class. These feedback metrics may be sent to appropriate FBS dedicated for that QoS class on the chosen OMMA Scheduler by Feedback WTRU Classifier.

[0374] FIG. 58 is a diagram illustrating an example of an OMMA Sender at NT for single RAT selection for Multi WTRU Multi IP Flow. An example of the OMMA layer at the sender is shown in FIG. 58 (e.g., at a NT when data traffic flows in the downlink direction from the NT to a WTRU, or at a WTRU when data traffic flows in the uplink direction from the WTRU to a NT).

[0375] Traffic routing at the OMMA sender may include one or more of the following.

IP packets may arrive at IP Packet WTRU Classifier of the OMMA layer. IP Packet WTRU Classifier may forward the IP packet to a corresponding OMMA Scheduler based on WTRU address. At the OMMA Scheduler, the IP packets may be sent to an IP Packet QoS Identifier. The IP Packet QoS Identifier may forward the IP packet to FBS of the corresponding QoS class (e.g., access category).

[0376] FBS may make a decision on RAT selection based on the RAT capability provided by the Capability Database using the A4 interface and/or feedback provided from the OMMA Controller for the IP flow's access category using the A5a interface.

RAT_Metrics_FBS_A5a signal of the A5a interface may include of one or more of the following parameters: RAT_Id, which may provide the RAT Ids of the enabled RATs; STA_Addr, which may provide the address of the WTRU for which the parameters may apply; IP_QoS_Type, which may provide QoS Classes (e.g., access category) for which feedback may be available; Metrics, which may comprise one or more of the following parameters for each QoS class (e.g., access category) given in IP_QoS_Type for the RATs given in RAT_Id vector for the WTRU given in STA_Addr: Arrival_Rate; Serving_Rate; and/or Avg_Pkt_Delay. It may choose one or more of the RATs capable for that WTRU, for example, at cold-start.

[0377] Based on the final decision on RAT selection, the FBS may distribute incoming

IP packets across the selected RATs (e.g., optimally) so as to, for example, minimize average end-to-end delay per packet and/or minimize out-of-order packet reception. The FBS may forward the packets to the Packet Fragmentation module (e.g., if enabled) of the selected RATs. The FBS may send a decision of the selected RATs to the Fragmentation Controller module of the OMMA Controller, for example, vai the Al l interface. A Frag_Decision_Request_Al 1 signal on Al 1 interface may include, for example, STA_Addr, which may provide an address of the WTRU for which request has been made, and/or RAT_Id_List, which may comprise one or more of the RAT Ids of the selected RATs.

[0378] A Fragmentation Controller may make a decision of fragmentation based on, for example, the request made through the Al l interface. If the fragmentation controller does not have MTU information of the selected RAT, the fragmentation controller may communicate with an Capability Database to receive MTU information, for example, using the Al interface. Signal STA RAT Capability Query Al on the Al interface may include STA Addr, which may provide an address of the WTRU for which request has been made, and/or RAT_Id_List, which may comprise one or more of the RAT Ids of the selected RATs. The capability database may send the response to the above request, for example, through the same interface Al. Signal STA RAT capability Response Al on the Al interface may include of one or more of the following parameters: STA_Addr, which may provide an address of the WTRU for which request has been made; RAT_Id_List, which may comprise the RAT Ids of the selected RATs; and/or RAT_Info, which may provide an array of 3-tuples (e.g., MTU, Max_RAT_Capability, RAT_Availability) for the RAT Id of the selected RATs (e.g., specified in RAT_Id_List).

[0379] A Packet Fragmentation module of the selected RATs may receive the decision of fragmenting or not fragmenting the incoming packet from the FBS, for example, based on the fragmentation decision received from Fragmentation Controller through interface A 12. Signal Fragmentation _Decision_A 12 on A12 interface may include of one or more of the following parameters: STA_Addr, which may provide an address of the WTRU for which request has been made; RAT_Id_List, which may comprise the RAT Ids of the selected RATs; and/or

Frag_Decision_List, which may comprise the decision for fragmentation for the selected RAT using, for example, '0' to indicate Fragmentation OFF and ' Γ to indicate Fragmentation ON. This may be performed after that packets/fragments may be sent to the RAT.

[0380] A RAT switch may occur when a selected RAT is unable to fulfill a requirement of given IP flow QoS Class. When FBS detects this situation, it may query the WTRU RAT Capability Database for RAT availability information through, for example, the

STA_RAT_Capability_Query_A4 signal on the A4 interface. After receiving a list of RATs that may be available for the WTRU (e.g. , through STA_RAT_Capability_Response_A4 signal on A4 interface), the FBS may select an unused RAT from the RAT availability list to replace the above RAT (e.g., which may not be able to fulfill the QoS requirement).

[0381] When a RAT switch occurs, the FBS may duplicate one or more packets across one or more RATs (e.g., two RAT, for example, a RAT which is not able to fulfil the QoS requirement and a RAT chosen to replace this RAT) to enable a soft handover across RATs and/or avoid out-of-order packet reception at OMMA receiver.

[0382] FIG. 59 is a diagram illustrating an example call flow comprising one or more of the implementations described herein.

[0383] As described herein, a node (e.g., a NT or a WTRU) comprising an OMMA layer may aggregate bandwidth available on RATs. The node may establish a communication path via one or more RATs. The OMMA layer of the node may comprise a controller in operable communication with one or more RATs, and a scheduler in operable communication with one or more RATs. For example, the controller and scheduler may be in operable communication with a first RAT and a second RAT. The controller may be configured to determine a time duration and a bandwidth requirement of an IP packet. For example, the controller may be configured to determine a first time duration and a first bandwidth requirement for a first IP packet, and determine a second time duration and a second bandwidth requirement for a second IP packet. The first IP packet and the second IP packet may be part of an IP flow addressed to a receiving node (e.g., a NT or a WTRU). For example, the IP flow may be associated with a single application. For example, the node may be a NT and the receiving node may be a WTRU, or the node may be a WTRU and the receiving node may be a NT.

[0384] The controller may be configured to request resources on the one or more RATs.

For example, the controller may be configured to request resources on the first RAT and the second RAT based on the first time duration and the first bandwidth requirement for the first IP packet and based on the second time duration and second bandwidth requirement for the second IP packet. The controller may be configured to send instructions to the scheduler.

[0385] The scheduler may be configured to receive feedback information associated with the one or more RATs. For example, the scheduler may be configured to receive first feedback information associated with the first RAT, and receive second feedback information associated with the second RAT. The scheduler may be configured to determine to send one or more IP packets via the one or more RATs (e.g., according to the implementations described herein). For example, the scheduler may be configured to determine to send the first IP packet via the first RAT according to the first and second feedback information and the instructions, and determine to send the second IP packet via the second RAT according to the first and second feedback information and the instructions. The scheduler may be configured to send one or more IP packets via one or more RATs. For example, the scheduler may be configured to send the first IP packet via the first RAT, and send the second IP packet via the second RAT.

[0386] As described herein, the OMMA layer may be utilized to aggregate IP packets into an IP flow. The OMMA layer may receive one or more IP packets from one or more RATs. For example, the OMMA layer may receive a first IP packet via a first RAT, and receive a second IP packet via a second RAT. For example, the first RAT may be associated with a first license exempt (LE) band channel, and the second RAT may be associated with a second LE band channel. The OMMA layer may aggregate on or more IP packets into an IP flow. For example, the OMMA layer may aggregate the first IP packet and second IP packet to recreate an IP flow. The IP flow may be associated with a single application.

[0387] For example, the OMMA layer may receive a third IP packet via a third RAT.

The third RAT may be associated with a WiFi channel. The OMMA layer may aggregate the first IP packet, the second IP packet, and the third IP packet to recreate the IP flow. Further, the OMMA layer may create headers for one or more IP packets. The headers may relate to the order of the IP packets within the IP flow. For example, the first IP packet may comprise a first header and the second IP packet may comprise a second header (e.g., which may have been created by the OMMA layer). The first header and the second header may relate to an order of IP packets of the IP flow.

[0388] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

What is Claimed:

1. A method of aggregating bandwidth available on multiple radio access technologies (RATs), the method comprising:

receiving first feedback information associated with a first RAT;

receiving second feedback information associated with a second RAT;

determining a first IP packet to send via the first RAT according to the first and second feedback information;

determining a second IP packet to send via the second RAT according to the first and second feedback information, wherein the first and second IP packets are part of an Internet Protocol (IP) flow addressed to a node;

sending the first IP packet via the first RAT; and

sending the second IP packet via the second RAT.

2. The method of claim 1, further comprising:

establishing a first communication path via the first RAT associated with the node; and establishing a second communication path via the second RAT associated with the node.

3. The method of claim 1 , wherein the IP flow is associated with a single application.

4. The method of claim 1, wherein the node is an access point (AP).

5. The method of claim 1, wherein the node is a wireless transmit/receive unit (WTRU).

6. The method of claim 1, wherein each of the first feedback information and the second feedback information comprise at least one of a medium access delay, a frame error rate, an average data rate, a received signal strength indication (RSSI), queuing latency per access category per RAT, end-to-end latency, a backoff time, a number of channels, channel bandwidth, a media access control (MAC) type, MAC aggregation support, an access category, a transmission opportunity (TXOP) duration, an estimated arrival rate of a packet, an average serving rate, an average serving latency, a second moment of average serving latency, an average vacation time, a second average of vacation time, or a transmission control protocol (TCP) parameter.

7. The method of claim 1, wherein the first feedback information and the second feedback information are received via at least one of of an A2 interface, an A3 interface, an A5a interface, or an A5b interface.

8. The method of claim 1, wherein determining to send the first IP packet via the first RAT and the second IP packet via the second RAT is determined further according to at least one rule, the at least one rule comprising a quality of service (QoS) class rule.

9. The method of claim 8, wherein the at least one rule further comprises at least one of a device capability rule, an operator policy rule, an IP packet flow rule, a device coordinate rule, a source domain rule, a source IP address rule, a destination domain rule, a destination IP address rule, IP protocol rule, a port number rule, a subscriber priority rule, a link quality rule, a charging rule, or a security rule.

10. The method of claim 1, further comprising:

determining a time duration and a bandwidth requirement for the IP flow; and requesting resources on the first RAT and on the second RAT based on the time duration and the bandwidth requirement for the first IP packet and the second IP packet, wherein the resources are characterized by the time duration and the bandwidth requirement.

1 1. The method of claim 10, further comprising:

receiving a quality of service (QoS) of the first IP packet and a QoS of the second IP packet, wherein the resources on the first RAT and on the second RAT are requested based further on at least one of the first feedback information, the second feedback information, the QoS of the first IP packet, and the QoS of the second IP packet.

12. The method of claim 10, wherein the resources are requested on the first RAT and on the second RAT using at least one of an A 1 interface or an A2 interface.

13. The method of claim 1, further comprising:

receiving first maximum transmit unit (MTU) information associated with the first RAT; receiving second MTU information associated with the second RAT;

receiving packet size information associated with the first IP packet;

receiving packet size information associated with the second IP packet; adjusting at least one of a size of a MTU of the first IP packet or a size of a MTU of the second IP packet based on the first MTU information and the second MTU information.

14. The method of claim 13, wherein the size of the MTU of the first packet is different from the size of the MTU of the second packet.

15. The method of claim 13, wherein the size of the MTU of the first packet is the same as the size of the MTU of the second packet.

16. The method of claim 1, wherein the node a multi-RAT node, the method further comprising:

receiving a signal from the multi-RAT node, the signal being characterized by a plurality of available RATs of the multi-RAT node.

17. The method of claim 1, wherein determining to send the first IP packet via the first RAT and the second IP packet via the second RAT is determined further according to a packet distribution mode.

18. The method of claim 17, wherein the packet distribution mode is at least one of diversity mode, multiplexing mode, hybrid mode, or dynamic RAT selection mode.

19. The method of claim 1, further comprising:

determining whether channel quality of the first RAT is below a threshold;

upon determining that the channel quality of the first RAT is below the threshold, duplicating the first IP packet to create a first instance of the first IP packet and a second instance of the first IP packet;

sending the first instance of the first IP packet via the first RAT; and

sending the second instance of the first IP packet via a third RAT.

20. The method of claim 19, further comprising:

determining whether channel quality of the second RAT is at or above the threshold; and upon determining that the channel quality of the second RAT is at or above the threshold, sending the second IP packet via the second RAT.

21. The method of claim 1, wherein the first RAT is at least one of a WiFi RAT, an LTE RAT, a WCDMA/HSPA RAT, an UTRAN RAT, or an E-UTRAN RAT; and

wherein the second RAT is at least one of a WiFi RAT, an LTE RAT, a WCDMA/HSPA RAT, an UTRAN RAT, or an E-UTRAN RAT.

22. The method of claim 1, wherein the first RAT is a WiFi RAT operating over an industrial, scientific and medical (ISM) radio band and the second RAT is a WiFi RAT operating over a TV white space (TVWS) radio band.

23. A node in communication with a wireless communication system, the node comprising: a processor in operable communication with a plurality of radio access technologies

(RATs), the processor configured to:

receive first feedback information associated with a first RAT;

receive second feedback information associated with a second RAT; determine a first IP packet to send via the first RAT according to the first and second feedback information;

determine a second IP packet to send via the second RAT according to the first and second feedback information, wherein the first and second IP packets are part of an Internet Protocol (IP) flow addressed to a receiving node;

send the first IP packet via the first RAT; and

send the second IP packet via the second RAT.

24. The node of claim 23, wherein the processor is further configured to:

establish a first communication path via the first RAT associated with the node; and establish a second communication path via the second RAT associated with the node.

25. The node of claim 23, wherein the IP flow is associated with a single application.

26. The node of claim 23, wherein the node is an access point (AP) and the receiving node is a wireless transmit/receive unit (WTRU).

27. The node of claim 23, wherein the node is a WTRU and the receiving node is an AP.

28. The node of claim 23, wherein each of the first feedback information and the second feedback information comprise at least one of a medium access delay, a frame error rate, an average data rate, a received signal strength indication (RSSI), queuing latency per access category per RAT, end-to-end latency, a backoff time, a number of channels, channel bandwidth, a media access control (MAC) type, MAC aggregation support, an access category, a transmission opportunity (TXOP) duration, an estimated arrival rate of a packet, an average serving rate, an average serving latency, a second moment of average serving latency, an average vacation time, a second average of vacation time, or a transmission control protocol (TCP) parameter.

29. The node of claim 23, wherein the processor is configured to receive the first feedback information and the second feedback information via one or more of an A2 interface, an A3 interface, an A5a interface, and an A5b interface.

30. The node of claim 23, wherein the processor is further configured to determine to send the first IP packet via the first RAT and the second IP packet via the second RAT according to at least one rule, the at least one rule comprising a quality of service (QoS) class rule.

31. The node of claim 30, wherein the at least one rule further comprises at least one of a device capability rule, an operator policy rule, an IP packet flow rule, a device coordinate rule, a source domain rule, a source IP address rule, a destination domain rule, a destination IP address rule, IP protocol rule, a port number rule, a subscriber priority rule, a link quality rule, a charging rule, and a security rule.

32. The node of claim 23, wherein the processor is further configured to:

determine a time duration and a bandwidth requirement for the IP flow; and

request resources on the first RAT and on the second RAT based on the time duration and the bandwidth requirement for the first IP packet and the second IP packet, wherein the resources are characterized by the time duration and the bandwidth requirement.

33. The node of claim 32, wherein the processor is further configured to:

receive a quality of service (QoS) of the first IP packet and a QoS of the second IP packet, wherein the resources on the first RAT and on the second RAT are requested based further on at least one of the first feedback information, the second feedback information, the QoS of the first IP packet, and the QoS of the second IP packet.

34. The node of claim 32, wherein the processor is configured to receive the resources on the first RAT and on the second RAT using one or more of an A 1 interface and an A2 interface.

35. The node of claim 23, wherein the processor is further configured to:

receive first maximum transmit unit (MTU) information associated with the first RAT; receive second MTU information associated with the second RAT;

receive packet size information associated with the first IP packet;

receive packet size information associated with the second IP packet;

adjust at least one of a size of a MTU of the first IP packet or a size of a MTU of the second IP packet based on the first MTU information and the second MTU information.

36. The node of claim 35, wherein the size of the MTU of the first packet is different from the size of the MTU of the second packet.

37. The node of claim 35, wherein the size of the MTU of the first packet is the same as the size of the MTU of the second packet.

38. The node of claim 23, wherein the receiving node a multi-RAT node, and the processor is further configured to:

receive a signal from the multi-RAT node, the signal being characterized by a plurality of available RATs of the multi-RAT node.

39. The node of claim 23, wherein the processor is further configured to determine to send the first IP packet via the first RAT and the second IP packet via the second RAT according to a packet distribution mode.

40. The node of claim 39, wherein the packet distribution mode is at least one of diversity mode, multiplexing mode, hybrid mode, or dynamic RAT selection mode.

41. The node of claim 23, wherein the processor is further configured to:

determine whether channel quality of the first RAT is below a threshold; upon determining that channel quality of the first RAT is below the threshold, duplicate the first IP packet to create a first instance of the first IP packet and a second instance of the first IP packet;

send the first instance of the first IP packet via the first RAT; and

send the second instance of the first IP packet via a third RAT.

42. The node of claim 41, wherein the processor is further configured to:

determine whether channel quality of the second RAT is below the threshold; and upon determining that channel quality of the second RAT is at or above the threshold, send the second IP packet via the second RAT.

43. The node of claim 23, wherein the first RAT is at least one of a WiFi RAT, an LTE RAT, a WCDMA/HSPA RAT, an UTRAN RAT, or an E-UTRAN RAT; and

wherein the second RAT is at least one of a WiFi RAT, an LTE RAT, a WCDMA/HSPA RAT, an UTRAN RAT, or an E-UTRAN RAT.

44. The node of claim 23, wherein the first RAT is a WiFi RAT operating over an industrial, scientific and medical (ISM) radio band and the second RAT is a WiFi RAT operating over a TV white space (TVWS) radio band.

45. A method of aggregating bandwidth available on multiple radio access technologies (RATs), the method comprising:

assigning a first variable to a first RAT and a second variable to a second RAT;

incrementing the first variable of the first RAT by a first rate, the first rate related to an estimated arrival rate of a packet transmitted across the first RAT;

incrementing the second variable of the second RAT by a second rate, the second rate related to an estimated arrival rate of a packet transmitted across the second RAT;

determining whether the first variable is greater than or equal to a threshold value;

upon determining that the first variable is greater than or equal to the threshold value and that the second variable is less than the threshold value, sending a packet across the first RAT; and

decreasing the first variable by the threshold value.

46. A method of aggregating bandwidth available on multiple radio access technologies (RATs), the method comprising:

assigning a variable to each of a plurality of RATs;

incrementing each of the plurality of variables at a rate, the rate related to an estimated arrival rate of a packet transmitted across the RAT to which the variable is assigned;

determining whether a variable of the plurality of variables is greater than or equal to a threshold value;

upon determining that the variable of the plurality of variables is greater than or equal to the threshold value, sending a packet across the RAT whose variable is greater than or equal to the threshold value; and

decreasing the variable that is greater than or equal to the threshold value by a number.

47. A method for aggregating IP packets into an IP flow, the method comprising:

receiving a first IP packet via a first radio access technologies (RAT);

receiving a second IP packet via a second RAT, wherein the first RAT is associated with a first license exempt (LE) band channel, and the second RAT is associated with a second LE band channel, wherein the first IP packet and the second IP packet are part of the IP flow; and aggregating the first IP packet and second IP packet to recreate the IP flow.

48. The method of claim 47, further comprising:

receiving a third IP packet via a third RAT, wherein the third RAT is associated with a WiFi channel; and

aggregating the first IP packet, the second IP packet, and the third IP packet to recreate the IP flow.

49. The method of claim 47, wherein the first IP packet comprises a first header and the second IP packet comprises a second header, the first header and the second header relating to an order of IP packets of the IP flow.

50. The method of claim 49, further comprising:

reading the first header of the first IP packet;

reading the second header of the second IP packet; and

aggregating the first IP packet and the second IP packet to recreate the IP flow based on the first header and the second header.

51. A node comprising an opportunistic multiple radio access technologies (RAT) aggregation (OMMA) layer, the OMMA layer comprising:

a controller in operable communication with a first radio access technology (RAT) and a second RAT, the controller configured to:

determine a first time duration and a first bandwidth requirement for a first IP packet;

determine a second time duration and a second bandwidth requirement for a second IP packet, wherein the first IP packet and the second IP packet are part of an IP flow addressed to a receiving node;

request resources on the first RAT and the second RAT based on the first time duration and the first bandwidth requirement for the first IP packet and based on the second time duration and second bandwidth requirement for the second IP packet; and send instructions to a scheduler;

the scheduler in operable communication with the first RAT and the second RAT, the scheduler configured to:

receive first feedback information associated with the first RAT; receive second feedback information associated with the second RAT;

determine to send the first IP packet via the first RAT according to the first and second feedback information and the instructions; and

determine to send the second IP packet via the second RAT according to the first and second feedback information and the instructions.

52. The node of claim 51, wherein the IP flow is associated with a single application.

53. The node of claim 51, wherein the node is an access point (AP) and the receiving node is a wireless transmit/receive unit (WTRU).

54. The node of claim 51 , wherein the node is a WTRU and the receiving node is an AP.