Patent Application
20140106770
Embodiments of the present invention relate to communication systems, more particularly but not exclusively to packet data transmission in mobile communication systems.
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 '10), 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 generations, 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 network 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 demands 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 Conference on Communications (ICC), June 2011, or in EP11305685.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 Networks”, EURASIP Journal on Wireless Communications and Networking (WCN), submitted for review October 2011.
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 information 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 Partnership Project (3GPP) Technical Specification (TS) 36.300 V11.0.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Overall description”, December 2011. 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 information 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) requirements 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, December 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 Classification 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 information 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 communication system, i.e. embodiments may provide said apparatus to be operated by or comprised in a mobile transceiver. In the following, the apparatus will also be referred to as mobile station transceiver apparatus. Moreover, the terms mobile communication network and mobile communication system will be used synonymously. The mobile communication system may, for example, correspond to one of the 3GPP-standardized mobile communication networks, as e.g. Long Term Evolution (LTE), an LTE-Advanced (LTE-A), a Universal Mobile Telecommunication System (UMTS) or a UMTS Terrestrial 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 Frequency Division Multiple Access (OFDMA) network, etc., or mobile communication networks with different standards, e.g. Worldwide Interoperability for Microwave Access (WIMAX).
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 enables 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 (eNB), a Base Transceiver Station (BTS), an access point, a remote radio head, a transmission point etc., which may be further subdivided in a remote 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 embodiments 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 multiple 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 communicating 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 Public 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 control 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 transceiver for, or in, a mobile communication system, which further comprises a mobile transceiver. 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 receiving 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 transmission 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 displayed 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 information 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 context information of the other application may indicate it is in background. Therefore, embodiments 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 prioritized. 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 determining a state of the application, may be extracted from a window manager of the operation 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 displaying 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 referring to the image should be transmitted to the mobile transceiver in an adequate time interval. 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 transceiver can provide the context information, e.g. as state information of an application (foreground/background, active/suspended, standby, etc.). Another option is that the application itself provides the context information.
Hence, in line with the above description the base station transceiver apparatus may receive 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 any-cast indication for the base station transceiver. The indication may, for example, be comprised 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 composing 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 information 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 user-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 classification 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 information 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 plurality of transactions may refer to a plurality of applications being run by one or more mobile 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 2 s. In other words, full user satisfaction may be achieved when the full content of the web page is transmitted in less than 2 s. Otherwise, the user satisfaction and therewith the utility function will degrade. The sequence of the transactions can be determined in different ways in embodiments. In some embodiments the transmission sequence 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 maximum 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 optimization 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 throughput criteria may be considered.
Accordingly, embodiments provide an apparatus for, or in, a data server, i.e. embodiments 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 transceiver through a mobile communication system to the mobile transceiver, in line with the above description. The data server apparatus comprises means for deriving context information 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 communication system. The means for transmitting may correspond to a transmitter, e.g. an interface 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 application 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 requirement 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 comprises 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 method further comprises communicating data packets with the base station transceiver, wherein the data packets comprise payload data packets and control data packets. The method further comprises communicating 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 communication system. The mobile communication system further comprises a mobile transceiver. 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 Media Streaming: Exploiting Mobility and Application-Layer Predictions”, Proc. Capacity Sharing Workshop, October 2011, and EP 11306323.4. In other words, embodiments enabling 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 DLC-based signaling approaches, while other embodiments may use user-plane signaling, which may not require standardization. Hence, embodiments may be entirely implemented 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 web-infrastructure (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.
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
Various example embodiments will now be described more fully with reference to the accompanying drawings in which some example embodiments are illustrated. In the figures, the thicknesses of lines, layers and/or regions may be exaggerated for clarity.
Accordingly, while example embodiments are capable of various modifications and alternative 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, example embodiments are to cover all modifications, equivalents, and alternatives falling within the scope of the invention. Like numbers refer to like or similar elements throughout the description of the figures.
It will be understood that when an element is referred to as being “connected” or “coupled” 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 singular 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 “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence 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, operations, 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.
The mobile transceiver apparatus 10 comprises 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 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 communicating 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
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).
Moreover,
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.
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 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, 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.
On the side of the mobile transceiver 100
The base station 200 comprises the base station transceiver apparatus 20, which is implemented as CARA transaction scheduler 20 with context usage and/or signaling. Moreover, 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
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 web-page) 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 mapping of the link-layer frames to the transaction. This information is collected in a handheld agent, i.e. the CARA transaction manager 10 in
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 transactions 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
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
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 satisfied when a web-page is shortly shown after requesting it. This can be expressed as a delay-dependent utility function as shown in
The transmission sequence can, for example, be determined from an iteration of multiple different sequences of transactions. The multiple different sequences correspond to different permutations of the plurality of transactions. In the base station transceiver apparatus 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 signaling paths are shown in
The arrows at the bottom of
In the following a first embodiment will be described, which uses direct control-plane signaling.
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.
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
In the following another embodiment will be described, which makes use of direct user-plane signaling.
Another embodiment using indirect control-plane signaling will be described subsequently.
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 correspond to a tag in a data packet received from the data server 300.
Another embodiment uses indirect user-plane signaling.
Packet classification is carried out at the PDN-GW 300, which also forwards transaction requirements to the eNB 200. The embodiments shown in
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
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
The mobile device 100 may not differentiate between the embodiments of
In the following an exemplary embodiment of a transaction signaling protocol is described. 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 eNB 200 (or PDN-GW 300) as described above. The protocol is text based and encoding is AN-SI\_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 transaction can be of the types:
An example transaction definition looks as follows:
Transaction web42 FINISH 2300
The Extended Backus-Naur-Form (EBNF) for this protocol is as follows:
This is a simple example. Instead of scalar requirements (Finish-Time, Deadline, Bandwidth), also complete utility curves, as described above, could be signaled in embodiments. 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 request to the server 300. As soon as the HTTP response header arrives at the mobile device 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.
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 invention 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 reciting 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 certain function does, hence, not imply that such means necessarily is performing said function (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 included.
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 diagrams, 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 subject 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 include 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. Furthermore, in some embodiments a single step may include or may be broken into multiple sub steps. Such sub steps may be included and part of the disclosure of this single step unless explicitly excluded.
| Number | Date | Country | Kind |
|---|---|---|---|
| 11305685.7 | Jun 2011 | EP | regional |
| 12305546.9 | May 2012 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2012/060369 | 6/1/2012 | WO | 00 | 12/4/2013 |
