U.S. patent application number 12/605184 was filed with the patent office on 2010-04-29 for header compression for cell relay communications.
This patent application is currently assigned to QUALCOMM Incorporated. Invention is credited to Parag A. Agashe, Gavin B. Horn, Yongsheng Shi, Nathan E. Tenny, Fatih Ulupinar.
Application Number | 20100103865 12/605184 |
Document ID | / |
Family ID | 42117409 |
Filed Date | 2010-04-29 |
United States Patent
Application |
20100103865 |
Kind Code |
A1 |
Ulupinar; Fatih ; et
al. |
April 29, 2010 |
HEADER COMPRESSION FOR CELL RELAY COMMUNICATIONS
Abstract
Systems and methodologies are described that facilitate
compressing packet headers for cell relay communications. Since
cell relays can support a number of evolved packet system (EPS)
bearers over a given dedicated radio bearer (DRB), robust header
compression (RoHC) can be multiplexed for communications to/from a
given cell relay. Thus, an upstream node compressing one or more
packet headers can indicate a RoHC context, which can be
represented by a RoHC context identifier in a RoHC header. A
receiving entity can decompress the headers based on determining
the RoHC context. Alternatively, the RoHC context can be associated
with an identifier of a related UE bearer such as a tunnel endpoint
identifier (TEID), a relay identifier, and/or the like, that is
received in a tunneling protocol header to facilitate packet
routing.
Inventors: |
Ulupinar; Fatih; (San Diego,
CA) ; Horn; Gavin B.; (La Jolla, CA) ; Agashe;
Parag A.; (San Diego, CA) ; Tenny; Nathan E.;
(Poway, CA) ; Shi; Yongsheng; (Falls Church,
VA) |
Correspondence
Address: |
QUALCOMM INCORPORATED
5775 MOREHOUSE DR.
SAN DIEGO
CA
92121
US
|
Assignee: |
QUALCOMM Incorporated
San Diego
CA
|
Family ID: |
42117409 |
Appl. No.: |
12/605184 |
Filed: |
October 23, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61108287 |
Oct 24, 2008 |
|
|
|
Current U.S.
Class: |
370/315 ;
370/477 |
Current CPC
Class: |
H04L 2212/00 20130101;
H04L 29/12207 20130101; H04W 84/047 20130101; H04L 61/20 20130101;
H04W 40/22 20130101; H04B 7/155 20130101; H04L 69/22 20130101; H04W
36/0072 20130101; H04L 69/04 20130101 |
Class at
Publication: |
370/315 ;
370/477 |
International
Class: |
H04B 7/14 20060101
H04B007/14; H04J 3/18 20060101 H04J003/18 |
Claims
1. A method, comprising: receiving a packet with a robust header
compression (RoHC) compressed header from at least one of a
plurality of evolved packet system (EPS) bearers mapped to a
dedicated radio bearer (DRB); determining a RoHC context for the
RoHC compressed header; and decompressing the RoHC compressed
header based at least in part on the RoHC context.
2. The method of claim 1, wherein the determining the RoHC context
includes obtaining a RoHC context identifier from a RoHC header of
the packet.
3. The method of claim 1, further comprising obtaining an
identifier for routing the packet from a tunneling protocol header,
wherein the packet or the RoHC compressed header is encapsulated in
the tunneling protocol header.
4. The method of claim 3, wherein the determining the RoHC context
includes determining the RoHC context based at least in part on the
identifier.
5. The method of claim 4, wherein the tunneling protocol header is
a general packet radio service (GPRS) tunneling protocol (GTP)-U
header and the identifier is a tunnel endpoint identifier
(TEID).
6. The method of claim 4, wherein the tunneling protocol header is
a relay protocol header and the identifier is a relay identifier
assigned by a donor evolved Node B (eNB).
7. The method of claim 1, further comprising providing an internet
protocol (IP) header and a related IP packet to a downstream user
equipment (UE), wherein decompressing the RoHC compressed header
yields the IP header.
8. A wireless communications apparatus, comprising: at least one
processor configured to: obtain a packet with a robust header
compression (RoHC) compressed header from one of a plurality of
evolved packet system (EPS) bearers mapped to a dedicated radio
bearer (DRB) of the wireless communications apparatus; discern a
RoHC context used for compression of the RoHC compressed header;
and decompress the RoHC compressed header according to the RoHC
context; and a memory coupled to the at least one processor.
9. The wireless communications apparatus of claim 8, wherein the at
least one processor discerns the RoHC context based at least in
part on a RoHC context identifier in a header of the packet with
the RoHC compressed header.
10. The wireless communications apparatus of claim 8, wherein the
at least one processor is further configured to extract an
identifier having at least a portion relating to a corresponding
user equipment (UE) bearer from a tunneling protocol header within
which the packet or the RoHC compressed header is encapsulated.
11. The wireless communications apparatus of claim 10, wherein the
at least one processor discerns the RoHC context based at least in
part on the identifier.
12. The wireless communications apparatus of claim 11, wherein the
tunneling protocol header is a general packet radio service (GPRS)
tunneling protocol (GTP)-U header and the identifier is a tunnel
endpoint identifier (TEID).
13. The wireless communications apparatus of claim 11, wherein the
tunneling protocol header is a relay protocol header and the
identifier is a relay identifier assigned by a donor evolved Node B
(eNB).
14. An apparatus, comprising: means for receiving a packet with a
robust header compression (RoHC) compressed header from at least
one of a plurality of evolved packet system (EPS) bearers mapped to
a dedicated radio bearer (DRB); means for determining a RoHC
context for the RoHC compressed header; and means for decompressing
the RoHC compressed header based at least in part on the RoHC
context.
15. The apparatus of claim 14, wherein the means for determining
the RoHC context determines the RoHC context based at least in part
on a RoHC context identifier in a RoHC header of the packet.
16. The apparatus of claim 14, further comprising means for
extracting an identifier relating to a user equipment (UE) bearer
that corresponds to the at least one of the plurality of EPS
bearers from a tunneling protocol header that encapsulates the
packet.
17. The apparatus of claim 16, wherein the means for determining
the RoHC context determines the RoHC context based at least in part
on the identifier.
18. The apparatus of claim 17, wherein the tunneling protocol
header is a general packet radio service (GPRS) tunneling protocol
(GTP)-U header and the identifier is a tunnel endpoint identifier
(TEID).
19. The apparatus of claim 17, wherein the tunneling protocol
header is a relay protocol header and the identifier is a relay
identifier.
20. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
receive a packet with a robust header compression (RoHC) compressed
header from at least one of a plurality of evolved packet system
(EPS) bearers mapped to a dedicated radio bearer (DRB); code for
causing the at least one computer to determine a RoHC context for
the RoHC compressed header; and code for causing the at least one
computer to decompress the RoHC compressed header based at least in
part on the RoHC context.
21. The computer program product of claim 20, wherein the code for
causing the at least one computer to determine the RoHC context
obtains a RoHC context identifier from a RoHC header of the
packet.
22. The computer program product of claim 20, wherein the
computer-readable medium further comprises code for causing the at
least one computer to obtain a local identifier from a tunneling
protocol header, wherein the packet is encapsulated in the
tunneling protocol header.
23. The computer program product of claim 22, wherein the code for
causing the at least one computer to determine the RoHC context
determines the RoHC context based at least in part on the local
identifier.
24. The computer program product of claim 23, wherein the tunneling
protocol header is a general packet radio service (GPRS) tunneling
protocol (GTP)-U header and the local identifier is a tunnel
endpoint identifier (TEID).
25. The computer program product of claim 23, wherein the tunneling
protocol header is a relay protocol header and the local identifier
is a relay identifier assigned by a donor evolved Node B (eNB).
26. An apparatus, comprising: a bearer communicating component that
receives a packet with a robust header compression (RoHC)
compressed header from at least one of a plurality of evolved
packet system (EPS) bearers mapped to a dedicated radio bearer
(DRB); a RoHC context determining component that discerns a RoHC
context for the RoHC compressed header; and a RoHC decompressing
component that decompresses the RoHC compressed header based at
least in part on the RoHC context.
27. The apparatus of claim 26, wherein the RoHC context determining
component discerns the RoHC context based at least in part on a
RoHC context identifier in a RoHC header of the packet.
28. The apparatus of claim 26, further comprising an identifier
receiving component that extracts an identifier relating to a user
equipment (UE) bearer that corresponds to the at least one of the
plurality of EPS bearers from a tunneling protocol header that
encapsulates the packet.
29. The apparatus of claim 28, wherein the RoHC context determining
component discerns the RoHC context based at least in part on the
identifier.
30. The apparatus of claim 29, wherein the tunneling protocol
header is a general packet radio service (GPRS) tunneling protocol
(GTP)-U header and the identifier is a tunnel endpoint identifier
(TEID).
31. The apparatus of claim 29, wherein the tunneling protocol
header is a relay protocol header and the identifier is a relay
identifier.
32. A method, comprising: compressing a header of a packet received
over an evolved packet system (EPS) bearer using robust header
compression (RoHC) based at least in part on a RoHC context;
indicating an identifier related to the RoHC context in the packet;
and transmitting the packet over a dedicated radio bearer (DRB) to
which the EPS bearer and one or more additional EPS bearers are
mapped.
33. The method of claim 32, further comprising selecting a RoHC
context identifier for the packet, wherein the compressing the
header using RoHC is based at least in part on the RoHC context
identifier.
34. The method of claim 33, wherein the indicating the identifier
includes specifying the RoHC context identifier in a RoHC header of
the packet.
35. The method of claim 32, further comprising encapsulating the
header or the packet in a tunneling protocol header, wherein the
indicating the identifier includes specifying the identifier in the
tunneling protocol header.
36. The method of claim 35, wherein the tunneling protocol header
is a general packet radio service (GPRS) tunneling protocol (GTP)-U
header, and the identifier is a tunnel endpoint identifier
(TEID).
37. The method of claim 35, wherein the tunneling protocol header
is a relay protocol header, and the identifier is a relay
identifier assigned by a donor evolved Node B (eNB).
38. The method of claim 32, wherein the packet is an IP packet
received from a core network for communicating to a user equipment
(UE).
39. A wireless communications apparatus, comprising: at least one
processor configured to: compress a header of a packet received
over an evolved packet system (EPS) bearer based at least in part
on a selected robust header compression (RoHC) context; specify an
identifier related to the selected RoHC context in the packet; and
communicate the packet over a dedicated radio bearer (DRB) to which
the EPS bearer and one or more disparate EPS bearers in a core
network are mapped; and a memory coupled to the at least one
processor.
40. The wireless communications apparatus of claim 39, wherein the
at least one processor is further configured to select a RoHC
context identifier for the packet and the selected RoHC context
relates to the RoHC context identifier.
41. The wireless communications apparatus of claim 40, wherein the
identifier is a RoHC context identifier in a RoHC header of the
packet.
42. The wireless communications apparatus of claim 39, wherein the
at least one processor is further configured to encapsulate the
header or the packet in a tunneling protocol header, and the
identifier is related to a relay evolved Node B (eNB) that provides
the DRB specified in the tunneling protocol header.
43. The wireless communications apparatus of claim 42, wherein the
tunneling protocol header is a general packet radio service (GPRS)
tunneling protocol (GTP)-U header, and the identifier is a tunnel
endpoint identifier (TEID).
44. The wireless communications apparatus of claim 42, wherein the
tunneling protocol header is a relay protocol header, and the
identifier is a relay identifier.
45. An apparatus, comprising: means for compressing a header of a
packet received over an evolved packet system (EPS) bearer based at
least in part on a robust header compression (RoHC) context; means
for indicating an identifier related to the RoHC context in the
packet; and means for transmitting the header over a dedicated
radio bearer (DRB) to which the EPS bearer and one or more
additional EPS bearers are mapped.
46. The apparatus of claim 45, further comprising means for
selecting the RoHC context.
47. The apparatus of claim 46, wherein the means for indicating the
identifier specifies an identifier of the RoHC context in a RoHC
header of the packet.
48. The apparatus of claim 45, further comprising means for
encapsulating the header or the packet in a tunneling protocol
header, wherein the means for indicating the identifier specifies
the identifier in the tunneling protocol header.
49. The apparatus of claim 48, wherein the tunneling protocol
header is a general packet radio service (GPRS) tunneling protocol
(GTP)-U header, and the identifier is a tunnel endpoint identifier
(TEID).
50. The apparatus of claim 48, wherein the tunneling protocol
header is a relay protocol header, and the identifier is a relay
identifier.
51. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
compress a header of a packet received over an evolved packet
system (EPS) bearer using robust header compression (RoHC) based at
least in part on a RoHC context; code for causing the at least one
computer to indicate an identifier related to the RoHC context in
the packet; and code for causing the at least one computer to
transmit the packet over a dedicated radio bearer (DRB) to which
the EPS bearer and one or more additional EPS bearers are
mapped.
52. The computer program product of claim 51, wherein the
computer-readable medium further comprises code for causing the at
least one computer to select a RoHC context identifier for the
packet, wherein the code for causing the at least one computer to
compress the header using RoHC compresses the header based at least
in part on the RoHC context identifier.
53. The computer program product of claim 52, wherein the code for
causing the at least one computer to indicate the identifier
specifies the RoHC context identifier in a RoHC header of the
packet.
54. The computer program product of claim 51, wherein the
computer-readable medium further comprises code for causing the at
least one computer to encapsulate the header or the packet in a
tunneling protocol header, wherein the code for causing the at
least one computer to indicate the identifier specifies the
identifier in the tunneling protocol header.
55. The computer program product of claim 54, wherein the tunneling
protocol header is a general packet radio service (GPRS) tunneling
protocol (GTP)-U header, and the identifier is a tunnel endpoint
identifier (TEID).
56. The computer program product of claim 54, wherein the tunneling
protocol header is a relay protocol header, and the identifier is a
relay identifier assigned by a donor evolved Node B (eNB).
57. An apparatus, comprising: a robust header compression (RoHC)
compressing component that compresses a header of a packet received
over an evolved packet system (EPS) bearer using RoHC based at
least in part on a RoHC context; a context identifying component
that specifies an identifier related to the RoHC context in the
packet; and a bearer communicating component that transmits the
header over a dedicated radio bearer (DRB) to which the EPS bearer
and one or more additional EPS bearers are mapped.
58. The apparatus of claim 57, further comprising a RoHC context
selecting component that determines the RoHC context.
59. The apparatus of claim 58, wherein the context identifying
component is a RoHC context indicating component that specifies an
identifier of the RoHC context in a RoHC header of the packet.
60. The apparatus of claim 57, further comprising a packet
encapsulating component that inserts the header or the packet in a
tunneling protocol header, wherein the context identifying
component is an identifier specifying component that indicates the
identifier in the tunneling protocol header.
61. The apparatus of claim 60, wherein the tunneling protocol
header is a general packet radio service (GPRS) tunneling protocol
(GTP)-U header, and the identifier is a tunnel endpoint identifier
(TEID).
62. The apparatus of claim 60, wherein the tunneling protocol
header is a relay protocol header, and the identifier is a relay
identifier.
63. A method, comprising: receiving a packet from an upstream node
comprising a user datagram protocol (UDP), internet protocol (IP),
or general packet radio service (GPRS) tunneling protocol (GTP)
header; compressing the header of the packet to include a
compressed serving gateway (SGW) IP address; and transmitting the
packet with the compressed header to a downstream node.
64. The method of claim 63, wherein the compressed SGW IP address
is of a smaller size than an SGW IP address specified in the header
before compression.
65. The method of claim 63, further comprising generating the
compressed SGW IP address based at least in part on a transport
address translation request received from the downstream node.
66. The method of claim 63, wherein the compressing the header
further comprises compressing the header to include a message type,
a tunnel endpoint identifier (TEID), a sequence number, a N-packet
data unit (PDU) number, or a next extension header type.
67. A wireless communications apparatus, comprising: at least one
processor configured to: obtain a packet from an upstream node
comprising a user datagram protocol (UDP), internet protocol (IP),
or general packet radio service (GPRS) tunneling protocol (GTP)
header; associate a compressed header with the packet that includes
a compressed serving gateway (SGW) IP address; and transmit the
packet with the compressed header to a downstream node; and a
memory coupled to the at least one processor.
68. The wireless communications apparatus of claim 67, wherein the
compressed SGW IP address is of a smaller size than an SGW IP
address specified in the header of the packet.
69. The wireless communications apparatus of claim 67, wherein the
at least one processor is further configured to generate the
compressed SGW IP address based at least in part on a transport
address translation request received from the downstream node.
70. The wireless communications apparatus of claim 67, wherein the
compressed header additionally includes a message type, a tunnel
endpoint identifier (TEID), a sequence number, a N-packet data unit
(PDU) number, or a next extension header type.
71. An apparatus, comprising: means for receiving a packet from an
upstream node comprising a user datagram protocol (UDP), internet
protocol (IP), or general packet radio service (GPRS) tunneling
protocol (GTP) header; means for applying compression to the header
of the packet to compress at least an serving gateway (SGW) IP
address; and means for transmitting the packet with the compressed
header to a downstream node.
72. The apparatus of claim 71, wherein the means for applying
compression to the header compresses the SGW IP address to a
smaller byte size.
73. The apparatus of claim 71, wherein the means for applying
compression generates a compressed representation of the SGW IP
address in response to a transport address translation request
received from the downstream node.
74. The apparatus of claim 71, wherein the compressed header
further includes a message type, a tunnel endpoint identifier
(TEID), a sequence number, a N-packet data unit (PDU) number, or a
next extension header type.
75. A computer program product, comprising: a computer-readable
medium comprising: code for causing at least one computer to
receive a packet from an upstream node comprising a user datagram
protocol (UDP), internet protocol (IP), or general packet radio
service (GPRS) tunneling protocol (GTP) header; code for causing
the at least one computer to compress the header of the packet to
include a compressed serving gateway (SGW) IP address; and code for
causing the at least one computer to transmit the packet with the
compressed header to a downstream node.
76. The computer program product of claim 75, wherein the
compressed SGW IP address is of a smaller size than an SGW IP
address specified in the header before compression.
77. The computer program product of claim 75, wherein the
computer-readable medium further comprises code for causing the at
least one computer to generate the compressed SGW IP address based
at least in part on a transport address translation request
received from the downstream node.
78. The computer program product of claim 75, wherein the code for
causing the at least one computer to compress the header further
compresses the header to include a message type, a tunnel endpoint
identifier (TEID), a sequence number, a N-packet data unit (PDU)
number, or a next extension header type.
79. An apparatus, comprising: an internet protocol (IP) packet
receiving component that receives a packet from an upstream node
comprising a user datagram protocol (UDP), IP, or general packet
radio service (GPRS) tunneling protocol (GTP) header; a header
compressing component compresses the header of the packet at least
in part by compressing an serving gateway (SGW) IP address in the
header; and a bearer communicating component that transmits the
packet with the compressed header to a downstream node.
80. The apparatus of claim 79, wherein the header compressing
component compresses the SGW IP address to a smaller byte size.
81. The apparatus of claim 79, wherein the header compressing
component generates a compressed representation of the SGW IP
address in response to a transport address translation request
received from the downstream node.
82. The apparatus of claim 79, wherein the compressed header
further includes a message type, a tunnel endpoint identifier
(TEID), a sequence number, a N-packet data unit (PDU) number, or a
next extension header type.
Description
CLAIM OF PRIORITY UNDER 35 U.S.C. .sctn.119
[0001] The present Application for Patent claims priority to
Provisional Application No. 61/108,287 entitled "CELL RELAY BASE
STATION FOR LTE" filed Oct. 24, 2008, and assigned to the assignee
hereof and hereby expressly incorporated by reference herein.
BACKGROUND
[0002] 1. Field
[0003] The following description relates generally to wireless
communications, and more particularly to compressing protocol
headers in communicating using cell relays.
[0004] 2. Background
[0005] Wireless communication systems are widely deployed to
provide various types of communication content such as, for
example, voice, data, and so on. Typical wireless communication
systems may be multiple-access systems capable of supporting
communication with multiple users by sharing available system
resources (e.g., bandwidth, transmit power, . . . ). Examples of
such multiple-access systems may include code division multiple
access (CDMA) systems, time division multiple access (TDMA)
systems, frequency division multiple access (FDMA) systems,
orthogonal frequency division multiple access (OFDMA) systems, and
the like. Additionally, the systems can conform to specifications
such as third generation partnership project (3GPP), 3GPP long term
evolution (LTE), ultra mobile broadband (UMB), and/or multi-carrier
wireless specifications such as evolution data optimized (EV-DO),
one or more revisions thereof, etc.
[0006] Generally, wireless multiple-access communication systems
may simultaneously support communication for multiple mobile
devices. Each mobile device may communicate with one or more access
points (e.g., base stations) via transmissions on forward and
reverse links. The forward link (or downlink) refers to the
communication link from access points to mobile devices, and the
reverse link (or uplink) refers to the communication link from
mobile devices to access points. Further, communications between
mobile devices and access points may be established via
single-input single-output (SISO) systems, multiple-input
single-output (MISO) systems, multiple-input multiple-output (MIMO)
systems, and so forth. Access points, however, can be limited in
geographic coverage area as well as resources such that mobile
devices near edges of coverage and/or devices in areas of high
traffic can experience degraded quality of communications from an
access point.
[0007] Cell relays can be provided to expand network capacity and
coverage area by facilitating communication between mobile devices
and access points. For example, a cell relay can establish a
backhaul link with a donor access point, which can provide access
to a number of cell relays, and the cell relay can establish an
access link with one or more mobile devices or additional cell
relays. To mitigate modification to backend core network
components, communication interfaces, such as S1-U, can terminate
at the donor access point. Thus, the donor access point appears as
a normal access point to backend network components. To this end,
the donor access point can route packets from the backend network
components to the cell relays for communicating to the mobile
devices.
SUMMARY
[0008] The following presents a simplified summary of one or more
aspects in order to provide a basic understanding of such aspects.
This summary is not an extensive overview of all contemplated
aspects, and is intended to neither identify key or critical
elements of all aspects nor delineate the scope of any or all
aspects. Its sole purpose is to present some concepts of one or
more aspects in a simplified form as a prelude to the more detailed
description that is presented later.
[0009] In accordance with one or more aspects and corresponding
disclosure thereof, various aspects are described in connection
with facilitating compressing protocol headers to provide efficient
communication among cell relays. In particular, robust header
compression (RoHC) contexts for multiple evolved packet system
(EPS) bearers can be supported over a single dedicated radio bearer
of a cell relay. In one example, a single robust header compressor
can be provided at one communication node and a single robust
header decompressor at the other in relay communications. In this
example, the multiple RoHC contexts for the given EPS bearers can
be differentiated according to assigned context identifiers. In
another example, multiple robust header compressors/decompressors
can be provided at the communication nodes for each RoHC context,
and a tunnel endpoint identifier (TEID) or similar identifier
related to the EPS bearers (or corresponding UE bearers) can be
utilized to differentiate EPS bearers at the nodes. In addition, to
facilitate header compression within the RoHC contexts, a donor eNB
can compress a tunneling protocol header in a packet received from
an upstream network node for downstream communication of the
packet.
[0010] According to related aspects, a method is provided that
includes receiving a packet with a RoHC compressed header from at
least one of a plurality of EPS bearers mapped to a dedicated radio
bearer (DRB). The method also includes determining a RoHC context
for the RoHC compressed header and decompressing the RoHC
compressed header based at least in part on the RoHC context.
[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 RoHC
compressed header from one of a plurality of EPS bearers mapped to
a DRB of the wireless communications apparatus and discern a RoHC
context used for compression of the RoHC compressed header. The at
least one processor is further configured to discern a RoHC context
used for compression of the RoHC compressed header. The wireless
communications apparatus also comprises a memory coupled to the at
least one processor.
[0012] Yet another aspect relates to an apparatus. The apparatus
includes means for receiving a packet with a RoHC compressed header
from at least one of a plurality of EPS bearers mapped to a DRB and
means for determining a RoHC context for the RoHC compressed
header. The apparatus also includes means for decompressing the
RoHC compressed header based at least in part on the RoHC
context.
[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 with a RoHC
compressed header from at least one of a plurality of EPS bearers
mapped to a DRB and code for causing the at least one computer to
determine a RoHC context for the RoHC compressed header. The
computer-readable medium can also comprise code for causing the at
least one computer to decompress the RoHC compressed header based
at least in part on the RoHC context.
[0014] Moreover, an additional aspect relates to an apparatus
including a bearer communicating component that receives a packet
with a RoHC compressed header from at least one of a plurality of
EPS bearers mapped to a DRB. The apparatus can further include a
RoHC context determining component that discerns a RoHC context for
the RoHC compressed header and a RoHC decompressing component that
decompresses the RoHC compressed header based at least in part on
the RoHC context.
[0015] In another aspect, a method is provided that includes
compressing a header of a packet received over an EPS bearer using
RoHC based at least in part on a RoHC context and indicating an
identifier related to the RoHC context in the packet. The method
further includes transmitting the packet over a DRB to which the
EPS bearer and one or more additional EPS bearers are mapped.
[0016] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to compress a header of a packet
received over an EPS bearer based at least in part on a selected
RoHC context and specify an identifier related to the selected RoHC
context in the packet. The at least one processor is further
configured to communicate the packet over a DRB to which the EPS
bearer and one or more disparate EPS bearers in a core network are
mapped. The wireless communications apparatus also comprises a
memory coupled to the at least one processor.
[0017] Yet another aspect relates to an apparatus. The apparatus
includes means for compressing a header of a packet received over
an EPS bearer based at least in part on a RoHC context and means
for indicating an identifier related to the RoHC context in the
packet. The apparatus also includes means for transmitting the
header over a DRB to which the EPS bearer and one or more
additional EPS bearers are mapped.
[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 compress a header of a packet
received over an EPS bearer using RoHC based at least in part on a
RoHC context and code for causing the at least one computer to
indicate an identifier related to the RoHC context in the packet.
The computer-readable medium can also comprise code for causing the
at least one computer to transmit the packet over a DRB to which
the EPS bearer and one or more additional EPS bearers are
mapped.
[0019] Moreover, an additional aspect relates to an apparatus
including a RoHC compressing component that compresses a header of
a packet received over an EPS bearer using RoHC based at least in
part on a RoHC context. The apparatus can further include a context
identifying component that specifies an identifier related to the
RoHC context in the packet and a bearer communicating component
that transmits the header over a DRB to which the EPS bearer and
one or more additional EPS bearers are mapped.
[0020] According to yet another aspect, a method is provided that
includes receiving a packet from an upstream node comprising a user
datagram protocol (UDP), internet protocol (IP), or general packet
radio service (GPRS) tunneling protocol (GTP) header. The method
further includes compressing a header of the packet to include a
compressed SGW IP address and transmitting the packet with the
compressed header to a downstream node.
[0021] Another aspect relates to a wireless communications
apparatus. The wireless communications apparatus can include at
least one processor configured to obtain a packet from an upstream
node comprising a UDP, IP, or GTP header and associate a compressed
header with the packet that includes a compressed SGW IP address.
The at least one processor is further configured to transmit the
packet with the compressed header to a downstream node. The
wireless communications apparatus also comprises a memory coupled
to the at least one processor.
[0022] Yet another aspect relates to an apparatus. The apparatus
includes means for receiving a packet from an upstream node
comprising a UDP, IP, or GTP header and means for applying
compression to a header of the packet to compress at least an SGW
IP address. The apparatus also includes means for transmitting the
packet with the compressed header to a downstream node.
[0023] Still another aspect relates to a computer program product,
which can have a computer-readable medium including code for
causing at least one computer to receive a packet from an upstream
node comprising a UDP, IP, or GTP header. The computer-readable
medium can also comprise code for causing the at least one computer
to compress a header of the packet to include a compressed SGW IP
address and code for causing the at least one computer to transmit
the packet with the compressed header to a downstream node.
[0024] Moreover, an additional aspect relates to an apparatus
including an IP packet receiving component that receives a packet
from an upstream node comprising a UDP, IP, or GTP header and a
header compressing component compresses a header of the packet at
least in part by compressing an SGW IP address in the header. The
apparatus can further include a bearer communicating component that
transmits the packet with the compressed header to a downstream
node.
[0025] To the accomplishment of the foregoing and related ends, the
one or more aspects comprise the features hereinafter fully
described and particularly pointed out in the claims. The following
description and the annexed drawings set forth in detail certain
illustrative features of the one or more aspects. These features
are indicative, however, of but a few of the various ways in which
the principles of various aspects may be employed and this
description is intended to include all such aspects and their
equivalents.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 is an illustration of an example wireless
communications system that facilitates providing relays for
wireless networks.
[0027] FIG. 2 is an illustration of an example wireless
communications system that facilitates compressing headers for cell
relay communication using robust header compression (RoHC).
[0028] FIG. 3 is an illustration of an example wireless
communications system that communicates packets with RoHC
compressed header for multiple EPS bearers over a single dedicated
radio bearer (DRB).
[0029] FIG. 4 is an illustration of an example wireless
communications system that facilitates compressing headers using a
RoHC context that corresponds to a downstream bearer
identifier.
[0030] FIG. 5 is an illustration of an example wireless
communications system that communicates packets with RoHC headers
compressed according to a RoHC context that corresponds to a
downstream bearer identifier.
[0031] FIG. 6 is an illustration of an example wireless
communications system that encapsulates RoHC compressed packets for
subsequent routing.
[0032] FIG. 7 is an illustration of an example wireless
communications system that utilizes cell relays to provide access
to a wireless network.
[0033] FIG. 8 is an illustration of example protocol stacks that
facilitate providing cell relay functionality for data plane
communications.
[0034] FIG. 9 is an illustration of example protocol stacks that
facilitate providing cell relay functionality for data plane
communications using a relay protocol.
[0035] FIG. 10 is an illustration of an example methodology for
decompressing a RoHC compressed header based on a determined RoHC
context.
[0036] FIG. 11 is an illustration of an example methodology that
compresses one or more packet headers using a RoHC context.
[0037] FIG. 12 is an illustration of an example methodology that
encapsulates a packet for subsequent routing.
[0038] FIG. 13 is an illustration of an example methodology that
determines an encapsulation for a received packet.
[0039] FIG. 14 is an illustration of an example methodology that
compresses a user datagram protocol (UDP), internet protocol (IP),
or general packet radio service (GPRS) tunneling protocol (GTP)
header of a received packet.
[0040] FIG. 15 is an illustration of a wireless communication
system in accordance with various aspects set forth herein.
[0041] FIG. 16 is an illustration of an example wireless network
environment that can be employed in conjunction with the various
systems and methods described herein.
[0042] FIG. 17 is an illustration of an example system that
facilitates decompressing a RoHC compressed header based on a
determined RoHC context.
[0043] FIG. 18 is an illustration of an example system that
facilitates compressing a header according to a RoHC context.
[0044] FIG. 19 is an illustration of an example system that
facilitates compressing a UDP, IP, or GTP header.
DETAILED DESCRIPTION
[0045] 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.
[0046] 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.
[0047] Furthermore, various aspects are described herein in
connection with a terminal, which can be a wired terminal or a
wireless terminal A terminal can also be called a system, device,
subscriber unit, subscriber station, mobile station, mobile, mobile
device, remote station, remote terminal, access terminal, user
terminal, terminal, communication device, user agent, user device,
or user equipment (UE). A wireless terminal may be a cellular
telephone, a satellite phone, a cordless telephone, a Session
Initiation Protocol (SIP) phone, a wireless local loop (WLL)
station, a personal digital assistant (PDA), a handheld device
having wireless connection capability, a computing device, or other
processing devices connected to a wireless modem. Moreover, various
aspects are described herein in connection with a base station. A
base station may be utilized for communicating with wireless
terminal(s) and may also be referred to as an access point, a Node
B, evolved Node B (eNB), or some other terminology.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] According to an example, relay eNB 104 can connect to a
donor eNB 102 at the link layer (e.g., media access control (MAC)
layer) as would a UE in regular LTE configurations. In this regard,
donor eNB 102 can be a regular LTE eNB requiring no changes at the
link layer or related interface (e.g., E-UTRA-Uu) to support the
relay eNB 104. In addition, relay eNB 104 can appear to UE 110 as a
regular eNB at the link layer, such that no changes are required
for UE 110 to connect to relay eNB 104 at the link layer, for
example. In addition, relay eNB 104 can configure procedures for
resource partitioning between access and backhaul link,
interference management, idle mode cell selection for a cluster,
and/or the like.
[0054] 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.
[0055] Relay eNB 104 can determine a relay eNB or UE related to the
communications, and provide the communications to the relay eNB or
UE (e.g., based on an identifier thereof within the
communications). Similarly, donor eNB 102 can terminate the
transport layer protocol for communications received from relay eNB
104, translate the communications to a disparate transport
protocol, and transmit the communications over the disparate
transport protocol to the core network 106 with the application
layer intact for relay eNB 104 as a cell relay. In these examples,
where relay eNB 104 is communicating with another relay eNB, the
relay eNB 104 can support application protocol routing to ensure
communications reach the correct relay eNB.
[0056] Moreover, application layer protocols can terminate at
upstream eNBs. Thus, for example, application layer protocols for
relay eNB 108 and UE 110 can terminate at relay eNB 104, and
similarly for relay eNB 104 can terminate at donor eNB 102. The
transport and application layer protocols, for example, can relate
to S1-U, S1-MME, and/or X2 interfaces. S1-U interface can be
utilized to communicate in a data plane between a node and a
serving gateway (not shown) of the core network 106. S1-MME
interface can be utilized for control plane communications between
a node and a mobility management entity (MME) (not shown) of the
core network 106. X2 interface can be utilized for communications
between eNBs. In addition, for example, donor eNB 102 can
communicate with other relay eNBs to allow communications
therebetween over the access network (e.g., relay eNB 104 can
communicate with one or more additional relay eNBs connected to
donor eNB 102).
[0057] According to an example, relay eNB 104 (and relay eNB 108)
can map multiple evolved packet system (EPS) bearers at core
network 106 to a single dedicated radio bearer (DRB) to support a
plurality of downstream UEs, such as UE 110, and/or bearers related
thereto. In addition, relay eNB 104 can support robust header
compression (RoHC) for the multiple UE bearers. In one example,
donor eNB 102 can have a single RoHC compressor and/or decompressor
instance for a DRB of relay eNB 104, and relay eNB 104 can
similarly have a single decompressor and/or compressor for a given
dedicated radio bearer. In this example, donor eNB 102 can compress
packet headers (e.g., internet protocol (IP), user datagram
protocol (UDP) and/or similar packet headers) for multiple EPS
bearers over a single DRB. For example, donor eNB 102 can insert a
RoHC context identifier in the RoHC header, and the relay eNB 104
can differentiate the RoHC contexts based on the RoHC context
identifiers. In this regard, relay eNB 104 can apply appropriate
decompression to the headers. Similarly, relay eNB 104 can compress
and donor eNB 102 can decompress using the RoHC context
identifiers. It is to be appreciated that a RoHC context can refer
to a procedure utilized to compress one or more packet headers for
efficient transmission thereof and can differ according to a type
of bearer and/or data transmitted thereover, a destination node or
type thereof, available resources, and/or the like.
[0058] In another example, donor eNB 102 can have one or more RoHC
compressors and/or decompressors for each EPS bearer mapped to the
DRB of relay eNB 104. Similarly, relay eNB 104 can have one or more
RoHC decompressors and/or compressors for each EPS bearer. In this
example, a RoHC compressor of the donor eNB 102 can compress the
packet headers, and donor eNB 102 can encapsulate the compressed IP
header and the IP packet for a given EPS bearer in a tunneling
protocol header that includes a tunnel endpoint identifier (TEID)
related to the EPS bearer (and/or a corresponding UE 110 bearer).
In one example, the tunneling protocol can be general packet radio
service (GPRS) tunneling protocol (GTP)-U. In another example,
donor eNB 102 can encapsulate the IP packet (or the GTP-U packet)
in a relay protocol (RP) header that facilitates packet routing
based on a relay identifier comprised in the RP packet header.
[0059] Upon receiving the encapsulated packet, relay eNB 104 can
extract the IP header and packet, for example, and one of the
decompressors of relay eNB 104 can determine the RoHC context based
at least in part on the TEID. In another example, one of the
decompressors can determine the RoHC based additionally or
alternatively on the relay identifier. In this regard, the
decompressor can apply the appropriate decompression to the header.
Similarly, relay eNB 104 can compress and donor eNB 102 can
decompress using TEID to determine RoHC context, as described.
[0060] In addition, it is to be appreciated that similar
compression/decompression can be performed in relay eNB 104 to
relay eNB 108 communications (e.g., as related to a bearer of a UE
communicating with relay eNB 108). Moreover, a header for the
tunneling protocol can also be compressed. In one example, the
header can include an address of an upstream network node, such as
a serving gateway (SGW) that can be compressed. The tunneling
protocol can be transmitted over a packet data convergence protocol
(PDCP) layer with an associated IP packet. Thus, for example, PDCP
configuration can be extended to include a payload type that
specifies whether the packet has an IP, GTP-U, or RP header.
[0061] Turning now to FIG. 2, an example wireless communication
system 200 that facilitates RoHC for multiple EPS bearers mapped to
a given cell relay bearer is illustrated. System 200 includes a
donor eNB 102 that provides relay eNB 104 (and/or other relay eNBs)
with access to core network 106. Additionally, as described, relay
eNB 104 can provide one or more devices, such as UE 110, and/or
other relay eNBs with access to the core network 106 through the
donor eNB 102. In addition, it is to be appreciated that relay eNB
104 can comprise the components of donor eNB 102, and vice versa,
to provide similar functionality, in one example. Moreover, donor
eNB 102 can be a macrocell access point, femtocell access point,
picocell access point, mobile base station, and/or the like. Relay
eNB 104 can similarly be mobile or stationary relay nodes that
communicate with donor eNB 102 over a wireless or wired backhaul,
as described.
[0062] Donor eNB 102 comprises a RoHC context selecting component
202 that determines a RoHC context or related identifier for
packets received over an EPS bearer, a RoHC compressing component
204 that applies compression to packet headers received over the
EPS bearer based at least in part on the RoHC context, a RoHC
context indicating component 206 that specifies the selected RoHC
context in a RoHC header of the compressed communication, and a
bearer communicating component 208 that transmits communications to
and/or receives communications from a DRB of a relay eNB. Relay eNB
104 can include a bearer communicating component 210 that receives
communications from and/or transmits communications to a core
network 106 over an EPS bearer (e.g., through one or more upstream
nodes), a RoHC context determining component 212 that obtains a
RoHC context of packet headers received over a DRB mapped to one or
more EPS bearers based at least in part on an identifier in the
RoHC headers of the packets, and a RoHC decompressing component 214
that applies decompression to the packet headers based at least in
part on the determined RoHC context.
[0063] According to an example, donor eNB 102 can receive
communications for relay eNB 104 (and/or one or more relay eNBs or
devices, such as UE 110, communicating directly or indirectly
therewith). For example, core network 106 can have previously
established an EPS bearer that maps to a bearer of UE 110. Relay
eNB 104, as an intermediary node, can have established a bearer to
which core network 106 that actually maps the EPS bearer and can
forward data transmitted over the EPS bearer to UE 110. As
described, relay eNB 104 can support multiple directly connected
UEs as well as relay eNBs, which can have connected UEs or
additional relay eNBs, etc. Thus, relay eNB 104 can be required to
support a number of EPS bearers given a limited number of DRBs at
relay eNB 104. Thus, RoHC can be performed to support a number of
EPS bearers over a single DRB.
[0064] In an example, once communications are received from core
network 106, RoHC context selecting component 202 can determine a
RoHC context for the communications. In one example, this can be
based at least in part on a type of the EPS bearer or related
communications (e.g., voice, video, gaming, etc.), the relay eNB
receiving the data (e.g., relay eNB 104 in this example), available
system resources, and/or the like. RoHC compressing component 204
can apply a RoHC compression to the communications, or headers
thereof, to facilitate efficient transmission of the communications
over a DRB. In one example, the RoHC compressing component 204 can
compress a header of an IP packet by removing or replacing one or
more parameters in the IP packet header previously communicated to
relay eNB 104.
[0065] This can include providing a RoHC header for the
communications. In addition, the RoHC context can have an
associated identifier, for example, that can be utilized to
indicate and subsequently determine the RoHC context type. In this
regard, RoHC context indicating component 206 can insert the
identifier in the header. Bearer communicating component 208 can
provide the RoHC compressed communication to relay eNB 104 over a
mapped DRB. As described, for example, bearer communicating
component 208 can simultaneously provide additional RoHC compressed
communications for disparate EPS bearers over the DRB. In one
example, bearer communicating component 208 can provide the RoHC
compressed communication to relay eNB 104 based at least in part on
locating an association between an identifier of a tunneling
protocol header of the communication and relay eNB 104 in a routing
table.
[0066] Bearer communicating component 210 can receive the RoHC
compressed communications. RoHC context determining component 212
can evaluate an identifier in the RoHC header to determine the RoHC
context. RoHC decompressing component 214 can decompress the
communications, or related headers, based on the determined RoHC
context, for example. It is to be appreciated, for example, that
the RoHC context identifiers can be known by the donor eNB 102
and/or relay eNB 104 according to a specification, configuration,
previous communications, and/or the like. Additionally, using a
RoHC context identifier mitigates the need to transmit other RoHC
context information required for decompressing the RoHC packet,
which decreases bandwidth requirements. Indeed, the context
identifier can be specified as a small number of bits in the RoHC
header. The RoHC context header, in one example, can relate not
only to the type of communications and/or the related RoHC
compression applied, but can also be specific to a corresponding
destination node (e.g., UE 110, or another relay eNB or UE
communicating directly or indirectly with relay eNB 104).
[0067] Moreover, as described, the RoHC functionality for multiple
EPS bearers mapped to a single DRB can be provided for relay eNB
104 communicating with a downstream relay eNB. Indeed,
substantially any two communicating nodes can utilize the
components described herein having a RoHC compressing component 204
at one node and a RoHC decompressing component 214 at the other.
The example shown with donor eNB 102 communicating with relay eNB
104 is but one possible implementation.
[0068] Referring to FIG. 3, an example wireless communication
system 300 for multiplexing multiple RoHC compressed EPS bearers
over a single DRB is illustrated. System 300 includes a donor eNB
102 that provides wireless network access to relay eNB 104, as
described. Donor eNB 102 can include a RoHC
compressing/decompressing component 302 that provides a single
instance of a RoHC compressor and decompressor for communicating
multiple EPS bearer RoHC packets over a single DRB 306 to relay eNB
104. Similarly, relay eNB 104 can include a RoHC
compressing/decompressing component 304 that provides a single
instance of a RoHC compressor and decompressor for communicating
multiple EPS bearer RoHC packets over a single DRB 306 to donor eNB
102. For example, as shown, RoHC compressing/decompressing
component 302 can compress communications for EPS bearer 1 (e.g.,
received from a core network (not shown)) according to a RoHC
context corresponding to identifier 0, and can transmit the
communication over DRB 306 as represented at 308. RoHC
compressing/decompressing component 304 can decompress
communications received from EPS bearer 1 according to the RoHC
context represented by identifier 0.
[0069] Similarly, as described, RoHC compressing/decompressing
component 304 can compress communications to be transmitted over
EPS bearer 1 according to RoHC context with identifier 0 and
transmit the compressed communications to donor eNB 102. RoHC
compressing/decompressing component 302 can decompress the
communications according to the RoHC context represented by
identifier 0, as described, for forwarding data comprised in the
RoHC communication to a core network. As described, the RoHC
contexts and associated identifiers can be known at donor eNB 102
and/or relay eNB 104, such as according to a configuration,
specification, and/or the like.
[0070] Similarly, RoHC compressing/decompressing component 302 can
compress/decompress communications over EPS bearer 2 using RoHC
context with identifier 1 at 310, communications over EPS bearer 3
using RoHC context with identifier 2 at 310, communications over
EPS bearer 4 using RoHC context with identifier 3 at 310, and
communications over EPS bearer 5 using RoHC context with identifier
4 at 310 over DRB 306. In one example, RoHC context identifier 0
can be represented in the RoHC header as zero bytes. RoHC context
identifiers, for example, can range from 0-15, where 1-15 can be
represented as a 4-bit field in the RoHC header. Moreover, for
example, the RoHC context identifiers can be extended to a larger
number to balance a number of supported contexts with a desired
bandwidth utilization.
[0071] Referring to FIG. 4, an example wireless communication
system 400 for communicating RoHC compressed headers for multiple
EPS bearers over a single DRB 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 one or more devices, such as UE 110, and/or
other relay eNBs with access to the core network 106 through the
donor eNB 102. In addition, it is to be appreciated that relay eNB
104 can comprise the components of donor eNB 102, and vice versa,
to provide similar functionality, in one example. Moreover, donor
eNB 102 can be a macrocell access point, femtocell access point,
picocell access point, mobile base station, and/or the like. Relay
eNB 104 can similarly be mobile or stationary relay nodes that
communicate with donor eNB 102 over a wireless or wired backhaul,
as described.
[0072] Donor eNB 102 comprises a RoHC compression instance
component 402 that initializes a RoHC compressor for compressing
headers of one or more packets received from core network 106, a
packet encapsulating component 404 that creates a tunneling
protocol header for routing compressed header packets, an
identifier specifying component 406 that inserts a TEID or other
relay identifier related to the relay eNB 104 in the tunneling
protocol header to facilitate routing the packet, and a bearer
communicating component 208 that transmits communications to and/or
receives communications from a DRB of a relay eNB. Relay eNB 104
can include a bearer communicating component 210 that receives
communications from and/or transmits communications to a core
network 106 over an EPS bearer (e.g., through one or more upstream
nodes), an identifier receiving component 408 that determines an
identifier in a received tunneling protocol header, a RoHC context
determining component 212 that discerns a RoHC context based at
least in part on the identifier, and a RoHC decompression instance
component 410 that initializes a RoHC decompressor that can
decompress packet headers based at least in part on the received
identifier.
[0073] According to an example, donor eNB 102 can receive
communications for relay eNB 104 (and/or one or more relay eNBs or
devices, such as UE 110, communicating directly or indirectly
therewith). For example, core network 106 can have previously
established an EPS bearer that maps to a bearer of UE 110. Relay
eNB 104, as an intermediary node, can have established a bearer to
which core network 106 (e.g., that actually maps the EPS bearer)
and can forward data transmitted over the EPS bearer to UE 110. As
described, relay eNB 104 can support multiple directly connected
UEs as well as relay eNBs, which can also have connected UEs or
additional relay eNBs, etc. Thus, relay eNB 104 can be required to
support a number of EPS bearers given a limited number of DRBs at
relay eNB 104. Thus, RoHC can be performed to support a number of
EPS bearers over a single DRB.
[0074] In an example, once IP packets (or other packets) are
received from core network 106, RoHC compression instance component
402 can create a RoHC compressor for the packet (and/or other
packets received over the same EPS bearer, for example), which can
compress the IP packet header according to one or more RoHC
compression specifications. Packet encapsulating component 404 can
create a tunneling protocol header for the RoHC packets. In one
example, the tunneling protocol header can be a GTP-U header, an RP
header, and/or the like, and can be compressed as well. In one
example, packet encapsulating component 404 can encapsulate the IP
header and packet in a GTP-U header, for example. Identifier
specifying component 406 can include an identifier, such as a TEID
or portion thereof, in the GTP-U header. Moreover, in another
example, packet encapsulating component 404 can additionally
encapsulate the entire packet along with the GTP-U header in a
relay protocol packet. Identifier specifying component 406 can
include a relay identifier in the relay protocol packet header.
[0075] Bearer communicating component 208 can provide the
encapsulated communication to relay eNB 104 over a mapped DRB. As
described, for example, bearer communicating component 208 can
simultaneously provide additional RoHC compressed communications
for disparate EPS bearers over the DRB. In one example, bearer
communicating component 208 can provide the encapsulated
communication to relay eNB 104 based at least in part on locating
an association between an identifier in a header of the
communication (e.g., a TEID and/or relay identifier) and relay eNB
104 in a routing table.
[0076] Bearer communicating component 210 can receive the
encapsulated communication. Identifier receiving component 408 can
determine an identifier in the tunneling protocol header (e.g.,
TEID and/or relay identifier, as described). RoHC context
determining component 212 can determine a RoHC context utilized to
compress the headers based at least in part on the identifier. RoHC
decompression instance component 410 can initialize a RoHC
decompressor that decompresses the IP packet header, which can be
extracted from the relay protocol payload in one example, according
to the RoHC context. In this regard, additional RoHC context
parameters need not be transmitted among the donor eNB 102 and
relay eNB 104; rather, relay eNB 104 can RoHC decompress the IP
packet header based on the TEID or relay identifier of relay eNB
104. In addition, for example, a type of RoHC compression for the
EPS bearer can be previously communicated between donor eNB 102 and
relay eNB 104 and each node can store an association between the
type of RoHC compression and the identifier of relay eNB 104. In
another example, an EPS bearer type can be known at donor eNB 102
and relay eNB 104, and the RoHC context can be based on the EPS
bearer type. It is to be appreciated that the RoHC decompressor can
similarly be utilized to decompress headers of additional IP
packets received over the corresponding EPS bearer.
[0077] Moreover, as described, the RoHC functionality based on an
identifier of relay eNB 104 for multiple EPS bearers mapped to a
single DRB can be provided for relay eNB 104 communicating with a
downstream relay eNB. Indeed, substantially any two communicating
nodes can utilize the components described herein having a
plurality of RoHC compressors at one node and a plurality of
corresponding RoHC decompressors at the other. In addition, relay
eNB 104 can perform the compressing and donor eNB 102 the
decompressing, in another example. The example shown with donor eNB
102 communicating with relay eNB 104 is but one possible
implementation.
[0078] Referring to FIG. 5, an example wireless communication
system 500 for multiplexing multiple RoHC compressed EPS bearers
over a single DRB based on an identifier of relay eNB 104 is
illustrated. System 500 includes a donor eNB 102 that provides
wireless network access to relay eNB 104, as described. Donor eNB
102 can include a RoHC compressing/decompressing component 502 that
provides multiple RoHC compressing instances 506, 508, 510, and 512
for compressing communications over a provided DRB 306. Similarly,
relay eNB 104 can include a RoHC compressing/decompressing
component 504 that provides multiple RoHC decompressing instances
514, 516, 518, and 520 for decompressing communications over DRB
306.
[0079] For example, as shown, RoHC compressing instance 506 can
compress communications and/or related headers received over EPS
bearer 1 using a RoHC context related to relay identifier AABB at
522. For example, the identifier can be an identifier assigned to
relay eNB 104 and/or a related downstream bearer by donor eNB 102,
such as a TEID and/or relay identifier. In another example, the
identifier can be a concatenation of a portion assigned by donor
eNB 102 to the relay eNB 104 or downstream bearer and a portion
assigned by another node (e.g., relay eNB 104 for the downstream
bearer). In any case, the identifier can be unique such that RoHC
decompressing instance 514 can determine and apply a RoHC
decompression context to compress communications according to the
identifier.
[0080] Similarly, RoHC compressing instance 508 can compress
communications over EPS bearer 2 according to identifier CCDD at
524, and RoHC decompressing instance 516 can decompress the
compressed communications or related headers based on the
identifier. In addition, as shown, RoHC compressing instance 510
can compress communications over EPS bearer 3 according to
identifier EEFF at 526, and RoHC decompressing instance 518 can
decompress the compressed communications or related headers based
on the identifier. Moreover, RoHC compressing instance 512 can
compress communications over EPS bearer 4 according to identifier
GGHH at 528, and RoHC decompressing instance 520 can decompress the
compressed communications or related headers based on the
identifier.
[0081] Referring to FIG. 6, an example wireless communication
system 600 for compressing packet headers is illustrated. System
600 includes a donor eNB 102 that provides relay eNB 104 (and/or
other relay eNBs) with access to core network 106. Additionally, as
described, relay eNB 104 can provide one or more devices, such as
UE 110, and/or other relay eNBs with access to the core network 106
through the donor eNB 102. In addition, it is to be appreciated
that relay eNB 104 can comprise the components of donor eNB 102,
and vice versa, to provide similar functionality, in one example.
Moreover, donor eNB 102 can be a macrocell access point, femtocell
access point, picocell access point, mobile base station, and/or
the like. Relay eNB 104 can similarly be mobile or stationary relay
nodes that communicate with donor eNB 102 over a wireless or wired
backhaul, as described.
[0082] Donor eNB 102 comprises an IP packet receiving component 602
that obtains one or more IP packets from core network 106 for a
downstream node, a tunneling protocol encapsulating component 604
that associates the IP packet and/or header with a tunneling
protocol header for packet routing, a header compressing component
606 that compresses one or more headers of the packet, and a bearer
communicating component 208 that transmits communications to and/or
receives communications from a DRB of a relay eNB. Relay eNB 104
can include a bearer communicating component 210 that receives
communications from and/or transmits communications to a core
network 106 over an EPS bearer (e.g., through one or more upstream
nodes), a header decompressing component 608 that decompresses one
or more packet headers, and an IP packet retrieving component 610
that determines an IP packet for providing to UE 110.
[0083] According to an example, IP packet receiving component 602
can obtain an IP packet from core network 106 for providing to UE
110. In this regard, the IP packet can be received with a GTP-U
header that includes an identifier related to UE 110. For example,
at least a portion of the identifier can have been assigned by
donor eNB 102 to facilitate routing the packet through one or more
intermediary relay eNBs. As described previously, in one example
donor eNB 102 can RoHC compress one or more headers of the packet.
Tunneling protocol encapsulating component 604 can create a
tunneling protocol header for the IP packet. For example, the
tunneling protocol header, as described, can be a compressed or
uncompressed GTP-U header, RP header, and/or the like. In an
example, tunneling protocol encapsulating component 604 can include
an identifier in the header for subsequent packet routing (e.g., a
TEID or related portion for a GTP-U header and/or a relay
identifier in an RP header).
[0084] Header compressing component 606 can apply compression to
one or more of the headers (e.g., IP header, GTP-U header, UDP
header, etc.) to reduce a size of the packet. In one example,
header compressing component 606 can compress a GTP-U header of the
received IP packet to a format similar to the following.
TABLE-US-00001 Bits Octets 8 7 6 5 4 3 2 1 1 Version PT I E S PN 2
Message Type 3 Tunnel Endpoint Identifier (1.sup.st Octet) 4 Tunnel
Endpoint Identifier (2.sup.nd Octet) 5 Tunnel Endpoint Identifier
(3.sup.rd Octet) 6 Tunnel Endpoint Identifier (4.sup.th Octet) 7
Sequence Number (1.sup.st Octet).sup.1)4) 8 Sequence Number
(2.sup.nd Octet).sup.1)4) 9 N-PDU Number.sup.2)4) 10 Next Extension
Header Type.sup.3)4) 11 Compressed SGW IP address
where PT is the protocol type, I indicates whether the SGW IP
address is present in the packet, E is an extension header flag
that indicates whether the next extension header type field has a
value, S is a sequence number flag that specifies whether the
sequence number fields have a value, and PN is a flag that
indicates whether the N-packet data unit (N-PDU) field has a value.
Thus, for example, the compressed SGW IP address can be reduced to
one byte. In this regard, donor eNB 102 and relay eNB 104 can have
previously communicated the SGW address and assigned a one byte
identifier to save bandwidth by not including the full address in
the compressed GTP-U header (e.g. in a transport address
translation response to a transport address translation request
received from relay eNB 104). In another example, header
compressing component 606 can compress the IP header. In addition,
in a PDCP protocol utilized to carry the compressed GTP-U header or
an IP header (e.g., where no encapsulation is applied), header
compression component 606 can specify a type of the payload of the
compressed packet (e.g., IP, GTP-U, RP, etc.). In this regard, a
receiving entity can determine which header is compressed.
[0085] Bearer communicating component 208 can transmit the
compressed header packet to relay eNB 104. In one example, as
described, bearer communicating component 208 can provide the
packet to relay eNB 104 based at least in part on locating an
association between an identifier of a tunneling protocol header
(e.g., TEID, relay protocol, etc., as described) of the
communication and relay eNB 104 in a routing table. Bearer
communicating component 210 can receive the packet. Header
decompressing component 608 can determine which header is
compressed based at least in part on a type specified in the PDCP
portion of the packet, as described, and can accordingly decompress
the appropriate header. IP packet retrieving component 610 can
obtain the IP packet and corresponding header once the appropriate
header is decompressed. In one example, IP packet receiving
component 602 can receive a packet with a packet structure similar
to the following.
TABLE-US-00002 L1/L2 UDP/IP Header GTP Header with TEID IP Packet
of Relay eNB
where L1/L2 represents a layer 1/layer 2 portion of the packet. In
this regard, header compressing component 606 can compress the
GTP-U header and prepare the packet for transmitting to relay eNB
104 over an access link, resulting in a packet structure similar to
the following, for example.
TABLE-US-00003 L1/L2 RLC PDCP Compressed GTP Header IP Packet
Thus, for example, header compressing component 606 can
additionally indicate that the packet has a compressed GTP-U header
in the PDCP portion of the packet. Upon receiving the packet, as
described, header decompressing component 608 can interpret the
compressed GTP-U header, which can include a destination address
for the packet, in one example, and IP packet retrieving component
610 can generate a packet structure similar to the following for
transmitting to UE 110.
TABLE-US-00004 L1/L2 RLC PDCP IP Packet
[0086] It is to be appreciated that there can be intermediary relay
eNBs (not shown) in the communications path between donor eNB 102
and relay eNB 104. In this example, the intermediary relay eNBs can
transmit the compressed GTP-U structure, shown above, without
modifying the packet based at least in part on an identifier (e.g.,
TEID and/or relay identifier) in the structure. In addition, it is
to be appreciated that uplink communications from UE 110 to donor
eNB 102 can similarly be compressed by relay eNB 104 for
transmission. In this example, donor eNB 102 can decompress the
GTP-U header to create a GTP-U header with an identifier of a core
network 106 component.
[0087] Now turning to FIG. 7, an example wireless communication
network 700 that provides cell relay functionality is depicted.
Network 700 includes a UE 110 that communicates with a relay eNB
104, as described, to receive access to a wireless network. Relay
eNB 104 can communicate with a donor eNB 102 using a relay protocol
to provide access to a wireless network, and as described, donor
eNB 102 can communicate with an MME 702 and/or SGW 704 that relate
to the relay eNB 104. SGW 704 can connect to or be coupled with a
PGW 706, which provides network access to SGW 704 and/or additional
SGWs. PGW 706 can communicate with a PCRF 708 to
authenticate/authorize UE 110 to use the network, which can utilize
an IMS 710 to provide addressing to the UE 110 and/or relay eNB
104.
[0088] According to an example, MME 702 and/or SGW 704 and PGW 706
can be related to donor eNB 102 serving substantially all relay
eNBs in the cluster. Donor eNB 102 can also communicate with an SGW
716 and PGW 718 that relate to the UE 110, such that the PGW 718
can assign UE 110 a network address to facilitate tunneling
communications thereto through the relay eNB 104, donor eNB 102,
and SGW 716. Moreover, for example, SGW 716 can communicate with an
MME 714 to facilitate control plane communications to and from the
UE 110. It is to be appreciated that MME 702 and MME 714 can be the
same MME, in one example. PGW 718 can similarly communicate with a
PCRF 708 to authenticate/authorize UE 110, which can communicate
with an IMS 710. In addition, PGW 718 can communicate directly with
the IMS 710 and/or internet 712.
[0089] In an example, UE 110 can communicate with the relay eNB 104
over an E-UTRA-Uu interface, as described, and the relay eNB 104
can communicate with the donor eNB 102 using an E-UTRA-Uu interface
or other interface using the relay protocol, as described herein.
Donor eNB 102 communicates with the MME 702 using an S1-MME
interface and the SGW 704 and PGW 706 over an S1-U interface, as
depicted. In one example, as described, communications received
from relay eNB 104 for MME 702 or SGW 704/PGW 706 can be over a
relay protocol and can have an IP address of MME 702 or SGW 704/PGW
706 in the relay protocol header. Donor eNB 102 can appropriately
route the packet according to the IP address and/or payload type of
the relay protocol. In another example, packets from relay eNB 104
can comprised a previously assigned TEID or portion thereof. In
addition, the transport layers used over the S1-MME and S1-U
interfaces are terminated at the donor eNB 102, as described. In
this regard, upon receiving communications for the relay eNB 104
from the MME 702 or SGW 704, donor eNB 102 can, for example,
decouple the application layer from the transport layer by defining
a new relay protocol packet, or other protocol layer packet, and
transmitting the application layer communication to the relay eNB
104 in the new protocol packet (over the E-UTRA-Uu interface, in
one example). Donor eNB 102 can transmit the packet to relay eNB
104 (and/or one or more disparate relay eNBs as described) based on
a TEID in the packet or relay identifier in the header.
[0090] Upon transmitting control plane communications from the
relay eNB 104 to the MME 702, donor eNB 102 can indicate an
identifier of the relay eNB 104 (e.g., in an S1-AP message), and
MME 702 can transmit the identifier in responding communications to
the donor eNB 102. When transmitting data plane communications from
relay eNB 104 to SGW 704, donor eNB 102 can insert an identifier
for the relay eNB 104 (or UE 110 or one or more related bearers) in
the TEID of a GTP-U header to identify the relay eNB 104 (or UE 110
or one or more related bearers). This can be an identifier
generated for relay eNB 104 by donor eNB 102 such that donor eNB
102 can determine the relay eNB 104, or one or more downstream
relay eNBs is to receive the translated packet, as described above.
For example, this can be based at least in part on locating at
least a portion of the identifier in a routing table at donor eNB
102. In addition, headers can be compressed, in one example, as
described. As shown, MME 702 can communicate with SGW 704, and MME
714 to SGW 716, using an S7 interface. PGWs 706 and 718 can
communicate with PCRF 708 over a Gx interface. Furthermore, PCRF
708 can communicate with IMS 710 using an Rx interface, and PGW 718
can communicate with IMS 710 and/or the internet 712 using an SGi
interface.
[0091] Referring to FIG. 8, example protocol stacks 800 are
illustrated that facilitate communicating in a wireless network to
provide cell relay functionality for data (e.g., user) plane
communications using a TEID for packet routing. A UE protocol stack
802 is shown comprising an L1 layer, MAC layer, an RLC layer, a
PDCP layer, and an IP layer. A relay eNB (ReNB) access link
protocol stack 804 is depicted having an L1 layer, MAC layer, RLC
layer, and PDCP layer, as well as an ReNB backhaul link protocol
stack 806 having an L1 layer, PDCP/RLC/MAC layer, and a
C-GTP-U/UDP/IP layer, which can be a compressed layer in one
example, to facilitate routing packets on the backhaul (e.g., by
populating the TEID with the ReNB address, as described
previously). A donor eNB (DeNB) access link protocol stack 808 is
also shown having an L1 layer, PDCP/RLC/MAC layer, and a
C-GTP/UDP/IP layer, as well as a DeNB backhaul link protocol stack
810 having an L1 layer, L2 layer, an IP layer, a UDP layer, and a
GTP-U layer to maintain communications with a PGW/SGW using an
address assigned by the PGW/SGW. PGW/SGW protocol stack 812 has an
L1 layer, L2, layer, IP layer related to an address assigned to the
DeNB, UDP layer, GTP-U layer, and another IP layer related to an
address assigned to the UE.
[0092] 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 802 and 804.
The UE can tunnel IP layer communications through the ReNB and
other entities to the PGW/SGW, which assigns an IP address to the
UE, as shown between protocol stacks 802 and 812. To facilitate
such tunneling, the ReNB communicates with a DeNB over L1,
PDCP/RLC/MAC, and C-GTP-U/UDP/IP layers using an S1-U-R interface,
as shown between protocol stacks 806 and 808. As described, the
S1-U-R interface can be a newly defined interface that utilizes a
disparate transport layer than communications between DeNB and
PGW/SGW. In this regard, communications between ReNB and DeNB
additionally use a compressed version of the GTP-U, UDP/IP headers.
Moreover, this compressed header can indicate TEID, as described
herein, of the ReNB in the GTP-U header to facilitate return
communications, as described, herein. DeNB can decouple the
C-GTP-U/UDP/IP header from the transport layer and communicate with
the PGW over separate GTP-U, UDP, and IP layers on top of L1 and L2
physical layers over an S1-U interface, as shown between protocol
stacks 810 and 812. The same can be true for downlink
communications, as described, where DeNB decouples the GTP, UDP,
and IP layers from the transport layers, compresses them into a
C-GTP-U/UDP/IP header, and transmits over the PDCP/RLC/MAC and L1
layers to the ReNB. DeNB, as described, can use a TEID in the GTP-U
header to route the packet to the ReNB. In one example, this
mitigates the need for UDP/IP routing on the backhaul, etc.
[0093] Referring to FIG. 9, example protocol stacks 900 are
illustrated that facilitate communicating in a wireless network to
provide cell relay functionality for data (e.g., user) plane
communications using a relay protocol. A UE protocol stack 902 is
shown comprising an L1 layer, MAC layer, an RLC layer, a PDCP
layer, and an IP layer. A relay eNB 1 (ReNB) access link protocol
stack 904 is depicted having an L1 layer, MAC layer, RLC layer, and
PDCP layer, as well as an ReNB1 backhaul link protocol stack 906
having an L1 layer, MAC layer, RLC layer, PDCP layer, relay
protocol (RP) layer, and a C-GTP-U/UDP/IP layer, which can be a
compressed layer in one example, to facilitate communicating
packets on the backhaul. An intermediary ReNB2 access link protocol
stack 908 is shown having an L1 layer, MAC layer, RLC layer, PDCP
layer, and RP layer, as well as a backhaul link protocol stack 910
for the intermediary ReNB2 having the same layers.
[0094] A DeNB access link protocol stack 908 is also shown having
an L1 layer, MAC layer, RLC layer, PDCP layer, RP layer, and a
C-GTP/UDP/IP layer, as well as a DeNB backhaul link protocol stack
910 having an L1 layer, L2 layer, a UDP/IP layer, and a GTP-U layer
to maintain communications with a PGW/SGW using an address assigned
by the PGW/SGW. PGW/SGW protocol stack 912 has an L1 layer, L2,
layer, UDP/IP layer related to an address assigned to the DeNB,
GTP-U layer, and another IP layer related to an address assigned to
the UE.
[0095] According to an example, a UE can communicate with an ReNB1
to receive access to a PGW/SGW. In this regard, UE can communicate
over L1, MAC, RLC, and PDCP layers with the ReNB1 over using a
EUTRA-Uu interface, as shown between protocol stacks 902 and 904.
The UE can tunnel IP layer communications through the ReNB1 and
other entities to the PGW/SGW, which assigns an IP address to the
UE, as shown between protocol stacks 902 and 916. To facilitate
such tunneling, ReNB 1 communicates with ReNB2 over an RP, as
described herein, on top of L1, MAC, RLC, PDCP layers using an
S1-U-R interface (or other new interface for communicating using a
relay protocol), as shown between protocol stacks 906 and 908. In
addition, the RP can carry the upper layer C-GTP-U/UDP/IP layer in
the RP payload, as described previously, to the disparate RP, as
shown between protocol stacks 906 and 908. Moreover, as described,
the RP header can include an identifier of ReNB1, an IP address of
the PGW/SGW, a protocol type indicating C-GTP-U/UDP/IP data in the
RP payload, and/or the like.
[0096] ReNB2, and any other intermediary ReNBs, can forward the RP
communication to the DeNB, as shown between protocol stack s 910
and 912. In this example, DeNB can receive the RP packet, over the
lower layers, and can extract the C-GTP-U/UDP/IP packet from the
payload and communicate with the PGW over separate GTP-U, UDP, and
IP layers on top of L1 and L2 physical layers over an S1-U
interface, as shown between protocol stacks 914 and 916. In one
example, the DeNB can include the relay identifier from the RP
packet header in the GTP-U communications. Thus, as described,
downlink communications from PGW/SGW protocol stack 912 can include
the relay identifier. In this regard, upon receiving downlink
communications from PGW/SGW protocol stack 916 over DeNB backhaul
link protocol stack 914, DeNB access link protocol stack 912 can
generate an RP packet with a header comprising the relay identifier
received over PGW/SGW protocol stack 916 and a compressed
GTP-U/UDP/IP packet as the payload. DeNB access link protocol stack
912 can transmit the RP packet over ReNB2 backhaul link protocol
stack 912, which can forward the RP packet over ReNB2 access link
protocol stack 908 to ReNB backhaul link protocol stack 906 based
on the relay identifier in the RP header, as described. ReNB1
backhaul link protocol stack 906 can obtain the C-GTP-U/UDP/IP
payload of the RP packet and forward to UE protocol stack 902,
where the RP packet payload is of certain types, as described.
[0097] Referring to FIGS. 10-14, methodologies relating to
compressing and/or encapsulating packets for transmission in a
wireless network using cell relays are illustrated. While, for
purposes of simplicity of explanation, the methodologies are shown
and described as a series of acts, it is to be understood and
appreciated that the methodologies are not limited by the order of
acts, as some acts may, in accordance with one or more aspects,
occur in different orders and/or concurrently with other acts from
that shown and described herein. For example, those skilled in the
art will understand and appreciate that a methodology could
alternatively be represented as a series of interrelated states or
events, such as in a state diagram. Moreover, not all illustrated
acts may be required to implement a methodology in accordance with
one or more aspects.
[0098] Turning to FIG. 10, an example methodology 1000 that
facilitates decompressing a received header based at least in part
on a RoHC context is illustrated. At 1002, a packet with a RoHC
compressed header can be received from at least one of a plurality
of EPS bearers mapped to a DRB. As described, the packet can be
RoHC compressed according to a RoHC context. At 1004, the RoHC
context for the RoHC compressed header can be determined. For
example, the RoHC context can be determined based on an identifier
in the RoHC header that relates to a RoHC compression context, an
identifier at least partially related to a respective UE bearer,
such as a TEID and/or relay identifier in a tunneling protocol
header, and/or the like, as described. At 1006, the RoHC compressed
header can be decompressed based at least in part on the RoHC
context. For example, the decompression, as described, can be
performed by a single decompressor that decompresses substantially
all RoHC compressed headers received from an upstream node, a
decompressor specific to the EPS bearer, and/or the like. Moreover,
the RoHC contexts can relate to procedures utilized to compress the
header that are known at the compression and decompression nodes,
as described; the RoHC contexts can differ based on an EPS bearer
type, data transmitted over the bearer, node type, available
resources, and/or the like.
[0099] Referring to FIG. 11, an example methodology 1100 is shown
that facilitates RoHC compressing packet headers using a RoHC
context. At 1102, a header of a packet received over an EPS bearer
can be compressed based at least in part on a RoHC context. As
described, the RoHC context can be selected based at least in part
on a bearer type, data type, node type, etc. At 1104, an identifier
related to the RoHC context can be indicated in the packet. In this
regard, a decompressor can determine the RoHC context to utilize
for decompressing the compressed header. At 1106, the packet can be
transmitted over a DRB to which the EPS bearer and one or more
disparate EPS bearers are mapped.
[0100] Turning to FIG. 12, an example methodology 1200 that
facilitates encapsulating a packet or header in a tunneling
protocol is illustrated. At 1202, an IP packet can be received from
a core network for transmitting to a UE bearer. For example, the IP
packet can include a GTP header that specifies an identifier
related at least in part to the UE bearer. At 1204, the IP header
and/or packet can be encapsulated in a tunneling protocol header
that includes an identifier related to the UE bearer. As described,
where the IP header is RoHC compressed, the identifier can be
utilized to determine a RoHC context for decompressing the header.
For example, the tunneling protocol header can be a compressed or
uncompressed GTP-U header, an RP header, etc., and the identifier
can be a TEID, relay identifier, or portion thereof, etc. At 1206,
a tunneling protocol header type can be indicated in a PDCP portion
of the packet. In this regard, a receiving node can determine the
encapsulated packet type to retrieve the IP packet and header. At
1208, the packet can be transmitted to one or more relay nodes in a
communications path to the UE. As described, the one or more relay
nodes can be determined from the identifier in the tunneling
protocol header (e.g., as indicated in a routing table, in one
example).
[0101] Referring to FIG. 13, an example methodology 1300 that
facilitates obtaining an IP packet and header from an encapsulated
packet is illustrated. At 1302, a packet encapsulated in a
tunneling protocol header can be received. At 1304, a type of the
tunneling protocol header can be determined from an indicator in
the PDCP portion of the packet. For example, the indicator can
specify a compressed GTP-U, RP, IP, or similar type. Based on the
type, at 1306, an IP packet and header can be retrieved from the
packet. For example, if the packet or header is RoHC compressed,
and the indicator specifies compressed GTP-U, the GTP-U header can
be decompressed and the IP packet and header retrieved from the
payload. If the type is RP, the IP packet and header can be
retrieved as the payload of the RP packet, for example.
[0102] Referring to FIG. 14, an example methodology 1400 that
facilitates compressing a UDP, IP, and/or GTP header of a packet is
illustrated. At 1402, a packet can be received from an upstream
node comprising a UDP, IP, or GTP header. At 1404, the header of
the packet can be compressed to include a compressed SGW IP
address. As described, for example, an SGW IP address in a header
received from a core network can be compressed to a one byte or
other smaller sized value previously communicated to a downstream
node (e.g., in a transport address translation response). In this
regard, the compressed header can require less bandwidth for
transmission. It is to be appreciated that the header can include
additional fields and/or the additional fields can be compressed as
well. At 1406, the packet with the compressed header can be
transmitted to a downstream node.
[0103] It will be appreciated that, in accordance with one or more
aspects described herein, inferences can be made regarding
determining a RoHC context and/or related identifier, associating a
RoHC context with a TEID or relay identifier, and/or other aspects
described herein. As used herein, the term to "infer" or
"inference" refers generally to the process of reasoning about or
inferring states of the system, environment, and/or user from a set
of observations as captured via events and/or data. Inference can
be employed to identify a specific context or action, or can
generate a probability distribution over states, for example. The
inference can be probabilistic--that is, the computation of a
probability distribution over states of interest based on a
consideration of data and events. Inference can also refer to
techniques employed for composing higher-level events from a set of
events and/or data. Such inference results in the construction of
new events or actions from a set of observed events and/or stored
event data, whether or not the events are correlated in close
temporal proximity, and whether the events and data come from one
or several event and data sources.
[0104] Referring now to FIG. 15, a wireless communication system
1500 is illustrated in accordance with various embodiments
presented herein. System 1500 comprises a base station 1502 that
can include multiple antenna groups. For example, one antenna group
can include antennas 1504 and 1506, another group can comprise
antennas 1508 and 1510, and an additional group can include
antennas 1512 and 1514. Two antennas are illustrated for each
antenna group; however, more or fewer antennas can be utilized for
each group. Base station 1502 can additionally include a
transmitter chain and a receiver chain, each of which can in turn
comprise a plurality of components associated with signal
transmission and reception (e.g., processors, modulators,
multiplexers, demodulators, demultiplexers, antennas, etc.), as
will be appreciated by one skilled in the art.
[0105] Base station 1502 can communicate with one or more mobile
devices such as mobile device 1516 and mobile device 1522; however,
it is to be appreciated that base station 1502 can communicate with
substantially any number of mobile devices similar to mobile
devices 1516 and 1522. Mobile devices 1516 and 1522 can be, for
example, cellular phones, smart phones, laptops, handheld
communication devices, handheld computing devices, satellite
radios, global positioning systems, PDAs, and/or any other suitable
device for communicating over wireless communication system 1500.
As depicted, mobile device 1516 is in communication with antennas
1512 and 1514, where antennas 1512 and 1514 transmit information to
mobile device 1516 over a forward link 1518 and receive information
from mobile device 1516 over a reverse link 1520. Moreover, mobile
device 1522 is in communication with antennas 1504 and 1506, where
antennas 1504 and 1506 transmit information to mobile device 1522
over a forward link 1524 and receive information from mobile device
1522 over a reverse link 1526. In a frequency division duplex (FDD)
system, forward link 1518 can utilize a different frequency band
than that used by reverse link 1520, and forward link 1524 can
employ a different frequency band than that employed by reverse
link 1526, for example. Further, in a time division duplex (TDD)
system, forward link 1518 and reverse link 1520 can utilize a
common frequency band and forward link 1524 and reverse link 1526
can utilize a common frequency band.
[0106] Each group of antennas and/or the area in which they are
designated to communicate can be referred to as a sector of base
station 1502. For example, antenna groups can be designed to
communicate to mobile devices in a sector of the areas covered by
base station 1502. In communication over forward links 1518 and
1524, the transmitting antennas of base station 1502 can utilize
beamforming to improve signal-to-noise ratio of forward links 1518
and 1524 for mobile devices 1516 and 1522. Also, while base station
1502 utilizes beamforming to transmit to mobile devices 1516 and
1522 scattered randomly through an associated coverage, mobile
devices in neighboring cells can be subject to less interference as
compared to a base station transmitting through a single antenna to
all its mobile devices. Moreover, mobile devices 1516 and 1522 can
communicate directly with one another using a peer-to-peer or ad
hoc technology (not shown).
[0107] According to an example, system 1500 can be a multiple-input
multiple-output (MIMO) communication system. Further, system 1500
can utilize substantially any type of duplexing technique to divide
communication channels (e.g., forward link, reverse link, . . . )
such as FDD, FDM, TDD, TDM, CDM, and the like. In addition,
communication channels can be orthogonalized to allow simultaneous
communication with multiple devices over the channels; in one
example, OFDM can be utilized in this regard. Thus, the channels
can be divided into portions of frequency over a period of time. In
addition, frames can be defined as the portions of frequency over a
collection of time periods; thus, for example, a frame can comprise
a number of OFDM symbols. The base station 1502 can communicate to
the mobile devices 1516 and 1522 over the channels, which can be
create for various types of data. For example, channels can be
created for communicating various types of general communication
data, control data (e.g., quality information for other channels,
acknowledgement indicators for data received over channels,
interference information, reference signals, etc.), and/or the
like.
[0108] FIG. 16 shows an example wireless communication system 1600.
The wireless communication system 1600 depicts one base station
1610 and one mobile device 1650 for sake of brevity. However, it is
to be appreciated that system 1600 can include more than one base
station and/or more than one mobile device, wherein additional base
stations and/or mobile devices can be substantially similar or
different from example base station 1610 and mobile device 1650
described below. In addition, it is to be appreciated that base
station 1610 and/or mobile device 1650 can employ the systems
(FIGS. 1-7 and 15), protocol stacks (FIG. 8-9) and/or methods
(FIGS. 10-14) described herein to facilitate wireless communication
therebetween.
[0109] At base station 1610, traffic data for a number of data
streams is provided from a data source 1612 to a transmit (TX) data
processor 1614. According to an example, each data stream can be
transmitted over a respective antenna. TX data processor 1614
formats, codes, and interleaves the traffic data stream based on a
particular coding scheme selected for that data stream to provide
coded data.
[0110] The coded data for each data stream can be multiplexed with
pilot data using orthogonal frequency division multiplexing (OFDM)
techniques. Additionally or alternatively, the pilot symbols can be
frequency division multiplexed (FDM), time division multiplexed
(TDM), or code division multiplexed (CDM). The pilot data is
typically a known data pattern that is processed in a known manner
and can be used at mobile device 1650 to estimate channel response.
The multiplexed pilot and coded data for each data stream can be
modulated (e.g., symbol mapped) based on a particular modulation
scheme (e.g., binary phase-shift keying (BPSK), quadrature
phase-shift keying (QPSK), M-phase-shift keying (M-PSK),
M-quadrature amplitude modulation (M-QAM), etc.) selected for that
data stream to provide modulation symbols. The data rate, coding,
and modulation for each data stream can be determined by
instructions performed or provided by processor 1630.
[0111] The modulation symbols for the data streams can be provided
to a TX MIMO processor 1620, which can further process the
modulation symbols (e.g., for OFDM). TX MIMO processor 1620 then
provides N.sub.T modulation symbol streams to N.sub.T transmitters
(TMTR) 1622a through 1622t. In various aspects, TX MIMO processor
1620 applies beamforming weights to the symbols of the data streams
and to the antenna from which the symbol is being transmitted.
[0112] Each transmitter 1622 receives and processes a respective
symbol stream to provide one or more analog signals, and further
conditions (e.g., amplifies, filters, and upconverts) the analog
signals to provide a modulated signal suitable for transmission
over the MIMO channel. Further, N.sub.T modulated signals from
transmitters 1622a through 1622t are transmitted from N.sub.T
antennas 1624a through 1624t, respectively.
[0113] At mobile device 1650, the transmitted modulated signals are
received by N.sub.R antennas 1652a through 1652r and the received
signal from each antenna 1652 is provided to a respective receiver
(RCVR) 1654a through 1654r. Each receiver 1654 conditions (e.g.,
filters, amplifies, and downconverts) a respective signal,
digitizes the conditioned signal to provide samples, and further
processes the samples to provide a corresponding "received" symbol
stream.
[0114] An RX data processor 1660 can receive and process the
N.sub.R received symbol streams from N.sub.R receivers 1654 based
on a particular receiver processing technique to provide N.sub.T
"detected" symbol streams. RX data processor 1660 can demodulate,
deinterleave, and decode each detected symbol stream to recover the
traffic data for the data stream. The processing by RX data
processor 1660 is complementary to that performed by TX MIMO
processor 1620 and TX data processor 1614 at base station 1610.
[0115] A processor 1670 can periodically determine which precoding
matrix to utilize as discussed above. Further, processor 1670 can
formulate a reverse link message comprising a matrix index portion
and a rank value portion.
[0116] The reverse link message can comprise various types of
information regarding the communication link and/or the received
data stream. The reverse link message can be processed by a TX data
processor 1638, which also receives traffic data for a number of
data streams from a data source 1636, modulated by a modulator
1680, conditioned by transmitters 1654a through 1654r, and
transmitted back to base station 1610.
[0117] At base station 1610, the modulated signals from mobile
device 1650 are received by antennas 1624, conditioned by receivers
1622, demodulated by a demodulator 1640, and processed by a RX data
processor 1642 to extract the reverse link message transmitted by
mobile device 1650. Further, processor 1630 can process the
extracted message to determine which precoding matrix to use for
determining the beamforming weights.
[0118] Processors 1630 and 1670 can direct (e.g., control,
coordinate, manage, etc.) operation at base station 1610 and mobile
device 1650, respectively. Respective processors 1630 and 1670 can
be associated with memory 1632 and 1672 that store program codes
and data. Processors 1630 and 1670 can also perform computations to
derive frequency and impulse response estimates for the uplink and
downlink, respectively.
[0119] It is to be understood that the aspects described herein can
be implemented in hardware, software, firmware, middleware,
microcode, or any combination thereof. For a hardware
implementation, the processing units can be implemented within one
or more application specific integrated circuits (ASICs), digital
signal processors (DSPs), digital signal processing devices
(DSPDs), programmable logic devices (PLDs), field programmable gate
arrays (FPGAs), processors, controllers, micro-controllers,
microprocessors, other electronic units designed to perform the
functions described herein, or a combination thereof.
[0120] When the aspects are implemented in software, firmware,
middleware or microcode, program code or code segments, they can be
stored in a machine-readable medium, such as a storage component. A
code segment can represent a procedure, a function, a subprogram, a
program, a routine, a subroutine, a module, a software package, a
class, or any combination of instructions, data structures, or
program statements. A code segment can be coupled to another code
segment or a hardware circuit by passing and/or receiving
information, data, arguments, parameters, or memory contents.
Information, arguments, parameters, data, etc. can be passed,
forwarded, or transmitted using any suitable means including memory
sharing, message passing, token passing, network transmission,
etc.
[0121] For a software implementation, the techniques described
herein can be implemented with modules (e.g., procedures,
functions, and so on) that perform the functions described herein.
The software codes can be stored in memory units and executed by
processors. The memory unit can be implemented within the processor
or external to the processor, in which case it can be
communicatively coupled to the processor via various means as is
known in the art.
[0122] With reference to FIG. 17, illustrated is a system 1700 that
facilitates decompressing RoHC headers in one or more received
packets. For example, system 1700 can reside at least partially
within a base station, mobile device, etc. It is to be appreciated
that system 1700 is represented as including functional blocks,
which can be functional blocks that represent functions implemented
by a processor, software, or combination thereof (e.g., firmware).
System 1700 includes a logical grouping 1702 of electrical
components that can act in conjunction. For instance, logical
grouping 1702 can include an electrical component for receiving a
packet with a RoHC compressed header from at least one of a
plurality of EPS bearers mapped to a DRB 1704. As described, system
1700 can support a number of UEs and thus can map the EPS bearers
provided by a core network to single bearers. Additionally, logical
grouping 1702 can include an electrical component for determining a
RoHC context for the RoHC compressed header 1706. As described,
this can include analyzing an identifier in the RoHC header that
indicates a RoHC context used for compression, determining an
identifier related at least in part to a downstream UE bearer that
indicates the RoHC context, and/or the like.
[0123] Moreover, logical grouping 1702 can include an electrical
component for decompressing the RoHC compressed header based at
least in part on the RoHC context 1708. In addition, for example,
logical grouping 1702 can include an electrical component for
extracting an identifier relating to a UE bearer the corresponds to
the EPS bearer from a tunneling protocol header that encapsulates
the packet 1710. For example, the tunneling protocol can be a
GTP-U, RP, and/or similar protocol, and the identifier, as
described can be a TEID, relay identifier, or portion thereof. The
identifier can relate to the RoHC context, as described previously.
Additionally, system 1700 can include a memory 1712 that retains
instructions for executing functions associated with electrical
components 1704, 1706, 1708, and 1710. While shown as being
external to memory 1712, it is to be understood that one or more of
electrical components 1704, 1706, 1708, and 1710 can exist within
memory 1712.
[0124] With reference to FIG. 18, illustrated is a system 1800 that
facilitates RoHC compressing packet headers for efficient
transmission of related packets in a wireless network that utilizes
cell relays. For example, system 1800 can reside at least partially
within a base station, mobile device, etc. It is to be appreciated
that system 1800 is represented as including functional blocks,
which can be functional blocks that represent functions implemented
by a processor, software, or combination thereof (e.g., firmware).
System 1800 includes a logical grouping 1802 of electrical
components that can act in conjunction. For instance, logical
grouping 1802 can include an electrical component for compressing a
header of a packet received over an EPS bearer based at least in
part on a RoHC context 1804. For example, as described, the RoHC
context can vary depending on one or more factors relating to
system 1800, core network, and/or the like, such as EPS bearer
type, data type transmitted over the EPS bearer, node type,
available resources, etc. Additionally, logical grouping 1802 can
include an electrical component for indicating an identifier
related to the RoHC context in the packet 1806. As described, this
can include a RoHC context identifier in a RoHC header, an
identifier related at least in part to a UE bearer indicated in a
tunneling protocol header (e.g., a TEID or relay identifier in a
GTP-U or RP header), and/or the like.
[0125] Moreover, logical grouping 1802 can include an electrical
component for transmitting the packet header over a DRB to which
the EPS bearer and one or more additional EPS bearers are mapped
1808. In addition, logical grouping 1802 can include an electrical
component for selecting the RoHC context 1810. This can be based on
one or more of the described parameters, in one example,
provisioned from a core network, and/or the like. Further, logical
grouping 1802 can include an electrical component for encapsulating
the header or the packet in a tunneling protocol header 1812. As
described, this can be a GTP-U header, an RP header, and/or the
like, to facilitate packet routing among various cell relays.
Additionally, system 1800 can include a memory 1814 that retains
instructions for executing functions associated with electrical
components 1804, 1806, 1808, 1810, and 1812. While shown as being
external to memory 1814, it is to be understood that one or more of
electrical components 1804, 1806, 1808, 1810, and 1812 can exist
within memory 1814.
[0126] With reference to FIG. 19, illustrated is a system 1900 that
facilitates compressing UDP, IP, or GTP headers in received packets
for forwarding to downstream nodes. For example, system 1900 can
reside at least partially within a base station, mobile device,
etc. It is to be appreciated that system 1900 is represented as
including functional blocks, which can be functional blocks that
represent functions implemented by a processor, software, or
combination thereof (e.g., firmware). System 1900 includes a
logical grouping 1902 of electrical components that can act in
conjunction. For instance, logical grouping 1902 can include an
electrical component for receiving a packet from an upstream node
comprising a UDP, IP, or GTP header 1904. Additionally, logical
grouping 1902 can include an electrical component for applying
compression to a header of the packet to compress at least an SGW
IP address 1906.
[0127] As described, compressing the SGW IP address can include
utilizing a compressed version of the SGW IP address negotiated
during a transport address translation request/response procedure
with system 1900. Moreover, logical grouping 1902 can include an
electrical component for transmitting the packet with the
compressed header to a downstream node 1908. Utilizing the
compressed header, as described, can conserve bandwidth for more
efficient transmitting. Additionally, system 1900 can include a
memory 1910 that retains instructions for executing functions
associated with electrical components 1904, 1906, and 1908. While
shown as being external to memory 1910, it is to be understood that
one or more of electrical components 1904, 1906, and 1908 can exist
within memory 1910.
[0128] 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.
[0129] 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.
[0130] In one or more aspects, the functions described may be
implemented in hardware, software, firmware, or any combination
thereof. If implemented in software, the functions may be stored or
transmitted as one or more instructions or code on a
computer-readable medium. Computer-readable media includes both
computer storage media and communication media including any medium
that facilitates transfer of a computer program from one place to
another. A storage medium may be any available media that can be
accessed by a computer. By way of example, and not limitation, such
computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or
other optical disk storage, magnetic disk storage or other magnetic
storage devices, or any other medium that can be used to carry or
store desired program code in the form of instructions or data
structures and that can be accessed by a computer. Also, any
connection may be termed a computer-readable medium. For example,
if software is transmitted from a website, server, or other remote
source using a coaxial cable, fiber optic cable, twisted pair,
digital subscriber line (DSL), or wireless technologies such as
infrared, radio, and microwave, then the coaxial cable, fiber optic
cable, twisted pair, DSL, or wireless technologies such as
infrared, radio, and microwave are included in the definition of
medium. Disk and disc, as used herein, includes compact disc (CD),
laser disc, optical disc, digital versatile disc (DVD), floppy disk
and blu-ray disc where disks usually reproduce data magnetically,
while discs usually reproduce data optically with lasers.
Combinations of the above should also be included within the scope
of computer-readable media.
[0131] 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.
* * * * *