Patent Application
20120275323
Quality of Service (QoS) provisioning may be thought of broadly as the ability to provide a different priority to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow. For example, a required bit rate, delay, jitter, packet dropping probability and/or bit error rate may be guaranteed. QoS guarantees may be important if the network capacity is insufficient, especially for real-time streaming multimedia applications such as voice over IP, online games and IP-TV, since these often require fixed bit rate and are delay sensitive, and in networks where the capacity is a limited resource, for example in cellular data communication.
The emergence of multi-connection protocols, such as MPTCP at L4 or multi-rat Dynamic Spectrum Management techniques in the MAC may re-introduce the need for QoS in a new light. Having multiple connection options to choose from can create new degrees of freedom for QoS management. In particular, optimizing one parameter often leads to a different connection management approach then would optimizing a different parameter (for example, latency minimization and peak aggregate rate are often achieved through different utilization of the available connections).
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description of Illustrative Embodiments. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Systems, methods, and instrumentalities are disclosed to determine quality of service information. A device, such as a user equipment (UE), may receive a policy. The policy may indicate a level of inspection relating to application identification for a session. The device may receive information associated with the session. For example, the information may include application provided information, packet data, operating system provided information, etc. The device may perform an inspection of the received information at the level indicated by the policy. The device may perform the inspection in order to identify an application associated with the session.
The policy may indicate that the level of inspection is a first level of inspection, and, the received information may comprise application provided information (e.g., a socket call, a 5-tuple flow marker, etc.). The first level of inspection may indicate that the inspection comprises inspecting the application provided information. The device may perform the inspection in order to identify an application associated with the session. For example, the application provided information may include a socket call, and, the first level of inspection may comprise comparing a port associated with the socket call with an identified port. The identified port may be a known port, such as a port identified by the Internet Assigned Numbers Authority (IANA). The identified port may be associated with an application. The device may identify an application associated with the session as the application associated with the identified port.
The policy may indicate that the level of inspection is a second level of inspection, and, the received information may comprise packet data. The second level of inspection may indicate that the inspection comprises a packet inspection of the packet data. The second level of inspection may indicate a depth of for the packet inspection. Different depths may indicate different computationally intensive inspections. For example, a depth may indicate performing a packet inspection to identify/confirm a top-level protocol, identify/confirm sessions opened by a protocol, identify/confirm application sub-flows, etc. The device may perform the inspection at the level and depth indicated and identify an application associated with the session based on the inspection.
The policy may indicate that the level of inspection is a third level of inspection. The device may query an operating system (e.g., based on the policy). The device may receive operating system provided information. The received information may comprise the operating system provided information. The third level of inspection may indicate that the inspection comprises inspecting the operating system provided information. The device may perform the inspection and identify an application associated with the session based on the inspection.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
A detailed description of illustrative embodiments may now be described with reference to the Figures. However, while the present invention may be described in connection with exemplary embodiments, it is not limited thereto and it is to be understood that other embodiments may be used or modifications and additions may be made to the described embodiments for performing the same function of the present invention without deviating therefrom. In addition, the figures may illustrate call flows, which are meant to be exemplary. It is to be understood that other embodiments may be used. The order of the flows may be varied where appropriate. Also, flows may be omitted if not needed and additional flows may be added.
As shown in
The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).
More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000). Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSMN), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
The base station 114b in
The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in
The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While
The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
In addition, although the transmit/receive element 122 is depicted in
The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
As shown in
The core network 106 shown in
The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.
As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in
The core network 107 shown in
The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
As shown in
The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 1021b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.
The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
As shown in
The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
Although not shown in
Multi-connection may refer to a User Equipment (UE) that keeps more than one network connection simultaneously. Different types of network connections may provide users with different user experiences, such as broad bandwidth, low time delay, and high security. Multi-connection may federate access technologies in order to access the network from different places and times, benefit from different advantages of multiple access technologies, and help provide a better user experience.
A “connection” may be an association established for the transfer of data, e.g., between two or more peer-(N)-entities. The association may bind the peer-(N)-entities together with the (N−1)-entities in the next lower layer.
A “session” may be a logical connection between two or more user terminals, e.g., for the purpose of exchanging information in text format on a real-time basis.
An “IP flow” at a given interface may be defined as the occurrence at that interface of the set of IP packets that match a given classification. An IP flow may comprise packets from a single application session. An IP flow may be an aggregation comprising combined traffic from a number of application sessions. When a classification is subdivided into different sub-classifications (separate or overlapping), different IP subflows may be recognized in the corresponding IP flow.
An “application” may be a structured set of capabilities that provides value added functionality, which may be supported by one or more services that may be supported by an API interface.
A “multi-connection” may be a collection of several connections, e.g., between two or more peer-(N)-entities receiving and/or transmitting simultaneously. The connections may be coordinated to provide service to higher layer entities. In multi-connection communications, at least one UE may be required to be a multi-connection UE.
A “service decomposition” may be a decomposition of one service into several service components. The original service logic may be restructured transparently to the end user and application.
A “media flow” may be a stream of media being transmitted from a sender to interested receivers.
Multi-connection capability may be required by subscribers in many cases, for example to balance network load, provide the subscribers with wider bandwidth, charge services more fairly by utilizing different available simultaneous accesses to them, support the user when visiting more than one network simultaneously, etc. Using video conferencing as an example, the voice may be transmitted by a 2G/3G network to assure real time service via a circuit switched network, while the video component may be transmitted via Wi-Fi with larger bandwidth.
In a multi-connection network, the UE and the network may be aware of the interactions created by the number of simultaneous accesses provided to the application and an associated QoS for each. The combination or resulting QoS may portrait the combination of each QoS associated with a specific service.
Specifying QoS may be implemented using a preferential approach. While an application may not know a data rate or a latency that it needs, it may be likely to know which one is more important to it (e.g., which one has a higher priority). There may be little incentive for an application to be honest about the quantity of service it needs (e.g., ask for less than the maximum rate or more than the minimum latency), there may be incentive for the application to indicate which one it considers to have a higher priority. A dishonest application (e.g., one that states that it cares about latency more than it does about data rate when the opposite is true) may risk getting poor service from a protocol (e.g., when multi-connection protocols are used).
In an example, consider a QoS space with two parameters, data rate and latency, although additional parameters may be utilized. A multi-connection end-to-end protocol may have available to it two connections, and, as part of its Application Interface, it may request the application to indicate which parameter has a higher priority to the application (e.g., indicate a preferred resource)—data rate or latency.
An exemplary multi-connection protocol may operate as follows. For each data packet from the application, the protocol may decide which connection to send the data packet over. For example, it may send a data packet over connection 1, connection 2, or both. If the packet is sent over both connections, an acknowledgement (ACK) over any one of the two connections may be sufficient to consider the packet delivered. Upon receiving data from the application, the multi-connection protocol may decide where to send it. If the application indicated that it cares more about data rate than latency, then the protocol may send some data over connection 1, while sending different data over connection 2. The resulting throughput rates achieved may be the sum of the rates available over both connections. If the application cares more about latency than data rate, the policy may send duplicate data over both connections. The latency on each packet may be the minimum of the latencies for that packet on each connection (e.g., latency is minimized). Such an approach may incur a penalty in that the throughput may be the minimum of the throughputs over the two connections.
As in the above example, data rate and latency may be potentially conflicting QoS criteria. By forcing the application to state which parameter it cares about more, a multi-connection protocol may force the application to be honest because dishonest behavior may be detrimental to the application. The information provided over the QoS interface may be actionable by the multi-connection protocol (e.g., it may provide it with information on how to prioritize transmission parameters).
QoS may include many parameters. For example, QoS may include one or more of the following: Data Rate/Throughput; Latency; Jitter; Delivery Guarantees; Cost; Power Consumption; or Security (which may, for example, be further broken down into Privacy, Integrity, Delivery Assurance, etc.).
Other actors besides the application may have a stake in a communication eco-system. For example, an operating system (OS) may have more influence about power consumption constraints than the application, link cost importance may be driven by the operator and/or user needs, etc.
A preferential interface may include one or more interfaces to an application. As an example, consider a single interface to the application. The interface may comprise a set of available parameters exposed to the application. The application may be informed of what the set is. The set may include one or more parameters, such as one or more of the parameters disclosed herein. As an example, {Cost, Latency, Throughput, Power Consumption} may be a set of QoS parameters. The application may be asked to rank the parameters in order of importance. For example, an application that needs maximal possible throughput, cares less about latency, even less about cost, and least about power consumption may provide the following ordered set to the connection protocol: {Throughput, Latency, Cost, Power Consumption}.
An application may not know what to do with some of the parameters. For example, an application running on a laptop may not be aware of power supply constraints or the nature of wireless connectivity. In this example, the application may not know what to do about power consumption or cost.
Components of the interface may be defined. Examples may include an ordered preference list (OPL) and a “no information list” (NIL) (e.g., for parameters that the application cannot rank). Continuing the example, the application may provide OPL={Throughput, Latency} and NIL={Cost, Power Consumption}. The NIL list may be implicit instead of explicit, e.g., if the design assumes that parameters not in OPL are in NIL.
Preference may be dependent on the quantitative performance that may be provided by the multi-connection protocol. For example, an application may care about throughput more than latency, provided a minimum latency requirement is met. To support this and similar types of operations, the interface may be enhanced with feedback. The protocol may provide the application feedback on the quantitative performance against the parameters in the OPL. The application may change the OPL and NIL settings at any time, adjusting how its data is handled.
An application may need to identify what data which QoS is to be applied to. As an example, web browsers may generate one or more of the following the following types of traffic: HTTP session negotiation; “Normal” web page data; embedded audio and video streams (which themselves may have various layers); secure components, etc. An application (e.g., an evolved web browser) may partition such data (or label it in a way that can be understood by the connection protocol) and set the QoS interface for each one of its sub-flows. This may require evolution of existing interface constructs. For example, the interface to existing L4 protocols (TCP, UDP) may use the notion of a “port.” An application may open a port with the L4 protocol, and the L4 protocol may use the notion of a port to separate data from different applications. An application may open multiple ports. A connection oriented protocol, e.g., TCP, may be used to keep the data on a single port in sync—a feature that may be desirable for the many sub-flows. By using different ports, this capability may be lost.
The notion of a port may help to uniquely identify the application. For example, currently the 3-tuple of <L4 protocol (generally TCP/UDP), port number, destination IP>[also source IP] may be used to identify an application uniquely. Different applications may use the same port to communicate with different destinations. The same port number may be used for different protocols (e.g., UDP or TCP) for the same destination. Usage of the same <L4 protocol, port number, destination IP> may not be explicitly prohibited, however, it may be avoided because it may make it difficult for the operating system (which may implement the TCP/IP protocol stack) to identify data with applications.
Changes may be made to the above. The source IP may become an essential part of the flow (or sub-flow) identifier as different sub-flows may be mapped to different interfaces by binding them to different source IP addresses. The notion of flow IDs may be required. The concept of a port may include the notion of sub-ports. Each sub-port may be associated with an application sub-flow and a different QoS setting may be defined for each sub-flow.
As another example, consider an L2 connection protocol with the IP protocol serving the role of “application.” In this case, it may be assumed that the IP protocol stack is able to associate different QoS needs with different datagrams (e.g., this information may be propagated through the stack in a proprietary way). Some MAC layers, such as 802.11 through the 802.11e extensions for example, may provide for placing data in different queues with a different QoS associated with each queue. The information provided over the QoS interface may then be used by the MAC protocol to determine which queue each datagram should be placed in.
An interface to multiple actors may be provided (e.g., application, operating system (OS), user, operator, etc.). A connection/port may be opened by an application, e.g., via an (advanced) socket call. This may enable the application to specify the QoS, e.g., either via OPL/NIL or by another implementation. The port opening process may not provide a direct means for other actors to provide their input. This may be accomplished, for example, depending on whether these actors wish to provide input on a per-port basis, or global input applicable to all ports opened since the time the input is provided and as long as it is valid.
In the case of global QoS provisioning by non-application actors, an actor (e.g., OS, user, operator) may provide the QoS management entity the information on parameters of interest to it. The information may be provided in a similar form as provided by the application (e.g., OPL/NIL). The content may be different. The information may not be associated with any specific port and may not be provided when a socket is opened. The information may be provided at any time.
The ways by which this information is provided may differ by actor. Examples may include one or more of the following. Operating system (OS) information may be provided via an API from the QoS Agent and the OS. The API may be different from the application API as it may not involve a socket call. User information may be provided via a user interface. Operator information may be provided to the device through an operator policy, which a device management entity (e.g., an OMA DM entity) may then pass to the QoS Agent via an API the Agent provides to the device management entity.
Per-application provisioning may be tied to opening a port (e.g., a socket call). The non-application actors may not be directly aware that a socket is being opened. If per-application provisioning by such an actor is enabled, the QoS Agent may need to trigger the actor to provide the information. The triggering may be accomplished by a polling call—e.g., the API to each actor may include a capability for the QoS agent to poll the actor for such information. For example, the QoS Agent may poll the OS as to its power preference for a particular application when that application requests to open a port.
In the case of a user and operator input the polling process may involve additional actions. For a user, the polling process may need to initiate a user interface action that requests a user to input particular data (e.g., a process similar to asking the user whether an application should or should not be allowed internet access).
In the case of the operator, the device management entity may be polled for such information. If the information is not available in the locally stored policy, the device management entity may need to communicate with the operator to obtain it.
An approach to preferential QoS specification may use descriptive properties for each QoS category. This may be implemented in a way that each value for each property is orthogonal (e.g., the application or non-application actor may need to remain honest). For example, one QoS property may be Throughput and it may be specified using 3 values, e.g., as illustrated in Table 1.
The property of Power may be specified as illustrated in Table 2.
The property of Latency may be specified as illustrated in Table 3.
Other properties may be specified in a similar fashion.
The QoS Sniffer Function (QSF) may exercise the QoS interface on behalf of applications, e.g., applications that may not be able to do this on their own. To do so, the QSF may need to determine what type of application the data stream is coming from and what QoS the application may need or be likely to need. This may include the following. The QSF may try to guess the application type based on the data the application is sending. This may be accomplished by the use of Deep Packet Inspection (DPI), e.g., a DPI algorithm. A DPI algorithm may examine the data for information such as transport protocol (TCP or UDP) ports being used, application protocol headers, and other information. This may allow it to determine the nature of the application protocol that is being used (e.g., FTP, HTTP, RTSP, etc.). Application types may be inferred from ports being used (e.g., web browsing sessions may typically be initiated using TCP Port 80 and the HTTP protocol). DPI algorithms may analyze the sub-flows of each application flow to further identify different types of sub-flows which may require a different QoS. For example, modern HTTP flows may include web page data, video streams and secure components, among others. Each of these may require different QoS treatment. A DPI implementation may be able to identify data packets carrying information for each of these sub-flows within a HTTP web browsing session.
DPI may be used to identify each application/data sub-flow. QSF may use this information to set the QoS interface based on the sub-flow type. For example, data sub-flows may be assumed to care most about peak throughputs, while interactive (e.g., VoIP) sub-flows may be assumed to care more about latency, and https sub-flows may be assumed to care most about security. The sub-flows may be partitioned by the QSF, and, the QoS interface may be set for each of them. QoS setting on behalf of legacy applications by the QSF may be performed as described herein.
In the context of the QoS interface, the QSF may be used to set priority for QoS properties that the application has set into the NIL set. For example, the QSF may be aware of power requirements of the device which each particular application is not aware. While the applications place “Power” into the NIL set, the QSF may modify this setting by placing “Power” into the OPL with the proper priority.
A source of information for the QSF may be the device operating system. For example, the OS may be aware of power or security requirements of which the applications are not aware. A source of information for the QSF may be the user and operator input (e.g., as disclosed herein). Cost, power, and security settings are examples that may be input by the user, e.g., through the connection manager application.
A function that the QSF may serve is that of a negotiator that discovers an application's needs. This feature may be used to add a quantitative QoS element to the preferential interface described herein. For example, suppose that an application requests a particular value for a data rate (e.g., through a quantitative add-on interface). The QSF function may start out by allowing that same value to be reported over the QoS interface, but then slowly reduce it (e.g., choke the data rate) until a negative effect is observed. For example, the application may signal over an API, or other measurements, e.g., as shown in
A choking approach may be slow in learning an application's true needs, may not be able to cope with very dynamic changes, and/or may cause problems for some applications that may not be able to tolerate a varying data rate. It may be possible to mitigate this by throttling the data rate in a controlled (e.g., slow) manner, compatible with the application, however this may reduce effectiveness. Bandwidth steering may be used.
Bandwidth steering may be used as follows. Bandwidth utilization may be monitored to determine that available bandwidth is being utilized. This may be done, for example, through physical layer measurements, observations of MAC queues (e.g., queue sizes and packet dwell times in the queue), observations of network delays (e.g., in the TCP congestion control algorithm), etc. If a device detects that bandwidth has become scarce (or is instructed by the network operator to reduce its total data output), it may operate as follows. For each existing stream, “stream momentum” may be preserved. This means that an application currently running may be allowed to keep the bandwidth it is actually using up to some maximum value. For example, if a video application is using 4 Mbps, it may be allowed to continue such use as long as it continues to provide 4 Mbps of traffic (e.g., assuming 4 Mbps is below the maximum value). Remaining bandwidth may be allocated to new applications according to priorities established by the QoS Analysis module.
If an application stops using the bandwidth, it may lose its “stream momentum” and the bandwidth it was using may go back into the available pool. The application may become a contender for it along with all other applications. Non-zero minimum rates may be guaranteed to applications to support connectivity. The process may be interrupted for an application marked as urgent (e.g., health, safety, etc). This may require keeping some bandwidth in reserve or allowing a small proportion of allocated bandwidth to be reclaimed (e.g., reduce the 4 Mbps to 3.75 Mbps).
Bandwidth steering based on QoS requirements may allow an application that is using bandwidth to retain its use (e.g., may be implemented akin to a first-come, first served policy). A policy may need to account for a situation where there is not enough bandwidth available (e.g., have a rule set for such situation). For example, such a policy may include one or more of the following. New applications may be denied service. Available bandwidth may be equitably split. As an illustration (e.g., using the above example), two streams may be given 2 Mbps each. This may risk that the reduced rate is not sufficient to maintain one or both streams and may be recognized in a similar way to the choking approach. An objective may be to recognize and react to an error situation to avoid a service interruption. For example, the new stream may be slowly throttled up while the existing stream is throttled down. Other policy examples, combining features described herein may also be implemented.
Systems, methods, and instrumentalities are disclosed to determine quality of service information. A device, such as a user equipment (UE), may receive a policy. The policy may indicate a level of inspection relating to application identification for a session. The device may receive information associated with the session. For example, the information may include application provided information, packet data, operating system provided information, etc. The device may perform an inspection of the received information at the level indicated by the policy. The device may perform the inspection in order to identify an application associated with the session.
Each level of inspection may be associated with a different level of computational intensity. For example, a level of inspection for an inspection of application provided information (e.g., a socket call, a 5-tuple flow marker, etc.) may be less computationally intensive than a level of inspection for packet inspection. A lower level of inspection may indicate a less computationally intensity inspection, while a higher level of inspection may indicate a more computationally intensive inspection. The level of inspection for a session flow, sub-flow, etc., may be set at a lower level by the policy to reduce device resource use. For example, the policy may indicate that when an application has been identified for a session, a lower level of inspection may apply to information for that session. Also as an example, a policy may indicate that an application may be associated with a certain port (e.g., an application using port 21 may be tagged as FTP). In such a case, the policy may indicate that further inspection is not necessary. This may relate to a top-level inspection as described below.
The policy may indicate that the level of inspection is a first level of inspection, and, the received information may comprise application provided information (e.g., a socket call, a 5-tuple flow marker, etc.). The first level of inspection may indicate that the inspection comprises inspecting the application provided information. The device may perform the inspection in order to identify an application associated with the session. For example, the application provided information may include a socket call, and, the first level of inspection may comprise comparing a port associated with the socket call with an identified port. The identified port may be a known port, such as a port identified by the Internet Assigned Numbers Authority (IANA). The identified port may be associated with an application. The device may identify an application associated with the session as the application associated with the identified port.
The policy may indicate that the level of inspection is a second level of inspection, and, the received information may comprise packet data. The second level of inspection may indicate that the inspection comprises a packet inspection of the packet data. The second level of inspection may indicate a depth of for the packet inspection. Different depths may indicate different computationally intensive inspections. For example, a depth may indicate performing a packet inspection to identify/confirm a top-level protocol, identify/confirm sessions opened by a protocol, identify/confirm application sub-flows, etc. The device may perform the inspection at the level and depth indicated and identify an application associated with the session based on the inspection.
The policy may indicate that the level of inspection is a third level of inspection. The device may query an operating system (e.g., based on the policy). The device may receive operating system provided information. The received information may comprise the operating system provided information. The third level of inspection may indicate that the inspection comprises inspecting the operating system provided information. The device may perform the inspection and identify an application associated with the session based on the inspection.
The policy may include a default inspection level. For example, the default inspection level may be applied to an unknown flow (e.g., until the flow is in an unverified state, verified state, etc.).
A socket (e.g., an Internet socket or network socket) may refer to an endpoint of a bidirectional inter-process communication flow across an IP-based network, such as the Internet. The term Internet sockets may be used as a name for an application programming interface (API) for the TCP/IP protocol stack, which may be provided by the operating system. Internet sockets may provide a mechanism for delivering incoming data packets to the appropriate application process or thread, based on a combination of local and remote IP addresses and port numbers. A socket may be mapped by the operating system to a communicating application process or thread.
A socket address may comprise a combination of an IP address and a port, which may be mapped to the application program process into a single identity, which may be similar to how one end of a telephone connection is the combination of a phone number and a particular extension. Some sockets (e.g., windows-based, Linux-based, UNIX-based) may be implemented by an API library, such as Berkeley or BSD sockets.
The socket API provided by kernels may be based on Berkeley socket API. Functions such as those in Table 4 may be supported. Note that the socket function calls may be the socket function calls used for Linux-based API.
An application may refer to an application running at L5 or above, e.g., in ISO module. It may be the application as seen by the user on his terminal. As examples, an application may be a web browser, an FTP application, a VoIP client, a Skype application, etc. An application may be uniquely identified by an Application ID (AID). The OS process ID associated with the application may be used as the Application ID.
A session may refer to an L4 transport socket as opened by an application through socket API. Example sockets may include a UDP, a TCP, an MCTP, an MNTP socket, etc. A session may be uniquely identified by a unique session ID. An application may open one or multiple sessions. For example, an FTP Application may open two sessions—an FTP control session and a separate FTP data session. These sessions may be referred to as dependent sessions.
A sub-flow may refer to a multi-connection (L4) transport layer concept. An MCTP or MNTP single session may open multiple sub-flows. These sub-flows may not be known as such by the application and may be handled by the transport layer.
A sub-stream may be an application concept. This may be a way to differentiate bits generated by the same application. For example, a voice codec may generate class A, B, and C sub-streams.
As communication capabilities of terminals (e.g., UEs) increase, the services provided by the standard socket interface may not be sufficient. A standard socket interface may not be able to indicate its service preference (e.g., to pass Quality of Service (QoS) information to the protocol stack).
The socket interface may be extended to provide QoS requesting capabilities to applications. For example, the socket interface may be extended to include advanced features. This approach may apply to applications that have actually been designed to take advantage of such “advanced” socket interface. For existing (e.g., legacy) applications, there may be a need to infer what an application needs from the socket calls it makes and the data it sends and receives. This may be accomplished by the use of a Deep Packet Inspection (DPI) algorithm. Such a protocol is typically computationally intensive (e.g., it may impact power consumption and/or the throughput of the stack).
Systems, methods, and instrumentalities are disclosed that may provide a desired level of identification without the use of DPI and/or may allow for selective, policy-controlled use of DPI. The extent to which DPI may be used may be configurable by a control entity in the terminal, e.g., a session manager. This may allow policy-based control of resources dedicated to DPI and a level of identification provided by the evolved socket interface described herein.
An Advanced Socket Interface (ASIF), e.g., for support of legacy applications, is disclosed herein. The ASIF may be a functional component for an enhanced protocol stack implementation that provides access capability for applications to initiate and utilize communication sessions. For the purposes of backwards compatibility, it may present itself to applications as an enhanced socket interface. The ASIF may provide one or more of the following: techniques for applications to open/close and manage IP stack (e.g., EIPS) connections for their purposes; provide the session management (SM) component information about an application that may require connectivity as well as its QoS requirements; or pass application data to/from the proper transport protocol, e.g., as defined by the connection manager.
The ASIF functional component may rely on parameters received from an application through a socket function and/or on packet inspection (PI) procedure, a variant of deep packet inspection algorithm to extract information related to a session, such as for example the port to transmit and receive packets, the application protocol used over the session, etc. PI may be used in the IncomingData and OutgoingData functions for confirmation, identification, monitoring, etc., of legacy applications and certain advanced applications. Session information extracted by the PI function may be reported to the SM. Parameters related to a session may include one or more of the following. A session ID) (SID) may be a parameter, which may be referred to as a socket ID. The socket ID may be set to NULL if not known. An Application Protocol Name (PNAME) may be a parameter, which may be set to NULL if not known. PNAME values may be linked to the protocols supported by PI (e.g., Table 8). An Application ID (AID) may be a parameter, which may be set to NULL if not known. If sessions are identified as sub-flows of the same application, they may have the same AID. For example, an FTP application may include an FTP control session and an FTP data session. Both sessions may have the same AID.
A single SessionOpen, SessionClose, and PassThrough process may be needed for the ASIF. A separate instance of IncomingData and OutgogingData may be needed for each active session.
A socket interface call may be mapped to ASIF Procedures. Table 5 shows an exemplary mapping between socket interface calls and ASIF processes. Some calls may not be mapped as they may be intended for a server (e.g., TCP server) that may accept connections and not a terminal that initiates them.
A session may have an associated state. An active session may be created by the SessionOpen process and deleted by the SessionClose process. An exemplary session lifetime is shown in
During the socket lifetime, the ASIF component may maintain a session state machine (SSM). The SSM may indicate knowledge of the type of application protocol used for the session. The SSM may be updated by a 5-tuple received with the connect( ) and by the PI function.
An exemplary state transition diagram (e.g., for the SSM) is shown in
Each state transitions, except NEW→U and NEW→US may occur as a result of reception of a packed in either the outgoing or incoming direction. The transitions NEW→U and NEW→US may occur upon connection of the socket as disclosed herein (e.g., NEW state). The nature of the transition may be a result of the packet inspection function, which may be called for every packet by the IncomingData and OutgoingData processes. The state machine transitions for SID n may occur if the PI function returned SID n.
Table 6 illustrates exemplary session state transition specifications, which may include a cause and result.
A packet inspection (PI) function may be called on for a packet, e.g., in either the incoming or outgoing direction. The PI function may be called on each packet that meets one or more of the following: a packet's SID is unknown (e.g., this may occur in the incoming direction); or a packet's SID is associated with a session in the U, US, or UR state. The PI function may be called for a packet with an SID in a VS or VR state. This decision may be left up to the SM and may be configured on a process-by-process basis.
In addition to a received packet, the packet inspection function may take one or more of the following inputs: SID, PNA ME, MODE, or INSPECTION LEVEL. SID may be set to NULL if not known (e.g., this may occur in the incoming direction). PNAME may represent a protocol name. PNAME may be set to NULL if not known. MODE may be one of {DISCOVER, CONFIRM, MONITOR}.
In DISCOVER mode, the task of the PI function may be to discover which application protocol is being used for a given SID. If PNAME is not NULL, the list of protocols may be treated as a candidate list and may be used to narrow and speed up the search space. If SID is null, the packet may be assumed to potentially belong to any session in the U state.
In CONFIRM and MONITOR modes, the task of the PI function may be to monitor the protocol operation and set reconfiguration triggers. In these states, SID and PNAME may not be allowed to be set to NULL. Moreover, PNAME may need to have a unique setting and the setting may need to be consistent with the previous setting of PNAME for this SID. A violation of this rule may result in the PI function returning VIOLATION for the SID on the given packet. In CONFIRM mode the PI function may be requested to confirm that a protocol is indeed corresponding to PNAME.
The INSPECTION LEVEL parameter may determine the depth (e.g., level) to which packet inspection is performed for a particular session. The INSPECTION LEVEL parameter may determine the types of reconfiguration triggers that the PI function may be able to set and protocol measurements it may be able to make. INSPECTION LEVEL may be set by the SM based on one or more SM policies. A DEFAULT INSPECTION LEVEL may be set by the SM and may be applied by the ASIF to sessions for which the SM has not set a specific INSPECTION LEVEL. Exemplary INSPECTION LEVELs are illustrated in Table 7.
The PI function may return one or more of the following: PNAME, the application protocol; application ID for the current packet SID; other related SIDs; one of the following {NO CHANGE, VIOLATION, CONFIRM, PROTOCOL ID}; one of the following {STABLE, RECONFIG}; or, if RECONFIG is returned, the nature of the reconfiguration may be reported. The nature of the configuration may comprise one or more of the following: NEXT_TP (transport protocol in the next message); NEXT_PRT_S (next source port); NEXT_PRT_D (next destination port); or application-protocol specific information.
The list of protocols supported by the PI function may be a configurable parameter. The actual PI function may be one of any known deep packet inspection algorithms.
In a current packet analysis, if PI detects a potential future opening session that may be linked to the current session and belonging to the application associated with the current session, it may setup a potential sub-flow trigger. The potential sub-flow trigger may be used for later session opening and new session packet analysis to confirm if the new open session belongs to the application associated with the current session. Associated with this trigger, PI may keep track of the details related to the expected future session (e.g., port number, protocol, etc.). For example, consider an FTP session started with an FTP control connection initiated at the terminal with TCP destination port 21 and some particular destination IP address (IPx). The PI function may monitor this connection and detect an FTP command returning to the terminal with an instruction to setup an FTP data connection using TCP port A and destination IP IPy. The PI function may then set up a potential sub-flow trigger. The potential sub-flow trigger may comprise one or more of the following: sub-flow trigger ID; sub-flow trigger details; sub-flow trigger information; or sub-flow trigger lifetime.
Sub-flow trigger details may include one or more of the following: application ID (e.g., use the app. ID associated with the FTP application); destination port type: TCP; destination port address: A; or, destination IP: IPy. Sub-flow trigger information may include one or more of the following: master session ID: session ID of the FTP control session; sub-flow trigger type: “FTP data transfer”; or sub-flow trigger additional info: additional information, such QoS requirement that may be associated with this type of session, e.g., size of file requested, etc. The sub-flow trigger lifetime may include time-to-live, expiration time, etc.
The SessionOpen process may be responsible for starting a communication session for an application. The SessionOpen process may be started when an application makes a socket( ) call, e.g., on D5, and may be responsible for generating a response to the call for the application. Upon activation, the SessionOpen process may perform one or more of the following: check if the socket( ) call corresponds to a new session or, if a potential sub-flow trigger is raised, determine if the socket can be associated with a pre-existing session; define a session ID (SID) to be used in communication about the session with other processes and components; retrieve the socket type (e.g., UDP, TCP, etc.) information from the socket( ) parameters; alert the session manager and connection manager of a request to open a new session; or, if the socket is accepted, enter into open session state.
The function int socket (int family, int type, int protocol) may create a communication end point and may return a descriptor (e.g., Session ID) that may be used for further action associated with the socket. For TCP/IP based sockets (e.g., as disclosed herein), the family parameter may be set to AF_INET. The type parameter may be SOCK STREAM (e.g., for TCP) or SOCK_DGIRAM (e.g., for UDP). The protocol field may specify a specific protocol in case the network model supports different types of stream and datagram models. This field may be set to 0 (e.g., TCP/IP may have one protocol for each).
The function domain may specify the communications domain in which a socket is to be created. For TCP/IP based sockets (e.g., as disclosed herein), the family parameter may be set to PF_INET (IPv4 Internet protocols) and PF_INET6 (IPv6 Internet protocols).
“Type” may specify the type of socket to be created. “Protocol” may specify a particular protocol to be used with the socket. If the protocol argument is non-zero, it may specify a protocol that is supported by the address family. If the protocol argument is zero, the default protocol for this address family and type may be used. The protocols supported by the system may be implementation-defined.
The session ID may be randomly generated by ASIF. The session ID may be returned as a socket ID that may be used by the application in later functions calls that may operate on that socket.
On reception of a connect( ) call, e.g., on D5, the SessionConnect process may be responsible for connecting the socket SID passed as a parameter in the function call to the peer whose destination port and IP have been passed through the function. The SessionConnect process may perform one or more of the following: attempt to identify the session using default application configurations; attempt to identify if the session is an application sub-flows; update SSM to either Unknown (U) or Unverified/Stable (US) state; request the session manager of a request to connect an already open session by calling SM_SessionConnect( ); or return a value.
The connect( ) function call may connect a socket, identified by its file descriptor, to a remote host specified by that host's address in the argument list. Certain types of sockets may be connectionless, UDP sockets may be an example. For these sockets, connect may take the following meaning: the default target for sending and receiving data gets set to the given address, which may allow the use of functions such as send( ) and recv( ) on connectionless sockets. connect( ) may return an integer representing an error code, 0 may represent success, −1 may represent an error, etc.
The prototype for connect may be as follows: int connect (int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen). A first argument may be a socket handle (e.g., the number returned from the socket( ) function call). A second argument may be a sockaddr_in structure. The sin_port field of the address argument may be the local source port number associated with this socket. That is, for a “send” operation with this socket, the source port field in the TCP/UDP header may get set with this value. If specifying a source port is not required, setting this value to INADDR_ANY(0) may allow the operating system to pick any available port number. The sin_addr field may specify which network interface device to use. Since many hosts may have one network interface and one IP address, this field may be set with the host's own IP address. The socket library may provide no immediate way for a host to determine its own IP address. Specifying the value of INADDR_ANY(0) in this field may indicate to the operating system to pick any available interface and address. The address of the sockaddr_in structure may be passed into the bind call so that the socket may be ready to communicate with remote hosts. A third parameter passed to bind may be the length of the sockaddr_in structure.
A check may be made for a known application protocol. For LEGACY applications, the triplet <transport protocol, source port, destination port> may be checked against a table of IANA known application. Table 8 is an example table of protocol analysis based on connect parameters.
If the connect( ) parameters are part of the table above, the SSM may be set to US with the associated application protocol PNAME setup with the value from the table. If not, SSM may transition to U state and PNAME may be set to NULL.
Incoming data may be called when the application calls a recv( ) or recevfrom( ) on D5. If the session ID for the packet can be identified (e.g., based on the 5-tuple), data may be passed to the correct application through D5. If the session for which data is received indicates that the PI function is to be invoked, this may be done. When the PI function completes, an action defined in Table 6 is taken. OutgoingData may be called on each outgoing packet. If the session number for the packet can be identified (e.g., based on the 5-tuple), data may be passed to the correct transport protocol.
SessionClose may be started when an application makes a close( ) call on D5 and is responsible for generating a response to this call for the application. Upon activation, the SessionClose process may perform one or more of the following: terminate the SSM related to the SID; alert the SM and CM of a request to close an open session; or deallocate the Session ID (SID).
The PassThrough process may transfer a socket call to another component with no ASIF specific process. For gethostbyname( ) or gethostbyaddr( ) call on D5, ASIF may transparently pass these functions to the SM to be processed and respond back the return value with no additional check. For the src address, applications may use APIs, e.g., getaddrinfo( ), that may return a list of addresses to the application. The list may comprise IPv6 and/or IPv4 addresses.
A specification of the interfaces associated with the ASIF functionality may be provided. D5 may refer to the interface between the applications and the advanced socket IF (ASIF). This interface may present a BSD-like sockets interface for both Legacy and ADV Application. Functions used may be limited to client side functions. Exemplary D5 functions are shown in Table 9.
C1 may refer to the interface between the advanced socket IF (ASIF) and a control plane entity, such as the SM. This interface may allow the ASIF to notify the SM that a new session has been detected or that a change has occurred for an active session. A change may refer to one or more of the following: an addition of a new socket (e.g., new session, sub-flow, etc.) to the session; a deletion of a sub-flow or a change in the session description (e.g., new QoS, mobility required or not, level of security), etc. Exemplary C1 functions are provided in Table 10.
D4 may be used between ASIF and the Transport FC. D4 may allow sending and receiving data packets to/from the Transport FC. Exemplary D4 functions are illustrated in Table 11.
The socket( ) interface function may be enhanced with a parameter (adv) so that it has the format shown in Table 12.
The adv parameter may include one or more of the following parameters: App. ID, QoS Preference, protocol: ADV, master_socket_id, num_subflows, subflow_desc, or Preferred_network. App. ID may be an application ID selected by the application that may be used by the system to link multiple sessions opened up by the same application. The process ID assigned to the application by the operating system may be used as the App ID. QoS Preference may provide a QoS Preference. An application may use protocol: ADV to transmit its application protocol with values, e.g., as disclosed herein. The master_socket_id may indicate that the socket is to be considered a sub-connection for a connection with another socket id. The num_subflows may be used to indicate that the socket includes multiple sub-flows. If values >1 are used, sub-flow descriptors may be included, otherwise this may be ignored. Values >1 may not be supported. The subflow_desc may be a sub-flow descriptor. Preferred_network may be used to indicate an application's network preference. Two types may be included. The application may indicate a preference for: <MOBILE, PUBLIC_IP, PRIVATE_IP> as a network or it may indicate a specific network (e.g., specific Mobile operator, specific public WiFI network via an SSID list, etc.). MOBILE may be a mobile/cellular network. PUBLIC_IP may be a public IP (e.g., internet access network). PRIVATE_IP may be a private IP network—e.g., an organization's enterprise network.
QoS Preference may provide the application a way to specify a type of connection it requires and allow the SM to allocate the session resources. It may define a set of QoS Indicators that the application may arrange in order of preference. An application may be limited to using one or a subset of QoS Indicators (e.g., specify several in order of highest preference to lowest). The ASIF may set and/or modify these based on packet inspection analysis.
QoS Classes may include one or more of the following. QoSI_THROUGHPUT: this QoS Indicator may be used to signal importance of throughput maximization. QoSI_LATENCY: this QoS Indicator may be used to signal importance of minimizing latency, which may be at the expense of throughput. QoSI_RELIABILITY: this QoS Indicator may be used to signal importance of minimizing packet error rate, which may be at the expense of throughput and latency. QoS_POWER_EFF: this QoS Indicator may be used to signal importance of minimizing power consumptions, which may be at the expense of other QoS aspects. QoS_CRITICAL: this QoS Indicator may be used to signal that the application considers itself a critical function service (e.g., human health, operational reliability, etc.). An application may use this to request high priority service, although the resources to be assigned to it may be subject to decisions by the SM. QoS_SECURE: this QoS Indicator may be used to signal that a highly secure connectivity is needed. The extent to which this is provided may be up to the SM. QoS_BACKGROUND: this QoS Indicator may be used for background services and may allow the SM to allocate resources, e.g., to minimize cost, etc.
In the case of cellular connections, the QoS Class specified may be mapped to a QoS class specified within cellular system specifications.
Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
This application claims the benefit of U.S. Provisional Patent Application No. 61/407,366, filed on Oct. 27, 2010 and U.S. Provisional Patent Application No. 61/474,017, filed on Apr. 11, 2011, the contents of which are hereby incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61407366 | Oct 2010 | US | |
| 61474017 | Apr 2011 | US |
