WO2013126859A2 - Sélection et agrégation de technologie d'accès radio opportunistes - Google Patents

Sélection et agrégation de technologie d'accès radio opportunistes Download PDF

Info

Publication number
WO2013126859A2
WO2013126859A2 PCT/US2013/027541 US2013027541W WO2013126859A2 WO 2013126859 A2 WO2013126859 A2 WO 2013126859A2 US 2013027541 W US2013027541 W US 2013027541W WO 2013126859 A2 WO2013126859 A2 WO 2013126859A2
Authority
WO
WIPO (PCT)
Prior art keywords
rat
packet
omma
node
layer
Prior art date
Application number
PCT/US2013/027541
Other languages
English (en)
Other versions
WO2013126859A3 (fr
Inventor
Amith V. Chincholi
Tan B. LE
Alpaslan Demir
John Cartmell
Sanjay Goyal
Chunxuan Ye
Zinan Lin
Bartosz Balazinski
Tariq ELKOURDI
Francois Periard
Original Assignee
Interdigital Patent Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Interdigital Patent Holdings, Inc. filed Critical Interdigital Patent Holdings, Inc.
Publication of WO2013126859A2 publication Critical patent/WO2013126859A2/fr
Publication of WO2013126859A3 publication Critical patent/WO2013126859A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1215—Wireless traffic scheduling for collaboration of different radio technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Definitions

  • NR network terminal
  • AP access point
  • eNB eNodeB
  • HeNbs Homes eNbs
  • WTRU wireless transmit/receive unit
  • UE user equipment
  • STA station
  • IP Internet Protocol
  • 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.
  • MAC Opportunistic Multiple- Medium Access Control
  • OMMA Opportunistic Multiple- Medium Access Control
  • a node 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.
  • IP Internet Protocol
  • the processor may send the first IP packet via the first RAT and may send the second IP packet via the second RAT.
  • the processor of the node may be further configured to perform a hybrid packet distribution method.
  • the processor may be configured to determine whether channel quality of the first RAT and/or the second RAT is below a 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.
  • the processor may be configured to send the second IP packet via the second RAT.
  • a method 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
  • 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.
  • a node 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.
  • FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. IB is a system diagram of an example wireless transmit/receive unit
  • WTRU wireless communications
  • 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.
  • 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 is a diagrammatic representation of FIG. 1A.
  • 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 is a diagrammatic representation of FIG. 1A.
  • FIG 2 is an example system architecture of a base station system infrastructure.
  • FIG 3 is an example system of a NT with capability to support multiple RATs.
  • FIG 4 is a diagram illustrating an example of multi-RAT aggregation using an
  • FIG. 5 is a diagram illustrating an example of dual-RAT aggregation with a common OMMA layer residing above a MAC.
  • FIG. 6 is a block diagram of an example OMMA layer.
  • 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.
  • FIG. 8 is a diagram illustrating an example of an active scanning procedure.
  • FIG. 9 is a diagram illustrating an example of an passive scanning procedure.
  • FIG. 10 is a diagram illustrating an example of diversity mode.
  • FIG. 1 1 is a diagram illustrating an example of multiplexing mode.
  • FIG. 12 is a diagram illustrating an example of hybrid mode.
  • FIG. 13 is a diagram illustrating an example of dynamic RAT switching mode.
  • FIG. 14 is a diagram illustrating an example timeline for transmitting feedback metrics.
  • FIG. 15 is a diagram illustrating an example message sequence where an OMMA requests measurement metrics for each RAT.
  • FIG. 16 is an example message sequence where RAT modules report metrics periodically or aperiodcially to an OMMA module.
  • FIG. 17 is a dia ⁇ *ram illustrating ; an example of state and state transition triggers of an OMMA layer.
  • FIG. 18 is a dia ⁇ *ram illustrating ; an example of a TCP session.
  • FIG. 19 is a dia ⁇ *ram illustrating ; an example of aggregation performed for TCP data.
  • FIG. 20 is a dia ⁇ *ram illustrating ; an example architecture of a solution.
  • FIG. 21 is a dia ⁇ *ram illustrating ; an example processing of a solution.
  • FIG. 22 is a dia ⁇ *ram illustrating ; an example header of a solution.
  • FIG. 23 is a dia ⁇ *ram illustrating ; an example of how OMMA may route packets.
  • FIG. 24 is a dia ⁇ *ram illustrating ; an example of a table maintained by OMMA.
  • FIG. 25 is a dia ⁇ *ram illustrating ; an example of logic used when there is a packet to be scheduled.
  • FIG. 26 is a dia ⁇ *ram illustrating ; an example of UDP logic.
  • FIG. 27 is a dia ⁇ *ram illustrating ; an example of TCP logic.
  • FIG. 28 is a functional block diagram that depicts an example implementation of an OMMA layer according to an embodiment.
  • FIG. 29 is a functional block diagram that depicts an example implementation of an OMMA Controller.
  • FIG. 30 is a functional block diagram illustrating one example implementation of an OMMA Scheduler.
  • FIG. 31 is a call flow diagram that illustrates an example call flow showing signaling corresponding to a process for RAT availability determination.
  • 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.
  • FIG. 33 illustrates a call flow for the example scenario of FIG. 32.
  • FIG. 34 is a functional block diagram illustrating an example transparent OMMA
  • Receiver for single RAT enabled, single WTRU, single IP flow Receiver for single RAT enabled, single WTRU, single IP flow.
  • FIG. 35 is a functional block diagram illustrating an example OMMA receiver performing reassembly on a selected RAT.
  • FIG. 36 depicts an example call flow for allocating wireless resources for medium access by a NT and WTRUs using a RAT.
  • FIG. 37 illustrates an example interface between an OMMA Controller and a
  • FIG. 38 illustrates an example interface between an OMMA Controller and a
  • FIG. 39 illustrates an example interface between an OMMA Controller and ai
  • FIG. 40 illustrates an example matrix for signaling parameters.
  • FIG. 41 illustrates an example matrix for signaling parameters.
  • FIG. 42 illustrates an example matrix for signaling parameters.
  • FIG. 43 illustrates an example interface between an OMMA Controller and a
  • FIG. 44 illustrates example feedback metrics that may be sent by RATs.
  • FIG. 45 is a functional block diagram depicting an example interface between an
  • FIG. 46 is a functional block diagram depicting an example interface between an
  • FIG. 47 is a functional block diagram illustrating an example interface between
  • 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.
  • FIG. 49 is a functional block diagram illustrating an example implementation of an Ax interface between a Policy Database and a DNS-APP entity.
  • 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.
  • UI-APP user interface application
  • FIG. 51 is a diagram illustrating an example of Multi-RAT Aggregation using
  • FIG. 52 is a diagram illustrating an example of a threshold for mode selection in two RAT systems.
  • FIG. 53 is a diagram illustrating and examples of a packet reordering scenario.
  • FIG. 54 is a diagram illustrating and examples of a packet reordering scenario.
  • FIG. 55a is a diagram illustrating a random assignment of packets
  • FIG. 55b is a diagram illustrating a smart assignment of packets across RATs.
  • FIG. 56 is a representation of an example OMMA smart packet allocation algorithm.
  • FIG. 57 is a graph illustrating an example of measurements of average reordering delay per packet for different scheduling schemes.
  • 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.
  • FIG. 59 is a diagram illustrating an example call flow.
  • 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.
  • 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.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single- carrier FDMA
  • 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.
  • 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.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • 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.
  • 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.
  • BTS base transceiver station
  • AP access point
  • 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.
  • BSC base station controller
  • RNC radio network controller
  • 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.
  • the cell associated with the base station 1 14a may be divided into three sectors.
  • the base station 114a may include three transceivers, e.g., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • the base stations 1 14a, 114b may communicate with one or more of the WTRUs
  • 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).
  • RAT radio access technology
  • 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.
  • 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).
  • UMTS Universal Mobile Telecommunications System
  • UTRA Universal Mobile Telecommunications System
  • WCDMA wideband CDMA
  • 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).
  • HSPA High-Speed Packet Access
  • HSDPA High-Speed Downlink Packet Access
  • HSUPA High-Speed Uplink Packet Access
  • 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).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • 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.
  • IEEE 802.16 e.g., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • 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).
  • 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).
  • WLAN wireless local area network
  • 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.
  • a cellular- based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
  • the base station 114b may have a direct connection to the Internet 1 10.
  • the base station 114b may not be required to access the Internet 1 10 via the core network 106/107/109.
  • the RAN 103/104/105 may be in communication with the core network
  • 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.
  • 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.
  • the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106/107/109 may also serve as a gateway for the WTRUs 102a,
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • 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.
  • 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
  • the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
  • 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.
  • FIG. IB is a system diagram of an example WTRU 102.
  • 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.
  • GPS global positioning system
  • 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.
  • BTS transceiver station
  • Node-B a Node-B
  • AP access point
  • eNodeB evolved home node-B
  • HeNB home evolved node-B gateway
  • proxy nodes among others, may include some or all of the elements depicted in FIG. IB and described herein.
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of
  • 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.
  • 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
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • 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.
  • 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.
  • 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.
  • the WTRU 102 may have multi-mode capabilities.
  • 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.
  • 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.
  • 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.
  • SIM subscriber identity module
  • SD secure digital
  • 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).
  • 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.
  • 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.
  • 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.
  • location information e.g., longitude and latitude
  • 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.
  • 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.
  • 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.
  • 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
  • FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment.
  • 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.
  • 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.
  • the Node-Bs 140a, 140b may be in communication with the Node-Bs 140a, 140b
  • RNC 142a 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.
  • the core network 106 shown in FIG. 1C may include a media gateway (MGW)
  • GGSN gateway GPRS support node
  • 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.
  • 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.
  • 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.
  • FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment.
  • 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.
  • 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
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell
  • the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • 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.
  • MME mobility management gateway
  • PDN packet data network
  • the MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer
  • 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.
  • the serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b,
  • 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.
  • 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.
  • the PDN gateway 166 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 core network 107 may facilitate communications with other networks.
  • 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.
  • 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.
  • IMS IP multimedia subsystem
  • 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.
  • 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.
  • ASN access service network
  • 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.
  • 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.
  • the base stations 180a, 180b, 180c may implement MIMO technology.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the MIP-HA may be responsible for IP address management, and may enable the
  • 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.
  • 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.
  • 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.
  • 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.
  • a network terminal e.g., an access point (AP), an eNodeB (eNB), a Home eNbs
  • HeNbs HeNbs
  • a relay e.g., a relay, etc.
  • a WTRU e.g., a UE, a STA, etc.
  • a node may refer to a network terminal, a WiFi access point, a WTRU, etc.
  • 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.
  • 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).
  • TDD time division duplexing
  • 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
  • NT communicates (e.g., simultaneously) with a NT over, for example, an ISM channel and a TVWS channel.
  • 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.
  • RF radio frequency
  • 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.
  • IP internet protocol
  • a WTRU may select a RAT to communicate over the air interface with the other WTRU or NT.
  • the medium access delay per channel may be high due to contention among
  • 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.
  • 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.
  • a single thin software layer e.g., an opportunistic multi-medium access control (MAC) aggregation (OMMA) layer
  • the single thin software layer may reside above the medium access control (MAC) layers of the protocol stacks but below the IP layer.
  • 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.
  • ISM industrial scientific medical
  • FIG. 2 is a diagram illustrating an example system 200 architecture of a base station system infrastructure.
  • 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.
  • TDD time division duplexing
  • 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
  • the OMMA layer 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.
  • the OMMA layer may receive meta-data/link statistics feedback (e.g., feedback information) from a RAT (e.g., each RAT).
  • 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.
  • 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.
  • the OMMA layer may comprise a MAC resource reservation mechanism.
  • MAC resource reservation mechanism may be responsible for requesting a specific amount of time or frequency resources on the medium per channel.
  • 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.
  • the packet distribution mode may be a diversity mode, a multiplexing mode, a hybrid mode, or a dynamic RAT selection mode.
  • 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.
  • 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.
  • a system may comprise a NT with the capability to support multiple Radio
  • 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.
  • 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.
  • a WTRU 315 in the system 300 may operate on one or more RATs (e.g., those described herein).
  • 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.
  • a WTRU (e.g. , a multi-RAT WTRU) may support more than one RAT.
  • FIG. 4 is a diagram illustrating an example of multi-RAT aggregation using an
  • 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.
  • 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.
  • 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;
  • a WTRU and a NT that comprise an OMMA layer may support multiple RAT connection simultaneously.
  • a NT and/or WTRU may comprise one or more modules within the NT and/or
  • 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.
  • RATs 401 multiple antenna/radio frequency (RF) front-end pairs 403
  • RF radio frequency
  • a RAT may be, for example, a WiFi RAT, an LTE RAT, a
  • 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.
  • ISM industrial, scientific and medical
  • TVWS TV white space
  • 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
  • a Bluetooth RAT operating on 2.4GHz ISM band e.g., 700MHz band
  • a Bluetooth RAT operating on 2.4GHz ISM band e.g., 700MHz band
  • each may be operating on a specific band.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • IP internet protocol
  • QoS quality of service
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • OMMA RAT selection may be described herein.
  • OMMA devices e.g., a NT and a WTRU
  • FIG. 8 is a diagram illustrating an example of an 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).
  • the NT may transmit a probe response on one or more of the RATs.
  • the NT may transmit its OMMA parameters along with the probe response.
  • the WTRU may select one or more of the RATs to perform the authentication with the other device.
  • 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.
  • FIG. 9 is a diagram illustrating an example of a 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.
  • 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.
  • the WTRU may compare a list of RATs supported by the NT with its own list of
  • 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.
  • 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.
  • 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.
  • FIG. 10 is a diagram illustrating an example of 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.
  • FIG. 11 is a diagram illustrating an example of multiplexing mode.
  • 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.
  • an upper threshold e.g., is very good
  • FIG. 12 is a diagram illustrating an example of hybrid mode.
  • 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.
  • FIG. 13 is a diagram illustrating an example of 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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,
  • some of the devices may have a fixed ratio in which they may serve packets across the RATs.
  • this fixed ratio may be stored in the device (e.g., WTRU or NT) memory.
  • the OMMA transmitter may look up an internal
  • 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
  • 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.
  • 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
  • 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
  • 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.
  • the cold start phase may be triggered when the device starts an OMMA layer/module for the very first time.
  • 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:
  • 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 )
  • 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.
  • 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).
  • BW bandwidth
  • FER frame error rate
  • the ratio may be determined by the OMMA layer utilizing the following:
  • 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.
  • OMMA multi-RAT metric feedback management may be described herein.
  • the OMMA layer may receive the available bandwidth of each of the one or more RATs.
  • the OMMA layer may receive RSSI values as seen by the one or more RATs.
  • 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
  • the OMMA layer algorithm may process the metrics received and update the ratio of distribution of packets across RATs
  • 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.
  • 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.
  • 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.
  • 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.
  • ISM_MSDU_ARRIVAL_U MAC MSDU OMMA is Transparent; IDLE IDLE L from ISM band Forwards packet to IP
  • TVWS_MSDU_ARRIVAL MAC MSDU OMMA is Transparent; IDLE IDLE _UL from TVWS band Forwards packet to IP
  • FIG. 18 is a diagram illustrating an example TCP.
  • 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.
  • 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.
  • FIG. 19 is a diagram illustrating an example of aggregation performed for TCP data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the receiving OMMA layer 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.
  • 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.
  • 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.
  • 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.
  • TCP protocol that has retransmissions
  • 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.
  • 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.
  • 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.
  • the OMMA layer may move them periodically.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a table e.g., the table of FIG. 24
  • 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.
  • UDP logic e.g., Figure 26
  • TCP logic e.g., Figure 27
  • 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.
  • the table may be updated with the packet at 2507. The packet may then be queued onto a separate transport.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the OMMA layer may receive metadata/link statistics feedback from each RAT.
  • 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.
  • 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.
  • Using multiple RATs simultaneously may provide increased bandwidth and/or increased reliability for an application.
  • a system comprising an OMMA layer may intelligently manage data traffic across multiple RATs for improved performance by
  • 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.
  • IP fragmentation may depend on the maximum transmission unit (MTU) size of the RAT.
  • MTU maximum transmission unit
  • An OMMA layer may support unequal MTU sizes of RATs, for example, by supporting fragmentation and reassembly of packets.
  • 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.
  • 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.
  • 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.
  • the OMMA layer may utilize MAC resource reservation to achieve globally optimal resource allocation across RATs.
  • a device 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.
  • 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.
  • interfaces disclosed herein may be standardized as a service access point (SAP) between the RAT protocol stacks and the OMMA layer.
  • SAP service access point
  • 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.
  • GW common gateway
  • 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.
  • 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.
  • a node e.g., a NT or a WTRU
  • the node may aggregate bandwidth available on multiple radio access technologies (RATs).
  • the node may establish a communication path via one or more RATs.
  • 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.
  • 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.
  • IP Internet Protocol
  • FIG. 28 is a functional block diagram illustrating an example implementation of an OMMA layer.
  • 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.
  • 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.
  • FIG. 29 is a functional block diagram that depicts an example implementation of an OMMA Controller.
  • 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).
  • the Multi-RAT Multi-Band Device Discovery module 2910 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).
  • the Multi-RAT Multi-Band Device Discovery module 2910 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).
  • the Multi-RAT Multi-Band Device Discovery module 2910 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).
  • 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).
  • 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.
  • GMKSA Multi-RAT Multi-Band Security
  • the OMMA Controller 2900 may comprise a Feedback Device Classifier module
  • 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
  • feedback metrics e.g., a vector comprising a value of serving rate, jitter, packet delay, and packet loss rate on its MAC
  • 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).
  • the OMMA Controller 2900 may comprise a Feedback QoS Classifier module
  • 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).
  • the OMMA Controller 2900 may comprise a RAT Update Management module
  • RAT availability of a device 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.
  • 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).
  • a RAT Capability Database e.g., RAT capability database 2830
  • 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.
  • This arrival rate "x" may be appended with one or more feedback metrics and/or sent to the FBS.
  • 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).
  • the OMMA Controller 2900 may comprise a Fragmentation Controller module
  • the Fragmentation Controller 2980 may make decisions for enabling of fragmentation (e.g., within the OMMA Scheduler) for an incoming 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).
  • the Fragmentation Controller module 2980 may decide to enable or disable fragmentation (e.g., within OMMA scheduler) for a RAT.
  • the Fragmentation Controller module 2980 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.
  • MTU size of that RAT e.g., in case of single RAT selection
  • a minimum MTU size of one or more selected RATs e.g., in case of multiple RAT selection
  • 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).
  • 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.
  • 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.
  • the OMMA scheduler may determine RAT(s) selection.
  • FIG. 30 is a functional block diagram illustrating one example of an OMMA
  • an OMMA Scheduler 3000 may comprise a Policy Based Scheduler (PBS) module 3010.
  • PBS Policy Based Scheduler
  • 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).
  • 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.
  • QoS quality of service
  • 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).
  • feedback metrics e.g., RSSI, medium access delay, etc.
  • 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.
  • RSSI received signal strength indication
  • 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.
  • 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:
  • 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 3 ⁇ 4to tj, where:
  • 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 3 ⁇ 4 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.
  • 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.
  • 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.
  • Serving delay variance may be calculated by:
  • ⁇ 2 may be the serving delay variance
  • X may be the serving delay
  • N' may be the number of samples being used to calculate the serving delay variance
  • Vacation time variance may be calculated by:
  • ⁇ may be the vacation time variance
  • X may be the vacation time
  • N' may be the number of samples being used to calculate the vacation time variance
  • 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.
  • 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.
  • 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).
  • 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
  • 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.
  • the OMMA Scheduler 3000 may comprise an Rx Duplicate Packet
  • a sender may switch RATs, for example, in the case of a single RAT selection at any given time.
  • 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.
  • the OMMA Scheduler 3000 may comprise an Rx Packet Reassembly module
  • 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).
  • 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.
  • an upper module e.g., an Rx Duplicate Packet Detection/Recovery module 3060.
  • the OMMA Scheduler 3000 may comprise an Rx Reordering Buffer module
  • a sender may switch RATs frequently, for example, in the case of a single RAT selection at any given time.
  • 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.
  • 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.
  • 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.
  • the OMMA Scheduler 3000 may comprise an IP Packet QoS Identifier module
  • 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.
  • the OMMA layer may comprise a RAT capability database
  • This 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.
  • 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).
  • 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.
  • the RAT capability database 2830 may store the Maximum Transmission Unit
  • 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.
  • 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.
  • QoS quality of service
  • 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.
  • IP Flow UDP traffic Select RATs such that
  • Location of device e.g.: TVWS channels are Look up TVWS database
  • 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.
  • 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
  • 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.
  • the actions/results may be performed for a specific IP Flow, a specific user's IP
  • 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.
  • 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.
  • 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).
  • OMMA Controller 3160 e.g., RAT Update Management module
  • the OMMA Controller 3160 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).
  • the OMMA Scheduler 3180 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.,
  • 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:
  • 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 ])
  • 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.
  • 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).
  • Multi-RAT fragmentation control at the OMMA layer may be described herein.
  • the OMMA layer may be used for multi-RAT fragmentation control.
  • 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.
  • 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.
  • FIG. 32 is a system diagram illustrating data flow in an example scenario of an
  • 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.
  • 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).
  • certain parameters in signal RAT_Metrics_PBS_A5b 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).
  • 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).
  • FBS Feedback based scheduler
  • 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.
  • 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).
  • a RAT e.g., the best RAT
  • RAT_Metrics_FBS_A5a signal of A5a interface may be modified.
  • 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.
  • 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.
  • RAT 3240 may be currently configured to have packets scheduled over it (e.g., send or receive)
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 34 is a functional block diagram illustrating an example of a transparent
  • 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).
  • RATs e.g., frequently.
  • packets may be received out-of-order for a single IP stream.
  • 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.
  • 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).
  • 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.
  • wireless resources e.g., bandwidth and time duration
  • 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.
  • 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.
  • QoS class e.g., every WTRU and every QoS class
  • 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.
  • QoS quality of service
  • 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.
  • 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.
  • 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.
  • FIG. 37 is a diagram illustrating examples of signals that may be communicated and used between the OMMA controller and the RAT capability database.
  • 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).
  • an associated device e.g., WTRU
  • Database 3710 may communicate a signal STA RAT Capability Update_Al that may be used at both the OMMA Sender and Receiver.
  • the OMMA Controller 3700 e.g., Multi-RAT Multi-Band Device Discovery or RAT Update Management module
  • the OMMA Controller 3700 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.
  • the signal STA RAT Capability Update_Al may be aperiodic.
  • the 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.
  • 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.
  • 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,
  • the array may be an array of RAT _AvailabUity comprising many elements as there are RAT Ids in the RATJd ist (e.g., RA
  • 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.
  • OMMA Controller 3700 e.g., OMMA Mode Management or Fragmentation Controller module
  • the signal STA RAT Capability Query _A1 may be aperiodic.
  • 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.
  • OMMA controller 3700 e.g., OMMA Mode Management or Fragmentation Controller module
  • 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 may comprise specific information regarding WTRU capability, for example, maximum RAT capability, available RATs, MTU size, etc.
  • the signal STA RAT Capability Response_Al may be aperiodic.
  • 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)).
  • 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.
  • 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.
  • 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.
  • the signal Policy _Response_A10 may be aperiodic.
  • 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.
  • 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.
  • the mode e.g., Transparent/Non-Transparent
  • the OMMA Controller 3900 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
  • 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.
  • the 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
  • the signal RAT_Metrics_FBS_A5a may be aperiodic.
  • the OMMA controller 3900 e.g., Feedback WTRU and QoS Classifier module
  • 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.
  • the OMMA Controller 3900 may signal the OMMA Scheduler 3910 about the mode in which it operates.
  • the signal OMMA_Mode_Decision_A9 may be aperiodic.
  • 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.
  • Controller 3900 may send the mode decision for a WTRU, for example, as shown in FIG. 42.
  • the 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
  • the PBS module of the OMMA Scheduler 3910 e.g., where PBS is enabled
  • the signal Frag_Decision_Request_Al 1 may be aperiodic.
  • 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.
  • the 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
  • the signal Fragmentation _Decision _A12 may be aperiodic.
  • 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.
  • 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.
  • the OMMA layer may receive feedback metrics and RAT capability information from a RAT Protocol Stack 4310.
  • the OMMA layer may reserve MAC resources on one or more RATs, for example, based on the requirements.
  • the OMMA Controller 4300 may request to reserve resources (e.g., x bandwidth for a fixed time duration "t") on one or more RATs.
  • 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.
  • the 4310 may communicate a signal System J 3 arameters_A3 that may be used at OMMA sender.
  • the OMMA Controller 4300 e.g., Multi-RAT Multi-Band Device Discovery
  • a RAT e.g., each RAT
  • This information may be used during discovery process to advertise WTRU RAT capability.
  • the signal System_Parameters_A3 may be aperiodic.
  • 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).
  • 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.
  • 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.
  • the signal RAT ⁇ Capabilities _A3 may be aperiodic.
  • the signal RAT ⁇ Capabilities _A3 may be aperiodic.
  • the 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
  • RAT ⁇ Capability (e.g., RATI ⁇ Capability, ...,RATn_Capabilityi).
  • the 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.
  • the signal Mode Jo JController _A3 may be aperiodic.
  • 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,
  • 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.
  • 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.
  • the OMMA Controller 4300 may signal a selected RAT about the mode, for example, which it may transfer in its beacon.
  • 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.
  • Max_RAT_Capabilities_A3 may be used at the OMMA receiver.
  • a device e.g., WTRU
  • 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
  • the OMMA Controller 4300 e.g., Multi-RAT Multi- Band Device Discovery module
  • the signal Max_RAT_Capabilities_A3 may be aperiodic.
  • 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).
  • the OMMA Controller 4300 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.
  • the signal Match _RAT_List_A3 may be aperiodic.
  • 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).
  • the 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.
  • FIG. 44 is a diagram illustrating example feedback metrics that may be sent by a
  • 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.
  • 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.
  • FIG. 45 is a functional block diagram depicting an example interface between an
  • 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.
  • the 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.
  • 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.
  • the 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).
  • the signal STA RAT Capability Response_A4 may be aperiodic.
  • RAT Capability Response_A4 may be generated in response to the signal
  • 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
  • FIG. 46 is a functional block diagram depicting an example interface between an
  • 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.
  • the predefined policies/rules e.g., the policies/rules described herein
  • 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.
  • 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.
  • 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.
  • the signal Policy _Response_A6 may be aperiodic.
  • 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.
  • modules may communicate with each other.
  • FIG. 1
  • 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.
  • 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.
  • 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).
  • the signal RAT_Selection_Decision_A7 may be aperiodic.
  • the signal RAT_Selection_Decision_A7 may be aperiodic.
  • 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].
  • FIG. 48 is a functional block diagram depicting an example interface between an
  • 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.
  • 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.
  • 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.
  • 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.
  • a token for each domain name may be defined in the policy database.
  • 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.
  • 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.
  • UI-APP user interface application
  • a user of a device e.g., a WTRU
  • 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.
  • 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.
  • FIG. 51 is a diagram illustrating an example of Multi-RAT Aggregation using
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Packet scheduling of IP traffic over multiple RATs 51 10 may be performed by the
  • 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.).
  • NTs network terminals
  • APs access points
  • AP Wi-Fi access point
  • eNodeB eNodeB
  • 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.
  • 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.
  • 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.
  • 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.
  • a system may comprise multiple WTRUs, a single NT, and multiple IP flows from the NT to one or more of the WTRUs.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Traffic shaping implementations at the OMMA layer 5100 to improve the system performance with TCP traffic may be described herein.
  • 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.
  • 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.
  • 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.
  • 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.
  • an OMMA layer 5100 may reside as a layer between RAT protocol stacks and the IP layer 5120.
  • the feedback metrics disclosed herein may be a service access point (SAP) between a RAT and the OMMA layer 5100.
  • SAP service access point
  • the OMMA layer 5100 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.
  • a common gateway e.g. , 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • FCFS first-come first-served
  • Rate R may reflect the quality of channel i and may be fed back from a RAT
  • 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 3 ⁇ 4. This may minimize average end-to-end latency per packet and/or maximum throughput.
  • the x (e.g., which may be an optimal x- ) may be expressed as:
  • R may be the average serving rate of a RAT
  • 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
  • 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.
  • channel contention process e.g., CSMA/CA
  • T may be counted as the total time duration that a MAC layer associated with a
  • T may include a retransmission delay if a packet needs to be retransmitted.
  • a MAC queuing delay may not be included in T
  • 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.
  • 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.
  • the OMMA layer may rely on the value of total arrival rate x and the value of ? 1 H2 — Ri ( e -g- > assuming Ri > R 2 ), for example, to adaptively decide the operation mode. For example, when 0 ⁇ x ⁇ J ? 1 i? 2 — ⁇ 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 ? 1 i? 2 — ff 2 ⁇ x ⁇ R 1 + R 2 , 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.
  • Packet assignment for multi-WTRU multi-IP flow may be described herein.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the average system delay across K RATs that may be minimized may be:
  • the arrival rate packets for RAT j may be:
  • 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.
  • a RAT e.g., as in Table 6
  • 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.
  • 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.
  • packets of the main stream may be split into multiple sub streams for transmission over different links, which may have different latencies.
  • the OMMA layer at the receiver 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.
  • the packet Upon reception, the packet may be given an index n + ⁇ , where ⁇ G ⁇ -N+l,..., N-2, N-l ⁇ may be the ordering 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.
  • 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).
  • 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.
  • QoS of real-time UDP applications 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.
  • packets out of order may generate a duplicate ACK issue, which may trigger unnecessary congestion control that may reduce end to end throughput.
  • a potential cause may be placing packets with a higher ID in a shorter queue
  • 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.
  • 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
  • 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
  • the OMMA layer may perform a method of aggregating bandwidth available on multiple radio access technologies (RATs), for example, using a leaky bucket implementation.
  • RATs radio access technologies
  • 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.
  • the OMMA layer may perform a method of aggregating bandwidth available on multiple radio access technologies (RATs), for example, using a leaky bucket implementation.
  • 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.
  • 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.
  • 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.
  • the OMMA layer may analyze the TCP header of an incoming packet to identify the beginning and/or the end of each TCP connection.
  • the OMMA layer may route traffic to send over a single RAT (e.g., single 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.
  • 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.
  • 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.
  • a short period of time e.g., a few milliseconds
  • 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.
  • 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)).
  • FBSs Feedback Based Schedulers
  • 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.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • RAT_Id which may provide the RAT Ids of the enabled RATs
  • STA_Addr which may provide
  • the FBS may distribute incoming
  • IP packets across the selected RATs e.g., optimally
  • 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.
  • 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).
  • 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
  • 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).
  • 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.
  • a RAT switch may occur when a selected RAT is unable to fulfill a requirement of given IP flow QoS Class.
  • FBS 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.
  • 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).
  • 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.
  • 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
  • FIG. 59 is a diagram illustrating an example call flow comprising one or more of the implementations described herein.
  • a node e.g., a NT or a WTRU
  • 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.
  • 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.
  • 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).
  • the IP flow may be associated with a single application.
  • 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.
  • the controller may be configured to request resources on the one or more RATs.
  • 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.
  • the scheduler may be configured to receive feedback information associated with the one or more RATs.
  • 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).
  • 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.
  • 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.
  • 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.
  • the OMMA layer may receive a first IP packet via a first RAT, and receive a second IP packet via a second RAT.
  • the first RAT may be associated with a first license exempt (LE) band channel
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • ROM read only memory
  • RAM random access memory
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne des systèmes, des procédés et des instruments qui permettent de gérer de multiples interfaces de technologie d'accès radio (RAT) pour permettre une sélection et une agrégation de RAT opportunistes afin d'envoyer un trafic de données sur les multiples interfaces RAT. Un système de sélection d'une RAT peut comprendre une couche de protocole Internet (IP) et des piles de protocole RAT résidant sous la couche IP. Une couche d'agrégation de commande d'accès aux supports multiples opportuniste (OMMA) peut résider entre la couche IP et les piles de protocole RAT. La couche OMMA peut comprendre un dispositif planificateur OMMA qui peut distribuer des paquets de données IP entrants parmi les piles de protocole RAT. Un dispositif de commande OMMA peut communiquer un paramètre de commande au dispositif planificateur OMMA pour sélectionner une pile de protocole RAT afin de distribuer un paquet de données IP entrant. Une base de données de capacité RAT d'unité d'émission/réception sans fil peut stocker des informations de capacité RAT. Une base de données de politiques peut stocker une politique afin de distribuer les paquets de données IP parmi les piles de protocole RAT.
PCT/US2013/027541 2012-02-24 2013-02-24 Sélection et agrégation de technologie d'accès radio opportunistes WO2013126859A2 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201261603004P 2012-02-24 2012-02-24
US61/603,004 2012-02-24
US201261676121P 2012-07-26 2012-07-26
US61/676,121 2012-07-26
US201261678060P 2012-07-31 2012-07-31
US61/678,060 2012-07-31

Publications (2)

Publication Number Publication Date
WO2013126859A2 true WO2013126859A2 (fr) 2013-08-29
WO2013126859A3 WO2013126859A3 (fr) 2013-11-07

Family

ID=47884530

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/027541 WO2013126859A2 (fr) 2012-02-24 2013-02-24 Sélection et agrégation de technologie d'accès radio opportunistes

Country Status (2)

Country Link
TW (1) TW201349897A (fr)
WO (1) WO2013126859A2 (fr)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015138079A1 (fr) * 2014-03-13 2015-09-17 Intel IP Corporation Procédé amélioré pour le transfert d'informations de capacité radio
CN104980985A (zh) * 2014-04-14 2015-10-14 美国博通公司 在多网络环境中分隔并再结合通信的系统和方法
US9237448B2 (en) 2012-08-15 2016-01-12 Interdigital Patent Holdings, Inc. Enhancements to enable fast security setup
CN105307278A (zh) * 2014-06-06 2016-02-03 财团法人工业技术研究院 基站与无线网络调度方法
WO2016130146A1 (fr) * 2015-02-13 2016-08-18 Nokia Technologies Oy Planification de liaison montante avec une agrégation de réseau local sans fil (wlan)/de projet de partenariat de troisième génération (3gpp)
EP3079439A1 (fr) * 2015-04-10 2016-10-12 Alcatel Lucent Procédé dans un réseau de télécommunication sans fil, dispositif d'équipement utilisateur et noeud de réseau
WO2017011026A1 (fr) * 2015-07-13 2017-01-19 Intel Corporation Fractionnement de porteuse
CN106571901A (zh) * 2015-10-13 2017-04-19 华为技术有限公司 媒体接入控制实体创建的方法、设备及系统
WO2017124941A1 (fr) * 2016-01-20 2017-07-27 华为技术有限公司 Procédé de transmission de données, équipement utilisateur et station de base
US9844065B2 (en) 2015-06-30 2017-12-12 Qualcomm Incorporated Optimizing the reach of a message beacon device
CN107535005A (zh) * 2015-05-05 2018-01-02 高通股份有限公司 用于动态敏感度控制的技术
US9888422B2 (en) 2013-06-03 2018-02-06 Avago Technologies General Ip (Singapore) Pte. Ltd. System and method for adaptive access and handover configuration based on prior history in a multi-RAT environment
WO2018029537A1 (fr) * 2016-08-12 2018-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Sélection de liaison dynamique
US9907006B2 (en) 2013-06-03 2018-02-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Cross radio access technology access with handoff and interference management using communication performance data
WO2018127622A1 (fr) 2017-01-05 2018-07-12 Nokia Technologies Oy Indicateur de performance pour l'interfonctionnement de technologies d'accès radio
EP3383075A1 (fr) * 2017-03-30 2018-10-03 LG Electronics Inc. Appareil de communication pour véhicule
KR20180111452A (ko) * 2017-03-30 2018-10-11 엘지전자 주식회사 차량용 통신 장치 및 차량
WO2018202933A1 (fr) * 2017-05-02 2018-11-08 Nokia Solutions And Networks Oy Amélioration de la fiabilité de communication
EP3504898A4 (fr) * 2016-11-03 2019-07-10 Samsung Electronics Co., Ltd. Procédé et appareil pour une communication utilisant une bande autorisée et une bande non autorisée
JP2020504510A (ja) * 2017-01-05 2020-02-06 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 移動通信システムにおいて無線リンクを選択する方法および装置
DE102018222139A1 (de) * 2018-12-18 2020-06-18 Continental Automotive Gmbh Telematik-Steuergerät mit Dispatcher für "Always On" Funkverbindungen
US12075470B2 (en) * 2019-05-08 2024-08-27 Tencent Technology (Shenzhen) Company Limited Data transmission method and apparatus, method and apparatus for creating access category, and storage medium

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3095733B1 (fr) * 2019-04-30 2021-10-22 Renault Sas Systeme et procede de gestion de communication v2x entre un vehicule et un dispositif recepteur

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100062800A1 (en) * 2008-09-08 2010-03-11 Agere Systems Inc. Wireless communications using multiple radio access technologies simultaneously
KR20120062788A (ko) * 2009-08-21 2012-06-14 인터디지탈 패튼 홀딩스, 인크 상이한 무선 액세스 기술들에 대해 다운링크 업링크를 분리하기 위한 멀티 무선 액세스 기술 계층에 대한 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9743280B2 (en) 2012-08-15 2017-08-22 Interdigital Patent Holdings, Inc. Enhancements to enable fast security setup
US9237448B2 (en) 2012-08-15 2016-01-12 Interdigital Patent Holdings, Inc. Enhancements to enable fast security setup
US9907006B2 (en) 2013-06-03 2018-02-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Cross radio access technology access with handoff and interference management using communication performance data
US9888422B2 (en) 2013-06-03 2018-02-06 Avago Technologies General Ip (Singapore) Pte. Ltd. System and method for adaptive access and handover configuration based on prior history in a multi-RAT environment
US11350348B2 (en) 2014-03-13 2022-05-31 Intel Corporation Method for the transfer of radio capability information
TWI646854B (zh) * 2014-03-13 2019-01-01 英特爾智財公司 無線電能力資訊之移轉的改善方法
US10660029B2 (en) 2014-03-13 2020-05-19 Intel IP Corporation Method for the transfer of radio capability information
AU2018202695B2 (en) * 2014-03-13 2019-06-06 Intel Corporation Improved method for the transfer of radio capability information
TWI556672B (zh) * 2014-03-13 2016-11-01 英特爾智財公司 無線電能力資訊之移轉的改善方法
WO2015138079A1 (fr) * 2014-03-13 2015-09-17 Intel IP Corporation Procédé amélioré pour le transfert d'informations de capacité radio
JP2017509234A (ja) * 2014-03-13 2017-03-30 インテル アイピー コーポレイション 無線能力情報の転送のための改良された方法
AU2015229969B2 (en) * 2014-03-13 2018-01-18 Intel Corporation Improved method for the transfer of radio capability information
US11071052B2 (en) 2014-03-13 2021-07-20 Intel Corporation Method for the transfer of radio capability information
JP2017216754A (ja) * 2014-03-13 2017-12-07 インテル アイピー コーポレイション 無線能力情報の転送のための改良された方法
CN104980985A (zh) * 2014-04-14 2015-10-14 美国博通公司 在多网络环境中分隔并再结合通信的系统和方法
EP2934045A1 (fr) * 2014-04-14 2015-10-21 Broadcom Corporation Systèmes et procédés de séparation et de recombinaison de communications dans des environnements à réseaux multiples
US9999098B2 (en) 2014-06-06 2018-06-12 Industrial Technology Research Institute Base station and scheduling method for wireless network
CN105307278A (zh) * 2014-06-06 2016-02-03 财团法人工业技术研究院 基站与无线网络调度方法
CN107211317B (zh) * 2015-02-13 2021-04-06 诺基亚技术有限公司 利用wlan/3gpp聚合的上行链路调度
WO2016130146A1 (fr) * 2015-02-13 2016-08-18 Nokia Technologies Oy Planification de liaison montante avec une agrégation de réseau local sans fil (wlan)/de projet de partenariat de troisième génération (3gpp)
US20180035443A1 (en) * 2015-02-13 2018-02-01 Nokia Technologies Oy Uplink scheduling with wlan/3gpp aggregation
CN107211317A (zh) * 2015-02-13 2017-09-26 诺基亚技术有限公司 利用wlan/3gpp聚合的上行链路调度
US10966221B2 (en) 2015-02-13 2021-03-30 Nokia Technologies Oy Uplink scheduling with WLAN/3GPP aggregation
EP3079439A1 (fr) * 2015-04-10 2016-10-12 Alcatel Lucent Procédé dans un réseau de télécommunication sans fil, dispositif d'équipement utilisateur et noeud de réseau
WO2016162458A1 (fr) * 2015-04-10 2016-10-13 Alcatel Lucent Procédé dans un réseau de télécommunication sans fil, dispositif d'équipement d'utilisateur et nœud de réseau
CN107535005A (zh) * 2015-05-05 2018-01-02 高通股份有限公司 用于动态敏感度控制的技术
US9844065B2 (en) 2015-06-30 2017-12-12 Qualcomm Incorporated Optimizing the reach of a message beacon device
WO2017011026A1 (fr) * 2015-07-13 2017-01-19 Intel Corporation Fractionnement de porteuse
EP3355508A4 (fr) * 2015-10-13 2018-10-17 Huawei Technologies Co., Ltd. Procédé, équipement, et système de création d'entité de commande d'accès au support
CN106571901A (zh) * 2015-10-13 2017-04-19 华为技术有限公司 媒体接入控制实体创建的方法、设备及系统
CN106571901B (zh) * 2015-10-13 2020-03-27 华为技术有限公司 媒体接入控制实体创建的方法、设备及系统
WO2017124941A1 (fr) * 2016-01-20 2017-07-27 华为技术有限公司 Procédé de transmission de données, équipement utilisateur et station de base
US10778375B2 (en) 2016-01-20 2020-09-15 Huawei Technologies Co., Ltd. Data transmission method, user equipment, and base station
US11695515B2 (en) 2016-01-20 2023-07-04 Huawei Technologies Co., Ltd. Data transmission method, user equipment, and base station
CN109792635A (zh) * 2016-08-12 2019-05-21 瑞典爱立信有限公司 动态链路选择
US11304088B2 (en) 2016-08-12 2022-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic link selection
US11825338B2 (en) 2016-08-12 2023-11-21 Telefonaktiabolaget Lm Ericsson (Publ) Dynamic link selection
WO2018029537A1 (fr) * 2016-08-12 2018-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Sélection de liaison dynamique
EP3498042A1 (fr) * 2016-08-12 2019-06-19 Telefonaktiebolaget LM Ericsson (publ) Sélection de liaison dynamique
RU2721755C1 (ru) * 2016-08-12 2020-05-21 Телефонактиеболагет Лм Эрикссон (Пабл) Динамический выбор линии связи
US20220210692A1 (en) * 2016-08-12 2022-06-30 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic link selection
JP2019528021A (ja) * 2016-08-12 2019-10-03 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 動的リンク選択
EP3504898A4 (fr) * 2016-11-03 2019-07-10 Samsung Electronics Co., Ltd. Procédé et appareil pour une communication utilisant une bande autorisée et une bande non autorisée
US10674368B2 (en) 2016-11-03 2020-06-02 Samsung Electronics Co., Ltd. Method and apparatus for communication using licensed band and unlicensed band
WO2018127622A1 (fr) 2017-01-05 2018-07-12 Nokia Technologies Oy Indicateur de performance pour l'interfonctionnement de technologies d'accès radio
US11356942B2 (en) 2017-01-05 2022-06-07 Panasonic Intellectual Property Corporation Of America Methods and apparatuses for selecting a radio link in a mobile communication system
US10959235B2 (en) 2017-01-05 2021-03-23 Nokia Technologies Oy Performance indicator for interworking radio access technologies
CN110383871A (zh) * 2017-01-05 2019-10-25 诺基亚技术有限公司 用于无线电接入技术互通的性能指示符
JP2020504510A (ja) * 2017-01-05 2020-02-06 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 移動通信システムにおいて無線リンクを選択する方法および装置
EP3566485A4 (fr) * 2017-01-05 2020-08-19 Nokia Technologies Oy Indicateur de performance pour l'interfonctionnement de technologies d'accès radio
JP7046071B2 (ja) 2017-01-05 2022-04-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ ユーザ機器、方法および第１の基地局
EP3383075A1 (fr) * 2017-03-30 2018-10-03 LG Electronics Inc. Appareil de communication pour véhicule
KR20180111452A (ko) * 2017-03-30 2018-10-11 엘지전자 주식회사 차량용 통신 장치 및 차량
US10743158B2 (en) 2017-03-30 2020-08-11 Lg Electronics Inc. Communication apparatus for vehicle and vehicle
KR102431044B1 (ko) * 2017-03-30 2022-08-09 엘지전자 주식회사 차량용 통신 장치 및 차량
CN108712733A (zh) * 2017-03-30 2018-10-26 Lg电子株式会社 用于车辆的通信设备和车辆
WO2018202933A1 (fr) * 2017-05-02 2018-11-08 Nokia Solutions And Networks Oy Amélioration de la fiabilité de communication
US10973071B2 (en) 2017-05-02 2021-04-06 Nokia Solutions And Networks Oy Improving communication reliability
DE102018222139A1 (de) * 2018-12-18 2020-06-18 Continental Automotive Gmbh Telematik-Steuergerät mit Dispatcher für "Always On" Funkverbindungen
US12075470B2 (en) * 2019-05-08 2024-08-27 Tencent Technology (Shenzhen) Company Limited Data transmission method and apparatus, method and apparatus for creating access category, and storage medium

Also Published As

Publication number Publication date
TW201349897A (zh) 2013-12-01
WO2013126859A3 (fr) 2013-11-07

Similar Documents

Publication Publication Date Title
WO2013126859A2 (fr) Sélection et agrégation de technologie d'accès radio opportunistes
JP5986244B2 (ja) チャネルアグリゲーションおよび媒体アクセス制御再送信を実行するための方法および装置
US20240323922A1 (en) Systems and methods for sidelink communication
JP6286588B2 (ja) ビデオアウェアの（ｖｉｄｅｏ ａｗａｒｅ）ハイブリッド自動再送要求のための方法および装置
TWI600297B (zh) 用於多重無線電異質網路中之承載體分流的系統、方法與設備
JP5731714B2 (ja) 帯域間キャリアアグリゲーション
US8891438B2 (en) Packet-data network and methods for RAN-agnostic multimedia content distribution
WO2015138914A1 (fr) Procédé et appareil destinés aux opérations de mailles bibandes
JP2013502850A (ja) 相異なる無線アクセス技術にわたってダウンリンク−アップリンクを分割するマルチ無線アクセス技術レイヤのための方法および装置
US20150312933A1 (en) Transmitting radio node and method therein for scheduling service data flows
CN115804146A (zh) 多链路装置之间的低时延数据的无线通信的方法和设备
EP3252978A1 (fr) Dispositifs, procédés et programmes informatiques permettant de transmettre ou de recevoir des données de charge utile et des données de récupération de charge utile
US20230209591A1 (en) Systems and methods for prioritizing bi-directional traffic flows
WO2015171759A1 (fr) Gestion de spectre pour une priorité d'accès dans un réseau à plusieurs niveaux
US11153891B2 (en) Method for scheduling data by network node aggregated with LTE and Wi-Fi protocol stacks
WO2024206805A1 (fr) Unités de transmission/réception sans fil associées à une transmission fiable d'ensembles de pdu
WO2024206798A1 (fr) Dispositifs de réseau associés à une transmission fiable d'ensembles de pdu
WO2024173574A1 (fr) Procédé et appareil de rapport d'état de tampon pour des données à trajets multiples
WO2024173510A1 (fr) Bsr pour supports flexibles/relayés pour unité(s) d'émission/réception sans fil en mode 1 en trajet multiple

Legal Events

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

Ref document number: 13709636

Country of ref document: EP

Kind code of ref document: A2

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase

Ref document number: 13709636

Country of ref document: EP

Kind code of ref document: A2