US20100103865A1 - Header compression for cell relay communications - Google Patents
Header compression for cell relay communications Download PDFInfo
- Publication number
- US20100103865A1 US20100103865A1 US12/605,184 US60518409A US2010103865A1 US 20100103865 A1 US20100103865 A1 US 20100103865A1 US 60518409 A US60518409 A US 60518409A US 2010103865 A1 US2010103865 A1 US 2010103865A1
- Authority
- US
- United States
- Prior art keywords
- header
- packet
- identifier
- rohc
- tunneling protocol
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
- 238000004891 communication Methods 0.000 title claims abstract description 182
- 230000006835 compression Effects 0.000 title claims abstract description 40
- 238000007906 compression Methods 0.000 title claims abstract description 40
- 230000005641 tunneling Effects 0.000 claims abstract description 90
- 238000000034 method Methods 0.000 claims abstract description 66
- 238000011144 upstream manufacturing Methods 0.000 claims abstract description 20
- 238000004590 computer program Methods 0.000 claims description 21
- 238000013519 translation Methods 0.000 claims description 9
- 230000004044 response Effects 0.000 claims description 7
- 239000000284 extract Substances 0.000 claims description 3
- 230000006870 function Effects 0.000 description 13
- 230000002441 reversible effect Effects 0.000 description 13
- 238000005516 engineering process Methods 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 9
- 230000000875 corresponding effect Effects 0.000 description 9
- 230000006837 decompression Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 9
- 230000009471 action Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000001143 conditioned effect Effects 0.000 description 3
- 239000011159 matrix material Substances 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000010363 phase shift Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 229920001690 polydopamine Polymers 0.000 description 1
- 238000004353 relayed correlation spectroscopy Methods 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
- H04W28/0263—Traffic management, e.g. flow control or congestion control per individual bearer or channel involving mapping traffic to individual bearers or channels, e.g. traffic flow template [TFT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0055—Transmission or use of information for re-establishing the radio link
- H04W36/0072—Transmission or use of information for re-establishing the radio link of resource information of target access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/22—Manipulation of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
- H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/155—Ground-based stations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2212/00—Encapsulation of packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
- H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
Definitions
- the following description relates generally to wireless communications, and more particularly to compressing protocol headers in communicating using cell relays.
- Wireless communication systems are widely deployed to provide various types of communication content such as, for example, voice, data, and so on.
- Typical wireless communication systems may be multiple-access systems capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, . . . ).
- multiple-access systems may include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and the like.
- CDMA code division multiple access
- TDMA time division multiple access
- FDMA frequency division multiple access
- OFDMA orthogonal frequency division multiple access
- the systems can conform to specifications such as third generation partnership project (3GPP), 3GPP long term evolution (LTE), ultra mobile broadband (UMB), and/or multi-carrier wireless specifications such as evolution data optimized (EV-DO), one or more revisions thereof, etc.
- 3GPP third generation partnership project
- LTE 3GPP long term evolution
- UMB ultra mobile broadband
- wireless multiple-access communication systems may simultaneously support communication for multiple mobile devices.
- Each mobile device may communicate with one or more access points (e.g., base stations) via transmissions on forward and reverse links.
- the forward link (or downlink) refers to the communication link from access points to mobile devices
- the reverse link (or uplink) refers to the communication link from mobile devices to access points.
- communications between mobile devices and access points may be established via single-input single-output (SISO) systems, multiple-input single-output (MISO) systems, multiple-input multiple-output (MIMO) systems, and so forth.
- SISO single-input single-output
- MISO multiple-input single-output
- MIMO multiple-input multiple-output
- Access points can be limited in geographic coverage area as well as resources such that mobile devices near edges of coverage and/or devices in areas of high traffic can experience degraded quality of communications from an access point.
- Cell relays can be provided to expand network capacity and coverage area by facilitating communication between mobile devices and access points.
- a cell relay can establish a backhaul link with a donor access point, which can provide access to a number of cell relays, and the cell relay can establish an access link with one or more mobile devices or additional cell relays.
- communication interfaces such as S1-U, can terminate at the donor access point.
- the donor access point appears as a normal access point to backend network components.
- the donor access point can route packets from the backend network components to the cell relays for communicating to the mobile devices.
- robust header compression (RoHC) contexts for multiple evolved packet system (EPS) bearers can be supported over a single dedicated radio bearer of a cell relay.
- EPS evolved packet system
- a single robust header compressor can be provided at one communication node and a single robust header decompressor at the other in relay communications.
- the multiple RoHC contexts for the given EPS bearers can be differentiated according to assigned context identifiers.
- multiple robust header compressors/decompressors can be provided at the communication nodes for each RoHC context, and a tunnel endpoint identifier (TEID) or similar identifier related to the EPS bearers (or corresponding UE bearers) can be utilized to differentiate EPS bearers at the nodes.
- TEID tunnel endpoint identifier
- a donor eNB can compress a tunneling protocol header in a packet received from an upstream network node for downstream communication of the packet.
- a method includes receiving a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a dedicated radio bearer (DRB). The method also includes determining a RoHC context for the RoHC compressed header and decompressing the RoHC compressed header based at least in part on the RoHC context.
- DRB dedicated radio bearer
- the wireless communications apparatus can include at least one processor configured to obtain a packet with a RoHC compressed header from one of a plurality of EPS bearers mapped to a DRB of the wireless communications apparatus and discern a RoHC context used for compression of the RoHC compressed header.
- the at least one processor is further configured to discern a RoHC context used for compression of the RoHC compressed header.
- the wireless communications apparatus also comprises a memory coupled to the at least one processor.
- the apparatus includes means for receiving a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB and means for determining a RoHC context for the RoHC compressed header.
- the apparatus also includes means for decompressing the RoHC compressed header based at least in part on the RoHC context.
- Still another aspect relates to a computer program product, which can have a computer-readable medium including code for causing at least one computer to receive a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB and code for causing the at least one computer to determine a RoHC context for the RoHC compressed header.
- the computer-readable medium can also comprise code for causing the at least one computer to decompress the RoHC compressed header based at least in part on the RoHC context.
- an additional aspect relates to an apparatus including a bearer communicating component that receives a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB.
- the apparatus can further include a RoHC context determining component that discerns a RoHC context for the RoHC compressed header and a RoHC decompressing component that decompresses the RoHC compressed header based at least in part on the RoHC context.
- a method in another aspect, includes compressing a header of a packet received over an EPS bearer using RoHC based at least in part on a RoHC context and indicating an identifier related to the RoHC context in the packet. The method further includes transmitting the packet over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- the wireless communications apparatus can include at least one processor configured to compress a header of a packet received over an EPS bearer based at least in part on a selected RoHC context and specify an identifier related to the selected RoHC context in the packet.
- the at least one processor is further configured to communicate the packet over a DRB to which the EPS bearer and one or more disparate EPS bearers in a core network are mapped.
- the wireless communications apparatus also comprises a memory coupled to the at least one processor.
- the apparatus includes means for compressing a header of a packet received over an EPS bearer based at least in part on a RoHC context and means for indicating an identifier related to the RoHC context in the packet.
- the apparatus also includes means for transmitting the header over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- Still another aspect relates to a computer program product, which can have a computer-readable medium including code for causing at least one computer to compress a header of a packet received over an EPS bearer using RoHC based at least in part on a RoHC context and code for causing the at least one computer to indicate an identifier related to the RoHC context in the packet.
- the computer-readable medium can also comprise code for causing the at least one computer to transmit the packet over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- an additional aspect relates to an apparatus including a RoHC compressing component that compresses a header of a packet received over an EPS bearer using RoHC based at least in part on a RoHC context.
- the apparatus can further include a context identifying component that specifies an identifier related to the RoHC context in the packet and a bearer communicating component that transmits the header over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- a method includes receiving a packet from an upstream node comprising a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header.
- the method further includes compressing a header of the packet to include a compressed SGW IP address and transmitting the packet with the compressed header to a downstream node.
- UDP user datagram protocol
- IP internet protocol
- GPRS general packet radio service tunneling protocol
- the wireless communications apparatus can include at least one processor configured to obtain a packet from an upstream node comprising a UDP, IP, or GTP header and associate a compressed header with the packet that includes a compressed SGW IP address.
- the at least one processor is further configured to transmit the packet with the compressed header to a downstream node.
- the wireless communications apparatus also comprises a memory coupled to the at least one processor.
- the apparatus includes means for receiving a packet from an upstream node comprising a UDP, IP, or GTP header and means for applying compression to a header of the packet to compress at least an SGW IP address.
- the apparatus also includes means for transmitting the packet with the compressed header to a downstream node.
- Still another aspect relates to a computer program product, which can have a computer-readable medium including code for causing at least one computer to receive a packet from an upstream node comprising a UDP, IP, or GTP header.
- the computer-readable medium can also comprise code for causing the at least one computer to compress a header of the packet to include a compressed SGW IP address and code for causing the at least one computer to transmit the packet with the compressed header to a downstream node.
- an additional aspect relates to an apparatus including an IP packet receiving component that receives a packet from an upstream node comprising a UDP, IP, or GTP header and a header compressing component compresses a header of the packet at least in part by compressing an SGW IP address in the header.
- the apparatus can further include a bearer communicating component that transmits the packet with the compressed header to a downstream node.
- the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims.
- the following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed and this description is intended to include all such aspects and their equivalents.
- FIG. 1 is an illustration of an example wireless communications system that facilitates providing relays for wireless networks.
- FIG. 2 is an illustration of an example wireless communications system that facilitates compressing headers for cell relay communication using robust header compression (RoHC).
- RoHC robust header compression
- FIG. 3 is an illustration of an example wireless communications system that communicates packets with RoHC compressed header for multiple EPS bearers over a single dedicated radio bearer (DRB).
- DRB dedicated radio bearer
- FIG. 4 is an illustration of an example wireless communications system that facilitates compressing headers using a RoHC context that corresponds to a downstream bearer identifier.
- FIG. 5 is an illustration of an example wireless communications system that communicates packets with RoHC headers compressed according to a RoHC context that corresponds to a downstream bearer identifier.
- FIG. 6 is an illustration of an example wireless communications system that encapsulates RoHC compressed packets for subsequent routing.
- FIG. 7 is an illustration of an example wireless communications system that utilizes cell relays to provide access to a wireless network.
- FIG. 8 is an illustration of example protocol stacks that facilitate providing cell relay functionality for data plane communications.
- FIG. 9 is an illustration of example protocol stacks that facilitate providing cell relay functionality for data plane communications using a relay protocol.
- FIG. 10 is an illustration of an example methodology for decompressing a RoHC compressed header based on a determined RoHC context.
- FIG. 11 is an illustration of an example methodology that compresses one or more packet headers using a RoHC context.
- FIG. 12 is an illustration of an example methodology that encapsulates a packet for subsequent routing.
- FIG. 13 is an illustration of an example methodology that determines an encapsulation for a received packet.
- FIG. 14 is an illustration of an example methodology that compresses a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header of a received packet.
- UDP user datagram protocol
- IP internet protocol
- GPRS general packet radio service tunneling protocol
- FIG. 15 is an illustration of a wireless communication system in accordance with various aspects set forth herein.
- FIG. 16 is an illustration of an example wireless network environment that can be employed in conjunction with the various systems and methods described herein.
- FIG. 17 is an illustration of an example system that facilitates decompressing a RoHC compressed header based on a determined RoHC context.
- FIG. 18 is an illustration of an example system that facilitates compressing a header according to a RoHC context.
- FIG. 19 is an illustration of an example system that facilitates compressing a UDP, IP, or GTP header.
- a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
- an application running on a computing device and the computing device can be a component.
- One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
- these components can execute from various computer readable media having various data structures stored thereon.
- the components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal.
- a terminal can be a wired terminal or a wireless terminal
- a terminal can also be called a system, device, subscriber unit, subscriber station, mobile station, mobile, mobile device, remote station, remote terminal, access terminal, user terminal, terminal, communication device, user agent, user device, or user equipment (UE).
- a wireless terminal may be a cellular telephone, a satellite phone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, a computing device, or other processing devices connected to a wireless modem.
- SIP Session Initiation Protocol
- WLL wireless local loop
- PDA personal digital assistant
- a base station may be utilized for communicating with wireless terminal(s) and may also be referred to as an access point, a Node B, evolved Node B (eNB), or some other terminology.
- the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from the context, the phrase “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, the phrase “X employs A or B” is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B.
- the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from the context to be directed to a singular form.
- a CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), cdma2000, etc.
- UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA.
- W-CDMA Wideband-CDMA
- cdma2000 covers IS-2000, IS-95 and IS-856 standards.
- GSM Global System for Mobile Communications
- An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc.
- E-UTRA Evolved UTRA
- UMB Ultra Mobile Broadband
- IEEE 802.11 Wi-Fi
- WiMAX IEEE 802.16
- Flash-OFDM Flash-OFDM
- UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS).
- UMTS Universal Mobile Telecommunication System
- 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink.
- UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP).
- cdma2000 and UMB are described in documents from an organization named “3rd Generation Partnership Project 2” (3GPP2).
- 3GPP2 3rd Generation Partnership Project 2
- such wireless communication systems may additionally include peer-to-peer (e.g., mobile-to-mobile) ad hoc network systems often using unpaired unlicensed spectrums, 802.xx wireless LAN, BLUETOOTH and any other short- or long-range, wireless communication techniques.
- System 100 includes a donor eNB 102 that provides one or more relay eNBs, such as relay eNB 104 , with access to a core network 106 .
- relay eNB 104 can provide one or more disparate relay eNBs, such as relay eNB 108 , or UEs, such as UE 110 , with access to the core network 106 via donor eNB 102 .
- Donor eNB 102 which can also be referred to as a cluster eNB, can communicate with the core network 106 over a wired or wireless backhaul link, which can be an LTE or other technology backhaul link.
- the core network 106 can be a 3GPP LTE or similar technology network.
- Donor eNB 102 can additionally provide an access link for relay eNB 104 , which can also be wired or wireless, LTE or other technologies, and the relay eNB 104 can communicate with the donor eNB 102 using a backhaul link over the access link of the donor eNB 102 .
- Relay eNB 104 can similarly provide an access link for relay eNB 108 and/or UE 110 , which can be a wired or wireless LTE or other technology link.
- donor eNB 102 can provide an LTE access link, to which relay eNB 104 can connect using an LTE backhaul, and relay eNB 104 can provide an LTE access link to relay eNB 108 and/or UE 110 .
- Donor eNB 102 can connect to the core network 106 over a disparate backhaul link technology.
- Relay eNB 108 and/or UE 110 can connect to the relay eNB 104 using the LTE access link to receive access to core network 106 , as described.
- a donor eNB and connected relay eNBs can be collectively referred to herein as a cluster.
- relay eNB 104 can connect to a donor eNB 102 at the link layer (e.g., media access control (MAC) layer) as would a UE in regular LTE configurations.
- donor eNB 102 can be a regular LTE eNB requiring no changes at the link layer or related interface (e.g., E-UTRA-Uu) to support the relay eNB 104 .
- relay eNB 104 can appear to UE 110 as a regular eNB at the link layer, such that no changes are required for UE 110 to connect to relay eNB 104 at the link layer, for example.
- relay eNB 104 can configure procedures for resource partitioning between access and backhaul link, interference management, idle mode cell selection for a cluster, and/or the like.
- transport protocols related to relay eNB 108 or UE 110 communications can terminate at the donor eNB 102 , referred to as cell relay functionality, since the relay eNB 104 is like a cell of the donor eNB 102 .
- donor eNB 102 can receive communications for the relay eNB 104 from the core network 106 , terminate the transport protocol, and forward the communications to the relay eNB 104 over a disparate transport layer keeping the application layer substantially intact.
- the forwarding transport protocol type can be the same as the terminated transport protocol type, but is a different transport layer established with the relay eNB 104 .
- Relay eNB 104 can determine a relay eNB or UE related to the communications, and provide the communications to the relay eNB or UE (e.g., based on an identifier thereof within the communications). Similarly, donor eNB 102 can terminate the transport layer protocol for communications received from relay eNB 104 , translate the communications to a disparate transport protocol, and transmit the communications over the disparate transport protocol to the core network 106 with the application layer intact for relay eNB 104 as a cell relay. In these examples, where relay eNB 104 is communicating with another relay eNB, the relay eNB 104 can support application protocol routing to ensure communications reach the correct relay eNB.
- application layer protocols can terminate at upstream eNBs.
- application layer protocols for relay eNB 108 and UE 110 can terminate at relay eNB 104 , and similarly for relay eNB 104 can terminate at donor eNB 102 .
- the transport and application layer protocols can relate to S1-U, S1-MME, and/or X2 interfaces.
- S1-U interface can be utilized to communicate in a data plane between a node and a serving gateway (not shown) of the core network 106 .
- S1-MME interface can be utilized for control plane communications between a node and a mobility management entity (MME) (not shown) of the core network 106 .
- MME mobility management entity
- X2 interface can be utilized for communications between eNBs.
- donor eNB 102 can communicate with other relay eNBs to allow communications therebetween over the access network (e.g., relay eNB 104 can communicate with one or more additional relay eNBs connected to donor eNB 102 ).
- relay eNB 104 can communicate with one or more additional relay eNBs connected to donor eNB 102 ).
- relay eNB 104 (and relay eNB 108 ) can map multiple evolved packet system (EPS) bearers at core network 106 to a single dedicated radio bearer (DRB) to support a plurality of downstream UEs, such as UE 110 , and/or bearers related thereto.
- relay eNB 104 can support robust header compression (RoHC) for the multiple UE bearers.
- donor eNB 102 can have a single RoHC compressor and/or decompressor instance for a DRB of relay eNB 104 , and relay eNB 104 can similarly have a single decompressor and/or compressor for a given dedicated radio bearer.
- donor eNB 102 can compress packet headers (e.g., internet protocol (IP), user datagram protocol (UDP) and/or similar packet headers) for multiple EPS bearers over a single DRB.
- packet headers e.g., internet protocol (IP), user datagram protocol (UDP) and/or similar packet headers
- donor eNB 102 can insert a RoHC context identifier in the RoHC header, and the relay eNB 104 can differentiate the RoHC contexts based on the RoHC context identifiers.
- relay eNB 104 can apply appropriate decompression to the headers.
- relay eNB 104 can compress and donor eNB 102 can decompress using the RoHC context identifiers.
- a RoHC context can refer to a procedure utilized to compress one or more packet headers for efficient transmission thereof and can differ according to a type of bearer and/or data transmitted thereover, a destination node or type thereof, available resources, and/or the like.
- donor eNB 102 can have one or more RoHC compressors and/or decompressors for each EPS bearer mapped to the DRB of relay eNB 104 .
- relay eNB 104 can have one or more RoHC decompressors and/or compressors for each EPS bearer.
- a RoHC compressor of the donor eNB 102 can compress the packet headers, and donor eNB 102 can encapsulate the compressed IP header and the IP packet for a given EPS bearer in a tunneling protocol header that includes a tunnel endpoint identifier (TEID) related to the EPS bearer (and/or a corresponding UE 110 bearer).
- TEID tunnel endpoint identifier
- the tunneling protocol can be general packet radio service (GPRS) tunneling protocol (GTP)-U.
- GPRS general packet radio service
- donor eNB 102 can encapsulate the IP packet (or the GTP-U packet) in a relay protocol (RP) header that facilitates packet routing based on a relay identifier comprised in the RP packet header.
- RP relay protocol
- relay eNB 104 Upon receiving the encapsulated packet, relay eNB 104 can extract the IP header and packet, for example, and one of the decompressors of relay eNB 104 can determine the RoHC context based at least in part on the TEID. In another example, one of the decompressors can determine the RoHC based additionally or alternatively on the relay identifier. In this regard, the decompressor can apply the appropriate decompression to the header. Similarly, relay eNB 104 can compress and donor eNB 102 can decompress using TEID to determine RoHC context, as described.
- a header for the tunneling protocol can also be compressed.
- the header can include an address of an upstream network node, such as a serving gateway (SGW) that can be compressed.
- SGW serving gateway
- the tunneling protocol can be transmitted over a packet data convergence protocol (PDCP) layer with an associated IP packet.
- PDCP configuration can be extended to include a payload type that specifies whether the packet has an IP, GTP-U, or RP header.
- System 200 includes a donor eNB 102 that provides relay eNB 104 (and/or other relay eNBs) with access to core network 106 . Additionally, as described, relay eNB 104 can provide one or more devices, such as UE 110 , and/or other relay eNBs with access to the core network 106 through the donor eNB 102 . In addition, it is to be appreciated that relay eNB 104 can comprise the components of donor eNB 102 , and vice versa, to provide similar functionality, in one example.
- donor eNB 102 can be a macrocell access point, femtocell access point, picocell access point, mobile base station, and/or the like.
- Relay eNB 104 can similarly be mobile or stationary relay nodes that communicate with donor eNB 102 over a wireless or wired backhaul, as described.
- Donor eNB 102 comprises a RoHC context selecting component 202 that determines a RoHC context or related identifier for packets received over an EPS bearer, a RoHC compressing component 204 that applies compression to packet headers received over the EPS bearer based at least in part on the RoHC context, a RoHC context indicating component 206 that specifies the selected RoHC context in a RoHC header of the compressed communication, and a bearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.
- a RoHC context selecting component 202 that determines a RoHC context or related identifier for packets received over an EPS bearer
- a RoHC compressing component 204 that applies compression to packet headers received over the EPS bearer based at least in part on the RoHC context
- a RoHC context indicating component 206 that specifies the selected RoHC context in a RoHC header of the compressed communication
- a bearer communicating component 208 that transmits communications to and
- Relay eNB 104 can include a bearer communicating component 210 that receives communications from and/or transmits communications to a core network 106 over an EPS bearer (e.g., through one or more upstream nodes), a RoHC context determining component 212 that obtains a RoHC context of packet headers received over a DRB mapped to one or more EPS bearers based at least in part on an identifier in the RoHC headers of the packets, and a RoHC decompressing component 214 that applies decompression to the packet headers based at least in part on the determined RoHC context.
- EPS bearer e.g., through one or more upstream nodes
- a RoHC context determining component 212 that obtains a RoHC context of packet headers received over a DRB mapped to one or more EPS bearers based at least in part on an identifier in the RoHC headers of the packets
- a RoHC decompressing component 214 that applies decompression to the packet header
- donor eNB 102 can receive communications for relay eNB 104 (and/or one or more relay eNBs or devices, such as UE 110 , communicating directly or indirectly therewith).
- core network 106 can have previously established an EPS bearer that maps to a bearer of UE 110 .
- Relay eNB 104 as an intermediary node, can have established a bearer to which core network 106 that actually maps the EPS bearer and can forward data transmitted over the EPS bearer to UE 110 .
- relay eNB 104 can support multiple directly connected UEs as well as relay eNBs, which can have connected UEs or additional relay eNBs, etc.
- relay eNB 104 can be required to support a number of EPS bearers given a limited number of DRBs at relay eNB 104 .
- RoHC can be performed to support a number of EPS bearers over a single DRB.
- RoHC context selecting component 202 can determine a RoHC context for the communications. In one example, this can be based at least in part on a type of the EPS bearer or related communications (e.g., voice, video, gaming, etc.), the relay eNB receiving the data (e.g., relay eNB 104 in this example), available system resources, and/or the like.
- RoHC compressing component 204 can apply a RoHC compression to the communications, or headers thereof, to facilitate efficient transmission of the communications over a DRB. In one example, the RoHC compressing component 204 can compress a header of an IP packet by removing or replacing one or more parameters in the IP packet header previously communicated to relay eNB 104 .
- the RoHC context can have an associated identifier, for example, that can be utilized to indicate and subsequently determine the RoHC context type.
- RoHC context indicating component 206 can insert the identifier in the header.
- Bearer communicating component 208 can provide the RoHC compressed communication to relay eNB 104 over a mapped DRB. As described, for example, bearer communicating component 208 can simultaneously provide additional RoHC compressed communications for disparate EPS bearers over the DRB. In one example, bearer communicating component 208 can provide the RoHC compressed communication to relay eNB 104 based at least in part on locating an association between an identifier of a tunneling protocol header of the communication and relay eNB 104 in a routing table.
- Bearer communicating component 210 can receive the RoHC compressed communications.
- RoHC context determining component 212 can evaluate an identifier in the RoHC header to determine the RoHC context.
- RoHC decompressing component 214 can decompress the communications, or related headers, based on the determined RoHC context, for example. It is to be appreciated, for example, that the RoHC context identifiers can be known by the donor eNB 102 and/or relay eNB 104 according to a specification, configuration, previous communications, and/or the like. Additionally, using a RoHC context identifier mitigates the need to transmit other RoHC context information required for decompressing the RoHC packet, which decreases bandwidth requirements. Indeed, the context identifier can be specified as a small number of bits in the RoHC header.
- the RoHC context header in one example, can relate not only to the type of communications and/or the related RoHC compression applied, but can also be specific to a corresponding destination node (e.g., UE 110 , or another relay eNB or UE communicating directly or indirectly with relay eNB 104 ).
- a corresponding destination node e.g., UE 110 , or another relay eNB or UE communicating directly or indirectly with relay eNB 104 ).
- the RoHC functionality for multiple EPS bearers mapped to a single DRB can be provided for relay eNB 104 communicating with a downstream relay eNB.
- substantially any two communicating nodes can utilize the components described herein having a RoHC compressing component 204 at one node and a RoHC decompressing component 214 at the other.
- the example shown with donor eNB 102 communicating with relay eNB 104 is but one possible implementation.
- System 300 includes a donor eNB 102 that provides wireless network access to relay eNB 104 , as described.
- Donor eNB 102 can include a RoHC compressing/decompressing component 302 that provides a single instance of a RoHC compressor and decompressor for communicating multiple EPS bearer RoHC packets over a single DRB 306 to relay eNB 104 .
- relay eNB 104 can include a RoHC compressing/decompressing component 304 that provides a single instance of a RoHC compressor and decompressor for communicating multiple EPS bearer RoHC packets over a single DRB 306 to donor eNB 102 .
- RoHC compressing/decompressing component 302 can compress communications for EPS bearer 1 (e.g., received from a core network (not shown)) according to a RoHC context corresponding to identifier 0 , and can transmit the communication over DRB 306 as represented at 308 .
- RoHC compressing/decompressing component 304 can decompress communications received from EPS bearer 1 according to the RoHC context represented by identifier 0 .
- RoHC compressing/decompressing component 304 can compress communications to be transmitted over EPS bearer 1 according to RoHC context with identifier 0 and transmit the compressed communications to donor eNB 102 .
- RoHC compressing/decompressing component 302 can decompress the communications according to the RoHC context represented by identifier 0 , as described, for forwarding data comprised in the RoHC communication to a core network.
- the RoHC contexts and associated identifiers can be known at donor eNB 102 and/or relay eNB 104 , such as according to a configuration, specification, and/or the like.
- RoHC compressing/decompressing component 302 can compress/decompress communications over EPS bearer 2 using RoHC context with identifier 1 at 310 , communications over EPS bearer 3 using RoHC context with identifier 2 at 310 , communications over EPS bearer 4 using RoHC context with identifier 3 at 310 , and communications over EPS bearer 5 using RoHC context with identifier 4 at 310 over DRB 306 .
- RoHC context identifier 0 can be represented in the RoHC header as zero bytes.
- RoHC context identifiers for example, can range from 0-15, where 1-15 can be represented as a 4-bit field in the RoHC header.
- the RoHC context identifiers can be extended to a larger number to balance a number of supported contexts with a desired bandwidth utilization.
- System 400 includes a donor eNB 102 that provides relay eNB 104 (and/or other relay eNBs) with access to core network 106 . Additionally, as described, relay eNB 104 can provide one or more devices, such as UE 110 , and/or other relay eNBs with access to the core network 106 through the donor eNB 102 . In addition, it is to be appreciated that relay eNB 104 can comprise the components of donor eNB 102 , and vice versa, to provide similar functionality, in one example.
- donor eNB 102 can be a macrocell access point, femtocell access point, picocell access point, mobile base station, and/or the like.
- Relay eNB 104 can similarly be mobile or stationary relay nodes that communicate with donor eNB 102 over a wireless or wired backhaul, as described.
- Donor eNB 102 comprises a RoHC compression instance component 402 that initializes a RoHC compressor for compressing headers of one or more packets received from core network 106 , a packet encapsulating component 404 that creates a tunneling protocol header for routing compressed header packets, an identifier specifying component 406 that inserts a TEID or other relay identifier related to the relay eNB 104 in the tunneling protocol header to facilitate routing the packet, and a bearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.
- Relay eNB 104 can include a bearer communicating component 210 that receives communications from and/or transmits communications to a core network 106 over an EPS bearer (e.g., through one or more upstream nodes), an identifier receiving component 408 that determines an identifier in a received tunneling protocol header, a RoHC context determining component 212 that discerns a RoHC context based at least in part on the identifier, and a RoHC decompression instance component 410 that initializes a RoHC decompressor that can decompress packet headers based at least in part on the received identifier.
- a bearer communicating component 210 that receives communications from and/or transmits communications to a core network 106 over an EPS bearer (e.g., through one or more upstream nodes)
- an identifier receiving component 408 that determines an identifier in a received tunneling protocol header
- a RoHC context determining component 212 that discerns a RoHC context based at least in
- donor eNB 102 can receive communications for relay eNB 104 (and/or one or more relay eNBs or devices, such as UE 110 , communicating directly or indirectly therewith).
- core network 106 can have previously established an EPS bearer that maps to a bearer of UE 110 .
- Relay eNB 104 as an intermediary node, can have established a bearer to which core network 106 (e.g., that actually maps the EPS bearer) and can forward data transmitted over the EPS bearer to UE 110 .
- relay eNB 104 can support multiple directly connected UEs as well as relay eNBs, which can also have connected UEs or additional relay eNBs, etc.
- relay eNB 104 can be required to support a number of EPS bearers given a limited number of DRBs at relay eNB 104 .
- RoHC can be performed to support a number of EPS bearers over a single DRB.
- RoHC compression instance component 402 can create a RoHC compressor for the packet (and/or other packets received over the same EPS bearer, for example), which can compress the IP packet header according to one or more RoHC compression specifications.
- Packet encapsulating component 404 can create a tunneling protocol header for the RoHC packets.
- the tunneling protocol header can be a GTP-U header, an RP header, and/or the like, and can be compressed as well.
- packet encapsulating component 404 can encapsulate the IP header and packet in a GTP-U header, for example.
- Identifier specifying component 406 can include an identifier, such as a TEID or portion thereof, in the GTP-U header.
- packet encapsulating component 404 can additionally encapsulate the entire packet along with the GTP-U header in a relay protocol packet.
- Identifier specifying component 406 can include a relay identifier in the relay protocol packet header.
- Bearer communicating component 208 can provide the encapsulated communication to relay eNB 104 over a mapped DRB. As described, for example, bearer communicating component 208 can simultaneously provide additional RoHC compressed communications for disparate EPS bearers over the DRB. In one example, bearer communicating component 208 can provide the encapsulated communication to relay eNB 104 based at least in part on locating an association between an identifier in a header of the communication (e.g., a TEID and/or relay identifier) and relay eNB 104 in a routing table.
- an identifier in a header of the communication e.g., a TEID and/or relay identifier
- Bearer communicating component 210 can receive the encapsulated communication.
- Identifier receiving component 408 can determine an identifier in the tunneling protocol header (e.g., TEID and/or relay identifier, as described).
- RoHC context determining component 212 can determine a RoHC context utilized to compress the headers based at least in part on the identifier.
- RoHC decompression instance component 410 can initialize a RoHC decompressor that decompresses the IP packet header, which can be extracted from the relay protocol payload in one example, according to the RoHC context.
- additional RoHC context parameters need not be transmitted among the donor eNB 102 and relay eNB 104 ; rather, relay eNB 104 can RoHC decompress the IP packet header based on the TEID or relay identifier of relay eNB 104 .
- a type of RoHC compression for the EPS bearer can be previously communicated between donor eNB 102 and relay eNB 104 and each node can store an association between the type of RoHC compression and the identifier of relay eNB 104 .
- an EPS bearer type can be known at donor eNB 102 and relay eNB 104 , and the RoHC context can be based on the EPS bearer type. It is to be appreciated that the RoHC decompressor can similarly be utilized to decompress headers of additional IP packets received over the corresponding EPS bearer.
- the RoHC functionality based on an identifier of relay eNB 104 for multiple EPS bearers mapped to a single DRB can be provided for relay eNB 104 communicating with a downstream relay eNB.
- substantially any two communicating nodes can utilize the components described herein having a plurality of RoHC compressors at one node and a plurality of corresponding RoHC decompressors at the other.
- relay eNB 104 can perform the compressing and donor eNB 102 the decompressing, in another example. The example shown with donor eNB 102 communicating with relay eNB 104 is but one possible implementation.
- System 500 includes a donor eNB 102 that provides wireless network access to relay eNB 104 , as described.
- Donor eNB 102 can include a RoHC compressing/decompressing component 502 that provides multiple RoHC compressing instances 506 , 508 , 510 , and 512 for compressing communications over a provided DRB 306 .
- relay eNB 104 can include a RoHC compressing/decompressing component 504 that provides multiple RoHC decompressing instances 514 , 516 , 518 , and 520 for decompressing communications over DRB 306 .
- RoHC compressing instance 506 can compress communications and/or related headers received over EPS bearer 1 using a RoHC context related to relay identifier AABB at 522 .
- the identifier can be an identifier assigned to relay eNB 104 and/or a related downstream bearer by donor eNB 102 , such as a TEID and/or relay identifier.
- the identifier can be a concatenation of a portion assigned by donor eNB 102 to the relay eNB 104 or downstream bearer and a portion assigned by another node (e.g., relay eNB 104 for the downstream bearer).
- the identifier can be unique such that RoHC decompressing instance 514 can determine and apply a RoHC decompression context to compress communications according to the identifier.
- RoHC compressing instance 508 can compress communications over EPS bearer 2 according to identifier CCDD at 524
- RoHC decompressing instance 516 can decompress the compressed communications or related headers based on the identifier.
- RoHC compressing instance 510 can compress communications over EPS bearer 3 according to identifier EEFF at 526
- RoHC decompressing instance 518 can decompress the compressed communications or related headers based on the identifier.
- RoHC compressing instance 512 can compress communications over EPS bearer 4 according to identifier GGHH at 528
- RoHC decompressing instance 520 can decompress the compressed communications or related headers based on the identifier.
- System 600 includes a donor eNB 102 that provides relay eNB 104 (and/or other relay eNBs) with access to core network 106 . Additionally, as described, relay eNB 104 can provide one or more devices, such as UE 110 , and/or other relay eNBs with access to the core network 106 through the donor eNB 102 . In addition, it is to be appreciated that relay eNB 104 can comprise the components of donor eNB 102 , and vice versa, to provide similar functionality, in one example.
- donor eNB 102 can be a macrocell access point, femtocell access point, picocell access point, mobile base station, and/or the like.
- Relay eNB 104 can similarly be mobile or stationary relay nodes that communicate with donor eNB 102 over a wireless or wired backhaul, as described.
- Donor eNB 102 comprises an IP packet receiving component 602 that obtains one or more IP packets from core network 106 for a downstream node, a tunneling protocol encapsulating component 604 that associates the IP packet and/or header with a tunneling protocol header for packet routing, a header compressing component 606 that compresses one or more headers of the packet, and a bearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.
- IP packet receiving component 602 that obtains one or more IP packets from core network 106 for a downstream node
- a tunneling protocol encapsulating component 604 that associates the IP packet and/or header with a tunneling protocol header for packet routing
- a header compressing component 606 that compresses one or more headers of the packet
- a bearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.
- Relay eNB 104 can include a bearer communicating component 210 that receives communications from and/or transmits communications to a core network 106 over an EPS bearer (e.g., through one or more upstream nodes), a header decompressing component 608 that decompresses one or more packet headers, and an IP packet retrieving component 610 that determines an IP packet for providing to UE 110 .
- EPS bearer e.g., through one or more upstream nodes
- IP packet retrieving component 610 e.g., IP packet for providing to UE 110 .
- IP packet receiving component 602 can obtain an IP packet from core network 106 for providing to UE 110 .
- the IP packet can be received with a GTP-U header that includes an identifier related to UE 110 .
- the identifier can have been assigned by donor eNB 102 to facilitate routing the packet through one or more intermediary relay eNBs.
- donor eNB 102 can RoHC compress one or more headers of the packet.
- Tunneling protocol encapsulating component 604 can create a tunneling protocol header for the IP packet.
- the tunneling protocol header as described, can be a compressed or uncompressed GTP-U header, RP header, and/or the like.
- tunneling protocol encapsulating component 604 can include an identifier in the header for subsequent packet routing (e.g., a TEID or related portion for a GTP-U header and/or a relay identifier in an RP header).
- an identifier in the header for subsequent packet routing e.g., a TEID or related portion for a GTP-U header and/or a relay identifier in an RP header.
- Header compressing component 606 can apply compression to one or more of the headers (e.g., IP header, GTP-U header, UDP header, etc.) to reduce a size of the packet.
- header compressing component 606 can compress a GTP-U header of the received IP packet to a format similar to the following.
- the compressed SGW IP address can be reduced to one byte.
- donor eNB 102 and relay eNB 104 can have previously communicated the SGW address and assigned a one byte identifier to save bandwidth by not including the full address in the compressed GTP-U header (e.g. in a transport address translation response to a transport address translation request received from relay eNB 104 ).
- header compressing component 606 can compress the IP header.
- header compression component 606 can specify a type of the payload of the compressed packet (e.g., IP, GTP-U, RP, etc.).
- a receiving entity can determine which header is compressed.
- Bearer communicating component 208 can transmit the compressed header packet to relay eNB 104 .
- bearer communicating component 208 can provide the packet to relay eNB 104 based at least in part on locating an association between an identifier of a tunneling protocol header (e.g., TEID, relay protocol, etc., as described) of the communication and relay eNB 104 in a routing table.
- Bearer communicating component 210 can receive the packet.
- Header decompressing component 608 can determine which header is compressed based at least in part on a type specified in the PDCP portion of the packet, as described, and can accordingly decompress the appropriate header.
- IP packet retrieving component 610 can obtain the IP packet and corresponding header once the appropriate header is decompressed.
- IP packet receiving component 602 can receive a packet with a packet structure similar to the following.
- header compressing component 606 can compress the GTP-U header and prepare the packet for transmitting to relay eNB 104 over an access link, resulting in a packet structure similar to the following, for example.
- header compressing component 606 can additionally indicate that the packet has a compressed GTP-U header in the PDCP portion of the packet.
- header decompressing component 608 can interpret the compressed GTP-U header, which can include a destination address for the packet, in one example, and IP packet retrieving component 610 can generate a packet structure similar to the following for transmitting to UE 110 .
- intermediary relay eNBs there can be intermediary relay eNBs (not shown) in the communications path between donor eNB 102 and relay eNB 104 .
- the intermediary relay eNBs can transmit the compressed GTP-U structure, shown above, without modifying the packet based at least in part on an identifier (e.g., TEID and/or relay identifier) in the structure.
- an identifier e.g., TEID and/or relay identifier
- uplink communications from UE 110 to donor eNB 102 can similarly be compressed by relay eNB 104 for transmission.
- donor eNB 102 can decompress the GTP-U header to create a GTP-U header with an identifier of a core network 106 component.
- Network 700 includes a UE 110 that communicates with a relay eNB 104 , as described, to receive access to a wireless network.
- Relay eNB 104 can communicate with a donor eNB 102 using a relay protocol to provide access to a wireless network, and as described, donor eNB 102 can communicate with an MME 702 and/or SGW 704 that relate to the relay eNB 104 .
- SGW 704 can connect to or be coupled with a PGW 706 , which provides network access to SGW 704 and/or additional SGWs.
- PGW 706 can communicate with a PCRF 708 to authenticate/authorize UE 110 to use the network, which can utilize an IMS 710 to provide addressing to the UE 110 and/or relay eNB 104 .
- MME 702 and/or SGW 704 and PGW 706 can be related to donor eNB 102 serving substantially all relay eNBs in the cluster.
- Donor eNB 102 can also communicate with an SGW 716 and PGW 718 that relate to the UE 110 , such that the PGW 718 can assign UE 110 a network address to facilitate tunneling communications thereto through the relay eNB 104 , donor eNB 102 , and SGW 716 .
- SGW 716 can communicate with an MME 714 to facilitate control plane communications to and from the UE 110 .
- MME 702 and MME 714 can be the same MME, in one example.
- PGW 718 can similarly communicate with a PCRF 708 to authenticate/authorize UE 110 , which can communicate with an IMS 710 .
- PGW 718 can communicate directly with the IMS 710 and/or internet 712 .
- UE 110 can communicate with the relay eNB 104 over an E-UTRA-Uu interface, as described, and the relay eNB 104 can communicate with the donor eNB 102 using an E-UTRA-Uu interface or other interface using the relay protocol, as described herein.
- Donor eNB 102 communicates with the MME 702 using an S1-MME interface and the SGW 704 and PGW 706 over an S1-U interface, as depicted.
- communications received from relay eNB 104 for MME 702 or SGW 704 /PGW 706 can be over a relay protocol and can have an IP address of MME 702 or SGW 704 /PGW 706 in the relay protocol header.
- Donor eNB 102 can appropriately route the packet according to the IP address and/or payload type of the relay protocol.
- packets from relay eNB 104 can comprised a previously assigned TEID or portion thereof.
- the transport layers used over the S1-MME and S1-U interfaces are terminated at the donor eNB 102 , as described.
- donor eNB 102 upon receiving communications for the relay eNB 104 from the MME 702 or SGW 704 , donor eNB 102 can, for example, decouple the application layer from the transport layer by defining a new relay protocol packet, or other protocol layer packet, and transmitting the application layer communication to the relay eNB 104 in the new protocol packet (over the E-UTRA-Uu interface, in one example).
- Donor eNB 102 can transmit the packet to relay eNB 104 (and/or one or more disparate relay eNBs as described) based on a TEID in the packet or relay identifier in the header.
- donor eNB 102 Upon transmitting control plane communications from the relay eNB 104 to the MME 702 , donor eNB 102 can indicate an identifier of the relay eNB 104 (e.g., in an S1-AP message), and MME 702 can transmit the identifier in responding communications to the donor eNB 102 .
- donor eNB 102 can insert an identifier for the relay eNB 104 (or UE 110 or one or more related bearers) in the TEID of a GTP-U header to identify the relay eNB 104 (or UE 110 or one or more related bearers).
- This can be an identifier generated for relay eNB 104 by donor eNB 102 such that donor eNB 102 can determine the relay eNB 104 , or one or more downstream relay eNBs is to receive the translated packet, as described above. For example, this can be based at least in part on locating at least a portion of the identifier in a routing table at donor eNB 102 .
- headers can be compressed, in one example, as described.
- MME 702 can communicate with SGW 704 , and MME 714 to SGW 716 , using an S7 interface.
- PGWs 706 and 718 can communicate with PCRF 708 over a Gx interface.
- PCRF 708 can communicate with IMS 710 using an Rx interface
- PGW 718 can communicate with IMS 710 and/or the internet 712 using an SGi interface.
- example protocol stacks 800 are illustrated that facilitate communicating in a wireless network to provide cell relay functionality for data (e.g., user) plane communications using a TEID for packet routing.
- a UE protocol stack 802 is shown comprising an L 1 layer, MAC layer, an RLC layer, a PDCP layer, and an IP layer.
- a relay eNB (ReNB) access link protocol stack 804 is depicted having an L 1 layer, MAC layer, RLC layer, and PDCP layer, as well as an ReNB backhaul link protocol stack 806 having an L 1 layer, PDCP/RLC/MAC layer, and a C-GTP-U/UDP/IP layer, which can be a compressed layer in one example, to facilitate routing packets on the backhaul (e.g., by populating the TEID with the ReNB address, as described previously).
- ReNB relay eNB
- a donor eNB (DeNB) access link protocol stack 808 is also shown having an L 1 layer, PDCP/RLC/MAC layer, and a C-GTP/UDP/IP layer, as well as a DeNB backhaul link protocol stack 810 having an L 1 layer, L 2 layer, an IP layer, a UDP layer, and a GTP-U layer to maintain communications with a PGW/SGW using an address assigned by the PGW/SGW.
- PGW/SGW protocol stack 812 has an L 1 layer, L 2 , layer, IP layer related to an address assigned to the DeNB, UDP layer, GTP-U layer, and another IP layer related to an address assigned to the UE.
- a UE can communicate with an ReNB to receive access to a PGW/SGW.
- UE can communicate over L 1 , MAC, RLC, and PDCP layers with the ReNB over using a EUTRA-Uu interface, as shown between protocol stacks 802 and 804 .
- the UE can tunnel IP layer communications through the ReNB and other entities to the PGW/SGW, which assigns an IP address to the UE, as shown between protocol stacks 802 and 812 .
- the ReNB communicates with a DeNB over L 1 , PDCP/RLC/MAC, and C-GTP-U/UDP/IP layers using an S1-U-R interface, as shown between protocol stacks 806 and 808 .
- the S1-U-R interface can be a newly defined interface that utilizes a disparate transport layer than communications between DeNB and PGW/SGW.
- communications between ReNB and DeNB additionally use a compressed version of the GTP-U, UDP/IP headers.
- this compressed header can indicate TEID, as described herein, of the ReNB in the GTP-U header to facilitate return communications, as described, herein.
- DeNB can decouple the C-GTP-U/UDP/IP header from the transport layer and communicate with the PGW over separate GTP-U, UDP, and IP layers on top of L 1 and L 2 physical layers over an S1-U interface, as shown between protocol stacks 810 and 812 .
- DeNB decouples the GTP, UDP, and IP layers from the transport layers, compresses them into a C-GTP-U/UDP/IP header, and transmits over the PDCP/RLC/MAC and L 1 layers to the ReNB.
- DeNB can use a TEID in the GTP-U header to route the packet to the ReNB. In one example, this mitigates the need for UDP/IP routing on the backhaul, etc.
- example protocol stacks 900 are illustrated that facilitate communicating in a wireless network to provide cell relay functionality for data (e.g., user) plane communications using a relay protocol.
- a UE protocol stack 902 is shown comprising an L 1 layer, MAC layer, an RLC layer, a PDCP layer, and an IP layer.
- a relay eNB 1 (ReNB) access link protocol stack 904 is depicted having an L 1 layer, MAC layer, RLC layer, and PDCP layer, as well as an ReNB 1 backhaul link protocol stack 906 having an L 1 layer, MAC layer, RLC layer, PDCP layer, relay protocol (RP) layer, and a C-GTP-U/UDP/IP layer, which can be a compressed layer in one example, to facilitate communicating packets on the backhaul.
- An intermediary ReNB 2 access link protocol stack 908 is shown having an L 1 layer, MAC layer, RLC layer, PDCP layer, and RP layer, as well as a backhaul link protocol stack 910 for the intermediary ReNB 2 having the same layers.
- a DeNB access link protocol stack 908 is also shown having an L 1 layer, MAC layer, RLC layer, PDCP layer, RP layer, and a C-GTP/UDP/IP layer, as well as a DeNB backhaul link protocol stack 910 having an L 1 layer, L 2 layer, a UDP/IP layer, and a GTP-U layer to maintain communications with a PGW/SGW using an address assigned by the PGW/SGW.
- PGW/SGW protocol stack 912 has an L 1 layer, L 2 , layer, UDP/IP layer related to an address assigned to the DeNB, GTP-U layer, and another IP layer related to an address assigned to the UE.
- a UE can communicate with an ReNB 1 to receive access to a PGW/SGW.
- UE can communicate over L 1 , MAC, RLC, and PDCP layers with the ReNB 1 over using a EUTRA-Uu interface, as shown between protocol stacks 902 and 904 .
- the UE can tunnel IP layer communications through the ReNB 1 and other entities to the PGW/SGW, which assigns an IP address to the UE, as shown between protocol stacks 902 and 916 .
- ReNB 1 communicates with ReNB 2 over an RP, as described herein, on top of L 1 , MAC, RLC, PDCP layers using an S1-U-R interface (or other new interface for communicating using a relay protocol), as shown between protocol stacks 906 and 908 .
- the RP can carry the upper layer C-GTP-U/UDP/IP layer in the RP payload, as described previously, to the disparate RP, as shown between protocol stacks 906 and 908 .
- the RP header can include an identifier of ReNB 1 , an IP address of the PGW/SGW, a protocol type indicating C-GTP-U/UDP/IP data in the RP payload, and/or the like.
- ReNB 2 can forward the RP communication to the DeNB, as shown between protocol stack s 910 and 912 .
- DeNB can receive the RP packet, over the lower layers, and can extract the C-GTP-U/UDP/IP packet from the payload and communicate with the PGW over separate GTP-U, UDP, and IP layers on top of L 1 and L 2 physical layers over an S1-U interface, as shown between protocol stacks 914 and 916 .
- the DeNB can include the relay identifier from the RP packet header in the GTP-U communications.
- downlink communications from PGW/SGW protocol stack 912 can include the relay identifier.
- DeNB access link protocol stack 912 can generate an RP packet with a header comprising the relay identifier received over PGW/SGW protocol stack 916 and a compressed GTP-U/UDP/IP packet as the payload.
- DeNB access link protocol stack 912 can transmit the RP packet over ReNB 2 backhaul link protocol stack 912 , which can forward the RP packet over ReNB 2 access link protocol stack 908 to ReNB backhaul link protocol stack 906 based on the relay identifier in the RP header, as described.
- ReNB 1 backhaul link protocol stack 906 can obtain the C-GTP-U/UDP/IP payload of the RP packet and forward to UE protocol stack 902 , where the RP packet payload is of certain types, as described.
- FIGS. 10-14 methodologies relating to compressing and/or encapsulating packets for transmission in a wireless network using cell relays are illustrated. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance with one or more aspects, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with one or more aspects.
- a packet with a RoHC compressed header can be received from at least one of a plurality of EPS bearers mapped to a DRB. As described, the packet can be RoHC compressed according to a RoHC context.
- the RoHC context for the RoHC compressed header can be determined.
- the RoHC context can be determined based on an identifier in the RoHC header that relates to a RoHC compression context, an identifier at least partially related to a respective UE bearer, such as a TEID and/or relay identifier in a tunneling protocol header, and/or the like, as described.
- the RoHC compressed header can be decompressed based at least in part on the RoHC context.
- the decompression as described, can be performed by a single decompressor that decompresses substantially all RoHC compressed headers received from an upstream node, a decompressor specific to the EPS bearer, and/or the like.
- the RoHC contexts can relate to procedures utilized to compress the header that are known at the compression and decompression nodes, as described; the RoHC contexts can differ based on an EPS bearer type, data transmitted over the bearer, node type, available resources, and/or the like.
- an example methodology 1100 is shown that facilitates RoHC compressing packet headers using a RoHC context.
- a header of a packet received over an EPS bearer can be compressed based at least in part on a RoHC context.
- the RoHC context can be selected based at least in part on a bearer type, data type, node type, etc.
- an identifier related to the RoHC context can be indicated in the packet.
- a decompressor can determine the RoHC context to utilize for decompressing the compressed header.
- the packet can be transmitted over a DRB to which the EPS bearer and one or more disparate EPS bearers are mapped.
- an example methodology 1200 that facilitates encapsulating a packet or header in a tunneling protocol is illustrated.
- an IP packet can be received from a core network for transmitting to a UE bearer.
- the IP packet can include a GTP header that specifies an identifier related at least in part to the UE bearer.
- the IP header and/or packet can be encapsulated in a tunneling protocol header that includes an identifier related to the UE bearer.
- the identifier can be utilized to determine a RoHC context for decompressing the header.
- the tunneling protocol header can be a compressed or uncompressed GTP-U header, an RP header, etc.
- the identifier can be a TEID, relay identifier, or portion thereof, etc.
- a tunneling protocol header type can be indicated in a PDCP portion of the packet.
- a receiving node can determine the encapsulated packet type to retrieve the IP packet and header.
- the packet can be transmitted to one or more relay nodes in a communications path to the UE. As described, the one or more relay nodes can be determined from the identifier in the tunneling protocol header (e.g., as indicated in a routing table, in one example).
- an example methodology 1300 that facilitates obtaining an IP packet and header from an encapsulated packet is illustrated.
- a packet encapsulated in a tunneling protocol header can be received.
- a type of the tunneling protocol header can be determined from an indicator in the PDCP portion of the packet.
- the indicator can specify a compressed GTP-U, RP, IP, or similar type.
- an IP packet and header can be retrieved from the packet. For example, if the packet or header is RoHC compressed, and the indicator specifies compressed GTP-U, the GTP-U header can be decompressed and the IP packet and header retrieved from the payload. If the type is RP, the IP packet and header can be retrieved as the payload of the RP packet, for example.
- a packet can be received from an upstream node comprising a UDP, IP, or GTP header.
- the header of the packet can be compressed to include a compressed SGW IP address.
- an SGW IP address in a header received from a core network can be compressed to a one byte or other smaller sized value previously communicated to a downstream node (e.g., in a transport address translation response).
- the compressed header can require less bandwidth for transmission.
- the header can include additional fields and/or the additional fields can be compressed as well.
- the packet with the compressed header can be transmitted to a downstream node.
- inferences can be made regarding determining a RoHC context and/or related identifier, associating a RoHC context with a TEID or relay identifier, and/or other aspects described herein.
- the term to “infer” or “inference” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events.
- Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.
- System 1500 comprises a base station 1502 that can include multiple antenna groups.
- one antenna group can include antennas 1504 and 1506
- another group can comprise antennas 1508 and 1510
- an additional group can include antennas 1512 and 1514 .
- Two antennas are illustrated for each antenna group; however, more or fewer antennas can be utilized for each group.
- Base station 1502 can additionally include a transmitter chain and a receiver chain, each of which can in turn comprise a plurality of components associated with signal transmission and reception (e.g., processors, modulators, multiplexers, demodulators, demultiplexers, antennas, etc.), as will be appreciated by one skilled in the art.
- Base station 1502 can communicate with one or more mobile devices such as mobile device 1516 and mobile device 1522 ; however, it is to be appreciated that base station 1502 can communicate with substantially any number of mobile devices similar to mobile devices 1516 and 1522 .
- Mobile devices 1516 and 1522 can be, for example, cellular phones, smart phones, laptops, handheld communication devices, handheld computing devices, satellite radios, global positioning systems, PDAs, and/or any other suitable device for communicating over wireless communication system 1500 .
- mobile device 1516 is in communication with antennas 1512 and 1514 , where antennas 1512 and 1514 transmit information to mobile device 1516 over a forward link 1518 and receive information from mobile device 1516 over a reverse link 1520 .
- mobile device 1522 is in communication with antennas 1504 and 1506 , where antennas 1504 and 1506 transmit information to mobile device 1522 over a forward link 1524 and receive information from mobile device 1522 over a reverse link 1526 .
- forward link 1518 can utilize a different frequency band than that used by reverse link 1520
- forward link 1524 can employ a different frequency band than that employed by reverse link 1526 , for example.
- forward link 1518 and reverse link 1520 can utilize a common frequency band and forward link 1524 and reverse link 1526 can utilize a common frequency band.
- Each group of antennas and/or the area in which they are designated to communicate can be referred to as a sector of base station 1502 .
- antenna groups can be designed to communicate to mobile devices in a sector of the areas covered by base station 1502 .
- the transmitting antennas of base station 1502 can utilize beamforming to improve signal-to-noise ratio of forward links 1518 and 1524 for mobile devices 1516 and 1522 .
- base station 1502 utilizes beamforming to transmit to mobile devices 1516 and 1522 scattered randomly through an associated coverage
- mobile devices in neighboring cells can be subject to less interference as compared to a base station transmitting through a single antenna to all its mobile devices.
- mobile devices 1516 and 1522 can communicate directly with one another using a peer-to-peer or ad hoc technology (not shown).
- system 1500 can be a multiple-input multiple-output (MIMO) communication system.
- system 1500 can utilize substantially any type of duplexing technique to divide communication channels (e.g., forward link, reverse link, . . . ) such as FDD, FDM, TDD, TDM, CDM, and the like.
- communication channels can be orthogonalized to allow simultaneous communication with multiple devices over the channels; in one example, OFDM can be utilized in this regard.
- the channels can be divided into portions of frequency over a period of time.
- frames can be defined as the portions of frequency over a collection of time periods; thus, for example, a frame can comprise a number of OFDM symbols.
- the base station 1502 can communicate to the mobile devices 1516 and 1522 over the channels, which can be create for various types of data.
- channels can be created for communicating various types of general communication data, control data (e.g., quality information for other channels, acknowledgement indicators for data received over channels, interference information, reference signals, etc.), and/or the like.
- FIG. 16 shows an example wireless communication system 1600 .
- the wireless communication system 1600 depicts one base station 1610 and one mobile device 1650 for sake of brevity.
- system 1600 can include more than one base station and/or more than one mobile device, wherein additional base stations and/or mobile devices can be substantially similar or different from example base station 1610 and mobile device 1650 described below.
- base station 1610 and/or mobile device 1650 can employ the systems ( FIGS. 1-7 and 15 ), protocol stacks ( FIG. 8-9 ) and/or methods ( FIGS. 10-14 ) described herein to facilitate wireless communication therebetween.
- traffic data for a number of data streams is provided from a data source 1612 to a transmit (TX) data processor 1614 .
- TX data processor 1614 formats, codes, and interleaves the traffic data stream based on a particular coding scheme selected for that data stream to provide coded data.
- the coded data for each data stream can be multiplexed with pilot data using orthogonal frequency division multiplexing (OFDM) techniques. Additionally or alternatively, the pilot symbols can be frequency division multiplexed (FDM), time division multiplexed (TDM), or code division multiplexed (CDM).
- the pilot data is typically a known data pattern that is processed in a known manner and can be used at mobile device 1650 to estimate channel response.
- the multiplexed pilot and coded data for each data stream can be modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM), etc.) selected for that data stream to provide modulation symbols.
- BPSK binary phase-shift keying
- QPSK quadrature phase-shift keying
- M-PSK M-phase-shift keying
- M-QAM M-quadrature amplitude modulation
- the data rate, coding, and modulation for each data stream can be determined by instructions performed or provided by processor 1630 .
- the modulation symbols for the data streams can be provided to a TX MIMO processor 1620 , which can further process the modulation symbols (e.g., for OFDM). TX MIMO processor 1620 then provides N T modulation symbol streams to N T transmitters (TMTR) 1622 a through 1622 t . In various aspects, TX MIMO processor 1620 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.
- TX MIMO processor 1620 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.
- Each transmitter 1622 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Further, N T modulated signals from transmitters 1622 a through 1622 t are transmitted from N T antennas 1624 a through 1624 t , respectively.
- the transmitted modulated signals are received by N R antennas 1652 a through 1652 r and the received signal from each antenna 1652 is provided to a respective receiver (RCVR) 1654 a through 1654 r .
- Each receiver 1654 conditions (e.g., filters, amplifies, and downconverts) a respective signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream.
- An RX data processor 1660 can receive and process the N R received symbol streams from N R receivers 1654 based on a particular receiver processing technique to provide N T “detected” symbol streams. RX data processor 1660 can demodulate, deinterleave, and decode each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 1660 is complementary to that performed by TX MIMO processor 1620 and TX data processor 1614 at base station 1610 .
- a processor 1670 can periodically determine which precoding matrix to utilize as discussed above. Further, processor 1670 can formulate a reverse link message comprising a matrix index portion and a rank value portion.
- the reverse link message can comprise various types of information regarding the communication link and/or the received data stream.
- the reverse link message can be processed by a TX data processor 1638 , which also receives traffic data for a number of data streams from a data source 1636 , modulated by a modulator 1680 , conditioned by transmitters 1654 a through 1654 r , and transmitted back to base station 1610 .
- the modulated signals from mobile device 1650 are received by antennas 1624 , conditioned by receivers 1622 , demodulated by a demodulator 1640 , and processed by a RX data processor 1642 to extract the reverse link message transmitted by mobile device 1650 . Further, processor 1630 can process the extracted message to determine which precoding matrix to use for determining the beamforming weights.
- Processors 1630 and 1670 can direct (e.g., control, coordinate, manage, etc.) operation at base station 1610 and mobile device 1650 , respectively. Respective processors 1630 and 1670 can be associated with memory 1632 and 1672 that store program codes and data. Processors 1630 and 1670 can also perform computations to derive frequency and impulse response estimates for the uplink and downlink, respectively.
- the aspects described herein can be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof.
- the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.
- ASICs application specific integrated circuits
- DSPs digital signal processors
- DSPDs digital signal processing devices
- PLDs programmable logic devices
- FPGAs field programmable gate arrays
- processors controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.
- a code segment can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements.
- a code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, etc.
- the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein.
- the software codes can be stored in memory units and executed by processors.
- the memory unit can be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.
- system 1700 that facilitates decompressing RoHC headers in one or more received packets.
- system 1700 can reside at least partially within a base station, mobile device, etc.
- system 1700 is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware).
- System 1700 includes a logical grouping 1702 of electrical components that can act in conjunction.
- logical grouping 1702 can include an electrical component for receiving a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB 1704 .
- system 1700 can support a number of UEs and thus can map the EPS bearers provided by a core network to single bearers.
- logical grouping 1702 can include an electrical component for determining a RoHC context for the RoHC compressed header 1706 . As described, this can include analyzing an identifier in the RoHC header that indicates a RoHC context used for compression, determining an identifier related at least in part to a downstream UE bearer that indicates the RoHC context, and/or the like.
- logical grouping 1702 can include an electrical component for decompressing the RoHC compressed header based at least in part on the RoHC context 1708 .
- logical grouping 1702 can include an electrical component for extracting an identifier relating to a UE bearer the corresponds to the EPS bearer from a tunneling protocol header that encapsulates the packet 1710 .
- the tunneling protocol can be a GTP-U, RP, and/or similar protocol
- the identifier, as described can be a TEID, relay identifier, or portion thereof.
- the identifier can relate to the RoHC context, as described previously.
- system 1700 can include a memory 1712 that retains instructions for executing functions associated with electrical components 1704 , 1706 , 1708 , and 1710 . While shown as being external to memory 1712 , it is to be understood that one or more of electrical components 1704 , 1706 , 1708 , and 1710 can exist within memory 1712 .
- system 1800 that facilitates RoHC compressing packet headers for efficient transmission of related packets in a wireless network that utilizes cell relays.
- system 1800 can reside at least partially within a base station, mobile device, etc.
- system 1800 is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware).
- System 1800 includes a logical grouping 1802 of electrical components that can act in conjunction.
- logical grouping 1802 can include an electrical component for compressing a header of a packet received over an EPS bearer based at least in part on a RoHC context 1804 .
- the RoHC context can vary depending on one or more factors relating to system 1800 , core network, and/or the like, such as EPS bearer type, data type transmitted over the EPS bearer, node type, available resources, etc.
- logical grouping 1802 can include an electrical component for indicating an identifier related to the RoHC context in the packet 1806 . As described, this can include a RoHC context identifier in a RoHC header, an identifier related at least in part to a UE bearer indicated in a tunneling protocol header (e.g., a TEID or relay identifier in a GTP-U or RP header), and/or the like.
- logical grouping 1802 can include an electrical component for transmitting the packet header over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped 1808 .
- logical grouping 1802 can include an electrical component for selecting the RoHC context 1810 . This can be based on one or more of the described parameters, in one example, provisioned from a core network, and/or the like.
- logical grouping 1802 can include an electrical component for encapsulating the header or the packet in a tunneling protocol header 1812 . As described, this can be a GTP-U header, an RP header, and/or the like, to facilitate packet routing among various cell relays.
- system 1800 can include a memory 1814 that retains instructions for executing functions associated with electrical components 1804 , 1806 , 1808 , 1810 , and 1812 . While shown as being external to memory 1814 , it is to be understood that one or more of electrical components 1804 , 1806 , 1808 , 1810 , and 1812 can exist within memory 1814 .
- system 1900 that facilitates compressing UDP, IP, or GTP headers in received packets for forwarding to downstream nodes.
- system 1900 can reside at least partially within a base station, mobile device, etc. It is to be appreciated that system 1900 is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware).
- System 1900 includes a logical grouping 1902 of electrical components that can act in conjunction.
- logical grouping 1902 can include an electrical component for receiving a packet from an upstream node comprising a UDP, IP, or GTP header 1904 .
- logical grouping 1902 can include an electrical component for applying compression to a header of the packet to compress at least an SGW IP address 1906 .
- compressing the SGW IP address can include utilizing a compressed version of the SGW IP address negotiated during a transport address translation request/response procedure with system 1900 .
- logical grouping 1902 can include an electrical component for transmitting the packet with the compressed header to a downstream node 1908 . Utilizing the compressed header, as described, can conserve bandwidth for more efficient transmitting.
- system 1900 can include a memory 1910 that retains instructions for executing functions associated with electrical components 1904 , 1906 , and 1908 . While shown as being external to memory 1910 , it is to be understood that one or more of electrical components 1904 , 1906 , and 1908 can exist within memory 1910 .
- DSP digital signal processor
- ASIC application specific integrated circuit
- FPGA field programmable gate array
- a general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
- a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Additionally, at least one processor may comprise one or more modules operable to perform one or more of the steps and/or actions described above.
- a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
- An exemplary storage medium may be coupled to the processor, such that the processor can read information from, and write information to, the storage medium.
- the storage medium may be integral to the processor.
- the processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a user terminal.
- processor and the storage medium may reside as discrete components in a user terminal. Additionally, in some aspects, the steps and/or actions of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which may be incorporated into a computer program product.
- the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium.
- Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
- a storage medium may be any available media that can be accessed by a computer.
- such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
- any connection may be termed a computer-readable medium.
- Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Telephonic Communication Services (AREA)
Abstract
Systems and methodologies are described that facilitate compressing packet headers for cell relay communications. Since cell relays can support a number of evolved packet system (EPS) bearers over a given dedicated radio bearer (DRB), robust header compression (RoHC) can be multiplexed for communications to/from a given cell relay. Thus, an upstream node compressing one or more packet headers can indicate a RoHC context, which can be represented by a RoHC context identifier in a RoHC header. A receiving entity can decompress the headers based on determining the RoHC context. Alternatively, the RoHC context can be associated with an identifier of a related UE bearer such as a tunnel endpoint identifier (TEID), a relay identifier, and/or the like, that is received in a tunneling protocol header to facilitate packet routing.
Description
- The present Application for Patent claims priority to Provisional Application No. 61/108,287 entitled “CELL RELAY BASE STATION FOR LTE” filed Oct. 24, 2008, and assigned to the assignee hereof and hereby expressly incorporated by reference herein.
- 1. Field
- The following description relates generally to wireless communications, and more particularly to compressing protocol headers in communicating using cell relays.
- 2. Background
- Wireless communication systems are widely deployed to provide various types of communication content such as, for example, voice, data, and so on. Typical wireless communication systems may be multiple-access systems capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, . . . ). Examples of such multiple-access systems may include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and the like. Additionally, the systems can conform to specifications such as third generation partnership project (3GPP), 3GPP long term evolution (LTE), ultra mobile broadband (UMB), and/or multi-carrier wireless specifications such as evolution data optimized (EV-DO), one or more revisions thereof, etc.
- Generally, wireless multiple-access communication systems may simultaneously support communication for multiple mobile devices. Each mobile device may communicate with one or more access points (e.g., base stations) via transmissions on forward and reverse links. The forward link (or downlink) refers to the communication link from access points to mobile devices, and the reverse link (or uplink) refers to the communication link from mobile devices to access points. Further, communications between mobile devices and access points may be established via single-input single-output (SISO) systems, multiple-input single-output (MISO) systems, multiple-input multiple-output (MIMO) systems, and so forth. Access points, however, can be limited in geographic coverage area as well as resources such that mobile devices near edges of coverage and/or devices in areas of high traffic can experience degraded quality of communications from an access point.
- Cell relays can be provided to expand network capacity and coverage area by facilitating communication between mobile devices and access points. For example, a cell relay can establish a backhaul link with a donor access point, which can provide access to a number of cell relays, and the cell relay can establish an access link with one or more mobile devices or additional cell relays. To mitigate modification to backend core network components, communication interfaces, such as S1-U, can terminate at the donor access point. Thus, the donor access point appears as a normal access point to backend network components. To this end, the donor access point can route packets from the backend network components to the cell relays for communicating to the mobile devices.
- The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
- In accordance with one or more aspects and corresponding disclosure thereof, various aspects are described in connection with facilitating compressing protocol headers to provide efficient communication among cell relays. In particular, robust header compression (RoHC) contexts for multiple evolved packet system (EPS) bearers can be supported over a single dedicated radio bearer of a cell relay. In one example, a single robust header compressor can be provided at one communication node and a single robust header decompressor at the other in relay communications. In this example, the multiple RoHC contexts for the given EPS bearers can be differentiated according to assigned context identifiers. In another example, multiple robust header compressors/decompressors can be provided at the communication nodes for each RoHC context, and a tunnel endpoint identifier (TEID) or similar identifier related to the EPS bearers (or corresponding UE bearers) can be utilized to differentiate EPS bearers at the nodes. In addition, to facilitate header compression within the RoHC contexts, a donor eNB can compress a tunneling protocol header in a packet received from an upstream network node for downstream communication of the packet.
- According to related aspects, a method is provided that includes receiving a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a dedicated radio bearer (DRB). The method also includes determining a RoHC context for the RoHC compressed header and decompressing the RoHC compressed header based at least in part on the RoHC context.
- Another aspect relates to a wireless communications apparatus. The wireless communications apparatus can include at least one processor configured to obtain a packet with a RoHC compressed header from one of a plurality of EPS bearers mapped to a DRB of the wireless communications apparatus and discern a RoHC context used for compression of the RoHC compressed header. The at least one processor is further configured to discern a RoHC context used for compression of the RoHC compressed header. The wireless communications apparatus also comprises a memory coupled to the at least one processor.
- Yet another aspect relates to an apparatus. The apparatus includes means for receiving a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB and means for determining a RoHC context for the RoHC compressed header. The apparatus also includes means for decompressing the RoHC compressed header based at least in part on the RoHC context.
- Still another aspect relates to a computer program product, which can have a computer-readable medium including code for causing at least one computer to receive a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB and code for causing the at least one computer to determine a RoHC context for the RoHC compressed header. The computer-readable medium can also comprise code for causing the at least one computer to decompress the RoHC compressed header based at least in part on the RoHC context.
- Moreover, an additional aspect relates to an apparatus including a bearer communicating component that receives a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to a DRB. The apparatus can further include a RoHC context determining component that discerns a RoHC context for the RoHC compressed header and a RoHC decompressing component that decompresses the RoHC compressed header based at least in part on the RoHC context.
- In another aspect, a method is provided that includes compressing a header of a packet received over an EPS bearer using RoHC based at least in part on a RoHC context and indicating an identifier related to the RoHC context in the packet. The method further includes transmitting the packet over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- Another aspect relates to a wireless communications apparatus. The wireless communications apparatus can include at least one processor configured to compress a header of a packet received over an EPS bearer based at least in part on a selected RoHC context and specify an identifier related to the selected RoHC context in the packet. The at least one processor is further configured to communicate the packet over a DRB to which the EPS bearer and one or more disparate EPS bearers in a core network are mapped. The wireless communications apparatus also comprises a memory coupled to the at least one processor.
- Yet another aspect relates to an apparatus. The apparatus includes means for compressing a header of a packet received over an EPS bearer based at least in part on a RoHC context and means for indicating an identifier related to the RoHC context in the packet. The apparatus also includes means for transmitting the header over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- Still another aspect relates to a computer program product, which can have a computer-readable medium including code for causing at least one computer to compress a header of a packet received over an EPS bearer using RoHC based at least in part on a RoHC context and code for causing the at least one computer to indicate an identifier related to the RoHC context in the packet. The computer-readable medium can also comprise code for causing the at least one computer to transmit the packet over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- Moreover, an additional aspect relates to an apparatus including a RoHC compressing component that compresses a header of a packet received over an EPS bearer using RoHC based at least in part on a RoHC context. The apparatus can further include a context identifying component that specifies an identifier related to the RoHC context in the packet and a bearer communicating component that transmits the header over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped.
- According to yet another aspect, a method is provided that includes receiving a packet from an upstream node comprising a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header. The method further includes compressing a header of the packet to include a compressed SGW IP address and transmitting the packet with the compressed header to a downstream node.
- Another aspect relates to a wireless communications apparatus. The wireless communications apparatus can include at least one processor configured to obtain a packet from an upstream node comprising a UDP, IP, or GTP header and associate a compressed header with the packet that includes a compressed SGW IP address. The at least one processor is further configured to transmit the packet with the compressed header to a downstream node. The wireless communications apparatus also comprises a memory coupled to the at least one processor.
- Yet another aspect relates to an apparatus. The apparatus includes means for receiving a packet from an upstream node comprising a UDP, IP, or GTP header and means for applying compression to a header of the packet to compress at least an SGW IP address. The apparatus also includes means for transmitting the packet with the compressed header to a downstream node.
- Still another aspect relates to a computer program product, which can have a computer-readable medium including code for causing at least one computer to receive a packet from an upstream node comprising a UDP, IP, or GTP header. The computer-readable medium can also comprise code for causing the at least one computer to compress a header of the packet to include a compressed SGW IP address and code for causing the at least one computer to transmit the packet with the compressed header to a downstream node.
- Moreover, an additional aspect relates to an apparatus including an IP packet receiving component that receives a packet from an upstream node comprising a UDP, IP, or GTP header and a header compressing component compresses a header of the packet at least in part by compressing an SGW IP address in the header. The apparatus can further include a bearer communicating component that transmits the packet with the compressed header to a downstream node.
- To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed and this description is intended to include all such aspects and their equivalents.
-
FIG. 1 is an illustration of an example wireless communications system that facilitates providing relays for wireless networks. -
FIG. 2 is an illustration of an example wireless communications system that facilitates compressing headers for cell relay communication using robust header compression (RoHC). -
FIG. 3 is an illustration of an example wireless communications system that communicates packets with RoHC compressed header for multiple EPS bearers over a single dedicated radio bearer (DRB). -
FIG. 4 is an illustration of an example wireless communications system that facilitates compressing headers using a RoHC context that corresponds to a downstream bearer identifier. -
FIG. 5 is an illustration of an example wireless communications system that communicates packets with RoHC headers compressed according to a RoHC context that corresponds to a downstream bearer identifier. -
FIG. 6 is an illustration of an example wireless communications system that encapsulates RoHC compressed packets for subsequent routing. -
FIG. 7 is an illustration of an example wireless communications system that utilizes cell relays to provide access to a wireless network. -
FIG. 8 is an illustration of example protocol stacks that facilitate providing cell relay functionality for data plane communications. -
FIG. 9 is an illustration of example protocol stacks that facilitate providing cell relay functionality for data plane communications using a relay protocol. -
FIG. 10 is an illustration of an example methodology for decompressing a RoHC compressed header based on a determined RoHC context. -
FIG. 11 is an illustration of an example methodology that compresses one or more packet headers using a RoHC context. -
FIG. 12 is an illustration of an example methodology that encapsulates a packet for subsequent routing. -
FIG. 13 is an illustration of an example methodology that determines an encapsulation for a received packet. -
FIG. 14 is an illustration of an example methodology that compresses a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header of a received packet. -
FIG. 15 is an illustration of a wireless communication system in accordance with various aspects set forth herein. -
FIG. 16 is an illustration of an example wireless network environment that can be employed in conjunction with the various systems and methods described herein. -
FIG. 17 is an illustration of an example system that facilitates decompressing a RoHC compressed header based on a determined RoHC context. -
FIG. 18 is an illustration of an example system that facilitates compressing a header according to a RoHC context. -
FIG. 19 is an illustration of an example system that facilitates compressing a UDP, IP, or GTP header. - Various aspects are now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects. It may be evident, however, that such aspect(s) may be practiced without these specific details.
- As used in this application, the terms “component,” “module,” “system” and the like are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal.
- Furthermore, various aspects are described herein in connection with a terminal, which can be a wired terminal or a wireless terminal A terminal can also be called a system, device, subscriber unit, subscriber station, mobile station, mobile, mobile device, remote station, remote terminal, access terminal, user terminal, terminal, communication device, user agent, user device, or user equipment (UE). A wireless terminal may be a cellular telephone, a satellite phone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, a computing device, or other processing devices connected to a wireless modem. Moreover, various aspects are described herein in connection with a base station. A base station may be utilized for communicating with wireless terminal(s) and may also be referred to as an access point, a Node B, evolved Node B (eNB), or some other terminology.
- Moreover, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from the context, the phrase “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, the phrase “X employs A or B” is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from the context to be directed to a singular form.
- The techniques described herein may be used for various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other systems. The terms “system” and “network” are often used interchangeably. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includes Wideband-CDMA (W-CDMA) and other variants of CDMA. Further, cdma2000 covers IS-2000, IS-95 and IS-856 standards. A TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). Additionally, cdma2000 and UMB are described in documents from an organization named “3rd
Generation Partnership Project 2” (3GPP2). Further, such wireless communication systems may additionally include peer-to-peer (e.g., mobile-to-mobile) ad hoc network systems often using unpaired unlicensed spectrums, 802.xx wireless LAN, BLUETOOTH and any other short- or long-range, wireless communication techniques. - Various aspects or features will be presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches may also be used.
- Referring to
FIG. 1 , awireless communication system 100 is illustrated that facilitates providing relay functionality in wireless networks.System 100 includes adonor eNB 102 that provides one or more relay eNBs, such asrelay eNB 104, with access to acore network 106. Similarly, relayeNB 104 can provide one or more disparate relay eNBs, such asrelay eNB 108, or UEs, such asUE 110, with access to thecore network 106 viadonor eNB 102.Donor eNB 102, which can also be referred to as a cluster eNB, can communicate with thecore network 106 over a wired or wireless backhaul link, which can be an LTE or other technology backhaul link. In one example, thecore network 106 can be a 3GPP LTE or similar technology network. -
Donor eNB 102 can additionally provide an access link forrelay eNB 104, which can also be wired or wireless, LTE or other technologies, and therelay eNB 104 can communicate with thedonor eNB 102 using a backhaul link over the access link of thedonor eNB 102.Relay eNB 104 can similarly provide an access link for relay eNB 108 and/orUE 110, which can be a wired or wireless LTE or other technology link. In one example,donor eNB 102 can provide an LTE access link, to whichrelay eNB 104 can connect using an LTE backhaul, and relayeNB 104 can provide an LTE access link to relayeNB 108 and/orUE 110.Donor eNB 102 can connect to thecore network 106 over a disparate backhaul link technology.Relay eNB 108 and/orUE 110 can connect to therelay eNB 104 using the LTE access link to receive access tocore network 106, as described. A donor eNB and connected relay eNBs can be collectively referred to herein as a cluster. - According to an example, relay
eNB 104 can connect to adonor eNB 102 at the link layer (e.g., media access control (MAC) layer) as would a UE in regular LTE configurations. In this regard,donor eNB 102 can be a regular LTE eNB requiring no changes at the link layer or related interface (e.g., E-UTRA-Uu) to support therelay eNB 104. In addition,relay eNB 104 can appear toUE 110 as a regular eNB at the link layer, such that no changes are required forUE 110 to connect to relayeNB 104 at the link layer, for example. In addition,relay eNB 104 can configure procedures for resource partitioning between access and backhaul link, interference management, idle mode cell selection for a cluster, and/or the like. - With respect to transport layer communications, transport protocols related to relay
eNB 108 orUE 110 communications can terminate at thedonor eNB 102, referred to as cell relay functionality, since therelay eNB 104 is like a cell of thedonor eNB 102. For example, in a cell relay configuration,donor eNB 102 can receive communications for therelay eNB 104 from thecore network 106, terminate the transport protocol, and forward the communications to therelay eNB 104 over a disparate transport layer keeping the application layer substantially intact. It is to be appreciated that the forwarding transport protocol type can be the same as the terminated transport protocol type, but is a different transport layer established with therelay eNB 104. -
Relay eNB 104 can determine a relay eNB or UE related to the communications, and provide the communications to the relay eNB or UE (e.g., based on an identifier thereof within the communications). Similarly,donor eNB 102 can terminate the transport layer protocol for communications received fromrelay eNB 104, translate the communications to a disparate transport protocol, and transmit the communications over the disparate transport protocol to thecore network 106 with the application layer intact forrelay eNB 104 as a cell relay. In these examples, whererelay eNB 104 is communicating with another relay eNB, therelay eNB 104 can support application protocol routing to ensure communications reach the correct relay eNB. - Moreover, application layer protocols can terminate at upstream eNBs. Thus, for example, application layer protocols for relay eNB 108 and
UE 110 can terminate atrelay eNB 104, and similarly forrelay eNB 104 can terminate atdonor eNB 102. The transport and application layer protocols, for example, can relate to S1-U, S1-MME, and/or X2 interfaces. S1-U interface can be utilized to communicate in a data plane between a node and a serving gateway (not shown) of thecore network 106. S1-MME interface can be utilized for control plane communications between a node and a mobility management entity (MME) (not shown) of thecore network 106. X2 interface can be utilized for communications between eNBs. In addition, for example,donor eNB 102 can communicate with other relay eNBs to allow communications therebetween over the access network (e.g., relayeNB 104 can communicate with one or more additional relay eNBs connected to donor eNB 102). - According to an example, relay eNB 104 (and relay eNB 108) can map multiple evolved packet system (EPS) bearers at
core network 106 to a single dedicated radio bearer (DRB) to support a plurality of downstream UEs, such asUE 110, and/or bearers related thereto. In addition,relay eNB 104 can support robust header compression (RoHC) for the multiple UE bearers. In one example,donor eNB 102 can have a single RoHC compressor and/or decompressor instance for a DRB ofrelay eNB 104, and relayeNB 104 can similarly have a single decompressor and/or compressor for a given dedicated radio bearer. In this example,donor eNB 102 can compress packet headers (e.g., internet protocol (IP), user datagram protocol (UDP) and/or similar packet headers) for multiple EPS bearers over a single DRB. For example,donor eNB 102 can insert a RoHC context identifier in the RoHC header, and therelay eNB 104 can differentiate the RoHC contexts based on the RoHC context identifiers. In this regard, relayeNB 104 can apply appropriate decompression to the headers. Similarly, relayeNB 104 can compress anddonor eNB 102 can decompress using the RoHC context identifiers. It is to be appreciated that a RoHC context can refer to a procedure utilized to compress one or more packet headers for efficient transmission thereof and can differ according to a type of bearer and/or data transmitted thereover, a destination node or type thereof, available resources, and/or the like. - In another example,
donor eNB 102 can have one or more RoHC compressors and/or decompressors for each EPS bearer mapped to the DRB ofrelay eNB 104. Similarly, relayeNB 104 can have one or more RoHC decompressors and/or compressors for each EPS bearer. In this example, a RoHC compressor of thedonor eNB 102 can compress the packet headers, anddonor eNB 102 can encapsulate the compressed IP header and the IP packet for a given EPS bearer in a tunneling protocol header that includes a tunnel endpoint identifier (TEID) related to the EPS bearer (and/or acorresponding UE 110 bearer). In one example, the tunneling protocol can be general packet radio service (GPRS) tunneling protocol (GTP)-U. In another example,donor eNB 102 can encapsulate the IP packet (or the GTP-U packet) in a relay protocol (RP) header that facilitates packet routing based on a relay identifier comprised in the RP packet header. - Upon receiving the encapsulated packet,
relay eNB 104 can extract the IP header and packet, for example, and one of the decompressors ofrelay eNB 104 can determine the RoHC context based at least in part on the TEID. In another example, one of the decompressors can determine the RoHC based additionally or alternatively on the relay identifier. In this regard, the decompressor can apply the appropriate decompression to the header. Similarly, relayeNB 104 can compress anddonor eNB 102 can decompress using TEID to determine RoHC context, as described. - In addition, it is to be appreciated that similar compression/decompression can be performed in
relay eNB 104 to relayeNB 108 communications (e.g., as related to a bearer of a UE communicating with relay eNB 108). Moreover, a header for the tunneling protocol can also be compressed. In one example, the header can include an address of an upstream network node, such as a serving gateway (SGW) that can be compressed. The tunneling protocol can be transmitted over a packet data convergence protocol (PDCP) layer with an associated IP packet. Thus, for example, PDCP configuration can be extended to include a payload type that specifies whether the packet has an IP, GTP-U, or RP header. - Turning now to
FIG. 2 , an examplewireless communication system 200 that facilitates RoHC for multiple EPS bearers mapped to a given cell relay bearer is illustrated.System 200 includes adonor eNB 102 that provides relay eNB 104 (and/or other relay eNBs) with access tocore network 106. Additionally, as described,relay eNB 104 can provide one or more devices, such asUE 110, and/or other relay eNBs with access to thecore network 106 through thedonor eNB 102. In addition, it is to be appreciated thatrelay eNB 104 can comprise the components ofdonor eNB 102, and vice versa, to provide similar functionality, in one example. Moreover,donor eNB 102 can be a macrocell access point, femtocell access point, picocell access point, mobile base station, and/or the like.Relay eNB 104 can similarly be mobile or stationary relay nodes that communicate withdonor eNB 102 over a wireless or wired backhaul, as described. -
Donor eNB 102 comprises a RoHCcontext selecting component 202 that determines a RoHC context or related identifier for packets received over an EPS bearer, aRoHC compressing component 204 that applies compression to packet headers received over the EPS bearer based at least in part on the RoHC context, a RoHCcontext indicating component 206 that specifies the selected RoHC context in a RoHC header of the compressed communication, and abearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.Relay eNB 104 can include abearer communicating component 210 that receives communications from and/or transmits communications to acore network 106 over an EPS bearer (e.g., through one or more upstream nodes), a RoHCcontext determining component 212 that obtains a RoHC context of packet headers received over a DRB mapped to one or more EPS bearers based at least in part on an identifier in the RoHC headers of the packets, and aRoHC decompressing component 214 that applies decompression to the packet headers based at least in part on the determined RoHC context. - According to an example,
donor eNB 102 can receive communications for relay eNB 104 (and/or one or more relay eNBs or devices, such asUE 110, communicating directly or indirectly therewith). For example,core network 106 can have previously established an EPS bearer that maps to a bearer ofUE 110.Relay eNB 104, as an intermediary node, can have established a bearer to whichcore network 106 that actually maps the EPS bearer and can forward data transmitted over the EPS bearer toUE 110. As described,relay eNB 104 can support multiple directly connected UEs as well as relay eNBs, which can have connected UEs or additional relay eNBs, etc. Thus, relayeNB 104 can be required to support a number of EPS bearers given a limited number of DRBs atrelay eNB 104. Thus, RoHC can be performed to support a number of EPS bearers over a single DRB. - In an example, once communications are received from
core network 106, RoHCcontext selecting component 202 can determine a RoHC context for the communications. In one example, this can be based at least in part on a type of the EPS bearer or related communications (e.g., voice, video, gaming, etc.), the relay eNB receiving the data (e.g., relayeNB 104 in this example), available system resources, and/or the like.RoHC compressing component 204 can apply a RoHC compression to the communications, or headers thereof, to facilitate efficient transmission of the communications over a DRB. In one example, theRoHC compressing component 204 can compress a header of an IP packet by removing or replacing one or more parameters in the IP packet header previously communicated to relayeNB 104. - This can include providing a RoHC header for the communications. In addition, the RoHC context can have an associated identifier, for example, that can be utilized to indicate and subsequently determine the RoHC context type. In this regard, RoHC
context indicating component 206 can insert the identifier in the header.Bearer communicating component 208 can provide the RoHC compressed communication to relayeNB 104 over a mapped DRB. As described, for example,bearer communicating component 208 can simultaneously provide additional RoHC compressed communications for disparate EPS bearers over the DRB. In one example,bearer communicating component 208 can provide the RoHC compressed communication to relayeNB 104 based at least in part on locating an association between an identifier of a tunneling protocol header of the communication and relayeNB 104 in a routing table. -
Bearer communicating component 210 can receive the RoHC compressed communications. RoHCcontext determining component 212 can evaluate an identifier in the RoHC header to determine the RoHC context.RoHC decompressing component 214 can decompress the communications, or related headers, based on the determined RoHC context, for example. It is to be appreciated, for example, that the RoHC context identifiers can be known by thedonor eNB 102 and/or relayeNB 104 according to a specification, configuration, previous communications, and/or the like. Additionally, using a RoHC context identifier mitigates the need to transmit other RoHC context information required for decompressing the RoHC packet, which decreases bandwidth requirements. Indeed, the context identifier can be specified as a small number of bits in the RoHC header. The RoHC context header, in one example, can relate not only to the type of communications and/or the related RoHC compression applied, but can also be specific to a corresponding destination node (e.g.,UE 110, or another relay eNB or UE communicating directly or indirectly with relay eNB 104). - Moreover, as described, the RoHC functionality for multiple EPS bearers mapped to a single DRB can be provided for
relay eNB 104 communicating with a downstream relay eNB. Indeed, substantially any two communicating nodes can utilize the components described herein having aRoHC compressing component 204 at one node and aRoHC decompressing component 214 at the other. The example shown withdonor eNB 102 communicating withrelay eNB 104 is but one possible implementation. - Referring to
FIG. 3 , an examplewireless communication system 300 for multiplexing multiple RoHC compressed EPS bearers over a single DRB is illustrated.System 300 includes adonor eNB 102 that provides wireless network access to relayeNB 104, as described.Donor eNB 102 can include a RoHC compressing/decompressing component 302 that provides a single instance of a RoHC compressor and decompressor for communicating multiple EPS bearer RoHC packets over asingle DRB 306 to relayeNB 104. Similarly, relayeNB 104 can include a RoHC compressing/decompressing component 304 that provides a single instance of a RoHC compressor and decompressor for communicating multiple EPS bearer RoHC packets over asingle DRB 306 todonor eNB 102. For example, as shown, RoHC compressing/decompressing component 302 can compress communications for EPS bearer 1 (e.g., received from a core network (not shown)) according to a RoHC context corresponding toidentifier 0, and can transmit the communication overDRB 306 as represented at 308. RoHC compressing/decompressing component 304 can decompress communications received fromEPS bearer 1 according to the RoHC context represented byidentifier 0. - Similarly, as described, RoHC compressing/
decompressing component 304 can compress communications to be transmitted overEPS bearer 1 according to RoHC context withidentifier 0 and transmit the compressed communications todonor eNB 102. RoHC compressing/decompressing component 302 can decompress the communications according to the RoHC context represented byidentifier 0, as described, for forwarding data comprised in the RoHC communication to a core network. As described, the RoHC contexts and associated identifiers can be known atdonor eNB 102 and/or relayeNB 104, such as according to a configuration, specification, and/or the like. - Similarly, RoHC compressing/
decompressing component 302 can compress/decompress communications overEPS bearer 2 using RoHC context withidentifier 1 at 310, communications overEPS bearer 3 using RoHC context withidentifier 2 at 310, communications overEPS bearer 4 using RoHC context withidentifier 3 at 310, and communications overEPS bearer 5 using RoHC context withidentifier 4 at 310 overDRB 306. In one example,RoHC context identifier 0 can be represented in the RoHC header as zero bytes. RoHC context identifiers, for example, can range from 0-15, where 1-15 can be represented as a 4-bit field in the RoHC header. Moreover, for example, the RoHC context identifiers can be extended to a larger number to balance a number of supported contexts with a desired bandwidth utilization. - Referring to
FIG. 4 , an examplewireless communication system 400 for communicating RoHC compressed headers for multiple EPS bearers over a single DRB is illustrated.System 400 includes adonor eNB 102 that provides relay eNB 104 (and/or other relay eNBs) with access tocore network 106. Additionally, as described,relay eNB 104 can provide one or more devices, such asUE 110, and/or other relay eNBs with access to thecore network 106 through thedonor eNB 102. In addition, it is to be appreciated thatrelay eNB 104 can comprise the components ofdonor eNB 102, and vice versa, to provide similar functionality, in one example. Moreover,donor eNB 102 can be a macrocell access point, femtocell access point, picocell access point, mobile base station, and/or the like.Relay eNB 104 can similarly be mobile or stationary relay nodes that communicate withdonor eNB 102 over a wireless or wired backhaul, as described. -
Donor eNB 102 comprises a RoHCcompression instance component 402 that initializes a RoHC compressor for compressing headers of one or more packets received fromcore network 106, apacket encapsulating component 404 that creates a tunneling protocol header for routing compressed header packets, anidentifier specifying component 406 that inserts a TEID or other relay identifier related to therelay eNB 104 in the tunneling protocol header to facilitate routing the packet, and abearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.Relay eNB 104 can include abearer communicating component 210 that receives communications from and/or transmits communications to acore network 106 over an EPS bearer (e.g., through one or more upstream nodes), anidentifier receiving component 408 that determines an identifier in a received tunneling protocol header, a RoHCcontext determining component 212 that discerns a RoHC context based at least in part on the identifier, and a RoHCdecompression instance component 410 that initializes a RoHC decompressor that can decompress packet headers based at least in part on the received identifier. - According to an example,
donor eNB 102 can receive communications for relay eNB 104 (and/or one or more relay eNBs or devices, such asUE 110, communicating directly or indirectly therewith). For example,core network 106 can have previously established an EPS bearer that maps to a bearer ofUE 110.Relay eNB 104, as an intermediary node, can have established a bearer to which core network 106 (e.g., that actually maps the EPS bearer) and can forward data transmitted over the EPS bearer toUE 110. As described,relay eNB 104 can support multiple directly connected UEs as well as relay eNBs, which can also have connected UEs or additional relay eNBs, etc. Thus, relayeNB 104 can be required to support a number of EPS bearers given a limited number of DRBs atrelay eNB 104. Thus, RoHC can be performed to support a number of EPS bearers over a single DRB. - In an example, once IP packets (or other packets) are received from
core network 106, RoHCcompression instance component 402 can create a RoHC compressor for the packet (and/or other packets received over the same EPS bearer, for example), which can compress the IP packet header according to one or more RoHC compression specifications.Packet encapsulating component 404 can create a tunneling protocol header for the RoHC packets. In one example, the tunneling protocol header can be a GTP-U header, an RP header, and/or the like, and can be compressed as well. In one example,packet encapsulating component 404 can encapsulate the IP header and packet in a GTP-U header, for example.Identifier specifying component 406 can include an identifier, such as a TEID or portion thereof, in the GTP-U header. Moreover, in another example,packet encapsulating component 404 can additionally encapsulate the entire packet along with the GTP-U header in a relay protocol packet.Identifier specifying component 406 can include a relay identifier in the relay protocol packet header. -
Bearer communicating component 208 can provide the encapsulated communication to relayeNB 104 over a mapped DRB. As described, for example,bearer communicating component 208 can simultaneously provide additional RoHC compressed communications for disparate EPS bearers over the DRB. In one example,bearer communicating component 208 can provide the encapsulated communication to relayeNB 104 based at least in part on locating an association between an identifier in a header of the communication (e.g., a TEID and/or relay identifier) and relayeNB 104 in a routing table. -
Bearer communicating component 210 can receive the encapsulated communication.Identifier receiving component 408 can determine an identifier in the tunneling protocol header (e.g., TEID and/or relay identifier, as described). RoHCcontext determining component 212 can determine a RoHC context utilized to compress the headers based at least in part on the identifier. RoHCdecompression instance component 410 can initialize a RoHC decompressor that decompresses the IP packet header, which can be extracted from the relay protocol payload in one example, according to the RoHC context. In this regard, additional RoHC context parameters need not be transmitted among thedonor eNB 102 and relayeNB 104; rather, relayeNB 104 can RoHC decompress the IP packet header based on the TEID or relay identifier ofrelay eNB 104. In addition, for example, a type of RoHC compression for the EPS bearer can be previously communicated betweendonor eNB 102 and relayeNB 104 and each node can store an association between the type of RoHC compression and the identifier ofrelay eNB 104. In another example, an EPS bearer type can be known atdonor eNB 102 and relayeNB 104, and the RoHC context can be based on the EPS bearer type. It is to be appreciated that the RoHC decompressor can similarly be utilized to decompress headers of additional IP packets received over the corresponding EPS bearer. - Moreover, as described, the RoHC functionality based on an identifier of
relay eNB 104 for multiple EPS bearers mapped to a single DRB can be provided forrelay eNB 104 communicating with a downstream relay eNB. Indeed, substantially any two communicating nodes can utilize the components described herein having a plurality of RoHC compressors at one node and a plurality of corresponding RoHC decompressors at the other. In addition,relay eNB 104 can perform the compressing anddonor eNB 102 the decompressing, in another example. The example shown withdonor eNB 102 communicating withrelay eNB 104 is but one possible implementation. - Referring to
FIG. 5 , an examplewireless communication system 500 for multiplexing multiple RoHC compressed EPS bearers over a single DRB based on an identifier ofrelay eNB 104 is illustrated.System 500 includes adonor eNB 102 that provides wireless network access to relayeNB 104, as described.Donor eNB 102 can include a RoHC compressing/decompressing component 502 that provides multipleRoHC compressing instances DRB 306. Similarly, relayeNB 104 can include a RoHC compressing/decompressing component 504 that provides multipleRoHC decompressing instances DRB 306. - For example, as shown,
RoHC compressing instance 506 can compress communications and/or related headers received overEPS bearer 1 using a RoHC context related to relay identifier AABB at 522. For example, the identifier can be an identifier assigned to relayeNB 104 and/or a related downstream bearer bydonor eNB 102, such as a TEID and/or relay identifier. In another example, the identifier can be a concatenation of a portion assigned bydonor eNB 102 to therelay eNB 104 or downstream bearer and a portion assigned by another node (e.g., relayeNB 104 for the downstream bearer). In any case, the identifier can be unique such thatRoHC decompressing instance 514 can determine and apply a RoHC decompression context to compress communications according to the identifier. - Similarly,
RoHC compressing instance 508 can compress communications overEPS bearer 2 according to identifier CCDD at 524, andRoHC decompressing instance 516 can decompress the compressed communications or related headers based on the identifier. In addition, as shown,RoHC compressing instance 510 can compress communications overEPS bearer 3 according to identifier EEFF at 526, andRoHC decompressing instance 518 can decompress the compressed communications or related headers based on the identifier. Moreover,RoHC compressing instance 512 can compress communications overEPS bearer 4 according to identifier GGHH at 528, andRoHC decompressing instance 520 can decompress the compressed communications or related headers based on the identifier. - Referring to
FIG. 6 , an examplewireless communication system 600 for compressing packet headers is illustrated.System 600 includes adonor eNB 102 that provides relay eNB 104 (and/or other relay eNBs) with access tocore network 106. Additionally, as described,relay eNB 104 can provide one or more devices, such asUE 110, and/or other relay eNBs with access to thecore network 106 through thedonor eNB 102. In addition, it is to be appreciated thatrelay eNB 104 can comprise the components ofdonor eNB 102, and vice versa, to provide similar functionality, in one example. Moreover,donor eNB 102 can be a macrocell access point, femtocell access point, picocell access point, mobile base station, and/or the like.Relay eNB 104 can similarly be mobile or stationary relay nodes that communicate withdonor eNB 102 over a wireless or wired backhaul, as described. -
Donor eNB 102 comprises an IPpacket receiving component 602 that obtains one or more IP packets fromcore network 106 for a downstream node, a tunnelingprotocol encapsulating component 604 that associates the IP packet and/or header with a tunneling protocol header for packet routing, aheader compressing component 606 that compresses one or more headers of the packet, and abearer communicating component 208 that transmits communications to and/or receives communications from a DRB of a relay eNB.Relay eNB 104 can include abearer communicating component 210 that receives communications from and/or transmits communications to acore network 106 over an EPS bearer (e.g., through one or more upstream nodes), aheader decompressing component 608 that decompresses one or more packet headers, and an IPpacket retrieving component 610 that determines an IP packet for providing toUE 110. - According to an example, IP
packet receiving component 602 can obtain an IP packet fromcore network 106 for providing toUE 110. In this regard, the IP packet can be received with a GTP-U header that includes an identifier related toUE 110. For example, at least a portion of the identifier can have been assigned bydonor eNB 102 to facilitate routing the packet through one or more intermediary relay eNBs. As described previously, in oneexample donor eNB 102 can RoHC compress one or more headers of the packet. Tunnelingprotocol encapsulating component 604 can create a tunneling protocol header for the IP packet. For example, the tunneling protocol header, as described, can be a compressed or uncompressed GTP-U header, RP header, and/or the like. In an example, tunnelingprotocol encapsulating component 604 can include an identifier in the header for subsequent packet routing (e.g., a TEID or related portion for a GTP-U header and/or a relay identifier in an RP header). -
Header compressing component 606 can apply compression to one or more of the headers (e.g., IP header, GTP-U header, UDP header, etc.) to reduce a size of the packet. In one example,header compressing component 606 can compress a GTP-U header of the received IP packet to a format similar to the following. -
Bits Octets 8 7 6 5 4 3 2 1 1 Version PT I E S PN 2 Message Type 3 Tunnel Endpoint Identifier (1st Octet) 4 Tunnel Endpoint Identifier (2nd Octet) 5 Tunnel Endpoint Identifier (3rd Octet) 6 Tunnel Endpoint Identifier (4th Octet) 7 Sequence Number (1st Octet)1)4) 8 Sequence Number (2nd Octet)1)4) 9 N-PDU Number2)4) 10 Next Extension Header Type3)4) 11 Compressed SGW IP address
where PT is the protocol type, I indicates whether the SGW IP address is present in the packet, E is an extension header flag that indicates whether the next extension header type field has a value, S is a sequence number flag that specifies whether the sequence number fields have a value, and PN is a flag that indicates whether the N-packet data unit (N-PDU) field has a value. Thus, for example, the compressed SGW IP address can be reduced to one byte. In this regard,donor eNB 102 and relayeNB 104 can have previously communicated the SGW address and assigned a one byte identifier to save bandwidth by not including the full address in the compressed GTP-U header (e.g. in a transport address translation response to a transport address translation request received from relay eNB 104). In another example,header compressing component 606 can compress the IP header. In addition, in a PDCP protocol utilized to carry the compressed GTP-U header or an IP header (e.g., where no encapsulation is applied),header compression component 606 can specify a type of the payload of the compressed packet (e.g., IP, GTP-U, RP, etc.). In this regard, a receiving entity can determine which header is compressed. -
Bearer communicating component 208 can transmit the compressed header packet to relayeNB 104. In one example, as described,bearer communicating component 208 can provide the packet to relayeNB 104 based at least in part on locating an association between an identifier of a tunneling protocol header (e.g., TEID, relay protocol, etc., as described) of the communication and relayeNB 104 in a routing table.Bearer communicating component 210 can receive the packet.Header decompressing component 608 can determine which header is compressed based at least in part on a type specified in the PDCP portion of the packet, as described, and can accordingly decompress the appropriate header. IPpacket retrieving component 610 can obtain the IP packet and corresponding header once the appropriate header is decompressed. In one example, IPpacket receiving component 602 can receive a packet with a packet structure similar to the following. -
L1/L2 UDP/IP Header GTP Header with TEID IP Packet of Relay eNB
where L1/L2 represents alayer 1/layer 2 portion of the packet. In this regard,header compressing component 606 can compress the GTP-U header and prepare the packet for transmitting to relayeNB 104 over an access link, resulting in a packet structure similar to the following, for example. -
L1/L2 RLC PDCP Compressed GTP Header IP Packet
Thus, for example,header compressing component 606 can additionally indicate that the packet has a compressed GTP-U header in the PDCP portion of the packet. Upon receiving the packet, as described,header decompressing component 608 can interpret the compressed GTP-U header, which can include a destination address for the packet, in one example, and IPpacket retrieving component 610 can generate a packet structure similar to the following for transmitting toUE 110. -
L1/L2 RLC PDCP IP Packet - It is to be appreciated that there can be intermediary relay eNBs (not shown) in the communications path between
donor eNB 102 and relayeNB 104. In this example, the intermediary relay eNBs can transmit the compressed GTP-U structure, shown above, without modifying the packet based at least in part on an identifier (e.g., TEID and/or relay identifier) in the structure. In addition, it is to be appreciated that uplink communications fromUE 110 todonor eNB 102 can similarly be compressed byrelay eNB 104 for transmission. In this example,donor eNB 102 can decompress the GTP-U header to create a GTP-U header with an identifier of acore network 106 component. - Now turning to
FIG. 7 , an examplewireless communication network 700 that provides cell relay functionality is depicted.Network 700 includes aUE 110 that communicates with arelay eNB 104, as described, to receive access to a wireless network.Relay eNB 104 can communicate with adonor eNB 102 using a relay protocol to provide access to a wireless network, and as described,donor eNB 102 can communicate with anMME 702 and/orSGW 704 that relate to therelay eNB 104.SGW 704 can connect to or be coupled with aPGW 706, which provides network access toSGW 704 and/or additional SGWs.PGW 706 can communicate with aPCRF 708 to authenticate/authorizeUE 110 to use the network, which can utilize anIMS 710 to provide addressing to theUE 110 and/or relayeNB 104. - According to an example,
MME 702 and/orSGW 704 andPGW 706 can be related todonor eNB 102 serving substantially all relay eNBs in the cluster.Donor eNB 102 can also communicate with anSGW 716 andPGW 718 that relate to theUE 110, such that thePGW 718 can assign UE 110 a network address to facilitate tunneling communications thereto through therelay eNB 104,donor eNB 102, andSGW 716. Moreover, for example,SGW 716 can communicate with anMME 714 to facilitate control plane communications to and from theUE 110. It is to be appreciated thatMME 702 andMME 714 can be the same MME, in one example.PGW 718 can similarly communicate with aPCRF 708 to authenticate/authorizeUE 110, which can communicate with anIMS 710. In addition,PGW 718 can communicate directly with theIMS 710 and/orinternet 712. - In an example,
UE 110 can communicate with therelay eNB 104 over an E-UTRA-Uu interface, as described, and therelay eNB 104 can communicate with thedonor eNB 102 using an E-UTRA-Uu interface or other interface using the relay protocol, as described herein.Donor eNB 102 communicates with theMME 702 using an S1-MME interface and theSGW 704 andPGW 706 over an S1-U interface, as depicted. In one example, as described, communications received fromrelay eNB 104 forMME 702 orSGW 704/PGW 706 can be over a relay protocol and can have an IP address ofMME 702 orSGW 704/PGW 706 in the relay protocol header.Donor eNB 102 can appropriately route the packet according to the IP address and/or payload type of the relay protocol. In another example, packets fromrelay eNB 104 can comprised a previously assigned TEID or portion thereof. In addition, the transport layers used over the S1-MME and S1-U interfaces are terminated at thedonor eNB 102, as described. In this regard, upon receiving communications for therelay eNB 104 from theMME 702 orSGW 704,donor eNB 102 can, for example, decouple the application layer from the transport layer by defining a new relay protocol packet, or other protocol layer packet, and transmitting the application layer communication to therelay eNB 104 in the new protocol packet (over the E-UTRA-Uu interface, in one example).Donor eNB 102 can transmit the packet to relay eNB 104 (and/or one or more disparate relay eNBs as described) based on a TEID in the packet or relay identifier in the header. - Upon transmitting control plane communications from the
relay eNB 104 to theMME 702,donor eNB 102 can indicate an identifier of the relay eNB 104 (e.g., in an S1-AP message), andMME 702 can transmit the identifier in responding communications to thedonor eNB 102. When transmitting data plane communications fromrelay eNB 104 toSGW 704,donor eNB 102 can insert an identifier for the relay eNB 104 (orUE 110 or one or more related bearers) in the TEID of a GTP-U header to identify the relay eNB 104 (orUE 110 or one or more related bearers). This can be an identifier generated forrelay eNB 104 bydonor eNB 102 such thatdonor eNB 102 can determine therelay eNB 104, or one or more downstream relay eNBs is to receive the translated packet, as described above. For example, this can be based at least in part on locating at least a portion of the identifier in a routing table atdonor eNB 102. In addition, headers can be compressed, in one example, as described. As shown,MME 702 can communicate withSGW 704, andMME 714 toSGW 716, using an S7 interface.PGWs PCRF 708 over a Gx interface. Furthermore,PCRF 708 can communicate withIMS 710 using an Rx interface, andPGW 718 can communicate withIMS 710 and/or theinternet 712 using an SGi interface. - Referring to
FIG. 8 , example protocol stacks 800 are illustrated that facilitate communicating in a wireless network to provide cell relay functionality for data (e.g., user) plane communications using a TEID for packet routing. AUE protocol stack 802 is shown comprising an L1 layer, MAC layer, an RLC layer, a PDCP layer, and an IP layer. A relay eNB (ReNB) accesslink protocol stack 804 is depicted having an L1 layer, MAC layer, RLC layer, and PDCP layer, as well as an ReNB backhaullink protocol stack 806 having an L1 layer, PDCP/RLC/MAC layer, and a C-GTP-U/UDP/IP layer, which can be a compressed layer in one example, to facilitate routing packets on the backhaul (e.g., by populating the TEID with the ReNB address, as described previously). A donor eNB (DeNB) accesslink protocol stack 808 is also shown having an L1 layer, PDCP/RLC/MAC layer, and a C-GTP/UDP/IP layer, as well as a DeNB backhaullink protocol stack 810 having an L1 layer, L2 layer, an IP layer, a UDP layer, and a GTP-U layer to maintain communications with a PGW/SGW using an address assigned by the PGW/SGW. PGW/SGW protocol stack 812 has an L1 layer, L2, layer, IP layer related to an address assigned to the DeNB, UDP layer, GTP-U layer, and another IP layer related to an address assigned to the UE. - According to an example, a UE can communicate with an ReNB to receive access to a PGW/SGW. In this regard, UE can communicate over L1, MAC, RLC, and PDCP layers with the ReNB over using a EUTRA-Uu interface, as shown between
protocol stacks protocol stacks protocol stacks protocol stacks - Referring to
FIG. 9 , example protocol stacks 900 are illustrated that facilitate communicating in a wireless network to provide cell relay functionality for data (e.g., user) plane communications using a relay protocol. AUE protocol stack 902 is shown comprising an L1 layer, MAC layer, an RLC layer, a PDCP layer, and an IP layer. A relay eNB 1 (ReNB) accesslink protocol stack 904 is depicted having an L1 layer, MAC layer, RLC layer, and PDCP layer, as well as an ReNB1 backhaullink protocol stack 906 having an L1 layer, MAC layer, RLC layer, PDCP layer, relay protocol (RP) layer, and a C-GTP-U/UDP/IP layer, which can be a compressed layer in one example, to facilitate communicating packets on the backhaul. An intermediary ReNB2 accesslink protocol stack 908 is shown having an L1 layer, MAC layer, RLC layer, PDCP layer, and RP layer, as well as a backhaullink protocol stack 910 for the intermediary ReNB2 having the same layers. - A DeNB access
link protocol stack 908 is also shown having an L1 layer, MAC layer, RLC layer, PDCP layer, RP layer, and a C-GTP/UDP/IP layer, as well as a DeNB backhaullink protocol stack 910 having an L1 layer, L2 layer, a UDP/IP layer, and a GTP-U layer to maintain communications with a PGW/SGW using an address assigned by the PGW/SGW. PGW/SGW protocol stack 912 has an L1 layer, L2, layer, UDP/IP layer related to an address assigned to the DeNB, GTP-U layer, and another IP layer related to an address assigned to the UE. - According to an example, a UE can communicate with an ReNB1 to receive access to a PGW/SGW. In this regard, UE can communicate over L1, MAC, RLC, and PDCP layers with the ReNB1 over using a EUTRA-Uu interface, as shown between
protocol stacks protocol stacks 902 and 916. To facilitate such tunneling,ReNB 1 communicates with ReNB2 over an RP, as described herein, on top of L1, MAC, RLC, PDCP layers using an S1-U-R interface (or other new interface for communicating using a relay protocol), as shown betweenprotocol stacks protocol stacks - ReNB2, and any other intermediary ReNBs, can forward the RP communication to the DeNB, as shown between protocol stack s 910 and 912. In this example, DeNB can receive the RP packet, over the lower layers, and can extract the C-GTP-U/UDP/IP packet from the payload and communicate with the PGW over separate GTP-U, UDP, and IP layers on top of L1 and L2 physical layers over an S1-U interface, as shown between
protocol stacks 914 and 916. In one example, the DeNB can include the relay identifier from the RP packet header in the GTP-U communications. Thus, as described, downlink communications from PGW/SGW protocol stack 912 can include the relay identifier. In this regard, upon receiving downlink communications from PGW/SGW protocol stack 916 over DeNB backhaullink protocol stack 914, DeNB accesslink protocol stack 912 can generate an RP packet with a header comprising the relay identifier received over PGW/SGW protocol stack 916 and a compressed GTP-U/UDP/IP packet as the payload. DeNB accesslink protocol stack 912 can transmit the RP packet over ReNB2 backhaullink protocol stack 912, which can forward the RP packet over ReNB2 accesslink protocol stack 908 to ReNB backhaullink protocol stack 906 based on the relay identifier in the RP header, as described. ReNB1 backhaullink protocol stack 906 can obtain the C-GTP-U/UDP/IP payload of the RP packet and forward toUE protocol stack 902, where the RP packet payload is of certain types, as described. - Referring to
FIGS. 10-14 , methodologies relating to compressing and/or encapsulating packets for transmission in a wireless network using cell relays are illustrated. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance with one or more aspects, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with one or more aspects. - Turning to
FIG. 10 , anexample methodology 1000 that facilitates decompressing a received header based at least in part on a RoHC context is illustrated. At 1002, a packet with a RoHC compressed header can be received from at least one of a plurality of EPS bearers mapped to a DRB. As described, the packet can be RoHC compressed according to a RoHC context. At 1004, the RoHC context for the RoHC compressed header can be determined. For example, the RoHC context can be determined based on an identifier in the RoHC header that relates to a RoHC compression context, an identifier at least partially related to a respective UE bearer, such as a TEID and/or relay identifier in a tunneling protocol header, and/or the like, as described. At 1006, the RoHC compressed header can be decompressed based at least in part on the RoHC context. For example, the decompression, as described, can be performed by a single decompressor that decompresses substantially all RoHC compressed headers received from an upstream node, a decompressor specific to the EPS bearer, and/or the like. Moreover, the RoHC contexts can relate to procedures utilized to compress the header that are known at the compression and decompression nodes, as described; the RoHC contexts can differ based on an EPS bearer type, data transmitted over the bearer, node type, available resources, and/or the like. - Referring to
FIG. 11 , anexample methodology 1100 is shown that facilitates RoHC compressing packet headers using a RoHC context. At 1102, a header of a packet received over an EPS bearer can be compressed based at least in part on a RoHC context. As described, the RoHC context can be selected based at least in part on a bearer type, data type, node type, etc. At 1104, an identifier related to the RoHC context can be indicated in the packet. In this regard, a decompressor can determine the RoHC context to utilize for decompressing the compressed header. At 1106, the packet can be transmitted over a DRB to which the EPS bearer and one or more disparate EPS bearers are mapped. - Turning to
FIG. 12 , anexample methodology 1200 that facilitates encapsulating a packet or header in a tunneling protocol is illustrated. At 1202, an IP packet can be received from a core network for transmitting to a UE bearer. For example, the IP packet can include a GTP header that specifies an identifier related at least in part to the UE bearer. At 1204, the IP header and/or packet can be encapsulated in a tunneling protocol header that includes an identifier related to the UE bearer. As described, where the IP header is RoHC compressed, the identifier can be utilized to determine a RoHC context for decompressing the header. For example, the tunneling protocol header can be a compressed or uncompressed GTP-U header, an RP header, etc., and the identifier can be a TEID, relay identifier, or portion thereof, etc. At 1206, a tunneling protocol header type can be indicated in a PDCP portion of the packet. In this regard, a receiving node can determine the encapsulated packet type to retrieve the IP packet and header. At 1208, the packet can be transmitted to one or more relay nodes in a communications path to the UE. As described, the one or more relay nodes can be determined from the identifier in the tunneling protocol header (e.g., as indicated in a routing table, in one example). - Referring to
FIG. 13 , anexample methodology 1300 that facilitates obtaining an IP packet and header from an encapsulated packet is illustrated. At 1302, a packet encapsulated in a tunneling protocol header can be received. At 1304, a type of the tunneling protocol header can be determined from an indicator in the PDCP portion of the packet. For example, the indicator can specify a compressed GTP-U, RP, IP, or similar type. Based on the type, at 1306, an IP packet and header can be retrieved from the packet. For example, if the packet or header is RoHC compressed, and the indicator specifies compressed GTP-U, the GTP-U header can be decompressed and the IP packet and header retrieved from the payload. If the type is RP, the IP packet and header can be retrieved as the payload of the RP packet, for example. - Referring to
FIG. 14 , anexample methodology 1400 that facilitates compressing a UDP, IP, and/or GTP header of a packet is illustrated. At 1402, a packet can be received from an upstream node comprising a UDP, IP, or GTP header. At 1404, the header of the packet can be compressed to include a compressed SGW IP address. As described, for example, an SGW IP address in a header received from a core network can be compressed to a one byte or other smaller sized value previously communicated to a downstream node (e.g., in a transport address translation response). In this regard, the compressed header can require less bandwidth for transmission. It is to be appreciated that the header can include additional fields and/or the additional fields can be compressed as well. At 1406, the packet with the compressed header can be transmitted to a downstream node. - It will be appreciated that, in accordance with one or more aspects described herein, inferences can be made regarding determining a RoHC context and/or related identifier, associating a RoHC context with a TEID or relay identifier, and/or other aspects described herein. As used herein, the term to “infer” or “inference” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.
- Referring now to
FIG. 15 , a wireless communication system 1500 is illustrated in accordance with various embodiments presented herein. System 1500 comprises a base station 1502 that can include multiple antenna groups. For example, one antenna group can include antennas 1504 and 1506, another group can comprise antennas 1508 and 1510, and an additional group can include antennas 1512 and 1514. Two antennas are illustrated for each antenna group; however, more or fewer antennas can be utilized for each group. Base station 1502 can additionally include a transmitter chain and a receiver chain, each of which can in turn comprise a plurality of components associated with signal transmission and reception (e.g., processors, modulators, multiplexers, demodulators, demultiplexers, antennas, etc.), as will be appreciated by one skilled in the art. - Base station 1502 can communicate with one or more mobile devices such as mobile device 1516 and mobile device 1522; however, it is to be appreciated that base station 1502 can communicate with substantially any number of mobile devices similar to mobile devices 1516 and 1522. Mobile devices 1516 and 1522 can be, for example, cellular phones, smart phones, laptops, handheld communication devices, handheld computing devices, satellite radios, global positioning systems, PDAs, and/or any other suitable device for communicating over wireless communication system 1500. As depicted, mobile device 1516 is in communication with antennas 1512 and 1514, where antennas 1512 and 1514 transmit information to mobile device 1516 over a forward link 1518 and receive information from mobile device 1516 over a reverse link 1520. Moreover, mobile device 1522 is in communication with antennas 1504 and 1506, where antennas 1504 and 1506 transmit information to mobile device 1522 over a forward link 1524 and receive information from mobile device 1522 over a reverse link 1526. In a frequency division duplex (FDD) system, forward link 1518 can utilize a different frequency band than that used by reverse link 1520, and forward link 1524 can employ a different frequency band than that employed by reverse link 1526, for example. Further, in a time division duplex (TDD) system, forward link 1518 and reverse link 1520 can utilize a common frequency band and forward link 1524 and reverse link 1526 can utilize a common frequency band.
- Each group of antennas and/or the area in which they are designated to communicate can be referred to as a sector of base station 1502. For example, antenna groups can be designed to communicate to mobile devices in a sector of the areas covered by base station 1502. In communication over forward links 1518 and 1524, the transmitting antennas of base station 1502 can utilize beamforming to improve signal-to-noise ratio of forward links 1518 and 1524 for mobile devices 1516 and 1522. Also, while base station 1502 utilizes beamforming to transmit to mobile devices 1516 and 1522 scattered randomly through an associated coverage, mobile devices in neighboring cells can be subject to less interference as compared to a base station transmitting through a single antenna to all its mobile devices. Moreover, mobile devices 1516 and 1522 can communicate directly with one another using a peer-to-peer or ad hoc technology (not shown).
- According to an example, system 1500 can be a multiple-input multiple-output (MIMO) communication system. Further, system 1500 can utilize substantially any type of duplexing technique to divide communication channels (e.g., forward link, reverse link, . . . ) such as FDD, FDM, TDD, TDM, CDM, and the like. In addition, communication channels can be orthogonalized to allow simultaneous communication with multiple devices over the channels; in one example, OFDM can be utilized in this regard. Thus, the channels can be divided into portions of frequency over a period of time. In addition, frames can be defined as the portions of frequency over a collection of time periods; thus, for example, a frame can comprise a number of OFDM symbols. The base station 1502 can communicate to the mobile devices 1516 and 1522 over the channels, which can be create for various types of data. For example, channels can be created for communicating various types of general communication data, control data (e.g., quality information for other channels, acknowledgement indicators for data received over channels, interference information, reference signals, etc.), and/or the like.
-
FIG. 16 shows an examplewireless communication system 1600. Thewireless communication system 1600 depicts onebase station 1610 and onemobile device 1650 for sake of brevity. However, it is to be appreciated thatsystem 1600 can include more than one base station and/or more than one mobile device, wherein additional base stations and/or mobile devices can be substantially similar or different fromexample base station 1610 andmobile device 1650 described below. In addition, it is to be appreciated thatbase station 1610 and/ormobile device 1650 can employ the systems (FIGS. 1-7 and 15), protocol stacks (FIG. 8-9 ) and/or methods (FIGS. 10-14 ) described herein to facilitate wireless communication therebetween. - At
base station 1610, traffic data for a number of data streams is provided from adata source 1612 to a transmit (TX)data processor 1614. According to an example, each data stream can be transmitted over a respective antenna.TX data processor 1614 formats, codes, and interleaves the traffic data stream based on a particular coding scheme selected for that data stream to provide coded data. - The coded data for each data stream can be multiplexed with pilot data using orthogonal frequency division multiplexing (OFDM) techniques. Additionally or alternatively, the pilot symbols can be frequency division multiplexed (FDM), time division multiplexed (TDM), or code division multiplexed (CDM). The pilot data is typically a known data pattern that is processed in a known manner and can be used at
mobile device 1650 to estimate channel response. The multiplexed pilot and coded data for each data stream can be modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM), etc.) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream can be determined by instructions performed or provided byprocessor 1630. - The modulation symbols for the data streams can be provided to a
TX MIMO processor 1620, which can further process the modulation symbols (e.g., for OFDM).TX MIMO processor 1620 then provides NT modulation symbol streams to NT transmitters (TMTR) 1622 a through 1622 t. In various aspects,TX MIMO processor 1620 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted. - Each transmitter 1622 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Further, NT modulated signals from
transmitters 1622 a through 1622 t are transmitted from NT antennas 1624 a through 1624 t, respectively. - At
mobile device 1650, the transmitted modulated signals are received by NR antennas 1652 a through 1652 r and the received signal from each antenna 1652 is provided to a respective receiver (RCVR) 1654 a through 1654 r. Each receiver 1654 conditions (e.g., filters, amplifies, and downconverts) a respective signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream. - An
RX data processor 1660 can receive and process the NR received symbol streams from NR receivers 1654 based on a particular receiver processing technique to provide NT “detected” symbol streams.RX data processor 1660 can demodulate, deinterleave, and decode each detected symbol stream to recover the traffic data for the data stream. The processing byRX data processor 1660 is complementary to that performed byTX MIMO processor 1620 andTX data processor 1614 atbase station 1610. - A
processor 1670 can periodically determine which precoding matrix to utilize as discussed above. Further,processor 1670 can formulate a reverse link message comprising a matrix index portion and a rank value portion. - The reverse link message can comprise various types of information regarding the communication link and/or the received data stream. The reverse link message can be processed by a
TX data processor 1638, which also receives traffic data for a number of data streams from adata source 1636, modulated by amodulator 1680, conditioned bytransmitters 1654 a through 1654 r, and transmitted back tobase station 1610. - At
base station 1610, the modulated signals frommobile device 1650 are received by antennas 1624, conditioned by receivers 1622, demodulated by ademodulator 1640, and processed by aRX data processor 1642 to extract the reverse link message transmitted bymobile device 1650. Further,processor 1630 can process the extracted message to determine which precoding matrix to use for determining the beamforming weights. -
Processors base station 1610 andmobile device 1650, respectively.Respective processors memory Processors - It is to be understood that the aspects described herein can be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.
- When the aspects are implemented in software, firmware, middleware or microcode, program code or code segments, they can be stored in a machine-readable medium, such as a storage component. A code segment can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, etc.
- For a software implementation, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes can be stored in memory units and executed by processors. The memory unit can be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.
- With reference to
FIG. 17 , illustrated is asystem 1700 that facilitates decompressing RoHC headers in one or more received packets. For example,system 1700 can reside at least partially within a base station, mobile device, etc. It is to be appreciated thatsystem 1700 is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware).System 1700 includes alogical grouping 1702 of electrical components that can act in conjunction. For instance,logical grouping 1702 can include an electrical component for receiving a packet with a RoHC compressed header from at least one of a plurality of EPS bearers mapped to aDRB 1704. As described,system 1700 can support a number of UEs and thus can map the EPS bearers provided by a core network to single bearers. Additionally,logical grouping 1702 can include an electrical component for determining a RoHC context for the RoHCcompressed header 1706. As described, this can include analyzing an identifier in the RoHC header that indicates a RoHC context used for compression, determining an identifier related at least in part to a downstream UE bearer that indicates the RoHC context, and/or the like. - Moreover,
logical grouping 1702 can include an electrical component for decompressing the RoHC compressed header based at least in part on theRoHC context 1708. In addition, for example,logical grouping 1702 can include an electrical component for extracting an identifier relating to a UE bearer the corresponds to the EPS bearer from a tunneling protocol header that encapsulates thepacket 1710. For example, the tunneling protocol can be a GTP-U, RP, and/or similar protocol, and the identifier, as described can be a TEID, relay identifier, or portion thereof. The identifier can relate to the RoHC context, as described previously. Additionally,system 1700 can include amemory 1712 that retains instructions for executing functions associated withelectrical components memory 1712, it is to be understood that one or more ofelectrical components memory 1712. - With reference to
FIG. 18 , illustrated is asystem 1800 that facilitates RoHC compressing packet headers for efficient transmission of related packets in a wireless network that utilizes cell relays. For example,system 1800 can reside at least partially within a base station, mobile device, etc. It is to be appreciated thatsystem 1800 is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware).System 1800 includes alogical grouping 1802 of electrical components that can act in conjunction. For instance,logical grouping 1802 can include an electrical component for compressing a header of a packet received over an EPS bearer based at least in part on aRoHC context 1804. For example, as described, the RoHC context can vary depending on one or more factors relating tosystem 1800, core network, and/or the like, such as EPS bearer type, data type transmitted over the EPS bearer, node type, available resources, etc. Additionally,logical grouping 1802 can include an electrical component for indicating an identifier related to the RoHC context in thepacket 1806. As described, this can include a RoHC context identifier in a RoHC header, an identifier related at least in part to a UE bearer indicated in a tunneling protocol header (e.g., a TEID or relay identifier in a GTP-U or RP header), and/or the like. - Moreover,
logical grouping 1802 can include an electrical component for transmitting the packet header over a DRB to which the EPS bearer and one or more additional EPS bearers are mapped 1808. In addition,logical grouping 1802 can include an electrical component for selecting theRoHC context 1810. This can be based on one or more of the described parameters, in one example, provisioned from a core network, and/or the like. Further,logical grouping 1802 can include an electrical component for encapsulating the header or the packet in atunneling protocol header 1812. As described, this can be a GTP-U header, an RP header, and/or the like, to facilitate packet routing among various cell relays. Additionally,system 1800 can include amemory 1814 that retains instructions for executing functions associated withelectrical components memory 1814, it is to be understood that one or more ofelectrical components memory 1814. - With reference to
FIG. 19 , illustrated is asystem 1900 that facilitates compressing UDP, IP, or GTP headers in received packets for forwarding to downstream nodes. For example,system 1900 can reside at least partially within a base station, mobile device, etc. It is to be appreciated thatsystem 1900 is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware).System 1900 includes alogical grouping 1902 of electrical components that can act in conjunction. For instance,logical grouping 1902 can include an electrical component for receiving a packet from an upstream node comprising a UDP, IP, orGTP header 1904. Additionally,logical grouping 1902 can include an electrical component for applying compression to a header of the packet to compress at least anSGW IP address 1906. - As described, compressing the SGW IP address can include utilizing a compressed version of the SGW IP address negotiated during a transport address translation request/response procedure with
system 1900. Moreover,logical grouping 1902 can include an electrical component for transmitting the packet with the compressed header to adownstream node 1908. Utilizing the compressed header, as described, can conserve bandwidth for more efficient transmitting. Additionally,system 1900 can include amemory 1910 that retains instructions for executing functions associated withelectrical components memory 1910, it is to be understood that one or more ofelectrical components memory 1910. - The various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Additionally, at least one processor may comprise one or more modules operable to perform one or more of the steps and/or actions described above.
- Further, the steps and/or actions of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor, such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. Further, in some aspects, the processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal. Additionally, in some aspects, the steps and/or actions of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which may be incorporated into a computer program product.
- In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection may be termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
- While the foregoing disclosure discusses illustrative aspects and/or embodiments, it should be noted that various changes and modifications could be made herein without departing from the scope of the described aspects and/or embodiments as defined by the appended claims. Furthermore, although elements of the described aspects and/or embodiments may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, all or a portion of any aspect and/or embodiment may be utilized with all or a portion of any other aspect and/or embodiment, unless stated otherwise. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim. Furthermore, although elements of the described aspects and/or aspects may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, all or a portion of any aspect and/or embodiment may be utilized with all or a portion of any other aspect and/or embodiment, unless stated otherwise.
Claims (82)
1. A method, comprising:
receiving a packet with a robust header compression (RoHC) compressed header from at least one of a plurality of evolved packet system (EPS) bearers mapped to a dedicated radio bearer (DRB);
determining a RoHC context for the RoHC compressed header; and
decompressing the RoHC compressed header based at least in part on the RoHC context.
2. The method of claim 1 , wherein the determining the RoHC context includes obtaining a RoHC context identifier from a RoHC header of the packet.
3. The method of claim 1 , further comprising obtaining an identifier for routing the packet from a tunneling protocol header, wherein the packet or the RoHC compressed header is encapsulated in the tunneling protocol header.
4. The method of claim 3 , wherein the determining the RoHC context includes determining the RoHC context based at least in part on the identifier.
5. The method of claim 4 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header and the identifier is a tunnel endpoint identifier (TEID).
6. The method of claim 4 , wherein the tunneling protocol header is a relay protocol header and the identifier is a relay identifier assigned by a donor evolved Node B (eNB).
7. The method of claim 1 , further comprising providing an internet protocol (IP) header and a related IP packet to a downstream user equipment (UE), wherein decompressing the RoHC compressed header yields the IP header.
8. A wireless communications apparatus, comprising:
at least one processor configured to:
obtain a packet with a robust header compression (RoHC) compressed header from one of a plurality of evolved packet system (EPS) bearers mapped to a dedicated radio bearer (DRB) of the wireless communications apparatus;
discern a RoHC context used for compression of the RoHC compressed header; and
decompress the RoHC compressed header according to the RoHC context; and
a memory coupled to the at least one processor.
9. The wireless communications apparatus of claim 8 , wherein the at least one processor discerns the RoHC context based at least in part on a RoHC context identifier in a header of the packet with the RoHC compressed header.
10. The wireless communications apparatus of claim 8 , wherein the at least one processor is further configured to extract an identifier having at least a portion relating to a corresponding user equipment (UE) bearer from a tunneling protocol header within which the packet or the RoHC compressed header is encapsulated.
11. The wireless communications apparatus of claim 10 , wherein the at least one processor discerns the RoHC context based at least in part on the identifier.
12. The wireless communications apparatus of claim 11 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header and the identifier is a tunnel endpoint identifier (TEID).
13. The wireless communications apparatus of claim 11 , wherein the tunneling protocol header is a relay protocol header and the identifier is a relay identifier assigned by a donor evolved Node B (eNB).
14. An apparatus, comprising:
means for receiving a packet with a robust header compression (RoHC) compressed header from at least one of a plurality of evolved packet system (EPS) bearers mapped to a dedicated radio bearer (DRB);
means for determining a RoHC context for the RoHC compressed header; and
means for decompressing the RoHC compressed header based at least in part on the RoHC context.
15. The apparatus of claim 14 , wherein the means for determining the RoHC context determines the RoHC context based at least in part on a RoHC context identifier in a RoHC header of the packet.
16. The apparatus of claim 14 , further comprising means for extracting an identifier relating to a user equipment (UE) bearer that corresponds to the at least one of the plurality of EPS bearers from a tunneling protocol header that encapsulates the packet.
17. The apparatus of claim 16 , wherein the means for determining the RoHC context determines the RoHC context based at least in part on the identifier.
18. The apparatus of claim 17 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header and the identifier is a tunnel endpoint identifier (TEID).
19. The apparatus of claim 17 , wherein the tunneling protocol header is a relay protocol header and the identifier is a relay identifier.
20. A computer program product, comprising:
a computer-readable medium comprising:
code for causing at least one computer to receive a packet with a robust header compression (RoHC) compressed header from at least one of a plurality of evolved packet system (EPS) bearers mapped to a dedicated radio bearer (DRB);
code for causing the at least one computer to determine a RoHC context for the RoHC compressed header; and
code for causing the at least one computer to decompress the RoHC compressed header based at least in part on the RoHC context.
21. The computer program product of claim 20 , wherein the code for causing the at least one computer to determine the RoHC context obtains a RoHC context identifier from a RoHC header of the packet.
22. The computer program product of claim 20 , wherein the computer-readable medium further comprises code for causing the at least one computer to obtain a local identifier from a tunneling protocol header, wherein the packet is encapsulated in the tunneling protocol header.
23. The computer program product of claim 22 , wherein the code for causing the at least one computer to determine the RoHC context determines the RoHC context based at least in part on the local identifier.
24. The computer program product of claim 23 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header and the local identifier is a tunnel endpoint identifier (TEID).
25. The computer program product of claim 23 , wherein the tunneling protocol header is a relay protocol header and the local identifier is a relay identifier assigned by a donor evolved Node B (eNB).
26. An apparatus, comprising:
a bearer communicating component that receives a packet with a robust header compression (RoHC) compressed header from at least one of a plurality of evolved packet system (EPS) bearers mapped to a dedicated radio bearer (DRB);
a RoHC context determining component that discerns a RoHC context for the RoHC compressed header; and
a RoHC decompressing component that decompresses the RoHC compressed header based at least in part on the RoHC context.
27. The apparatus of claim 26 , wherein the RoHC context determining component discerns the RoHC context based at least in part on a RoHC context identifier in a RoHC header of the packet.
28. The apparatus of claim 26 , further comprising an identifier receiving component that extracts an identifier relating to a user equipment (UE) bearer that corresponds to the at least one of the plurality of EPS bearers from a tunneling protocol header that encapsulates the packet.
29. The apparatus of claim 28 , wherein the RoHC context determining component discerns the RoHC context based at least in part on the identifier.
30. The apparatus of claim 29 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header and the identifier is a tunnel endpoint identifier (TEID).
31. The apparatus of claim 29 , wherein the tunneling protocol header is a relay protocol header and the identifier is a relay identifier.
32. A method, comprising:
compressing a header of a packet received over an evolved packet system (EPS) bearer using robust header compression (RoHC) based at least in part on a RoHC context;
indicating an identifier related to the RoHC context in the packet; and
transmitting the packet over a dedicated radio bearer (DRB) to which the EPS bearer and one or more additional EPS bearers are mapped.
33. The method of claim 32 , further comprising selecting a RoHC context identifier for the packet, wherein the compressing the header using RoHC is based at least in part on the RoHC context identifier.
34. The method of claim 33 , wherein the indicating the identifier includes specifying the RoHC context identifier in a RoHC header of the packet.
35. The method of claim 32 , further comprising encapsulating the header or the packet in a tunneling protocol header, wherein the indicating the identifier includes specifying the identifier in the tunneling protocol header.
36. The method of claim 35 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header, and the identifier is a tunnel endpoint identifier (TEID).
37. The method of claim 35 , wherein the tunneling protocol header is a relay protocol header, and the identifier is a relay identifier assigned by a donor evolved Node B (eNB).
38. The method of claim 32 , wherein the packet is an IP packet received from a core network for communicating to a user equipment (UE).
39. A wireless communications apparatus, comprising:
at least one processor configured to:
compress a header of a packet received over an evolved packet system (EPS) bearer based at least in part on a selected robust header compression (RoHC) context;
specify an identifier related to the selected RoHC context in the packet; and
communicate the packet over a dedicated radio bearer (DRB) to which the EPS bearer and one or more disparate EPS bearers in a core network are mapped; and
a memory coupled to the at least one processor.
40. The wireless communications apparatus of claim 39 , wherein the at least one processor is further configured to select a RoHC context identifier for the packet and the selected RoHC context relates to the RoHC context identifier.
41. The wireless communications apparatus of claim 40 , wherein the identifier is a RoHC context identifier in a RoHC header of the packet.
42. The wireless communications apparatus of claim 39 , wherein the at least one processor is further configured to encapsulate the header or the packet in a tunneling protocol header, and the identifier is related to a relay evolved Node B (eNB) that provides the DRB specified in the tunneling protocol header.
43. The wireless communications apparatus of claim 42 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header, and the identifier is a tunnel endpoint identifier (TEID).
44. The wireless communications apparatus of claim 42 , wherein the tunneling protocol header is a relay protocol header, and the identifier is a relay identifier.
45. An apparatus, comprising:
means for compressing a header of a packet received over an evolved packet system (EPS) bearer based at least in part on a robust header compression (RoHC) context;
means for indicating an identifier related to the RoHC context in the packet; and
means for transmitting the header over a dedicated radio bearer (DRB) to which the EPS bearer and one or more additional EPS bearers are mapped.
46. The apparatus of claim 45 , further comprising means for selecting the RoHC context.
47. The apparatus of claim 46 , wherein the means for indicating the identifier specifies an identifier of the RoHC context in a RoHC header of the packet.
48. The apparatus of claim 45 , further comprising means for encapsulating the header or the packet in a tunneling protocol header, wherein the means for indicating the identifier specifies the identifier in the tunneling protocol header.
49. The apparatus of claim 48 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header, and the identifier is a tunnel endpoint identifier (TEID).
50. The apparatus of claim 48 , wherein the tunneling protocol header is a relay protocol header, and the identifier is a relay identifier.
51. A computer program product, comprising:
a computer-readable medium comprising:
code for causing at least one computer to compress a header of a packet received over an evolved packet system (EPS) bearer using robust header compression (RoHC) based at least in part on a RoHC context;
code for causing the at least one computer to indicate an identifier related to the RoHC context in the packet; and
code for causing the at least one computer to transmit the packet over a dedicated radio bearer (DRB) to which the EPS bearer and one or more additional EPS bearers are mapped.
52. The computer program product of claim 51 , wherein the computer-readable medium further comprises code for causing the at least one computer to select a RoHC context identifier for the packet, wherein the code for causing the at least one computer to compress the header using RoHC compresses the header based at least in part on the RoHC context identifier.
53. The computer program product of claim 52 , wherein the code for causing the at least one computer to indicate the identifier specifies the RoHC context identifier in a RoHC header of the packet.
54. The computer program product of claim 51 , wherein the computer-readable medium further comprises code for causing the at least one computer to encapsulate the header or the packet in a tunneling protocol header, wherein the code for causing the at least one computer to indicate the identifier specifies the identifier in the tunneling protocol header.
55. The computer program product of claim 54 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header, and the identifier is a tunnel endpoint identifier (TEID).
56. The computer program product of claim 54 , wherein the tunneling protocol header is a relay protocol header, and the identifier is a relay identifier assigned by a donor evolved Node B (eNB).
57. An apparatus, comprising:
a robust header compression (RoHC) compressing component that compresses a header of a packet received over an evolved packet system (EPS) bearer using RoHC based at least in part on a RoHC context;
a context identifying component that specifies an identifier related to the RoHC context in the packet; and
a bearer communicating component that transmits the header over a dedicated radio bearer (DRB) to which the EPS bearer and one or more additional EPS bearers are mapped.
58. The apparatus of claim 57 , further comprising a RoHC context selecting component that determines the RoHC context.
59. The apparatus of claim 58 , wherein the context identifying component is a RoHC context indicating component that specifies an identifier of the RoHC context in a RoHC header of the packet.
60. The apparatus of claim 57 , further comprising a packet encapsulating component that inserts the header or the packet in a tunneling protocol header, wherein the context identifying component is an identifier specifying component that indicates the identifier in the tunneling protocol header.
61. The apparatus of claim 60 , wherein the tunneling protocol header is a general packet radio service (GPRS) tunneling protocol (GTP)-U header, and the identifier is a tunnel endpoint identifier (TEID).
62. The apparatus of claim 60 , wherein the tunneling protocol header is a relay protocol header, and the identifier is a relay identifier.
63. A method, comprising:
receiving a packet from an upstream node comprising a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header;
compressing the header of the packet to include a compressed serving gateway (SGW) IP address; and
transmitting the packet with the compressed header to a downstream node.
64. The method of claim 63 , wherein the compressed SGW IP address is of a smaller size than an SGW IP address specified in the header before compression.
65. The method of claim 63 , further comprising generating the compressed SGW IP address based at least in part on a transport address translation request received from the downstream node.
66. The method of claim 63 , wherein the compressing the header further comprises compressing the header to include a message type, a tunnel endpoint identifier (TEID), a sequence number, a N-packet data unit (PDU) number, or a next extension header type.
67. A wireless communications apparatus, comprising:
at least one processor configured to:
obtain a packet from an upstream node comprising a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header;
associate a compressed header with the packet that includes a compressed serving gateway (SGW) IP address; and
transmit the packet with the compressed header to a downstream node; and
a memory coupled to the at least one processor.
68. The wireless communications apparatus of claim 67 , wherein the compressed SGW IP address is of a smaller size than an SGW IP address specified in the header of the packet.
69. The wireless communications apparatus of claim 67 , wherein the at least one processor is further configured to generate the compressed SGW IP address based at least in part on a transport address translation request received from the downstream node.
70. The wireless communications apparatus of claim 67 , wherein the compressed header additionally includes a message type, a tunnel endpoint identifier (TEID), a sequence number, a N-packet data unit (PDU) number, or a next extension header type.
71. An apparatus, comprising:
means for receiving a packet from an upstream node comprising a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header;
means for applying compression to the header of the packet to compress at least an serving gateway (SGW) IP address; and
means for transmitting the packet with the compressed header to a downstream node.
72. The apparatus of claim 71 , wherein the means for applying compression to the header compresses the SGW IP address to a smaller byte size.
73. The apparatus of claim 71 , wherein the means for applying compression generates a compressed representation of the SGW IP address in response to a transport address translation request received from the downstream node.
74. The apparatus of claim 71 , wherein the compressed header further includes a message type, a tunnel endpoint identifier (TEID), a sequence number, a N-packet data unit (PDU) number, or a next extension header type.
75. A computer program product, comprising:
a computer-readable medium comprising:
code for causing at least one computer to receive a packet from an upstream node comprising a user datagram protocol (UDP), internet protocol (IP), or general packet radio service (GPRS) tunneling protocol (GTP) header;
code for causing the at least one computer to compress the header of the packet to include a compressed serving gateway (SGW) IP address; and
code for causing the at least one computer to transmit the packet with the compressed header to a downstream node.
76. The computer program product of claim 75 , wherein the compressed SGW IP address is of a smaller size than an SGW IP address specified in the header before compression.
77. The computer program product of claim 75 , wherein the computer-readable medium further comprises code for causing the at least one computer to generate the compressed SGW IP address based at least in part on a transport address translation request received from the downstream node.
78. The computer program product of claim 75 , wherein the code for causing the at least one computer to compress the header further compresses the header to include a message type, a tunnel endpoint identifier (TEID), a sequence number, a N-packet data unit (PDU) number, or a next extension header type.
79. An apparatus, comprising:
an internet protocol (IP) packet receiving component that receives a packet from an upstream node comprising a user datagram protocol (UDP), IP, or general packet radio service (GPRS) tunneling protocol (GTP) header;
a header compressing component compresses the header of the packet at least in part by compressing an serving gateway (SGW) IP address in the header; and
a bearer communicating component that transmits the packet with the compressed header to a downstream node.
80. The apparatus of claim 79 , wherein the header compressing component compresses the SGW IP address to a smaller byte size.
81. The apparatus of claim 79 , wherein the header compressing component generates a compressed representation of the SGW IP address in response to a transport address translation request received from the downstream node.
82. The apparatus of claim 79 , wherein the compressed header further includes a message type, a tunnel endpoint identifier (TEID), a sequence number, a N-packet data unit (PDU) number, or a next extension header type.
Priority Applications (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/605,184 US20100103865A1 (en) | 2008-10-24 | 2009-10-23 | Header compression for cell relay communications |
JP2011533413A JP2012507209A (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communication |
PCT/US2009/062100 WO2010048621A2 (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communications |
TW098136223A TW201032547A (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communications |
KR1020117011797A KR20110074930A (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communications |
EP09744866A EP2359566A2 (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communications |
KR1020127032534A KR20130008642A (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communications |
CN2009801418820A CN102197629A (en) | 2008-10-24 | 2009-10-26 | Header compression for cell relay communications |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10828708P | 2008-10-24 | 2008-10-24 | |
US12/605,184 US20100103865A1 (en) | 2008-10-24 | 2009-10-23 | Header compression for cell relay communications |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100103865A1 true US20100103865A1 (en) | 2010-04-29 |
Family
ID=42117409
Family Applications (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/603,392 Active 2031-11-22 US8902805B2 (en) | 2008-10-24 | 2009-10-21 | Cell relay packet routing |
US12/604,215 Abandoned US20100103864A1 (en) | 2008-10-24 | 2009-10-22 | Cell relay protocol |
US12/604,189 Active 2031-02-07 US8401068B2 (en) | 2008-10-24 | 2009-10-22 | Device attachment and bearer activation using cell relays |
US12/604,198 Abandoned US20100103857A1 (en) | 2008-10-24 | 2009-10-22 | Cell relay network attachment procedures |
US12/604,210 Abandoned US20100103845A1 (en) | 2008-10-24 | 2009-10-22 | Cell relay mobility procedures |
US12/604,205 Active 2031-10-12 US9088939B2 (en) | 2008-10-24 | 2009-10-22 | Bearer QoS mapping for cell relays |
US12/605,184 Abandoned US20100103865A1 (en) | 2008-10-24 | 2009-10-23 | Header compression for cell relay communications |
Family Applications Before (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/603,392 Active 2031-11-22 US8902805B2 (en) | 2008-10-24 | 2009-10-21 | Cell relay packet routing |
US12/604,215 Abandoned US20100103864A1 (en) | 2008-10-24 | 2009-10-22 | Cell relay protocol |
US12/604,189 Active 2031-02-07 US8401068B2 (en) | 2008-10-24 | 2009-10-22 | Device attachment and bearer activation using cell relays |
US12/604,198 Abandoned US20100103857A1 (en) | 2008-10-24 | 2009-10-22 | Cell relay network attachment procedures |
US12/604,210 Abandoned US20100103845A1 (en) | 2008-10-24 | 2009-10-22 | Cell relay mobility procedures |
US12/604,205 Active 2031-10-12 US9088939B2 (en) | 2008-10-24 | 2009-10-22 | Bearer QoS mapping for cell relays |
Country Status (9)
Country | Link |
---|---|
US (7) | US8902805B2 (en) |
EP (3) | EP2359654A1 (en) |
JP (4) | JP5384655B2 (en) |
KR (5) | KR20130106888A (en) |
CN (4) | CN102197679A (en) |
BR (1) | BRPI0919845B1 (en) |
ES (1) | ES2427172T3 (en) |
TW (7) | TWI424766B (en) |
WO (7) | WO2010048577A1 (en) |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100103862A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Device attachment and bearer activation using cell relays |
US20100189076A1 (en) * | 2009-01-23 | 2010-07-29 | Samsung Electronics Co. Ltd. | Apparatus and method for processing gtp in mobile communication system |
US20100260129A1 (en) * | 2009-04-10 | 2010-10-14 | Qualcomm Incorporated | Qos mapping for relay nodes |
US20110019617A1 (en) * | 2009-07-23 | 2011-01-27 | Qualcomm Incorporated | Header compression for relay nodes |
US20110090840A1 (en) * | 2008-07-21 | 2011-04-21 | Electronics And Telecommunications Research Institute | Communication system for removing transmission overhead |
US20110103294A1 (en) * | 2009-10-30 | 2011-05-05 | Institute For Information Industry | Donor evolved nodeb, relay node and communication method thereof |
US20110185049A1 (en) * | 2010-01-28 | 2011-07-28 | Verizon Patent And Licensing, Inc. | Localized media offload |
US20120036304A1 (en) * | 2010-08-04 | 2012-02-09 | International Business Machines Corporation | Injection of i/o messages |
US20130155918A1 (en) * | 2011-12-20 | 2013-06-20 | Nokia Siemens Networks Oy | Techniques To Enhance Header Compression Efficiency And Enhance Mobile Node Security |
US20130215820A1 (en) * | 2010-10-08 | 2013-08-22 | Nokia Siemens Networks Oy | Relay Nodes |
US8549202B2 (en) | 2010-08-04 | 2013-10-01 | International Business Machines Corporation | Interrupt source controller with scalable state structures |
US20150023250A1 (en) * | 2012-01-19 | 2015-01-22 | Samsun Electronics Co., Ltd. | Method for establishing an interface and communication between a relay node and a core network |
US20160021161A1 (en) * | 2014-07-16 | 2016-01-21 | Alcatel-Lucent Usa, Inc. | Mobile network video optimization for centralized processing base stations |
US9336029B2 (en) | 2010-08-04 | 2016-05-10 | International Business Machines Corporation | Determination via an indexed structure of one or more partitionable endpoints affected by an I/O message |
US9584213B2 (en) * | 2008-11-05 | 2017-02-28 | Qualcomm Incorporated | Relays in a multihop heterogeneous UMTS wireless communication system |
US20170230102A1 (en) * | 2014-10-28 | 2017-08-10 | Bayerische Motoren Werke Aktiengesellschaft | Vehicle-Based Femtocell with Prioritization of Data Packets on the Basis of the Required Internet Service Quality |
US9860786B1 (en) | 2016-02-01 | 2018-01-02 | Sprint Spectrum L.P. | Efficient backhaul for relay nodes |
US10021594B2 (en) | 2014-06-26 | 2018-07-10 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
US10623989B2 (en) * | 2016-10-27 | 2020-04-14 | Qualcomm Incorporated | Techniques and apparatuses for unidirectional robust header compression |
CN112399480A (en) * | 2020-11-05 | 2021-02-23 | 中国联合网络通信集团有限公司 | Method, apparatus and storage medium for reducing transmission overhead |
US11252635B2 (en) | 2018-02-14 | 2022-02-15 | Kt Corporation | Method for processing uplink user data in relay node, and device for same |
US11343715B1 (en) * | 2020-08-23 | 2022-05-24 | Rockwell Collins, Inc. | Header compression for network |
Families Citing this family (241)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2720398C (en) | 2008-04-02 | 2016-08-16 | Twilio Inc. | System and method for processing telephony sessions |
US8837465B2 (en) | 2008-04-02 | 2014-09-16 | Twilio, Inc. | System and method for processing telephony sessions |
US8121077B2 (en) * | 2008-07-24 | 2012-02-21 | Panasonic Corporation | Relay device and relay method |
US8964726B2 (en) | 2008-10-01 | 2015-02-24 | Twilio, Inc. | Telephony web event system and method |
US8848594B2 (en) | 2008-12-10 | 2014-09-30 | Blackberry Limited | Method and apparatus for discovery of relay nodes |
US8402334B2 (en) * | 2008-12-17 | 2013-03-19 | Research In Motion Limited | System and method for hybrid automatic repeat request (HARQ) functionality in a relay node |
US8355388B2 (en) | 2008-12-17 | 2013-01-15 | Research In Motion Limited | System and method for initial access to relays |
US8040904B2 (en) | 2008-12-17 | 2011-10-18 | Research In Motion Limited | System and method for autonomous combining |
US8311061B2 (en) | 2008-12-17 | 2012-11-13 | Research In Motion Limited | System and method for multi-user multiplexing |
US8446856B2 (en) | 2008-12-19 | 2013-05-21 | Research In Motion Limited | System and method for relay node selection |
CN102326441A (en) * | 2008-12-19 | 2012-01-18 | 瑞典爱立信有限公司 | Method and entity for conveying data units |
US8335466B2 (en) * | 2008-12-19 | 2012-12-18 | Research In Motion Limited | System and method for resource allocation |
US8265128B2 (en) | 2008-12-19 | 2012-09-11 | Research In Motion Limited | Multiple-input multiple-output (MIMO) with relay nodes |
KR101531531B1 (en) * | 2009-01-08 | 2015-07-07 | 삼성전자주식회사 | Method for connecting user equipment to local packet data network by evolved node b |
US20100182970A1 (en) * | 2009-01-21 | 2010-07-22 | Qualcomm Incorporated | Multiple Subscriptions Using a Single Air-Interface Resource |
JP5671484B2 (en) | 2009-03-02 | 2015-02-18 | トゥイリオ インコーポレイテッドTwilio Inc. | Method and system for a multi-tenant telephone network |
CN101827451B (en) * | 2009-03-03 | 2012-12-12 | 华为技术有限公司 | Network access method of relaying node and device |
WO2010099705A1 (en) * | 2009-03-06 | 2010-09-10 | 中国移动通信集团公司 | Method, system and network device for network access of relay node |
WO2010105410A1 (en) * | 2009-03-17 | 2010-09-23 | 华为技术有限公司 | Method, device and system for setting up radio bearer |
EP2409515B1 (en) * | 2009-03-20 | 2015-12-23 | Telefonaktiebolaget L M Ericsson (publ) | Radio bearer identification for self backhauling and relaying in lte advanced |
WO2010111819A1 (en) * | 2009-03-30 | 2010-10-07 | 华为技术有限公司 | Method, network system and device for realizing data retransmission |
DK3562205T3 (en) | 2009-04-02 | 2020-08-10 | Ericsson Telefon Ab L M | Techniques for managing network traffic |
WO2010115469A1 (en) * | 2009-04-09 | 2010-10-14 | Nokia Siemens Networks Oy | Base station caching for an efficient handover in a mobile telecommunication network with relays |
US8902827B2 (en) * | 2009-04-21 | 2014-12-02 | Htc Corporation | Relay for handling data forwarding in a wireless communication system and related method for controlling the same |
CN102405610B (en) * | 2009-04-21 | 2016-06-01 | Lg电子株式会社 | The method using via node in a wireless communication system |
KR100968037B1 (en) * | 2009-04-21 | 2010-07-07 | 엘지전자 주식회사 | Apparatus and method of managing radio bearer in wireless communication system |
EP2259651A1 (en) * | 2009-06-05 | 2010-12-08 | Panasonic Corporation | QoS Multiplexing via base station-relay node interface |
US8762532B2 (en) * | 2009-08-13 | 2014-06-24 | Qualcomm Incorporated | Apparatus and method for efficient memory allocation |
US9038073B2 (en) * | 2009-08-13 | 2015-05-19 | Qualcomm Incorporated | Data mover moving data to accelerator for processing and returning result data based on instruction received from a processor utilizing software and hardware interrupts |
US8788782B2 (en) | 2009-08-13 | 2014-07-22 | Qualcomm Incorporated | Apparatus and method for memory management and efficient data processing |
US20110041128A1 (en) * | 2009-08-13 | 2011-02-17 | Mathias Kohlenz | Apparatus and Method for Distributed Data Processing |
CN101998449B (en) * | 2009-08-17 | 2015-07-22 | 中兴通讯股份有限公司 | Transmission system and method applied to wireless relay |
CN101998657A (en) * | 2009-08-18 | 2011-03-30 | 中兴通讯股份有限公司 | Relay communication system supporting multi-hop and access method thereof |
CN101998303B (en) * | 2009-08-18 | 2013-11-06 | 华为技术有限公司 | Data transmission method, system, donor base station, relay equipment and evolved packet core network node |
CN101998621B (en) * | 2009-08-21 | 2013-08-28 | 华为技术有限公司 | Buffer status report (BSR) reporting method, relay node (RN), evolved node base (eNB) and system |
US8213337B2 (en) * | 2009-09-23 | 2012-07-03 | Via Telecom, Inc. | IP multimedia subsystem for a multimode wireless device |
US9210275B2 (en) | 2009-10-07 | 2015-12-08 | Twilio, Inc. | System and method for running a multi-module telephony application |
US8452319B2 (en) * | 2009-10-15 | 2013-05-28 | Electronics And Telecommunications Research Institute | Ad-hoc wireless communication method using sector antenna, recovery method in ad-hoc wireless communication and ad-hoc wireless communication system |
US20110134826A1 (en) * | 2009-12-04 | 2011-06-09 | Xiangying Yang | Relay data path architecture for a wireless network |
JP4838377B2 (en) * | 2009-12-14 | 2011-12-14 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile communication system and radio base station |
EP2517519A1 (en) * | 2009-12-22 | 2012-10-31 | Fujitsu Limited | Quality of service control in a relay |
KR20110077560A (en) * | 2009-12-30 | 2011-07-07 | 삼성전자주식회사 | Apparatus and method for managing quality of service in broadband wirelress communication system with multiple hop relay communication |
CN102118812B (en) * | 2009-12-31 | 2014-07-30 | 华为技术有限公司 | Switching method, system, relay station, control base station and base station in relay network, |
IL206455A (en) | 2010-01-28 | 2016-11-30 | Elta Systems Ltd | Cellular communication system with moving base stations and methods and apparatus useful in conjunction therewith |
CN102149214B (en) * | 2010-02-05 | 2015-05-13 | 中兴通讯股份有限公司 | Data transmission method and system in communication system |
US20110194533A1 (en) * | 2010-02-11 | 2011-08-11 | Te-Ming Chen | Method of Handling Radio Resource Reconfiguration |
US8943174B2 (en) * | 2010-02-19 | 2015-01-27 | Telefonaktiebolaget L M Ericsson (Publ) | Identification of relay nodes in a communication network |
CN102088771B (en) * | 2010-03-12 | 2013-10-16 | 电信科学技术研究院 | Method, system and device for selecting data surface path according to UE (User Equipment) status |
US8724472B2 (en) * | 2010-03-25 | 2014-05-13 | Qualcomm Incorporated | Data radio bearer mapping in a telecommunication network with relays |
CN103098507B (en) | 2010-04-02 | 2017-08-15 | 交互数字专利控股公司 | Method and apparatus for supporting the communication via via node |
GB2479904A (en) * | 2010-04-28 | 2011-11-02 | Sharp Kk | LTE-A relay apparatus, in particular for type 1 relays |
US20110267943A1 (en) * | 2010-04-30 | 2011-11-03 | Qualcomm Incorporated | Static uu-un bearer mapping based on quality of service |
CN102238667B (en) * | 2010-05-07 | 2015-09-16 | 北京三星通信技术研究有限公司 | A kind ofly set up the method connected between base station |
DE102010028974A1 (en) * | 2010-05-12 | 2011-11-17 | Vodafone Holding Gmbh | Providing an end-to-end connection from an end unit to a network |
CN102271405B (en) * | 2010-06-04 | 2014-09-10 | 中兴通讯股份有限公司 | Method and device for allocating bearer resources |
CN103262632A (en) * | 2010-06-04 | 2013-08-21 | 得克萨斯系统大学评议会 | Wireless communication method, system and computer program product |
CN102104930A (en) * | 2010-06-12 | 2011-06-22 | 电信科学技术研究院 | Mapping method and apparatus in resource status process |
US9385862B2 (en) | 2010-06-16 | 2016-07-05 | Qualcomm Incorporated | Method and apparatus for binding subscriber authentication and device authentication in communication systems |
US8839373B2 (en) * | 2010-06-18 | 2014-09-16 | Qualcomm Incorporated | Method and apparatus for relay node management and authorization |
JP4996718B2 (en) * | 2010-06-21 | 2012-08-08 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile communication method and radio base station |
CN102291789B (en) * | 2010-06-21 | 2015-08-12 | 中兴通讯股份有限公司 | The cell switching method of acquisition adjacent cell information method, subscriber equipment and network |
US9590849B2 (en) | 2010-06-23 | 2017-03-07 | Twilio, Inc. | System and method for managing a computing cluster |
US20120208495A1 (en) | 2010-06-23 | 2012-08-16 | Twilio, Inc. | System and method for monitoring account usage on a platform |
US9459925B2 (en) | 2010-06-23 | 2016-10-04 | Twilio, Inc. | System and method for managing a computing cluster |
US9459926B2 (en) | 2010-06-23 | 2016-10-04 | Twilio, Inc. | System and method for managing a computing cluster |
JP5277210B2 (en) * | 2010-06-24 | 2013-08-28 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile communication method and relay node |
US8838707B2 (en) | 2010-06-25 | 2014-09-16 | Twilio, Inc. | System and method for enabling real-time eventing |
US8897134B2 (en) * | 2010-06-25 | 2014-11-25 | Telefonaktiebolaget L M Ericsson (Publ) | Notifying a controller of a change to a packet forwarding configuration of a network element over a communication channel |
US8375245B2 (en) * | 2010-07-15 | 2013-02-12 | Verizon Patent And Licensing Inc. | Mobility management entity failover |
WO2012013238A1 (en) | 2010-07-29 | 2012-02-02 | Telefonaktiebolaget L M Ericsson (Publ) | Handling network traffic via a fixed access |
WO2012016187A2 (en) | 2010-07-30 | 2012-02-02 | Board Of Regents | Distributed rate allocation and collision detection in wireless networks |
KR101466678B1 (en) | 2010-08-03 | 2014-11-28 | 닛본 덴끼 가부시끼가이샤 | Relay station device, mobile communication system, base station device, and method for controlling relay station |
WO2012028200A1 (en) * | 2010-09-03 | 2012-03-08 | Nokia Siemens Networks Oy | Relay nodes in multi-operator scenario |
CN102404770B (en) * | 2010-09-08 | 2015-04-01 | 电信科学技术研究院 | Method and device for secondary measurement of wireless relay system layer |
WO2012032782A1 (en) * | 2010-09-09 | 2012-03-15 | パナソニック株式会社 | Communication system, communication method, mobile terminal, and base station device |
CN102438258A (en) * | 2010-09-29 | 2012-05-02 | 中兴通讯股份有限公司 | Method and device for bearing multiplexing |
US8345603B2 (en) * | 2010-09-30 | 2013-01-01 | Alcatel Lucent | Method and apparatus for processing GTP triggered messages |
JP4932933B2 (en) | 2010-10-06 | 2012-05-16 | 株式会社エヌ・ティ・ティ・ドコモ | Relay station and relay method for relaying wireless communication |
CN103270789A (en) * | 2010-10-19 | 2013-08-28 | 诺基亚西门子通信公司 | Reconfiguring a base station for handover in relay-nhanced communication network |
US9204290B2 (en) * | 2010-11-03 | 2015-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for constructing a domain name for a radio network node in a cellular communication system |
JP4937398B1 (en) * | 2010-11-04 | 2012-05-23 | 株式会社エヌ・ティ・ティ・ドコモ | Relay station and reconnection method |
JP5728586B2 (en) * | 2010-11-05 | 2015-06-03 | インターデイジタル パテント ホールディングス インコーポレイテッド | Layer 2 measurement related to the interface of the relay node and handling of the relay node during network load balancing |
KR20130135875A (en) | 2010-11-24 | 2013-12-11 | 엘타 시스템즈 리미티드 | Various routing architectures for dynamic multi-hop backhauling cellular network and various methods useful in conjunction therewith |
WO2012070044A1 (en) | 2010-11-24 | 2012-05-31 | Elta Systems Ltd. | Architecture and methods for traffic management by tunneling in moving hierarchical cellular networks |
CN102547892B (en) * | 2010-12-20 | 2014-12-10 | 大唐移动通信设备有限公司 | Nomadic data access system, device and transmission method |
CN102083006B (en) * | 2011-01-17 | 2014-06-04 | 大唐移动通信设备有限公司 | Data transmission method, device and system |
US8649268B2 (en) | 2011-02-04 | 2014-02-11 | Twilio, Inc. | Method for processing telephony sessions of a network |
EP2676477B1 (en) * | 2011-02-14 | 2019-01-09 | Telefonaktiebolaget LM Ericsson (publ) | Backwards-compatible approach to fields of a protocol layer |
US8806042B2 (en) | 2011-02-18 | 2014-08-12 | Telefonaktiebolaget L M Ericsson (Publ) | Mobile router in EPS |
WO2012122508A2 (en) | 2011-03-09 | 2012-09-13 | Board Of Regents | Network routing system, method, and computer program product |
US20120238208A1 (en) * | 2011-03-17 | 2012-09-20 | Maik Bienas | Mobile radio communication devices and servers |
TW201246956A (en) * | 2011-03-29 | 2012-11-16 | Innovative Sonic Corp | Method and apparatus to improve high-speed mobility in a wireless communication system |
US8817690B2 (en) * | 2011-04-04 | 2014-08-26 | Qualcomm Incorporated | Method and apparatus for scheduling network traffic in the presence of relays |
CN102740278B (en) * | 2011-04-11 | 2016-01-20 | 普天信息技术研究院有限公司 | The method of eNB config update in wireless relay network |
US8780799B2 (en) * | 2011-05-02 | 2014-07-15 | Verizon Patent And Licensing Inc. | Handling multiple voice over internet protocol (VoIP) calls via a single bearer |
US9648006B2 (en) | 2011-05-23 | 2017-05-09 | Twilio, Inc. | System and method for communicating with a client application |
WO2012162397A1 (en) | 2011-05-23 | 2012-11-29 | Twilio, Inc. | System and method for connecting a communication to a client |
US20140044123A1 (en) | 2011-05-23 | 2014-02-13 | Twilio, Inc. | System and method for real time communicating with a client application |
JP5484399B2 (en) * | 2011-05-31 | 2014-05-07 | 株式会社Nttドコモ | Mobile communication method, relay node, and radio base station |
EP2721843B1 (en) | 2011-06-16 | 2019-02-06 | Nokia Solutions and Networks Oy | Methods, apparatus, a system, and a related computer program product for activation and deacitivation of bearers |
US9203766B2 (en) * | 2011-06-17 | 2015-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Quality of service for serving node and method |
US8965415B2 (en) | 2011-07-15 | 2015-02-24 | Qualcomm Incorporated | Short packet data service |
EP2568749B1 (en) * | 2011-09-06 | 2018-01-31 | Alcatel Lucent | Method of providing communication over a mobile communication network |
US10123327B2 (en) * | 2011-09-19 | 2018-11-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for transmitting and receiving data in orthogonal frequency division multiplexing system |
US9510256B2 (en) * | 2011-09-20 | 2016-11-29 | Wildfire.Exchange, Inc. | Seamless handoff, offload, and load balancing in integrated Wi-Fi/small cell systems |
US10182147B2 (en) | 2011-09-21 | 2019-01-15 | Twilio Inc. | System and method for determining and communicating presence information |
US20130137469A1 (en) * | 2011-11-30 | 2013-05-30 | Intel Mobile Communications GmbH | Method for transmitting an opportunistic network related message |
EP2789187A2 (en) * | 2011-12-08 | 2014-10-15 | Interdigital Patent Holdings, Inc. | High-rate dual-band cellular communications |
US20130155964A1 (en) * | 2011-12-19 | 2013-06-20 | Motorola Solutions, Inc. | Allowing end-user devices access to resources of a mobile broadband network at desired quality of service levels using a transit device |
WO2013109171A1 (en) * | 2012-01-16 | 2013-07-25 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for relaying |
WO2013116981A1 (en) * | 2012-02-06 | 2013-08-15 | Alcatel-Lucent Shanghai Bell Co., Ltd. | Apparatus, method, and computer program for a mobile relay station transceiver, system, and means for mass transportation |
US8660078B2 (en) | 2012-02-07 | 2014-02-25 | Qualcomm Incorporated | Data radio bearer (DRB) enhancements for small data transmissions apparatus, systems, and methods |
US9495227B2 (en) | 2012-02-10 | 2016-11-15 | Twilio, Inc. | System and method for managing concurrent events |
JP5792661B2 (en) * | 2012-03-06 | 2015-10-14 | 株式会社日立製作所 | Ad hoc network system and meter reading information collection method |
TWI484853B (en) * | 2012-03-14 | 2015-05-11 | Inst Information Industry | Communication system and communication method thereof |
US9526091B2 (en) * | 2012-03-16 | 2016-12-20 | Intel Corporation | Method and apparatus for coordination of self-optimization functions in a wireless network |
US9986535B2 (en) * | 2012-03-31 | 2018-05-29 | Tejas Networks Limited | Method and system for managing mobile management entity (MME) in a telecommunication network |
US9602586B2 (en) | 2012-05-09 | 2017-03-21 | Twilio, Inc. | System and method for managing media in a distributed communication network |
JP2013239817A (en) * | 2012-05-14 | 2013-11-28 | Sharp Corp | Relay device, radio terminal device, communication system and communication method |
WO2013185285A1 (en) * | 2012-06-12 | 2013-12-19 | Nokia Corporation | Methods, apparatuses and computer program products for configuration of signaling radio bearers |
WO2013188665A1 (en) | 2012-06-14 | 2013-12-19 | Tekelec, Inc. | Methods, systems, and computer readable media for providing policy and charging rules function (pcrf) with integrated openflow controller |
US9247062B2 (en) | 2012-06-19 | 2016-01-26 | Twilio, Inc. | System and method for queuing a communication session |
CN102769930B (en) * | 2012-07-11 | 2018-05-11 | 中兴通讯股份有限公司 | Bearing processing method and device |
GB2503923A (en) * | 2012-07-12 | 2014-01-15 | Nec Corp | Coordinated multipoint transmissions to a relay node |
CN106488568B (en) * | 2012-07-20 | 2020-01-31 | 华为技术有限公司 | data transmission method, device and communication system |
US8737962B2 (en) | 2012-07-24 | 2014-05-27 | Twilio, Inc. | Method and system for preventing illicit use of a telephony platform |
JP5871750B2 (en) | 2012-08-28 | 2016-03-01 | 株式会社Nttドコモ | Mobile communication system, radio base station and mobile station |
US8938053B2 (en) | 2012-10-15 | 2015-01-20 | Twilio, Inc. | System and method for triggering on platform usage |
US8948356B2 (en) | 2012-10-15 | 2015-02-03 | Twilio, Inc. | System and method for routing communications |
WO2014063319A1 (en) * | 2012-10-24 | 2014-05-01 | 华为技术有限公司 | Processing method, base station and system for cooperative communication |
US9480106B2 (en) * | 2012-11-28 | 2016-10-25 | T-Mobile Usa, Inc. | Inter-base station logical interface communication using relay devices |
US9672527B2 (en) * | 2013-01-21 | 2017-06-06 | Tejas Networks Limited | Associating and consolidating MME bearer management functions |
US9537904B2 (en) * | 2013-01-24 | 2017-01-03 | Tekelec, Inc. | Methods, systems, and computer readable media for using policy knowledge of or obtained by a policy and charging rules function (PCRF) for needs based forwarding of bearer session traffic to network nodes |
WO2014127346A1 (en) | 2013-02-18 | 2014-08-21 | Tekelec, Inc. | Methods, systems, and computer readable media for providing a thinking diameter network architecture |
CN105052074B (en) | 2013-02-18 | 2019-03-19 | 泰科来股份有限公司 | For providing method, system and the computer-readable medium of virtualization diameter network framework and the diameter resource instances for portfolio to be routed to D ynamic instantiation |
US9282124B2 (en) | 2013-03-14 | 2016-03-08 | Twilio, Inc. | System and method for integrating session initiation protocol communication in a telecommunications platform |
CN104969653B (en) * | 2013-04-07 | 2019-07-26 | 华为技术有限公司 | The method for building up and equipment of wireless backhaul link |
KR101410248B1 (en) * | 2013-05-21 | 2014-06-20 | 주식회사 이노와이어리스 | method for measuring backhaul throughput for LTE small cell |
CN104244426B (en) | 2013-06-09 | 2019-02-05 | 华为技术有限公司 | A kind of resource allocation methods and device of Data Radio Bearer DRB |
US9240966B2 (en) | 2013-06-19 | 2016-01-19 | Twilio, Inc. | System and method for transmitting and receiving media messages |
US9225840B2 (en) | 2013-06-19 | 2015-12-29 | Twilio, Inc. | System and method for providing a communication endpoint information service |
US9483328B2 (en) | 2013-07-19 | 2016-11-01 | Twilio, Inc. | System and method for delivering application content |
US9391897B2 (en) | 2013-07-31 | 2016-07-12 | Oracle International Corporation | Methods, systems, and computer readable media for mitigating traffic storms |
US9137127B2 (en) | 2013-09-17 | 2015-09-15 | Twilio, Inc. | System and method for providing communication platform metadata |
US9274858B2 (en) | 2013-09-17 | 2016-03-01 | Twilio, Inc. | System and method for tagging and tracking events of an application platform |
US9510376B2 (en) | 2013-09-25 | 2016-11-29 | At&T Intellectual Property I, L.P. | Tunneling packet exchange in long term evolution protocol based networks |
KR102097408B1 (en) * | 2013-10-15 | 2020-04-06 | 삼성전자주식회사 | Apparatus and method for controlling to operate use carrier aggregation technology in mobile communication system |
US9553799B2 (en) | 2013-11-12 | 2017-01-24 | Twilio, Inc. | System and method for client communication in a distributed telephony network |
US9325624B2 (en) | 2013-11-12 | 2016-04-26 | Twilio, Inc. | System and method for enabling dynamic multi-modal communication |
US11388082B2 (en) | 2013-11-27 | 2022-07-12 | Oracle International Corporation | Methods, systems, and computer readable media for diameter routing using software defined network (SDN) functionality |
US10250490B2 (en) * | 2013-12-23 | 2019-04-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and network node for routing backhaul packets |
WO2015108305A1 (en) | 2014-01-14 | 2015-07-23 | Lg Electronics Inc. | Method and apparatus for transmitting/receiving broadcasting signal including robust header compression packet stream and fast information |
US9344573B2 (en) | 2014-03-14 | 2016-05-17 | Twilio, Inc. | System and method for a work distribution service |
US9787595B2 (en) * | 2014-03-24 | 2017-10-10 | Intel IP Corporation | Evolved node-B and mobility management entity and user equipment and methods for supporting attended and unattended services |
WO2015160329A1 (en) * | 2014-04-15 | 2015-10-22 | Nokia Solutions And Networks Oy | Interworking with bearer-based system |
US9226217B2 (en) | 2014-04-17 | 2015-12-29 | Twilio, Inc. | System and method for enabling multi-modal communication |
US10506607B2 (en) | 2014-06-02 | 2019-12-10 | Qualcomm Incorporated | Discovery of multi-hop capabilities and routing on a per link basis |
US9961587B2 (en) | 2014-06-26 | 2018-05-01 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
RO130953A2 (en) * | 2014-07-04 | 2016-02-26 | Ixia, A California Corporation | Methods, system and computer-readable medium for distributing general packet radio service tunnelling protocol (gtp) traffic |
US9251371B2 (en) | 2014-07-07 | 2016-02-02 | Twilio, Inc. | Method and system for applying data retention policies in a computing platform |
US9246694B1 (en) | 2014-07-07 | 2016-01-26 | Twilio, Inc. | System and method for managing conferencing in a distributed communication network |
US9516101B2 (en) | 2014-07-07 | 2016-12-06 | Twilio, Inc. | System and method for collecting feedback in a multi-tenant communication platform |
US9774687B2 (en) | 2014-07-07 | 2017-09-26 | Twilio, Inc. | System and method for managing media and signaling in a communication platform |
CN105451282A (en) | 2014-08-22 | 2016-03-30 | 电信科学技术研究院 | Relay terminal reselection method and apparatus |
WO2016051578A1 (en) * | 2014-10-02 | 2016-04-07 | 富士通株式会社 | Repeater and base station system |
US9538563B2 (en) | 2014-10-13 | 2017-01-03 | At&T Intellectual Property I, L.P. | System and methods for managing a user data path |
WO2016065080A1 (en) * | 2014-10-21 | 2016-04-28 | Twilio, Inc. | System and method for providing a miro-services communication platform |
US20160135166A1 (en) * | 2014-11-06 | 2016-05-12 | Bruce Cilli | System and method for exporting real-time user equipment and bearer state information |
US9906973B2 (en) | 2014-11-28 | 2018-02-27 | Industrial Technology Research Institute | Evolved NodeB and traffic dispatch method thereof |
DE102014018873A1 (en) | 2014-12-16 | 2016-06-30 | Unify Gmbh & Co. Kg | A telecommunications device and method for establishing an RTC connection between a first endpoint and a second endpoint |
US9477975B2 (en) | 2015-02-03 | 2016-10-25 | Twilio, Inc. | System and method for a media intelligence platform |
US20160255632A1 (en) * | 2015-02-27 | 2016-09-01 | Nokia Solutions And Networks Oy | LTE/WI-FI Aggregation For Existing Network Nodes |
US10542457B2 (en) * | 2015-04-20 | 2020-01-21 | Qualcomm Incorporated | Enhanced compression formats for data compression |
WO2016176816A1 (en) * | 2015-05-05 | 2016-11-10 | 华为技术有限公司 | Method, network device and system for circuit switched fallback |
US10148509B2 (en) | 2015-05-13 | 2018-12-04 | Oracle International Corporation | Methods, systems, and computer readable media for session based software defined networking (SDN) management |
US10419891B2 (en) | 2015-05-14 | 2019-09-17 | Twilio, Inc. | System and method for communicating through multiple endpoints |
US9948703B2 (en) | 2015-05-14 | 2018-04-17 | Twilio, Inc. | System and method for signaling through data storage |
US9826422B2 (en) | 2015-05-28 | 2017-11-21 | Alcatel-Lucent Usa Inc. | System and method for controlling an operation of an application |
WO2016193864A1 (en) * | 2015-05-29 | 2016-12-08 | Nokia Technologies Oy | Minimization of service interruption during relay reselection in device-to-device (d2d) based user equipment (ue)-to-network relay |
US9838893B2 (en) | 2015-06-25 | 2017-12-05 | Alcatel Lucent | System and method for cooperatively controlling an application |
WO2017061643A1 (en) * | 2015-10-06 | 2017-04-13 | 엘지전자(주) | Method and device for transmitting/receiving data to/from base station in wireless communication system |
US10659349B2 (en) | 2016-02-04 | 2020-05-19 | Twilio Inc. | Systems and methods for providing secure network exchanged for a multitenant virtual private cloud |
US9961588B2 (en) | 2016-02-24 | 2018-05-01 | Keysight Technologies Singapore (Holdings) Pte. Ltd. | Methods, systems, and computer readable media for distributing monitored network traffic |
US10165492B2 (en) * | 2016-03-22 | 2018-12-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and network nodes for multi-connectivity handling in a communication system |
US10148340B1 (en) * | 2016-03-30 | 2018-12-04 | Sprint Communications Company L.P. | Multi-core communication system to serve wireless relays and user equipment |
EP3439424A4 (en) * | 2016-03-31 | 2019-05-01 | Sony Corporation | Relay device, terminal device, and communication method |
EP3456145A1 (en) * | 2016-05-13 | 2019-03-20 | Telecom Italia S.p.A. | Method and system for data tunneling in device to device communication assisted by a telecommunication network |
US10063713B2 (en) | 2016-05-23 | 2018-08-28 | Twilio Inc. | System and method for programmatic device connectivity |
US10686902B2 (en) | 2016-05-23 | 2020-06-16 | Twilio Inc. | System and method for a multi-channel notification service |
CN107707475B (en) * | 2016-08-09 | 2020-03-06 | 大唐移动通信设备有限公司 | Data transmission method and system |
CN108307528B (en) * | 2016-08-11 | 2021-05-25 | 中兴通讯股份有限公司 | Information transmission method, device and system |
US10499278B2 (en) * | 2016-08-31 | 2019-12-03 | Qualcomm Incorporated | Header compression for reduced bandwidth wireless devices |
CN109565705B (en) * | 2016-10-17 | 2023-03-28 | Sk电信有限公司 | Base station apparatus and QOS control method in wireless zone |
JP6953706B2 (en) * | 2016-11-22 | 2021-10-27 | ソニーグループ株式会社 | base station |
US10142008B1 (en) | 2016-12-15 | 2018-11-27 | Sprint Communications Company L.P. | Data compression for wireless relays in a data communication network |
CN106658380A (en) * | 2016-12-30 | 2017-05-10 | 宇龙计算机通信科技(深圳)有限公司 | Data multiplex method of device and device relay network and intelligent terminal |
JP6808809B2 (en) * | 2017-01-05 | 2021-01-06 | エルジー エレクトロニクス インコーポレイティド | Methods and Devices for Sending Rules for QoS Flow-to-DRB Mapping |
WO2018144855A1 (en) * | 2017-02-03 | 2018-08-09 | Intel IP Corporation | Quality of service flow to data radio bearer mapping override bit |
KR102012463B1 (en) * | 2017-02-28 | 2019-08-20 | 주식회사 이노와이어리스 | data processing data in mobile Xhaul network |
US10264612B2 (en) * | 2017-03-15 | 2019-04-16 | Qualcomm Incorporated | Discovery of controller function for wireless backhaul using cellular radio access technology |
CN108924824B (en) * | 2017-03-20 | 2020-10-09 | 电信科学技术研究院 | EPS bearing identifier distribution method and device, SMF and PCF |
US10873874B2 (en) * | 2017-03-23 | 2020-12-22 | Nec Corporation | Base station, radio relay station, and communication method for cancelling a connection to a base station during an overload condition |
EP3603324A1 (en) * | 2017-03-23 | 2020-02-05 | INTEL Corporation | Advanced radio resource management in next-gen multi-hop relaying cellular network |
US10873890B2 (en) * | 2017-03-23 | 2020-12-22 | Nec Corporation | Base station, radio relay station, communication method for cancelling a connection to a base station during an overload condition |
US10028186B1 (en) | 2017-03-24 | 2018-07-17 | Sprint Communications Company L.P. | Wireless communication system to redirect use equipment (UE) from a wireless relay to a donor base station |
US10433203B1 (en) | 2017-04-19 | 2019-10-01 | Sprint Spectrum L.P. | Providing a quality of service to wireless devices attached to relay access nodes |
US10299185B1 (en) * | 2017-04-24 | 2019-05-21 | Sprint Communications Company L.P. | Wireless relay quality-of-service based on relay-delivered media services |
CN109245845B (en) * | 2017-05-05 | 2022-05-13 | 中兴通讯股份有限公司 | Signaling transmission method and device |
US10469358B2 (en) * | 2017-05-18 | 2019-11-05 | Qualcomm Incorporated | Wireless multihop relay |
WO2019001697A1 (en) * | 2017-06-28 | 2019-01-03 | Huawei Technologies Co., Ltd. | Sub-band compression domain processing for uplink mimo systems |
US10873479B2 (en) * | 2017-08-03 | 2020-12-22 | Qualcomm Incorporated | Techniques and apparatuses for forwarding in multi-hop wireless networks via multi-layer tunneling and centralized control |
WO2019136607A1 (en) * | 2018-01-09 | 2019-07-18 | Oppo广东移动通信有限公司 | Routing method for relay and communication node |
US11089527B2 (en) * | 2018-01-17 | 2021-08-10 | T-Mobile Usa, Inc. | Telecommunications network bearer allocation and deallocation |
US12069528B2 (en) | 2018-01-17 | 2024-08-20 | T-Mobile Usa, Inc. | Telecommunications network bearer allocation and deallocation |
US10567954B2 (en) | 2018-01-18 | 2020-02-18 | At&T Intellectual Property I, L.P. | Integrated access backhaul under a non-standalone network architecture for 5G or other next generation network |
AU2018407956B2 (en) * | 2018-02-11 | 2021-08-05 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Mobile communication system, method and device |
KR102322380B1 (en) * | 2018-02-14 | 2021-11-10 | 주식회사 케이티 | Methods for processing Uplink user data of relay node and Apparatuses thereof |
CN110418427B (en) * | 2018-04-28 | 2021-06-08 | 华为技术有限公司 | Communication method and device |
CN116406033A (en) | 2018-05-11 | 2023-07-07 | 大唐移动通信设备有限公司 | Bearer mapping method of wireless backhaul node, wireless backhaul node and donor base station |
US10904795B2 (en) * | 2018-06-21 | 2021-01-26 | Qualcomm Incorporated | Remapping quality of service flows among data radio bearers |
CN110636583B (en) * | 2018-06-21 | 2021-08-13 | 华为技术有限公司 | Path changing method and device |
CN110636570B (en) * | 2018-06-25 | 2022-08-02 | 中兴通讯股份有限公司 | Method and device for processing IAB node information in IAB network |
GB2576204B (en) | 2018-07-27 | 2021-02-17 | Samsung Electronics Co Ltd | Operation of automatic repeat request (ARQ) |
CN112567796B (en) * | 2018-08-09 | 2023-05-30 | 中兴通讯股份有限公司 | Method, apparatus and system for integrated access and backhaul bearer management |
EP3837880A4 (en) * | 2018-08-13 | 2022-03-09 | Cisco Technology, Inc. | Centralized son assisted multi hop discovery and management |
CN110876175B (en) * | 2018-08-31 | 2021-07-16 | 大唐移动通信设备有限公司 | Link interruption processing method, relay node and computer readable storage medium |
WO2020056364A1 (en) * | 2018-09-14 | 2020-03-19 | Intel Corporation | Signaling configurations for cell selection in fifth generation (5g) new radio (nr) (5g-nr) integrated access and backhaul (iab) |
WO2020061911A1 (en) * | 2018-09-27 | 2020-04-02 | Nokia Shanghai Bell Co., Ltd. | Generation of tunnel endpoint identifier for packet tunneling |
CN110971363B (en) | 2018-09-28 | 2022-03-08 | 华为技术有限公司 | Method and device for communication method of Ethernet data |
CN112997553B (en) * | 2018-11-01 | 2023-04-14 | 联想(北京)有限公司 | Method and apparatus for buffer status report indicator |
WO2020097134A1 (en) * | 2018-11-05 | 2020-05-14 | Parallel Wireless, Inc. | Locally-generated teids for core high availability |
US11349557B2 (en) | 2018-11-30 | 2022-05-31 | At&T Intellectual Property I, L.P. | System model and architecture for mobile integrated access and backhaul in advanced networks |
WO2020122676A1 (en) | 2018-12-14 | 2020-06-18 | Samsung Electronics Co., Ltd. | Apparatus and method for initial access in wireless communication system |
EP3970351B1 (en) * | 2019-05-13 | 2024-02-28 | Nokia Technologies Oy | Address assignment |
CN110830170A (en) * | 2019-11-12 | 2020-02-21 | 北京理工大学 | Data transmission method based on ROHC compression in satellite communication |
US11239898B1 (en) * | 2019-11-19 | 2022-02-01 | T-Mobile Innovations Llc | Relaying data to multiple access points |
EP4107990A4 (en) * | 2020-03-17 | 2023-08-16 | Samsung Electronics Co., Ltd. | Methods and systems for reducing fronthaul bandwidth in a wireless communication system |
EP3913881B1 (en) * | 2020-05-20 | 2024-07-31 | Nokia Solutions and Networks Oy | Header compression management in a radio access network |
US12016083B1 (en) * | 2020-06-30 | 2024-06-18 | Sprint Spectrum Llc | Dynamically establishing relay voice-bearer in response to detecting of voice communication on other relay bearer |
CN113133078B (en) * | 2021-04-19 | 2022-04-08 | 西安电子科技大学 | Light-weight inter-satellite switching device and method for giant low-orbit satellite network |
US11706607B1 (en) | 2021-06-16 | 2023-07-18 | T-Mobile Usa, Inc. | Location based routing that bypasses circuit-based networks |
Citations (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5999980A (en) * | 1996-09-12 | 1999-12-07 | Cabletron Systems, Inc. | Apparatus and method for setting a congestion indicate bit in an backwards RM cell on an ATM network |
US20030223381A1 (en) * | 2002-06-04 | 2003-12-04 | Osmo Schroderus | Method for controlling parties in real-time data communication |
US20040001508A1 (en) * | 2002-06-28 | 2004-01-01 | Haihong Zheng | Method and system for transmitting data in a packet based communication network |
US6839339B1 (en) * | 2000-02-02 | 2005-01-04 | Lucent Technologies Inc. | Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets |
US20050265363A1 (en) * | 2002-09-24 | 2005-12-01 | Xiaobao Chen | Methods and apparatus for data transfer in a packet-switched data network |
US20060139869A1 (en) * | 2004-12-29 | 2006-06-29 | Matusz Pawel O | Extended compression arrangements within telecommunication systems and associated methods |
US20060262732A1 (en) * | 2005-05-18 | 2006-11-23 | Mika Joutsenvirta | Method for informing changed communications capabilities |
US20070072604A1 (en) * | 2005-08-17 | 2007-03-29 | Nortel Networks Limited | Method and system for a wireless multi-hop relay network |
US20070213060A1 (en) * | 2006-03-07 | 2007-09-13 | Interdigital Technology Corporation | Method and apparatus for supporting handoff in an lte gtp based wireless communication system |
US20070230352A1 (en) * | 2006-03-28 | 2007-10-04 | Nec Laboratories America, Inc. | Multipath Routing Architecture for Large Data Transfers |
US7301947B2 (en) * | 2001-06-27 | 2007-11-27 | Nokia Corporation | Transmission of compression identifier of headers on data packet connection |
US20080064390A1 (en) * | 2005-02-07 | 2008-03-13 | Kim Myeong-Cheol | Enhanced Radio Link Control Error Handling |
US20080123660A1 (en) * | 2006-08-09 | 2008-05-29 | Interdigital Technology Corporation | Method and apparatus for providing differentiated quality of service for packets in a particular flow |
US20080144555A1 (en) * | 2006-11-29 | 2008-06-19 | Samsung Electronics Co., Ltd. | Apparatus and method for identifying header compression channel in broadband wireless communication system |
US20080165719A1 (en) * | 2007-01-05 | 2008-07-10 | Motorola, Inc. | Method and apparatus for relay zone bandwidth allocation |
US20080219203A1 (en) * | 2007-03-09 | 2008-09-11 | Industrial Technology Research Institute. | Method for mac process and flexible connection in wireless multi-hop relaying network |
US20080240439A1 (en) * | 2007-03-15 | 2008-10-02 | Interdigital Technology Corporation | Methods and apparatus to facilitate data and security context transfer, and re-initialization during mobile device handover |
US20080268852A1 (en) * | 2004-03-30 | 2008-10-30 | Matsushita Electric Industrial Co., Ltd. | Delayed Base Station Relocation in Distributed Radio Access Networks |
US20080268846A1 (en) * | 2007-02-12 | 2008-10-30 | Interdigital Technology Corporation | Method and apparatus for supporting handoff from gprs/geran to lte eutran |
US20090016282A1 (en) * | 2007-03-26 | 2009-01-15 | Vodafone Group Plc | Data transmission |
US20090042576A1 (en) * | 2007-07-27 | 2009-02-12 | Interdigital Patent Holdings, Inc. | Method and apparatus for handling mobility between non-3gpp to 3gpp networks |
US20090043902A1 (en) * | 2007-04-12 | 2009-02-12 | Stefano Faccin | Packet data network connectivity domain selection and bearer setup |
US20090052409A1 (en) * | 2004-07-30 | 2009-02-26 | Orange Sa | Telecommunications apparatus and method |
US20090080422A1 (en) * | 2007-09-21 | 2009-03-26 | Posdata Co., Ltd. | Header-compression packet processing method, mobile station, base station, and control station in wireless communication system |
US20090111476A1 (en) * | 2007-10-29 | 2009-04-30 | Nokia Siemens Networks Oy | Allocation of user equipment identifier |
US20090111423A1 (en) * | 2007-10-25 | 2009-04-30 | Interdigital Patent Holdings, Inc. | Non-access stratum architecture and protocol enhancements for long term evolution mobile units |
US20090109924A1 (en) * | 2007-10-26 | 2009-04-30 | Fujitsu Limited | Packet communication method, packet communication system, wireless terminal, and packet communication device |
US20090196177A1 (en) * | 2008-02-01 | 2009-08-06 | Nokia Siemens Networks Oy | Method, apparatus and computer program for uplink scheduling in a network that employs relay nodes |
US20090201878A1 (en) * | 2007-11-19 | 2009-08-13 | Cellco Partnership D/B/A Verizon Wireless | Low latency handover between wireless communication networks using different radio access technologies |
US20090215459A1 (en) * | 2008-02-25 | 2009-08-27 | Richard Lee-Chee Kuo | Method and Apparatus for Improving Random Access Procedure for Handover |
US20090238207A1 (en) * | 2008-03-21 | 2009-09-24 | Research In Motion Limited | Dynamic Aggregated Maximum Bit Rate for Evolved Packet System Non-Guaranteed Bit Rate Quality of Service Enforcement and Network Bandwidth Utilization |
US20090257432A1 (en) * | 2006-03-16 | 2009-10-15 | Tsuyoshi Yamaguchi | Terminal |
US7616601B2 (en) * | 2001-01-16 | 2009-11-10 | Netsocket, Inc. | Network resource manager in a mobile telecommunication system |
US20090296626A1 (en) * | 2008-05-30 | 2009-12-03 | Nokia Corporation | Method, apparatus and computer program for relay selection |
US20100091823A1 (en) * | 2008-10-13 | 2010-04-15 | Cisco Technology, Inc. | Two-hop Relay for Reducing Distance Vector Routing Information |
US20100097976A1 (en) * | 2008-10-16 | 2010-04-22 | Qualcomm Incorporated | Incremental redundancy relays for wireless communication |
US20100103862A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Device attachment and bearer activation using cell relays |
US20100226314A1 (en) * | 2007-09-27 | 2010-09-09 | Lixiang Xu | Method for user equipment performing direct communications via hnb access systems |
US20100238805A1 (en) * | 2007-08-22 | 2010-09-23 | Reiner Ludwig | Data Transmission Control Methods And Devices |
US20100246533A1 (en) * | 2006-08-18 | 2010-09-30 | Niklas Lundin | Intersystem Change Involving Mapping Between Different Types Of Radio Bearers |
US20100260126A1 (en) * | 2009-04-13 | 2010-10-14 | Qualcomm Incorporated | Split-cell relay packet routing |
US20100309881A1 (en) * | 2007-11-29 | 2010-12-09 | Samsung Electronics Co., Ltd. | Mobile communication system and tunnel management method thereof |
US7876808B2 (en) * | 2006-11-30 | 2011-01-25 | Broadcom Corp. | Method and apparatus for adaptive noise and/or signal filtering in an HSDPA channel quality indicator (CQI) selection |
US7881247B2 (en) * | 2006-08-17 | 2011-02-01 | Interdigital Technology Corporation | Method and apparatus for providing efficient precoding feedback in a MIMO wireless communication system |
US20110044279A1 (en) * | 2008-04-30 | 2011-02-24 | Niklas Johansson | Self-Backhauling in LTE |
US20110222428A1 (en) * | 2008-11-18 | 2011-09-15 | Nokia Corporation | Relaying in a communication system |
US8054806B2 (en) * | 2007-08-14 | 2011-11-08 | Alcatel Lucent | Method and apparatus for radio link failure recovery in a wireless communications network |
US8055263B2 (en) * | 2005-10-05 | 2011-11-08 | Samsung Electronics Co., Ltd. | Fast cell selection method and apparatus for high speed downlink packet access system |
US8064909B2 (en) * | 2007-10-25 | 2011-11-22 | Cisco Technology, Inc. | Interworking gateway for mobile nodes |
US20120120831A1 (en) * | 2009-06-05 | 2012-05-17 | Panasonic Corporation | Qos multiplexing via base station-relay node interface |
US20120140666A1 (en) * | 2009-06-08 | 2012-06-07 | Ntt Docomo, Inc. | Mobile communication system, relay node, radio base station, and gateway device |
US20120155375A1 (en) * | 2009-08-26 | 2012-06-21 | Huawei Technologies Co., Ltd. | Method and Apparatus for Header Compression in Network Relay Scenario |
Family Cites Families (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5963865A (en) | 1997-11-24 | 1999-10-05 | Telefonaktiebolaget Lm Ericsson | Traffic channel assignment in a cellular telephone system using an uplink interference driven frequency packing method |
JP3441367B2 (en) | 1998-05-25 | 2003-09-02 | 三菱電機株式会社 | Multiple communication connection setting method |
FI106288B (en) * | 1998-10-06 | 2000-12-29 | Nokia Networks Oy | Identifying a mobile station in a packet radio network |
US6608841B1 (en) | 1999-12-30 | 2003-08-19 | Nokia Networks Oy | System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks |
US6785510B2 (en) | 2000-03-09 | 2004-08-31 | Salbu Resarch & Development (Proprietary) Limited | Routing in a multi-station network |
TW490950B (en) | 2000-05-09 | 2002-06-11 | Nutex Comm Corp | Method and system for accessing and displaying area information |
FI111493B (en) | 2000-09-22 | 2003-07-31 | Nokia Corp | Defining a Contextual Tag in Compression of Header Fields |
US6967964B1 (en) | 2000-10-03 | 2005-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Context identification using header compression key at link layer |
MXPA04012665A (en) * | 2002-06-21 | 2005-03-23 | Thomson Licensing Sa | Registration of a wlan as a umts routing area for wlan-umts interworking. |
ATE506822T1 (en) | 2003-09-23 | 2011-05-15 | Panasonic Corp | PROTOCOL CONTEXT TRANSMISSION IN A MOBILE RADIO COMMUNICATION SYSTEM |
TWI273853B (en) | 2004-02-11 | 2007-02-11 | Chunghwa Telecom Co Ltd | Method for planning and optimizing orientation angle of cellular antenna for base station |
KR20060009433A (en) | 2004-07-22 | 2006-02-01 | 삼성전자주식회사 | Method for packet service in a mobile communication using a header compression |
KR100762650B1 (en) | 2005-03-10 | 2007-10-01 | 삼성전자주식회사 | Transmission control method for tcp bi-directional transmission in asymmetric bandwidth pre-allocated subscriber network and apparatus therefor |
KR100744374B1 (en) * | 2005-07-15 | 2007-07-30 | 삼성전자주식회사 | Handover method between core network entities in packet-switched based network and therefor apparatus |
EP1748662A1 (en) * | 2005-07-25 | 2007-01-31 | Orange S.A. | Mobile network performance evaluation system and method |
CN1964225B (en) | 2005-11-11 | 2013-03-13 | 上海贝尔阿尔卡特股份有限公司 | A method to control wireless access, relay station and base station |
US7864731B2 (en) * | 2006-01-04 | 2011-01-04 | Nokia Corporation | Secure distributed handover signaling |
US7986915B1 (en) * | 2006-02-24 | 2011-07-26 | Nortel Networks Limited | Method and system for a wireless multi-hop relay network |
US20070213058A1 (en) | 2006-03-08 | 2007-09-13 | Interdigital Technology Corporation | Method and apparatus for supporting handoff and serving radio network subsystem relocation procedures in a single tunnel gprs-based wireless communication system |
EP2001246A2 (en) | 2006-03-28 | 2008-12-10 | NTT DoCoMo, Inc. | Base station, route control device, and handover control method |
JP5181472B2 (en) | 2006-04-21 | 2013-04-10 | 日本電気株式会社 | Communication control method |
CN101047421B (en) * | 2006-04-28 | 2011-12-07 | 华为技术有限公司 | Device and method for mobile communication using repeater station |
KR101100515B1 (en) | 2006-05-03 | 2011-12-29 | 인터디지탈 테크날러지 코포레이션 | Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures |
US8483123B2 (en) * | 2006-06-30 | 2013-07-09 | Nokia Corporation | QoS request and information distribution for wireless relay networks |
CN201134894Y (en) | 2006-07-12 | 2008-10-15 | 美商内数位科技公司 | Activation of multiple bearing services in long-term evolution system |
TWM329296U (en) | 2006-07-12 | 2008-03-21 | Interdigital Tech Corp | Wireless communication system |
CN101132564B (en) * | 2006-08-25 | 2011-09-14 | 华为技术有限公司 | Base station, relay station, wireless relay communication system and method thereof |
US7995524B2 (en) * | 2006-09-07 | 2011-08-09 | Industrial Technology Research Institute | Wireless communication system and method |
JP5192201B2 (en) | 2006-09-07 | 2013-05-08 | 財團法人工業技術研究院 | Wireless communication system and method |
KR20080024745A (en) * | 2006-09-14 | 2008-03-19 | 삼성전자주식회사 | Apparatus and method for operation of radio access network in broadband mobile communication system |
WO2008042414A2 (en) * | 2006-10-03 | 2008-04-10 | Interdigital Technology Corporation | Enhanced node b configuration with a universal integrated circuit card |
GB2442782A (en) | 2006-10-13 | 2008-04-16 | Fujitsu Ltd | Wireless communication systems |
US20080181176A1 (en) * | 2006-10-30 | 2008-07-31 | Hyunjeong Lee | Framework to design new mac message exchange procedure related to mobile station (ms) handover in multi-hop relay broadband wireless access network |
JP4983208B2 (en) * | 2006-11-07 | 2012-07-25 | 富士通株式会社 | Relay station, wireless communication method |
EP1921807A1 (en) | 2006-11-13 | 2008-05-14 | Alcatel Lucent | Method for forwarding MAC protocol data units in a mobile radio communication network, corresponding communication end point and relay station |
JP5102224B2 (en) | 2006-12-15 | 2012-12-19 | シャープ株式会社 | Wireless communication system and wireless transmission path control method |
US20080165776A1 (en) * | 2007-01-08 | 2008-07-10 | Zhifeng Tao | Relay Tunneling in Wireless Multi-User Multi-Hop Relay Networks |
CN101227714B (en) | 2007-01-18 | 2011-04-06 | 华为技术有限公司 | System, apparatus and method for sharing network resource |
EP2528250B1 (en) | 2007-01-30 | 2015-03-04 | Nec Corporation | Mobile communication system, core network node, access network, terminal and corresponding multicast data distribution methods |
US8259677B2 (en) | 2007-02-06 | 2012-09-04 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for intra E-utran handover |
WO2008102547A1 (en) * | 2007-02-19 | 2008-08-28 | Panasonic Corporation | QoS ESTABLISHING METHOD, AND MOBILE TERMINAL AND RELAY NODE USED IN THE METHOD |
FI20075252A0 (en) | 2007-04-13 | 2007-04-13 | Nokia Corp | Procedure, radio system, mobile terminal and base station |
EP2158714B1 (en) * | 2007-05-04 | 2019-08-21 | Nokia Solutions and Networks Oy | Aggregated harq report |
US8340029B2 (en) * | 2007-07-06 | 2012-12-25 | Zte (Usa) Inc. | Resource allocation in wireless multi-hop relay networks |
FI20075697A0 (en) * | 2007-10-02 | 2007-10-02 | Nokia Siemens Networks Oy | Method, computer program, apparatus and system |
EP1973274B1 (en) * | 2007-10-05 | 2010-06-02 | Industrial Technology Research Institute | Method for MAC process and flexible connection in wireless multi-hop relaying network |
CN101150587B (en) * | 2007-10-24 | 2010-07-07 | 华为技术有限公司 | A method, device and system for traffic switching of multi-protocol label switching traffic engineering |
CN100583800C (en) * | 2007-11-23 | 2010-01-20 | 清华大学 | Method for multicast employing single static bidirectional sharing tree in flexible wire type tunnel |
FI20070995A0 (en) | 2007-12-19 | 2007-12-19 | Nokia Siemens Networks Oy | Scalable deployment of network nodes |
US20090213778A1 (en) * | 2008-01-14 | 2009-08-27 | Zhifeng Tao | Fragmentation and Packing for Wireless Multi-User Multi-Hop Relay Networks |
US20100260109A1 (en) * | 2009-04-10 | 2010-10-14 | Qualcomm Incorporated | Optimized inter-access point packet routing for ip relay nodes |
US8724472B2 (en) * | 2010-03-25 | 2014-05-13 | Qualcomm Incorporated | Data radio bearer mapping in a telecommunication network with relays |
-
2009
- 2009-10-21 US US12/603,392 patent/US8902805B2/en active Active
- 2009-10-22 US US12/604,215 patent/US20100103864A1/en not_active Abandoned
- 2009-10-22 US US12/604,189 patent/US8401068B2/en active Active
- 2009-10-22 US US12/604,198 patent/US20100103857A1/en not_active Abandoned
- 2009-10-22 US US12/604,210 patent/US20100103845A1/en not_active Abandoned
- 2009-10-22 US US12/604,205 patent/US9088939B2/en active Active
- 2009-10-23 JP JP2011533385A patent/JP5384655B2/en active Active
- 2009-10-23 BR BRPI0919845-8A patent/BRPI0919845B1/en active IP Right Grant
- 2009-10-23 CN CN2009801418892A patent/CN102197679A/en active Pending
- 2009-10-23 WO PCT/US2009/061947 patent/WO2010048577A1/en active Application Filing
- 2009-10-23 JP JP2011533388A patent/JP5209796B2/en active Active
- 2009-10-23 KR KR1020137021816A patent/KR20130106888A/en not_active Application Discontinuation
- 2009-10-23 WO PCT/US2009/061933 patent/WO2010048565A1/en active Application Filing
- 2009-10-23 CN CN201610404530.1A patent/CN106102121B/en active Active
- 2009-10-23 KR KR1020117011812A patent/KR101383186B1/en active IP Right Grant
- 2009-10-23 TW TW098135994A patent/TWI424766B/en active
- 2009-10-23 TW TW098136021A patent/TW201032545A/en unknown
- 2009-10-23 TW TW098135990A patent/TW201032544A/en unknown
- 2009-10-23 EP EP09749249A patent/EP2359654A1/en not_active Withdrawn
- 2009-10-23 KR KR1020117011791A patent/KR101252031B1/en active IP Right Grant
- 2009-10-23 US US12/605,184 patent/US20100103865A1/en not_active Abandoned
- 2009-10-23 CN CN200980141865.7A patent/CN102197693B/en active Active
- 2009-10-23 WO PCT/US2009/061939 patent/WO2010048571A1/en active Application Filing
- 2009-10-23 TW TW098135982A patent/TWI424728B/en active
- 2009-10-23 WO PCT/US2009/061943 patent/WO2010048574A2/en active Application Filing
- 2009-10-23 TW TW098136014A patent/TW201019760A/en unknown
- 2009-10-23 WO PCT/US2009/061937 patent/WO2010048569A1/en active Application Filing
- 2009-10-23 WO PCT/US2009/061934 patent/WO2010048566A1/en active Application Filing
- 2009-10-23 EP EP09744859.1A patent/EP2359642B1/en active Active
- 2009-10-23 TW TW098136000A patent/TW201019762A/en unknown
- 2009-10-23 ES ES09744859T patent/ES2427172T3/en active Active
- 2009-10-26 EP EP09744866A patent/EP2359566A2/en not_active Withdrawn
- 2009-10-26 WO PCT/US2009/062100 patent/WO2010048621A2/en active Application Filing
- 2009-10-26 JP JP2011533413A patent/JP2012507209A/en active Pending
- 2009-10-26 CN CN2009801418820A patent/CN102197629A/en active Pending
- 2009-10-26 TW TW098136223A patent/TW201032547A/en unknown
- 2009-10-26 KR KR1020127032534A patent/KR20130008642A/en not_active Application Discontinuation
- 2009-10-26 KR KR1020117011797A patent/KR20110074930A/en active IP Right Grant
-
2013
- 2013-04-02 JP JP2013076891A patent/JP5579895B2/en active Active
Patent Citations (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5999980A (en) * | 1996-09-12 | 1999-12-07 | Cabletron Systems, Inc. | Apparatus and method for setting a congestion indicate bit in an backwards RM cell on an ATM network |
US6839339B1 (en) * | 2000-02-02 | 2005-01-04 | Lucent Technologies Inc. | Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets |
US7616601B2 (en) * | 2001-01-16 | 2009-11-10 | Netsocket, Inc. | Network resource manager in a mobile telecommunication system |
US7301947B2 (en) * | 2001-06-27 | 2007-11-27 | Nokia Corporation | Transmission of compression identifier of headers on data packet connection |
US20030223381A1 (en) * | 2002-06-04 | 2003-12-04 | Osmo Schroderus | Method for controlling parties in real-time data communication |
US20040001508A1 (en) * | 2002-06-28 | 2004-01-01 | Haihong Zheng | Method and system for transmitting data in a packet based communication network |
US20050265363A1 (en) * | 2002-09-24 | 2005-12-01 | Xiaobao Chen | Methods and apparatus for data transfer in a packet-switched data network |
US20080268852A1 (en) * | 2004-03-30 | 2008-10-30 | Matsushita Electric Industrial Co., Ltd. | Delayed Base Station Relocation in Distributed Radio Access Networks |
US20090052409A1 (en) * | 2004-07-30 | 2009-02-26 | Orange Sa | Telecommunications apparatus and method |
US20060139869A1 (en) * | 2004-12-29 | 2006-06-29 | Matusz Pawel O | Extended compression arrangements within telecommunication systems and associated methods |
US20080064390A1 (en) * | 2005-02-07 | 2008-03-13 | Kim Myeong-Cheol | Enhanced Radio Link Control Error Handling |
US20060262732A1 (en) * | 2005-05-18 | 2006-11-23 | Mika Joutsenvirta | Method for informing changed communications capabilities |
US20070072604A1 (en) * | 2005-08-17 | 2007-03-29 | Nortel Networks Limited | Method and system for a wireless multi-hop relay network |
US8055263B2 (en) * | 2005-10-05 | 2011-11-08 | Samsung Electronics Co., Ltd. | Fast cell selection method and apparatus for high speed downlink packet access system |
US20070213060A1 (en) * | 2006-03-07 | 2007-09-13 | Interdigital Technology Corporation | Method and apparatus for supporting handoff in an lte gtp based wireless communication system |
US20090257432A1 (en) * | 2006-03-16 | 2009-10-15 | Tsuyoshi Yamaguchi | Terminal |
US20070230352A1 (en) * | 2006-03-28 | 2007-10-04 | Nec Laboratories America, Inc. | Multipath Routing Architecture for Large Data Transfers |
US20080123660A1 (en) * | 2006-08-09 | 2008-05-29 | Interdigital Technology Corporation | Method and apparatus for providing differentiated quality of service for packets in a particular flow |
US7881247B2 (en) * | 2006-08-17 | 2011-02-01 | Interdigital Technology Corporation | Method and apparatus for providing efficient precoding feedback in a MIMO wireless communication system |
US20100246533A1 (en) * | 2006-08-18 | 2010-09-30 | Niklas Lundin | Intersystem Change Involving Mapping Between Different Types Of Radio Bearers |
US20080144555A1 (en) * | 2006-11-29 | 2008-06-19 | Samsung Electronics Co., Ltd. | Apparatus and method for identifying header compression channel in broadband wireless communication system |
US7876808B2 (en) * | 2006-11-30 | 2011-01-25 | Broadcom Corp. | Method and apparatus for adaptive noise and/or signal filtering in an HSDPA channel quality indicator (CQI) selection |
US20080165719A1 (en) * | 2007-01-05 | 2008-07-10 | Motorola, Inc. | Method and apparatus for relay zone bandwidth allocation |
US20080268846A1 (en) * | 2007-02-12 | 2008-10-30 | Interdigital Technology Corporation | Method and apparatus for supporting handoff from gprs/geran to lte eutran |
US20080219203A1 (en) * | 2007-03-09 | 2008-09-11 | Industrial Technology Research Institute. | Method for mac process and flexible connection in wireless multi-hop relaying network |
US20080240439A1 (en) * | 2007-03-15 | 2008-10-02 | Interdigital Technology Corporation | Methods and apparatus to facilitate data and security context transfer, and re-initialization during mobile device handover |
US8064395B2 (en) * | 2007-03-26 | 2011-11-22 | Vodafone Group Plc | Data transmission |
US20090016282A1 (en) * | 2007-03-26 | 2009-01-15 | Vodafone Group Plc | Data transmission |
US20090043902A1 (en) * | 2007-04-12 | 2009-02-12 | Stefano Faccin | Packet data network connectivity domain selection and bearer setup |
US20090042576A1 (en) * | 2007-07-27 | 2009-02-12 | Interdigital Patent Holdings, Inc. | Method and apparatus for handling mobility between non-3gpp to 3gpp networks |
US8054806B2 (en) * | 2007-08-14 | 2011-11-08 | Alcatel Lucent | Method and apparatus for radio link failure recovery in a wireless communications network |
US20100238805A1 (en) * | 2007-08-22 | 2010-09-23 | Reiner Ludwig | Data Transmission Control Methods And Devices |
US20090080422A1 (en) * | 2007-09-21 | 2009-03-26 | Posdata Co., Ltd. | Header-compression packet processing method, mobile station, base station, and control station in wireless communication system |
US20100226314A1 (en) * | 2007-09-27 | 2010-09-09 | Lixiang Xu | Method for user equipment performing direct communications via hnb access systems |
US8064909B2 (en) * | 2007-10-25 | 2011-11-22 | Cisco Technology, Inc. | Interworking gateway for mobile nodes |
US20090111423A1 (en) * | 2007-10-25 | 2009-04-30 | Interdigital Patent Holdings, Inc. | Non-access stratum architecture and protocol enhancements for long term evolution mobile units |
US20090109924A1 (en) * | 2007-10-26 | 2009-04-30 | Fujitsu Limited | Packet communication method, packet communication system, wireless terminal, and packet communication device |
US20090111476A1 (en) * | 2007-10-29 | 2009-04-30 | Nokia Siemens Networks Oy | Allocation of user equipment identifier |
US20090201878A1 (en) * | 2007-11-19 | 2009-08-13 | Cellco Partnership D/B/A Verizon Wireless | Low latency handover between wireless communication networks using different radio access technologies |
US20100309881A1 (en) * | 2007-11-29 | 2010-12-09 | Samsung Electronics Co., Ltd. | Mobile communication system and tunnel management method thereof |
US20090196177A1 (en) * | 2008-02-01 | 2009-08-06 | Nokia Siemens Networks Oy | Method, apparatus and computer program for uplink scheduling in a network that employs relay nodes |
US20090215459A1 (en) * | 2008-02-25 | 2009-08-27 | Richard Lee-Chee Kuo | Method and Apparatus for Improving Random Access Procedure for Handover |
US20090238207A1 (en) * | 2008-03-21 | 2009-09-24 | Research In Motion Limited | Dynamic Aggregated Maximum Bit Rate for Evolved Packet System Non-Guaranteed Bit Rate Quality of Service Enforcement and Network Bandwidth Utilization |
US20110044279A1 (en) * | 2008-04-30 | 2011-02-24 | Niklas Johansson | Self-Backhauling in LTE |
US20090296626A1 (en) * | 2008-05-30 | 2009-12-03 | Nokia Corporation | Method, apparatus and computer program for relay selection |
US20100091823A1 (en) * | 2008-10-13 | 2010-04-15 | Cisco Technology, Inc. | Two-hop Relay for Reducing Distance Vector Routing Information |
US20100097976A1 (en) * | 2008-10-16 | 2010-04-22 | Qualcomm Incorporated | Incremental redundancy relays for wireless communication |
US20100103864A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay protocol |
US20100103845A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay mobility procedures |
US20100103857A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay network attachment procedures |
US20100103863A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | BEARER QoS MAPPING FOR CELL RELAYS |
US20100103862A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Device attachment and bearer activation using cell relays |
US20100103861A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay packet routing |
US20110222428A1 (en) * | 2008-11-18 | 2011-09-15 | Nokia Corporation | Relaying in a communication system |
US20100260126A1 (en) * | 2009-04-13 | 2010-10-14 | Qualcomm Incorporated | Split-cell relay packet routing |
US20120120831A1 (en) * | 2009-06-05 | 2012-05-17 | Panasonic Corporation | Qos multiplexing via base station-relay node interface |
US20120140666A1 (en) * | 2009-06-08 | 2012-06-07 | Ntt Docomo, Inc. | Mobile communication system, relay node, radio base station, and gateway device |
US20120155375A1 (en) * | 2009-08-26 | 2012-06-21 | Huawei Technologies Co., Ltd. | Method and Apparatus for Header Compression in Network Relay Scenario |
Cited By (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110090840A1 (en) * | 2008-07-21 | 2011-04-21 | Electronics And Telecommunications Research Institute | Communication system for removing transmission overhead |
US20100103864A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay protocol |
US20100103845A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay mobility procedures |
US20100103857A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay network attachment procedures |
US20100103861A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Cell relay packet routing |
US20100103863A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | BEARER QoS MAPPING FOR CELL RELAYS |
US8902805B2 (en) | 2008-10-24 | 2014-12-02 | Qualcomm Incorporated | Cell relay packet routing |
US9088939B2 (en) | 2008-10-24 | 2015-07-21 | Qualcomm Incorporated | Bearer QoS mapping for cell relays |
US8401068B2 (en) | 2008-10-24 | 2013-03-19 | Qualcomm Incorporated | Device attachment and bearer activation using cell relays |
US20100103862A1 (en) * | 2008-10-24 | 2010-04-29 | Qualcomm Incorporated | Device attachment and bearer activation using cell relays |
US9584213B2 (en) * | 2008-11-05 | 2017-02-28 | Qualcomm Incorporated | Relays in a multihop heterogeneous UMTS wireless communication system |
US9380510B2 (en) * | 2009-01-23 | 2016-06-28 | Samsung Electronics Co., Ltd. | Apparatus and method for processing GTP in mobile communication system |
US20100189076A1 (en) * | 2009-01-23 | 2010-07-29 | Samsung Electronics Co. Ltd. | Apparatus and method for processing gtp in mobile communication system |
US9160566B2 (en) | 2009-04-10 | 2015-10-13 | Qualcomm Incorporated | QOS mapping for relay nodes |
US20100260129A1 (en) * | 2009-04-10 | 2010-10-14 | Qualcomm Incorporated | Qos mapping for relay nodes |
US8588138B2 (en) * | 2009-07-23 | 2013-11-19 | Qualcomm Incorporated | Header compression for relay nodes |
US20110019617A1 (en) * | 2009-07-23 | 2011-01-27 | Qualcomm Incorporated | Header compression for relay nodes |
US20110103294A1 (en) * | 2009-10-30 | 2011-05-05 | Institute For Information Industry | Donor evolved nodeb, relay node and communication method thereof |
US8630221B2 (en) * | 2009-10-30 | 2014-01-14 | Institute For Information Industry | Donor evolved NodeB, relay node and communication method thereof |
US9021072B2 (en) * | 2010-01-28 | 2015-04-28 | Verizon Patent And Licensing Inc. | Localized media offload |
US20110185049A1 (en) * | 2010-01-28 | 2011-07-28 | Verizon Patent And Licensing, Inc. | Localized media offload |
US8495271B2 (en) * | 2010-08-04 | 2013-07-23 | International Business Machines Corporation | Injection of I/O messages |
US8549202B2 (en) | 2010-08-04 | 2013-10-01 | International Business Machines Corporation | Interrupt source controller with scalable state structures |
US9336029B2 (en) | 2010-08-04 | 2016-05-10 | International Business Machines Corporation | Determination via an indexed structure of one or more partitionable endpoints affected by an I/O message |
US20120036304A1 (en) * | 2010-08-04 | 2012-02-09 | International Business Machines Corporation | Injection of i/o messages |
US20130215820A1 (en) * | 2010-10-08 | 2013-08-22 | Nokia Siemens Networks Oy | Relay Nodes |
US9986442B2 (en) * | 2010-10-08 | 2018-05-29 | Nokia Solutions And Networks Oy | Relay nodes |
US20130155918A1 (en) * | 2011-12-20 | 2013-06-20 | Nokia Siemens Networks Oy | Techniques To Enhance Header Compression Efficiency And Enhance Mobile Node Security |
US10945124B2 (en) | 2012-01-19 | 2021-03-09 | Samsung Electronics Co., Ltd. | Method for establishing an interface and communication between a relay node and a core network |
US20150023250A1 (en) * | 2012-01-19 | 2015-01-22 | Samsun Electronics Co., Ltd. | Method for establishing an interface and communication between a relay node and a core network |
US10009757B2 (en) * | 2012-01-19 | 2018-06-26 | Samsung Electronics Co., Ltd. | Method for establishing an interface and communication between a relay node and a core network |
US10021594B2 (en) | 2014-06-26 | 2018-07-10 | Gilat Satellite Networks Ltd. | Methods and apparatus for optimizing tunneled traffic |
US20160021161A1 (en) * | 2014-07-16 | 2016-01-21 | Alcatel-Lucent Usa, Inc. | Mobile network video optimization for centralized processing base stations |
US10277303B2 (en) * | 2014-10-28 | 2019-04-30 | Bayerische Motoren Werke Aktiengesellschaft | Vehicle-based femtocell with prioritization of data packets on the basis of the required internet service quality |
US20170230102A1 (en) * | 2014-10-28 | 2017-08-10 | Bayerische Motoren Werke Aktiengesellschaft | Vehicle-Based Femtocell with Prioritization of Data Packets on the Basis of the Required Internet Service Quality |
US9860786B1 (en) | 2016-02-01 | 2018-01-02 | Sprint Spectrum L.P. | Efficient backhaul for relay nodes |
US10623989B2 (en) * | 2016-10-27 | 2020-04-14 | Qualcomm Incorporated | Techniques and apparatuses for unidirectional robust header compression |
US11252635B2 (en) | 2018-02-14 | 2022-02-15 | Kt Corporation | Method for processing uplink user data in relay node, and device for same |
US11343715B1 (en) * | 2020-08-23 | 2022-05-24 | Rockwell Collins, Inc. | Header compression for network |
CN112399480A (en) * | 2020-11-05 | 2021-02-23 | 中国联合网络通信集团有限公司 | Method, apparatus and storage medium for reducing transmission overhead |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20100103865A1 (en) | Header compression for cell relay communications | |
EP2417795B1 (en) | Header compression for ip relay nodes | |
US9674311B2 (en) | Robust header compression for relay nodes | |
US8588138B2 (en) | Header compression for relay nodes | |
US8588227B2 (en) | Recursive header compression for relay nodes | |
US8787242B2 (en) | Header compression for relay nodes | |
US8855138B2 (en) | Relay architecture framework | |
US20110149848A1 (en) | Header compression for relay nodes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: QUALCOMM INCORPORATED,CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ULUPINAR, FATIH;HORN, GAVIN B.;AGASHE, PARAG A.;AND OTHERS;SIGNING DATES FROM 20091029 TO 20091104;REEL/FRAME:023537/0597 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |