U.S. patent application number 12/604215 was filed with the patent office on 2010-04-29 for cell relay protocol.
This patent application is currently assigned to QUALCOMM Incorporated. Invention is credited to Parag A. Agashe, Gavin B. Horn, Yongsheng Shi, Nathan E. Tenny, Fatih Ulupinar.
Application Number | 20100103864 12/604215 |
Document ID | / |
Family ID | 42117409 |
Filed Date | 2010-04-29 |
United States Patent
Application |
20100103864 |
Kind Code |
A1 |
Ulupinar; Fatih ; et
al. |
April 29, 2010 |
CELL RELAY PROTOCOL
Abstract
Systems and methodologies are described that facilitate
providing a relay protocol to facilitate communicating upper layer
protocol data among relay and donor nodes. In particular, a donor
node can create a relay protocol packet upon receiving data for a
relay node from a core network. Donor node can indicate an assigned
relay identifier in the relay protocol packet header to facilitate
routing the packet among related downstream relay nodes to arrive
at the appropriate relay node, which can process the upper layer
protocol data. In addition, a relay node can formulate a relay
protocol packet for communication to a donor node through zero or
more intermediary upstream relay nodes. Similarly, the relay node
can insert the assigned relay identifier in the header to allow the
donor node to associate response or related packets from the core
network with the relay node.
Inventors: |
Ulupinar; Fatih; (San Diego,
CA) ; Horn; Gavin B.; (La Jolla, CA) ; Agashe;
Parag A.; (San Diego, CA) ; Tenny; Nathan E.;
(Poway, CA) ; Shi; Yongsheng; (Falls Church,
VA) |
Correspondence
Address: |
QUALCOMM INCORPORATED
5775 MOREHOUSE DR.
SAN DIEGO
CA
92121
US
|
Assignee: |
QUALCOMM Incorporated
San Diego
CA
|
Family ID: |
42117409 |
Appl. No.: |
12/604215 |
Filed: |
October 22, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61108287 |
Oct 24, 2008 |
|
|
|
Current U.S.
Class: |
370/315 |
Current CPC
Class: |
H04L 69/22 20130101;
H04L 61/20 20130101; H04W 40/22 20130101; H04W 84/047 20130101;
H04L 2212/00 20130101; H04B 7/155 20130101; H04L 69/04 20130101;
H04L 29/12207 20130101; H04W 36/0072 20130101 |
Class at
Publication: |
370/315 |
International
Class: |
H04B 7/14 20060101
H04B007/14 |
Claims
1. A method, comprising: generating a relay protocol packet
comprising an upper layer protocol payload; populating a header of
the relay protocol packet with a relay identifier; and transmitting
the relay protocol packet to one or more evolved Node Bs (eNB) in a
wireless network.
2. The method of claim 1, further comprising: receiving a
downstream relay protocol packet from the one or more eNBs;
determining a type of an upper layer protocol corresponding to a
payload of the downstream relay protocol packet; and processing the
payload according to the type of the upper layer protocol.
3. The method of claim 2, wherein the processing the payload
includes providing the payload to a user equipment (UE) based at
least in part on the type of the upper layer protocol.
4. The method of claim 3, wherein the generating the relay protocol
packet includes generating the relay protocol packet based on a
communication received from the UE.
5. The method of claim 2, wherein the type of the upper layer
protocol is S1-U, S1-MME, X2, or other transport layer or
application protocol.
6. The method of claim 1, further comprising populating the header
of the relay protocol packet with a destination address of a
serving gateway (SGW) or a mobility management entity (MME).
7. The method of claim 1, further comprising setting a protocol
type value in the header of the relay protocol packet to a type of
the upper layer protocol payload.
8. The method of claim 1, wherein the upper layer protocol payload
is a compressed or uncompressed general packet radio service (GPRS)
tunneling protocol (GTP)-U/user datagram protocol (UDP)/internet
protocol (IP) packet.
9. The method of claim 1, further comprising receiving the relay
identifier in an assignment from a donor eNB.
10. The method of claim 1, wherein the relay identifier is a
received cell radio network temporary identifier (C-RNTI).
11. A wireless communications apparatus, comprising: at least one
processor configured to: create a relay protocol packet having an
upper layer protocol payload; insert a relay identifier in a header
of the relay protocol packet; and communicate the relay protocol
packet to one or more evolved Node Bs (eNB); and a memory coupled
to the at least one processor.
12. The wireless communications apparatus of claim 11, wherein the
at least one processor is further configured to: receive a
disparate relay protocol packet from the one or more eNBs; discern
a type of an upper layer protocol related to a payload of the
disparate relay protocol packet.
13. The wireless communications apparatus of claim 12, wherein the
at least one processor is further configured to provide the payload
to a user equipment (UE) based at least in part on the type of the
upper layer protocol.
14. The wireless communications apparatus of claim 12, wherein the
type of the upper layer protocol is S1-U, S1-MME, X2, or other
transport or application protocol.
15. The wireless communications apparatus of claim 11, wherein the
at least one processor creates the relay protocol packet based at
least in part on a request from a UE.
16. The wireless communications apparatus of claim 11, wherein the
at least one processor is further configured to insert a
destination address of a serving gateway (SGW) or a mobility
management entity (MME) in the header.
17. The wireless communications apparatus of claim 11, wherein the
at least one processor is further configured to initialize a
protocol type field in the header to a type of the upper layer
protocol payload.
18. The wireless communications apparatus of claim 11, wherein the
upper layer protocol payload is a compressed or uncompressed
general packet radio service (GPRS) tunneling protocol (GTP)-U/user
datagram protocol (UDP)/internet protocol (IP) packet.
19. An apparatus, comprising: means for generating a relay protocol
packet; and means for inserting a relay identifier in a header of
the relay protocol packet; and means for communicating the relay
protocol packet to one or more evolved Node Bs (eNB) in a wireless
network.
20. The apparatus of claim 19, further comprising means for
determining a type of an upper layer protocol corresponding to a
payload of a disparate relay protocol packet, wherein the means for
communicating further receives the disparate relay protocol packet
from the one or more eNBs.
21. The apparatus of claim 20, further comprising means for
providing the payload of the disparate relay protocol packet to a
user equipment (UE) based at least in part on the type of the upper
layer protocol.
22. The apparatus of claim 20, wherein the type of the upper layer
protocol is S1-U, S1-MME, X2, or other transport or application
protocol.
23. The apparatus of claim 19, wherein the means for generating the
relay protocol packet generates the relay protocol packet based at
least in part on a communication received from a UE.
24. The apparatus of claim 19, wherein the means for inserting the
relay identifier also inserts a destination address of a serving
gateway (SGW) or mobility management entity (MME) in the header of
the relay protocol packet.
25. The apparatus of claim 19, wherein the means for inserting the
relay identifier also inserts a type of an upper layer protocol
payload of the relay protocol packet in the header of the relay
protocol packet.
26. The apparatus of claim 25, wherein the upper layer protocol
payload is a compressed or uncompressed general packet radio
service (GPRS) tunneling protocol (GTP)-U/user datagram protocol
(UDP)/internet protocol (IP) packet.
27. The apparatus of claim 19, further comprising means for
receiving the relay identifier from a donor eNB.
28. The apparatus of claim 27, further comprising means for
requesting the relay identifier from the donor eNB, wherein the
means for receiving the relay identifier receives the relay
identifier based at least in part on requesting the relay
identifier.
29. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
generate a relay protocol packet comprising an upper layer protocol
payload; code for causing the at least one computer to populate a
header of the relay protocol packet with a relay identifier; and
code for causing the at least one computer to transmit the relay
protocol packet to one or more evolved Node Bs (eNB) in a wireless
network.
30. The computer program product of claim 29, wherein the
computer-readable medium further comprises: code for causing the at
least one computer to receive a downstream relay protocol packet
from the one or more eNBs; code for causing the at least one
computer to determine a type of an upper layer protocol
corresponding to a payload of the downstream relay protocol packet;
and code for causing the at least one computer to process the
payload according to the type of the upper layer protocol.
31. The computer program product of claim 30, wherein the code for
causing the at least one computer to process the payload provides
the payload to a user equipment (UE) based at least in part on the
type of the upper layer protocol.
32. The computer program product of claim 31, wherein the code for
causing the at least one computer to generate the relay protocol
packet generates the relay protocol packet based on a communication
received from the UE.
33. The computer program product of claim 30, wherein the type of
the upper layer protocol is S1-U, S1-MME, X2, or other transport or
application protocol.
34. The computer program product of claim 29, wherein the
computer-readable medium further comprises code for causing the at
least one computer to populate the header of the relay protocol
packet with a destination address of a serving gateway (SGW) or a
mobility management entity (MME).
35. The computer program product of claim 29, wherein the
computer-readable medium further comprises code for causing the at
least one computer to set a protocol type value in the header of
the relay protocol packet to a type of the upper layer protocol
payload.
36. The computer program product of claim 29, wherein the upper
layer protocol payload is a compressed or uncompressed general
packet radio service (GPRS) tunneling protocol (GTP)-U/user
datagram protocol (UDP)/internet protocol (IP) packet.
37. An apparatus, comprising: a relay protocol packet generating
component that creates a relay protocol packet comprising an upper
layer protocol payload; and a relay protocol header populating
component that inserts a relay identifier in a header of the relay
protocol packet; and a relay protocol communicating component that
transmits the relay protocol packet to one or more evolved Node Bs
(eNB) in a wireless network.
38. The apparatus of claim 37, further comprising a relay protocol
header reading component that determines a type of an upper layer
protocol corresponding to a payload of a disparate relay protocol
packet, wherein the relay protocol communicating component further
receives the disparate relay protocol packet from the one or more
eNBs.
39. The apparatus of claim 38, further comprising a packet routing
component that provides the payload of the disparate relay protocol
packet to a user equipment (UE) based at least in part on the type
of the upper layer protocol.
40. The apparatus of claim 38, wherein the type of the upper layer
protocol is S1-U, S1-MME, X2, or other transport or application
protocol.
41. The apparatus of claim 37, wherein the relay protocol packet
generating component creates the relay protocol packet based at
least in part on a communication received from a UE.
42. The apparatus of claim 37, wherein the relay protocol header
populating component also inserts a destination address of a
serving gateway (SGW) or mobility management entity (MME) in the
header of the relay protocol packet.
43. The apparatus of claim 42, wherein the relay protocol header
populating component also inserts a type of the upper layer
protocol payload in the header of the relay protocol packet.
44. The apparatus of claim 37, wherein the upper layer protocol
payload is a compressed or uncompressed general packet radio
service (GPRS) tunneling protocol (GTP)-U/user datagram protocol
(UDP)/internet protocol (IP) packet.
45. The apparatus of claim 37, further comprising a relay
identifier receiving component that receives the relay identifier
from a donor eNB.
46. The apparatus of claim 45, further comprising an identifier
requesting component that requests the relay identifier from the
donor eNB, wherein the relay identifier receiving component
receives the relay identifier based at least in part on requesting
the relay identifier.
47. A method, comprising: receiving a relay protocol packet
comprising an upper layer protocol payload and a relay identifier;
determining a relay evolved Node B (eNB) to receive the relay
protocol packet based at least in part on the relay identifier; and
transmitting the relay protocol packet to the relay eNB.
48. The method of claim 47, wherein the determining the relay eNB
to receive the relay protocol packet includes locating the relay
identifier in a routing table associating relay identifiers to cell
radio network temporary identifier (C-RNTI) of next hop downstream
relay eNBs.
49. The method of claim 47, further comprising: receiving a
disparate relay protocol packet from the relay eNB; and forwarding
the disparate relay protocol packet to an eNB from which the relay
protocol packet is received.
50. A wireless communications apparatus, comprising: at least one
processor configured to: obtain a relay protocol packet including
an upper layer protocol payload and a relay identifier; select a
relay evolved Node B (eNB) to receive the relay protocol packet
based at least in part on the relay identifier; and forward the
relay protocol packet to the relay eNB; and a memory coupled to the
at least one processor.
51. The wireless communications apparatus of claim 50, wherein the
at least one processor is further configured to maintain a routing
table associating relay identifiers with identifiers of next hop
relay eNBs, and the at least one processor selects the relay eNB
based at least in part on locating the relay identifier in the
routing table along with an associated identifier of the relay
eNB.
52. The wireless communications apparatus of claim 50, wherein the
at least one processor is further configured to: receive a
disparate relay protocol packet from the relay eNB; and forward the
disparate relay protocol packet to an eNB from which the relay
protocol packet is obtained.
53. An apparatus, comprising: means for storing a relay identifier
along with an identifier of a next hop relay evolved Node B (eNB);
and means for forwarding a relay protocol packet to the next hop
relay eNB based at least in part on locating the relay identifier
extracted from the relay protocol packet in the means for
storing.
54. The apparatus of claim 53, wherein the means for forwarding
determines a cell radio network temporary identifier (C-RNTI) of
the next hop relay eNB associated with the relay identifier in the
means for storing and forwards the relay protocol packet based on
the C-RNTI.
55. The apparatus of claim 53, wherein the means for forwarding
further forwards a disparate relay protocol packet received from
the next hop relay eNB to an eNB from which the relay protocol
packet is received.
56. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
receive a relay protocol packet comprising an upper layer protocol
payload and a relay identifier; code for causing the at least one
computer to determine a relay evolved Node B (eNB) to receive the
relay protocol packet based at least in part on the relay
identifier; and code for causing the at least one computer to
transmit the relay protocol packet to the relay eNB.
57. The computer program product of claim 56, wherein the code for
causing the at least one computer to determine the relay eNB to
receive the relay protocol packet locates the relay identifier in a
routing table associating relay identifiers to cell radio network
temporary identifier (C-RNTI) of next hop downstream relay
eNBs.
58. The computer program product of claim 56, wherein the
computer-readable medium further comprises: code for causing the at
least one computer to receive a disparate relay protocol packet
from the relay eNB; and code for causing the at least one computer
to forward the disparate relay protocol packet to an eNB from which
the relay protocol packet is received.
59. An apparatus, comprising: a routing table component that stores
a relay identifier along with an identifier of a next hop relay
evolved Node B (eNB); and a relay protocol forwarding component
that transmits a relay protocol packet to the next hop relay eNB
based at least in part on locating the relay identifier extracted
from the relay protocol packet in the routing table component.
60. The apparatus of claim 59, wherein the relay protocol
forwarding component determines a cell radio network temporary
identifier (C-RNTI) of the next hop relay eNB associated with the
relay identifier in the routing table component and forwards the
relay protocol packet based on the C-RNTI.
61. The apparatus of claim 59, wherein the relay protocol
forwarding component further forwards a disparate relay protocol
packet received from the next hop relay eNB to an eNB from which
the relay protocol packet is received.
62. A method, comprising: receiving a relay protocol packet
comprising an upper layer protocol payload and a relay identifier;
determining a type of the upper layer protocol payload; and
communicating the upper layer protocol payload, along with the
relay identifier, to a core network component over a disparate
transport layer based at least in part on the type of the upper
layer protocol payload.
63. The method of claim 62, further comprising determining a
destination internet protocol (IP) address of the core network
component from a header of the relay protocol packet, wherein the
communicating is further based at least in part on the destination
IP address.
64. The method of claim 62, wherein the determining the type of the
upper layer protocol payload includes determining the type of the
upper layer protocol payload to be S1-U and the communicating
includes communicating the upper layer protocol payload to a
serving gateway (SGW).
65. The method of claim 62, wherein the determining the type of the
upper layer protocol payload includes determining the type of the
upper layer protocol payload to be S1-MME and the communicating
includes communicating the upper layer protocol payload to a
mobility management entity (MME).
66. The method of claim 62, further comprising: receiving a
communication from the core network component comprising the relay
identifier; generating a disparate relay protocol packet including
the communication as a payload thereof; determining an next hop
relay evolved Node B (eNB) to receive the disparate relay protocol
packet; and transmitting the disparate relay protocol packet to the
next hop relay eNB.
67. The method of claim 66, further comprising populating a header
of the disparate relay protocol packet with the relay
identifier.
68. The method of claim 66, wherein the determining the next hop
relay eNB includes locating an association between an identifier of
the next hop relay eNB and the relay identifier in a routing table
of such identifier associations.
69. A wireless communications apparatus, comprising: at least one
processor configured to: obtain a relay protocol packet comprising
an upper layer protocol payload and a relay identifier; discern a
type of the upper layer protocol payload; and transmit the upper
layer protocol payload along with the relay identifier over a
disparate transport layer to an upstream network component; and a
memory coupled to the at least one processor.
70. The wireless communications apparatus of claim 69, wherein the
at least one processor is further configured to determine the
upstream network component based at least in part on the type of
the upper layer protocol payload.
71. The wireless communications apparatus of claim 70, wherein the
type of the upper layer protocol payload is S1-U and the upstream
network component is a serving gateway (SGW).
72. The wireless communications apparatus of claim 70, wherein the
type of the upper layer protocol payload is S1-MME and the upstream
network component is a mobility management entity (MME).
73. The wireless communications apparatus of claim 69, wherein the
at least one processor is further configured to determine a
destination internet protocol (IP) address of the upstream network
component from a header of the relay protocol packet, and the at
least one processor transmits the upper layer protocol payload to
the upstream network component based on the destination IP
address.
74. The wireless communications apparatus of claim 69, wherein the
at least one processor is further configured to: obtain a
communication from the upstream network component comprising the
relay identifier; create a disparate relay protocol packet having
the communication as a payload; select a next hop relay evolved
Node B (eNB) to receive the disparate relay protocol packet; and
transmit the relay protocol packet to the next hop relay eNB.
75. The wireless communications apparatus of claim 74, wherein the
at least one processor is further configured to populate a header
of the disparate relay protocol packet with the relay
identifier.
76. The wireless communications apparatus of claim 74, wherein the
at least one processor selects the next hop relay eNB based at
least in part on locating an association between the relay
identifier and an identifier of the next hop relay eNB in a routing
table.
77. An apparatus, comprising: means for receiving a relay protocol
packet comprising an upper layer protocol payload and a relay
identifier; and means for determining a type of the upper layer
protocol payload; and means for communicating the upper layer
protocol payload along with the relay identifier to a core network
component over a disparate transport layer.
78. The apparatus of claim 77, wherein the means for communicating
selects the core network component based at least in part on the
type of the upper layer protocol payload.
79. The apparatus of claim 78, wherein the type of the upper layer
protocol payload is S1-U and the core network component is a
serving gateway (SGW).
80. The apparatus of claim 78, wherein the type of the upper layer
protocol payload is S1-MME and the core network component is a
mobility management entity (MME).
81. The apparatus of claim 77, wherein the means for determining
the type of the upper layer protocol payload further extracts a
destination internet protocol (IP) address of the core network
component from a header of the relay protocol packet, and the means
for communicating selects the core network component based on the
destination IP address.
82. The apparatus of claim 77, further comprising: means for
generating a disparate relay protocol packet including a
communication as a payload thereof; and means for determining a
next hop relay evolved Node B (eNB) to receive the disparate relay
protocol packet, wherein the means for communicating receives the
communication from the core network component, and the means for
receiving transmits the disparate relay protocol packet to the next
hop relay eNB.
83. The apparatus of claim 82, further comprising means for
inserting the relay identifier in a header of the disparate relay
protocol packet.
84. The apparatus of claim 82, wherein the means for determining
the next hop relay eNB determines the next hop relay eNB based at
least in part on locating the relay identifier in a routing
table.
85. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
receive a relay protocol packet comprising an upper layer protocol
payload and a relay identifier; code for causing the at least one
computer to determine a type of the upper layer protocol payload;
and code for causing the at least one computer to communicate the
upper layer protocol payload, along with the relay identifier, to a
core network component over a disparate transport layer based at
least in part on the type of the upper layer protocol payload.
86. The computer program product of claim 85, further comprising
code for causing the at least one computer to determine a
destination internet protocol (IP) address of the core network
component from a header of the relay protocol packet, wherein the
code for causing the at least one computer to communicate
communicates the upper layer protocol payload further based at
least in part on the destination IP address.
87. The computer program product of claim 85, wherein the code for
causing the at least one computer to determine the type of the
upper layer protocol payload determines the type of the upper layer
protocol payload to be S1-U and the code for causing the at least
one computer to communicate communicates the upper layer protocol
payload to a serving gateway (SGW).
88. The computer program product of claim 85, wherein the code for
causing the at least one computer to determine the type of the
upper layer protocol payload determines the type of the upper layer
protocol payload to be S1-MME and the code for causing the at least
one computer to communicate communicates the upper layer protocol
payload to a mobility management entity (MME).
89. The computer program product of claim 85, wherein the
computer-readable medium further comprises: code for causing the at
least one computer to receive a communication from the core network
component comprising the relay identifier; code for causing the at
least one computer to generate a disparate relay protocol packet
including the communication as a payload thereof; code for causing
the at least one computer to determine an next hop relay evolved
Node B (eNB) to receive the disparate relay protocol packet; and
code for causing the at least one computer to transmit the
disparate relay protocol packet to the next hop relay eNB.
90. The computer program product of claim 89, wherein the
computer-readable medium further comprises code for causing the at
least one computer to populate a header of the disparate relay
protocol packet with the relay identifier.
91. The computer program product of claim 89, wherein the code for
causing the at least one computer to determine the next hop relay
eNB locates an association between an identifier of the next hop
relay eNB and the relay identifier in a routing table of such
identifier associations.
92. An apparatus, comprising: a relay protocol component that
receives a relay protocol packet comprising an upper layer protocol
payload and a relay identifier; and a relay protocol header reading
component that determines a type of the upper layer protocol
payload; and a backhaul link component that communicates the upper
layer protocol payload along with the relay identifier to a core
network component over a disparate transport layer.
93. The apparatus of claim 92, wherein the backhaul link component
selects the core network component based at least in part on the
type of the upper layer protocol payload.
94. The apparatus of claim 93, wherein the type of the upper layer
protocol payload is S1-U and the core network component is a
serving gateway (SGW).
95. The apparatus of claim 93, wherein the type of the upper layer
protocol payload is S1-MME and the core network component is a
mobility management entity (MME).
96. The apparatus of claim 92, wherein the relay protocol header
reading component further extracts a destination internet protocol
(IP) address of the core network component from a header of the
relay protocol packet, and the backhaul link component selects the
core network component based on the destination IP address.
97. The apparatus of claim 92, further comprising: a relay protocol
packet generating component that creates a disparate relay protocol
packet including a communication as a payload thereof; and a
routing table component that determines a next hop relay evolved
Node B (eNB) to receive the disparate relay protocol packet,
wherein the backhaul link component receives the communication from
the core network component, and the relay protocol component
transmits the disparate relay protocol packet to the next hop relay
eNB.
98. The apparatus of claim 97, further comprising a relay protocol
header populating component that inserts the relay identifier in a
header of the disparate relay protocol packet.
99. The apparatus of claim 97, wherein the routing table component
determines the next hop relay eNB based at least in part on
locating the relay identifier in a routing table.
Description
CLAIM OF PRIORITY UNDER 35 U.S.C. .sctn.119
[0001] 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.
BACKGROUND
[0002] 1. Field
[0003] The following description relates generally to wireless
communications, and more particularly to providing a protocol for
relay node communications.
[0004] 2. Background
[0005] 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.
[0006] 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.
[0007] 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.
SUMMARY
[0008] 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.
[0009] In accordance with one or more aspects and corresponding
disclosure thereof, various aspects are described in connection
with facilitating providing a relay protocol that supports packet
routing, point-to-point communications, and/or the like. In
particular, relay evolved Node Bs (eNB) can communicate using a
relay protocol layer that carriers upper layer protocol messages.
Relay eNBs can create a header for packets communicated over the
relay protocol layer, which can include fields indicating a type of
upper layer protocol message, an identifier for a destination relay
eNB, a destination internet protocol (IP) address, and/or the like.
In one example, the relay eNB identifier can be assigned by a donor
eNB and communicated to each relay eNB in the chain to the
destination relay eNB. In this regard, packets received from a core
network at the donor eNB can be routed to the destination relay eNB
by populating a relay ID field in the relay protocol header.
Receiving relay eNBs can obtain the relay ID and route the packet
according to a routing table associating relay IDs to downstream
relay eNB identifiers.
[0010] According to related aspects, a method is provided that
includes generating a relay protocol packet comprising an upper
layer protocol payload. The method also includes populating a
header of the relay protocol packet with a relay identifier and
transmitting the relay protocol packet to one or more eNBs in a
wireless network.
[0011] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to create a relay protocol packet
having an upper layer protocol payload and insert a relay
identifier in a header of the relay protocol packet. The at least
one processor is further configured to communicate the relay
protocol packet to one or more eNBs. The wireless communications
apparatus also comprises a memory coupled to the at least one
processor.
[0012] Yet another aspect relates to an apparatus. The apparatus
includes means for generating a relay protocol packet and means for
inserting a relay identifier in a header of the relay protocol
packet. The apparatus also includes means for communicating the
relay protocol packet to one or more eNBs in a wireless
network.
[0013] 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 generate a relay protocol packet
comprising an upper layer protocol payload. The computer-readable
medium can also comprise code for causing the at least one computer
to populate a header of the relay protocol packet with a relay
identifier and code for causing the at least one computer to
transmit the relay protocol packet to one or more eNBs in a
wireless network.
[0014] Moreover, an additional aspect relates to an apparatus
including a relay protocol packet generating component that creates
a relay protocol packet comprising an upper layer protocol payload
and a relay protocol header populating component that inserts a
relay identifier in a header of the relay protocol packet. The
apparatus can further include a relay protocol communicating
component that transmits the relay protocol packet to one or more
eNBs in a wireless network.
[0015] According to an additional aspect, a method is provided that
includes receiving a relay protocol packet comprising an upper
layer protocol payload and a relay identifier. The method also
includes determining a relay eNB to receive the relay protocol
packet based at least in part on the relay identifier and
transmitting the relay protocol packet to the relay eNB.
[0016] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to obtain a relay protocol packet
including an upper layer protocol payload and a relay identifier.
The at least one processor is further configured to select a relay
eNB to receive the relay protocol packet based at least in part on
the relay identifier and forward the relay protocol packet to the
relay eNB. The wireless communications apparatus also comprises a
memory coupled to the at least one processor.
[0017] Yet another aspect relates to an apparatus. The apparatus
includes means for storing a relay identifier along with an
identifier of a next hop relay eNB. The apparatus also includes
means for forwarding a relay protocol packet to the next hop relay
eNB based at least in part on locating the relay identifier
extracted from the relay protocol packet in the means for
storing.
[0018] 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 relay protocol packet
comprising an upper layer protocol payload and a relay identifier
and code for causing the at least one computer to determine a relay
eNB to receive the relay protocol packet based at least in part on
the relay identifier. The computer-readable medium can also
comprise code for causing the at least one computer to transmit the
relay protocol packet to the relay eNB.
[0019] Moreover, an additional aspect relates to an apparatus
including a routing table component that stores a relay identifier
along with an identifier of a next hop relay eNB. The apparatus can
further include a relay protocol forwarding component that
transmits a relay protocol packet to the next hop relay eNB based
at least in part on locating the relay identifier extracted from
the relay protocol packet in the routing table component.
[0020] According to yet another aspect, a method is provided that
includes receiving a relay protocol packet comprising an upper
layer protocol payload and a relay identifier and determining a
type of the upper layer protocol payload. The method further
includes communicating the upper layer protocol payload, along with
the relay identifier, to a core network component over a disparate
transport layer based at least in part on the type of the upper
layer protocol payload
[0021] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to obtain a relay protocol packet
comprising an upper layer protocol payload and a relay identifier
and discern a type of the upper layer protocol payload. The at
least one processor is further configured to transmit the upper
layer protocol payload along with the relay identifier over a
disparate transport layer to an upstream network component. The
wireless communications apparatus also comprises a memory coupled
to the at least one processor.
[0022] Yet another aspect relates to an apparatus. The apparatus
includes means for receiving a relay protocol packet comprising an
upper layer protocol payload and a relay identifier and means for
determining a type of the upper layer protocol payload. The
apparatus also includes means for communicating the upper layer
protocol payload along with the relay identifier to a core network
component over a disparate transport layer.
[0023] 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 relay protocol packet
comprising an upper layer protocol payload and a relay identifier
and code for causing the at least one computer to determine a type
of the upper layer protocol payload. The computer-readable medium
can also comprise code for causing the at least one computer to
communicate the upper layer protocol payload, along with the relay
identifier, to a core network component over a disparate transport
layer based at least in part on the type of the upper layer
protocol payload.
[0024] Moreover, an additional aspect relates to an apparatus
including a relay protocol component that receives a relay protocol
packet comprising an upper layer protocol payload and a relay
identifier. The apparatus can further include a relay protocol
header reading component that determines a type of the upper layer
protocol payload and a backhaul link component that communicates
the upper layer protocol payload along with the relay identifier to
a core network component over a disparate transport layer.
[0025] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 is an illustration of an example wireless
communications system that facilitates providing relays for
wireless networks.
[0027] FIG. 2 is an illustration of an example wireless
communications system that facilitates communicating over a relay
protocol.
[0028] FIG. 3 is an illustration of an example wireless
communications system that communicates over a relay protocol using
a cell radio network temporary identifier.
[0029] FIG. 4 is an illustration of an example relay protocol
component in accordance with aspects described herein.
[0030] FIG. 5 is an illustration of an example wireless
communications system that utilizes cell relays to provide access
to a wireless network.
[0031] FIG. 6 is an illustration of example protocol stacks that
facilitate providing cell relay functionality for data plane
communications using a relay protocol.
[0032] FIG. 7 is an illustration of an example methodology for
communicating with upstream relay nodes using a relay protocol.
[0033] FIG. 8 is an illustration of an example methodology for
receiving communications over a relay protocol.
[0034] FIG. 9 is an illustration of an example methodology that
forwards relay protocol packets in a wireless network.
[0035] FIG. 10 is an illustration of an example methodology that
receives relay protocol packets from downstream relay nodes and
formulates associated core network packets.
[0036] FIG. 11 is an illustration of an example methodology that
transmits relay protocol packets to downstream relay nodes.
[0037] FIG. 12 is an illustration of a wireless communication
system in accordance with various aspects set forth herein.
[0038] FIG. 13 is an illustration of an example wireless network
environment that can be employed in conjunction with the various
systems and methods described herein.
[0039] FIG. 14 is an illustration of an example system that
facilitates transmitting relay protocol packets to and receiving
relay protocol packets from upstream relay nodes.
[0040] FIG. 15 is an illustration of an example system that
facilitates forwarding relay protocol packets to relay nodes.
[0041] FIG. 16 is an illustration of an example system that
facilitates communicating between relay nodes and a core
network.
DETAILED DESCRIPTION
[0042] 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.
[0043] 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.
[0044] 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, or some other terminology.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] Referring to FIG. 1, a wireless communication system 100 is
illustrated that facilitates providing relay functionality in
wireless networks. 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. Similarly, 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. In one example, the core network 106 can be a 3GPP LTE or
similar technology network.
[0049] 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. In one example, 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.
[0050] According to an example, 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. 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 the
relay eNB 104. In addition, 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. 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.
[0051] With respect to transport layer communications, 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. For example, in a cell relay configuration, 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. 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 the relay eNB 104.
[0052] 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.
[0053] Moreover, application layer protocols can terminate at
upstream eNBs. Thus, for example, 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, 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 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. 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., relay eNB 104 can
communicate with one or more additional relay eNBs connected to
donor eNB 102).
[0054] According to an example, relay eNBs 104 and 108 and donor
eNB 102 can communicate over a relay protocol layer, which can be
communicated over a packet data convergence protocol (PDCP) layer
and can carry upper layer protocols. For example, communications
over the relay protocol layer can utilize a header, which can
include a field to indicate the upper layer protocol or interface
type (e.g., S1-U, S1-MME, X2, another transport or application
protocol, etc.) in the relay protocol packet payload, a destination
or source relay eNB identifier, an internet protocol (IP) address
related to a destination network node (e.g., MME, serving gateway
(SGW), etc.), and/or the like. In one example, relay eNB 108 can
request relay identifier assignment from donor eNB 102 via relay
eNB 104. Donor eNB 102 can assign a relay identifier to the relay
eNB 108 unique to the cluster provided by donor eNB 102, and
provide the relay identifier to relay eNB 108 through one or more
intermediary relay nodes, such as relay eNB 104. Donor eNB 102 and
the intermediary relay nodes can create a routing table that
associates the relay identifier to an identifier of a next
downstream relay eNB (e.g., a related cell radio network temporary
identifier (C-RNTI)), for example. Subsequent routing of packets
from core network 106 to relay eNB 108 can be based at least in
part on determining identifiers of next hop relay eNBs associated
with the relay identifier in respective routing tables.
[0055] In an example, relay eNB 108 can subsequently communicate
with relay eNB 104 over a relay protocol, which can carry upper
layer protocol data. A header for communications over the relay
protocol can include the type of the upper layer protocol, an
identifier for relay eNB 108, and a destination IP address for a
node in core network 106, where applicable. Relay eNB 104 can
forward the relay protocol communication to donor eNB 102, and
donor eNB 102 can determine the type of upper layer protocol,
formulate the appropriate transport layer packet, include the relay
identifier in the packet, and transmit the packet to the
appropriate node in core network 106; this can be based at least in
part on the IP address if present, the upper layer protocol type,
and/or the like.
[0056] Upon receiving a response or other related communication
from core network 106, donor eNB 102 can obtain the relay
identifier from the communication. In addition, donor eNB 102 can
establish a relay protocol layer for communication with relay eNB
104 in place of a transport layer (e.g., user datagram protocol
(UDP)/IP) utilized in communicating with core network 106 and
generate a related relay protocol header. Donor eNB 102 can
populate the header with a relay identifier for relay eNB 108, a
protocol type for the application layer carried by the relay
protocol, and/or the like, and attach the header to the application
layer communication from core network 106. Donor eNB 102 can
determine a next hop relay eNB from the routing table, described
previously, by locating the relay identifier in the routing table
and obtaining the related next hop relay eNB identifier. Donor eNB
102 can then transmit the relay protocol communication to the next
hop relay, relay eNB 104, based at least in part on the identifier
thereof in the routing table. Relay eNB 104 can receive the
communication, extract the relay identifier, and forward the
communication to relay eNB 108 based at least in part on locating
relay eNB 108 as the next hop in a routing table, for example.
Relay eNB 108 can receive the packet over the relay protocol and
process that data. Where the data relates to a UE or other device
communicating with the relay eNB 108, relay eNB 108 can forward at
least a portion of the packet thereto.
[0057] Turning now to FIG. 2, an example wireless communication
system 200 that facilitates communicating among eNBs using a relay
protocol is illustrated. 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 relay eNB 108 with access to the core network 106 through
the donor eNB 102. In an example, however, relay eNB 104 may not be
present, and relay eNB 108 can communicate directly with donor eNB
102. In a similar example, there can be multiple relay eNBs 104
between the donor eNB 102 and relay eNB 108. In addition, it is to
be appreciated that relay eNB 108 can comprise the components of
relay eNB 104 and 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 eNBs 104 (and relay eNB 108) can similarly be
mobile or stationary relay nodes that communicate with donor eNB
102 (and relay eNB 104) over a wireless or wired backhaul, as
described.
[0058] Donor eNB 102 comprises an identifier request receiving
component 202 that obtains a relay identifier assignment request
from one or more relay eNBs, a relay identifier assigning component
204 that selects a relay identifier for the one or more relay eNBs,
a routing table component 206 that stores associations between
assigned relay identifiers and identifiers of next hop relay eNBs
to reach the relay eNB related to the relay identifier, a backhaul
link component 208 that communicates with core network 106 over a
transport layer, and a relay protocol component 210 that
communicates with relay eNBs over a disparate transport layer.
[0059] Relay eNB 104 can include an identifier request receiving
component 212 that obtains a request for a relay identifier from a
downstream eNB and forwards the request to an upstream eNB, a relay
identifier receiving component 214 that obtains a relay identifier
for a downstream eNB from one or more upstream eNBs and provides
the relay identifier to a next hop downstream eNB, a routing table
component 216 that stores an association between the relay
identifier and an identifier of the next hop downstream eNB, and a
relay protocol forwarding component 218 that establishes and
communicates over a relay protocol to one or more eNBs.
[0060] Relay eNB 108 comprises an identifier requesting component
220 that transmits a request for a relay identifier to one or more
upstream eNBs, a relay identifier receiving component 222 that
obtains a relay identifier from the one or more upstream eNBs, a
relay protocol component 224 that establishes and communicates over
a relay protocol connection with one or more upstream eNBs, and a
packet routing component 226 that communicates data received over a
relay protocol to one or more UEs or other devices.
[0061] According to an example, identifier requesting component 220
can formulate a request for a relay identifier for communicating
with other relay or donor eNBs over a relay protocol in a wireless
network. Identifier requesting component 220 can transmit the
request to relay eNB 104, if present, or donor eNB 102 if relay eNB
104 is not present. Where relay eNB 104 is present, identifier
request receiving component 212 can obtain the request from relay
eNB 108 and forward the request upstream to donor eNB 102. It is to
be appreciated, in one example, that there can be multiple relay
eNBs in the communication chain from relay eNB 108 to donor eNB
102, and the multiple relay eNBs can similarly receive and forward
the request.
[0062] In any case, identifier request receiving component 202 can
obtain the request for relay identifier assignment. Relay
identifier assigning component 204 can select a relay identifier
for relay eNB 108. The selection can conform to one or more
specification details, such as size, character set, etc., and can
be unique within the cluster served by donor eNB 102. Routing table
component 206 can store an association between the relay identifier
and an identifier of next hop eNB (eNB 104 if present, or eNB 108
if eNB 104 is not present), and relay identifier assigning
component 204 can provide the relay identifier to the next hop eNB.
If relay eNB 104 is present, relay identifier receiving component
214 can obtain the relay identifier for relay eNB 108, and routing
table can store an association between the relay identifier and an
identifier for the next hop relay eNB (relay eNB 108 in this
example). It is to be appreciated that, where multiple relay eNBs
exist in the communication chain between relay eNB 108 and donor
eNB 102, each of the multiple relay eNBs can receive the relay
identifier assignment, store an association to a next hop relay eNB
in a routing table, and forward the relay identifier assignment to
the next hop relay eNB.
[0063] In any case, relay identifier receiving component 222 can
obtain and store the relay identifier. Relay protocol component 224
can subsequently generate relay protocol layer communications to
relay eNB 104, if present, or donor eNB 102 if relay eNB 104 is not
present. In one example, relay protocol component 224 can generate
the relay protocol layer communications in response to receiving a
request or other communications from UE 110 or another device.
Relay protocol component 224 can create a relay protocol packet
comprising a relay protocol header and a payload, which can
comprise upper layer protocol data (e.g., S1-U, S1-MME, X2 data
and/or the like). In addition, relay protocol component 224 can
populate the header with the relay identifier, a protocol type of
upper layer protocol data in the payload, an optional destination
IP address (e.g., of an MME or SGW in the core network 106), and
can transmit the relay protocol packet to relay eNB 104, if
present, or donor eNB 102 if relay eNB 104 is not present.
[0064] Relay protocol forwarding component 218 can receive the
relay protocol communications from relay eNB 108, if relay eNB 104
is present, and can forward the communications to donor eNB 102
over the relay protocol. Similarly, if multiple relay eNBs are in
the communication path between relay eNB 108 and donor eNB 102,
each of the multiple relay eNBs can similarly receive and forward
the relay protocol communications to the next upstream relay eNB.
Relay protocol component 210 can receive the communications over
the relay protocol from relay eNB 104 or relay eNB 108 and can
obtain the relay identifier from the relay protocol header.
Backhaul link component 208 can generate a communication for core
network 106 over a disparate transport layer, indicate the relay
identifier in the communication, and transmit the communication to
the core network 106, for example. The disparate transport layer
can be a UDP/IP layer and/or the like, for example.
[0065] Backhaul link component 208 can receive a response or other
communication related to relay eNB 108 from core network 106.
Backhaul link component 208 can obtain the relay identifier from
the communication, and routing table component 206 can determine a
next hop relay eNB based on the relay identifier, as described.
Relay protocol component 210 can generate a relay protocol packet
comprising a header and payload, which can be the upper layer
protocol data received from core network 106 by backhaul link
component 208 (e.g., S1-U, S1-MME, or X2 data). Relay protocol
component 210 can set the relay identifier field in the header to
be the relay identifier of relay eNB 108 and the protocol type to
indicate the type of upper layer protocol data in the payload.
Relay protocol component 210 can transmit the relay protocol packet
to the next hop relay eNB determined by the routing table component
206 (e.g., relay eNB 104 if present, or relay eNB 108 if relay eNB
104 is not present, in this example).
[0066] If relay eNB 104 is present, relay protocol forwarding
component 218 can receive the packet from donor eNB 102 and can
obtain the relay identifier in the relay protocol packet header.
Routing table component 216 can determine the next hop relay eNB by
locating the relay identifier in the routing table and retrieving
the associated next hop relay eNB identifier. Relay protocol
forwarding component 218 can forward the relay protocol packet to
the next hop relay eNB. Where additional relay eNBs exist in the
communication chain between relay eNB 108 and donor eNB 102, the
additional relay eNBs can similarly receive the relay protocol
packet, determine the relay identifier, discern a next hop relay
eNB based on the relay identifier, and forward the packet to the
next hop eNB.
[0067] Relay protocol component 224 can receive the relay protocol
packet from relay eNB 104, if present, or donor eNB 102 if relay
eNB 104 is not present, and can determine the upper layer protocol
message type from the relay protocol header. For example, where the
upper layer protocol type is a S1-U, S1-MME, or other message
relating to a communication from UE 110 or another device, packet
routing component 226 can forward the payload of the relay protocol
message to UE 110 or other related device; this can be based on a
previously created routing table, in one example. Where the
protocol type is X2 or another message relating to eNB
communications, relay eNB 108 can process the message. In one
example, the relay protocol header can have a format similar to the
following.
TABLE-US-00001 Protocol (3 bits) I (1 bit) Reserved (4 bits) Relay
ID (16 bits) Destination IP Address (optional)
In this format, for example, the protocol field, as described, can
relate to an upper layer protocol type for the payload data in the
packet, the I (indicator) field can specify whether the destination
IP address is present, the reserved field can be reserved for
additional data, the relay ID field can store the relay identifier
described above, and the destination IP field can hold an IP
address for a destination SGW, MME, etc. (e.g., in uplink packets).
It is to be appreciated that this is but one example of a relay
packet header; substantially limitless formats are possible.
[0068] Turning now to FIG. 3, an example wireless communication
system 300 that facilitates providing a relay protocol for a single
tier relay node wireless network implementation is illustrated.
System 300 includes a donor eNB 102 that provides relay eNB 108
(and/or other relay eNBs) with access to core network 106.
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 108 can similarly be mobile or stationary relay
nodes that communicate with donor eNB 102 over a wireless or wired
backhaul, as described.
[0069] Donor eNB 102 comprises a backhaul link component 208 that
communicates with core network 106 over a transport layer and a
relay protocol component 210 that communicates with relay eNBs over
a disparate transport layer. Relay eNB 108 comprises a relay
protocol component 224 that establishes and communicates over a
relay protocol connection with one or more upstream eNBs and a
packet routing component 226 that communicates data received over a
relay protocol to one or more UEs or other devices.
[0070] According to an example, relay protocol component 224 can
generate a communication for one or more core network 106
components (e.g., a SGW, MME, disparate eNB, and/or the like) along
with a relay protocol packet for the communication. This can be
based on receiving a communication from UE 110, in one example.
Relay protocol component 224 can populate a relay identifier field
in the relay protocol header with a C-RNTI of relay eNB 108, which
is unique in the cluster provided by donor eNB 102 where only one
tier of relay eNBs are attached to donor eNB 102 (e.g., there is
only one relay eNB between end devices, such as UEs, and donor eNB
102). In this regard, no identifier requesting process is
needed.
[0071] Relay protocol component 224 can transmit the relay protocol
packet to donor eNB 102, and relay protocol component 210 can
receive the packet. Relay protocol component 210 can additionally
extract the relay identifier. Backhaul link component 208 can
generate a packet over a disparate transport layer (e.g., UDP/IP
layer) for transmission to core network 106. Backhaul link
component 208 can also include the relay identifier (C-RNTI) in the
packet and transmit the packet to core network 106. In addition,
backhaul link component 208 can receive a response to the packet or
other communication from core network 106 over the disparate
transport layer. Backhaul link component can extract a relay
identifier from the packet, for example. Relay protocol component
210 can generate a relay protocol packet with application layer
data from the packet received over the backhaul link as the
payload. Relay protocol component 210 can transmit the packet to
relay eNB 108 based on the relay identifier (C-RNTI). Thus, no
routing table is needed in this example either. Relay protocol
component 224 can receive the packet and can communicate the
payload to UE 110 using packet routing component 226, as described,
where applicable.
[0072] Referring to FIG. 4, an example relay protocol component 400
is depicted in accordance with various aspects described herein.
For example, relay protocol component 400 can be similar to relay
protocol components 210 and 224 of the previous figures. Relay
protocol component 400 can include a relay protocol communicating
component 402 that receives and transmits data over a relay
protocol, a relay protocol header reading component 404 that
obtains one or more field values from a relay protocol header, a
relay protocol packet generating component 406 that creates a relay
protocol packet for transmitting to one or more eNBs, and a relay
protocol header populating component 408 that initializes one or
more fields in a relay protocol header.
[0073] According to an example, as described, relay protocol
communicating component 402 can receive a relay protocol packet
from one or more eNBs, and relay protocol header reading component
404 can extract one or more field values from the header, such as
protocol type, relay identifier, destination IP address, and/or the
like, as described. Other components, as described, can utilize the
information to process payload of the relay protocol packet, route
the packet, and/or the like. In another example, relay protocol
packet generating component 406 can create relay protocol packets
for transmitting to one or more eNBs, as described. In addition,
the relay protocol packet generating component 406 can insert an
upper layer protocol message in the payload of the relay protocol
packet. Moreover, as described previously, the relay protocol
header populating component 408 can set field values in the relay
protocol header. Relay protocol communicating component 402 can
transmit the relay protocol packet to one or more eNBs.
[0074] Now turning to FIG. 5, an example wireless communication
network 500 that provides cell relay functionality is depicted.
Network 500 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 502 and/or SGW 504 that relate
to the relay eNB 104. SGW 504 can connect to or be coupled with a
PGW 506, which provides network access to SGW 504 and/or additional
SGWs. PGW 506 can communicate with a PCRF 508 to
authenticate/authorize UE 110 to use the network, which can utilize
an IMS 510 to provide addressing to the UE 110 and/or relay eNB
104.
[0075] According to an example, MME 502 and/or SGW 504 and PGW 506
can be related to donor eNB 102 serving substantially all relay
eNBs in the cluster. Donor eNB 102 can also communicate with an SGW
516 and PGW 518 that relate to the UE 110, such that the PGW 518
can assign UE 110 a network address to facilitate tunneling
communications thereto through the relay eNB 104, donor eNB 102,
and SGW 516. Moreover, for example, SGW 516 can communicate with an
MME 514 to facilitate control plane communications to and from the
UE 110. It is to be appreciated that MME 502 and MME 514 can be the
same MME, in one example. PGW 518 can similarly communicate with a
PCRF 508 to authenticate/authorize UE 110, which can communicate
with an IMS 510. In addition, PGW 518 can communicate directly with
the IMS 510 and/or internet 512.
[0076] In an example, 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 502 using an S1-MME
interface and the SGW 504 and PGW 506 over an S1-U interface, as
depicted. In addition, as described, communications received from
relay eNB 104 for MME 502 or SGW 504/PGW 506 can be over a relay
protocol and can have an IP address of MME 502 or SGW 504/PGW 506
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 addition, the transport layers used over the
S1-MME and S1-U interfaces are terminated at the donor eNB 102, as
described. In this regard, upon receiving communications for the
relay eNB 104 from the MME 502 or SGW 504, donor eNB 102 decouples
the application layer from the transport layer by defining a new
relay protocol packet and transmitting the application layer
communication to the relay eNB 104 in the new relay protocol packet
(over the E-UTRA-Uu interface, in one example).
[0077] Upon transmitting control plane communications from the
relay eNB 104 to the MME 502, donor eNB 102 can indicate an
identifier of the relay eNB 104 (e.g., in an S1-AP message), and
MME 502 can transmit the identifier in responding communications to
the donor eNB 102. When transmitting data plane communications from
relay eNB 104 to SGW 504, 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 general packet radio service (GPRS) tunneling
protocol (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. In
addition, headers can be compressed, in one example, as described.
As shown, MME 502 can communicate with SGW 504, and MME 514 to SGW
516, using an S11 interface. PGWs 506 and 518 can communicate with
PCRF 508 over a Gx interface. Furthermore, PCRF 508 can communicate
with IMS 510 using an Rx interface, and PGW 518 can communicate
with IMS 510 and/or the internet 512 using an SGi interface.
[0078] Referring to FIG. 6, example protocol stacks 600 are
illustrated that facilitate communicating in a wireless network to
provide cell relay functionality for data (e.g., user) plane
communications. A UE protocol stack 602 is shown comprising an L1
layer, MAC layer, an RLC layer, a PDCP layer, and an IP layer. A
relay eNB1 (ReNB) access link protocol stack 604 is depicted having
an L1 layer, MAC layer, RLC layer, and PDCP layer, as well as an
ReNB1 backhaul link protocol stack 606 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 or uncompressed
layer in one example, to facilitate communicating packets on the
backhaul. An intermediary ReNB2 access link protocol stack 608 is
shown having an L1 layer, MAC layer, RLC layer, PDCP layer, and RP
layer, as well as a backhaul link protocol stack 610 for the
intermediary ReNB2 having the same layers.
[0079] A CeNB access link protocol stack 608 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 CeNB backhaul link protocol stack
610 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 612 has an L1 layer, L2,
layer, UDP/IP layer related to an address assigned to the CeNB,
GTP-U layer, and another IP layer related to an address assigned to
the UE.
[0080] 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 602 and 604.
The UE can tunnel IP layer communications through the ReNB1 and
other entities to the PGW/SGW, which assigns an IP address to the
UE, as shown between protocol stacks 602 and 616. To facilitate
such tunneling, ReNB1 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 between protocol stacks 606 and 608. In
addition, 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 606 and 608. Moreover, as described,
the RP header can include an identifier of ReNB1, 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.
[0081] ReNB2, and any other intermediary ReNBs, can forward the RP
communication to the CeNB, as shown between protocol stack s 610
and 612. In this example, CeNB 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 614 and 616. In one
example, the CeNB 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 612 can include
the relay identifier. In this regard, upon receiving downlink
communications from PGW/SGW protocol stack 616 over CeNB backhaul
link protocol stack 614, CeNB access link protocol stack 612 can
generate an RP packet with a header comprising the relay identifier
received over PGW/SGW protocol stack 616 and a compressed
GTP-U/UDP/IP packet as the payload. CeNB access link protocol stack
612 can transmit the RP packet over ReNB2 backhaul link protocol
stack 612, which can forward the RP packet over ReNB2 access link
protocol stack 608 to ReNB backhaul link protocol stack 606 based
on the relay identifier in the RP header, as described. ReNB1
backhaul link protocol stack 606 can obtain the C-GTP-U/UDP/IP
payload of the RP packet and forward to UE protocol stack 602,
where the RP packet payload is of certain types, as described.
[0082] Referring to FIGS. 7-11, methodologies relating to providing
a relay protocol in relay node communications 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.
[0083] Referring to FIG. 7, a methodology 700 is shown that
facilitates transmitting upstream relay protocol packets with relay
identifiers. At 702, a relay protocol packet can be generated
comprising an upper layer protocol payload. For example, the relay
protocol packet can be created based at least in part on receiving
a request or other communication from a UE. In addition, the upper
layer protocol payload can be the communication from the UE, which
can be a S1-U, S1-MME, or similar protocol communication. In
another example, the upper layer protocol payload can be an X2
protocol communication. At 704, a header of the relay protocol
packet can be populated with a relay identifier. This can be an
identifier previously received from a donor eNB, a C-RNTI, and/or
the like, as described. At 706, the relay protocol packet can be
transmitted. In one example, the packet can be transmitted to an
upstream relay node to eventually reach a donor eNB. The donor eNB
can utilize the relay identifier, as described herein, to associate
response data to the transmitted packet. In another example, a
destination IP address can be specified in the header, as
described, to facilitate routing the packet to a certain core
network component via the donor eNB.
[0084] Turning to FIG. 8, an example methodology 800 that
facilitates receiving relay protocol packets from upstream relay or
donor nodes is illustrated. At 802, a downstream relay protocol
packet can be received. For example, the relay protocol can be
received from an upstream relay or donor node. At 804, a type of an
upper layer protocol payload of the relay protocol packet can be
determined. In one example, the type can be specified in a header
of the relay protocol packet, and thus can be determined by
obtaining the type field from the header. At 806, the upper layer
protocol payload can be processed according to the type. For
example, if the upper layer protocol type is S1-U or S1-MME, the
payload can be transmitted to a related UE. If the upper layer
protocol type is X2, however, the payload can be processed locally,
in an example.
[0085] Referring to FIG. 9, an example methodology 900 is shown
that facilitates forwarding relay protocol packets among eNBs based
on a relay identifier in the header of the relay protocol packets.
At 902, a relay protocol packet comprising a relay identifier can
be received. As described, the packet can be received from an
upstream node, such as a donor eNB or a disparate relay eNB. A
relay node to receive the relay protocol packet can be determined
based at least in part on the relay identifier, at 904. As
described, this step can include consulting a routing table to
determine a next hop relay node relating to the relay identifier.
The association can have been stored during an initial request for
the relay identifier from a downstream relay node. At 906, the
relay protocol packet can be forwarded to the relay node.
[0086] Turning to FIG. 10, an example methodology 1000 that
facilitates communicating relay protocol data to a core network is
illustrated. At 1002, a relay protocol packet comprising an upper
layer protocol payload and a relay identifier is received. The
relay protocol packet can be received from a downstream relay node,
as described. At 1004, a type of the upper layer protocol payload
can be determined. In one example, the type can relate to an S1-U,
S1-MME, X2, or similar protocol. At 1006, the upper layer protocol
payload can be transmitted over a disparate transport layer along
with the relay identifier. Thus, for example, the payload can be
transmitted over a backhaul link to a core network over a UDP/IP or
other transport protocol. Depending on the type of the upper layer
protocol payload, for example, the packet can be transmitted to
different core network components (e.g., an SGW for S1-U payload,
MME for S1-MME payload, a disparate eNB for X2 payload, etc.).
[0087] Referring to FIG. 11, an example methodology 1100 is shown
that facilitates routing downstream packets from a core network to
one or more relay nodes. At 1102, a communication can be received
from a core network component comprising a relay identifier. A
relay protocol packet can be generated including the communication
as the payload at 1104. Using the relay protocol, as described,
facilitates routing of the packets to one or more relay nodes, for
example. At 1106, the relay protocol packet header can be populated
with the relay identifier. Subsequent relay nodes, as described,
can utilize the relay identifier to determine next hop relay nodes
for the relay protocol packet. At 1108, a next hop relay node can
be determined. In an example, this can be determined based at least
in part on querying a routing table to locate an association
between the relay identifier and an identifier of the next hop
relay node, as described herein. At 1110, the relay protocol packet
can be transmitted to the next hop relay node.
[0088] It will be appreciated that, in accordance with one or more
aspects described herein, inferences can be made regarding
generating a relay protocol packet, such as whether to include a
destination IP address, etc., generating a relay identifier unique
to a cluster, determining next hop relay eNBs, 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.
[0089] Referring now to FIG. 12, a wireless communication system
1200 is illustrated in accordance with various embodiments
presented herein. System 1200 comprises a base station 1202 that
can include multiple antenna groups. For example, one antenna group
can include antennas 1204 and 1206, another group can comprise
antennas 1208 and 1210, and an additional group can include
antennas 1212 and 1214. Two antennas are illustrated for each
antenna group; however, more or fewer antennas can be utilized for
each group. Base station 1202 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.
[0090] Base station 1202 can communicate with one or more mobile
devices such as mobile device 1216 and mobile device 1222; however,
it is to be appreciated that base station 1202 can communicate with
substantially any number of mobile devices similar to mobile
devices 1216 and 1222. Mobile devices 1216 and 1222 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 1200.
As depicted, mobile device 1216 is in communication with antennas
1212 and 1214, where antennas 1212 and 1214 transmit information to
mobile device 1216 over a forward link 1218 and receive information
from mobile device 1216 over a reverse link 1220. Moreover, mobile
device 1222 is in communication with antennas 1204 and 1206, where
antennas 1204 and 1206 transmit information to mobile device 1222
over a forward link 1224 and receive information from mobile device
1222 over a reverse link 1226. In a frequency division duplex (FDD)
system, forward link 1218 can utilize a different frequency band
than that used by reverse link 1220, and forward link 1224 can
employ a different frequency band than that employed by reverse
link 1226, for example. Further, in a time division duplex (TDD)
system, forward link 1218 and reverse link 1220 can utilize a
common frequency band and forward link 1224 and reverse link 1226
can utilize a common frequency band.
[0091] 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 1202. For example, antenna groups can be designed to
communicate to mobile devices in a sector of the areas covered by
base station 1202. In communication over forward links 1218 and
1224, the transmitting antennas of base station 1202 can utilize
beamforming to improve signal-to-noise ratio of forward links 1218
and 1224 for mobile devices 1216 and 1222. Also, while base station
1202 utilizes beamforming to transmit to mobile devices 1216 and
1222 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 1216 and 1222 can
communicate directly with one another using a peer-to-peer or ad
hoc technology (not shown).
[0092] According to an example, system 1200 can be a multiple-input
multiple-output (MIMO) communication system. Further, system 1200
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 1202 can communicate to
the mobile devices 1216 and 1222 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.
[0093] FIG. 13 shows an example wireless communication system 1300.
The wireless communication system 1300 depicts one base station
1310 and one mobile device 1350 for sake of brevity. However, it is
to be appreciated that system 1300 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 1310 and mobile device 1350
described below. In addition, it is to be appreciated that base
station 1310 and/or mobile device 1350 can employ the systems
(FIGS. 1-5 and 12), protocol stacks (FIG. 6) and/or methods (FIGS.
7-11) described herein to facilitate wireless communication
therebetween.
[0094] At base station 1310, traffic data for a number of data
streams is provided from a data source 1312 to a transmit (TX) data
processor 1314. According to an example, each data stream can be
transmitted over a respective antenna. TX data processor 1314
formats, codes, and interleaves the traffic data stream based on a
particular coding scheme selected for that data stream to provide
coded data.
[0095] 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 1350 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 by processor 1330.
[0096] The modulation symbols for the data streams can be provided
to a TX MIMO processor 1320, which can further process the
modulation symbols (e.g., for OFDM). TX MIMO processor 1320 then
provides N.sub.T modulation symbol streams to N.sub.T transmitters
(TMTR) 1322a through 1322t. In various aspects, TX MIMO processor
1320 applies beamforming weights to the symbols of the data streams
and to the antenna from which the symbol is being transmitted.
[0097] Each transmitter 1322 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.sub.T modulated signals from
transmitters 1322a through 1322t are transmitted from N.sub.T
antennas 1324a through 1324t, respectively.
[0098] At mobile device 1350, the transmitted modulated signals are
received by N.sub.R antennas 1352a through 1352r and the received
signal from each antenna 1352 is provided to a respective receiver
(RCVR) 1354a through 1354r. Each receiver 1354 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.
[0099] An RX data processor 1360 can receive and process the
N.sub.R received symbol streams from N.sub.R receivers 1354 based
on a particular receiver processing technique to provide N.sub.T
"detected" symbol streams. RX data processor 1360 can demodulate,
deinterleave, and decode each detected symbol stream to recover the
traffic data for the data stream. The processing by RX data
processor 1360 is complementary to that performed by TX MIMO
processor 1320 and TX data processor 1314 at base station 1310.
[0100] A processor 1370 can periodically determine which precoding
matrix to utilize as discussed above. Further, processor 1370 can
formulate a reverse link message comprising a matrix index portion
and a rank value portion.
[0101] 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 1338, which also receives traffic data for a number of
data streams from a data source 1336, modulated by a modulator
1380, conditioned by transmitters 1354a through 1354r, and
transmitted back to base station 1310.
[0102] At base station 1310, the modulated signals from mobile
device 1350 are received by antennas 1324, conditioned by receivers
1322, demodulated by a demodulator 1340, and processed by a RX data
processor 1342 to extract the reverse link message transmitted by
mobile device 1350. Further, processor 1330 can process the
extracted message to determine which precoding matrix to use for
determining the beamforming weights.
[0103] Processors 1330 and 1370 can direct (e.g., control,
coordinate, manage, etc.) operation at base station 1310 and mobile
device 1350, respectively. Respective processors 1330 and 1370 can
be associated with memory 1332 and 1372 that store program codes
and data. Processors 1330 and 1370 can also perform computations to
derive frequency and impulse response estimates for the uplink and
downlink, respectively.
[0104] 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.
[0105] 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.
[0106] 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.
[0107] With reference to FIG. 14, illustrated is a system 1400 that
facilitates communicating relay protocol packets to/from upstream
relay or donor nodes. For example, system 1400 can reside at least
partially within a base station, mobile device, etc. It is to be
appreciated that system 1400 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 1400 includes a logical grouping 1402 of
electrical components that can act in conjunction. For instance,
logical grouping 1402 can include an electrical component for
generating a relay protocol packet 1404. For example, as described,
this can be in response to a communication from a UE, and the
payload of the packet can be the communication from the UE.
Additionally, logical grouping 1402 can include an electrical
component for inserting a relay identifier in a header of the relay
protocol packet 1406. Thus, for example, the header can be
subsequently used to identify the source system 1400 of the packet.
Moreover, logical grouping 1402 can include an electrical component
for communicating the relay protocol packet to one or more eNBs in
a wireless network 1408.
[0108] Electrical component 1408 can additionally receive a
disparate relay protocol packet, for example, in response or
related to the communicated packet. In this regard, logical
grouping 1402 can include an electrical component for determining a
type of an upper layer protocol corresponding to a payload of a
disparate relay protocol packet 1410. Moreover, logical grouping
1402 can include an electrical component for providing the payload
of the relay protocol packet to a UE based at least in part on the
type of the upper layer protocol 1412. For example, if the type is
S1-U, S1-MME, or a similar type, electrical component 1412 can
provide the upper layer protocol payload to the UE. Furthermore,
logical grouping 1402 includes an electrical component for
receiving the relay identifier from the donor eNB 1414. In
addition, logical grouping 1402 includes an electrical component
for requesting the relay identifier from the donor eNB 1416.
Additionally, system 1400 can include a memory 1418 that retains
instructions for executing functions associated with electrical
components 1404, 1406, 1408, 1410, 1412, 1414, and 1416. While
shown as being external to memory 1418, it is to be understood that
one or more of electrical components 1404, 1406, 1408, 1410, 1412,
1414, and 1416 can exist within memory 1418.
[0109] With reference to FIG. 15, illustrated is a system 1500 that
facilitates forwarding relay protocol packets based on a relay
identifier comprised within packet headers. For example, system
1500 can reside at least partially within a base station, mobile
device, etc. It is to be appreciated that system 1500 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 1500
includes a logical grouping 1502 of electrical components that can
act in conjunction. For instance, logical grouping 1502 can include
an electrical component for storing a relay identifier along with
an identifier of a next hop relay eNB 1504. For example, as
described, this can be performed upon receiving a relay identifier
assignment from an upstream node for a downstream node (e.g., the
downstream node can be the next hop node). Moreover, logical
grouping 1502 can include an electrical component for forwarding a
relay protocol packet to the next hop relay eNB based at least in
part on locating a relay identifier extracted from the relay
protocol packet in the electrical component for storing 1506. Thus,
the identifier for the next hop node can be determined and packet
forwarded thereto, as described. Additionally, system 1500 can
include a memory 1508 that retains instructions for executing
functions associated with electrical components 1504 and 1506.
While shown as being external to memory 1508, it is to be
understood that one or more of electrical components 1504 and 1506
can exist within memory 1508.
[0110] With reference to FIG. 16, illustrated is a system 1600 that
facilitates communicating relay protocol packets to/from downstream
relay nodes. For example, system 1600 can reside at least partially
within a base station, mobile device, etc. It is to be appreciated
that system 1600 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 1600 includes a logical grouping 1602 of electrical
components that can act in conjunction. For instance, logical
grouping 1602 can include an electrical component for receiving a
relay protocol packet comprising an upper layer protocol payload
and a relay identifier 1604. For example, as described, the packet
can be received from a downstream relay node for communicating to a
core network. Additionally, logical grouping 1602 can include an
electrical component for determining a type of the upper layer
protocol payload 1606. This can facilitate determining a recipient
of the payload, as described (e.g., S1-U payload can go to an SGW,
S1-MME to an MME, etc.). Moreover, logical grouping 1602 can
include an electrical component for communicating the upper layer
protocol payload along with the relay identifier to a core network
component over a disparate transport layer 1608.
[0111] Thus, for example, the payload can be transmitted over a
UDP/IP layer. In addition, logical grouping 1602 can include an
electrical component for generating a disparate relay protocol
packet including a communication as the payload 1610. In this
regard, for example, electrical component 1608 can also receive
communications from the core network component for transmitting to
one or more relay nodes, for which a relay protocol packet can be
generated (and the payload can be the communication from the core
network component, for example). Moreover, logical grouping 1602
can include an electrical component for determining a next hop
relay eNB to receive the disparate relay protocol packet 1612. As
described, this can include searching a routing table to locate the
next hop relay eNB identifier (e.g., C-RNTI) related to the relay
identifier. In addition, logical grouping 1602 can include an
electrical component for inserting the relay identifier in a header
of the disparate relay protocol packet 1614. This allows subsequent
downstream relay eNBs to forward the packet on to the relay eNB
related to the relay identifier. Additionally, system 1600 can
include a memory 1616 that retains instructions for executing
functions associated with electrical components 1604, 1606, 1608,
1610, 1612, and 1614. While shown as being external to memory 1616,
it is to be understood that one or more of electrical components
1604, 1606, 1608, 1610, 1612, and 1614 can exist within memory
1616.
[0112] 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.
[0113] 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.
[0114] 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.
[0115] 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.
* * * * *