U.S. patent application number 12/752968 was filed with the patent office on 2010-10-14 for split-cell relay packet routing.
This patent application is currently assigned to QUALCOMM Incorporated. Invention is credited to Parag Arun Agashe, Gavin Bernard Horn, Xiaolong Huang, Yongsheng Shi, Fatih Ulupinar.
Application Number | 20100260126 12/752968 |
Document ID | / |
Family ID | 42934323 |
Filed Date | 2010-10-14 |
United States Patent
Application |
20100260126 |
Kind Code |
A1 |
Ulupinar; Fatih ; et
al. |
October 14, 2010 |
SPLIT-CELL RELAY PACKET ROUTING
Abstract
Systems and methodologies are described that facilitate packet
routing among relay eNBs in a wireless network. Packet data
convergence protocol (PDCP) layer communications from a user
equipment (UE) can terminate at a donor evolved Node B (eNB) and
vice versa. In this regard, relay eNBs can forward PDCP layer
communications over a routing protocol without locally processing
the layer. The relay eNBs can, however, retrieve one or more
parameters from a header of the PDCP layer for feedback to the
donor eNB to assist in flow control, sequence number status
transfer, and/or the like. In addition, routing identifier can be
utilized to determine relay eNBs for receiving the packets. The
routing identifier can additionally include an identifier of a
radio bearer of the relay eNB communicating with the UE over which
the PDCP layer communications are to be transmitted.
Inventors: |
Ulupinar; Fatih; (San Diego,
CA) ; Shi; Yongsheng; (Falls Church, VA) ;
Horn; Gavin Bernard; (La Jolla, CA) ; Agashe; Parag
Arun; (San Diego, CA) ; Huang; Xiaolong; (San
Diego, CA) |
Correspondence
Address: |
QUALCOMM INCORPORATED
5775 MOREHOUSE DR.
SAN DIEGO
CA
92121
US
|
Assignee: |
QUALCOMM Incorporated
San Diego
CA
|
Family ID: |
42934323 |
Appl. No.: |
12/752968 |
Filed: |
April 1, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61168737 |
Apr 13, 2009 |
|
|
|
Current U.S.
Class: |
370/329 |
Current CPC
Class: |
H04W 92/20 20130101;
H04W 28/065 20130101; H04W 92/04 20130101; H01L 2924/00013
20130101; H04B 7/2606 20130101; H01L 2224/29099 20130101; H04W
76/12 20180201; H01L 2924/00013 20130101; H04W 40/36 20130101; H04W
84/047 20130101 |
Class at
Publication: |
370/329 |
International
Class: |
H04W 8/00 20090101
H04W008/00 |
Claims
1. A method, comprising: receiving a packet having a routing layer
that includes a payload with a packet data convergence protocol
(PDCP) layer from an upstream evolved Node B (eNB); determining a
user equipment (UE) to receive the payload based at least in part
on a routing identifier specified in the routing layer of the
packet; and transmitting the payload to the UE in a disparate
packet.
2. The method of claim 1, further comprising extracting one or more
parameters from a header of the PDCP layer.
3. The method of claim 2, further comprising transmitting the one
or more parameters extracted from the header of the PDCP layer to
the upstream eNB.
4. The method of claim 3, wherein the extracting the one or more
parameters from the header of the PDCP layer includes extracting a
sequence number related to the PDCP layer of the payload, and
transmitting the one or more parameters includes transmitting the
sequence number to the upstream eNB.
5. The method of claim 1, further comprising maintaining a buffer
that stores the packet received from the upstream eNB until the
transmitting the payload to the UE in the disparate packet.
6. The method of claim 5, further comprising providing one or more
parameters related to the buffer to the upstream eNB.
7. The method of claim 1, further comprising establishing a
connection with the upstream eNB and receiving an identifier for
communicating with the upstream eNB.
8. The method of claim 7, wherein the routing layer is a relay
routing protocol layer and the routing identifier includes the
identifier for communicating with the upstream eNB, an identifier
of the UE, and an identifier of a radio bearer over which to
transmit the payload to the UE in the disparate packet.
9. A wireless communications apparatus, comprising: at least one
processor configured to: obtain a packet with a routing layer that
comprises a packet data convergence protocol (PDCP) layer from an
upstream evolved Node B (eNB); detect a user equipment (UE) for
which the packet is intended based at least in part on a routing
identifier specified in the routing layer; and transmit a payload
of the PDCP layer to the UE in a disparate packet; and a memory
coupled to the at least one processor.
10. The wireless communications apparatus of claim 9, wherein the
at least one processor is further configured to retrieve one or
more parameters from a header of the PDCP layer.
11. The wireless communications apparatus of claim 10, wherein the
at least one processor is further configured to provide the one or
more parameters to the upstream eNB.
12. The wireless communications apparatus of claim 11, wherein the
one or more parameters includes a sequence number related to the
PDCP layer.
13. The wireless communications apparatus of claim 9, wherein the
at least one processor is further configured to maintain a buffer
that stores the packet until the at least one processor transmits
the payload of the PDCP layer to the UE.
14. The wireless communications apparatus of claim 13, wherein the
at least one processor is further configured to provide one or more
parameters related to the buffer to the upstream eNB.
15. The wireless communications apparatus of claim 9, wherein the
at least one processor is further configured to receive an
identifier for communicating with the upstream eNB upon
establishing a connection with the upstream eNB.
16. The wireless communications apparatus of claim 15, wherein the
routing identifier includes the identifier for communicating with
the upstream eNB, an identifier of the UE, and an identifier of a
radio bearer over which to transmit the payload of the PDCP layer
to the UE in the disparate packet.
17. An apparatus, comprising: means for receiving a packet having a
routing layer that includes a packet data convergence protocol
(PDCP) layer from an upstream evolved Node B (eNB); and means for
transmitting a payload of the PDCP layer in a disparate packet to a
user equipment (UE) related to the packet based at least in part on
a routing identifier specified in the routing layer of the
packet.
18. The apparatus of claim 17, further comprising means for
retrieving one or more parameters from a header of the PDCP
layer.
19. The apparatus of claim 18, further comprising means for
transmitting the one or more parameters to the upstream eNB.
20. The apparatus of claim 19, wherein the one or more parameters
includes a sequence number related to the PDCP layer.
21. The apparatus of claim 17, wherein the means for transmitting
the payload maintains a buffer that stores the packet at least
until the means for transmitting transmits the payload of the PDCP
layer in the disparate packet to the UE.
22. The apparatus of claim 21, further comprising means for
transmitting one or more parameters related to the buffer to the
upstream eNB.
23. The apparatus of claim 17, further comprising means for
receiving an identifier from the upstream eNB upon establishing a
connection with the upstream eNB.
24. The apparatus of claim 23, wherein the routing identifier
includes the identifier received from the upstream eNB, an
identifier of the UE, and an identifier of a radio bearer over
which the means for transmitting is to transmit the payload of the
PDCP layer in the disparate packet to the UE.
25. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
receive a packet having a routing layer that includes a payload
with a packet data convergence protocol (PDCP) layer from an
upstream evolved Node B (eNB); code for causing the at least one
computer to determine a user equipment (UE) to receive the payload
based at least in part on a routing identifier specified in the
routing layer of the packet; and code for causing the at least one
computer to transmit the payload to the UE in a disparate
packet.
26. The computer program product of claim 25, wherein the
computer-readable medium further comprises code for causing the at
least one computer to extract one or more parameters from a header
of the PDCP layer.
27. The computer program product of claim 26, wherein the
computer-readable medium further comprises code for causing the at
least one computer to transmit the one or more parameters extracted
from the header of the PDCP layer to the upstream eNB.
28. The computer program product of claim 27, wherein the one or
more parameters includes a sequence number related to the PDCP
layer of the payload.
29. The computer program product of claim 25, wherein the
computer-readable medium further comprises code for causing the at
least one computer to maintain a buffer that stores the packet
received from the upstream eNB, along with other packets received
from the upstream eNB, until the code for causing the at last one
computer to transmit transmits the payload to the UE in the
disparate packet.
30. The computer program product of claim 29, wherein the
computer-readable medium further comprises code for causing the at
least one computer to provide one or more parameters related to the
buffer to the upstream eNB.
31. The computer program product of claim 25, wherein the
computer-readable medium further comprises code for causing the at
least one computer to receive an identifier for communicating with
the upstream eNB upon establishing a connection with the upstream
eNB.
32. The computer program product of claim 31, wherein the routing
identifier includes the identifier for communicating with the
upstream eNB, an identifier of the UE, and an identifier of a radio
bearer over which the code for causing the at least one computer to
transmit transmits the payload to the UE in the disparate
packet.
33. An apparatus, comprising: a packet receiving component that
obtains a packet having a routing layer that includes a packet data
convergence protocol (PDCP) layer from an upstream evolved Node B
(eNB); and a packet routing component that transmits a payload of
the PDCP layer in a disparate packet to a user equipment (UE)
related to the packet based at least in part on a routing
identifier specified in the routing layer of the packet.
34. The apparatus of claim 33, further comprising a PDCP header
observing component that retrieves one or more parameters from a
header of the PDCP layer.
35. The apparatus of claim 34, further comprising a PDCP parameter
providing component that transmits the one or more parameters to
the upstream eNB.
36. The apparatus of claim 35, wherein the one or more parameters
includes a sequence number related to the PDCP layer.
37. The apparatus of claim 33, wherein the packet routing component
further maintains a buffer that stores the packet at least until
the packet routing component transmits the payload of the PDCP
layer in the disparate packet to the UE.
38. The apparatus of claim 37, further comprising a PDCP parameter
providing component that transmits one or more parameters related
to the buffer to the upstream eNB.
39. The apparatus of claim 33, further comprising an ID receiving
component that obtains an identifier from the upstream eNB upon
establishing a connection with the upstream eNB.
40. The apparatus of claim 39, wherein the routing identifier
includes the identifier received from the upstream eNB, an
identifier of the UE, and an identifier of a radio bearer over
which the packet routing component transmits the payload of the
PDCP layer in the disparate packet to the UE.
41. A method, comprising: maintaining a packet data convergence
protocol (PDCP) context related to a user equipment (UE); applying
an encryption or security procedure to at least a portion of a
packet received over a backhaul link for the UE according to the
PDCP context related to the UE; and transmitting at least the
portion of the packet in a PDCP layer of a disparate packet to a
downstream relay evolved Node B (eNB) in a communications path to
the UE.
42. The method of claim 41, further comprising receiving one or
more parameters related to PDCP layer communications at the UE from
the downstream relay eNB.
43. The method of claim 42, wherein the receiving the one or more
parameters includes receiving a PDCP layer sequence number of the
packet from the downstream relay eNB.
44. The method of claim 43, further comprising transmitting one or
more PDCP packets in a buffer of the PDCP context related to the UE
to the downstream relay eNB based at least in part on the PDCP
layer sequence number.
45. The method of claim 42, wherein the receiving the one or more
parameters includes receiving an index of a last downlink PDCP
packet data unit (PDU) sent to the UE by the downstream relay eNB,
an index of a last downlink PDCP PDU received at the downstream
relay eNB, or a maximum size of a PDCP layer buffer at the
downstream relay eNB.
46. The method of claim 41, further comprising generating a routing
identifier for the disparate packet based at least in part on an
identifier in the portion of the packet received over the backhaul
link.
47. The method of claim 46, further comprising determining the
downstream relay eNB based at least in part on a portion of the
routing identifier.
48. The method of claim 47, wherein the determining the downstream
relay eNB includes locating an identifier of the downstream relay
eNB in a routing table based at least in part on the portion of the
routing identifier.
49. The method of claim 46, further comprising generating the
disparate packet to include a relay routing protocol layer that
comprises the PDCP layer and the routing identifier.
50. The method of claim 49, further comprising: determining a radio
bearer of the downstream relay eNB for transmitting the PDCP layer
of the packet to the UE based at least in part on a bearer mapping
table that associates evolved packet system (EPS) bearers with
radio bearers of one or more downstream relay eNBs; and specifying
an identifier of the radio bearer as a portion of the routing
identifier.
51. A wireless communications apparatus, comprising: at least one
processor configured to: negotiate one or more parameters for
communicating with a user equipment (UE); apply the one or more
parameters to at least a portion of a packet for the UE received
over a backhaul link; and transmit at least the portion of the
packet in a packet data convergence protocol (PDCP) layer of a
disparate packet to a downstream relay evolved Node B (eNB) in a
communications path to the UE; and a memory coupled to the at least
one processor.
52. The wireless communications apparatus of claim 51, wherein the
at least one processor is further configured to receive one or more
PDCP layer communication parameters related to PDCP layer
communications at the UE from the downstream relay eNB.
53. The wireless communications apparatus of claim 52, wherein the
one or more PDCP layer communication parameters includes a PDCP
layer sequence number of the packet from the downstream relay
eNB.
54. The wireless communications apparatus of claim 53, wherein the
at least one processor is further configured to transmit one or
more PDCP packets having a PDCP layer from a buffer related to the
UE to the downstream relay eNB based at least in part on the PDCP
layer sequence number.
55. The wireless communications apparatus of claim 52, wherein the
one or more PDCP layer communication parameters includes an index
of a last downlink PDCP packet data unit (PDU) sent to the UE by
the downstream relay eNB, an index of a last downlink PDCP PDU
received at the downstream relay eNB, or a maximum size of a PDCP
layer buffer at the downstream relay eNB.
56. The wireless communications apparatus of claim 51, wherein the
at least one processor is further configured to generate a routing
identifier for a routing layer of the disparate packet based at
least in part on an identifier specified in at least the portion of
the packet received over the backhaul link.
57. The wireless communications apparatus of claim 56, wherein the
at least one processor is further configured to select the
downstream relay eNB for transmitting the disparate packet to based
at least in part on a portion of the routing identifier.
58. The wireless communications apparatus of claim 57, wherein the
at least one processor selects the downstream relay eNB based at
least in part on locating an identifier of the downstream relay eNB
associated with the portion of the routing identifier in a routing
table.
59. The wireless communications apparatus of claim 56, wherein the
at least one processor is further configured to create the
disparate packet including a relay routing protocol layer that
comprises the portion of the packet in the PDCP layer and the
routing identifier.
60. The wireless communications apparatus of claim 59, wherein the
at least one processor is further configured to: maintain a bearer
mapping table that associates radio bearer identifiers of
downstream relay eNBs to evolved packet system (EPS) bearers;
locate an identifier of a radio bearer of the downstream relay eNB
in the bearer mapping table that is associated to an EPS bearer
specified in at least the portion of the packet; and specify the
identifier of the radio bearer of the downstream relay eNB in the
routing identifier.
61. An apparatus, comprising: means for maintaining a packet data
convergence protocol (PDCP) context related to a user equipment
(UE); means for applying an encryption or security procedure to at
least a portion of a packet received over a backhaul link for the
UE according to the PDCP context related to the UE; and means for
transmitting at least the portion of the packet in a PDCP layer of
a disparate packet to a downstream relay evolved Node B (eNB) in a
communications path to the UE.
62. The apparatus of claim 61, further comprising means for
receiving one or more parameters related to PDCP layer
communications at the UE from the downstream relay eNB.
63. The apparatus of claim 62, wherein the one or more parameters
includes a PDCP layer sequence number of the packet.
64. The apparatus of claim 63, wherein the means for transmitting
the packet further transmits one or more other packets from a
buffer related to the PDCP context based at least in part on the
PDCP layer sequence number.
65. The apparatus of claim 62, wherein the one or more parameters
includes an index of a last downlink PDCP packet data unit (PDU)
sent to the UE by the downstream relay eNB, an index of a last
downlink PDCP PDU received at the downstream relay eNB, or a
maximum size of a PDCP layer buffer at the downstream relay
eNB.
66. The apparatus of claim 61, further comprising means for
generating a routing identifier for the disparate packet based at
least in part on an identifier in at least the portion of the
packet received over the backhaul link.
67. The apparatus of claim 66, wherein the means for transmitting
the packet in the PDCP layer of the disparate packet selects the
downstream relay eNB based at least in part on a portion of the
routing identifier.
68. The apparatus of claim 67, wherein the means for transmitting
the packet in the PDCP layer of the disparate packet selects the
downstream relay eNB based further at least in part on locating an
identifier of the downstream relay eNB in a routing table based at
least in part on the portion of the routing identifier.
69. The apparatus of claim 66, wherein the means for generating the
routing identifier further creates the disparate packet to include
a relay routing protocol layer that comprises the PDCP layer and
the routing identifier.
70. The apparatus of claim 69, further comprising means for
locating an identifier of a radio bearer of the downstream relay
eNB that is associated to an evolved packet system (EPS) bearer
specified in at least the portion of the packet in a bearer mapping
table that maps radio bearer identifiers of downstream relay eNBs
to EPS bearers, wherein the means for generating the routing
identifier specifies the identifier of the radio bearer in a
portion of the routing identifier.
71. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
maintain a packet data convergence protocol (PDCP) context related
to a user equipment (UE); code for causing the at least one
computer to apply an encryption or security procedure to at least a
portion of a packet received over a backhaul link for the UE
according to the PDCP context related to the UE; and code for
causing the at least one computer to transmit at least the portion
of the packet in a PDCP layer of a disparate packet to a downstream
relay evolved Node B (eNB) in a communications path to the UE.
72. The computer program product of claim 71, wherein the
computer-readable medium further comprises code for causing the at
least one computer to receive one or more parameters related to
PDCP layer communications at the UE from the downstream relay
eNB.
73. The computer program product of claim 72, wherein the one or
more parameters includes a PDCP layer sequence number of the
packet.
74. The computer program product of claim 73, wherein the
computer-readable medium further comprises code for causing the at
least one computer to transmit one or more PDCP packets in a buffer
of the PDCP context related to the UE to the downstream relay eNB
based at least in part on the PDCP layer sequence number.
75. The computer program product of claim 72, wherein the one or
more parameters includes an index of a last downlink PDCP packet
data unit (PDU) sent to the UE by the downstream relay eNB, an
index of a last downlink PDCP PDU received at the downstream relay
eNB, or a maximum size of a PDCP layer buffer at the downstream
relay eNB.
76. The computer program product of claim 71, wherein the
computer-readable medium further comprises code for causing the at
least one computer to generate a routing identifier for the
disparate packet based at least in part on an identifier in the
portion of the packet received over the backhaul link.
77. The computer program product of claim 76, wherein the
computer-readable medium further comprises code for causing the at
least one computer to determine the downstream relay eNB based at
least in part on a portion of the routing identifier.
78. The computer program product of claim 77, wherein the code for
causing the at least one computer to determine the downstream relay
eNB locates an identifier of the downstream relay eNB in a routing
table based at least in part on the portion of the routing
identifier.
79. The computer program product of claim 76, wherein the
computer-readable medium further comprises code for causing the at
least one computer to generate the disparate packet to include a
relay routing protocol layer that comprises the PDCP layer and the
routing identifier.
80. The computer program product of claim 79, wherein the
computer-readable medium further comprises: code for causing the at
least one computer to determine a radio bearer of the downstream
relay eNB for transmitting the PDCP layer of the packet to the UE
based at least in part on a bearer mapping table that associates
evolved packet system bearers with radio bearers of one or more
downstream relay eNBs; and code for causing the at least one
computer to specify an identifier of the radio bearer as a portion
of the routing identifier.
81. An apparatus, comprising: a packet data convergence protocol
(PDCP) context maintaining component that creates and stores a PDCP
context related to a user equipment (UE); a PDCP applying component
that that associates an encryption or security procedure to at
least a portion of a packet received over a backhaul link for the
UE according to the PDCP context related to the UE; and a packet
routing component that transmits at least the portion of the packet
in a PDCP layer of a disparate packet to a downstream relay evolved
Node B (eNB) in a communications path to the UE.
82. The apparatus of claim 81, further comprising a PDCP parameter
receiving component that obtains one or more parameters related to
PDCP layer communications at the UE from the downstream relay
eNB.
83. The apparatus of claim 82, wherein the one or more parameters
includes a PDCP layer sequence number of the packet.
84. The apparatus of claim 83, wherein the packet routing component
further transmits one or more other packets from a buffer related
to the PDCP context based at least in part on the PDCP layer
sequence number.
85. The apparatus of claim 82, wherein the one or more parameters
includes an index of a last downlink PDCP packet data unit (PDU)
sent to the UE by the downstream relay eNB, an index of a last
downlink PDCP PDU received at the downstream relay eNB, or a
maximum size of a PDCP layer buffer at the downstream relay
eNB.
86. The apparatus of claim 81, further comprising a relay routing
protocol (RRP) packet generating component that specifies a routing
identifier for the disparate packet based at least in part on an
identifier in at least the portion of the packet received over the
backhaul link.
87. The apparatus of claim 86, wherein the packet routing component
selects the downstream relay eNB based at least in part on a
portion of the routing identifier.
88. The apparatus of claim 87, wherein the packet routing component
selects the downstream relay eNB based further at least in part on
locating an identifier of the downstream relay eNB in a routing
table based at least in part on the portion of the routing
identifier.
89. The apparatus of claim 86, wherein the RRP packet generating
component further creates the disparate packet to include an RRP
layer that comprises the PDCP layer and the routing identifier.
90. The apparatus of claim 89, further comprising a bearer mapping
component that locates an identifier of a radio bearer of the
downstream relay eNB that is associated to an evolved packet system
(EPS) bearer specified in at least the portion of the packet in a
bearer mapping table that maps radio bearer identifiers of
downstream relay eNBs to EPS bearers, wherein the RRP packet
generating component specifies the identifier of the radio bearer
in a portion of the routing identifier.
Description
CLAIM OF PRIORITY UNDER 35 U.S.C. .sctn.119
[0001] The present Application for patent claims priority to
Provisional Application No. 61/168,737 entitled "SPLIT-CELL BASED
RELAY FOR LTE" filed Apr. 13, 2009, 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 routing data packets among
multiple access points.
[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 with the backend network
components, 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 routing packets between a donor eNB and one or
more cell relay eNBs. In particular, a packet data convergence
protocol (PDCP) layer of packets related to the cell relay eNB or a
user equipment (UE) communicating with the cell relay eNB can be
terminated at the donor eNB. In this regard, the donor eNB can
handle security, encryption/decryption, etc. of communications with
the cell relay eNB or the related UE, rather than handling such at
each intermediary cell relay eNB, through which communications of
the cell relay eNB or related UE are forwarded. Performing
security, encryption/decryption, and similar procedures at the
donor eNB increases efficiency of cell relay eNB and UE
communications through the intermediary cell relay eNBs.
[0010] According to related aspects, a method is provided that
includes receiving a packet having a routing layer that includes a
payload with a PDCP layer from an upstream eNB and determining a UE
to receive the payload based at least in part on a routing
identifier specified in the routing layer of the packet. The method
also includes transmitting the payload to the UE in a disparate
packet.
[0011] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to obtain a packet with a routing
layer that comprises a PDCP layer from an upstream eNB and detect a
UE for which the packet is intended based at least in part on a
routing identifier specified in the routing layer. The at least one
processor is further configured to transmit a payload of the PDCP
layer to the UE in a disparate packet. 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 receiving a packet having a routing layer that
includes a PDCP layer from an upstream eNB and means for
transmitting a payload of the PDCP layer in a disparate packet to a
UE related to the packet based at least in part on a routing
identifier specified in the routing layer of the packet.
[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 receive a packet having a routing
layer that includes a payload with a PDCP layer from an upstream
eNB. The computer-readable medium can also comprise code for
causing the at least one computer to determine a UE to receive the
payload based at least in part on a routing identifier specified in
the routing layer of the packet and code for causing the at least
one computer to transmit the payload to the UE in a disparate
packet.
[0014] Moreover, an additional aspect relates to an apparatus
including a packet receiving component that obtains a packet having
a routing layer that includes a PDCP layer from an upstream eNB.
The apparatus can further include a packet routing component that
transmits a payload of the PDCP layer in a disparate packet to a UE
related to the packet based at least in part on a routing
identifier specified in the routing layer of the packet.
[0015] According to another aspect, a method is provided that
includes maintaining a PDCP context related to a UE and applying an
encryption or security procedure to at least a portion of a packet
received over a backhaul link for the UE according to the PDCP
context related to the UE. The method further includes transmitting
at least the portion of the packet in a PDCP layer of a disparate
packet to a downstream relay eNB in a communications path to the
UE.
[0016] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to negotiate one or more parameters
for communicating with a UE and to apply the one or more parameters
to at least a portion of a packet for the UE received over a
backhaul link. The at least one processor is further configured to
transmit at least the portion of the packet in a PDCP layer of a
disparate packet to a downstream relay eNB in a communications path
to the UE. 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 maintaining a PDCP context related to a UE and
means for applying an encryption or security procedure to at least
a portion of a packet received over a backhaul link for the UE
according to the PDCP context related to the UE. The apparatus also
includes means for transmitting at least the portion of the packet
in a PDCP layer of a disparate packet to a downstream relay eNB in
a communications path to the UE.
[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 maintain a PDCP context related to
a UE and code for causing the at least one computer to apply an
encryption or security procedure to at least a portion of a packet
received over a backhaul link for the UE according to the PDCP
context related to the UE. The computer-readable medium can also
comprise code for causing the at least one computer to transmit at
least the portion of the packet in a PDCP layer of a disparate
packet to a downstream relay eNB in a communications path to the
UE.
[0019] Moreover, an additional aspect relates to an apparatus
including a PDCP context maintaining component that creates and
stores a PDCP context related to a UE and a PDCP applying component
that that associates an encryption or security procedure to at
least a portion of a packet received over a backhaul link for the
UE according to the PDCP context related to the UE. The apparatus
can further include a packet routing component that transmits at
least the portion of the packet in a PDCP layer of a disparate
packet to a downstream relay eNB in a communications path to the
UE.
[0020] 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
[0021] FIG. 1 is an illustration of an example wireless
communications system that facilitates providing relays for
wireless networks.
[0022] FIG. 2 is an illustration of an example communications
apparatus for employment within a wireless communications
environment.
[0023] FIG. 3 is an illustration of an example wireless
communications system that facilitates tunneling packet data
convergence protocol (PDCP) layer communications through one or
more relay eNBs.
[0024] FIG. 4 is an illustration of an example wireless
communications system that facilitates generating routing
identifiers for forwarding wireless communications.
[0025] FIG. 5 is an illustration of an example wireless
communications system that utilizes cell relays to provide access
to a wireless network.
[0026] FIG. 6 is an illustration of example protocol stacks that
facilitate providing split-cell relay functionality for device
communications.
[0027] FIG. 7 is an illustration of example protocol stacks that
facilitate providing multiple PDCP contexts for routing
communications in a wireless network.
[0028] FIG. 8 is an illustration of an example methodology for
routing packets to user equipment (UE) without processing a PDCP
layer.
[0029] FIG. 9 is an illustration of an example methodology that
observes one or more PDCP header parameters of packets to be or
that have been routed.
[0030] FIG. 10 is an illustration of an example methodology that
communicates to UEs over a PDCP layer through one or more relay
eNBs.
[0031] FIG. 11 is an illustration of an example methodology that
controls flow of PDCP layer packets based on one or more parameters
received from a relay eNB.
[0032] FIG. 12 is an illustration of an example methodology that
specifies a radio bearer in a routing identifier for transmitting
packets to a UE.
[0033] FIG. 13 is an illustration of a wireless communication
system in accordance with various aspects set forth herein.
[0034] FIG. 14 is an illustration of an example wireless network
environment that can be employed in conjunction with the various
systems and methods described herein.
[0035] FIG. 15 is an illustration of an example system that
facilitates routing packets from a donor eNB to a UE without
processing a PDCP layer of the packets.
[0036] FIG. 16 is an illustration of an example system that
facilitates providing packets to a relay eNB for forwarding to a
UE.
DETAILED DESCRIPTION
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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 conventional LTE configurations. In this
regard, donor eNB 102 can act as a conventional LTE eNB requiring
no changes at the link layer or related interface (e.g.,
user-to-user (Uu), such as E-UTRA-Uu) to support the relay eNB 104.
In addition, relay eNB 104 can appear to UE 110 as a conventional
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. It is to be appreciated that relay eNB 104 can connect to
additional donor eNBs, in one example.
[0046] 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.
[0047] Relay eNB 104 can determine a relay eNB or UE (e.g., relay
eNB 108 or UE 110) 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.
[0048] In an example, a packet data convergence protocol (PDCP)
layer for relay eNB 108 (or related devices communicating
therewith) and/or UE 110 can also be terminated at the donor eNB
102. In this example, for packets or other data received from relay
eNB 108, UE 110, or other relay eNBs or UEs communicating with
relay eNB 104, relay eNB 104 can forward the packets or other data
to donor eNB 102 (and vice versa) without determining the PDCP
payload. In this regard, security and encryption considerations can
be handled at the donor eNB 102 and a node from which the packet or
other data originated, which can be relay eNB 108, UE 110, etc.
Thus, relay eNB 104 and/or other intermediary relay eNBs need not
decrypt and re-encrypt communications (or apply other security
procedures) upon receiving and forwarding the packets or other
data.
[0049] For example, upon receiving packets from a relay eNB 108 or
UE 110, relay eNB 104 can forward the packets to donor eNB 102,
without analyzing the PDCP layer payload, based at least in part on
an identifier or address specified in a radio link control (RLC) or
similar layer. Similarly, relay eNB 104 can forward packets from
donor eNB 102 to relay eNB 108 or UE 110 without processing the
PDCP layer. In an example, relay eNB 104 can analyze a PDCP header
of the packets to determine one or more parameters for
communicating to donor eNB 102. For instance, to assist in flow
control, sequence number (SN) status transfer, etc., relay eNB 104
can acquire one or more parameters from a header of a PDCP layer of
a packet from donor eNB 102 to relay UE 110 (e.g., such as an SN or
similar parameters), and specify the one or more parameters to
donor eNB 102. In addition, for example, relay eNB 104 can send
PDCP layer feedback information to donor eNB 102 related to
communicating packets from donor eNB 102 to relay eNB 108 or UE
110.
[0050] In addition, donor eNB 102 can store PDCP layer contexts for
each UE (e.g., UE 110), relay eNB (e.g., relay eNB 104), or other
device with which donor eNB 102 ultimately communicates (e.g., via
intermediary relay eNBs). In this regard, donor eNB 102 can store
and/or analyze the PDCP layer feedback according to a related
context for relay eNB 108 or UE 110 for subsequent use in
communicating with the relay eNB 108 or UE 110. Moreover, donor eNB
102, in an example, can multiplex PDCP layer communications over a
single Un or other radio protocol interface with relay eNB 104 to
provide PDCP instances to communicate with the related devices. It
is to be appreciated, however, that donor eNB 102 can maintain less
than one context per PDCP layer communication, and in one example,
can have one PDCP context to handle substantially all PDCP layer
communications therewith.
[0051] Turning to FIG. 2, illustrated is a communications apparatus
200 for employment within a wireless communications environment.
The communications apparatus 200 can be a base station or a portion
thereof, a mobile device or a portion thereof, or substantially any
communications apparatus that receives data transmitted in a
wireless communications environment. The communications apparatus
200 can include a PDCP communication receiving component 202 that
obtains one or more packets having a PDCP layer, a PDCP header
observing component 204 that retrieves one or more parameters of a
PDCP header in the one or more packets, a PDCP parameter providing
component 206 that communicates the one or more parameters to a
disparate device (not shown), and a PDCP forwarding component 208
that transmits the packet having the PDCP layer to the disparate
device.
[0052] According to an example, PDCP communication receiving
component 202 can obtain a packet from a device (not shown), which
can include a PDCP layer among other layers. For example, the
packet can have layers that comprise the PDCP layer, such as a
layer 1 (L1), MAC layer, RLC layer, etc., and/or layers within the
PDCP layer, such as internet protocol (IP) layer, or substantially
any application or higher layer that supports control or user plane
message exchange between the communications apparatus 200 and
another device. PDCP header observing component 204 can obtain one
or more parameters from a PDCP header of the packet. For example,
the one or more parameters can be one or more PDCP layer
communication parameters, which can relate to SNs or similar
parameters in the PDCP header. PDCP parameter providing component
206 can subsequently transmit the one or more parameters to the
disparate device to facilitate flow control, SN status transfer,
etc. PDCP forwarding component 208 can provide the packet to the
disparate device. In this regard, communications apparatus 200 can
relay packets (e.g., one or more PDCP packets) from the device to
the disparate device without disrupting the PDCP layer, decrypting
the PDCP layer, and/or the like, which can improve efficiency in
packet routing.
[0053] Turning now to FIG. 3, an example wireless communication
system 300 that facilitates routing packets in a wireless network
without disrupting a PDCP layer is illustrated. System 300 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 and UE 110 with access to
the core network 106 through the donor eNB 102. Moreover, for
example, there can be multiple relay eNBs 104 between the donor eNB
102 and relay eNB 108 or UE 110. 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.
[0054] Donor eNB 102 comprises a packet receiving component 302
that obtains a packet from a relay eNB or UE, a PDCP context
generating component 304 that can create a local context for the
relay eNB or UE to facilitate subsequent PDCP layer communicating,
a PDCP context maintaining component 306 that can store or
otherwise manage one or more created PDCP contexts, a packet
translating component 308 that processes the packet (e.g., the PDCP
layer payload) according to a related PDCP context, which can
include decrypting the packet, applying security to the packet,
and/or the like, to determine an application layer or other portion
of the packet in the PDCP layer payload for forwarding to an
upstream network component, a backhaul link component 310 that can
communicate the packet to a core network 106 and/or receive a
corresponding packet in response, a PDCP context applying component
312 that can associate the corresponding packet or another packet
received over backhaul link component 310 to a PDCP context based
on a determined destination node (e.g., relay eNB or UE) of the
packet, a packet routing component 314 that can provide the
corresponding packet to an intermediary relay eNB or other entity
in a communications path to the destination node, and a PDCP
parameter receiving component 316 that obtains one or more PDCP
parameters in a header of the packet received from the relay eNB or
UE.
[0055] Relay eNB 104 can include a packet receiving component 318
that obtains a packet from one or more disparate relay eNBs or UEs
over an uplink connection and/or obtains a packet from a donor eNB
over a downlink connection, a PDCP header observing component 204
that determines one or more parameters in a PDCP header of one or
more of the packets, a PDCP parameter providing component 206 that
transmits the one or more parameters in the PDCP header(s) to a
donor eNB, a packet routing component 320 that provides a packet
received over the uplink connection to a donor eNB or one or more
relay eNBs in a communications path to the donor eNB and provides a
packet received over the downlink connection to one or more
destination nodes (e.g., a relay eNB or UE) or one or more
intermediary relay eNBs in a communications path to the destination
node, a PDCP feedback receiving component 322 that obtains
communications metrics from the destination node (e.g., through one
or more intermediary relay eNBs) regarding communications over the
PDCP layer, and a PDCP feedback relaying component 324 that
provides the communications metrics to the donor eNB.
[0056] According to an example, UE 110 can establish a connection
with relay eNB 104 to communicate with core network 106 via donor
eNB 102 (and/or one or more intermediary relay eNBs, in one
example). UE 110 can subsequently transmit a packet to the relay
eNB 104 for providing to donor eNB 102. The packet can comprise
multiple layers to facilitate communication and routing in the
wireless network. For example, the packet can include a PDCP layer
(e.g., between an application layer and a radio transport layer).
The packet can also include a layer for routing the packet among
multiple relay eNBs, in one example. Packet receiving component 318
can obtain the packet from UE 110.
[0057] Packet routing component 320 can provide the packet from UE
110 to donor eNB 102. Packet receiving component 302 can obtain the
packet, and PDCP context maintaining component 306 selects a
related PDCP context for the packet. If no PDCP context yet exists
for UE 110, PDCP context generating component 304 can create a PDCP
context. As part of creating the PDCP context for UE 110, PDCP
context generating component 304 can negotiate an
encryption/decryption key or other security parameters with the UE
110. This can include communicating such information to the UE 110
(e.g., via relay eNB 104) as part of an acknowledgement of
receiving the packet, receiving such information from UE 110 (e.g.,
via relay eNB 104) in the packet or upon subsequent request, and/or
the like. Moreover, it is to be appreciated that establishing the
PDCP context for UE 110 can additionally or alternatively be part
of a separate procedure (e.g., during connection establishment,
and/or the like).
[0058] The PDCP context maintaining component 306 can select the
related PDCP context for the packet based on an identifier in the
packet, such as an identifier in one or more layers of the packet
(e.g., a relay routing protocol (RRP) layer, as described, an IP
layer, etc.) that corresponds to the related PDCP context. Packet
translating component 308 can process the packet from the UE 110
according to the related PDCP context and/or one or more parameters
thereof. As described, this can include decrypting the packet
according to a key at the PDCP layer previously negotiated between
donor eNB 102 and UE 110, or similar procedures to determine a
payload of the packet at the PDCP layer. Thus, the PDCP layer is
terminated at donor eNB 102. Backhaul link component 310 can create
a disparate packet for transmitting the payload to core network
106, such as a general packet radio service (GPRS) tunneling
protocol (GTP) packet, including the payload in the packet.
Backhaul link component 310 can transmit the disparate packet to
the core network 106. In one example, backhaul link component 310
can include an identifier of the UE 110 or the related PDCP context
in the disparate packet to facilitate associating response packets
with the UE 110 or the related PDCP context.
[0059] According to an example, core network 106 can transmit a
responding packet (or another packet) intended for UE 110, to donor
eNB 102, which can be received at backhaul link component 310. PDCP
context maintaining component 306 can determine a stored PDCP
context for the responding packet, which can be based on an
identifier of the context, an identifier of UE 110, etc., in the
responding packet. Packet translating component 308 can generate a
packet for transmitting to downstream nodes, which can include
multiple layers, such as an RLC layer for radio transmissions. PDCP
context applying component 312 can create a PDCP layer for the
packet and include an application layer or higher layer portion of
the responding packet as the PDCP payload (e.g., an IP layer of the
responding packet). In addition, PDCP context applying component
312 can include one or more parameters from the determined PDCP
context in the PDCP layer of the generated packet, such as security
parameters, and/or can modify the packet at the PDCP layer based on
the determined PDCP context (e.g., encrypt the PDCP payload).
[0060] In one example, PDCP context maintaining component 306 can
store the generated packet in a buffer related to the UE 110 to
facilitate flow control. For example, PDCP context maintaining
component 306 establishes and/or maintains the PDCP buffer for the
UE 110, and the PDCP buffer can include packets received from core
network 106 until the packets are transmitted by packet routing
component 314 to relay eNB 104. Packet routing component 314 can
transmit the generated packet (e.g., from the buffer) to relay eNB
104 for forwarding to UE 110. It is to be appreciated that packet
routing component 314 can have previously associated relay eNB 104
with UE 110 (e.g., by using a routing table or similar function
that maps a received or generated identifier of the UE 110 or a
related bearer of the UE 110 to an identifier of relay eNB 104, as
described herein). In one example, packet routing component 314 can
transmit packets from the PDCP buffer according to a timer, one or
more received parameters, as described below, and/or the like.
[0061] In this example, packet receiving component 318 can obtain
the generated packet, and packet routing component 320 can provide
the packet to UE 110. Similarly, as described, packet routing
component 320 can route packets based on an identifier established
with the UE 110, based on a maintained routing table or similar
function that maps such an identifier, and/or the like. The
identifier can have been previously established between UE 110 and
relay eNB 104, donor eNB 102, etc., as described herein, and can
have been provided to each node in the communications path between
UE 110 and donor eNB 102. It is to be appreciated, in one example,
that there can be other intermediary relay eNBs between relay eNB
104 and UE 110, in which case packet routing component 320 can
forward the packet to the next intermediary relay eNB based on the
routing table, the established identifier, etc. In this regard, the
routing table or similar function that can be part of packet
routing component 320 can map the identifier in the packet received
from donor eNB 102 to the next node in the communications path to
the destination node.
[0062] In addition, for example, PDCP header observing component
204 can obtain one or more parameters from a PDCP header of the
PDCP layer of the packet received from donor eNB 102, such as a SN
or a similar parameter, and PDCP parameter providing component 206
can transmit the one or more parameters to donor eNB 102. This can
be subsequent to receiving the packet at packet receiving component
318 and/or forwarding the packet by packet routing component 320,
as described. In this example, PDCP parameter receiving component
316 can obtain the one or more parameters from the PDCP header and
can provide the one or more parameters to PDCP context maintaining
component 306, packet receiving component 302, and/or the like to
assist flow control, SN status transfer message transmission, etc.
at donor eNB 102.
[0063] In this regard, for example, PDCP context maintaining
component 306 can utilize a SN parameter received by PDCP parameter
receiving component 316 to control the flow of packets to relay eNB
104. For example, if a difference between the received SN and an SN
of a packet in the PDCP buffer for UE 110 is over a threshold
level, packet routing component 314 can slow the flow of packets to
relay eNB 104 (e.g., according to a parameter of the PDCP context
modified by the PDCP context maintaining component 306, etc.).
Similarly, if the difference is less than a threshold, packet
routing component 314 can obtain one or more packets from the
buffer in the PDCP context maintaining component 306 (e.g., or
empty the buffer in one example) for transmitting to relay eNB 104.
In this regard, the donor eNB 102 controls the flow of packets to
relay eNB 104 based on communications parameters between the relay
eNB 104 and UE 110.
[0064] In addition, at the request of donor eNB 102 or otherwise,
relay eNB 104 can transmit feedback received from UE 110 (via one
or more intermediary relay eNBs where present, which can have
similar components to receive and relay feedback parameters)
regarding the PDCP layer to donor eNB 102. In this example, PDCP
feedback receiving component 322 can receive one or more feedback
parameters from UE 110, and PDCP feedback relaying component 324
can provide the one or more feedback parameters to donor eNB 102,
such as a last PDCP packet data unit (PDU) sent to UE 110, a last
PDCP PDU received from donor eNB 102, and/or the like. PDCP
parameter receiving component 316 can obtain the one or more
feedback parameters and provide the parameters to PDCP context
maintaining component 306, which can modify a related PDCP context
based on the one or more feedback parameters (e.g., empty the queue
related to the PDCP context based on the last PDCP PDU received by
UE 110). Where intermediary relay eNBs exist between relay eNB 104
and donor eNB 102, the intermediary relay eNBs can also comprise a
PDCP feedback receiving component 322 that obtains PDCP feedback
parameters form relay eNB 104 and a PDCP feedback relaying
component 324 that forwards the PDCP feedback parameters to donor
eNB 102 or one or more additional intermediary relay eNBs.
[0065] For instance, relay eNB 104 can handover UE 110
communications to another relay eNB (not shown), which can be in
the cluster of donor eNB 102. In this example, PDCP feedback
relaying component 324 can provide one or more parameters to assist
in handover to donor eNB 102, which can be received at PDCP
parameter receiving component 316. For example, PDCP feedback
receiving component 322 can obtain SN information related to
communicating with UE 110, such as the last PDCP PDU sent to UE
110, a last PDCP PDU received from donor eNB 102, and/or the like.
In this example, PDCP feedback relaying component 324 can transmit
the SN information to donor eNB 102 upon providing a handover
command to UE 110. Where intermediary relay eNBs exist between
relay eNB 104 and donor eNB 102, the intermediary relay eNBs can
similarly include a PDCP feedback receiving component 322 and PDCP
feedback relaying component 324, as described, that act in
conjunction to forward the SN information up to donor eNB 102. PDCP
parameter receiving component 316 can obtain the SN information and
utilize such to facilitate handover. For example, based on the last
PDCP PDU sent to UE 110, packet routing component 314 can forward
packets to a new relay eNB serving UE 110 starting at the next SN
from the last PDCP PDU received by UE 110.
[0066] In another example, PDCP parameter providing component 206
can retrieve one or more local PDCP parameters for providing to
donor eNB 102 or an immediate upstream relay eNB where one or more
intermediary relay eNBs exist between relay eNB 104 and donor eNB
102. In one example, upon request or otherwise, PDCP parameter
providing component 206 can determine and transmit a sequence
number of a last downlink PDCP PDU sent to UE 110, a sequence
number of the last downlink PDCP PDU received from donor eNB 102 or
the immediate upstream relay eNB where present, a maximum size of a
PDCP layer buffer that stores packets for transmitting to UE 110,
and/or the like, to donor eNB 102 or the immediate upstream relay
eNB where present. PDCP parameter receiving component 316 can
obtain the parameters, and packet routing component 314 can utilize
the parameters in transmitting or controlling flow of packets to
relay eNB 104, as described. For example, the packet routing
component 314 of donor eNB 102 (or a similar component of an
immediate upstream relay eNB where present) can determine whether
to modify a rate of transmitting packets to relay eNB 104 based on
a difference between the last downlink PDCP PDU sent to UE 110 and
the sequence number of the last PDCP PDU received from donor eNB
102. Similarly, packet routing component 314 can determine whether
to modify the rate of transmitting packets to relay eNB 104 based
on the maximum buffer size (e.g., where the difference is within a
threshold of the maximum buffer size). In another example, PDCP
parameter providing component 206 can determine a utilization of
the buffer and transmit that to the immediate upstream eNB, which
can indicate whether to slow or speed flow of packets.
Additionally, in this regard, PDCP parameter providing component
206 can determine whether the immediate upstream eNB should slow or
speed packet delivery and can issue an appropriate command
thereto.
[0067] Further, in an example, relay eNB 104 can provide the
foregoing functionality to a plurality of UEs or other devices. In
this regard, for example, a PDCP header observing component 204, a
PDCP parameter providing component 206, and/or a packet routing
component 320 can be provided for each UE or other device. Thus,
the PDCP header observing components 204, PDCP parameter providing
components 206, and/or packet routing components 320 can operate in
parallel increasing efficiency of the packet routing and/or flow
control. In addition, packet routing components 320 can forward the
packets to donor eNB 102 over other lower protocol layer instances,
as described, as well. In another example, however, a single
instance of PDCP header observing component 204, PDCP parameter
providing component 206, and/or packet routing component 320 or any
number of instances in between can be utilized to support the
plurality of UEs or other devices. In either case, as shown, PDCP
is terminated at the donor eNB 102. Therefore, relay eNB 104 (and
other relay eNBs) need not decrypt communications upon receiving
and forwarding to donor eNB 102. This increases efficiency for
routing packets in a wireless network.
[0068] Referring to FIG. 4, an example wireless communication
system 400 that facilitates routing packets in a wireless network
is illustrated. System 400 includes a donor eNB 102 that provides
relay eNB 104 (and/or other relay eNBs) with access to core network
106. Additionally, as described, relay eNB 104 can provide relay
eNB 108 and UE 110 with access to the core network 106 through the
donor eNB 102. Moreover, for example, there can be multiple relay
eNBs 104 between the donor eNB 102 and relay eNB 108 or UE 110. 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.
[0069] Donor eNB 102 comprises a relay identifier (ID) providing
component 402 that retrieves and provides an ID to one or more
relay eNBs, a packet receiving component 302 that obtains one or
more communication packets from the one or more relay eNBs, an RRP
ID extracting component 404 that determines a relay identifier from
one or more communications packets, a backhaul link component 310
that communicates with core network 106 to provide access thereto
to one or more relay eNBs or UEs, an RRP packet generating
component 406 that creates a response packet including an RRP layer
for communicating to one or more downstream relay eNBs or UEs, a
packet routing component 314 that provides the response packet to
the one or more downstream relay eNBs or UEs, a routing table
component 408 that can maintain mappings of relay IDs to
identifiers of next relay eNBs in a communications path to relay
eNBs represented by the relay IDs, if one or more such intermediary
relay eNBs are present, and a bearer mapping component 410 that
stores associations between evolved packet system (EPS) or similar
core network 106 bearers to radio bearers of one or more downstream
relay eNBs directly communicating with a UE.
[0070] Relay eNB 104 can comprise an ID receiving component 412
that obtains an ID from a donor eNB 102 to include in subsequent
communications therewith, a UE ID providing component 414 that
obtains or generates an ID for a UE communicating with relay eNB
104 and provisions the ID to the UE, a packet receiving component
318 that obtains a communications packet from the UE or donor eNB
102, an RRP packet generating component 416 that creates a packet
having an RRC layer for communicating UE data with a donor eNB or
one or more upstream relay eNBs, a packet routing component 320
that transmits the packet to the donor eNB, one or more upstream
relay eNBs or the UE, an RRP ID extracting component 418 that
determines an RRP identifier in a packet intended for the UE and
received from the donor eNB or one or more relay eNBs, and a
routing table component 420 that can maintain mappings of relay IDs
to identifiers of next relay eNBs in a communications path to the
UE, if one or more such intermediary relay eNBs are present.
[0071] According to an example, relay ID providing component 402
can generate an identifier for relay eNB 104, for example, when
establishing an initial connection therewith, during connection
re-establishment, and/or the like. As described, the connection
between donor eNB 102 and relay eNB 104 can be a wired and/or
wireless link (e.g., a wireless link can include established radio
bearers that communicate using a wireless technology, such as LTE,
and/or the like). Relay ID providing component 402 can transmit the
relay ID to relay eNB 104, and ID receiving component 412 can
obtain the ID. In an example, where intermediary relay eNBs exist
between donor eNB 102 and relay eNB 104, routing table component
408 can store the identifier with an identifier of the next
downstream intermediary relay eNB in a communications path to relay
eNB 104 for appropriate routing. Similarly, UE ID providing
component 414 can create or otherwise receive an identifier for UE
110, for example, when establishing or re-establishing a connection
therewith, etc., and can transmit the ID to UE 110 for subsequent
use in communicating with relay eNB 104. In addition, UE ID
providing component 414 can store the ID in the routing table
component 420 along with a disparate identifier received from UE
110, resources related to communicating with the UE 110, and/or the
like.
[0072] In addition, relay eNB 104 can communicate with donor eNB
102 during UE 110 connection establishment to perform
authentication with core network 106 for the UE 110, bearer
establishment, and/or the like. During bearer establishment for the
UE 110, for example, core network 106 can assign an EPS bearer to
UE 110. Relay eNB 104 can associate a radio bearer with the EPS
bearer for transmitting data received over the EPS bearer to UE
110. In one example, the bearer of relay eNB 104 can be assigned by
the core network 106, donor eNB 102, and/or the like. In any case,
donor eNB 102 can be notified of the bearer of relay eNB 104
associated with the EPS bearer, and bearer mapping component 410
can store a mapping for the EPS bearer to an identifier of the
radio bearer of relay eNB 104 (and/or an identifier of the relay
eNB 104 or UE 110). Where there are additional intermediary relay
eNBs between donor eNB 102 and relay eNB 104, bearer mapping
component 410 associates the EPS bearer and an identifier of the
radio bearer of the relay eNB that communicates directly with the
UE (in this case, relay eNB 104).
[0073] Once connection is established, packet receiving component
318 can obtain a communications packet from UE 110. For example,
the communications packet can include multiple layers, such as an
L1 layer, MAC layer, RLC layer, PDCP layer, IP layer, etc. RRP
packet generating component 416 can create another packet for
forwarding a payload of the communications packet between other
intermediary relay eNBs and/or donor eNB 102. The RRP packet can
comprise L1, MAC, and RLC layers related to communicating with
relay eNB 104, for example, and the RRP packet generating component
416 can create an RRP layer over the RLC layer. The RRP layer can
include an RRP identifier, as described herein, to facilitate
routing the packet among the various relay eNBs and/or donor eNB
102. For example, the RRP packet generating component 416 can
additionally generate the RRP identifier, which can include the
relay ID and the UE ID described above. In addition, for example,
the RRP identifier can include the bearer identifier of relay eNB
104 assigned to transmit communications intended for UE 110,
described above. In one example, the RRP identifier can have a
format similar to the following:
TABLE-US-00001 Relay ID UE ID Relay Radio Bearer ID
[0074] RRP packet generating component 416, for example, can
include upper layers of the received packet (e.g., PDCP, IP, etc.)
in the payload of the generated packet, and packet routing
component 320 can provide the packet to donor eNB 102 (e.g., or one
or more intermediary relay eNBs in a communications path to donor
eNB 102). Packet receiving component 302 can obtain the packet from
relay eNB 104. RRP ID extracting component 404 can detect the RRP
ID in the RRP layer of the received packet. Backhaul link component
310 can communicate a higher layer (e.g., application layer, such
as an IP layer) payload to core network 106 and can specify the RRP
ID, or a portion thereof, in the communication. In this regard,
core network 106 can include the RRP ID, or portion thereof, in any
subsequent responses received over backhaul link component 310. It
is to be appreciated, in an alternative example, that routing table
component 408 can store the RRP ID, or portion thereof, mapped to a
disparate identifier utilized to communicate data related to UE 110
to core network 106, and upon receiving response data, routing
table component 408 can locate the appropriate RRP ID, or portion
thereof, mapped to the corresponding identifier in the response
data.
[0075] In either case, upon backhaul link component 310 receiving
response data from core network 106, RRP packet generating
component 406 can create a response packet for transmitting to UE
110 through one or more relay eNBs. The response packet can have a
similar structure to the packet previously obtained from relay eNB
104 by the packet receiving component 302; in this regard, the
response packet can have a similar RRP layer that comprises the RRP
ID received in the response data over backhaul link component 310
(or as mapped to an identifier received in the response data, as
described), which can be an identifier of relay eNB 104 in this
example. RRP packet generating component 406 can additionally
include the response data in a payload of the response packet.
Moreover, bearer mapping component 410 can determine a radio bearer
of the relay eNB directly communicating with UE 110 (relay eNB 104
in this example) to utilize in communicating the response data to
UE 110. As described, the radio bearer can have been mapped to an
EPS bearer for UE 110 in the core network 106. Thus, based on an
EPS bearer identifier received from core network 106 (e.g., in a
TEID of a GTP packet comprising the response data), bearer mapping
component 410 can determine the appropriate radio bearer identifier
of relay eNB 104 and include the radio bearer identifier in the RRP
ID, which can entail specifying the radio bearer identifier in the
RRP ID.
[0076] Packet routing component 314 can determine a relay eNB for
receiving the response packet based at least in part on the RRP ID.
For example, packet routing component 314 can forward the response
packet to relay eNB 104, as indicated in the RRP ID. In another
example, where there are intermediary relay eNBs between donor eNB
102 and relay eNB to 104, routing table component 408 locates an
identifier of the next intermediary downstream relay eNB in a
communications path to relay eNB 104 from a stored association (as
described). In this regard, packet routing component 314 can
forward the response packet to the next intermediary relay eNB.
[0077] In this example, packet receiving component 318 can obtain
the response packet. RRP ID extracting component 418 can obtain the
RRP ID from the RRP layer of the response packet. As described, the
RRP ID can include an ID of UE 110. In this regard, packet routing
component 320 can transmit a payload of one or more higher layers
of the response packet, or at least a portion thereof, to UE 110.
For example, packet routing component 320 can transmit a PDCP layer
payload over an RLC layer established with UE 110 without the RRP
layer utilized between donor eNB 102 and relay eNB 104 for routing
the response packet. In an example, routing table component 420 can
store a mapping between the UE ID and an identifier of a bearer of
UE 110, and packet routing component 320 can route the response
packet to UE 110 (e.g., over resources assigned thereto) based on
the mapping.
[0078] In another example, a disparate UE (not shown) attached to
relay eNB 108 (or one or more relay eNBs attached thereto) can
communicate with donor eNB 102 via relay eNBs 104 and 108. In this
example, relay ID providing component 402 can generate an
identifier for relay eNB 108 (or one or more relay eNBs attached
thereto) and forward the identifier to relay eNB 104 for
provisioning to relay eNB 108. In this example, ID receiving
component 412 can obtain the identifier, and routing table
component 420 can associate the identifier to a disparate
identifier of relay eNB 108, such as a bearer identifier, resources
assigned thereto, and/or the like, to facilitate subsequent packet
routing thereto. Thus, upon packet receiving component 318
obtaining response packets from donor eNB for the disparate UE, RRP
ID extracting component 418 can retrieve the RRP ID. Where the
relay ID in the RRP ID is not an identifier previously assigned to
relay eNB 104, packet routing component 320 can utilize routing
table component 420 to determine a mapping of the relay ID to a
disparate relay eNB (e.g., relay eNB 108 or one or more relay eNBs
attached thereto). In this example, packet routing component 320
can forward the response packet to relay eNB 108 based on the
mapping. Relay eNB 108 can thus receive the packet and forward a
payload to the disparate UE over a radio bearer specified in the
RRP ID, as described above with respect to relay eNB 104.
[0079] Now turning to FIG. 5, an example wireless communication
network 500 that provides split-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 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.
[0080] 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.
[0081] In an example, UE 110 can communicate with the relay eNB 104
over one or more radio protocol interfaces, such as an E-UTRA-Uu
interface, as described, and the relay eNB 104 can communicate with
the donor eNB 102 using one or more radio protocol interfaces, such
as an E-UTRA-Uu interface, E-UTRA-Un interface or other interface.
As described, relay eNB 104 can leave a PDCP layer of packets from
UE 110 intact, while retrieving one or more parameters from the
PDCP header. In this regard, encryption/decryption, security, and
or other procedures can be performed by UE 110 and donor eNB 102,
such that relay eNB 104 does not need to perform such tasks. 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. 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 transport layer packet and
transmitting the application layer communication to the relay eNB
104 in the new transport layer packet (over the E-UTRA-Un
interface, in one example).
[0082] 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 (and/or UE 110 or one or more related
bearers), such as an RRP ID. In this example, donor eNB 102 can
insert the identifier in the TEID of a GTP-U header, etc. SGW 504
can transmit the TEID in a responding GTP-U header 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 TEID in a routing table at donor eNB 102.
These foregoing functionalities can mitigate the need for UDP/IP
routing on the backhaul link between various eNBs, for example. 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.
[0083] Referring to FIG. 6, example protocol stacks 600 are
illustrated that facilitate communicating in a wireless network to
provide split-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 eNB (ReNB) access link protocol stack 604 is depicted having
an L1 layer, MAC layer, RLC layer, and PDCP header observation, as
described to retrieve one or more parameters, along with an ReNB
backhaul link protocol stack 606 having an L1 layer, MAC layer, RLC
layer, and an RRP layer, which is used to route packets among
multiple ReNBs and/or donor eNBs (DeNB). A DeNB access link
protocol stack 608 is also shown having an L1 layer, MAC layer, RLC
layer, RRP layer, and a PDCP layer, which is terminated at the DeNB
as described, along with a DeNB backhaul link protocol stack 610
having an L1 layer, L2 layer, a user datagram protocol (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, GTP-U layer, and an
IP layer related to an address assigned to the UE.
[0084] According to an example, a UE can communicate with an ReNB
to receive access to a PGW/SGW. In this regard, UE can communicate
over L1, MAC, RLC, and PDCP layers with the ReNB over using a
EUTRA-Uu interface, as shown between protocol stacks 602 and 604.
The UE can tunnel IP layer communications through the ReNB and
other entities to the PGW/SGW, which assigns an IP address to the
UE, as shown between protocol stacks 602 and 612. To facilitate
such tunneling, the ReNB communicates with a DeNB over L1, MAC,
RLC, and RRP layers using an EUTRA-Un interface, as shown between
protocol stacks 606 and 608. As described, the RRP layer can be
generated to include an RRP ID, which can comprise an identifier of
the ReNB (e.g., assigned by the DeNB) and an identifier of the UE
(e.g., assigned by the ReNB). As described, the ReNB and DeNB can
route packets to/from the UE, through various intermediary ReNBs in
one example, using the RRP ID. In addition, upon receiving packets
from DeNB for the UE, ReNB can extract one or more parameters from
a PDCP layer of communications and provide them to the DeNB, as
described, to assist in flow control, SN status transfer, and/or
other purposes.
[0085] The DeNB can receive UE communications from the ReNB and
terminate the PDCP layer. This can include applying
encryption/decryption, security procedures, and/or the like, such
that ReNB need not perform such procedures for UE communication.
The DeNB can transmit the PDCP payload to the PGW/SGW, after
applying such procedures, in a GTP-U layer payload over L1, L2, and
UDP/IP layers. Similarly, the DeNB can receive packets from the
PGW/SGW and can create and transmit a packet comprising the GTP-U
payload in a PDCP layer of the packet. As described, the packet can
also include an RRP layer with a corresponding RRP ID to
appropriately route the packet based on identifiers within the RRP
ID. The ReNB can receive the packet from DeNB and can forward the
PDCP payload to the UE over L1, MAC, and RLC layers.
[0086] Referring to FIG. 7, example protocol stacks 700 are
illustrated that facilitate communicating in a wireless network to
provide split-cell relay functionality for data (e.g., user) plane
communications. A protocol stack 702 for UE 1 is shown comprising
an L1 layer, MAC layer, an RLC layer, a PDCP layer, and an IP
layer, as well as a similar protocol stack 704 for UE 2. ReNB
protocol stacks 706 are additionally shown including access link
protocol stacks 708 and 710, which comprise L1, MAC, and RLC
layers, that respectively receive communications from UE 1 and UE
2. ReNB protocol stacks 706 also include a backhaul link protocol
stack 712 having an L1 layer, MAC layer, RLC layer, an RRP layer,
which is used to route packets among multiple ReNBs and/or a donor
eNBs (DeNB), and a PDCP layer comprising multiplexed PDCP contexts
714, 716, and 718. DeNB protocol stacks 720 are also depicted
including an access link protocol stack 722 and a backhaul link
protocol stack 724. The DeNB access link protocol stack 722 can
include an L1 layer, MAC layer, RLC layer, RRP layer, and a PDCP
layer comprising multiplexed PDCP contexts 726, 728, and 730, and
the DeNB backhaul link protocol stack 724 can include an L1 layer,
L2 layer, a UDP/IP layer, and a GTP-U layer to maintain
communications with a PGW/SGW.
[0087] According to an example, UEs 1 and 2 can communicate with an
ReNB to receive access to a core network via a DeNB. In this
regard, UEs 1 and 2 can communicate over L1, MAC, and RLC layers,
with the ReNB, as shown between protocol stacks 702 and 708, as
well as protocol stacks 704 and 710. The UE can tunnel PDCP and/or
IP layer communications through the ReNB to other network
components. To facilitate such tunneling, the ReNB communicates
with a DeNB over L1, MAC, RLC, and RRP layers for UE 1 and UE 2
communications, as shown between protocol stacks 712 and 722.
Similarly, DeNB can tunnel PDCP and/or IP layer communications to
UEs 1 and 2 through ReNB, as shown. In addition, multiple PDCP
observe contexts 714 and 716 can be generated by the ReNB to tunnel
the communications to the DeNB as shown. In one example, PDCP
context 714 can evaluate one or more parameters in a packet header
of the PDCP layer received from protocol stack 722 intended for UE
1 (e.g., ReNB can determine the intended UE from an identifier in
the RRP layer, as described). The ReNB can provide the one or more
parameters to the DeNB, in one example, and the DeNB can utilize
the parameters in PDCP context 726, and/or one or more additional
parameters as described, for flow control with UE 1, SN status
transfer message processing, and/or the like, as described.
[0088] Similarly, PDCP observe context 716 can retrieve one or more
parameters from a packet header of the PDCP layer received from
protocol stack 722 intended for UE 2. The ReNB, as described can
provide the one or more parameters to the DeNB, which can utilize
the one or more parameters at PDCP context 728 to control flow,
and/or the like. In addition, PDCP context 718 can relate to
explicit PDCP layer communication between the ReNB and DeNB (e.g.,
where communication originates from and/or is terminated at the
ReNB). DeNB can utilize PDCP context 730 to interpret
communications for ReNB. Thus, DeNB, as described, can maintain
separate PDCP contexts, in one example, for communicating with
multiple UEs and/or ReNBs. In another example, however, ReNB
backhaul link protocol stack 712 can include a single PDCP layer
for all UE communications instead of separate contexts to handle
the UEs, or a certain number of multiplexed PDCP contexts that can
each handle one or more UE communications. In addition, in this
example, DeNB access link protocol stack 722 can include a single
PDCP context. In either case, PDCP can terminate at DeNB to provide
end-to-end encrypting/decrypting, security procedures, and/or the
like therewith.
[0089] Referring to FIGS. 8-12, methodologies relating to routing
packets using split-cell relays are illustrated. While, for
purposes of simplicity of explanation, the methodologies are shown
and described as a series of acts, it is to be understood and
appreciated that the methodologies are not limited by the order of
acts, as some acts may, in accordance with one or more aspects,
occur in different orders and/or concurrently with other acts from
that shown and described herein. For example, those skilled in the
art will understand and appreciate that a methodology could
alternatively be represented as a series of interrelated states or
events, such as in a state diagram. Moreover, not all illustrated
acts may be required to implement a methodology in accordance with
one or more aspects.
[0090] Turning to FIG. 8, an example methodology 800 that
facilitates routing a packet to a UE without processing a PDCP
layer thereof is illustrated. At 802, a packet having a routing
layer that includes a payload with a PDCP layer can be received
from an upstream eNB. In one example, the upstream eNB can be a
donor eNB. In addition, for example, the routing layer can be an
RRP layer having an RRP ID related to the UE. At 804, a UE to
receive the payload can be determined based at least in part on a
routing identifier specified in the routing layer of the packet. At
806, the payload can be transmitted to the UE in a disparate
packet. Thus, for example, the identifier of the UE in the routing
identifier can be utilized to determine resources over which to
transmit the payload in the disparate packet to the UE. In
addition, the PDCP layer is forwarded in a disparate packet to the
UE; in this regard, the PDCP layer can be generated at the donor
eNB, as described, and terminated at the UE, and vice versa for
uplink communications. Moreover, in one example, the routing
identifier can specify a radio bearer to utilize in transmitting
the payload to the UE in the disparate packet, and the radio bearer
can be utilized at 806 in this regard.
[0091] Referring to FIG. 9, an example methodology 900 is shown
that facilitates observing PDCP header parameters in routing
communications to a UE. At 902, a packet with a PDCP layer related
to a UE can be received from an upstream eNB. As described, in one
example, a donor eNB can have generated the PDCP layer payload. At
904, one or more parameters can be extracted from a header of the
PDCP layer. For example, the one or more parameters can relate to
an SN of the PDCP layer. At 906, the one or more parameters can be
transmitted to the upstream eNB. Thus, for example, the upstream
eNB can utilize the one or more parameters for flow control, to
assist in SN status transfer message, and/or the like. As
described, for example, the upstream eNB can have a buffer for
controlling flow of downstream packets. Where an SN related to the
last packet forwarded to the UE is received and is over a threshold
difference from an SN of a packet in the buffer, for example, the
upstream can slow the flow of packets.
[0092] Turning to FIG. 10, an example methodology 1000 that
facilitates maintaining a PDCP context for a UE for communicating
packets through one or more relay eNBs is illustrated. At 1002, a
PDCP context related to a UE can be maintained. For example, the UE
context can be initialized upon establishing communications with
the UE (e.g., through one or more relay eNBs) and can include one
or more parameters related to communicating with the UE over a PDCP
layer, such as encryption parameters, security procedure
information, and/or the like, as described. At 1004, an encryption
or security procedure can be applied to a portion of a packet
received over a backhaul link based on the PDCP context. At 1006,
the portion of the packet can be transmitted in a PDCP layer of a
disparate packet to a downstream relay eNB. As described, the
downstream relay eNB can forward the packet to the UE (e.g.,
through one or more intermediary relay eNBs or otherwise) without
processing the PDCP layer.
[0093] Referring to FIG. 11, an example methodology 1100 is shown
that facilitates processing one or more PDCP layer parameters
received from a downstream relay eNB related to communicating with
a UE. At 1102, a packet can be transmitted to a downstream relay
eNB for providing to a UE. As described, in one example, the
downstream relay eNB can be in a communications path to the UE, and
the packet can include a PDCP layer that terminates at the UE.
Thus, the downstream relay eNB can forward the PDCP layer to the UE
without processing the layer. As described, however, the downstream
relay eNB can communicate one or more parameters in the PDCP header
to assist in flow control. At 1104, one or more PDCP layer
parameters can be received from the downstream relay eNB. The one
or more parameters, for example, can include an SN of a packet,
such as a last packet transmitted to the UE. At 1106, flow of the
packets to the downstream relay eNB can be controlled based at
least in part on the one or more PDCP layer parameters. Thus, for
example, where a difference between the SN and an SN of a packet in
a buffer to be transmitted to the downstream relay eNB is above a
threshold, flow of packets to the downstream relay eNB can be
slowed. On the other hand, for example, where the difference is
below a threshold, one or more packets in the buffer can be
transmitted to the downstream relay eNB for providing to the UE, as
described.
[0094] Turning to FIG. 12, an example methodology 1200 that
facilitates preparing packets for routing to a UE is illustrated.
At 1202, a packet for a UE can be received over a backhaul link.
For example, the packet can be received from one or more core
network components. At 1204, a radio bearer of a downstream relay
eNB can be determined for transmitting at least a portion of the
packet to the UE. For instance, the radio bearer can be determined
by locating an association between an EPS bearer identifier related
to the packet (and/or an identifier of the downstream relay eNB)
and the radio bearer identifier in a bearer mapping table that
stores such associations. At 1206, an identifier of the radio
bearer can be specified in a routing identifier. At 1208, the
portion of the packet can be transmitted to one or more downstream
relay eNBs in a communication path to the UE along with the routing
identifier. As described, a downstream relay eNB that communicates
directly with the UE can transmit the portion of the packet over
the radio bearer indicated in the routing identifier.
[0095] It will be appreciated that, in accordance with one or more
aspects described herein, inferences can be made regarding
controlling flow of packets according to one or more PDCP
parameters, transmitting PDCP parameters to upstream eNBs to
control flow, 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.
[0096] Referring now to FIG. 13, a wireless communication system
1300 is illustrated in accordance with various embodiments
presented herein. System 1300 comprises a base station 1302 that
can include multiple antenna groups. For example, one antenna group
can include antennas 1304 and 1306, another group can comprise
antennas 1308 and 1310, and an additional group can include
antennas 1312 and 1314. Two antennas are illustrated for each
antenna group; however, more or fewer antennas can be utilized for
each group. Base station 1302 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.
[0097] Base station 1302 can communicate with one or more mobile
devices such as mobile device 1316 and mobile device 1322; however,
it is to be appreciated that base station 1302 can communicate with
substantially any number of mobile devices similar to mobile
devices 1316 and 1322. Mobile devices 1316 and 1322 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 1300.
As depicted, mobile device 1316 is in communication with antennas
1312 and 1314, where antennas 1312 and 1314 transmit information to
mobile device 1316 over a forward link 1318 and receive information
from mobile device 1316 over a reverse link 1320. Moreover, mobile
device 1322 is in communication with antennas 1304 and 1306, where
antennas 1304 and 1306 transmit information to mobile device 1322
over a forward link 1324 and receive information from mobile device
1322 over a reverse link 1326. In a frequency division duplex (FDD)
system, forward link 1318 can utilize a different frequency band
than that used by reverse link 1320, and forward link 1324 can
employ a different frequency band than that employed by reverse
link 1326, for example. Further, in a time division duplex (TDD)
system, forward link 1318 and reverse link 1320 can utilize a
common frequency band and forward link 1324 and reverse link 1326
can utilize a common frequency band.
[0098] 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 1302. For example, antenna groups can be designed to
communicate to mobile devices in a sector of the areas covered by
base station 1302. In communication over forward links 1318 and
1324, the transmitting antennas of base station 1302 can utilize
beamforming to improve signal-to-noise ratio of forward links 1318
and 1324 for mobile devices 1316 and 1322. Also, while base station
1302 utilizes beamforming to transmit to mobile devices 1316 and
1322 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 1316 and 1322 can
communicate directly with one another using a peer-to-peer or ad
hoc technology (not shown).
[0099] According to an example, system 1300 can be a multiple-input
multiple-output (MIMO) communication system. Further, system 1300
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 1302 can communicate to
the mobile devices 1316 and 1322 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.
[0100] FIG. 14 shows an example wireless communication system 1400.
The wireless communication system 1400 depicts one base station
1410 and one mobile device 1450 for sake of brevity. However, it is
to be appreciated that system 1400 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 1410 and mobile device 1450
described below. In addition, it is to be appreciated that base
station 1410 and/or mobile device 1450 can employ the systems
(FIGS. 1-5 and 13), protocol stacks (FIG. 6-7) and/or methods
(FIGS. 8-12) described herein to facilitate wireless communication
therebetween.
[0101] At base station 1410, traffic data for a number of data
streams is provided from a data source 1412 to a transmit (TX) data
processor 1414. According to an example, each data stream can be
transmitted over a respective antenna. TX data processor 1414
formats, codes, and interleaves the traffic data stream based on a
particular coding scheme selected for that data stream to provide
coded data.
[0102] 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 1450 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 1430.
[0103] The modulation symbols for the data streams can be provided
to a TX MIMO processor 1420, which can further process the
modulation symbols (e.g., for OFDM). TX MIMO processor 1420 then
provides N.sub.T modulation symbol streams to N.sub.T transmitters
(TMTR) 1422a through 1422t. In various aspects, TX MIMO processor
1420 applies beamforming weights to the symbols of the data streams
and to the antenna from which the symbol is being transmitted.
[0104] Each transmitter 1422 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 1422a through 1422t are transmitted from N.sub.T
antennas 1424a through 1424t, respectively.
[0105] At mobile device 1450, the transmitted modulated signals are
received by N.sub.R antennas 1452a through 1452r and the received
signal from each antenna 1452 is provided to a respective receiver
(RCVR) 1454a through 1454r. Each receiver 1454 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.
[0106] An RX data processor 1460 can receive and process the
N.sub.R received symbol streams from N.sub.R receivers 1454 based
on a particular receiver processing technique to provide N.sub.T
"detected" symbol streams. RX data processor 1460 can demodulate,
deinterleave, and decode each detected symbol stream to recover the
traffic data for the data stream. The processing by RX data
processor 1460 is complementary to that performed by TX MIMO
processor 1420 and TX data processor 1414 at base station 1410.
[0107] A processor 1470 can periodically determine which precoding
matrix to utilize as discussed above. Further, processor 1470 can
formulate a reverse link message comprising a matrix index portion
and a rank value portion.
[0108] 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 1438, which also receives traffic data for a number of
data streams from a data source 1436, modulated by a modulator
1480, conditioned by transmitters 1454a through 1454r, and
transmitted back to base station 1410.
[0109] At base station 1410, the modulated signals from mobile
device 1450 are received by antennas 1424, conditioned by receivers
1422, demodulated by a demodulator 1440, and processed by a RX data
processor 1442 to extract the reverse link message transmitted by
mobile device 1450. Further, processor 1430 can process the
extracted message to determine which precoding matrix to use for
determining the beamforming weights.
[0110] Processors 1430 and 1470 can direct (e.g., control,
coordinate, manage, etc.) operation at base station 1410 and mobile
device 1450, respectively. Respective processors 1430 and 1470 can
be associated with memory 1432 and 1472 that store program codes
and data. Processors 1430 and 1470 can also perform computations to
derive frequency and impulse response estimates for the uplink and
downlink, respectively.
[0111] With reference to FIG. 15, illustrated is a system 1500 that
facilitates routing packets to a UE without processing a PDCP layer
payload thereof. 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
receiving a packet having a routing layer that includes a PDCP
layer from an upstream eNB 1504. For example, as described, the
routing layer can include a routing identifier that specifies a
relay eNB communicating with the UE to receive the packet, an
identifier of the UE, and/or an identifier of a radio bearer of the
relay eNB over which the packet is to be transmitted. Additionally,
logical grouping 1502 can include an electrical component for
transmitting a payload of the PDCP layer in a disparate packet to a
UE related to the packet based at least in part on a routing
identifier 1506.
[0112] As described, the UE can be identified from the routing
identifier, as can a radio bearer over which the disparate packet
can be transmitted to the UE by electrical component 1506.
Moreover, logical grouping 1502 can include an electrical component
for retrieving one or more parameters from the header of the PDCP
layer 1508. In addition, logical grouping 1502 can include an
electrical component for transmitting the one or more parameters to
the upstream eNB 1510. Thus, the PDCP header can be observed, as
described, without processing the PDCP payload. In addition, the
one or more parameters can relate to a SN at the PDCP layer, which
can be utilized by the upstream eNB for flow control, to assist in
SN status transfer, and/or the like, as described. Moreover,
logical grouping 1502 can include an electrical component for
receiving an identifier from the upstream eNB upon establishing a
connection with the upstream eNB 1512. As described, this
identifier can be utilized by the upstream eNB in generating the
routing identifier. Additionally, system 1500 can include a memory
1514 that retains instructions for executing functions associated
with electrical components 1504, 1506, 1508, 1510, and 1512. While
shown as being external to memory 1514, it is to be understood that
one or more of electrical components 1504, 1506, 1508, 1510, and
1512 can exist within memory 1514.
[0113] With reference to FIG. 16, illustrated is a system 1600 that
facilitates routing packets to a UE through one or more relay eNBs.
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 maintaining a
PDCP context related to a UE 1604. For example, as described, PDCP
context can be established upon initiating communications with the
UE and can include one or more parameters for encoding a PDCP layer
for the UE. Additionally, logical grouping 1602 can include an
electrical component for applying an encryption or security
procedure to a portion of a packet received over a backhaul link
for a UE according to the PDCP context 1606.
[0114] Moreover, logical grouping 1602 can include an electrical
component for transmitting at least the portion of the packet in a
PDCP layer of a disparate packet to a downstream relay eNB in a
communications path to the UE 1608. In this regard, as described,
the downstream relay eNB can forward the PDCP layer to the UE
without processing a payload thereof. The downstream relay eNB can,
however, determine one or more parameters in a header of the PDCP
packet to assist in flow control, etc., as described. Thus, logical
grouping 1602 can include an electrical component for receiving one
or more parameters related to PDCP layer communications at the UE
from the downstream relay eNB 1610.
[0115] In addition, logical grouping 1602 can include an electrical
component for generating a routing identifier for the disparate
packet based at least in part on an identifier in the portion of
the packet received over the backhaul link 1612. As described, the
routing identifier can include an identifier of a downstream relay
eNB connected to the UE, an identifier or the UE, an identifier of
the radio bearer over which the relay eNB is to transmit the PDCP
layer to the UE, and/or the like. Also, logical grouping 1602 can
include an electrical component for locating an identifier of a
radio bearer of the downstream relay eNB that is associated to an
EPS bearer specified in the portion of the packet in a bearer
mapping table 1614. 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.
[0116] 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.
[0117] 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.
[0118] 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, procedures,
etc. 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.
[0119] 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.
* * * * *