Patent Application
20120258674
The Connection Manager (CM) may provide access connections so that users can connect to a network using predefined and static connections. The Connection Manager profiles can be used to connect to remote networks through servers, for example, again using predefined and static connections. The Connection Manager may also provide predetermined and static access connections for users to connect to applications.
The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. 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.
Embodiments contemplate one or more Session managers (SM) and/or source Internet Protocol (IP) address selection techniques. Embodiments contemplate that a session manager may establish a session in a wireless communication environment based on one or more policies specified by a policy manager. In one or more embodiments, a session manager may also delete the session. For example, a session may be deleted in response to receipt of a request from an application. Embodiments also contemplate that a session manager may store a session description for the session. A session manager may also perform source IP selection for a data plane, for example. In addition, embodiments contemplate that a session manager may also provide a Multi-Connection (MC) transport with IP addresses for negotiating additional sub-flows, among other purposes.
Embodiments also contemplate a wireless transmit/receive unit (WTRU) that may comprise a processor. The processor may be configured, at least in part, to use at least one function to dynamically control one or more connection configurations based on, at least in part, one or more requirements of at least one of a WTRU user or one or more applications operating on the WTRU. Embodiments further contemplate that alternatively or additionally the processor may be further configured to use the at least one function to determine the use of one or more connections based, at least in part, on the one or more requirements. One or more embodiments contemplate that the one or more connections may be part of one or more respective sessions. Embodiments also contemplate that, alternatively or additionally, the processor may be further configured to use the at least one function based on one or more policies. One or more embodiments contemplate that the at least one function may operate in a control plane of the WTRU. Also, one or more embodiments contemplate that the at least one function may be a first function, and the first function may include one or more second functions.
Embodiments also contemplate that, alternatively or additionally, the processor may be further configured to use the at least one function to determine a service type for use by at least one of the one or more sessions. Alternatively or additionally, embodiments contemplate that the processor may be further configured to use the at least one function to determine a radio access technology (RAT) for use by at least one of the one or more sessions. Alternatively or additionally, embodiments contemplate that the processor may be further configured to use the at least one function to determine a priority of a first session of the one or more sessions relative to a second session of the one or more sessions.
Embodiments also contemplate, alternatively or additionally, that the processor may be further configured to use the at least one function to delete the second session of the one or more sessions upon determining that the first session of the one or more sessions is higher in priority than the second session. One or more embodiments contemplate that the at least one function may be a session manager function. Alternatively or additionally, embodiments contemplate that the processor may be configured to use the at least one function to determine that at least one of the one or more sessions is to be closed, and, to close the at least one of the one or more sessions.
Embodiments contemplate a wireless transmit/receive unit (WTRU) that may comprise a processor, where the processor may be configured, at least in part, to use at least one function to dynamically determine one or more source Internet Protocol (IP) addresses for one or more applications operating on the WTRU based, at least in part, on at least one of one or more policies or one or more quality of service (QoS) requirements. Alternatively or additionally, one or more embodiments contemplate that the one or more policies may include a correspondence between the one or more source IP addresses and one or more conditions.
Embodiments further contemplate, alternatively or additionally, that the one or more conditions may include at least one correspondence between the one or more source IP addresses and at least one of a type of application or an availability of a mobility support. One or more embodiments contemplate that the at least one function may be a session manager function. Alternatively or additionally, embodiments contemplate that the at least one function may utilize a getaddrinfo parameter. Embodiments also contemplate that the QoS requirements may include at least one of a preferred network for an application, a list of prohibited networks, a mobility requirement per application, or a bandwidth aggregation requirement.
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 will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application. As used herein, the article “a”, absent further qualification or characterization, may be understood to mean “one or more” or “at least one”, for example.
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 (GSM), 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, 102b, 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
Embodiments recognize that in a multi-homed device (e.g., a device which may support one or more, or multiple, wired and/or wireless interfaces) a connection manager (CM) may be a function that can make an interface between one or more applications and one or more low-layer interfaces. The connection manager may be responsible for establishing, maintaining, and/or releasing interfaces at the physical layer and may track which connections may be in use or may be requested by applications. Further, embodiments recognize that a connection manager may close unused connections and/or automatically disconnect connections when they are idle for a specified period of time, etc., for example.
In an example, the command Getaddrinfo( ) issued by one or more applications can return a list of local addresses to the one or more applications that may contain IPv6 and/or IPv4 addresses. Executing the command may be performed by the operating system (OS). Suitable algorithms may provide for the Source (Src) IP sorting, perhaps based on how close the Source IP address is from the given destination IP address, for example. Embodiments recognize that applicable rules may, however, be static and thus may not be adequate in many cases. In an example, Linux provides a way to configure the sorting algorithm configuration but may also not be adequate in many cases.
Embodiments contemplate that network selection can be controlled and/or monitored by the operator (e.g., 3GPP network) and/or by the user (e.g., in a café, where there is 3G and a hotspot wireless local area network (WLAN) coverage, the user might prefer to connect freely to the hotspot preferably to the 3G network). Applications can also have their own policies (e.g., even at home, a voice over Internet Protocol (VoIP) session is more reliable if done over 3G if the user wants eventually to leave home and continue the voice over Internet Protocol (VoIP) outside, while a HTTP session is good enough on the Home WLAN). One or more of these access rules may be supported by different protocols or functions, such as OMA DM (Device Management), ANDSF (Access Network Discovery and Selection Function) in 3G/4G network, or the like, for example.
Embodiments contemplate that the granularity of the rules can also be per IP Flow, such as but not limited to policies developed by the current 3GPP MAPCON and IFOM (multi access PDN connectivity and IP flow mobility) working Group, by way of example and not limitation.
Embodiments contemplate that, by way of example and not limitation, an application may be an application running at L5 or above in an ISO module. Also by way of example, an application may be the application as seen by the user on his terminal By way of further example and not limitation, an application can be a web browser, a FTP application, a VoIP client, or a voice over Internet Protocol (VoIP) application. An application may be uniquely identified by an application ID (AID). In one or more embodiments, the OS process ID associated with the application may be used as the application ID.
Embodiments contemplate that a session may be an L4 Transport socket as opened by an application through socket API, by way of example and not limitation. Embodiments contemplate that a socket may be a UDP, a TCP, and/or a Multi-Connection Transport (e.g., MPTCP) socket. One or more embodiments contemplate that a session may be uniquely identified by a unique session ID. Embodiments contemplate that the same application may open one or multiple sessions. For example, an FTP Application may open two sessions, an FTP Control and a separate FTP Data session. In one or more embodiments, these sessions may be referred to as “dependent sessions.”
Embodiments recognize that an example task of a Connection Manager (CM) may be to make sure that a protocol stack and communication interfaces are configured as per user (and/or, perhaps to a limited extent, operator/OS/application) requirements. CMs may expect that the requirements are “direct”, which by way of example may mean that the user can specify which WiFi AP to use by choosing an SSID; the user may specify which, among several, mobile networks to use by choosing one from a menu; the application may select an interface to use by selecting a source IP—or this may be left to the operating system. Embodiments recognize that an example CM may have two roles, and perhaps only two roles: serve as an interface to the user/OS/application; and a manager for control protocols that setup connections (e.g., WiFi's WPA authentication).
One or more embodiments recognize that in evolved communication systems, such direct control by the user/OS, etc. may be undesirable or otherwise unwanted. One or more embodiments contemplate that multi-connection devices may increase, or perhaps even maximize, their utility when managed dynamically to help ensure that connection configurations—and/or even which connections may be used—are adjusted to the communication need or needs of the user and/or application, for example. Further, operator, user, device and/or application preferences are often communicated to the device via high-level policies. By way of example, and not limitation, a preference may be “use WiFi for Video when WiFi QoS is sufficient.” Embodiments recognize that current CM cannot handle such high-level policies. Further, embodiments recognize that current (or traditional) CM solutions or implementations may be insufficient to address these needs. Embodiments contemplate additions to a CM in the terminal “control plane”, for example.
Embodiments recognize that, as stated herein, a getaddrinfo( ) operation may return a list of local addresses. Embodiments also recognize algorithms that may provide for Src IP sorting, which in one or more embodiments may be based on how close the Source IP address is from a given Dest IP address, for example.
Embodiments contemplate that, perhaps in cases of a multi-homing devices, among other cases for example, static rules may not be sufficiently accurate. Indeed, existing source IP selection algorithms may base decisions on the IP addresses, and sometimes on the IP addresses only, perhaps with no other consideration about the interfaces' characteristics on which these IP addresses are mapped. Embodiments contemplate that in a multi-homing device managed by operator and/or supporting users' preferences for example, consideration such as wired/wireless, trusted/untrusted, operator preferred network, user preferred network, etc., and various other policies and/or requirements may be considered for the Source IP selection, and in one or more embodiments should be considered for the Source IP selection. Also embodiments recognize that during operation, if an application's requirements change, a CM may not address these changes dynamically. Embodiments contemplate dynamically addressing an application's changing requirements. One or more embodiments contemplate that a dynamic change may be made in response to a change of conditions that may occur after an initial configuration is made, for example. By way of example, and not limitation, embodiments contemplate that a change in network congestion may make a move of a flow from WiFi to 3G useful. Also by way of example, embodiments contemplate that a change in the number of simultaneous applications running on the WTRU may make a redistribution of how flows are allocated to various interfaces useful.
One or more embodiments contemplate a function, which may be referred to herein as a session manager (SM) for exemplary description purposes and not by limitation. For example, system and process embodiments are contemplated for SM techniques and algorithms; SM architecture and interface embodiments perhaps with one or more other functional components are contemplated; and one or more source IP address selection algorithm embodiments are contemplated.
Embodiments contemplate that the SM can be a functional component that may sit in the overall ACMS/EIPS architecture, for example. In one or more embodiments, the SM may partition the overall connection management problems into one or more less complex sub-problems. For example, for each session, the SM may decide: what kind of service(s) to be used (BW aggregation, IFOM, etc.); which radio access technologies (RATS) may be made available for a particular session; and/or what a session's priority may be with respect to other sessions. These decisions may then allow other decisions to be made in an independent fashion including, but not limited to, source IP selection, L4 protocol selection, aggregation management, among others, for example.
In one or more embodiments, the SM may be responsible for managing the one or more sockets that may be opened by the applications and/or configuring for some sockets or for each socket the full stack (Transport/IP/Physical Layers) according to the application requirements provided at the opening of the socket and/or in accordance with one or more policies in an application operating in the wireless transmit/receive unit (WTRU, or user equipment (UE)).
The SM may keep track of some or all opened sessions. The SM may update some or all opened sessions, perhaps based on information received from Application Interface (API) or from CM in case of a change in IP/Phys layers, for example. Also, the SM may provide new IP addresses, if needed, to the multi connection transport layer.
Further, embodiments contemplate that the SM may perform one or more of the following functions: session establishment, session maintenance, and/or session deletion, perhaps based on defined policies received from policy management, for example. For session establishment, the SM may request resources setup to the CM by providing the related policies and parameters, for example. Session deletion can occur either on request from the application, based on received policy or in reception of resource deletion from CM. For example, if a high priority session arrives and resources are limited, a lower priority session can be interrupted. In one or more embodiments, perhaps when a change is detected on the application (e.g., application type change, quality of service (QoS) requirements update, etc.), some QoS changes can be requested to the CM. In some embodiments, the QoS changes can be directly provided by the application, or may be detected through Packet Inspection (PI) which level may be controlled by SM.
One or more embodiments contemplate that the SM can identify when a session reconfiguration is required and may requests it to the CM. The SM can maintain session description for some or each running session. Further, the SM can perform source IP selection for the data plane. During operation, the SM may manage IP addresses exposure to multi-connection transport layer. For a MC Transport Layer (e.g., MPTCP), the SM may provide the MC transport with additional IP addresses so that the MC transport layer can negotiate with its peers additional sub-flows, for example, among other reasons. For aggregation protocols, the SM may support a scheduler control functions for the aggregated schedulers in use, for example. The SM may also interface to a security client, for example for SSO.
In one or more embodiments, the SM configuration may be provided by some pre-provisioned data, received from the user, and/or received from a network. A number of parameters may be used by the SM. They can be changed dynamically, for example through policy management functions. The SM may request the ACMS/EIPS configuration parameters to policy management by calling SM_Configuration( ). Table 1 below shows an example SM mode of operation.
For some current open sessions, or for each current open session, the SM may keep and maintain some or all the related parameters in a session table such as the example SM session table shown in Table 2.
In one or more embodiments, the SM may receive connection information from the CM. Example connection related information is shown in Table 3.
One or more embodiments contemplate that, while some sessions or each session may have its own Session Table, SM may also store common resources that may be available on the WTRU and which may be shared between the different sessions. Examples of such parameters (or resources) may be stored in an SM Operation Table, an example of which is illustrated in Table 4.
One or more embodiments contemplate that, perhaps prior to requesting resources to CM, the SM may check the application's requirements and the policies that may apply to the requested socket to identify an appropriate or most suitable match.
Embodiments contemplate the application of Quality of Service (QoS) requirements. Example QoS priorities include throughput, latency, error, etc. An example network for the application includes APN provided for a 3G network, and network ID provided for non-3GPP access. A list of prohibited networks may be provided. Traffic prioritization may be provided. Mobility requirements per application may be provided. BWA (e.g., aggregation) requirements may be provided. Embodiments contemplate that security requirements may be provided. Embodiments contemplate that BWA may be conducted via one or more mechanisms involved in deciding which actual interface an IP Flow may be sent over. Embodiments contemplate that the process of sending IP Flow may involve, among other things, a segregation (e.g., the ability to assign flows to interfaces on a per-flow basis). One or more embodiments contemplate that BWA may also include support of Flow Mobility (e.g., the ability to move flows between interfaces. Further, one or more embodiments contemplate that BWA may include aggregation (e.g., the ability to send a single flow over multiple interfaces at the same time).
Embodiments contemplate that for LEGACY applications, the QoS requirements may be provided by the policy management. Table 5 below shows an example of per application QoS requirements.
One or more embodiments contemplate that for ADVANCED applications, these QoS requirements may be provided directly by the application with the ADV socket( ) call, for example.
Embodiments contemplate one or more IFOM Type Policies. While the initial IFOM support is network-controlled IFOM (e.g., the WTRU may be passive and may react to network decisions by sending outcoming packets on interface on which it has received incoming packets), the WTRU may need to setup or not the LIF for a requested socket. For this, the policies are two-fold, per flow based and per services based rules, similarly to the Inter System Routing Policies (ISRP) element including in ANDSF Management Object, allowing the operator to provide policies based on the traffic exchanged by the user equipment (UE) or WTRU. The granularity of the policies is the IP flow. In this way, the operator can indicate different preferred or forbidden radio access technologies as a function of the type of traffic the WTRU may send.
The IP flows may be identified by the range on which the 5-tuplets belong (e.g., protocol type, start/end of source and destination IP address and start/end of source and destination ports). The service may be identified by the APN (Access Point Name). As an example, this can be a set of ISRP provided by an operator to the WTRU. Table 6 shows an example of per flow policies (note that information included in the ANDSF MO such as validity, location and others are not shown in this table for the sake of simplicity).
Embodiments contemplate a SM_SessionOpen operation. This operation may be used to establish a new session, identified by the session ID received through the SM_SessionOpen( ) call. At that stage, the SM may create a new session table for this session, as shown in Table 2, and may store the SessionID and the transport FC related parameters received on the SM_SessionOpen( ).
Embodiments contemplate an SM_SessionConnect operation. In one or more embodiments, the SM may store in the session table the parameters received on the SM_Connect( ) call for the session identified by the Session ID, e.g., the application protocol (PNAME) and the requested QoS (if available). The SM may also update the destination part of the IP flow ID (5-tuple, 6-tuple) with the destination address with its length (IPv4 or IPv6) also received in the SM_SessionConnect( ). Based on this input, in one or more embodiments—perhaps additionally to the policies that apply to the WTRU—the SM may setup the full stack for this session, e.g., define the transport layer and physical layer resources and requests their setup to the TrFC and to CM.
By way of example, and not limitation, the following are some examples of the type of SM_SessionConnect( ) scenarios. In one or more embodiments, the application may use a WiFi breakout but can send data over 3GPP. In such cases, the following may be applied: List Phys (WiFi, 3GPP); LIF=0; and/or VIF=0, for example.
In one or more embodiments, the application may use a LIF over WiFi and 3GPP. In such cases, the following may be applied: List Phys (WiFi, 3GPP); LIF=1; and/or VIF=IPsec, for example.
In one or more embodiments, the application may want to do some aggregation over WiFi and 3GPP. In such cases, the following may be applied: List Phys (WiFi, 3GPP); LIF=0; and/or VIF=0, for example.
Embodiments contemplate Transport Layer Selection. To setup correctly the stack, one or more embodiments contemplate that the SM may decide which transport session should be open or, in some embodiments, may needs to be open. The SM may request the same type of socket as the one requested in the in the socket( ) request received from an Advanced Socket Interface (ASIF), perhaps for example if the BWM mode of operation is set to OFF, among other reasons for example. In one or more embodiments, if the type of socket is SOCK_STREAM (which may be considered as a TCP session) and/or if the internal configuration parameter BWM status is different to OFF, then perhaps for those conditions and/or other conditions, the SM may request a multi connection transport layer according the BWM mode. The SM may update accordingly the MC protocol in the session table. In one or more embodiments, the BWM status/mode may be equivalent to an L4 multi-path management status/mode, for example, which may indicate and/or activate the use of MPTCP or similar protocols.
Embodiments contemplate Mobility Type and IFOM Selection. For the purpose of, for example (among other purposes), setting up a correct physical interface (PhIF) and/or requesting the appropriate IP type (e.g., local IP address or a tunnel IP address), the SM may check the PNAME and the IP flow ID (5-tuple) requested. Based on one or more of them, the SM may extract the mobility policies for the application QoS requirement table and/or the flow policies from the per flow policies table. This may allow the SM to decide the PhIF (with the related network name, e.g., SSID for WiFi), the LIF type, and/or the VIF type, for example.
Embodiments contemplate an SM_SessionClose function/operation. This operation may close the session identified by the session ID received through the SIF_SessionClose( ) or ASIF_ProtocolViolationNotification( ) call. SM_Session Close may release the related Phys and transport resources by calling TrFC_Disconnect and CM connection with CM_Disconnect, for example. In one or more embodiments, SM_SessionClose may then delete the SessionTable related to this Session ID.
Embodiments contemplate an SM_OperationTableUpdate function/operation. This function may update the SM operation table based on, at least in part, input received from the CM. The function may update the list of interfaces available received through the SM_PhIFStatus( ) call and/or may update the list of Src IP available received through the different CM_connect( ) for example.
Embodiments contemplate an SM_BWM function/operation (BandWidth Management). In one or more embodiments, perhaps when the sessions are created for example, the SM may maintain and/or monitor them during operation. In sessions that may support a MC TransportFC (e.g., MC protocol set to MPTCP in a session table), the SM may provide them with any new (source) IP addresses so that the MC transport session can open or close one or more related sub-flows with its MPTCP peer, for example. Embodiments contemplate that the SM_BWM (BandWidth Management) function may provide the aforementioned functionality. For example, perhaps when a new PhIF is indicated as UP or DW, among other reasons, the SM may decide if an IP can be retrieved from this interface and provided to the MC TrFC.
Embodiments contemplate an SM PolicyUpdate function/operation. In one or more embodiments, perhaps during operation for example, the policies can dynamically change. For example, if a new or recent (e.g., a change of conditions after an initial configuration is made) BWM Mode or IFOM are received, among other reasons, the SM may close and/or open one or more sessions which do not address the recently received BWM and/or IFOM policies by calling the SM_SessionClose function with the relevant Session ID.
Embodiments contemplate Session Manager Architecture & Interfaces. In one or more embodiments, the SM may interface with the CM, policy management system, ASIF, transport FC, SSO proxy, and/or DNS proxy through, respectively, interfaces C3, P1, C1, C2, C12 and/or C13.
Embodiments contemplate one or more Session Manager (SM) Interfaces. For example, one or more embodiments contemplate a C1—Session Manager and ASIF interface. C1 may serve as the interface between the advanced socket IF (ASIF) and the session manager (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. By way of example, and not limitation, a change can be an addition of a new sub-flow to the session, a deletion of a sub-flow or a change in the session description (new QoS, mobility required or not, level of security), among other changes. Example C1 functions are provided in Table 7.
Embodiments contemplate a C2 interface, perhaps to sever for the Session Manager and Transport FC (TFC), for example. Table 8 shows example C2 functions.
Embodiments contemplate a C3 interface, perhaps to serve for the Connection Manager (CM) and Session Manager (SM), for example. In one or more embodiments, C3 is the interface between the CM and the SM. Example C3 functions are provided in Table 9.
Embodiments contemplate a P1 interface, perhaps to serve for the Policy Manager and Session Manager (SM), for example. In one or more embodiments, P1 may allow policy manager to provide SM with the policy that may need to be applied by the device or may be used by the device. Table 10 below shows example P1 functions.
Embodiments contemplate a C12 interface, perhaps to serve as an interface for the Session Manager and SSO Proxy, for example. In one or more embodiments, C12 may be the interface between the SM and the SSO proxy. This interface may allow the triggering of the SSO steps that handle authentication of the user in the network, for example. Example C12 functions are provided in Table 11.
Embodiments contemplate a C13 interface, perhaps to serve the Session Manager (SM) and Domain Name System (DNS), for example. In one or more embodiments, C12 may be the interface between the SM and the DNS proxy. Table 12 shows example C13 functions.
Embodiments contemplate one or more Source IP Address Selection Algorithms. In one or more embodiments, heretofore unknown or described functions and/or operations of the parameter “Getaddrinfo” are contemplated. In one or more embodiments, the SM may perform source IP address selection that may better align with the applied policies, e.g., a specific application can go over this type of link, based on QoS, security, etc.
In one or more embodiments, the CM may indicate to SM the mobility support of an IP address (if it is a Mobile Core IP address, or a local breakout IP, etc.). The SM may have the list of source IP available stored in the SM operation table. The SM may maintain a table of initial source IP and conditions when they are used. Example conditions and source IP that may be used are illustrated in Table 12-A.
Embodiments contemplate that, for cases not specified in table 12-A (and perhaps in all such cases), the SM may use a DEFAULT_SOURCE_IP. DEFAULT_SOURCEIP may be determined based on, at least in part, operator and other policies. In one or more embodiments, the DEFAULT_SOURCE_IP may be at least one of following: primary mobile operation IP associated with primary PDP context; and/or “fake” non-existent IP from private network, e.g. 192.xxx.xxx.xxx.
Embodiments contemplate one or more Local IP Addresses for an Unbound Socket. In one or more embodiments, perhaps if the connect( ) is called to an unbound socket for example (among other reasons and conditions), the kernel may determine over which local interface to send outgoing packets. In one or more embodiments, the kernel may select a random free source port with the local address set to INADDR_ANY, which may mean the default IP address provided by the routing table. Similarly to source IP selection, in one or more embodiments, the SM may perform this function to better align with the policies, e.g., most preferred network, etc.
Embodiments contemplate one or more SM Policies and QoS Requirements. In one or more embodiments, perhaps prior to requesting resources to CM—or for other reasons or conditions, the SM may check the application's requirements and the policies that apply to the requested socket to identify the best match, for example.
Embodiments contemplate one or more Application QoS Requirements. By way of example, and not limitation, QoS requirements may include, but are not limited to, QoS priorities (e.g., throughput, latency, error, etc.); preferred network for the application (e.g., preferred APN provided for 3G network, and preferred network ID provided for non-3GPP access); list of prohibited networks; traffic prioritization; mobility requirement per application; BWA (i.e. aggregation) requirement; and/or security requirements.
For LEGACY Application, the QoS requirements may be provided by the policy management (policy and/or QoS manager), with a table similar to the following Table 13 showing an example of per application QoS requirements.
In view of
Embodiments contemplate that, alternatively or additionally, at 5008, the processor may be further configured to use the at least one function to determine a service type for use by at least one of the one or more sessions. At, 5010, alternatively or additionally, embodiments contemplate that the processor may be further configured to use the at least one function to determine a radio access technology (RAT) for use by at least one of the one or more sessions. Referring to
At 5014, alternatively or additionally, embodiments contemplate that the processor may be further configured to use the at least one function to delete the second session of the one or more sessions upon determining that the first session of the one or more sessions is higher in priority than the second session. One or more embodiments contemplate that the at least one function may be a session manager function. Alternatively or additionally, at 5016, embodiments contemplate that the processor may be configured to use the at least one function to determine that at least one of the one or more sessions is to be closed, and, at 5018, to use the at least one function to close the at least one of the one or more sessions.
Referring to
At 6006, alternatively or additionally, embodiments contemplate that the one or more conditions may include at least one correspondence between the one or more source IP addresses and at least one of a type of application or an availability of a mobility support. One or more embodiments contemplate that the at least one function may be a session manager function. At 6008, alternatively or additionally, embodiments contemplate that the at least one function may utilize a getaddrinfo parameter. Embodiments contemplate that the QoS requirements may include at least one of a preferred network for an application, a list of prohibited networks, a mobility requirement per application, or a bandwidth aggregation requirement.
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 Application No. 61/473,963, titled “SESSION MANAGER AND SOURCE INTERNET PROTOCOL (IP) ADDRESS SELECTION”, filed on Apr. 11, 2011, the content of which being hereby incorporated by reference herein in its entirety, for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61473963 | Apr 2011 | US |
