Mobile Transceiver, Base Station Transceiver, Data Server, and Related Apparat¬
uses, Methods, and Computer Programs
Embodiments of the present invention relate to communication systems, more particularly
but not exclusively to packet data transmission in mobile communication systems.
Background
Demands for higher data rates for mobile services are steadily increasing. At the same
time modern mobile communication systems as 3rd Generation systems (3G) and 4th
Generation systems (4G) provide enhanced technologies, which enable higher spectral
efficiencies and allow for higher data rates and cell capacities. Users of today's
handhelds become more difficult to satisfy. While old feature phones generated only data
or voice traffic, current smartphones, tablets, and netbooks run various applications in
parallel that can fundamentally differ from each other. Compared to feature phones, this
application mix leads to a number of new characteristics. For example, highly dynamic
load statistics result.
Conventional cellular networks become more and more overloaded by data traffic; cf. G.
Maier, F. Schneider, A. Feldmann. "A First Look at Mobile Hand-held Device Traffic",
In Proc. Int. Conference on Passive and Active Network Measurement (PAM 0), April
2010. This high load is mainly caused by smart handhelds such as smartphones, tablets,
and laptops, which may generate substantially more traffic than previous handheld gen
erations, lead to complex traffic requests that may not be efficiently served at the base
station, and span more and more user sessions over multiple cells, decreasing the net
work efficiency per session.
Furthermore, smart handhelds provide more information about the user, when compared
to previous handheld generations. Context-Aware Resource Allocation (CARA) can exploit
such information about the user's device, its location, and the communication de
mands of its currently running applications. Details on CARA can, for example, be found
in M. Proebster, M. Kaschub, and S. Valentin "Context- Aware Resource Allocation to
Improve the Quality of Service of Heterogeneous Traffic", Proc. IEEE International Con
ference on Communications (ICC), Jun. 201 1, or in EP1 1305685.7. By being aware of
the user's context a Base Station (BS) can substantially reduce the network load without
sacrificing the user's Quality of Service (QoS), M. Proebster, M. Kaschub, T. Werthmann,
and S. Valentin, "Context- Aware Resource Allocation for Cellular Wireless Net
works", EURASIP Journal on Wireless Communications and Networking (WCN), sub
mitted for review Oct. 201 1.
Summary
It is one finding of the present invention that CARA concepts and algorithms may run at
a Data Link Control (DLC) layer of a BS, and although they may provide tremendous
gains, they rely on context information from the handheld' s higher layers. According to
another finding this essential information for the CARA algorithms can be provided by a
feedback protocol, which may signal context information from the handheld to the BS
and/or to the core network behind it. Moreover, handheld information from layers higher
than the DLC may be provided to the BS' DLC layer. Furthermore, embodiments are
based on the finding that a signaling concept and general types of context information
can be provided by several signaling architectures and protocols.
Embodiments are based on the finding that mobile devices may signal context infor
mation to the BS or to the core network. Moreover, other information is already signaled
during the uplink. In particular, mobile devices may signal Channel Quality Information
(CQI), acknowledgements for retransmission schemes and scheduling requests to the
base station, details of such signaling concepts can be found, for example, in 3G Partner
ship Project (3GPP) Technical Specification (TS) 36.300 VI 1.0.0, "Evolved Universal
Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access
Network (E-UTRAN), Overall description", Dec. 201 1. It is a further finding that this
may happen entirely at the DLC in a dedicated control channel. Furthermore, these feedback
procedures may not support information transfer between layers above and the
DLC. Moreover, the feedback procedures may have no access to such higher layer in
formation at the handheld. Thus, existing DLC signaling may not provide context information
from higher layers (e.g., locations, application status or requirements) to the BS.
Although the 3GPP DLC includes methods to signal Quality of Service (QoS) require
ments from the handheld to the BS, such signaling is based on a fixed table and header
field of limited space. Such fixed signaling may not be flexible enough to signal utility
functions or arbitrary further context information to the BS.
It is a further finding that at the network layer, e . g . in Internet Protocol (IP) packets,
there is a header field to signal a QoS-class, cf. K. Nichols, S. Blake, F. Baker, and D.
Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", IETF RFC 2474, Dec. 1998. However, this field has a size of 6 bit and is used
to classify the packet in flight. It may not be possible to carry all necessary information
for the applications' requirements and the classification of data packets to application
transactions within this header field. Hence, a mechanism may be desirable to directly
signal information from the application layer of the mobile device to the DLC at the BS.
Moreover, it is a finding that one approach to provide such cross-layer signaling can be
Deep Packet Inspection (DPI). By inspecting the user's packets in the BS queues, cf.
Nguyen, T.T.T.; Armitage, G.; , "A Survey of Techniques for Internet Traffic Classifica
tion Using Machine Learning," Communications Surveys & Tutorials, IEEE , Fourth
Quarter 2008, the access network can extract information from layers above the DLC.
However, this method may be limited to unencrypted packets, can add high processing
and memory costs, can add high communication delay, and only provides a limited set of
information to the BS. Compared to classifying inspected packets, directly measuring the
context of a user (e.g., its location, mobility path, running applications and their QoS
requirements) at the handheld may be more accurate and efficient. Embodiments are
based on the finding that a middleware or an entity at the handheld may access such in
formation and may explicitly signal it to the BS.
Embodiments may provide cross-layer signaling architectures and protocols for transferring
context information from the higher layers of a mobile transceiver to the DLC of a
base station transceiver. To do so, embodiments can make use of mechanisms to signal
QoS requirements of application-layer data flows to a DLC. This signaling procedure
can, for example, be integrated into the user's or a mobile's feedback communication in
the uplink. Further procedures can map DLC data frames to application layer flows for
the downlink.
Embodiments provide an apparatus for a mobile transceiver for, or in, a mobile commu
nication system, i.e. embodiments may provide said apparatus to be operated by or com
prised in a mobile transceiver. In the following, the apparatus will also be referred to as
mobile station transceiver apparatus. Moreover, the terms mobile communication net
work and mobile communication system will be used synonymously. The mobile communication
system may, for example, correspond to one of the 3GPP-standardized mo
bile communication networks, as e.g. Long Term Evolution (LTE), an LTE-Advanced
(LTE-A), a Universal Mobile Telecommunication System (UMTS) or a UMTS Terrestri
al Radio Access network (UTRAN), an Evolved-UTRAN (E-UTRAN), a Global System
for Mobile Communication (GSM) or Enhanced Data Rates for GSM Evolution (EDGE)
network, a GSM/EDGE Radio Access Network (GERAN), generally an Orthogonal Fre
quency Division Multiple Access (OFDMA) network, etc., or mobile communication
networks with different standards, e.g. Worldwide Interoperability for Microwave Access
(WFMAX).
The mobile communication system further comprises a base station transceiver. The base
station transceiver can be operable to communicate with a number of mobile transceivers.
In embodiments, the mobile communication system may comprise mobile transceivers
and base station transceivers, wherein the base station transceivers may establish macro
cells or small cells, as e.g. pico-, metro-, or femto cells. A mobile transceiver may
correspond to a smartphone, a cell phone, a laptop, a notebook, a personal computer, a
Personal Digital Assistant (PDA), a Universal Serial Bus (USB) -stick, a car, etc. it may
also be referred to as handheld or mobile. A mobile transceiver may also be referred to as
User Equipment (UE) in line with the 3GPP terminology.
A base station transceiver can be located in the fixed or stationary part of the network or
system. A base station transceiver may correspond to a remote radio head, a transmission
point, an access point, a macro cell, a small cell, a micro cell, a femto cell, a metro cell
etc. A base station transceiver can be a wireless interface of a wired network, which ena
bles transmission of radio signals to a UE or mobile transceiver. Such a radio signal may
comply with radio signals as, for example, standardized by 3GPP or, generally, in line
with one or more of the above listed systems. Thus, a base station transceiver may correspond
to a NodeB, an eNodeB (e B), a Base Transceiver Station (BTS), an access point,
a remote radio head, a transmission point etc., which may be further subdivided in a r e
mote unit and a central unit.
A mobile transceiver can be associated with the base station transceiver or cell. The term
cell refers to a coverage area of radio services provided by a base station transceiver, e.g.
a NodeB, an eNodeB, a remote radio head, a transmission point, etc. A base station
transceiver may operate multiple cells on one or more frequency layers, in some embod
iments a cell may correspond to a sector. For example, sectors can be achieved using
sector antennas, which provide a characteristic for covering an angular section around a
remote unit or base station transceiver. In some embodiments, a base station transceiver
may, for example, operate three or six cells covering sectors of 120° (in case of three
cells), 60° (in case of six cells) respectively. A base station transceiver may operate mu l
tiple sectorized antennas.
In embodiments the mobile transceiver apparatus comprises means for extracting context
information from an application being run on the mobile transceiver, context information
from an operation system being run on the mobile transceiver, or context information
from hardware drivers or hardware of the mobile transceiver. The context information
comprises information on a state of the application and/or information on a state of the
mobile transceiver. The means for extracting may correspond to an extractor, a processor,
a micro-processor, a controller, etc. The mobile transceiver apparatus further comprises
means for communicating data packets with the base station transceiver, wherein the data
packets comprise payload data packets and control data packets. The means for com
municating may correspond to a communicator, a transceiver, a transmitter, a receiver,
etc., e.g. in line with one of the above listed communication systems. The means for
communicating is operable to communicate payload data packets associated with the
application with a data server through the base station transceiver. The data server may
correspond to a server providing the actual application data, it can also correspond to a
gateway of the mobile communication system, as e.g. an Internet gateway such as a Pub
lic Data Network GateWay (PDN-GW).
The mobile transceiver apparatus further comprises means for providing the context information
to the base station transceiver, wherein the context information is comprised in
a payload data packet or in a control data packet. Hence, embodiments can make use of
different signaling and classification approaches. In some embodiments a dedicated con
trol channel between the mobile device and the base station can be used. That is to say,
the mobile transceiver may transmit requirements and classification rules to the BS and
the BS may map this information to the downlink DLC frames. In other words, in some
embodiments layer 2 or layer 3 signaling may be used in terms of control data packets to
provide the context information from the mobile transceiver apparatus to the BS. In terms
of 3GPP a Signaling Radio Bearer (SRB) may, for example, be used to carry the context
information as part of a Radio Resource Control (RRC) protocol.
Hence, embodiments also provide a corresponding apparatus for a base station transceiv
er for, or in, a mobile communication system, which further comprises a mobile trans
ceiver. That is to say, embodiments may provide said apparatus to be operated by or
comprised in a base station transceiver, which can be compliant to one or more of the
above listed communication systems. In the following, the apparatus will also be referred
to as base station transceiver apparatus. The base station transceiver apparatus comprises
means for receiving control data packets and payload data packets. The means for receiv
ing may correspond to a receiver or transceiver compliant to one or more of the above
listed systems. The payload data packets are associated with an application being run on
the mobile transceiver. The base station transceiver apparatus further comprises means
for obtaining context information associated with the application from a control data
packet or from a payload data packet. The means for obtaining may correspond to an
obtainer, a processor, a micro-processor, a controller, etc.
Moreover, the base station transceiver apparatus may comprise means for scheduling the
mobile transceiver for transmission of the data packets based on the context information.
The means for scheduling may correspond to a scheduler, a processor, a microprocessor,
a controller, etc. The term scheduling is to be understood as the assignment of
radio resources, such as time, frequency, power, code or spatial resources, for transmis
sion or reception of data packets. It may refer to uplink, downlink or both.
In the following the context information is assumed to comprise one or more elements of
the group of information on a quality of service requirement of the application, priority
information of the data packets associated with the application, information on a unity of
a plurality of the data packets of the application, information on a load demand of the
application, information on a delay or error rate constraint of the application, information
on a window state at the mobile transceiver, information on a memory consumption of
the mobile transceiver, information on a processor usage of the application running on
the mobile transceiver, information on a current location, speed, orientation of the mobile
transceiver, or a distance of the mobile transceiver to another mobile transceiver. The
context information or a transaction data packet may comprise mapping information between
one or more data packets and a scheduling queue at the base station transceiver.
In other words, the context information may comprise information on the application, for
example, it may comprise an information on a user focus, i.e. whether the application is
currently displayed in the foreground or in the background, information on the type of
application, i.e. web browsing, interactive, streaming, conversational, etc., information
on the type of request, i.e. whether the requested data is just a prefetch or it is to be dis
played immediately, information on certain delay or QOS requirements, etc.
In other words, the context information can be provided per application. For example,
two streaming applications are running in parallel on the mobile transceiver. According
to the prior art, both applications' data would be mapped to streaming transport channels
at the lower layers. Therefore, according to the prior art, data from the two applications
would not be distinguished by a scheduler. According to embodiments, the context in
formation may be available for the applications separately. For example, the context information
of one application may indicate that it is displayed in the foreground; the con
text information of the other application may indicate it is in background. Therefore, em
bodiments can provide the advantage that these two applications and their data can be
distinguished by the scheduler and the application running in the foreground can be pr i
oritized. Hence, separate or differentiating context information may be provided even for
applications of the same type, e.g. two web browsing sessions. The context information
can as well be extracted from the operation system, as an application may not have the
information on whether it is in foreground or background. This information, also deter
mining a state of the application, may be extracted from a window manager of the opera
tion system of the mobile transceiver.
The unity of the data packets may refer to information indicating that a number of data
packets belong together, for example, the application can correspond to an image dis
playing application and the image data is contained in a plurality of data packets. Then
the context information may indicate how many data packets refer to one image. This
information may be taken into account by the scheduler. In other words, from the context
information the scheduler may determine a certain relation between the data packets, e.g.
the user may only be satisfied if the whole image is displayed, therefore all packets refer
ring to the image should be transmitted to the mobile transceiver in an adequate time in
terval. Therewith the scheduler can be enabled to plan ahead.
In embodiments the means for extracting can be adapted to extract the context information
from an operation system of the mobile transceiver or from the application being
run on the mobile transceiver. In other words, the operation system of the mobile trans
ceiver can provide the context information, e.g. as state information of an application
(foreground/background, active/suspended, standby, etc.). Another option is that the ap
plication itself provides the context information.
Hence, in line with the above description the base station transceiver apparatus may r e
ceive the context information via layer 2 or layer 3, e.g. RRC, control data packets. In
other embodiments signaling at the application layer may be used, e.g. in terms of IP
packets. Since the IP address of the base station transceiver may be unknown at the mobile
transceiver apparatus an any-cast mechanism may be used. Hence, data packets can
be addressed to the base station using any-cast data packets, and which are interpreted by
the base station transceiver apparatus extracting the context information. The context
information can then be used at the base station transceiver apparatus in line with the
above description. The term any-cast is understood as mechanism in a network, where an
according data packet is interpreted by any next node, which receives the data packet. An
any-cast indication in a data packet may tell the base station transceiver apparatus that
the packet is meant to be interpreted, as the base station transceiver is the first node to
receive said data packet. Any-cast can be used on different layers in the protocol stack.
For example, an any-cast data packet may correspond to an IP data packet with an anycast
indication for the base station transceiver. The indication may, for example, be com
prised in the Type Of Service (TOS) field in the header of the IP packet. In other embodiments
the Universal Datagram Protocol (UDP) can be used and the any-cast indication
may correspond to a certain port given in the IDP header, e.g. a certain destination port.
In further embodiments, the mobile transceiver apparatus may comprise means for com
posing a transaction data packet as part of a transaction protocol. The transaction data
packet comprises the context information. In some embodiments the transaction data
packet is communicated to the base station transceiver using an any-cast payload data
packet in line with the above description. A transaction data packet or context infor
mation can be communicated to the base station transceiver using a link layer protocol
control data packet. The transaction protocol may then use lower protocol layer services,
such as layer 1 or PHYsical layer (PHY), layer 2, e.g. Medium Access Control (MAC) or
Radio Link Control (RLC). Moreover, the transaction protocol may use the so called u s
er-plane protocols for payload data packet transmission. Hence, the transaction protocol
may also use UDP, IP, the packet Data Convergency Protocol (PDCP). The transaction
protocol may use the control plane and it may, for example, be part of RRC.
In further embodiments the transaction data packet is communicated to the data server
using a unicast payload data packet, e.g. using IP. In other words, the transaction data
packet may then be received at the base station from the data server using a unicast payload
data packet, e.g. via IP. Hence, the context information may not be communicated
directly to the base station transceiver but indirectly through the data server. In another
embodiment a control data packet may be used to signal the context information from the
mobile transceiver apparatus to the base station transceiver apparatus. Thus, the transaction
data packet or the context information may be received from the mobile transceiver
using a link layer protocol control data packet. The base station transceiver apparatus
may then forward classification information to the data server, e.g. an Internet gateway.
The context information can then be received from the data server, which is provided
with classification information from the base station transceiver. The context information
may then correspond to a tag in a data packet received from the data server. The classifi
cation information may comprise QoS settings or requirements for a scheduler queue at
the base station transceiver, a transaction context at the scheduler of the base station
transceiver, respectively.
Hence, the gateway or data server may classify downlink packets accordingly and tag
them to provide the mapping information to the base station transceiver. In yet another
embodiment, the mobile transceiver apparatus performs IP signaling of the context in
formation directly to the data server. A classification can then be carried out at the data
server, but, in addition to tags, the data server may signal the application flow's QoS requirements
to the base station transceiver. The context information or a transaction data
packet may comprise mapping information between one or more data packets and a
scheduling queue at the base station transceiver.
In embodiments of the base station transceiver apparatus the means for scheduling can be
operable to determine a transmission sequence for a plurality of transactions. The plurali
ty of transactions may refer to a plurality of applications being run by one or more mo
bile transceivers. A transaction may correspond to a plurality of data packets for which
the context information indicates unity. The order of the sequence of transactions can be
based on a utility function, which may depend on a completion time of a transaction,
which is determined based on the context information.
In other words, the context information may be evaluated using a utility function. The
utility function may be a measure for the user satisfaction and therefore depend on a
completion time of a transaction. For example, for a transaction comprising data packets
of a web page, a web browsing application has requested the completion time may, for
example, be 2s. In other words, full user satisfaction may be achieved when the full content
of the web page is transmitted in less than 2s. Otherwise, the user satisfaction and
therewith the utility function will degrade. The sequence of the transactions can be de
termined in different ways in embodiments. In some embodiments the transmission se
quence is determined from an iteration of multiple different sequences of transactions.
The multiple different sequences can correspond to different permutations of the plurality
of transactions. The means for scheduling can be adapted to determine the utility function
for each of the multiple different sequences and it can be further adapted to select the
transmission sequence from the multiple different sequences corresponding to the maxi
mum sum utility function. In other words, in embodiments the scheduling decision may
be determined based on an optimized user satisfaction or utility function, where the op
timization may be based on a limited set of sequences.
In some embodiments, the actual transmission sequence or scheduling decision may be
further based on the radio condition of a particular user, e.g. the means for scheduling
can be adapted to further modify the transmission sequence based on the supportable data
rate for each transaction. In other embodiments other fairness criteria or rate or through
put criteria may be considered.
Accordingly, embodiments provide an apparatus for, or in, a data server, i.e. embodi
ments may provide said apparatus to be operated by or comprised in a data server. In the
following, the apparatus will also be referred to as data server apparatus. The data server
communicates data packets associated with an application being run on a mobile trans
ceiver through a mobile communication system to the mobile transceiver, in line with the
above description. The data server apparatus comprises means for deriving context in
formation for the data packets based on classification information received from a base
station transceiver. The means for deriving may correspond to a deriver, a processor, a
micro-processor, a controller, etc. The data server apparatus further comprises means for
transmitting the context information along with the data packets to the mobile communi
cation system. The means for transmitting may correspond to a transmitter, e.g. an inter
face for communicating with the base station transceiver, e.g. an Ethernet interface. In
some embodiments a wireless interface between the data server and the base station is
conceivable, e.g. when the data server correspond to another mobile transceiver.
As it has been described above, the data server apparatus may further comprise means for
composing a data packet. The means for composing may correspond to a composer, a
processor, a micro-processor, a controller, etc. The data packet may comprise application
data packets and a tag with mapping information for the data packet to a scheduling
queue at the base station transceiver, in line with what is described above. The means for
composing may be operable to compose a transaction data packet, which comprises ap
plication data packets and the context information, to compose a data packet header with
the context information, or to compose a data packet comprising a quality of service r e
quirement of the application.
Embodiments may further provide the according methods. That is to say, embodiments
may provide a method for a mobile transceiver in a mobile communication system. The
mobile communication system comprises a base station transceiver. The method com
prises extracting context information from an application being run on the mobile transceiver,
context information from an operation system being run on the mobile transceiv
er, or context information from hardware drivers or hardware of the mobile transceiver.
The context information comprises information on a state of the application and/or in
formation on a state of the mobile transceiver. The method further comprises communi
cating data packets with the base station transceiver, wherein the data packets comprise
payload data packets and control data packets. The method further comprises communi
cating payload data packets associated with the application with a data server through the
base station transceiver. The method further comprises providing the context information
to the base station transceiver, wherein the context information is comprised in a payload
data packet or in a control data packet.
Embodiments further provide a method for a base station transceiver in a mobile com
munication system. The mobile communication system further comprises a mobile trans
ceiver. The method comprises receiving control data packets and payload data packets,
wherein the payload data packets are associated with an application being run on the mobile
transceiver. The method further comprises obtaining context information on the data
packets associated with the application from a control data packet or from a payload data
packet. The method further comprises scheduling the mobile transceiver for transmission
of the data packets based on the context information.
Embodiments further provide a method for a data server. The data server communicates
data packets associated with an application being run on a mobile transceiver through a
mobile communication system to the mobile transceiver. The method comprises deriving
context information for the data packets based on classification information received
from a base station transceiver and transmitting the context information along with the
data packets to the mobile communication system.
Embodiments may further provide a mobile transceiver comprising the above described
mobile transceiver apparatus, a base station transceiver comprising the above described
base station transceiver apparatus, a data server comprising the above described data
server apparatus, and/or a mobile communication system comprising the mobile transceiver,
the base station transceiver, and/or the data server.
Embodiments may enable a radio access network to exploit context information from
higher layers. This information about the user, the handheld, and its environment can be
used to efficiently allocate wireless channel resources according to a user's requirements.
Unlike existing signaling for QoS differentiation, the provided context information may
go beyond a small set of QoS classes. By signaling an application-layer flow's unique
utility function in data rate and delay, embodiments may convey the heterogeneous QoS
requirements of modern smartphone applications to the BS. Even different requirements
of the same application may be captured. Further information on the user's location, its
previous or planned mobility path, the application in the foreground of the screen, device
specifics (e.g., screen size) may complement the picture embodiments can provide to the
radio access network.
In embodiments the context-awareness may enable resource allocation concepts that can
decrease the wireless network's traffic load without sacrificing the users' QoS, provide
seamless QoS over multiple cells even to mobile users and increase the data rate and
fairness for mobile users.
Some details on the benefit of long term resource allocations can also be found in H.
Abou-zeid, S. Valentin, and H. Hassanein, "Context- Aware Resource Allocation for Me
dia Streaming: Exploiting Mobility and Application-Layer Predictions", Proc. Capacity
Sharing Workshop, Oct. 201 1, and EP 11306323.4. In other words, embodiments ena
bling context signaling may be a prerequisite to apply powerful new resource allocation
approaches that substantially improve the service for mobile users and serve more users
at equal QoS. Compared to the current QoS signaling at LTE's DLC, embodiments may
provide a larger degree of information to the radio access network. In addition to QoS
classes, utility functions and further context information can be provided.
Compared to Packet Inspection (PI), embodiments may provide context information even
for encrypted data streams. As PI may add high effort on memory and processing power,
embodiments may save some hardware costs. Moreover, embodiments may ensure a low,
constant delay, which may not be the case with PI. Some embodiments may use DLCbased
signaling approaches, while other embodiments may use user-plane signaling,
which may not require standardization. Hence, embodiments may be entirely implement
ed as a handheld-middleware and as software running in the radio access network. This
may enable embodiments to be easily rolled out and updated via existing webinfrastructure
(e.g., Android market or other App stores).
Some embodiments comprise a digital control circuit installed within the apparatus for
performing the method. Such a digital control circuit, e.g. a digital signal processor
(DSP), needs to be programmed accordingly. Hence, yet further embodiments also provide
a computer program having a program code for performing embodiments of the
method, when the computer program is executed on a computer or a digital processor.
Brief description of the Figures
Some embodiments of apparatuses and/or methods will be described in the following by
way of example only, and with reference to the accompanying figures, in which
Fig. 1 shows an embodiment of an apparatus for a mobile transceiver, an apparatus for a
base station transceiver and an apparatus for a data server;
Fig. 2 illustrates an embodiment of a communication network with an embodiment of a
mobile device and an embodiment of a base station;
Fig. 3 illustrates two transactions in an embodiment;
Fig. 4 shows a utility function in an embodiment;
Fig. 5 illustrates embodiments in an EPC;
Fig. 6 illustrates protocol stacks in an embodiment making use of a dedicated control
channel;
Fig. 7 illustrates protocol stacks in an embodiment making use of signaling in a user
plane;
Fig. 8 illustrates protocol stacks in an embodiment making use of a dedicated control
channel and downlink packet classification at a data server;
Fig. 9 illustrates protocol stacks in an embodiment making use of signaling in a data
plane with indirect provision of context information;
Fig. 10 shows a block diagram of a flow chart of an embodiment of a method for a mo
bile transceiver;
Fig. 11 shows a block diagram of a flow chart of an embodiment of a method for a base
station transceiver; and
Fig. 12 shows a block diagram of a flow chart of an embodiment of a method for a data
server.
Description of Embodiments
Various example embodiments will now be described more fully with reference to the
accompanying drawings in which some example embodiments are illustrated. In the fig
ures, the thicknesses of lines, layers and/or regions may be exaggerated for clarity.
Accordingly, while example embodiments are capable of various modifications and a l
ternative forms, embodiments thereof are shown by way of example in the figures and
will herein be described in detail. It should be understood, however, that there is no intent
to limit example embodiments to the particular forms disclosed, but on the contrary, ex
ample embodiments are to cover all modifications, equivalents, and alternatives falling
within the scope of the invention. Like numbers refer to like or similar elements through
out the description of the figures.
It will be understood that when an element is referred to as being "connected" or "cou
pled" to another element, it can be directly connected or coupled to the other element or
intervening elements may be present. In contrast, when an element is referred to as being
"directly connected" or "directly coupled" to another element, there are no intervening
elements present. Other words used to describe the relationship between elements should
be interpreted in a like fashion (e.g., "between" versus "directly between," "adjacent"
versus "directly adjacent," etc.).
The terminology used herein is for the purpose of describing particular embodiments
only and is not intended to be limiting of example embodiments. As used herein, the sin
gular forms "a," "an" and "the" are intended to include the plural forms as well, unless
the context clearly indicates otherwise. It will be further understood that the terms "com
prises," "comprising," "includes" and/or "including," when used herein, specify the pres
ence of stated features, integers, steps, operations, elements and/or components, but do
not preclude the presence or addition of one or more other features, integers, steps, opera
tions, elements, components and/or groups thereof.
Unless otherwise defined, all terms (including technical and scientific terms) used herein
have the same meaning as commonly understood by one of ordinary skill in the art to
which example embodiments belong. It will be further understood that terms, e.g., those
defined in commonly used dictionaries, should be interpreted as having a meaning that is
consistent with their meaning in the context of the relevant art and will not be interpreted
in an idealized or overly formal sense unless expressly so defined herein.
Fig. 1 shows an embodiment of an apparatus 10 for a mobile transceiver 100, an appa
ratus 20 for a base station transceiver 200, and an apparatus 30 for a data server 300. Fig.
1 shows at the top the apparatus 10 for a mobile transceiver 100 for a mobile communi
cation system 500. In the embodiment the mobile communication system 500 system
comprises a base station transceiver 200, which is displayed in the center of Fig. 1. The
base station transceiver 200 is coupled to a data server 300, which is displayed at the bot
tom of Fig. 1, all of which will be detailed subsequently.
The mobile transceiver apparatus 10 comprises means for extracting 12 context infor
mation from an application being run on the mobile transceiver 100, context information
from an operation system being run on the mobile transceiver 100, or context information
from hardware drivers or hardware of the mobile transceiver 100, the context information
comprising information on a state of the application and/or information on a state of the
mobile transceiver 100. The mobile transceiver apparatus 10 further comprises means for
communicating 14 data packets with the base station transceiver 200, wherein the data
packets comprise payload data packets and control data packets. The means for com
municating 14 is operable to communicate payload data packets associated with the application
with a data server 300 through the base station transceiver 200. The mobile
transceiver apparatus further comprises means for providing 16 the context information
to the base station transceiver 200. The context information is comprised in a payload
data packet or in a control data packet. As can be seen from Fig. 1 the means for extract
ing 12, the means for communicating 14, and the means for providing 16 are coupled to
each other.
The communication network in the present embodiment corresponds to a 3rd Generation
Partnership Project Long Term Evolution (3GPP LTE) system with an Evolved Packet
Core (EPC).
Fig. 1 further shows an embodiment of an apparatus 20 for the base station transceiver
200. The base station transceiver apparatus 20 comprises means for receiving 22 control
data packets and payload data packets. The payload data packets are associated with an
application being run on the mobile transceiver 100. The base station transceiver appa
ratus further comprises means for obtaining 24 context information associated with the
application from a control data packet or from a payload data packet and means for
scheduling 26 the mobile transceiver 100 for transmission of the data packets based on
the context information. As shown in Fig. 1 the means for receiving 22, the means for
obtaining 24, and the means for scheduling 26 are coupled to each other.
Moreover, Fig. 1 illustrates an embodiment of an apparatus 30 for the data server 300,
which communicates data packets associated with the application being run on a mobile
transceiver 100 through the mobile communication system 500 to the mobile transceiver
100. The data server apparatus 30 comprises means 32 for deriving context information
for the data packets based on classification information received from the base station
transceiver 200 and means 34 for transmitting the context information along with the
data packets to the mobile communication system 500. The means for deriving 32 and
the means for transmitting 34 are coupled to each other.
In the following an embodiment for cross-layer signaling of context information for the
example of a 3GPP LTE cellular radio access network 500 will be described. Fig. 2 illu s
trates the communication network 500 with the embodiment of the mobile device 100
and the embodiment of the base station 200. Fig. 2 illustrates a Context-Aware Resource
Allocation system architecture, with the respective components of the Context-Aware
Resource Allocation (CARA) framework, more details can be found in EP 11305685.
Fig. 2 shows the relevant components for signaling.
In the following description of embodiments it is assumed that the context information
comprises one or more elements of the group of information on a quality of service r e
quirement of the application, priority information of the data packets associated with the
application, information on a unity of a plurality of the data packets of the application,
information on a load demand of the application, information on a delay or error rate
constraint of the application, information on a window state, information on a memory
consumption, information on a processor usage of the application running on the mobile
transceiver 100, information on a current location, speed, orientation of the mobile trans
ceiver 100, mapping information between one or more data packets and a scheduling
queue, or a distance of the mobile transceiver 100 to another mobile transceiver.
On the side of the mobile transceiver 100 Fig. 2 illustrates several applications (Apps)
102, which run on the mobile terminal. The applications 102 interact with platform li
braries 104, which in turn interact with the operating system 106 of the mobile transceiver
100. The applications 102, the platform libraries 104, and/or the operating system 106
may provide context information to the mobile transceiver apparatus 10, which is imple
mented as CARA transaction manager 10 with context signaling. The operating system
106 as well as the transaction manager 10 interacts with the wireless network 108, the
lower layers thereof, respectively. In the present embodiment the wireless network 108
may provide transport layer services in terms of LTE layer 2 or IP-services.
The base station 200 comprises the base station transceiver apparatus 20, which is im
plemented as CARA transaction scheduler 20 with context usage and/or signaling. More
over, the transaction scheduler 20 interacts with scheduling queues 202, in which data
buffers for different transactions are located. The transaction scheduler 20 as well as the
scheduling queues 202 interact with the wireless network 204, the lower layers thereof,
respectively. Similar to mobile transceiver 100 the wireless network 204 may provide
transport layer services in terms of LTE layer 2 or IP to the transaction scheduler 20 and
the scheduling queues 202. The scheduling queues 202 communicate or interact with the
Internet 300, which in the present embodiment also comprises the data server 300. As
can be seen from Fig. 2, the two wireless network entities 108 and 204 exchange user
data, i.e. payload data packets, and signaling data, i.e. control data packets. Between the
transaction manager 10 on the mobile transceiver side 100 and the transaction scheduler
20 on the base station transceiver 200 side a context protocol is established, e.g. a trans
action protocol.
In the present embodiment transactions can be considered as a data unit or data packet
that represents application-layer data flows at the DLC. A transaction may include all
DLC frames from the user's first request at the application layer (e.g., the load of a webpage)
until the result is delivered to the user (i.e., all elements included in that web-page).
Transactions may include information on the application's QoS requirements and a map
ping of the link-layer frames to the transaction. This information is collected in a
handheld agent, i.e. the CARA transaction manager 10 in Fig. 2 . In many cases, the
transaction manager 10 can extract the context information on requirements from appli
cations, platform libraries (e.g., Android Application Programming Interface, API) or the
operating system (e.g., Linux Kernel). Identification of downlink data packets belonging
to a transaction can be often be accomplished with a 5-tuple in the IP header and the
stream positions of the transport layer denoting "start" and "end".
On the base station transceiver 200 side, the means for scheduling 26 is operable to determine
a transmission sequence for a plurality of transactions. The plurality of transac
tions refers to a plurality of applications being run by one or more mobile transceivers
100. Hence a transaction corresponds to a plurality of data packets for which the context
information indicates unity. This is also indicated in Fig. 2 by the multiple scheduling
queues 202, each of which may hold or buffer payload data packets for one transmission.
The transaction manager 10 can extract this information from the network socket in use
by the regarded application. An example for using transactions to map application data to
flows is given in Fig. 3 . Fig. 3 illustrates two transactions, "transaction 1" and "transac
tion 2" in an embodiment. Moreover, Fig. 3 shows different UDP and Transmission Control
Protocol (TCP) connections "UDP 1", "TCP 1", "TCP 2", "TCP 3". Depending on
the application, multiple transport layer connections (e.g. using TCP may belong to the
same transaction (e.g. Transaction 1) or one connection may contain multiple transactions
(e.g., TCP1). Each transport layer session includes IP packets and DLC frames that
are scheduled at the BS 200.
A transaction's QoS requirement can be expressed by a utility function. For example, for
a transaction belonging to a web-surfing session inside a web-browser, the user is satis
fied when a web-page is shortly shown after requesting it. This can be expressed as a
delay-dependent utility function as shown in Fig. 4, which states the transaction's utility
in terms of its finish time, i.e. the time when the user can see the result. The CARA
transaction scheduler can leverage such context information to substantially increase the
QoS for all users per cell, cf. M. Proebster et al. Fig. 4 illustrates a utility function lift)
versus time t . The utility function expresses a user's satisfaction for a varying communi
cation delay t . At a starting time tsta rt the utility function is at its maximum value, which
is normalized to 1 in Fig. 4 . After an expectation time, i.e. a time, which a user may ex
pect to wait for the transaction, the lift) has decreased only a little bit, but not significantly.
After the expectation time lift) starts decreasing faster until it reaches its maximum
decreasing rate after inflection time tinfl. An order of a sequence of transactions to be
scheduled can then be based on their respective utility functions.
The transmission sequence can, for example, be determined from an iteration of multiple
different sequences of transactions. The multiple different sequences correspond to dif
ferent permutations of the plurality of transactions. In the base station transceiver appa
ratus 20 the means for scheduling 26 is operable to determine the sum utility function for
each of the multiple different sequences and is further operable to select the transmission
sequence from the multiple different sequences corresponding to a maximum sum of the
utility functions. The means for scheduling 26 can be further operable to modify the
transmission sequence based on a supportable data rate for each transaction, which can
be determined through measurements and according reports received from the mobile
transceiver 100, e.g. in terms of CQI.
Components of the 3GPP EPC for signaling transaction information as well as the signal
ing paths are shown in Fig. 5 . Fig. 5 shows a mobile transceiver or UE 100, a base station
transceiver or eNodeB 200, a Home Subscriber Server (HSS) 210, a Mobility Management
Entity (MME) 212, a Serving-GateWay (S-GW) 400 and a PDN-GW 300, which is
connected to the Internet 310. As Fig. 5 further shows, the eNodeB 200 communicates
with the S-GW 400 using the SI -User plane (Sl-U) protocol. The eNodeB 200 further
uses the Sl-MME protocol to communicate with the MME 212. Moreover, the PDN-GW
300 communicates with the S-GW 400 using the S5/S8 protocols. The HSS 210 com
municates with the MME 212 using the S6a protocol and the MME 212 uses the Sl l
protocol to communicate with the S-GW 400. More details on these components and
protocols can be found in the 3GPP specifications. In the following, HSS 210 and MME
212 are neglected as they are not required for signaling.
The arrows at the bottom of Fig. 5 illustrate signaling paths of embodiments, which will
be detailed subsequently. The short arrow having the circled 1 and 2 above represents the
signaling paths of the embodiments described in Figs. 6 and 7, which use direct commu
nication between the UE 100 and the eNB 200. The long arrow going from the UE 100 to
the PDN-GW 300 and back to the eNB 200 having the circled 3 and 4 underneath repre
sents the signaling paths of the embodiments described in Figs. 8 and 9, which use indi
rect communication from the UE 100 to the eNB 200 via the PDN-GW 300.
In the following a first embodiment will be described, which uses direct control-plane
signaling. Fig. 6 illustrates the protocol stacks in this embodiment. On the UE 100 side
Fig. 6 depicts layer 1 or PHY, layer 2 as MAC and RLC, and a transaction protocol "Tr-
Protocol" on top of RLC.
Hence, in this embodiment the mobile transceiver apparatus 10 further comprises means
for composing a transaction data packet as part of the transaction protocol "Tr-Protocol".
The transaction data packet comprises the context information. In the embodiment the
UE 100 uses a dedicated control channel between the UE 100 and the eNB 200. Fig. 6
shows the layered stacks on each device. Lines between peer entities indicate a direct
communication between those entities; higher layer entities use the services of lower
layer entities. The transaction information is directly transported with a signaling proto
col above the RLC layer as no addressing or routing is required. The transaction protocol
contains QoS requirements and classification rules of the transactions. The eNB 200 receives
and processes all protocol information. The context information is communicated
to the base station transceiver 200 using a link layer protocol control data packet.
Hence, the means for obtaining 24 at the eNodeB 200 is operable to obtain the context
information from the transaction data packet as part of the transaction protocol. The
transaction data packet or the context information is received from the mobile transceiver
100 using a link layer protocol control data packet. In the present embodiment the eNB
200 classifies downlink data packets, i.e. it may perform header inspection and queue
packets of different transactions separately, cf. indication 202 in Fig. 2 . The QoS requirement
can be directly forwarded to the MAC layer scheduler 20 within the eNB 200.
In the following another embodiment will be described, which makes use of direct userplane
signaling. Fig. 7 illustrates protocol stacks in an embodiment making use of signal
ing in a user or data plane between a UE 100 and an eNB 200. Compared to the previous
embodiment shown in Fig. 6 the transaction protocol uses UDP, with underlying IP,
PDCP, and the lower layers as described above. The signaling information is transported
from the UE 100 to the eNB 200 at the application layer. The UE 100 can address the
base station 200 via IP any-cast, as the base station 200 is the gateway to the network
from the perspective of the UEIOO. As signaling information usually does not extend
over multiple IP packets and RLC mechanisms can prohibit packet losses, when being
used in acknowledged mode, between UE 100 and eNB 200, it is sufficient to use a con
nectionless User Datagram Protocol (UDP) stream for signaling. Optionally, a simple
acknowledgement-mechanism from the eNB could be devised. Hence, in the present em
bodiment the transaction data packet is communicated to the base station transceiver 200
using an any-cast payload data packet. The any-cast payload data packet can correspond
to an IP-packet with a TOS indication or a UDP-packet with a destination port indication.
For the classification the eNB 200 has the same capabilities as in the previous embodi
ment.
Another embodiment using indirect control-plane signaling will be described subsequent
ly. Fig. 8 illustrates protocol stacks in an embodiment making use of a dedicated control
channel and downlink packet classification in a data server 300, which is implemented as
PDN-GW 300. In this embodiment, the transaction signaling protocol is transported to
the e B 200 as in the embodiment described with Fig. 6 . The e B 200 then forwards the
transactions' QoS requirements to the MAC scheduler 20 and classification information
via UDP to the PDN-GW 300 using a separate protocol. The S-GW 400 just serves as
relay in this embodiment. Towards the S-GW 400 and between the S-GW 400 and the
PDN-GW 300 the lower layers are labeled as layer 1 (LI) and layer 2 (L2). As indicated
in Fig. 8 by the "*" a modified transaction protocol "Tr-P*" is used to communicate the
context information as classification information from the eNB 200 to the PDN-GW 300
via the S-GW 400. The classification information can correspond to the QoS settings or
requirements for a scheduler queue or a transaction context at the scheduler 20 of the
base station transceiver 200. At the base station transceiver 200 the context information
is hence received from the data server 300, which is provided with classification infor
mation from the base station transceiver 200.
The PDN-GW 300 is foreseen in the standards to be able to perform DPI. Thus, it can
classify downlink data packets according to the signaled information. After the PDN-GW
300 has classified the data packets, it informs the eNB 200 about the classification. As
EPC employs a flat IP architecture, Differentiated Services Field Codepoints (DSCP) in
the IP header can be used to differentiate between transactions. This way, 64 transactions
can be differentiated for a single UE at a time in IPv4. With IPv6, even more transactions
(220-1) can be differentiated by the flow label. The context information can hence corre
spond to a tag in a data packet received from the data server 300.
Another embodiment uses indirect user-plane signaling. Fig. 9 illustrates protocol stacks
in an embodiment making use of signaling in a data plane with indirect provision of con
text information. Fig. 9 shows the signaling between UE 100 and PDN-GW 300 via the
data plane. The eNB 200 uses the General packet radio service Tunneling Protocol in the
User-plane (GTP-U) to forward the respective data packet to the S-GW 400, which also
uses GTP-U to forward the same to the PDN-GW 300. As it is also indicated in Fig. 9 the
eNB 200 and the S-GW 400 are considered as relays. The protocol stacks at the respec
tive components are similar to those described above.
Packet classification is carried out at the PDN-GW 300, which also forwards transaction
requirements to the eNB 200. The embodiments shown in Fig. 9 employ application lay
er transport for signaling from the UE 100 to the PDN-GW 300. This can be accom
plished by IP any-cast or unicast (in case the IP-address of the PDN-GW 300 is known),
in line with the above description. The transaction data packet is received at the PDNGW
300 from the mobile transceiver 100 using an any-cast or a unicast payload data
packet. The PDN-GW 300 signals the QoS requirements of the transactions back to the
eNB 200 over a separate protocol. In some embodiments multiple PDN-GWs may serve
the mobile transceiver 100. In this case an any-cast payload data packet can be received
by one PDN-GW, which can then inform the others, or, although this may then rather
refer to a multi-cast payload data packet, the multiple PDN-GWs may all receive the
multicast (any-cast) data packet. In this embodiment, classification is performed in the
PDN-GW 300 as in the embodiment described with Fig. 8 . In embodiments the transac
tion data packet can be communicated to the data server 300 using a unicast payload data
packet, e.g. the UE 100 addresses an IP-packet directly to the PDN-GW 300.
Hence, the data server apparatus 30 comprises means for composing a data packet, e.g. in
line with the Tr-P*. The data packet comprises application data packets and a tag with
mapping information for the data packet to a scheduling queue at the base station transceiver
200. A transaction data packet can be composed, which comprises application data
packets and the context information. In some embodiments a data packet header with the
context information or a data packet comprising a quality of service requirement of the
application can be composed.
The embodiments described with Figs. 6 and 7 assume that the eNB 200 is able to inspect
at least the IP and transport protocol headers for classifying downlink data packets.
However, in an LTE system this may not be the case as data can be tunneled (e. g . via the
tunneling protocol GTP-U) and/or encrypted between the PDN-GW 300 and UE 100.
Therefore the embodiments described with Figs. 8 and 9 may have the advantage that
they would allow for lower processing capabilities at the eNB 200.
The mobile device 100 may not differentiate between the embodiments of Figs. 7 and 9,
neither between the embodiment of Figs. 6 and 8 . For the mobile device 100 only the
type of signaling is known.
In the following an exemplary embodiment of a transaction signaling protocol is de
scribed. The following protocol description is a simplified, text-based realization of the
signaling for CARA. Signaling is sent (unidirectional) by the UE 100 to the e B 200 (or
PDN-GW 300) as described above. The protocol is text based and encoding is ANSI\_
X3.4-1968 (7 bit ASCII). Lines are delimited by "\n" (ASCII code 0x0A), fields are
delimited by a single whitespace. Each transaction is formulated by a sequence of lines.
The first line starts with the keyword Transaction". Each following line formulates one
traffic chunk, usually a section of a transport layer connection. The signaling for each
transaction is sent as a single UDP datagram. The destination address for these datagrams
is configured manually. The destination port is 1024 and the source IP address is the IP
address of each UE 100 and the source port is insignificant. The client can resend the
transaction specification whenever requirements, chunks or size prediction have changed.
These resends may not be incremental. That means that when resending, all chunks may
be repeated. Uplink and downlink chunks can be identified using a routing table, therefore
there is no need to specify it explicitly. Depending on the application media, a trans
action can be of the types:
FINISH: The time of completion of the transmission is important (the earlier, the
better); e.g. Web-surfing
• REALTIME: Each packet has an individual deadline; e.g. voice-calls / live-TV
STREAMING: Buffering of content is possible, however, the transmission should
not fall below the play-out curve; e.g. buffered video streaming in YouTube
An example transaction definition looks as follows:
Transaction web42 FINISH 2300
TCP 10.0.0.10 1025 2.3.4.5 80 0 1200
TCP 2.3.4.5 80 10.0.0.10 1025 0 17000
TCP 2.3.4.5 80 10.0.0.10 1026 0 17000
The Extended Backus-Naur-Form (EBNF) for this protocol is as follows:
Message Transaction
Transaction "Transaction" Name Requirement "\n" {Chunk}
Requirement "FINISH" Finish-Time | "REALTIME" Deadline | "STREAMING"
Bandwidth
Chunk Filter Start Stop "\n"
Filter "TCP" SrcIP SrcPort DstIP DstPort | "UDP" SrcIP SrcPort DstIP DstPort
Name An arbitrary name for the transaction (could also be an ID-number)
SrcIP, DstIP text representation of IPv4/IPv6 address
SrcPort, DstPort decimal
Start, Stop These parameters allow to specify, which bytes of this transport layer con
nection belong the transaction. In case the length is not known, a predic
tion has to be specified by the client.
Finish-Time in ms relative to the time the signaling message is received
Deadline in ms per packet
Bandwidth in bit/s
This is a simple example. Instead of scalar requirements (Finish- Time, Deadline, Band
width), also complete utility curves, as described above, could be signaled in embodi
ments. E.g. with function type and relevant parameters or as a table of (x,y)-values.
In the following an exemplary use case of an embodiment will be described. A user
clicks on a link in a web-browser. The mobile device 100 initiates a TCP connection with
the web server 300 and signals a new transaction to the base station 200 containing the
requirement and the IP 5-tuple to be in use. When the first downlink DLC frame arrives
at the BS 200, it can use the signaled classification to map the frame to the transaction
and its requirements. After connection setup, the mobile device 100 sends a HTTP r e
quest to the server 300. As soon as the HTTP response header arrives at the mobile de
vice 100, it can send a transaction update containing the predicted content size to the BS
200. Studies have shown that, for a typical Internet traffic mix, the signaling overhead of
this signaling protocol is only 0.2% of the downlink data traffic.
Fig. 10 shows a block diagram of a flow chart of an embodiment of a method for a mobile
transceiver 100 in a mobile communication system 500. The mobile communication
500 system further comprises a base station transceiver 200. The method comprising a
step of extracting 712 context information from an application being run on the mobile
transceiver 100, context information from an operation system being run on the mobile
transceiver 100, or context information from hardware drivers or hardware of the mobile
transceiver 100, the context information comprising information on a state of the applica
tion and/or information on a state of the mobile transceiver 100. The method further
comprises a step of communicating 714 data packets with the base station transceiver
200, wherein the data packets comprise payload data packets and control data packets.
The method further comprises a step of communicating 715 payload data packets associated
with the application with a da-ta server 300 through the base station transceiver 200
and a step of providing 716 the context information to the base station transceiver 200,
wherein the context information is comprised in a payload data packet or in a control
data packet.
Fig. 11 shows a block diagram of a flow chart of an embodiment of a method for a base
station transceiver 200 in a mobile communication system 500. The mobile communica
tion system 500 further comprises a mobile transceiver 100. The method comprises a step
of receiving 722 control data packets and payload data packets, wherein the payload data
packets are associated with an application being run on the mobile transceiver 100. The
method comprises a further step of obtaining 724 context information on the data packets
associated with the application from a control data packet or from a payload data packet.
The method comprises a further step of scheduling 726 the mobile transceiver 100 for
transmission of the data packets based on the context information.
Fig. 12 shows a block diagram of a flow chart of an embodiment of a method for a data
server 300, which communicates data packets associated with an application being run
on a mobile transceiver 100 through a mobile communication system 500 to the mobile
transceiver 100. The method comprises a step of deriving 732 context information for the
data packets based on classification information received from a base station transceiver
200 and a step of transmitting 734 the context information along with the data packets to
the mobile communication system 500.
The description and drawings merely illustrate the principles of the invention. It will thus
be appreciated that those skilled in the art will be able to devise various arrangements
that, although not explicitly described or shown herein, embody the principles of the in
vention and are included within its spirit and scope. Furthermore, all examples recited
herein are principally intended expressly to be only for pedagogical purposes to aid the
reader in understanding the principles of the invention and the concepts contributed by
the inventor(s) to furthering the art, and are to be construed as being without limitation to
such specifically recited examples and conditions. Moreover, all statements herein recit
ing principles, aspects, and embodiments of the invention, as well as specific examples
thereof, are intended to encompass equivalents thereof.
Functional blocks denoted as "means for ..." (performing a certain function) shall be
understood as functional blocks comprising circuitry that is operable for performing a
certain function, respectively. Hence, a "means for s.th." may as well be understood as a
"means being operable or suited for s.th.". A means being operable for performing a cer
tain function does, hence, not imply that such means necessarily is performing said func
tion (at a given time instant).
The functions of the various elements shown in the Figures, including any functional
blocks labeled as "means", "means for extracting", "means for communicating", "means
for providing" , "means for receiving" , "means for obtaining" , "means for scheduling" ,
"means for deriving" , "means for transmitting", etc., may be provided through the use of
dedicated hardware, as e.g. a processor, "an extractor", "a communicator", "a provider",
"a receiver", "an obtainer", "a scheduler ", "a deriver", "a transmitter", etc., as well as
hardware capable of executing software in association with appropriate software. When
provided by a processor, the functions may be provided by a single dedicated processor,
by a single shared processor, or by a plurality of individual processors, some of which
may be shared. Moreover, explicit use of the term "processor" or "controller" should not
be construed to refer exclusively to hardware capable of executing software, and may
implicitly include, without limitation, digital signal processor (DSP) hardware, network
processor, application specific integrated circuit (ASIC), field programmable gate array
(FPGA), read only memory (ROM) for storing software, random access memory (RAM),
and non-volatile storage. Other hardware, conventional and/or custom, may also be in
cluded.
It should be appreciated by those skilled in the art that any block diagrams herein represent
conceptual views of illustrative circuitry embodying the principles of the invention.
Similarly, it will be appreciated that any flow charts, flow diagrams, state transition dia
grams, pseudo code, and the like represent various processes which may be substantially
represented in computer readable medium and so executed by a computer or processor,
whether or not such computer or processor is explicitly shown.
Furthermore, the following claims are hereby incorporated into the Detailed Description,
where each claim may stand on its own as a separate embodiment. While each claim may
stand on its own as a separate embodiment, it is to be noted that - although a dependent
claim may refer in the claims to a specific combination with one or more other claims -
other embodiments may also include a combination of the dependent claim with the sub
ject matter of each other dependent claim. Such combinations are proposed herein unless
it is stated that a specific combination is not intended. Furthermore, it is intended to in
clude also features of a claim to any other independent claim even if this claim is not
directly made dependent to the independent claim.
It is further to be noted that methods disclosed in the specification or in the claims may
be implemented by a device having means for performing each of the respective steps of
these methods.
Further, it is to be understood that the disclosure of multiple steps or functions disclosed
in the specification or claims may not be construed as to be within the specific order.
Therefore, the disclosure of multiple steps or functions will not limit these to a particular
order unless such steps or functions are not interchangeable for technical reasons. Fur
thermore, in some embodiments a single step may include or may be broken into mult i
ple sub steps. Such sub steps may be included and part of the disclosure of this single
step unless explicitly excluded.
Claims
1. An apparatus (10) for a mobile transceiver (100) for a mobile communication system
(500), the mobile communication (500) system comprising a base station transceiver
(200), the apparatus (10) comprising
means for extracting (12) context information from an application being run on the
mobile transceiver (100), context information from an operation system being run on
the mobile transceiver (100), or context information from hardware drivers or hard
ware of the mobile transceiver (100), the context information comprising information
on a state of the application and/or information on a state of the mobile trans
ceiver (100);
means for communicating (14) data packets with the base station transceiver (200),
wherein the data packets comprise payload data packets and control data packets,
and wherein the means for communicating (14) is operable to communicate payload
data packets associated with the application with a data server (300) through the base
station transceiver (200); and
means for providing (16) the context information to the base station transceiver
(200), wherein the context information is comprised in a payload data packet or in a
control data packet.
2 . The apparatus (10) of claim 1, wherein the context information comprises one or
more elements of the group of information on a quality of service requirement of the
application, priority information of the data packets associated with the application,
information on a unity of a plurality of the data packets of the application, infor
mation on a load demand of the application, information on a delay or error rate constraint
of the application, information on a window state, information on a memory
consumption, information on a processor usage of the application running on the
mobile transceiver (100), information on a current location, speed, orientation of the
mobile transceiver (100), or a distance of the mobile transceiver (100) to another
mobile transceiver.
The apparatus (10) of claim 1, further comprising means for composing a transaction
data packet as part of a transaction protocol, the transaction data packet comprising
the context information, wherein the transaction data packet is communicated to the
base station transceiver (200) using an any-cast payload data packet, wherein the
transaction data packet is communicated to the data server (300) using a unicast payload
data packet, or wherein the transaction data packet or the context information is
communicated to the base station transceiver (200) using a Link Layer protocol con
trol data packet.
An apparatus (20) for a base station transceiver (200) for a mobile communication
system (500), the mobile communication system (500) further comprising a mobile
transceiver (100), the apparatus (20) comprising
means for receiving (22) control data packets and payload data packets, wherein the
payload data packets are associated with an application being run on the mobile
transceiver (100);
means for obtaining (24) context information associated with the application from a
control data packet or from a payload data packet; and
means for scheduling (26) the mobile transceiver (100) for transmission of the data
packets based on the context information.
The apparatus (20) of claim 4, wherein the means for obtaining (24) is operable to
obtain the context information from a transaction data packet as part of a transaction
protocol, wherein the transaction data packet is received from the mobile transceiver
(100) using an any-cast payload data packet, wherein the transaction data packet is
received from a data server (300) using a unicast payload data packet, wherein the
transaction data packet or the context information is received from the mobile trans
ceiver (100) using a Link Layer protocol control data packet, or wherein the context
information is received from the data server (300), which is provided with classifica
tion information from the base station transceiver (200), wherein the context infor
mation corresponds to a tag in a data packet received from the data server (300).
The apparatus (20) of claim 4, wherein the means for scheduling (26) is operable to
determine a transmission sequence for a plurality of transactions, the plurality of
transactions referring to a plurality of applications being run by one or more mobile
transceivers (100), a transaction corresponding to a plurality of data packets for
which the context information indicates unity, an order of the sequence of transac
tions being based on a utility function, the utility function depending on a comple
tion time of a transaction, which is determined based on the context information,
and/or
wherein the context information comprises one or more elements of the group of in
formation on a quality of service requirement of the application, priority information
of the data packets associated with the application, information on a unity of a plu
rality of the data packets of the application, information on a load demand of the ap
plication, information on a delay or error rate constraint of the application, infor
mation on a window state, information on a memory consumption, information on a
processor usage of the application running on the mobile transceiver (100), infor
mation on a current location, speed, orientation of the mobile transceiver (100),
mapping information between one or more data packets and a scheduling queue, or a
distance of the mobile transceiver (100) to another mobile transceiver.
The apparatus (20) of claim 6, wherein the transmission sequence is determined from
an iteration of multiple different sequences of transactions, where the multiple dif
ferent sequences correspond to different permutations of the plurality of transactions,
wherein the means for scheduling (26) is operable to determine the utility function
for each of the multiple different sequences and is further operable to select the
transmission sequence from the multiple different sequences corresponding to a
maximum of the utility function, and/or wherein the means for scheduling (26) is
operable to further modify the transmission sequence based on the supportable data
rate for each transaction.
An apparatus (30) for a data server (300), the data server (300) communicating data
packets associated with an application being run on a mobile transceiver (100)
through a mobile communication system (500) to the mobile transceiver (100), the
apparatus (30) comprising
means for deriving (32) context information for the data packets based on classifica
tion information received from a base station transceiver (200); and
means for transmitting (34) the context information along with the data packets to
the mobile communication system (500).
9 . The apparatus (30) of claim 8, wherein the context information comprises one or
more elements of the group of information on a quality of service requirement of the
application, priority information of the data packets associated with the application,
information on a unity of a plurality of the data packets of the application, infor
mation on a load demand of the application, information on a delay or error rate constraint
of the application, information on a window state, information on a memory
consumption, information on a processor usage of the application running on the
mobile transceiver (100), information on a current location, speed, orientation of the
mobile transceiver (100), mapping information between one or more data packets
and a scheduling queue, or a distance of the mobile transceiver (100) to another mobile
transceiver and wherein the means for deriving (32) is operable to extract the
context information from a unicast payload data packet received from the mobile
transceiver (100) or from a unicast payload data packet from the base station trans
ceiver (200).
10. The apparatus (30) of claim 8, further comprising means for composing a data packet,
the data packet comprising application data packets and a tag with mapping in
formation for the data packet to a scheduling queue at the base station transceiver
(200), for composing a transaction data packet, the transaction data packet compris
ing application data packets and the context information, for composing a data pack
et header with the context information, or for composing a data packet comprising a
quality of service requirement of the application.
11. A method for a mobile transceiver (100) in a mobile communication system (500),
the mobile communication (500) system further comprising a base station transceiv
er (200), the method comprising
extracting (712) context information from an application being run on the mobile
transceiver (100), context information from an operation system being run on the
mobile transceiver (100), or context information from hardware drivers or hardware
of the mobile transceiver (100), the context information comprising information on a
state of the application and/or information on a state of the mobile transceiver (100);
communicating (714) data packets with the base station transceiver (200), wherein
the data packets comprise payload data packets and control data packets;
communicating (715) payload data packets associated with the application with a da
ta server (300) through the base station transceiver (200); and
providing (716) the context information to the base station transceiver (200), where
in the context information is comprised in a payload data packet or in a control data
packet.
12. A method for a base station transceiver (200) in a mobile communication system
(500), the mobile communication system (500) further comprising a mobile trans
ceiver (100), the method comprising
receiving (722) control data packets and payload data packets, wherein the payload
data packets are associated with an application being run on the mobile transceiver
(100);
obtaining (724) context information on the data packets associated with the applica
tion from a control data packet or from a payload data packet; and
scheduling (726) the mobile transceiver (100) for transmission of the data packets
based on the context information.
13. A method for a data server (300), the data server (300) communicating data packets
associated with an application being run on a mobile transceiver (100) through a
mobile communication system (500) to the mobile transceiver (100), the method
comprising
deriving (732) context information for the data packets based on classification in
formation received from a base station transceiver (200); and
transmitting (734) the context information along with the data packets to the mobile
communication system (500).
A mobile transceiver (100) comprising the apparatus (10) of claim 1, a base station
transceiver (200) comprising the apparatus (20) of claim 4, a data server (300) com
prising the apparatus (30) of claim 8, and/or a mobile communication system (500)
comprising the mobile transceiver (100), the base station transceiver (200), and/or
the data server (300).
A computer program having a program code for performing one of the methods of
claims 12, 13 or 14, when the computer program is executed on a computer or pro
cessor.